linux, branch v2.6.13

Linux v2.6.13

2005-08-28T23:41:01Z

[PATCH] zfcp: bugfix and compile fixes

2005-08-28T20:53:48Z

Bugfix (usage of uninitialized pointer in zfcp_port_dequeue) and compile fixes for the zfcp device driver. Signed-off-by: Heiko Carstens Acked-by: James Bottomley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] zfcp: fix compilation due to rports changes

2005-08-28T17:43:18Z

struct zfcp_port::scsi_id was removed by commit 3859f6a248cbdfbe7b41663f3a2b51f48e30b281 Signed-off-by: Alexey Dobriyan Signed-off-by: Linus Torvalds

Merge refs/heads/upstream-fixes from master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6

2005-08-28T01:05:14Z

[PATCH] Remove race between con_open and con_close

2005-08-28T01:03:42Z

[ Same race and same patch also by Steven Rostedt ] I have a laptop (G3 powerbook) which will pretty reliably hit a race between con_open and con_close late in the boot process and oops in vt_ioctl due to tty->driver_data being NULL. What happens is this: process A opens /dev/tty6; it comes into con_open() (drivers/char/vt.c) and assign a non-NULL value to tty->driver_data. Then process A closes that and concurrently process B opens /dev/tty6. Process A gets through con_close() and clears tty->driver_data, since tty->count == 1. However, before process A can decrement tty->count, we switch to process B (e.g. at the down(&tty_sem) call at drivers/char/tty_io.c line 1626). So process B gets to run and comes into con_open with tty->count == 2, as tty->count is incremented (in init_dev) before con_open is called. Because tty->count != 1, we don't set tty->driver_data. Then when the process tries to do anything with that fd, it oopses. The simple and effective fix for this is to test tty->driver_data rather than tty->count in con_open. The testing and setting of tty->driver_data is serialized with respect to the clearing of tty->driver_data in con_close by the console_sem. We can't get a situation where con_open sees tty->driver_data != NULL and then con_close on a different fd clears tty->driver_data, because tty->count is incremented before con_open is called. Thus this patch eliminates the race, and in fact with this patch my laptop doesn't oops. Signed-off-by: Paul Mackerras [ Same patch Signed-off-by: Steven Rostedt in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ] Signed-off-by: Linus Torvalds

[PATCH] zfcp: add rports to enable scsi_add_device to work again

2005-08-27T18:22:36Z

This patch fixes a severe problem with 2.6.13-rc7. Due to recent SCSI changes it is not possible to add any LUNs to the zfcp device driver anymore. With registration of remote ports this is fixed. Signed-off-by: Andreas Herrmann Acked-by: James Bottomley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] sg.c: fix a memory leak in devices seq_file implementation

2005-08-27T18:22:27Z

I know that scsi procfs is legacy code but this is a fix for a memory leak. While reading through sg.c I realized that the implementation of /proc/scsi/sg/devices with seq_file is leaking memory due to freeing the pointer returned by the next() iterator method. Since next() might return NULL or an error this is wrong. This patch fixes it through using the seq_files private field for holding the reference to the iterator object. Here is a small bash script to trigger the leak. Use slabtop to watch the size-32 usage grow and grow. #!/bin/sh while true; do cat /proc/scsi/sg/devices > /dev/null done Signed-off-by: Jan Blunck Acked-by: James Bottomley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fix for race problem in DVB USB drivers (dibusb)

2005-08-27T18:03:45Z

Fixed race between submitting streaming URBs in the driver and starting the actual transfer in hardware (demodulator and USB controller) which sometimes lead to garbled data transfers. URBs are now submitted first, then the transfer is enabled. Dibusb devices and clones are now fully functional again. Signed-off-by: Patrick Boettcher Signed-off-by: Linus Torvalds

[PATCH] Fix capifs bug in initialization error path.

2005-08-27T17:11:40Z

This fixes a bug in the capifs initialization code, where the filesystem is not unregistered if kern_mount() fails. Signed-off-by: James Morris Signed-off-by: Karsten Keil Signed-off-by: Linus Torvalds

[PATCH] acpi_shutdown: Only prepare for power off on power_off

2005-08-27T17:11:40Z

When acpi_sleep_prepare was moved into a shutdown method we started calling it for all shutdowns. It appears this triggers some systems to power off on reboot. Avoid this by only calling acpi_sleep_prepare if we are going to power off the system. Signed-off-by: Eric W. Biederman Signed-off-by: Linus Torvalds