kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-16 22:39:48 +00:00
Code Issues Releases Packages Activity
linux/fs/ntfs/malloc.h

91 lines
3 KiB
Raw Permalink Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: Fix ntfs_{read,write}page() to cope with concurrent truncates better. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-19 09:41:39 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. - Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based allocations are done. - Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail() which is analogous to ntfs_malloc_nofs() but it performs allocations with __GFP_NOFAIL and hence cannot fail. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-08 16:28:25 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. - Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based allocations are done. - Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail() which is analogous to ntfs_malloc_nofs() but it performs allocations with __GFP_NOFAIL and hence cannot fail. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-08 16:28:25 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: In attrib.c::ntfs_attr_set() call balance_dirty_pages_ratelimited() and cond_resched() in the main loop as we could be dirtying a lot of pages and this ensures we play nice with the VM and the system as a whole. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-10-11 14:54:42 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: Mask out __GFP_HIGHMEM when doing kmalloc() in __ntfs_malloc() as it otherwise causes a BUG(). Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-12 15:43:03 +01:00
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. - Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based allocations are done. - Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail() which is analogous to ntfs_malloc_nofs() but it performs allocations with __GFP_NOFAIL and hence cannot fail. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-08 16:28:25 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
mm: replace various uses of num_physpages by totalram_pages Sizing of memory allocations shouldn't depend on the number of physical pages found in a system, as that generally includes (perhaps a huge amount of) non-RAM pages. The amount of what actually is usable as storage should instead be used as a basis here. Some of the calculations (i.e. those not intending to use high memory) should likely even use (totalram_pages - totalhigh_pages). Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Dave Airlie <airlied@linux.ie> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: "David S. Miller" <davem@davemloft.net> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-21 17:03:05 -07:00
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. - Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based allocations are done. - Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail() which is analogous to ntfs_malloc_nofs() but it performs allocations with __GFP_NOFAIL and hence cannot fail. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-08 16:28:25 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. - Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based allocations are done. - Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail() which is analogous to ntfs_malloc_nofs() but it performs allocations with __GFP_NOFAIL and hence cannot fail. Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
2005-09-08 16:28:25 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
NTFS: use kvfree() in ntfs_free() Use kvfree() instead of open-coding it. Signed-off-by: Pekka Enberg <penberg@kernel.org> Cc: Anton Altaparmakov <anton@tuxera.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-24 16:54:48 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00