20 Apr, 2007

5 commits

  • I've traced down an off-by-one TCP checksum calculation error under
    the following conditions:

    1) The TCP code needs to split a full-sized packet due to a reduced
    MSS (typically due to the addition of TCP options mid-stream like
    SACK).
    _AND_
    2) The checksum of the 2nd fragment is larger than the checksum of the
    original packet. After subtraction this results in a checksum for
    the 1st fragment with bits 16..31 set to 1. (this is ok)
    _AND_
    3) The checksum of the 1st fragment's TCP header plus the previously
    32bit checksum of the 1st fragment DOES NOT cause a 32bit overflow
    when added together. This results in a checksum of the TCP header
    plus TCP data that still has the upper 16 bits as 1's.
    _THEN_
    4) The TCP+data checksum is added to the checksum of the pseudo IP
    header with csum_tcpudp_nofold() incorrectly (the bug).

    The problem is the checksum of the TCP+data is passed to
    csum_tcpudp_nofold() as an 32bit unsigned value, however the assembly
    code acts on it as if it is a 64bit unsigned value.

    This causes an incorrect 32->64bit extension if the sum has bit 31
    set. The resulting checksum is off by one.

    This problems is data and TCP header dependent due to #2 and #3
    above so it doesn't occur on every TCP packet split.

    Signed-off-by: Dave Johnson
    Signed-off-by: Ralf Baechle

    Dave Johnson
     
  • With commit 63dc68a8cf60cb110b147dab1704d990808b39e2, kernel can not
    handle BUG() and BUG_ON() properly since get_user() returns false for
    kernel code. Use __get_user() to skip unnecessary access_ok(). This
    patch also make BRK_BUG code encoded in the TNE instruction.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     
  • The save_fp_context()/restore_fp_context() might sleep on accessing
    user stack and therefore might lose FPU ownership in middle of them.

    If these function failed due to "in_atomic" test in do_page_fault,
    touch the sigcontext area in non-atomic context and retry these
    save/restore operation.

    This is a replacement of a (broken) fix which was titled "Allow CpU
    exception in kernel partially".

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     
  • The commit 4d40bff7110e9e1a97ff8c01bdd6350e9867cc10 ("Allow CpU
    exception in kernel partially") was broken. The commit was to fix
    theoretical problem but broke usual case. Revert it for now.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     
  • Recent versions of the BCM112X processors aren't recognized by Linux
    (preventing Linux from booting on those processors). This patch adds
    support for those that are missing.

    Signed-off-by: Mark Mason
    Signed-off-by: Ralf Baechle

    Mark Mason
     

30 Mar, 2007

2 commits


25 Mar, 2007

6 commits


18 Mar, 2007

1 commit


17 Mar, 2007

4 commits


10 Mar, 2007

1 commit

  • o Fix build error.
    o Handle error returns.
    o Deal with signals received while sleeping.
    o Don't allow to be selected when we're not building the directory with
    the driver anyway.
    o Coding style cleanups.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

08 Mar, 2007

1 commit


07 Mar, 2007

7 commits


05 Mar, 2007

6 commits


27 Feb, 2007

2 commits


22 Feb, 2007

1 commit

  • This patch adds trivial support for SMARTMIPS extension. This extension
    is currently implemented by 4KS[CD] CPUs.

    Basically it saves/restores ACX register, which is part of the SMARTMIPS
    ASE, when needed. This patch does *not* add any support for Smartmips MMU
    features.

    Futhermore this patch does not add explicit support for 4KS[CD] CPUs since
    they are respectively mips32 and mips32r2 compliant. So with the current
    processor configuration, a platform that has such CPUs needs to select
    both configs:

    CPU_HAS_SMARTMIPS
    SYS_HAS_CPU_MIPS32_R[12]

    This is due to the processor configuration which is mixing up all the
    architecture variants and the processor types.

    The drawback of this, is that we currently pass '-march=mips32' option to
    gcc when building a kernel instead of '-march=4ksc' for 4KSC case. This
    can lead to a kernel image a little bit bigger than required.

    Signed-off-by: Franck Bui-Huu
    Signed-off-by: Ralf Baechle

    Franck Bui-Huu
     

20 Feb, 2007

2 commits

  • From the 01408c4939479ec46c15aa7ef6e2406be50eeeca log message:

    The problem is that when we write to a file, the copy from userspace to
    pagecache is first done with preemption disabled, so if the source
    address is not immediately available the copy fails *and* *zeros* *the*
    *destination*.

    This is a problem because a concurrent read (which admittedly is an odd
    thing to do) might see zeros rather that was there before the write, or
    what was there after, or some mixture of the two (any of these being a
    reasonable thing to see).

    If the copy did fail, it will immediately be retried with preemption
    re-enabled so any transient problem with accessing the source won't
    cause an error.

    The first copying does not need to zero any uncopied bytes, and doing
    so causes the problem. It uses copy_from_user_atomic rather than
    copy_from_user so the simple expedient is to change copy_from_user_atomic
    to *not* zero out bytes on failure.

    < --- end cite --- >

    This patch finally implements at least a not so pretty solution by
    duplicating the relevant part of __copy_user.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • The kernel use 64-bit for sc_regs[0], and both N32/N64 userland
    expects it was 64-bit. But size of 'long' on N32 is actually 32-bit.
    So this definition make some confusion. Use __u32 and __u64 for
    N32/N64 sigcontext to get rid of this confusion.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     

19 Feb, 2007

2 commits