[PATCH] 2.4 NFS client - update d_cache when server reports ENOENT on an NFS remove

Anuwat Phrukphicharn of HP discovered and patched this problem in
RHEL-3, and asked that I push it upstream.

When the 2.4 NFS client does a REMOVE and gets an ENOENT back from the
server it does not remove the dentry from the d_cache. This can make it
inappropriately keep writing to an inode that has been renamed.

To reproduce, run this on an NFS server with /scratch exported:

#!/bin/sh
dir=/scratch/98201
mkdir -p $dir/recv
cat /dev/null > $dir/recv/x
while true; do
        length=`wc -l $dir/recv/x | cut -d' ' -f1`
        if [ ${length} -gt 1 ]; then
                echo "problem occured!"
                date
                exit 1
        fi
        mv $dir/x $dir/recv/x
        sleep 1
done

...and then do this on the client:

mount server:/scratch /mnt/server
while true; do
        rm -f /mnt/server/98201/x
        date >> /mnt/server/98201/x
        usleep 100
done

The file "x" should never contain more than 1 line, but occasionally,
the server will report an ENOENT back to the client (indicating that the
server script has renamed the file before the rm could occur). After
this, the client will keep appending to the same inode, even though the
file has been renamed.

I've not seen this problem in 2.6 kernels, but I've not done any
extensive testing there as of yet so I can't confirm whether it's still
a problem there or not.

A patch to fix this follows. It just makes ENOENT a special case when
handling errors in the nfs_safe_remove function, and lets the client
update the dcache as if the remove had succeeded. The ENOENT is still
reported back to userspace. This corrected the problem on my test rig
and for the reporter as well:

Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
[PATCH] [BLKMTD] : missing offset sometimes causes panics

Using JFFS2 on CompactFlash devices via blkmtd on kernel 2.4.32 causes
occasionnal kernel panics.

It happens that every few days (5-10 days), we encounter a kernel BUG in
set_bh_page() during a write because ->offset is bigger than PAGE_SIZE.
The call chain passes via jffs2 and blkmtd. I finally tracked it down to
the commit_pages() function in blkmtd not setting the ->offset member
in the kiovec structure. This one only gets initialized on a previous
read, because kiobuf_init() does not set it either.

I found it logical to set it to zero in commit_pages() because this
function also sets the ->length parameter to a page-aligned value.

2.6 does not have this problem, because it does not use kiovecs.

I suspect not many people use jffs2 on top of blkmtd, and even in this
case, the conditions to meet to trigger the bug are not common at all.

Signed-Off-By: Willy Tarreau <w@1wt.eu>
Ack-By: David Woodhouse <dwmw2@infradead.org>
[PATCH] Bug with USB proc_bulk in 2.4 kernel

Replace the semaphore exclusive_access with an open-coded lock for
the special use. The lock can be taken for: read, write, and both.
This way, two bulk URBs can be submitted simultaneously with ioctl
USBDEVFS_BULK: one read and one write. Such access was possible
before 2.4.28.

The semaphore was introduced in 2.4.28 for the purpose of exclusion
between access from device.c (cat /proc/bus/usb/devices), devio.c
through libusb, and in-kernel driver. Currently, only usb-storage
observes the locking protocol. The most popular device which locks
in case of simultaneous access is TEAC CD-210PU.

Signed-off-By: Pete Zaitcev <zaitcev@redhat.com>
[PATCH] Fix AVM C4 ISDN card init problems with newer CPUs

AVM C4 ISDN NIC: Add three memory barriers, taken from 2.6.7,
(they are there in 2.6.17.7 too), to fix module initialization
problems appearing with at least some newer Celerons and
Pentium III.

Signed-off-by: Jukka Partanen <jspartanen@gmail.com>
Acked-by: Karsten Keil <kkeil@suse.de>
[PATCH] AVM C4 ISDN card : use cpu_relax() in busy loops

As suggested by Alan, use cpu_relax() in 3 busy loops : "It's a
polled busy loop so you want other CPU threads to run if possible".

Signed-off-by: Willy Tarreau <w@1wt.eu>
[PATCH] USB: Little Rework for usbserial

This patch fixes various hangs and oopses which happen if serial devices
are handled roughly (e.g. disconnected while open), open-close-open
races and hangs, and issues with getty running on ttyUSBx.

Finally, I got rid of the "#ifdef I_AM_A_DARING_HACKER". Originally,
I thought it would be there for a week or two, and it was stuck in the
code for two years.

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
[PATCH] USB: unsigned long flags

After a similar problem surfaced in usbserial, I looked across the code base
and found this instance. The bug is obvious: local_irq_save takes a long,
not int.

Signed-Off-By: Pete Zaitcev <zaitcev@redhat.com>
[PATCH] binfmt_elf.c : fix checks for bad address

Fix check for bad address; use macro instead of open-coding two checks.

Explanation from Ernie Petries in 2.6 commit :

  For background, the BAD_ADDR() macro should return TRUE if the address is
  TASK_SIZE, because that's the lowest address that is *not* valid for
  user-space mappings.  The macro was correct in binfmt_aout.c but was wrong
  for the "equal to" case in binfmt_elf.c.  There were two in-line validations
  of user-space addresses in binfmt_elf.c, which have been appropriately
  converted to use the corrected BAD_ADDR() macro in the patch you posted
  yesterday.  Note that the size checks against TASK_SIZE are okay as coded.

Note that this patch slightly differs from Ernie's in that the printk()
only got commented out instead of being removed, since a rate limited call
is expected soon.
[PATCH] crypto : prevent cryptoloop from oopsing on stupid ciphers

With the cryptoloop patch applied, it's possible to request
ECB mode encryption, which will result in a Oops because of
uninitialized function pointers. Initializing them to the
nocrypt_iv() function does not completely solve the problem
because cryptoloop does not check the return code, and kernel
memory will leak uninitialized through cryptoloop.

Proposed solution :
  Can we maybe define working but IV-ignoring functions for ECB (like I
  did), but use memory-clearing nocrypt*() for CFB and CTR (as long as
  these are not supported)?  Of course, all of these will return -ENOSYS.

Response from Herbert Xu :
  In cryptodev-2.6, with block ciphers you can no longer select CFB/CTR
  until someone writes support for them so this is no longer an issue.
  For 2.4, I don't really mind either way what nocrypt does.

Final solution :
  OK, I've merged Willy's suggestion for the memset()s into the patch
  that I had submitted previously.  The resulting patch is attached.
[PATCH] loop.c: kernel_thread() retval check

Patch extracted from 2.4.33-ow1. It has also been ported to 2.6 by
Julio Auto.

Basically, the code in drivers/block/loop.c did not check the return
value from kernel_thread().  If kernel_thread() would fail, the code
would misbehave (IIRC, the invoking process would become unkillable).

An easy way to trigger the bug was to run losetup under strace (as
root), and this is also how I tested the error path added with this
patch.

This change has been a part of publicly released -ow patches for 8+
months.

There are more instances of kernel_thread() calls that do not check the
return value; some of the remaining ones might need to be fixed, too.

Acked-by: Alan Cox <alan@redhat.com>
[PATCH] cciss: do not mark cciss_scsi_detect __init

if the cciss driver is compiled in then later discovery requests
initiated from userland will result in calling free'd memory since
the detect method is marked as __init. suggested fix is to simply
not mark it as __init, 2.6 has done it as well.
[PATCH] [SCTP] Fix sctp_primitive_ABORT() call in sctp_close()

Here is a 2.4 backport of David's fix for a problem with the recent
embargoed patch for CVE-2006-3745. Compile-tested, original
description follows:

[SCTP]: Fix sctp_primitive_ABORT() call in sctp_close().

With the recent fix, the callers of sctp_primitive_ABORT()
need to create an ABORT chunk and pass it as an argument rather
than msghdr that was passed earlier.

Signed-off-by: dann frazier <dannf@debian.org>
[PATCH] Fix possible UDF deadlock and memory corruption (CVE-2006-4145)

Here is a backport of the fix for CVE-2006-4145 fix from 2.6[1]
I've compile-tested it.

[1] http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=commit;h=7127be29378b1230eb8dd8b84f18d6b69c56e959

Description in the original patch follows :

UDF code is not really ready to handle extents larger that 1GB. This
is the easy way to forbid creating those. Also truncation code did not
count with the case when there are no extents in the file and we are
extending the file.

Signed-off-by: dann frazier <dannf@debian.org>
[PATCH] i386 : fix exception processing in early boot

fix the longest existing kernel bug ever (since 0.01 ;-). basically,
the dummy interrupt handler installed for the early boot period does
not work for exceptions that push an error code as well, effectively
making the iret at the end of the handler to trigger another exception,
ad infinitum, or rather, until the kernel stack runs over, trashes all
memory below and eventually causes a CPU reset or a hang. without this
fix the early printk facility in 2.6 is also rather useless.
[PATCH] fbdev: correct buffer size limit in fbmem_read_proc()

Address http://bugzilla.kernel.org/show_bug.cgi?id=7189

It should check `clen', not `len'.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <jurij@wooyd.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: <stable@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
[PATCH] ISDN: fix drivers, by handling errors thrown by ->readstat()

(backport from 2.6-stable)

This is a particularly ugly on-failure bug, possibly security, since the
lack of error handling here is covering up another class of bug: failure to
handle copy_to_user() return values.

The I4L API function ->readstat() returns an integer, and by looking at
several existing driver implementations, it is clear that a negative return
value was meant to indicate an error.

Given that several drivers already return a negative value indicating an
errno-style error, the current code would blindly accept that [negative]
value as a valid amount of bytes read.  Obvious damage ensues.

Correcting ->readstat() handling to properly notice errors fixes the
existing code to work correctly on error, and enables future patches to
more easily indicate errors during operation.

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Karsten Keil <kkeil@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

For 2.4 backport :
Acked-by: Karsten Keil <kkeil@suse.de>
[PATCH-2.4] i2c-elv: fix erroneous '&&' operator

There was clearly a typo in i2c-elv.c.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jean Delvare <khali@linux-fr.org>