[PATCH 00/22] -stable review

[PATCH 00/22] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.16.17 release.
There are 22 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Fri, May 19 22:00 UTC.  Anything received
after that time, might be too late.

thanks,

the -stable release team

[PATCH 01/22] md: Avoid oops when attempting to fix read errors on raid10

[Chris Wright]

[-- Attachment #1: md-avoid-oops-when-attempting-to-fix-read-errors-on-raid10.patch --]
[-- Type: text/plain, Size: 951 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

We should add to the counter for the rdev *after* checking if the rdev is
NULL!!!

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/md/raid10.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.16.orig/drivers/md/raid10.c
+++ linux-2.6.16.16/drivers/md/raid10.c
@@ -1436,9 +1436,9 @@ static void raid10d(mddev_t *mddev)
 						sl--;
 						d = r10_bio->devs[sl].devnum;
 						rdev = conf->mirrors[d].rdev;
-						atomic_add(s, &rdev->corrected_errors);
 						if (rdev &&
 						    test_bit(In_sync, &rdev->flags)) {
+							atomic_add(s, &rdev->corrected_errors);
 							if (sync_page_io(rdev->bdev,
 									 r10_bio->devs[sl].addr +
 									 sect + rdev->data_offset,

--

[PATCH 02/22] [PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards

[Chris Wright]

[-- Attachment #1: via-rhine-zero-pad-short-packets-on-rhine-i-ethernet-cards.patch --]
[-- Type: text/plain, Size: 2512 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

[PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards

Fixes Rhine I cards disclosing fragments of previously transmitted frames
in new transmissions.

Before transmission, any socket buffer (skb) shorter than the ethernet
minimum length of 60 bytes was zero-padded.  On Rhine I cards the data can
later be copied into an aligned transmission buffer without copying this
padding.  This resulted in the transmission of the frame with the extra
bytes beyond the provided content leaking the previous contents of this
buffer on to the network.

Now zero-padding is repeated in the local aligned buffer if one is used.

Following a suggestion from the via-rhine maintainer, no attempt is made
here to avoid the duplicated effort of padding the skb if it is known that
an aligned buffer will definitely be used.  This is to make the change
"obviously correct" and allow it to be applied to a stable kernel if
necessary.  There is no change to the flow of control and the changes are
only to the Rhine I code path.

The patch has run on an in-service Rhine-I host without incident.  Frames
shorter than 60 bytes are now correctly zero-padded when captured on a
separate host.  I see no unusual stats reported by ifconfig, and no unusual
log messages.

Signed-off-by: Craig Brind <craigbrind@gmail.com>
Signed-off-by: Roger Luethi <rl@hellgate.ch>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/via-rhine.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-2.6.16.16.orig/drivers/net/via-rhine.c
+++ linux-2.6.16.16/drivers/net/via-rhine.c
@@ -129,6 +129,7 @@
 	- Massive clean-up
 	- Rewrite PHY, media handling (remove options, full_duplex, backoff)
 	- Fix Tx engine race for good
+	- Craig Brind: Zero padded aligned buffers for short packets.
 
 */
 
@@ -1306,7 +1307,12 @@ static int rhine_start_tx(struct sk_buff
 			rp->stats.tx_dropped++;
 			return 0;
 		}
+
+		/* Padding is not copied and so must be redone. */
 		skb_copy_and_csum_dev(skb, rp->tx_buf[entry]);
+		if (skb->len < ETH_ZLEN)
+			memset(rp->tx_buf[entry] + skb->len, 0,
+			       ETH_ZLEN - skb->len);
 		rp->tx_skbuff_dma[entry] = 0;
 		rp->tx_ring[entry].addr = cpu_to_le32(rp->tx_bufs_dma +
 						      (rp->tx_buf[entry] -

--

[PATCH 03/22] USB: ub oops in block_uevent

[Chris Wright]

[-- Attachment #1: usb-ub-oops-in-block_uevent.patch --]
[-- Type: text/plain, Size: 2110 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

In kernel 2.6.16, if a mounted storage device is removed, an oops happens
because ub supplies an interface device (and kobject) to the block layer,
but neglects to pin it. And apparently, the block layer expects its users
to pin device structures.

The code in ub was broken this way for years. But the bug was exposed only
by 2.6.16 when it started to call block_uevent on close, which traverses
device structures (kobjects actually).

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/block/ub.c |   18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

--- linux-2.6.16.16.orig/drivers/block/ub.c
+++ linux-2.6.16.16/drivers/block/ub.c
@@ -704,6 +704,9 @@ static void ub_cleanup(struct ub_dev *sc
 		kfree(lun);
 	}
 
+	usb_set_intfdata(sc->intf, NULL);
+	usb_put_intf(sc->intf);
+	usb_put_dev(sc->dev);
 	kfree(sc);
 }
 
@@ -2428,7 +2431,12 @@ static int ub_probe(struct usb_interface
 	// sc->ifnum = intf->cur_altsetting->desc.bInterfaceNumber;
 	usb_set_intfdata(intf, sc);
 	usb_get_dev(sc->dev);
-	// usb_get_intf(sc->intf);	/* Do we need this? */
+	/*
+	 * Since we give the interface struct to the block level through
+	 * disk->driverfs_dev, we have to pin it. Otherwise, block_uevent
+	 * oopses on close after a disconnect (kernels 2.6.16 and up).
+	 */
+	usb_get_intf(sc->intf);
 
 	snprintf(sc->name, 12, DRV_NAME "(%d.%d)",
 	    sc->dev->bus->busnum, sc->dev->devnum);
@@ -2509,7 +2517,7 @@ static int ub_probe(struct usb_interface
 err_diag:
 err_dev_desc:
 	usb_set_intfdata(intf, NULL);
-	// usb_put_intf(sc->intf);
+	usb_put_intf(sc->intf);
 	usb_put_dev(sc->dev);
 	kfree(sc);
 err_core:
@@ -2688,12 +2696,6 @@ static void ub_disconnect(struct usb_int
 	 */
 
 	device_remove_file(&sc->intf->dev, &dev_attr_diag);
-	usb_set_intfdata(intf, NULL);
-	// usb_put_intf(sc->intf);
-	sc->intf = NULL;
-	usb_put_dev(sc->dev);
-	sc->dev = NULL;
-
 	ub_put(sc);
 }
 

--

[PATCH 04/22] [PATCH] fs/locks.c: Fix sys_flock() race

[Chris Wright]

[-- Attachment #1: fs-locks.c-Fix-sys_flock-race.patch --]
[-- Type: text/plain, Size: 3154 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

sys_flock() currently has a race which can result in a double free in the
multi-thread case.

Thread 1			Thread 2

sys_flock(file, LOCK_EX)
				sys_flock(file, LOCK_UN)

If Thread 2 removes the lock from inode->i_lock before Thread 1 tests for
list_empty(&lock->fl_link) at the end of sys_flock, then both threads will
end up calling locks_free_lock for the same lock.

Fix is to make flock_lock_file() do the same as posix_lock_file(), namely
to make a copy of the request, so that the caller can always free the lock.

This also has the side-effect of fixing up a reference problem in the
lockd handling of flock.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 fs/locks.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

--- linux-2.6.16.16.orig/fs/locks.c
+++ linux-2.6.16.16/fs/locks.c
@@ -714,8 +714,9 @@ EXPORT_SYMBOL(posix_locks_deadlock);
  * at the head of the list, but that's secret knowledge known only to
  * flock_lock_file and posix_lock_file.
  */
-static int flock_lock_file(struct file *filp, struct file_lock *new_fl)
+static int flock_lock_file(struct file *filp, struct file_lock *request)
 {
+	struct file_lock *new_fl = NULL;
 	struct file_lock **before;
 	struct inode * inode = filp->f_dentry->d_inode;
 	int error = 0;
@@ -730,17 +731,19 @@ static int flock_lock_file(struct file *
 			continue;
 		if (filp != fl->fl_file)
 			continue;
-		if (new_fl->fl_type == fl->fl_type)
+		if (request->fl_type == fl->fl_type)
 			goto out;
 		found = 1;
 		locks_delete_lock(before);
 		break;
 	}
-	unlock_kernel();
 
-	if (new_fl->fl_type == F_UNLCK)
-		return 0;
+	if (request->fl_type == F_UNLCK)
+		goto out;
 
+	new_fl = locks_alloc_lock();
+	if (new_fl == NULL)
+		goto out;
 	/*
 	 * If a higher-priority process was blocked on the old file lock,
 	 * give it the opportunity to lock the file.
@@ -748,26 +751,27 @@ static int flock_lock_file(struct file *
 	if (found)
 		cond_resched();
 
-	lock_kernel();
 	for_each_lock(inode, before) {
 		struct file_lock *fl = *before;
 		if (IS_POSIX(fl))
 			break;
 		if (IS_LEASE(fl))
 			continue;
-		if (!flock_locks_conflict(new_fl, fl))
+		if (!flock_locks_conflict(request, fl))
 			continue;
 		error = -EAGAIN;
-		if (new_fl->fl_flags & FL_SLEEP) {
-			locks_insert_block(fl, new_fl);
-		}
+		if (request->fl_flags & FL_SLEEP)
+			locks_insert_block(fl, request);
 		goto out;
 	}
+	locks_copy_lock(new_fl, request);
 	locks_insert_lock(&inode->i_flock, new_fl);
-	error = 0;
+	new_fl = NULL;
 
 out:
 	unlock_kernel();
+	if (new_fl)
+		locks_free_lock(new_fl);
 	return error;
 }
 
@@ -1532,9 +1536,7 @@ asmlinkage long sys_flock(unsigned int f
 		error = flock_lock_file_wait(filp, lock);
 
  out_free:
-	if (list_empty(&lock->fl_link)) {
-		locks_free_lock(lock);
-	}
+	locks_free_lock(lock);
 
  out_putf:
 	fput(filp);

--

[PATCH 05/22] [PATCH] smbfs: Fix slab corruption in samba error path

[Chris Wright]

[-- Attachment #1: smbfs-fix-slab-corruption-in-samba-error-path.patch --]
[-- Type: text/plain, Size: 8252 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Yesterday, I got the following error with 2.6.16.13 during a file copy from
a smb filesystem over a wireless link.  I guess there was some error on the
wireless link, which in turn caused an error condition for the smb
filesystem.

In the log, smb_file_read reports error=4294966784 (0xfffffe00), which also
shows up in the slab dumps, and also is -ERESTARTSYS.  Error code 27499
corresponds to 0x6b6b, so the rq_errno field seems to be the only one being
set after freeing the slab.

In smb_add_request (which is the only place in smbfs where I found
ERESTARTSYS), I found the following:

        if (!timeleft || signal_pending(current)) {
                /*
                 * On timeout or on interrupt we want to try and remove the
                 * request from the recvq/xmitq.
                 */
                smb_lock_server(server);
                if (!(req->rq_flags & SMB_REQ_RECEIVED)) {
                        list_del_init(&req->rq_queue);
                        smb_rput(req);
                }
                smb_unlock_server(server);
        }
	[...]
        if (signal_pending(current))
                req->rq_errno = -ERESTARTSYS;

I guess that some codepath like smbiod_flush() caused the request to be
removed from the queue, and smb_rput(req) be called, without
SMB_REQ_RECEIVED being set.  This violates an asumption made by the quoted
code.

Then, the above code calls smb_rput(req) again, the req gets freed, and
req->rq_errno = -ERESTARTSYS writes into the already freed slab.  As
list_del_init doesn't cause an error if called multiple times, that does
cause the observed behaviour (freed slab with rq_errno=-ERESTARTSYS).

If this observation is correct, the following patch should fix it.

I wonder why the smb code uses list_del_init everywhere - using list_del
instead would catch such situations by poisoning the next and prev
pointers.

May  4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Firmware error detected.  Restarting.
May  4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Sysfs 'error' log captured.
May  4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Firmware error detected.  Restarting.
May  4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Sysfs 'error' log already exists.
May  4 23:33:02 knautsch kernel: [17180306.968000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:34:18 knautsch kernel: [17180383.256000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:34:18 knautsch kernel: [17180383.284000] SMB connection re-established (-5)
May  4 23:37:19 knautsch kernel: [17180563.956000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:40:09 knautsch kernel: [17180733.636000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:40:26 knautsch kernel: [17180750.700000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:02 knautsch kernel: [17180907.304000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:08 knautsch kernel: [17180912.324000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:34 knautsch kernel: [17180938.416000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:43:34 knautsch kernel: [17180938.416000] Slab corruption: start=c4ebe09c, len=244
May  4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.416000] 0f0: 00 fe ff ff
May  4 23:43:34 knautsch kernel: [17180938.416000] Next obj: start=c4ebe19c, len=244
May  4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.416000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.460000] SMB connection re-established (-5)
May  4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Firmware error detected.  Restarting.
May  4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Sysfs 'error' log already exists.
May  4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Firmware error detected.  Restarting.
May  4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Sysfs 'error' log already exists.
May  4 23:45:05 knautsch kernel: [17181029.868000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:45:36 knautsch kernel: [17181060.984000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:45:36 knautsch kernel: [17181060.984000] Slab corruption: start=c4ebe09c, len=244
May  4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181060.984000] 0f0: 00 fe ff ff
May  4 23:45:36 knautsch kernel: [17181060.984000] Next obj: start=c4ebe19c, len=244
May  4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181060.984000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181061.024000] SMB connection re-established (-5)
May  4 23:46:17 knautsch kernel: [17181102.132000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:47:46 knautsch kernel: [17181190.468000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:47:46 knautsch kernel: [17181190.468000] Slab corruption: start=c4ebe09c, len=244
May  4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.468000] 0f0: 00 fe ff ff
May  4 23:47:46 knautsch kernel: [17181190.468000] Next obj: start=c4ebe19c, len=244
May  4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.468000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.492000] SMB connection re-established (-5)
May  4 23:49:20 knautsch kernel: [17181284.828000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:49:39 knautsch kernel: [17181303.896000] smb_file_read: //some_file validation failed, error=4294966784

Signed-off-by: Jan Niehusmann <jan@gondor.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 fs/smbfs/request.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.16.16.orig/fs/smbfs/request.c
+++ linux-2.6.16.16/fs/smbfs/request.c
@@ -339,9 +339,11 @@ int smb_add_request(struct smb_request *
 		/*
 		 * On timeout or on interrupt we want to try and remove the
 		 * request from the recvq/xmitq.
+		 * First check if the request is still part of a queue. (May
+		 * have been removed by some error condition)
 		 */
 		smb_lock_server(server);
-		if (!(req->rq_flags & SMB_REQ_RECEIVED)) {
+		if (!list_empty(&req->rq_queue)) {
 			list_del_init(&req->rq_queue);
 			smb_rput(req);
 		}

--

[PATCH 06/22] [PATCH] fs/compat.c: fix if (a |= b ) typo

[Chris Wright]

[-- Attachment #1: fs-compat.c-fix-if-typo.patch --]
[-- Type: text/plain, Size: 843 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Mentioned by Mark Armbrust somewhere on Usenet.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 fs/compat.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.16.orig/fs/compat.c
+++ linux-2.6.16.16/fs/compat.c
@@ -1901,7 +1901,7 @@ asmlinkage long compat_sys_ppoll(struct 
 	}
 
 	if (sigmask) {
-		if (sigsetsize |= sizeof(compat_sigset_t))
+		if (sigsetsize != sizeof(compat_sigset_t))
 			return -EINVAL;
 		if (copy_from_user(&ss32, sigmask, sizeof(ss32)))
 			return -EFAULT;

--

[PATCH 07/22] [PATCH] smbus unhiding kills thermal management

[Chris Wright]

[-- Attachment #1: smbus-unhiding-kills-thermal-management.patch --]
[-- Type: text/plain, Size: 1933 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Do not enable the SMBus device on Asus boards if suspend is used.  We do
not reenable the device on resume, leading to all sorts of undesirable
effects, the worst being a total fan failure after resume on Samsung P35
laptop.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/pci/quirks.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- linux-2.6.16.16.orig/drivers/pci/quirks.c
+++ linux-2.6.16.16/drivers/pci/quirks.c
@@ -861,6 +861,7 @@ static void __init quirk_eisa_bridge(str
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82375,	quirk_eisa_bridge );
 
+#ifndef CONFIG_ACPI_SLEEP
 /*
  * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
  * is not activated. The myth is that Asus said that they do not want the
@@ -872,8 +873,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
  * bridge. Unfortunately, this device has no subvendor/subdevice ID. So it 
  * becomes necessary to do this tweak in two steps -- I've chosen the Host
  * bridge as trigger.
+ *
+ * Actually, leaving it unhidden and not redoing the quirk over suspend2ram
+ * will cause thermal management to break down, and causing machine to
+ * overheat.
  */
-static int __initdata asus_hides_smbus = 0;
+static int __initdata asus_hides_smbus;
 
 static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
 {
@@ -1008,6 +1013,8 @@ static void __init asus_hides_smbus_lpc_
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1,	asus_hides_smbus_lpc_ich6 );
 
+#endif
+
 /*
  * SiS 96x south bridge: BIOS typically hides SMBus device...
  */

--

Re: [PATCH 07/22] [PATCH] smbus unhiding kills thermal management

[Jean Delvare]

> -stable review patch.  If anyone has any objections, please let us know.
> ------------------
> 
> Do not enable the SMBus device on Asus boards if suspend is used.  We do
> not reenable the device on resume, leading to all sorts of undesirable
> effects, the worst being a total fan failure after resume on Samsung P35
> laptop.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

As the i2c and hwmon maintainer, I wish to thank Carl-Daniel for his
good work on this, and this patch is
Signed-off-by: Jean Delvare <khali@linux-fr.org>

Note that this patch should fix bug #6449.

> ---
> 
>  drivers/pci/quirks.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.16.16.orig/drivers/pci/quirks.c
> +++ linux-2.6.16.16/drivers/pci/quirks.c
> @@ -861,6 +861,7 @@ static void __init quirk_eisa_bridge(str
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82375,	quirk_eisa_bridge );
>  
> +#ifndef CONFIG_ACPI_SLEEP
>  /*
>   * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
>   * is not activated. The myth is that Asus said that they do not want the
> @@ -872,8 +873,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
>   * bridge. Unfortunately, this device has no subvendor/subdevice ID. So it 
>   * becomes necessary to do this tweak in two steps -- I've chosen the Host
>   * bridge as trigger.
> + *
> + * Actually, leaving it unhidden and not redoing the quirk over suspend2ram
> + * will cause thermal management to break down, and causing machine to
> + * overheat.
>   */
> -static int __initdata asus_hides_smbus = 0;
> +static int __initdata asus_hides_smbus;
>  
>  static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
>  {
> @@ -1008,6 +1013,8 @@ static void __init asus_hides_smbus_lpc_
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1,	asus_hides_smbus_lpc_ich6 );
>  
> +#endif
> +
>  /*
>   * SiS 96x south bridge: BIOS typically hides SMBus device...
>   */

-- 
Jean Delvare

Re: [stable] Re: [PATCH 07/22] [PATCH] smbus unhiding kills thermal management

[Greg KH]

On Thu, May 18, 2006 at 10:53:10PM +0200, Jean Delvare wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> > ------------------
> > 
> > Do not enable the SMBus device on Asus boards if suspend is used.  We do
> > not reenable the device on resume, leading to all sorts of undesirable
> > effects, the worst being a total fan failure after resume on Samsung P35
> > laptop.
> > 
> > Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
> > Signed-off-by: Pavel Machek <pavel@suse.cz>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> As the i2c and hwmon maintainer, I wish to thank Carl-Daniel for his
> good work on this, and this patch is
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> 
> Note that this patch should fix bug #6449.

Thanks, I've added this info to the patch and will show up in the final
changelog.

greg k-h

[PATCH 08/22] [PATCH] scx200_acb: Fix resource name use after free

[Chris Wright]

[-- Attachment #1: scx200_acb-fix-resource-name-use-after-free.patch --]
[-- Type: text/plain, Size: 1365 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

We can't pass a string on the stack to request_region. As soon as we
leave the function that stack is gone and the string is lost. Let's
use the same string we identify the i2c_adapter with instead, it's
more simple, more consistent, and just works.

This is the second half of fix to bug #6445.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/i2c/busses/scx200_acb.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- linux-2.6.16.16.orig/drivers/i2c/busses/scx200_acb.c
+++ linux-2.6.16.16/drivers/i2c/busses/scx200_acb.c
@@ -440,7 +440,6 @@ static int  __init scx200_acb_create(int
 	struct scx200_acb_iface *iface;
 	struct i2c_adapter *adapter;
 	int rc = 0;
-	char description[64];
 
 	iface = kzalloc(sizeof(*iface), GFP_KERNEL);
 	if (!iface) {
@@ -459,8 +458,7 @@ static int  __init scx200_acb_create(int
 
 	init_MUTEX(&iface->sem);
 
-	snprintf(description, sizeof(description), "NatSemi SCx200 ACCESS.bus [%s]", adapter->name);
-	if (request_region(base, 8, description) == 0) {
+	if (!request_region(base, 8, adapter->name)) {
 		dev_err(&adapter->dev, "can't allocate io 0x%x-0x%x\n",
 			base, base + 8-1);
 		rc = -EBUSY;

--

[PATCH 09/22] [PATCH] Netfilter: do_add_counters race, possible oops or info leak (CVE-2006-0039)

[Chris Wright]

[-- Attachment #1: netfilter-do_add_counters-race-possible-info-leak.patch --]
[-- Type: text/plain, Size: 2396 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Solar Designer found a race condition in do_add_counters(). The beginning
of paddc is supposed to be the same as tmp which was sanity-checked
above, but it might not be the same in reality. In case the integer
overflow and/or the race condition are triggered, paddc->num_counters
might not match the allocation size for paddc. If the check below
(t->private->number != paddc->num_counters) nevertheless passes (perhaps
this requires the race condition to be triggered), IPT_ENTRY_ITERATE()
would read kernel memory beyond the allocation size, potentially causing
an oops or leaking sensitive data (e.g., passwords from host system or
from another VPS) via counter increments.  This requires CAP_NET_ADMIN.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191698

Cc: Solar Designer <solar@openwall.com>
Cc: Kirill Korotaev <dev@sw.ru>
Cc: Patrick McHardy <kaber@trash.net>
(chrisw: rebase of Solar's patch to 2.6.16.16)
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 net/ipv4/netfilter/arp_tables.c |    2 +-
 net/ipv4/netfilter/ip_tables.c  |    2 +-
 net/ipv6/netfilter/ip6_tables.c |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.16.16.orig/net/ipv4/netfilter/arp_tables.c
+++ linux-2.6.16.16/net/ipv4/netfilter/arp_tables.c
@@ -941,7 +941,7 @@ static int do_add_counters(void __user *
 
 	write_lock_bh(&t->lock);
 	private = t->private;
-	if (private->number != paddc->num_counters) {
+	if (private->number != tmp.num_counters) {
 		ret = -EINVAL;
 		goto unlock_up_free;
 	}
--- linux-2.6.16.16.orig/net/ipv4/netfilter/ip_tables.c
+++ linux-2.6.16.16/net/ipv4/netfilter/ip_tables.c
@@ -1063,7 +1063,7 @@ do_add_counters(void __user *user, unsig
 
 	write_lock_bh(&t->lock);
 	private = t->private;
-	if (private->number != paddc->num_counters) {
+	if (private->number != tmp.num_counters) {
 		ret = -EINVAL;
 		goto unlock_up_free;
 	}
--- linux-2.6.16.16.orig/net/ipv6/netfilter/ip6_tables.c
+++ linux-2.6.16.16/net/ipv6/netfilter/ip6_tables.c
@@ -1120,7 +1120,7 @@ do_add_counters(void __user *user, unsig
 
 	write_lock_bh(&t->lock);
 	private = t->private;
-	if (private->number != paddc->num_counters) {
+	if (private->number != tmp.num_counters) {
 		ret = -EINVAL;
 		goto unlock_up_free;
 	}

--

[PATCH 10/22] [PATCH] TG3: ethtool always report port is TP.

[Chris Wright]

[-- Attachment #1: tg3-ethtool-always-report-port-is-tp.patch --]
[-- Type: text/plain, Size: 1422 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.

Signed-off-by: Karsten Keil <kkeil@suse.de>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/net/tg3.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- linux-2.6.16.16.orig/drivers/net/tg3.c
+++ linux-2.6.16.16/drivers/net/tg3.c
@@ -7368,21 +7368,23 @@ static int tg3_get_settings(struct net_d
 		cmd->supported |= (SUPPORTED_1000baseT_Half |
 				   SUPPORTED_1000baseT_Full);
 
-	if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
+	if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES)) {
 		cmd->supported |= (SUPPORTED_100baseT_Half |
 				  SUPPORTED_100baseT_Full |
 				  SUPPORTED_10baseT_Half |
 				  SUPPORTED_10baseT_Full |
 				  SUPPORTED_MII);
-	else
+		cmd->port = PORT_TP;
+	} else {
 		cmd->supported |= SUPPORTED_FIBRE;
+		cmd->port = PORT_FIBRE;
+	}
   
 	cmd->advertising = tp->link_config.advertising;
 	if (netif_running(dev)) {
 		cmd->speed = tp->link_config.active_speed;
 		cmd->duplex = tp->link_config.active_duplex;
 	}
-	cmd->port = 0;
 	cmd->phy_address = PHY_ADDR;
 	cmd->transceiver = 0;
 	cmd->autoneg = tp->link_config.autoneg;

--

[PATCH 11/22] [PATCH] selinux: check for failed kmalloc in security_sid_to_context()

[Chris Wright]

[-- Attachment #1: selinux-check-for-failed-kmalloc-in-security_sid_to_context.patch --]
[-- Type: text/plain, Size: 1006 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Check for NULL kmalloc return value before writing to it.

Signed-off-by: "Serge E. Hallyn" <serue@us.ibm.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 security/selinux/ss/services.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-2.6.16.16.orig/security/selinux/ss/services.c
+++ linux-2.6.16.16/security/selinux/ss/services.c
@@ -592,6 +592,10 @@ int security_sid_to_context(u32 sid, cha
 
 			*scontext_len = strlen(initial_sid_to_string[sid]) + 1;
 			scontextp = kmalloc(*scontext_len,GFP_ATOMIC);
+			if (!scontextp) {
+				rc = -ENOMEM;
+				goto out;
+			}
 			strcpy(scontextp, initial_sid_to_string[sid]);
 			*scontext = scontextp;
 			goto out;

--

[PATCH 12/22] PCI: correctly allocate return buffers for osc calls

[Chris Wright]

[-- Attachment #1: pci-correctly-allocate-return-buffers-for-osc-calls.patch --]
[-- Type: text/plain, Size: 4281 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

The OSC set and query functions do not allocate enough space for return values,
and set the output buffer length to a false, too large value.  This causes the 
acpi-ca code to assume that the output buffer is larger than it actually is, 
and overwrite memory when copying acpi return buffers into this caller provided
buffer.  In some cases this can cause kernel oops if the memory that is 
overwritten is a pointer.  This patch will change these calls to use a 
dynamically allocated output buffer, thus allowing the acpi-ca code to decide 
how much space is needed.

Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/pci/pci-acpi.c |   60 ++++++++++++++++++++++++++++---------------------
 1 file changed, 35 insertions(+), 25 deletions(-)

--- linux-2.6.16.16.orig/drivers/pci/pci-acpi.c
+++ linux-2.6.16.16/drivers/pci/pci-acpi.c
@@ -33,13 +33,10 @@ acpi_query_osc (
 	acpi_status		status;
 	struct acpi_object_list	input;
 	union acpi_object 	in_params[4];
-	struct acpi_buffer	output;
-	union acpi_object 	out_obj;	
+	struct acpi_buffer	output = {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object 	*out_obj;
 	u32			osc_dw0;
 
-	/* Setting up output buffer */
-	output.length = sizeof(out_obj) + 3*sizeof(u32);  
-	output.pointer = &out_obj;
 	
 	/* Setting up input parameters */
 	input.count = 4;
@@ -61,12 +58,15 @@ acpi_query_osc (
 			"Evaluate _OSC Set fails. Status = 0x%04x\n", status);
 		return status;
 	}
-	if (out_obj.type != ACPI_TYPE_BUFFER) {
+	out_obj = output.pointer;
+
+	if (out_obj->type != ACPI_TYPE_BUFFER) {
 		printk(KERN_DEBUG  
 			"Evaluate _OSC returns wrong type\n");
-		return AE_TYPE;
+		status = AE_TYPE;
+		goto query_osc_out;
 	}
-	osc_dw0 = *((u32 *) out_obj.buffer.pointer);
+	osc_dw0 = *((u32 *) out_obj->buffer.pointer);
 	if (osc_dw0) {
 		if (osc_dw0 & OSC_REQUEST_ERROR)
 			printk(KERN_DEBUG "_OSC request fails\n"); 
@@ -76,15 +76,21 @@ acpi_query_osc (
 			printk(KERN_DEBUG "_OSC invalid revision\n"); 
 		if (osc_dw0 & OSC_CAPABILITIES_MASK_ERROR) {
 			/* Update Global Control Set */
-			global_ctrlsets = *((u32 *)(out_obj.buffer.pointer+8));
-			return AE_OK;
+			global_ctrlsets = *((u32 *)(out_obj->buffer.pointer+8));
+			status = AE_OK;
+			goto query_osc_out;
 		}
-		return AE_ERROR;
+		status = AE_ERROR;
+		goto query_osc_out;
 	}
 
 	/* Update Global Control Set */
-	global_ctrlsets = *((u32 *)(out_obj.buffer.pointer + 8));
-	return AE_OK;
+	global_ctrlsets = *((u32 *)(out_obj->buffer.pointer + 8));
+	status = AE_OK;
+
+query_osc_out:
+	kfree(output.pointer);
+	return status;
 }
 
 
@@ -96,14 +102,10 @@ acpi_run_osc (
 	acpi_status		status;
 	struct acpi_object_list	input;
 	union acpi_object 	in_params[4];
-	struct acpi_buffer	output;
-	union acpi_object 	out_obj;	
+	struct acpi_buffer	output = {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object 	*out_obj;
 	u32			osc_dw0;
 
-	/* Setting up output buffer */
-	output.length = sizeof(out_obj) + 3*sizeof(u32);  
-	output.pointer = &out_obj;
-	
 	/* Setting up input parameters */
 	input.count = 4;
 	input.pointer = in_params;
@@ -124,12 +126,14 @@ acpi_run_osc (
 			"Evaluate _OSC Set fails. Status = 0x%04x\n", status);
 		return status;
 	}
-	if (out_obj.type != ACPI_TYPE_BUFFER) {
+	out_obj = output.pointer;
+	if (out_obj->type != ACPI_TYPE_BUFFER) {
 		printk(KERN_DEBUG  
 			"Evaluate _OSC returns wrong type\n");
-		return AE_TYPE;
+		status = AE_TYPE;
+		goto run_osc_out;
 	}
-	osc_dw0 = *((u32 *) out_obj.buffer.pointer);
+	osc_dw0 = *((u32 *) out_obj->buffer.pointer);
 	if (osc_dw0) {
 		if (osc_dw0 & OSC_REQUEST_ERROR)
 			printk(KERN_DEBUG "_OSC request fails\n"); 
@@ -139,11 +143,17 @@ acpi_run_osc (
 			printk(KERN_DEBUG "_OSC invalid revision\n"); 
 		if (osc_dw0 & OSC_CAPABILITIES_MASK_ERROR) {
 			printk(KERN_DEBUG "_OSC FW not grant req. control\n");
-			return AE_SUPPORT;
+			status = AE_SUPPORT;
+			goto run_osc_out;
 		}
-		return AE_ERROR;
+		status = AE_ERROR;
+		goto run_osc_out;
 	}
-	return AE_OK;
+	status = AE_OK;
+
+run_osc_out:
+	kfree(output.pointer);
+	return status;
 }
 
 /**

--

[PATCH 13/22] [PATCH] [BLOCK] limit request_fn recursion

[Chris Wright]

[-- Attachment #1: BLOCK-limit-request_fn-recursion.patch --]
[-- Type: text/plain, Size: 2482 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Don't recurse back into the driver even if the unplug threshold is met,
when the driver asks for a requeue. This is both silly from a logical
point of view (requeues typically happen due to driver/hardware
shortage), and also dangerous since we could hit an endless request_fn
-> requeue -> unplug -> request_fn loop and crash on stack overrun.

Also limit blk_run_queue() to one level of recursion, similar to how
blk_start_queue() works.

This patch fixed a real problem with SLES10 and lpfc, and it could hit
any SCSI lld that returns non-zero from it's ->queuecommand() handler.

Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 block/elevator.c  |    8 +++++++-
 block/ll_rw_blk.c |   17 +++++++++++++++--
 2 files changed, 22 insertions(+), 3 deletions(-)

--- linux-2.6.16.16.orig/block/elevator.c
+++ linux-2.6.16.16/block/elevator.c
@@ -314,6 +314,7 @@ void elv_insert(request_queue_t *q, stru
 {
 	struct list_head *pos;
 	unsigned ordseq;
+	int unplug_it = 1;
 
 	rq->q = q;
 
@@ -378,6 +379,11 @@ void elv_insert(request_queue_t *q, stru
 		}
 
 		list_add_tail(&rq->queuelist, pos);
+		/*
+		 * most requeues happen because of a busy condition, don't
+		 * force unplug of the queue for that case.
+		 */
+		unplug_it = 0;
 		break;
 
 	default:
@@ -386,7 +392,7 @@ void elv_insert(request_queue_t *q, stru
 		BUG();
 	}
 
-	if (blk_queue_plugged(q)) {
+	if (unplug_it && blk_queue_plugged(q)) {
 		int nrq = q->rq.count[READ] + q->rq.count[WRITE]
 			- q->in_flight;
 
--- linux-2.6.16.16.orig/block/ll_rw_blk.c
+++ linux-2.6.16.16/block/ll_rw_blk.c
@@ -1719,8 +1719,21 @@ void blk_run_queue(struct request_queue 
 
 	spin_lock_irqsave(q->queue_lock, flags);
 	blk_remove_plug(q);
-	if (!elv_queue_empty(q))
-		q->request_fn(q);
+
+	/*
+	 * Only recurse once to avoid overrunning the stack, let the unplug
+	 * handling reinvoke the handler shortly if we already got there.
+	 */
+	if (!elv_queue_empty(q)) {
+		if (!test_and_set_bit(QUEUE_FLAG_REENTER, &q->queue_flags)) {
+			q->request_fn(q);
+			clear_bit(QUEUE_FLAG_REENTER, &q->queue_flags);
+		} else {
+			blk_plug_device(q);
+			kblockd_schedule_work(&q->unplug_work);
+		}
+	}
+
 	spin_unlock_irqrestore(q->queue_lock, flags);
 }
 EXPORT_SYMBOL(blk_run_queue);

--

[PATCH 14/22] [PATCH] [Cardman 40x0] Fix udev device creation

[Chris Wright]

[-- Attachment #1: Cardman-40x0-Fix-udev-device-creation.patch --]
[-- Type: text/plain, Size: 1902 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

This patch corrects the order of the calls to register_chrdev() and
pcmcia_register_driver().  Now udev correctly creates userspace device
files /dev/cmmN and /dev/cmxN respectively.

Based on an earlier patch by Jan Niehusmann <jan@gondor.com>.

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/char/pcmcia/cm4000_cs.c |   10 ++++++----
 drivers/char/pcmcia/cm4040_cs.c |   11 +++++++----
 2 files changed, 13 insertions(+), 8 deletions(-)

--- linux-2.6.16.16.orig/drivers/char/pcmcia/cm4000_cs.c
+++ linux-2.6.16.16/drivers/char/pcmcia/cm4000_cs.c
@@ -2010,10 +2010,6 @@ static int __init cmm_init(void)
 	if (!cmm_class)
 		return -1;
 
-	rc = pcmcia_register_driver(&cm4000_driver);
-	if (rc < 0)
-		return rc;
-
 	major = register_chrdev(0, DEVICE_NAME, &cm4000_fops);
 	if (major < 0) {
 		printk(KERN_WARNING MODULE_NAME
@@ -2021,6 +2017,12 @@ static int __init cmm_init(void)
 		return -1;
 	}
 
+	rc = pcmcia_register_driver(&cm4000_driver);
+	if (rc < 0) {
+		unregister_chrdev(major, DEVICE_NAME);
+		return rc;
+	}
+
 	return 0;
 }
 
--- linux-2.6.16.16.orig/drivers/char/pcmcia/cm4040_cs.c
+++ linux-2.6.16.16/drivers/char/pcmcia/cm4040_cs.c
@@ -769,16 +769,19 @@ static int __init cm4040_init(void)
 	if (!cmx_class)
 		return -1;
 
-	rc = pcmcia_register_driver(&reader_driver);
-	if (rc < 0)
-		return rc;
-
 	major = register_chrdev(0, DEVICE_NAME, &reader_fops);
 	if (major < 0) {
 		printk(KERN_WARNING MODULE_NAME
 			": could not get major number\n");
 		return -1;
 	}
+
+	rc = pcmcia_register_driver(&reader_driver);
+	if (rc < 0) {
+		unregister_chrdev(major, DEVICE_NAME);
+		return rc;
+	}
+
 	return 0;
 }
 

--

Re: [PATCH 14/22] [PATCH] [Cardman 40x0] Fix udev device creation

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Wed, May 17, 2006 at 12:00:14AM -0700, Chris Wright wrote:
> -stable review patch.  If anyone has any objections, please let us know.

that patch is perfetly fine, and I support it going into -stable.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[PATCH 15/22] [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges

[Chris Wright]

[-- Attachment #1: PCI-quirk-VIA-IRQ-fixup-should-only-run-for-VIA-southbridges.patch --]
[-- Type: text/plain, Size: 1600 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
on my system which has no VIA southbridge (but I do have a VIA IEEE
1394 device).

This should address that.  I also changed "Via IRQ" to "VIA IRQ"
(initially I read Via as a capitalized via (by way/means of).

Signed-off-by: Chris Wedgwood <cw@f00f.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/pci/quirks.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- linux-2.6.16.16.orig/drivers/pci/quirks.c
+++ linux-2.6.16.16/drivers/pci/quirks.c
@@ -639,13 +639,15 @@ static void quirk_via_irq(struct pci_dev
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
-		printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+		printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
 			pci_name(dev), irq, new_irq);
 		udelay(15);	/* unknown if delay really needed */
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

--

[PATCH 16/22] [PATCH] VIA quirk fixup, additional PCI IDs

[Chris Wright]

[-- Attachment #1: PCI-VIA-quirk-fixup-additional-PCI-IDs.patch --]
[-- Type: text/plain, Size: 2083 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list.  Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.

This should I hope correct this.

Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.

Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/pci/quirks.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- linux-2.6.16.16.orig/drivers/pci/quirks.c
+++ linux-2.6.16.16/drivers/pci/quirks.c
@@ -631,6 +631,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
  * non-x86 architectures (yes Via exists on PPC among other places),
  * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
  * interrupts delivered properly.
+ *
+ * Some of the on-chip devices are actually '586 devices' so they are
+ * listed here.
  */
 static void quirk_via_irq(struct pci_dev *dev)
 {
@@ -645,6 +648,10 @@ static void quirk_via_irq(struct pci_dev
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);

--

[PATCH 17/22] [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300

[Chris Wright]

[-- Attachment #1: i386-x86_64-Force-pci-noacpi-on-HP-XW9300.patch --]
[-- Type: text/plain, Size: 1048 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

This is needed to see all devices.

The system has multiple PCI segments and we don't handle that properly
yet in PCI and ACPI. Short term before this is fixed blacklist it to
pci=noacpi.

Acked-by: len.brown@intel.com
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/i386/kernel/acpi/boot.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- linux-2.6.16.16.orig/arch/i386/kernel/acpi/boot.c
+++ linux-2.6.16.16/arch/i386/kernel/acpi/boot.c
@@ -1060,6 +1060,14 @@ static struct dmi_system_id __initdata a
 		     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
 		     },
 	 },
+	{
+	 .callback = disable_acpi_pci,
+	 .ident = "HP xw9300",
+	 .matches = {
+		    DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		    DMI_MATCH(DMI_PRODUCT_NAME, "HP xw9300 Workstation"),
+		    },
+	},
 	{}
 };
 

--

Re: [PATCH 17/22] [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300

[Andi Kleen]

On Wednesday 17 May 2006 09:00, Chris Wright wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> ------------------

Who submitted that? I didn't

There seems to be some controversy about this patch so better not put 
it into stable for now.

-Andi

> 
> This is needed to see all devices.
> 
> The system has multiple PCI segments and we don't handle that properly
> yet in PCI and ACPI. Short term before this is fixed blacklist it to
> pci=noacpi.
>

Re: [PATCH 17/22] [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300

[Greg KH]

On Thu, May 18, 2006 at 12:16:04AM +0200, Andi Kleen wrote:
> On Wednesday 17 May 2006 09:00, Chris Wright wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> > ------------------
> 
> Who submitted that? I didn't

I did.

> There seems to be some controversy about this patch so better not put 
> it into stable for now.

Ok, that's fine, I'll go drop it, I thought it fixed some machines so I
added it.

thanks,

greg k-h

Re: [PATCH 17/22] [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300

[Chris Wright]

* Andi Kleen (ak@suse.de) wrote:
> On Wednesday 17 May 2006 09:00, Chris Wright wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> > ------------------
> 
> Who submitted that? I didn't
> 
> There seems to be some controversy about this patch so better not put 
> it into stable for now.

Came from Greg.  Dropped.

thanks,
-chris

[PATCH 18/22] [PATCH] Remove cond_resched in gather_stats()

[Chris Wright]

[-- Attachment #1: remove-cond_resched-in-gather_stats.patch --]
[-- Type: text/plain, Size: 718 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

gather_stats() is called with a spinlock held from check_pte_range.  We
cannot reschedule with a lock held.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
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>

---
 mm/mempolicy.c |    1 -
 1 file changed, 1 deletion(-)

--- linux-2.6.16.16.orig/mm/mempolicy.c
+++ linux-2.6.16.16/mm/mempolicy.c
@@ -1796,7 +1796,6 @@ static void gather_stats(struct page *pa
 		md->mapcount_max = count;
 
 	md->node[page_to_nid(page)]++;
-	cond_resched();
 }
 
 #ifdef CONFIG_HUGETLB_PAGE

--

[PATCH 19/22] [PATCH] add migratepage address space op to shmem

[Chris Wright]

[-- Attachment #1: add-migratepage-address-space-op-to-shmem.patch --]
[-- Type: text/plain, Size: 1947 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Basic problem: pages of a shared memory segment can only be migrated once.

In 2.6.16 through 2.6.17-rc1, shared memory mappings do not have a
migratepage address space op.  Therefore, migrate_pages() falls back to
default processing.  In this path, it will try to pageout() dirty pages.
Once a shared memory page has been migrated it becomes dirty, so
migrate_pages() will try to page it out.  However, because the page count
is 3 [cache + current + pte], pageout() will return PAGE_KEEP because
is_page_cache_freeable() returns false.  This will abort all subsequent
migrations.

This patch adds a migratepage address space op to shared memory segments to
avoid taking the default path.  We use the "migrate_page()" function
because it knows how to migrate dirty pages.  This allows shared memory
segment pages to migrate, subject to other conditions such as # pte's
referencing the page [page_mapcount(page)], when requested.

I think this is safe.  If we're migrating a shared memory page, then we
found the page via a page table, so it must be in memory.

Can be verified with memtoy and the shmem-mbind-test script, both
available at:  http://free.linux.hp.com/~lts/Tools/

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 mm/shmem.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.16.orig/mm/shmem.c
+++ linux-2.6.16.16/mm/shmem.c
@@ -2172,6 +2172,7 @@ static struct address_space_operations s
 	.prepare_write	= shmem_prepare_write,
 	.commit_write	= simple_commit_write,
 #endif
+	.migratepage	= migrate_page,
 };
 
 static struct file_operations shmem_file_operations = {

--

[PATCH 20/22] [PATCH] page migration: Fix fallback behavior for dirty pages

[Chris Wright]

[-- Attachment #1: page-migration-Fix-fallback-behavior-for-dirty-pages.patch --]
[-- Type: text/plain, Size: 1885 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Currently we check PageDirty() in order to make the decision to swap out
the page.  However, the dirty information may be only be contained in the
ptes pointing to the page.  We need to first unmap the ptes before checking
for PageDirty().  If unmap is successful then the page count of the page
will also be decreased so that pageout() works properly.

This is a fix necessary for 2.6.17.  Without this fix we may migrate dirty
pages for filesystems without migration functions.  Filesystems may keep
pointers to dirty pages.  Migration of dirty pages can result in the
filesystem keeping pointers to freed pages.

Unmapping is currently not be separated out from removing all the
references to a page and moving the mapping.  Therefore try_to_unmap will
be called again in migrate_page() if the writeout is successful.  However,
it wont do anything since the ptes are already removed.

The coming updates to the page migration code will restructure the code
so that this is no longer necessary.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 mm/vmscan.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- linux-2.6.16.16.orig/mm/vmscan.c
+++ linux-2.6.16.16/mm/vmscan.c
@@ -949,6 +949,17 @@ redo:
 			goto unlock_both;
                 }
 
+		/* Make sure the dirty bit is up to date */
+		if (try_to_unmap(page, 1) == SWAP_FAIL) {
+			rc = -EPERM;
+			goto unlock_both;
+		}
+
+		if (page_mapcount(page)) {
+			rc = -EAGAIN;
+			goto unlock_both;
+		}
+
 		/*
 		 * Default handling if a filesystem does not provide
 		 * a migration function. We can only migrate clean

--

[PATCH 21/22] [PATCH] Fix ptrace_attach()/ptrace_traceme()/de_thread() race

[Chris Wright]

[-- Attachment #1: fix-ptrace_attach-ptrace_traceme-de_thread-race.patch --]
[-- Type: text/plain, Size: 2292 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

This holds the task lock (and, for ptrace_attach, the tasklist_lock)
over the actual attach event, which closes a race between attacking to a
thread that is either doing a PTRACE_TRACEME or getting de-threaded.

Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
for noticing a lost return value in my first version.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 kernel/ptrace.c |   39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

--- linux-2.6.16.16.orig/kernel/ptrace.c
+++ linux-2.6.16.16/kernel/ptrace.c
@@ -149,12 +149,16 @@ int ptrace_may_attach(struct task_struct
 int ptrace_attach(struct task_struct *task)
 {
 	int retval;
-	task_lock(task);
+
 	retval = -EPERM;
 	if (task->pid <= 1)
-		goto bad;
+		goto out;
 	if (task->tgid == current->tgid)
-		goto bad;
+		goto out;
+
+	write_lock_irq(&tasklist_lock);
+	task_lock(task);
+
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)
 		goto bad;
@@ -167,17 +171,15 @@ int ptrace_attach(struct task_struct *ta
 				      ? PT_ATTACHED : 0);
 	if (capable(CAP_SYS_PTRACE))
 		task->ptrace |= PT_PTRACE_CAP;
-	task_unlock(task);
 
-	write_lock_irq(&tasklist_lock);
 	__ptrace_link(task, current);
-	write_unlock_irq(&tasklist_lock);
 
 	force_sig_specific(SIGSTOP, task);
-	return 0;
 
 bad:
+	write_unlock_irq(&tasklist_lock);
 	task_unlock(task);
+out:
 	return retval;
 }
 
@@ -418,21 +420,22 @@ int ptrace_request(struct task_struct *c
  */
 int ptrace_traceme(void)
 {
-	int ret;
+	int ret = -EPERM;
 
 	/*
 	 * Are we already being traced?
 	 */
-	if (current->ptrace & PT_PTRACED)
-		return -EPERM;
-	ret = security_ptrace(current->parent, current);
-	if (ret)
-		return -EPERM;
-	/*
-	 * Set the ptrace bit in the process ptrace flags.
-	 */
-	current->ptrace |= PT_PTRACED;
-	return 0;
+	task_lock(current);
+	if (!(current->ptrace & PT_PTRACED)) {
+		ret = security_ptrace(current->parent, current);
+		/*
+		 * Set the ptrace bit in the process ptrace flags.
+		 */
+		if (!ret)
+			current->ptrace |= PT_PTRACED;
+	}
+	task_unlock(current);
+	return ret;
 }
 
 /**

--

[PATCH 22/22] [PATCH] ptrace_attach: fix possible deadlock schenario with irqs

[Chris Wright]

[-- Attachment #1: ptrace_attach-fix-possible-deadlock-schenario-with-irqs.patch --]
[-- Type: text/plain, Size: 1748 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

Eric Biederman points out that we can't take the task_lock while holding
tasklist_lock for writing, because another CPU that holds the task lock
might take an interrupt that then tries to take tasklist_lock for writing.

Which would be a nasty deadlock, with one CPU spinning forever in an
interrupt handler (although admittedly you need to really work at
triggering it ;)

Since the ptrace_attach() code is special and very unusual, just make it
be extra careful, and use trylock+repeat to avoid the possible deadlock.

Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 kernel/ptrace.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

--- linux-2.6.16.16.orig/kernel/ptrace.c
+++ linux-2.6.16.16/kernel/ptrace.c
@@ -156,8 +156,26 @@ int ptrace_attach(struct task_struct *ta
 	if (task->tgid == current->tgid)
 		goto out;
 
-	write_lock_irq(&tasklist_lock);
+repeat:
+	/*
+	 * Nasty, nasty.
+	 *
+	 * We want to hold both the task-lock and the
+	 * tasklist_lock for writing at the same time.
+	 * But that's against the rules (tasklist_lock
+	 * is taken for reading by interrupts on other
+	 * cpu's that may have task_lock).
+	 */
 	task_lock(task);
+	local_irq_disable();
+	if (!write_trylock(&tasklist_lock)) {
+		local_irq_enable();
+		task_unlock(task);
+		do {
+			cpu_relax();
+		} while (!write_can_lock(&tasklist_lock));
+		goto repeat;
+	}
 
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)

--

Re: [PATCH 00/22] -stable review

[Linus Torvalds]

On Wed, 17 May 2006, Chris Wright wrote:
>
> This is the start of the stable review cycle for the 2.6.16.17 release.
> There are 22 patches in this series, all will be posted as a response to
> this one.

I notice that none of the patches have authorship information.

Has that always been true and I just never noticed before?

Could you make your review script add the proper "From:" to the top of the 
body of the email so that that is visible during review too?

		Linus

Re: [PATCH 00/22] -stable review

[Chris Wright]

* Linus Torvalds (torvalds@osdl.org) wrote:
> 
> 
> On Wed, 17 May 2006, Chris Wright wrote:
> >
> > This is the start of the stable review cycle for the 2.6.16.17 release.
> > There are 22 patches in this series, all will be posted as a response to
> > this one.
> 
> I notice that none of the patches have authorship information.
> 
> Has that always been true and I just never noticed before?

It has always been that way with my script, I think Greg's as well.  Of
course, it's in the patch, and goes into git with proper authorship.

> Could you make your review script add the proper "From:" to the top of the 
> body of the email so that that is visible during review too?

Sure, that should be doable...SMOS (small matter of scripting ;-)

thanks,
-chris

Re: [stable] Re: [PATCH 00/22] -stable review

[Greg KH]

On Wed, May 17, 2006 at 03:36:01PM -0700, Chris Wright wrote:
> * Linus Torvalds (torvalds@osdl.org) wrote:
> > 
> > 
> > On Wed, 17 May 2006, Chris Wright wrote:
> > >
> > > This is the start of the stable review cycle for the 2.6.16.17 release.
> > > There are 22 patches in this series, all will be posted as a response to
> > > this one.
> > 
> > I notice that none of the patches have authorship information.
> > 
> > Has that always been true and I just never noticed before?
> 
> It has always been that way with my script, I think Greg's as well.  Of
> course, it's in the patch, and goes into git with proper authorship.

The original versions of the patches do have the proper authorship
information, it's just that quilt strips it off when generating emails
like this.

When applying them to the git tree, everything comes out properly and
they get the correct authorship information.  And the git tools know to
properly create the emails with the right From: lines, maybe I should
play around with quilt to add that to it too...

thanks,

greg k-h

Re: [stable] Re: [PATCH 00/22] -stable review

[Michael Tokarev]

Greg KH wrote:
> On Wed, May 17, 2006 at 03:36:01PM -0700, Chris Wright wrote:
>> * Linus Torvalds (torvalds@osdl.org) wrote:
>>>
>>> On Wed, 17 May 2006, Chris Wright wrote:
>>>> This is the start of the stable review cycle for the 2.6.16.17 release.
>>>> There are 22 patches in this series, all will be posted as a response to
>>>> this one.
>>> I notice that none of the patches have authorship information.
>>>
>>> Has that always been true and I just never noticed before?
>> It has always been that way with my script, I think Greg's as well.  Of
>> course, it's in the patch, and goes into git with proper authorship.
> 
> The original versions of the patches do have the proper authorship
> information, it's just that quilt strips it off when generating emails
> like this.
> 
> When applying them to the git tree, everything comes out properly and
> they get the correct authorship information.  And the git tools know to
> properly create the emails with the right From: lines, maybe I should
> play around with quilt to add that to it too...

While we're on it.. Just another small nitpick.  Random patch from this 00/22
series:

 Subject: [PATCH 05/22] [PATCH] smbfs: Fix slab corruption in samba error path

Can the 2nd "[PATCH]" tag be removed as well? ;)

/mjt

Re: [stable] Re: [PATCH 00/22] -stable review

[Greg KH]

On Thu, May 18, 2006 at 01:15:40PM +0400, Michael Tokarev wrote:
> Greg KH wrote:
> > On Wed, May 17, 2006 at 03:36:01PM -0700, Chris Wright wrote:
> >> * Linus Torvalds (torvalds@osdl.org) wrote:
> >>>
> >>> On Wed, 17 May 2006, Chris Wright wrote:
> >>>> This is the start of the stable review cycle for the 2.6.16.17 release.
> >>>> There are 22 patches in this series, all will be posted as a response to
> >>>> this one.
> >>> I notice that none of the patches have authorship information.
> >>>
> >>> Has that always been true and I just never noticed before?
> >> It has always been that way with my script, I think Greg's as well.  Of
> >> course, it's in the patch, and goes into git with proper authorship.
> > 
> > The original versions of the patches do have the proper authorship
> > information, it's just that quilt strips it off when generating emails
> > like this.
> > 
> > When applying them to the git tree, everything comes out properly and
> > they get the correct authorship information.  And the git tools know to
> > properly create the emails with the right From: lines, maybe I should
> > play around with quilt to add that to it too...
> 
> While we're on it.. Just another small nitpick.  Random patch from this 00/22
> series:
> 
>  Subject: [PATCH 05/22] [PATCH] smbfs: Fix slab corruption in samba error path
> 
> Can the 2nd "[PATCH]" tag be removed as well? ;)

Oops, sorry about that.  I've fixed that up for all of the patches now,
I forgot to do that this time around.

thanks,

greg k-h