Eric Lee / smarc-fsl-linux-kernel

07 Apr, 2009

1 commit

  • e0724bf6e   Merge branch 'linux-next' of git://git.infradead.org/ubifs-2.6 ... Browse Code »

    * 'linux-next' of git://git.infradead.org/ubifs-2.6:
    UBIFS: fix recovery bug
    UBIFS: add R/O compatibility
    UBIFS: fix compiler warnings
    UBIFS: fully sort GCed nodes
    UBIFS: fix commentaries
    UBIFS: introduce a helpful variable
    UBIFS: use KERN_CONT
    UBIFS: fix lprops committing bug
    UBIFS: fix bogus assertion
    UBIFS: fix bug where page is marked uptodate when out of space
    UBIFS: amend key_hash return value
    UBIFS: improve find function interface
    UBIFS: list usage cleanup
    UBIFS: fix dbg_chk_lpt_sz()

    Linus Torvalds
     

01 Apr, 2009

1 commit

  • c2ec175c3   mm: page_mkwrite change prototype to match fault ... Browse Code »

    Change the page_mkwrite prototype to take a struct vm_fault, and return
    VM_FAULT_xxx flags. There should be no functional change.

    This makes it possible to return much more detailed error information to
    the VM (and also can provide more information eg. virtual_address to the
    driver, which might be important in some special cases).

    This is required for a subsequent fix. And will also make it easier to
    merge page_mkwrite() with fault() in future.

    Signed-off-by: Nick Piggin
    Cc: Chris Mason
    Cc: Trond Myklebust
    Cc: Miklos Szeredi
    Cc: Steven Whitehouse
    Cc: Mark Fasheh
    Cc: Joel Becker
    Cc: Artem Bityutskiy
    Cc: Felix Blyakher
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

21 Mar, 2009

1 commit

14 Mar, 2009

1 commit

  • f55aa5910   UBIFS: fix bug where page is marked uptodate when out of space ... Browse Code »

    UBIFS fast path in write_begin may mark a page up to date
    and then discover that there may not be enough space to do
    the write, and so fall back to a slow path. The slow path
    tries harder, but may still find no space - leaving the page
    marked up to date, when it is not. This patch ensures that
    the page is marked not up to date in that case.

    The bug that this patch fixes becomes evident when the write
    is into a hole (sparse file) or is at the end of the file
    and a subsequent read is off the end of the file. In both
    cases, the file system should return zeros but was instead
    returning the page that had not been written because the
    file system was out of space.

    Signed-off-by: Adrian Hunter
    Signed-off-by: Artem Bityutskiy

    Adrian Hunter
     

26 Jan, 2009

1 commit

18 Jan, 2009

1 commit

05 Jan, 2009

1 commit

  • 54566b2c1   fs: symlink write_begin allocation context fix ... Browse Code »

    With the write_begin/write_end aops, page_symlink was broken because it
    could no longer pass a GFP_NOFS type mask into the point where the
    allocations happened. They are done in write_begin, which would always
    assume that the filesystem can be entered from reclaim. This bug could
    cause filesystem deadlocks.

    The funny thing with having a gfp_t mask there is that it doesn't really
    allow the caller to arbitrarily tinker with the context in which it can be
    called. It couldn't ever be GFP_ATOMIC, for example, because it needs to
    take the page lock. The only thing any callers care about is __GFP_FS
    anyway, so turn that into a single flag.

    Add a new flag for write_begin, AOP_FLAG_NOFS. Filesystems can now act on
    this flag in their write_begin function. Change __grab_cache_page to
    accept a nofs argument as well, to honour that flag (while we're there,
    change the name to grab_cache_page_write_begin which is more instructive
    and does away with random leading underscores).

    This is really a more flexible way to go in the end anyway -- if a
    filesystem happens to want any extra allocations aside from the pagecache
    ones in ints write_begin function, it may now use GFP_KERNEL (rather than
    GFP_NOFS) for common case allocations (eg. ocfs2_alloc_write_ctxt, for a
    random example).

    [kosaki.motohiro@jp.fujitsu.com: fix ubifs]
    [kosaki.motohiro@jp.fujitsu.com: fix fuse]
    Signed-off-by: Nick Piggin
    Reviewed-by: KOSAKI Motohiro
    Cc: [2.6.28.x]
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    [ Cleaned up the calling convention: just pass in the AOP flags
    untouched to the grab_cache_page_write_begin() function. That
    just simplifies everybody, and may even allow future expansion of the
    logic. - Linus ]
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

31 Dec, 2008

1 commit

  • f92b98268   UBIFS: fix checkpatch.pl warnings ... Browse Code »

    These are mostly long lines and wrong indentation warning
    fixes. But also there are two volatile variables and
    checkpatch.pl complains about them:

    WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
    + volatile int gc_seq;

    WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
    + volatile int gced_lnum;

    Well, we anyway use smp_wmb() for c->gc_seq and c->gced_lnum, so
    these 'volatile' modifiers can be just dropped.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

23 Dec, 2008

1 commit

22 Nov, 2008

3 commits

  • 3477d2046   UBIFS: pre-allocate bulk-read buffer ... Browse Code »

    To avoid memory allocation failure during bulk-read, pre-allocate
    a bulk-read buffer, so that if there is only one bulk-reader at
    a time, it would just use the pre-allocated buffer and would not
    do any memory allocation. However, if there are more than 1 bulk-
    reader, then only one reader would use the pre-allocated buffer,
    while the other reader would allocate the buffer for itself.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • 6c0c42cdf   UBIFS: do not allocate too much ... Browse Code »

    Bulk-read allocates 128KiB or more using kmalloc. The allocation
    starts failing often when the memory gets fragmented. UBIFS still
    works fine in this case, because it falls-back to standard
    (non-optimized) read method, though. This patch teaches bulk-read
    to allocate exactly the amount of memory it needs, instead of
    allocating 128KiB every time.

    This patch is also a preparation to the further fix where we'll
    have a pre-allocated bulk-read buffer as well. For example, now
    the @bu object is prepared in 'ubifs_bulk_read()', so we could
    path either pre-allocated or allocated information to
    'ubifs_do_bulk_read()' later. Or teaching 'ubifs_do_bulk_read()'
    not to allocate 'bu->buf' if it is already there.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • 39ce81ce7   UBIFS: do not print scary memory allocation warnings ... Browse Code »

    Bulk-read allocates a lot of memory with 'kmalloc()', and when it
    is/gets fragmented 'kmalloc()' fails with a scarry warning. But
    because bulk-read is just an optimization, UBIFS keeps working fine.
    Supress the warning by passing __GFP_NOWARN option to 'kmalloc()'.

    This patch also introduces a macro for the magic 128KiB constant.
    This is just neater.

    Note, this is not really fixes the problem we had, but just hides
    the warnings. The further patches fix the problem.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

06 Nov, 2008

1 commit

  • 0ecb9529a   UBIFS: endian handling fixes and annotations ... Browse Code »

    Noticed by sparse:
    fs/ubifs/file.c:75:2: warning: restricted __le64 degrades to integer
    fs/ubifs/file.c:629:4: warning: restricted __le64 degrades to integer
    fs/ubifs/dir.c:431:3: warning: restricted __le64 degrades to integer

    This should be checked to ensure the ubifs_assert is working as
    intended, I've done the suggested annotation in this patch.

    fs/ubifs/sb.c:298:6: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:298:6: expected int [signed] [assigned] tmp
    fs/ubifs/sb.c:298:6: got restricted __le64 [usertype]
    fs/ubifs/sb.c:299:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:299:19: expected restricted __le64 [usertype] atime_sec
    fs/ubifs/sb.c:299:19: got int [signed] [assigned] tmp
    fs/ubifs/sb.c:300:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:300:19: expected restricted __le64 [usertype] ctime_sec
    fs/ubifs/sb.c:300:19: got int [signed] [assigned] tmp
    fs/ubifs/sb.c:301:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:301:19: expected restricted __le64 [usertype] mtime_sec
    fs/ubifs/sb.c:301:19: got int [signed] [assigned] tmp

    This looks like a bugfix as your tmp was a u32 so there was truncation in
    the atime, mtime, ctime value, probably not intentional, add a tmp_le64
    and use it here.

    fs/ubifs/key.h:348:9: warning: cast to restricted __le32
    fs/ubifs/key.h:348:9: warning: cast to restricted __le32
    fs/ubifs/key.h:419:9: warning: cast to restricted __le32

    Read from the annotated union member instead.

    fs/ubifs/recovery.c:175:13: warning: incorrect type in assignment (different base types)
    fs/ubifs/recovery.c:175:13: expected unsigned int [unsigned] [usertype] save_flags
    fs/ubifs/recovery.c:175:13: got restricted __le32 [usertype] flags
    fs/ubifs/recovery.c:186:13: warning: incorrect type in assignment (different base types)
    fs/ubifs/recovery.c:186:13: expected restricted __le32 [usertype] flags
    fs/ubifs/recovery.c:186:13: got unsigned int [unsigned] [usertype] save_flags

    Do byteshifting at compile time of the flag value. Annotate the saved_flags
    as le32.

    fs/ubifs/debug.c:368:10: warning: cast to restricted __le32
    fs/ubifs/debug.c:368:10: warning: cast from restricted __le64

    Should be checked if the truncation was intentional, I've changed the
    printk to print the full width.

    Signed-off-by: Harvey Harrison
    Signed-off-by: Artem Bityutskiy

    Harvey Harrison
     

30 Sep, 2008

3 commits

21 Aug, 2008

1 commit

  • 04da11bfc   UBIFS: fix zero-length truncations ... Browse Code »

    Always allow truncations to zero, even if budgeting thinks there
    is no space. UBIFS reserves some space for deletions anyway.

    Otherwise, the following happans:
    1. create a file, and write as much as possible there, until ENOSPC
    2. truncate the file, which fails with ENOSPC, which is not good.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

13 Aug, 2008

3 commits

27 Jul, 2008

1 commit

15 Jul, 2008

1 commit