27 Mar, 2012

3 commits

  • Use pr_fmt to prefix KBUILD_MODNAME to appropriate logging messages.

    Remove now unnecessary internal prefixes from formats.

    Signed-off-by: Joe Perches
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Joe Perches
     
  • Use the more current logging style.

    Coalesce formats, align arguments.
    Convert uses of embedded function names to %s, __func__.

    A couple of long line checkpatch errors I don't care about exist.

    Signed-off-by: Joe Perches
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Joe Perches
     
  • D1 and D2 macros are mostly uses to emit debugging messages.

    Convert the logging uses of D1 & D2 to jffs2_dbg(level, fmt, ...)
    to be a bit more consistent style with the rest of the kernel.

    All jffs2_dbg output is now at KERN_DEBUG where some of
    the previous uses were emitted at various KERN_s.

    Signed-off-by: Joe Perches
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Joe Perches
     

01 Dec, 2009

1 commit

  • In 2.6.23 kernel, commit a32ea1e1f925399e0d81ca3f7394a44a6dafa12c
    ("Fix read/truncate race") fixed a race in the generic code, and as a
    side effect, now do_generic_file_read() can ask us to readpage() past
    the i_size. This seems to be correctly handled by the block routines
    (e.g. block_read_full_page() fills the page with zeroes in case if
    somebody is trying to read past the last inode's block).

    JFFS2 doesn't handle this; it assumes that it won't be asked to read
    pages which don't exist -- and thus that there will be at least _one_
    valid 'frag' on the page it's being asked to read. It will fill any
    holes with the following memset:

    memset(buf, 0, min(end, frag->ofs + frag->size) - offset);

    When the 'closest smaller match' returned by jffs2_lookup_node_frag() is
    actually on a previous page and ends before 'offset', that results in:

    memset(buf, 0, );

    Hopefully, in most cases the corruption is fatal, and quickly causing
    random oopses, like this:

    root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01
    Unable to handle kernel paging request for data at address 0x00000008
    Faulting instruction address: 0xc01cd980
    Oops: Kernel access of bad area, sig: 11 [#1]
    [...]
    NIP [c01cd980] rb_insert_color+0x38/0x184
    LR [c0043978] enqueue_hrtimer+0x88/0xc4
    Call Trace:
    [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable)
    [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4
    [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc
    [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8
    [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254
    [c6c63c30] [c001352c] ret_from_except+0x0/0x14
    --- Exception: 901 at memset+0x38/0x5c
    LR = jffs2_read_inode_range+0x144/0x17c
    [c6c63cf0] [00000000] (null) (unreliable)

    This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with
    JFFS2 filesystem that were failing since 2.6.23 (seems like the bug
    above also broke the truncation).

    Reported-By: Anton Vorontsov
    Tested-By: Anton Vorontsov
    Signed-off-by: David Woodhouse
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    David Woodhouse
     

25 Apr, 2007

1 commit

  • In particular, remove the bit in the LICENCE file about contacting
    Red Hat for alternative arrangements. Their errant IS department broke
    that arrangement a long time ago -- the policy of collecting copyright
    assignments from contributors came to an end when the plug was pulled on
    the servers hosting the project, without notice or reason.

    We do still dual-license it for use with eCos, with the GPL+exception
    licence approved by the FSF as being GPL-compatible. It's just that nobody
    has the right to license it differently.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

07 Nov, 2005

2 commits


06 Nov, 2005

1 commit


23 May, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds