17 Oct, 2007
2 commits
-
Slab constructors currently have a flags parameter that is never used. And
the order of the arguments is opposite to other slab functions. The object
pointer is placed before the kmem_cache pointer.Convert
ctor(void *object, struct kmem_cache *s, unsigned long flags)
to
ctor(struct kmem_cache *s, void *object)
throughout the kernel
[akpm@linux-foundation.org: coupla fixes]
Signed-off-by: Christoph Lameter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Nick Piggin
Cc: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Oct, 2007
7 commits
-
Signed-off-by: David Woodhouse
-
In three places: summary scan, normal scan, REF_PRISTINE GC.
Just truncate at the NUL, since that was the correct thing to do in the
only case where this (inexplicable) breakage has been seen.Signed-off-by: David Woodhouse
-
I have no idea how this happened, but OLPC trac #4184 suggests that it
did. Catch it early.Signed-off-by: David Woodhouse
-
... where we'll actually print the count in a debug message.
Signed-off-by: David Woodhouse
-
In OLPC trac #4184 we found a case where a corrupted node didn't
actually get obsoleted when we tried to garbage-collect it. So we wrote
out many million copies of it, in repeated attempts to obsolete it,
until the flash became full. Don't Do That.Signed-off-by: David Woodhouse
-
Instead of matching resv_blocks_gcmerge, which is only about 3, instead
match resv_blocks_gctrigger, which includes a proportion of the total
device size.These ought to become tunable from userspace, at some point.
Signed-off-by: David Woodhouse
07 Oct, 2007
1 commit
-
With huge amounts of free space, we weren't bothering to GC for while a
while, and pathological numbers of obsolete nodes were accumulating,
seriously affecting performance on NAND flash (OLPC trac #3978)Signed-off-by: David Woodhouse
24 Sep, 2007
1 commit
-
Fix a couple of instances in JFFS2 where the unpoint() routine is
being called with the wrong length in cases where the point() routine
truncated a request.Signed-off-by: Andy Lowe
Signed-off-by: Nicolas Pitre
Signed-off-by: David Woodhouse
03 Sep, 2007
1 commit
-
I've bisected the deadlock when many small appends are done on jffs2 down to
this commit:commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2
Author: Nick Piggin
Date: Sun May 6 14:49:04 2007 -0700mm: make read_cache_page synchronous
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate calls.I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
block2mtd. All depending on whether the filler is async and/or can return
with a !uptodate page.It introduced a wait to read_cache_page, as well as a
read_cache_page_async function equivalent to the old read_cache_page
without any callers.Switching jffs2_gc_fetch_page to read_cache_page_async for the old
behavior makes the deadlocks go away, but maybe reintroduces the
use-before-uptodate problem? I don't understand the mm/fs interaction
well enough to say.[It's fine. dwmw2.]
Signed-off-by: Jason Lunz
Signed-off-by: David Woodhouse
23 Aug, 2007
1 commit
22 Aug, 2007
2 commits
-
fs/jffs2/erase.c: In function 'jffs2_block_check_erase':
fs/jffs2/erase.c:355: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'and
fs/jffs2/erase.c: In function 'jffs2_erase_pending_blocks':
fs/jffs2/erase.c:404: warning: 'bad_offset' may be used uninitialized in this functionSigned-off-by: Andrew Morton
Signed-off-by: David Woodhouse -
When POSIX ACL support was enabled, we weren't writing correct
legacy modes to the medium on inode creation, or when the ACL was set.
This meant that the permissions would be incorrect after the file system
was remounted.Signed-off-by: David Woodhouse
21 Aug, 2007
1 commit
-
Commit a491486a2087ac3dfc00efb4f838c8d684afaf54 introduced a locking
problem in JFFS2 -- we up() the alloc_sem when we weren't previously
holding it. This leads to all kinds of fun behaviour later.There was a _reason_ for the
if (1 /* alternative path needs testing */ ||
which the above-mentioned commit removed :)Discovered and debugged by Giulio Fedel
Signed-off-by: David Woodhouse
Signed-off-by: Linus Torvalds
09 Aug, 2007
1 commit
-
Commit a7a6ace1406f95c3edb8365788f85984377f3832 revamped the OOB
handling but accidentally switched to 12-byte cleanmarkers, which is
incompatible with what 'flash_eraseall -j' will do. So using
flash_eraseall -j and then trying to mount the 'empty' flash will fail,
because the cleanmarkers aren't recognised.Signed-off-by: David Woodhouse
03 Aug, 2007
4 commits
-
Debugging the hardware problems in OLPC trac #1905 would be a whole lot
easier if the correct node offsets were printed for the offending nodes.Signed-off-by: David Woodhouse
-
The try_to_freeze() call was in the wrong place; we need it in the
signal-pending loop now that a pending freeze also makes
signal_pending() return true.Signed-off-by: David Woodhouse
-
Otherwise they'll never actually get garbage-collected.
Noted by Jonathan Larmour.Signed-off-by: David Woodhouse
-
jffs2_add_physical_node_ref() should never really return error -- it's
an internal debugging check which triggered. We really need to work out
why and stop it happening. But in the meantime, let's make the failure
mode a little less nasty.Signed-off-by: Joakim Tjernlund
Signed-off-by: David Woodhouse
23 Jul, 2007
1 commit
20 Jul, 2007
1 commit
-
Slab destructors were no longer supported after Christoph's
c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
BUGs for both slab and slub, and slob never supported them
either.This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).Signed-off-by: Paul Mundt
18 Jul, 2007
2 commits
-
Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
users to it. This is done because we want to avoid bugs in the future
where we check for only effective fsuid of the current task against a
file's owning uid, without simultaneously checking for CAP_FOWNER as
well, thus violating its semantics.
[ XFS uses special macros and structures, and in general looked ...
untouchable, so we leave it alone -- but it has been looked over. ]The (current->fsuid != inode->i_uid) check in generic_permission() and
exec_permission_lite() is left alone, because those operations are
covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.Signed-off-by: Satyam Sharma
Cc: Al Viro
Acked-by: Serge E. Hallyn
Signed-off-by: Linus Torvalds -
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves. This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.The patch causes all kernel threads to be nonfreezable by default (ie. to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE. It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear. Additionally, it updates documentation to
describe the freezing of tasks more accurately.[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki
Acked-by: Nigel Cunningham
Cc: Pavel Machek
Cc: Oleg Nesterov
Cc: Gautham R Shenoy
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jul, 2007
5 commits
-
fs/jffs2/compr.c: In function ‘jffs2_compressors_init’:
fs/jffs2/compr.c:320: warning: implicit declaration of function ‘jffs2_lzo_init’
fs/jffs2/compr.c: In function ‘jffs2_compressors_exit’:
fs/jffs2/compr.c:346: warning: implicit declaration of function ‘jffs2_lzo_exit’Signed-off-by: David Woodhouse
-
Add a "favourlzo" compression mode to jffs2 which tries to
optimise by size but gives lzo an advantage when comparing sizes.
This means the faster lzo algorithm can be preferred when there
isn't much difference in compressed size (the exact threshold can
be changed).Signed-off-by: Richard Purdie
Signed-off-by: David Woodhouse -
Add LZO1X compression/decompression support to jffs2.
LZO's interface doesn't entirely match that required by jffs2 so a
buffer and memcpy is unavoidable.Signed-off-by: Richard Purdie
Signed-off-by: David Woodhouse -
We've seen some evil corruption issues, where the corruption seems to be
introduced after the JFFS2 crc32 is calculated but before the NAND
controller calculates the ECC. So it's in RAM or in the PCI DMA
transfer; not on the flash. Attempt to catch it earlier by (optionally)
reading back from the flash immediately after writing it.Signed-off-by: David Woodhouse
10 Jul, 2007
2 commits
-
Convert many spaces to tabs; one or two other minor cosmetic fixes.
Signed-off-by: David Woodhouse
-
They can use generic_file_splice_read() instead. Since sys_sendfile() now
prefers that, there should be no change in behaviour.Signed-off-by: Jens Axboe
05 Jul, 2007
1 commit
-
Debugging the hardware problems in OLPC trac #1905 would be a whole lot
easier if the correct node offsets were printed for the offending nodes.Signed-off-by: David Woodhouse
04 Jul, 2007
2 commits
-
We should have stopped returning 1 from read_dnode() to indicate
failure. We can just mark the damn thing obsolete immediately. But I
missed a case where we don't.Signed-off-by: David Woodhouse
-
We should have stopped returning 1 from read_dnode() to indicate
failure. We can just mark the damn thing obsolete immediately. But I
missed a case where we don't.Signed-off-by: David Woodhouse
29 Jun, 2007
5 commits
-
Otherwise they'll never actually get garbage-collected.
Noted by Jonathan Larmour.Signed-off-by: David Woodhouse
-
The try_to_freeze() call was in the wrong place; we need it in the
signal-pending loop now that a pending freeze also makes
signal_pending() return true.Signed-off-by: David Woodhouse
-
Jocke has seen this fail. We want to know why.
Signed-off-by: David Woodhouse
-
With current desing erase_free_sem is locked every time the flash
block is being erased. For NOR flashes - ~1 second is needed to erase
single flash block. In the worst case scenario erase_free_sem may be
locked for a couple of seconds when the number of blocks is being
erased (e.g. after large file was removed). When erase_free_sem is
locked all read/write operations for given JFFS2 partition are locked
too - in effect from time to time access to the JFFS2 partition is
locked for a number of seconds. This fix makes critical section in
flash erasing procedure shorter - now erase_free_sem is locked around
erase_completion_lock spinlock only.Originally from Radoslaw Bisewski
Signed-off-by: Joakim Tjernlund
Signed-off-by: David Woodhouse -
jffs2_add_physical_node_ref() should never really return error -- it's
an internal debugging check which triggered. We really need to work out
why and stop it happening. But in the meantime, let's make the failure
mode a little less nasty.Signed-off-by: Joakim Tjernlund
Signed-off-by: David Woodhouse