[patch 00/26] 2.6.16.2 -stable review

[patch 00/26] 2.6.16.2 -stable review

[gregkh]

This is the start of the stable review cycle for the 2.6.16.1 release.
There are 26 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 Thursday April 6, 23:00:00 UTC.  Anything
received after that time, might be too late.

thanks,

the -stable release team

[patch 01/26] tlclk: fix handling of device major

[gregkh]

[-- Attachment #1: tlclk-fix-handling-of-device-major.patch --]
[-- Type: text/plain, Size: 1009 bytes --]


From: Andrew Morton <akpm@osdl.org>

tlclk calls register_chrdev() and permits register_chrdev() to allocate the
major, but it promptly forgets what that major was.  So if there's no hardware
present you still get "telco_clock" appearing in /proc/devices and, I assume,
an oops reading /proc/devices if tlclk was a module.

Fix.

Mark, I'd suggest that that we not call register_chrdev() until _after_ we've
established that the hardware is present.

Cc: Mark Gross <mgross@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/char/tlclk.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.1.orig/drivers/char/tlclk.c
+++ linux-2.6.16.1/drivers/char/tlclk.c
@@ -767,6 +767,7 @@ static int __init tlclk_init(void)
 		printk(KERN_ERR "tlclk: can't get major %d.\n", tlclk_major);
 		return ret;
 	}
+	tlclk_major = ret;
 	alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
 	if (!alarm_events)
 		goto out1;

--

[patch 02/26] USB: Fix irda-usb use after use

[gregkh]

[-- Attachment #1: usb-0079-Fix-irda-usb-use-after-use.patch --]
[-- Type: text/plain, Size: 1175 bytes --]

Don't read from free'd memory after calling netif_rx().  docopy is used as
a boolean (0 and 1) so unsigned int is sufficient.

Coverity bug #928

Signed-off-by: Eugene Teo <eugene.teo@eugeneteo.net>
Cc: "David Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 drivers/net/irda/irda-usb.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.16.1.orig/drivers/net/irda/irda-usb.c
+++ linux-2.6.16.1/drivers/net/irda/irda-usb.c
@@ -740,7 +740,7 @@ static void irda_usb_receive(struct urb 
 	struct sk_buff *newskb;
 	struct sk_buff *dataskb;
 	struct urb *next_urb;
-	int		docopy;
+	unsigned int len, docopy;
 
 	IRDA_DEBUG(2, "%s(), len=%d\n", __FUNCTION__, urb->actual_length);
 	
@@ -851,10 +851,11 @@ static void irda_usb_receive(struct urb 
 	dataskb->dev = self->netdev;
 	dataskb->mac.raw  = dataskb->data;
 	dataskb->protocol = htons(ETH_P_IRDA);
+	len = dataskb->len;
 	netif_rx(dataskb);
 
 	/* Keep stats up to date */
-	self->stats.rx_bytes += dataskb->len;
+	self->stats.rx_bytes += len;
 	self->stats.rx_packets++;
 	self->netdev->last_rx = jiffies;
 

--

Re: [patch 02/26] USB: Fix irda-usb use after use

[David S. Miller]

From: gregkh@suse.de
Date: Tue, 4 Apr 2006 16:59:43 -0700

> Don't read from free'd memory after calling netif_rx().  docopy is used as
> a boolean (0 and 1) so unsigned int is sufficient.
> 
> Coverity bug #928
> 
> Signed-off-by: Eugene Teo <eugene.teo@eugeneteo.net>
> Cc: "David Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [stable] Re: [patch 02/26] USB: Fix irda-usb use after use

[Greg KH]

On Tue, Apr 04, 2006 at 05:16:44PM -0700, David S. Miller wrote:
> From: gregkh@suse.de
> Date: Tue, 4 Apr 2006 16:59:43 -0700
> 
> > Don't read from free'd memory after calling netif_rx().  docopy is used as
> > a boolean (0 and 1) so unsigned int is sufficient.
> > 
> > Coverity bug #928
> > 
> > Signed-off-by: Eugene Teo <eugene.teo@eugeneteo.net>
> > Cc: "David Miller" <davem@davemloft.net>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

Thanks, I've added this to the patch.

greg k-h

Re: [patch 02/26] USB: Fix irda-usb use after use

[Randy.Dunlap]

On Tue, 4 Apr 2006 16:59:43 -0700 gregkh@suse.de wrote:

> Don't read from free'd memory after calling netif_rx().  docopy is used as
> a boolean (0 and 1) so unsigned int is sufficient.
> 
> Coverity bug #928
> 
> Signed-off-by: Eugene Teo <eugene.teo@eugeneteo.net>
> Cc: "David Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
> 
>  drivers/net/irda/irda-usb.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> --- linux-2.6.16.1.orig/drivers/net/irda/irda-usb.c
> +++ linux-2.6.16.1/drivers/net/irda/irda-usb.c
> @@ -740,7 +740,7 @@ static void irda_usb_receive(struct urb 
>  	struct sk_buff *newskb;
>  	struct sk_buff *dataskb;
>  	struct urb *next_urb;
> -	int		docopy;
> +	unsigned int len, docopy;
>  

Is the <docopy> part of the patch just a convenience so that the patch
doesn't have to be split?  I don't see this part as critical.

>  	IRDA_DEBUG(2, "%s(), len=%d\n", __FUNCTION__, urb->actual_length);
>  	
> @@ -851,10 +851,11 @@ static void irda_usb_receive(struct urb 
>  	dataskb->dev = self->netdev;
>  	dataskb->mac.raw  = dataskb->data;
>  	dataskb->protocol = htons(ETH_P_IRDA);
> +	len = dataskb->len;
>  	netif_rx(dataskb);
>  
>  	/* Keep stats up to date */
> -	self->stats.rx_bytes += dataskb->len;
> +	self->stats.rx_bytes += len;
>  	self->stats.rx_packets++;
>  	self->netdev->last_rx = jiffies;
>  
> 

---
~Randy

[patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[gregkh]

[-- Attachment #1: sysfs-off-by-one.patch --]
[-- Type: text/plain, Size: 689 bytes --]

No one should be writing a PAGE_SIZE worth of data to a normal sysfs
file, so properly terminate the buffer.

Thanks to Al Viro for pointing out my stupidity here.

CVE-2006-1055 has been assigned for this.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- linux-2.6.16.1.orig/fs/sysfs/file.c
+++ linux-2.6.16.1/fs/sysfs/file.c
@@ -183,7 +183,7 @@ fill_write_buffer(struct sysfs_buffer * 
 		return -ENOMEM;
 
 	if (count >= PAGE_SIZE)
-		count = PAGE_SIZE;
+		count = PAGE_SIZE - 1;
 	error = copy_from_user(buffer->page,buf,count);
 	buffer->needs_read_fill = 1;
 	return error ? -EFAULT : count;

--

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Sergey Vlasov]

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

On Tue, 4 Apr 2006 16:59:47 -0700 gregkh@suse.de wrote:

> No one should be writing a PAGE_SIZE worth of data to a normal sysfs
> file, so properly terminate the buffer.
> 
> Thanks to Al Viro for pointing out my stupidity here.
> 
> CVE-2006-1055 has been assigned for this.
> 
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  fs/sysfs/file.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2.6.16.1.orig/fs/sysfs/file.c
> +++ linux-2.6.16.1/fs/sysfs/file.c
> @@ -183,7 +183,7 @@ fill_write_buffer(struct sysfs_buffer * 
>  		return -ENOMEM;
>  
>  	if (count >= PAGE_SIZE)
> -		count = PAGE_SIZE;
> +		count = PAGE_SIZE - 1;
>  	error = copy_from_user(buffer->page,buf,count);
>  	buffer->needs_read_fill = 1;
>  	return error ? -EFAULT : count;

This will break the "color_map" sysfs file for framebuffers -
drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
for a colormap with 256 entries.  In fact, the original patch which
changed PAGE_SIZE - 1 to PAGE_SIZE:

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d9d27fb651a7c95a46f276bacb4329db47470a6

was done exactly for use with that "color_map" file.

This patch also does not completely guarantee that the buffer will be
null-terminated.  A program may first call read() on the sysfs file,
which will allocate buffer->page and invoke ->show to fill that page;
then subsequent write() on the same file will reuse buffer->page.  To
get really bad results, you need to have ->store which assumes
null-terminated buffer together with ->show which writes to the last
byte of the page (which is probably rare, but show_cmap() does exactly
that).

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

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> This will break the "color_map" sysfs file for framebuffers -
> drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> for a colormap with 256 entries.  In fact, the original patch which
> changed PAGE_SIZE - 1 to PAGE_SIZE:

... cheerfully assuming that nobody assumes NUL-termination and
everyone (sysfs patch writers!) certainly uses the length argument.
Fscking brilliant, that.

Are you willing to audit all sysfs ->show() in the kernel?  Original
author of that turd had not been.

FWIW, "color_map" is a blatant abuse of interface.  Doesn't get
any more borderline...

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > This will break the "color_map" sysfs file for framebuffers -
> > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > for a colormap with 256 entries.  In fact, the original patch which
> > changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> ... cheerfully assuming that nobody assumes NUL-termination and
> everyone (sysfs patch writers!) certainly uses the length argument.
> Fscking brilliant, that.
>
> Are you willing to audit all sysfs ->show() in the kernel?  Original
> author of that turd had not been.
>
> FWIW, "color_map" is a blatant abuse of interface.  Doesn't get
> any more borderline...

The firmware interface is worse. You write the ROM image line by line
to the attribute and a hidden counter tracks how far your are into the
image.

There needs to be a standardized way to transfer larger pieces of data
via sysfs or we should go back to IOCTLs.

--
Jon Smirl
jonsmirl@gmail.com

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 11:38:06AM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > This will break the "color_map" sysfs file for framebuffers -
> > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > for a colormap with 256 entries.  In fact, the original patch which
> > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> >
> > ... cheerfully assuming that nobody assumes NUL-termination and
> > everyone (sysfs patch writers!) certainly uses the length argument.
> > Fscking brilliant, that.
> >
> > Are you willing to audit all sysfs ->show() in the kernel?  Original
> > author of that turd had not been.
> >
> > FWIW, "color_map" is a blatant abuse of interface.  Doesn't get
> > any more borderline...
> 
> The firmware interface is worse. You write the ROM image line by line
> to the attribute and a hidden counter tracks how far your are into the
> image.
> 
> There needs to be a standardized way to transfer larger pieces of data
> via sysfs or we should go back to IOCTLs.

How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
of your own?  ~20 lines for all of it, not counting #include...

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 11:38:06AM -0400, Jon Smirl wrote:
> > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > This will break the "color_map" sysfs file for framebuffers -
> > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > for a colormap with 256 entries.  In fact, the original patch which
> > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > >
> > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > Fscking brilliant, that.
> > >
> > > Are you willing to audit all sysfs ->show() in the kernel?  Original
> > > author of that turd had not been.
> > >
> > > FWIW, "color_map" is a blatant abuse of interface.  Doesn't get
> > > any more borderline...
> >
> > The firmware interface is worse. You write the ROM image line by line
> > to the attribute and a hidden counter tracks how far your are into the
> > image.
> >
> > There needs to be a standardized way to transfer larger pieces of data
> > via sysfs or we should go back to IOCTLs.
>
> How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> of your own?  ~20 lines for all of it, not counting #include...

Sysfs attributes allow full read/write on their file handles. But
GregKH has been discouraging that.

--
Jon Smirl
jonsmirl@gmail.com

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
              ^^^^^^^^^^^^^^^^^
> > of your own?  ~20 lines for all of it, not counting #include...
> 
> Sysfs attributes allow full read/write on their file handles. But
  ^^^^^^^^^^^^^^^^
> GregKH has been discouraging that.

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
>               ^^^^^^^^^^^^^^^^^

Where does this file come from? A device node?


> > > of your own?  ~20 lines for all of it, not counting #include...
> >
> > Sysfs attributes allow full read/write on their file handles. But
>   ^^^^^^^^^^^^^^^^
> > GregKH has been discouraging that.
>


--
Jon Smirl
jonsmirl@gmail.com

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 12:18:07PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > > > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
 ~~~~~
> >               ^^^^^^^^^^^^^^^^^
> 
> Where does this file come from? A device node?
> 
> 
> > > > of your own?  ~20 lines for all of it, not counting #include...
        ~~~~~~~~~~~

Are you really incapable of understanding a simple sentence?

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Valdis.Kletnieks]

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

On Wed, 05 Apr 2006 16:39:57 BST, Al Viro said:

> How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> of your own?  ~20 lines for all of it, not counting #include...

Great.  Instead of everybody using the same piece-of-manure sysfs interface,
each driver carries around its 20 lines to implement read() and write() in
subtly buggy and incompatible ways.

% grep nodev /proc/filesystems | wc -l
19

That's fsck'ing insane already.

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

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Greg KH]

On Wed, Apr 05, 2006 at 03:58:15PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 05 Apr 2006 16:39:57 BST, Al Viro said:
> 
> > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> > of your own?  ~20 lines for all of it, not counting #include...
> 
> Great.  Instead of everybody using the same piece-of-manure sysfs interface,
> each driver carries around its 20 lines to implement read() and write() in
> subtly buggy and incompatible ways.
> 
> % grep nodev /proc/filesystems | wc -l
> 19
> 
> That's fsck'ing insane already.

What is insane is using sysfs in ways it was not designed to do so.  The
color map is clearly not a "single, small value".  I have recommended
that the binary file in sysfs be used instead, as that is a designed
solution, but the authors do not want to do so for some odd reason.

So, we have a number of proposed solutions:
	- custom fs
	- binary sysfs file
	- configfs
and yet, people still complain...

bleah.

greg k-h

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 03:58:15PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 05 Apr 2006 16:39:57 BST, Al Viro said:
> 
> > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> > of your own?  ~20 lines for all of it, not counting #include...
> 
> Great.  Instead of everybody using the same piece-of-manure sysfs interface,
> each driver carries around its 20 lines to implement read() and write() in
> subtly buggy and incompatible ways.

No, that would be 20 lines to tell what and where you want in that fs and
how long should the things live.  Plus whatever you've got for your ->read()
and ->write() - using existing libfs helpers if needed.  Instead of pushing
into sysfs the things that do not fit sysfs interfaces.

BTW, in my experience "subtly buggy and incompatible ways" describes sysfs
uses, except that there's rarely anything subtle about that.  Care to name
four kernel data structures that got kobjects embedded into them (directly
or via struct device and it ilk) and had _NOT_ required at one point or
another (post-merge) fixing of blatant user-exploitable holes due to botched
lifetime rules?

Not that you had to embed them to achieve the same wonderful effect -
witness fbsysfs.c user-exploitable holes on unregister_framebuffer();
sure, fb_info->class_device will stay allocated if you have one of the
attributes opened.  Now try to call read(); what will it access?

Not to mention that the same file has a pile of ->store() assuming we
have NUL-termination, or the lovely use of sscanf() on non-NUL-terminated
array right in store_cmap() itself.  Equivalent of
	p = malloc(5);
	if (p) {
		memcpy(p, q, 5);
		sscanf(p, "%4hx", &v);
	}
You do realize that it's broken, don't you?  sscanf field width for %x
applies _after_ skipping the whitespace, not to the total amount of
characters being eaten.  And in reality this buffer comes from the end
of get_zeroed_page() result, so there's really nothing past its end.

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > This will break the "color_map" sysfs file for framebuffers -
> > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > for a colormap with 256 entries.  In fact, the original patch which
> > changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> ... cheerfully assuming that nobody assumes NUL-termination and
> everyone (sysfs patch writers!) certainly uses the length argument.
> Fscking brilliant, that.

Why does sysfs have two string length determination methods - both
NULL termination and a length parameter. It should be one or the
other, not both. Having both simply cause problems when some
developers implement one scheme and others only implement the other.


>
> Are you willing to audit all sysfs ->show() in the kernel?  Original
> author of that turd had not been.
>
> FWIW, "color_map" is a blatant abuse of interface.  Doesn't get
> any more borderline...
>
>


--
Jon Smirl
jonsmirl@gmail.com

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > This will break the "color_map" sysfs file for framebuffers -
> > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > for a colormap with 256 entries.  In fact, the original patch which
> > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> >
> > ... cheerfully assuming that nobody assumes NUL-termination and
> > everyone (sysfs patch writers!) certainly uses the length argument.
> > Fscking brilliant, that.
> 
> Why does sysfs have two string length determination methods - both
> NULL termination and a length parameter. It should be one or the
> other, not both. Having both simply cause problems when some
> developers implement one scheme and others only implement the other.

Which part of "sysfs patches can be written by idiots and usually are"
is too hard to understand?  Oh, wait.  I see...  Well, nevermind, then...

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > This will break the "color_map" sysfs file for framebuffers -
> > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > for a colormap with 256 entries.  In fact, the original patch which
> > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > >
> > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > Fscking brilliant, that.
> >
> > Why does sysfs have two string length determination methods - both
> > NULL termination and a length parameter. It should be one or the
> > other, not both. Having both simply cause problems when some
> > developers implement one scheme and others only implement the other.
>
> Which part of "sysfs patches can be written by idiots and usually are"
> is too hard to understand?  Oh, wait.  I see...  Well, nevermind, then...

I look forward to seeing your patches address these problems.

--
Jon Smirl
jonsmirl@gmail.com

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro]

On Wed, Apr 05, 2006 at 01:06:32PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> > > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > > This will break the "color_map" sysfs file for framebuffers -
> > > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > > for a colormap with 256 entries.  In fact, the original patch which
> > > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > > >
> > > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > > Fscking brilliant, that.
> > >
> > > Why does sysfs have two string length determination methods - both
> > > NULL termination and a length parameter. It should be one or the
> > > other, not both. Having both simply cause problems when some
> > > developers implement one scheme and others only implement the other.
> >
> > Which part of "sysfs patches can be written by idiots and usually are"
> > is too hard to understand?  Oh, wait.  I see...  Well, nevermind, then...
> 
> I look forward to seeing your patches address these problems.

I don't patch wetware.  As for the NUL-termination, fixing widespread breakage
you've introduced is _your_ responsibility.  Preferably taken care of before
submitting the patch in question.  As far as I'm concerned, reverting it
solves the problem.

I'm sorry, but by now I'm _REALLY_ sick and tired of sysfs wankers crowd
and your brand of idiocy is getting slightly past the annoying stage.
Let me spell it out for you:
	1) when you change the property of implementation, you must at least
try to check how much might rely on it.
	2) when interface is not documented, do not assume that its properties
are accidental and/or not relied upon.
	3) if you are breaking things, at least make sure that breakage is
easily found.  Do not introduce an obscure case when old assumption is false;
make it visible.
	4) when considerable part of interface users is obviously broken
by a change and you want to preserve that change, suggesting that somebody
else should fix the interface users for you since they did not match your
assumptions is... not the brightest idea in the world.

Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Jon Smirl]

On 4/5/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
> On Tue, 4 Apr 2006 16:59:47 -0700 gregkh@suse.de wrote:
>
> > No one should be writing a PAGE_SIZE worth of data to a normal sysfs
> > file, so properly terminate the buffer.
> >
> > Thanks to Al Viro for pointing out my stupidity here.
> >
> > CVE-2006-1055 has been assigned for this.
> >
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> >
> > ---
> >  fs/sysfs/file.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-2.6.16.1.orig/fs/sysfs/file.c
> > +++ linux-2.6.16.1/fs/sysfs/file.c
> > @@ -183,7 +183,7 @@ fill_write_buffer(struct sysfs_buffer *
> >               return -ENOMEM;
> >
> >       if (count >= PAGE_SIZE)
> > -             count = PAGE_SIZE;
> > +             count = PAGE_SIZE - 1;
> >       error = copy_from_user(buffer->page,buf,count);
> >       buffer->needs_read_fill = 1;
> >       return error ? -EFAULT : count;
>
> This will break the "color_map" sysfs file for framebuffers -
> drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> for a colormap with 256 entries.  In fact, the original patch which
> changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d9d27fb651a7c95a46f276bacb4329db47470a6
>
> was done exactly for use with that "color_map" file.
>
> This patch also does not completely guarantee that the buffer will be
> null-terminated.  A program may first call read() on the sysfs file,
> which will allocate buffer->page and invoke ->show to fill that page;
> then subsequent write() on the same file will reuse buffer->page.  To
> get really bad results, you need to have ->store which assumes
> null-terminated buffer together with ->show which writes to the last
> byte of the page (which is probably rare, but show_cmap() does exactly
> that).
>

That is correct, that the color_map attribute will break. Color_map is
not in general use outside the Mesa development community.

The whole scheme of using sysfs instead of IOCTLs is not working out
very well for framebuffer. The original idea was to let you control
your framebuffer with simple scripts or from the keyboard. But since
the attributes don't strip \n and blanks, it has made them more
complex to use from the keyboard.

The one attribute per file model doesn't work well when the attributes
need to be changed in a transaction. For example you want to change
your display to 1024x768 16bit color.  As you set the attributes one
at a time the display has to change since there is not guarantee that
you will complete the sequence. The framebuffer sysfs interface breaks
the one attribute per file rule and uses strings for grouped
attributes.

Ultimately I expect framebuffer will switch back to a helper app and
binary IOCTLs. Mainly because the help app can signal begin/end around
a change to a group of attributes.

--
Jon Smirl
jonsmirl@gmail.com

Re: [stable] Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Greg KH]

On Wed, Apr 05, 2006 at 11:30:54AM -0400, Jon Smirl wrote:
> 
> The one attribute per file model doesn't work well when the attributes
> need to be changed in a transaction. For example you want to change
> your display to 1024x768 16bit color.  As you set the attributes one
> at a time the display has to change since there is not guarantee that
> you will complete the sequence. The framebuffer sysfs interface breaks
> the one attribute per file rule and uses strings for grouped
> attributes.

I suggest you use configfs instead for this.  It allows this kind of
"grouped attributes".

good luck,

greg k-h

[patch 04/26] USB: EHCI full speed ISO bugfixes

[gregkh]

[-- Attachment #1: usb-ehci-full-speed-iso-bugfixes.patch --]
[-- Type: text/plain, Size: 2120 bytes --]


This patch replaces the split ISO raw_mask calculation code in the
iso_stream_init() function that computed incorrect numbers of high
speed transactions for both input and output transfers.

In the output case, it added a superfluous start-split transaction for
all maxmimum packet sizes that are a multiple of 188.

In the input case, it forgot to add complete-split transactions for all
microframes covered by the full speed transaction, and the additional
complete-split transaction needed for the case when full speed data
starts arriving near the end of a microframe.

These changes don't affect the lack of full speed bandwidth, but at
least it removes the MMF errors that the HC raised with some input
streams.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ehci-sched.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

--- linux-2.6.16.1.orig/drivers/usb/host/ehci-sched.c
+++ linux-2.6.16.1/drivers/usb/host/ehci-sched.c
@@ -707,6 +707,7 @@ iso_stream_init (
 	} else {
 		u32		addr;
 		int		think_time;
+		int		hs_transfers;
 
 		addr = dev->ttport << 24;
 		if (!ehci_is_TDI(ehci)
@@ -719,6 +720,7 @@ iso_stream_init (
 		think_time = dev->tt ? dev->tt->think_time : 0;
 		stream->tt_usecs = NS_TO_US (think_time + usb_calc_bus_time (
 				dev->speed, is_input, 1, maxp));
+		hs_transfers = max (1u, (maxp + 187) / 188);
 		if (is_input) {
 			u32	tmp;
 
@@ -727,12 +729,11 @@ iso_stream_init (
 			stream->usecs = HS_USECS_ISO (1);
 			stream->raw_mask = 1;
 
-			/* pessimistic c-mask */
-			tmp = usb_calc_bus_time (USB_SPEED_FULL, 1, 0, maxp)
-					/ (125 * 1000);
-			stream->raw_mask |= 3 << (tmp + 9);
+			/* c-mask as specified in USB 2.0 11.18.4 3.c */
+			tmp = (1 << (hs_transfers + 2)) - 1;
+			stream->raw_mask |= tmp << (8 + 2);
 		} else
-			stream->raw_mask = smask_out [maxp / 188];
+			stream->raw_mask = smask_out [hs_transfers - 1];
 		bandwidth = stream->usecs + stream->c_usecs;
 		bandwidth /= 1 << (interval + 2);
 

--

[patch 05/26] USB: usbcore: usb_set_configuration oops (NULL ptr dereference)

[gregkh]

[-- Attachment #1: usb-usbcore-usb_set_configuration-oops.patch --]
[-- Type: text/plain, Size: 1308 bytes --]

When trying to deconfigure a device via usb_set_configuration(dev, 0),
2.6.16-rc kernels after 55c527187c9d78f840b284d596a0b298bc1493af oops
with "Unable to handle NULL pointer dereference at...". This is due to
an unchecked dereference of cp in the power budget part.

This patch was already included in Linus' tree.    

Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---
 drivers/usb/core/message.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- linux-2.6.16.1.orig/drivers/usb/core/message.c
+++ linux-2.6.16.1/drivers/usb/core/message.c
@@ -1388,11 +1388,13 @@ free_interfaces:
 	if (dev->state != USB_STATE_ADDRESS)
 		usb_disable_device (dev, 1);	// Skip ep0
 
-	i = dev->bus_mA - cp->desc.bMaxPower * 2;
-	if (i < 0)
-		dev_warn(&dev->dev, "new config #%d exceeds power "
-				"limit by %dmA\n",
-				configuration, -i);
+	if (cp) {
+		i = dev->bus_mA - cp->desc.bMaxPower * 2;
+		if (i < 0)
+			dev_warn(&dev->dev, "new config #%d exceeds power "
+					"limit by %dmA\n",
+					configuration, -i);
+	}
 
 	if ((ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
 			USB_REQ_SET_CONFIGURATION, 0, configuration, 0,

--

[patch 06/26] sbp2: fix spinlock recursion

[gregkh]

[-- Attachment #1: sbp2-fix-spinlock-recursion.patch --]
[-- Type: text/plain, Size: 3720 bytes --]

sbp2util_mark_command_completed takes a lock which was already taken by
sbp2scsi_complete_all_commands.  This is a regression in Linux 2.6.15.
Reported by Kristian Harms at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187394

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ieee1394/sbp2.c |   32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

--- linux-2.6.16.1.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.16.1/drivers/ieee1394/sbp2.c
@@ -495,22 +495,17 @@ static struct sbp2_command_info *sbp2uti
 /*
  * This function finds the sbp2_command for a given outstanding SCpnt.
  * Only looks at the inuse list.
+ * Must be called with scsi_id->sbp2_command_orb_lock held.
  */
-static struct sbp2_command_info *sbp2util_find_command_for_SCpnt(struct scsi_id_instance_data *scsi_id, void *SCpnt)
+static struct sbp2_command_info *sbp2util_find_command_for_SCpnt(
+		struct scsi_id_instance_data *scsi_id, void *SCpnt)
 {
 	struct sbp2_command_info *command;
-	unsigned long flags;
 
-	spin_lock_irqsave(&scsi_id->sbp2_command_orb_lock, flags);
-	if (!list_empty(&scsi_id->sbp2_command_orb_inuse)) {
-		list_for_each_entry(command, &scsi_id->sbp2_command_orb_inuse, list) {
-			if (command->Current_SCpnt == SCpnt) {
-				spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
+	if (!list_empty(&scsi_id->sbp2_command_orb_inuse))
+		list_for_each_entry(command, &scsi_id->sbp2_command_orb_inuse, list)
+			if (command->Current_SCpnt == SCpnt)
 				return command;
-			}
-		}
-	}
-	spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 	return NULL;
 }
 
@@ -579,17 +574,15 @@ static void sbp2util_free_command_dma(st
 
 /*
  * This function moves a command to the completed orb list.
+ * Must be called with scsi_id->sbp2_command_orb_lock held.
  */
-static void sbp2util_mark_command_completed(struct scsi_id_instance_data *scsi_id,
-					    struct sbp2_command_info *command)
+static void sbp2util_mark_command_completed(
+		struct scsi_id_instance_data *scsi_id,
+		struct sbp2_command_info *command)
 {
-	unsigned long flags;
-
-	spin_lock_irqsave(&scsi_id->sbp2_command_orb_lock, flags);
 	list_del(&command->list);
 	sbp2util_free_command_dma(command);
 	list_add_tail(&command->list, &scsi_id->sbp2_command_orb_completed);
-	spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 }
 
 /*
@@ -2177,7 +2170,9 @@ static int sbp2_handle_status_write(stru
 		 * Matched status with command, now grab scsi command pointers and check status
 		 */
 		SCpnt = command->Current_SCpnt;
+		spin_lock_irqsave(&scsi_id->sbp2_command_orb_lock, flags);
 		sbp2util_mark_command_completed(scsi_id, command);
+		spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 
 		if (SCpnt) {
 
@@ -2513,6 +2508,7 @@ static int sbp2scsi_abort(struct scsi_cm
 		(struct scsi_id_instance_data *)SCpnt->device->host->hostdata[0];
 	struct sbp2scsi_host_info *hi = scsi_id->hi;
 	struct sbp2_command_info *command;
+	unsigned long flags;
 
 	SBP2_ERR("aborting sbp2 command");
 	scsi_print_command(SCpnt);
@@ -2523,6 +2519,7 @@ static int sbp2scsi_abort(struct scsi_cm
 		 * Right now, just return any matching command structures
 		 * to the free pool.
 		 */
+		spin_lock_irqsave(&scsi_id->sbp2_command_orb_lock, flags);
 		command = sbp2util_find_command_for_SCpnt(scsi_id, SCpnt);
 		if (command) {
 			SBP2_DEBUG("Found command to abort");
@@ -2540,6 +2537,7 @@ static int sbp2scsi_abort(struct scsi_cm
 				command->Current_done(command->Current_SCpnt);
 			}
 		}
+		spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 
 		/*
 		 * Initiate a fetch agent reset.

--

[patch 07/26] powerpc: make ISA floppies work again

[gregkh]

[-- Attachment #1: powerpc-make-isa-floppies-work-again.patch --]
[-- Type: text/plain, Size: 1700 bytes --]


From: Stephen Rothwell <sfr@canb.auug.org.au>

We used to assume that a DMA mapping request with a NULL dev was for
ISA DMA.  This assumption was broken at some point.  Now we explicitly
pass the detected ISA PCI device in the floppy setup.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/kernel/pci_64.c |    1 +
 include/asm-powerpc/floppy.h |    5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

--- linux-2.6.16.1.orig/arch/powerpc/kernel/pci_64.c
+++ linux-2.6.16.1/arch/powerpc/kernel/pci_64.c
@@ -78,6 +78,7 @@ int global_phb_number;		/* Global phb co
 
 /* Cached ISA bridge dev. */
 struct pci_dev *ppc64_isabridge_dev = NULL;
+EXPORT_SYMBOL_GPL(ppc64_isabridge_dev);
 
 static void fixup_broken_pcnet32(struct pci_dev* dev)
 {
--- linux-2.6.16.1.orig/include/asm-powerpc/floppy.h
+++ linux-2.6.16.1/include/asm-powerpc/floppy.h
@@ -35,6 +35,7 @@
 #ifdef CONFIG_PCI
 
 #include <linux/pci.h>
+#include <asm/ppc-pci.h>	/* for ppc64_isabridge_dev */
 
 #define fd_dma_setup(addr,size,mode,io) powerpc_fd_dma_setup(addr,size,mode,io)
 
@@ -52,12 +53,12 @@ static __inline__ int powerpc_fd_dma_set
 	if (bus_addr 
 	    && (addr != prev_addr || size != prev_size || dir != prev_dir)) {
 		/* different from last time -- unmap prev */
-		pci_unmap_single(NULL, bus_addr, prev_size, prev_dir);
+		pci_unmap_single(ppc64_isabridge_dev, bus_addr, prev_size, prev_dir);
 		bus_addr = 0;
 	}
 
 	if (!bus_addr)	/* need to map it */
-		bus_addr = pci_map_single(NULL, addr, size, dir);
+		bus_addr = pci_map_single(ppc64_isabridge_dev, addr, size, dir);
 
 	/* remember this one as prev */
 	prev_addr = addr;

--

[patch 08/26] PCMCIA_SPECTRUM must select FW_LOADER

[gregkh]

[-- Attachment #1: pcmcia_spectrum-must-select-fw_loader.patch --]
[-- Type: text/plain, Size: 692 bytes --]

PCMCIA_SPECTRUM must select FW_LOADER.

Reported by "Alexander E. Patrakov" <patrakov@ums.usu.ru>.

This patch was already included in Linus' tree.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.1.orig/drivers/net/wireless/Kconfig
+++ linux-2.6.16.1/drivers/net/wireless/Kconfig
@@ -374,6 +374,7 @@ config PCMCIA_HERMES
 config PCMCIA_SPECTRUM
 	tristate "Symbol Spectrum24 Trilogy PCMCIA card support"
 	depends on NET_RADIO && PCMCIA && HERMES
+	select FW_LOADER
 	---help---
 
 	  This is a driver for 802.11b cards using RAM-loadable Symbol

--

[patch 09/26] pcmcia: permit single-character-identifiers

[gregkh]

[-- Attachment #1: pcmcia-permit-single-character-identifiers.patch --]
[-- Type: text/plain, Size: 1105 bytes --]

From: Janos Farkas <chexum@gmail.com>

For some time, the core pcmcia drivers seem not to think single
character prod_ids are valid, thus preventing the "cleverly" named

  "D" "Link DWL-650 11Mbps WLAN Card"

Before (as in 2.6.16):
PRODID_1=""
PRODID_2="Link DWL-650 11Mbps WLAN Card"
PRODID_3="Version 01.02"
PRODID_4=""
MANFID=0156,0002
FUNCID=6

After (with the patch)
PRODID_1="D"
PRODID_2="Link DWL-650 11Mbps WLAN Card"
PRODID_3="Version 01.02"
PRODID_4=""
MANFID=0156,0002
FUNCID=6

Signed-off-by: Janos Farkas <chexum@gmail.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/pcmcia/ds.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.1.orig/drivers/pcmcia/ds.c
+++ linux-2.6.16.1/drivers/pcmcia/ds.c
@@ -546,7 +546,7 @@ static int pcmcia_device_query(struct pc
 			tmp = vers1->str + vers1->ofs[i];
 
 			length = strlen(tmp) + 1;
-			if ((length < 3) || (length > 255))
+			if ((length < 2) || (length > 255))
 				continue;
 
 			p_dev->prod_id[i] = kmalloc(sizeof(char) * length,

--

[patch 10/26] opti9x - Fix compile without CONFIG_PNP

[gregkh]

[-- Attachment #1: opti9x-fix-compile-without-config_pnp.patch --]
[-- Type: text/plain, Size: 1429 bytes --]

From: Takashi Iwai <tiwai@suse.de>

Modules: Opti9xx drivers

Fix compile errors without CONFIG_PNP.

This patch was already included in Linus' tree.
 
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/isa/opti9xx/opti92x-ad1848.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-2.6.16.1.orig/sound/isa/opti9xx/opti92x-ad1848.c
+++ linux-2.6.16.1/sound/isa/opti9xx/opti92x-ad1848.c
@@ -2088,9 +2088,11 @@ static int __init alsa_card_opti9xx_init
 	int error;
 	struct platform_device *device;
 
+#ifdef CONFIG_PNP
 	pnp_register_card_driver(&opti9xx_pnpc_driver);
 	if (snd_opti9xx_pnp_is_probed)
 		return 0;
+#endif
 	if (! is_isapnp_selected()) {
 		error = platform_driver_register(&snd_opti9xx_driver);
 		if (error < 0)
@@ -2102,7 +2104,9 @@ static int __init alsa_card_opti9xx_init
 		}
 		platform_driver_unregister(&snd_opti9xx_driver);
 	}
+#ifdef CONFIG_PNP
 	pnp_unregister_card_driver(&opti9xx_pnpc_driver);
+#endif
 #ifdef MODULE
 	printk(KERN_ERR "no OPTi " CHIP_NAME " soundcard found\n");
 #endif
@@ -2115,7 +2119,9 @@ static void __exit alsa_card_opti9xx_exi
 		platform_device_unregister(snd_opti9xx_platform_device);
 		platform_driver_unregister(&snd_opti9xx_driver);
 	}
+#ifdef CONFIG_PNP
 	pnp_unregister_card_driver(&opti9xx_pnpc_driver);
+#endif
 }
 
 module_init(alsa_card_opti9xx_init)

--

[patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[gregkh]

[-- Attachment #1: move-destructor-from-neigh-ops-to.patch --]
[-- Type: text/plain, Size: 4380 bytes --]

From: Michael Tsirkin <mst@mellanox.co.il>

struct neigh_ops currently has a destructor field, but not a constructor field.
The infiniband/ulp/ipoib in-tree driver stashes some info in the neighbour
structure (the results of the second-stage lookup from ARP results to real
link-level path), and it uses neigh->ops->destructor to get a callback so it can
clean up this extra info when a neighbour is freed.  We've run into problems
with this: since the destructor is in an ops field that is shared between
neighbours that may belong to different net devices, there's no way to set/clear
it safely.

The following patch moves this field to neigh_parms where it can be safely set,
together with its twin neigh_setup, and switches the only two in-kernel users
(ipoib and clip) to this interface.

Signed-off-by: Michael Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/infiniband/ulp/ipoib/ipoib_main.c      |   16 +---------------
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |    1 -
 include/net/neighbour.h                        |    2 +-
 net/atm/clip.c                                 |    2 +-
 net/core/neighbour.c                           |    4 ++--
 5 files changed, 5 insertions(+), 20 deletions(-)

--- linux-2.6.16.1.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ linux-2.6.16.1/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -247,7 +247,6 @@ static void path_free(struct net_device 
 		if (neigh->ah)
 			ipoib_put_ah(neigh->ah);
 		*to_ipoib_neigh(neigh->neighbour) = NULL;
-		neigh->neighbour->ops->destructor = NULL;
 		kfree(neigh);
 	}
 
@@ -530,7 +529,6 @@ static void neigh_add_path(struct sk_buf
 err:
 	*to_ipoib_neigh(skb->dst->neighbour) = NULL;
 	list_del(&neigh->list);
-	neigh->neighbour->ops->destructor = NULL;
 	kfree(neigh);
 
 	++priv->stats.tx_dropped;
@@ -769,21 +767,9 @@ static void ipoib_neigh_destructor(struc
 		ipoib_put_ah(ah);
 }
 
-static int ipoib_neigh_setup(struct neighbour *neigh)
-{
-	/*
-	 * Is this kosher?  I can't find anybody in the kernel that
-	 * sets neigh->destructor, so we should be able to set it here
-	 * without trouble.
-	 */
-	neigh->ops->destructor = ipoib_neigh_destructor;
-
-	return 0;
-}
-
 static int ipoib_neigh_setup_dev(struct net_device *dev, struct neigh_parms *parms)
 {
-	parms->neigh_setup = ipoib_neigh_setup;
+	parms->neigh_destructor = ipoib_neigh_destructor;
 
 	return 0;
 }
--- linux-2.6.16.1.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ linux-2.6.16.1/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -115,7 +115,6 @@ static void ipoib_mcast_free(struct ipoi
 		if (neigh->ah)
 			ipoib_put_ah(neigh->ah);
 		*to_ipoib_neigh(neigh->neighbour) = NULL;
-		neigh->neighbour->ops->destructor = NULL;
 		kfree(neigh);
 	}
 
--- linux-2.6.16.1.orig/include/net/neighbour.h
+++ linux-2.6.16.1/include/net/neighbour.h
@@ -68,6 +68,7 @@ struct neigh_parms
 	struct net_device *dev;
 	struct neigh_parms *next;
 	int	(*neigh_setup)(struct neighbour *);
+	void	(*neigh_destructor)(struct neighbour *);
 	struct neigh_table *tbl;
 
 	void	*sysctl_table;
@@ -145,7 +146,6 @@ struct neighbour
 struct neigh_ops
 {
 	int			family;
-	void			(*destructor)(struct neighbour *);
 	void			(*solicit)(struct neighbour *, struct sk_buff*);
 	void			(*error_report)(struct neighbour *, struct sk_buff*);
 	int			(*output)(struct sk_buff*);
--- linux-2.6.16.1.orig/net/atm/clip.c
+++ linux-2.6.16.1/net/atm/clip.c
@@ -289,7 +289,6 @@ static void clip_neigh_error(struct neig
 
 static struct neigh_ops clip_neigh_ops = {
 	.family =		AF_INET,
-	.destructor =		clip_neigh_destroy,
 	.solicit =		clip_neigh_solicit,
 	.error_report =		clip_neigh_error,
 	.output =		dev_queue_xmit,
@@ -346,6 +345,7 @@ static struct neigh_table clip_tbl = {
 
 	/* parameters are copied from ARP ... */
 	.parms = {
+		.neigh_destructor	= clip_neigh_destroy,
 		.tbl 			= &clip_tbl,
 		.base_reachable_time 	= 30 * HZ,
 		.retrans_time 		= 1 * HZ,
--- linux-2.6.16.1.orig/net/core/neighbour.c
+++ linux-2.6.16.1/net/core/neighbour.c
@@ -586,8 +586,8 @@ void neigh_destroy(struct neighbour *nei
 			kfree(hh);
 	}
 
-	if (neigh->ops && neigh->ops->destructor)
-		(neigh->ops->destructor)(neigh);
+	if (neigh->parms->neigh_destructor)
+		(neigh->parms->neigh_destructor)(neigh);
 
 	skb_queue_purge(&neigh->arp_queue);
 

--

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[David S. Miller]

From: gregkh@suse.de
Date: Tue, 4 Apr 2006 17:00:30 -0700

> From: Michael Tsirkin <mst@mellanox.co.il>
> 
> struct neigh_ops currently has a destructor field, but not a constructor field.
> The infiniband/ulp/ipoib in-tree driver stashes some info in the neighbour
> structure (the results of the second-stage lookup from ARP results to real
> link-level path), and it uses neigh->ops->destructor to get a callback so it can
> clean up this extra info when a neighbour is freed.  We've run into problems
> with this: since the destructor is in an ops field that is shared between
> neighbours that may belong to different net devices, there's no way to set/clear
> it safely.
> 
> The following patch moves this field to neigh_parms where it can be safely set,
> together with its twin neigh_setup, and switches the only two in-kernel users
> (ipoib and clip) to this interface.

Major NAK.

This does not fix a bug, it is merely and API change that the
inifiniband folks want for some of their infrastructure.

It was accepted for 2.6.17, but this change is not appropriate
for the -stable release branch.

Furthermore, this version of the patch here will break the build of
ATM.

Re: [stable] Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[Greg KH]

On Tue, Apr 04, 2006 at 05:07:20PM -0700, David S. Miller wrote:
> From: gregkh@suse.de
> Date: Tue, 4 Apr 2006 17:00:30 -0700
> 
> > From: Michael Tsirkin <mst@mellanox.co.il>
> > 
> > struct neigh_ops currently has a destructor field, but not a constructor field.
> > The infiniband/ulp/ipoib in-tree driver stashes some info in the neighbour
> > structure (the results of the second-stage lookup from ARP results to real
> > link-level path), and it uses neigh->ops->destructor to get a callback so it can
> > clean up this extra info when a neighbour is freed.  We've run into problems
> > with this: since the destructor is in an ops field that is shared between
> > neighbours that may belong to different net devices, there's no way to set/clear
> > it safely.
> > 
> > The following patch moves this field to neigh_parms where it can be safely set,
> > together with its twin neigh_setup, and switches the only two in-kernel users
> > (ipoib and clip) to this interface.
> 
> Major NAK.
> 
> This does not fix a bug, it is merely and API change that the
> inifiniband folks want for some of their infrastructure.
> 
> It was accepted for 2.6.17, but this change is not appropriate
> for the -stable release branch.
> 
> Furthermore, this version of the patch here will break the build of
> ATM.

Thanks for the information and the review, I've dropped this patch from
the queue now.

greg k-h

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[Roland Dreier]

    David> Major NAK.

    David> This does not fix a bug, it is merely and API change that
    David> the inifiniband folks want for some of their infrastructure.

It definitely does fix a bug: without the change, because
ops->destructor is shared (possibly with other net devices), IPoIB
ops->can't set it or clear it safely.  I don't have exact details at
hand but this was definitely causing panics for people.

    David> Furthermore, this version of the patch here will break the
    David> build of ATM.

I'll admit I haven't tested but it looks OK to me -- it seems to have
the required chunk in clip.c.

I'm not going to fight too hard for it (I'll let Michael champion it
if he really cares), but I think this is a legitimate -stable patch:
it fixes a panic that real users are seeing.

 - R.

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[David S. Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Tue, 04 Apr 2006 17:14:27 -0700

> I'm not going to fight too hard for it (I'll let Michael champion it
> if he really cares), but I think this is a legitimate -stable patch:
> it fixes a panic that real users are seeing.

You were using an interface in an unintended way.

Do you know %100 for certain that moving that callback to
a different location won't break anything?

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[Roland Dreier]

    David> You were using an interface in an unintended way.

There were a lot of opportunities to suggest a better way or even just
raise the alarm when IPoIB was first being reviewed.  And I don't
remember anyone giving any guidance or insight into the neighbour
destructor design the three or four times Michael raised the issue of
the IPoIB crash and posted this patch for review....

    David> Do you know %100 for certain that moving that callback to a
    David> different location won't break anything?

Of course it's not %100 certain, but it definitely fixes a panic in
IPoIB, and the clip.c change looks "obviously correct."

If this patch is too risky for -stable, that's fine.  But let's be
clear that it _does_ fix a panic people hit in practice, and as far as
I know it doesn't break the ATM build

 - R.

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[David S. Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Tue, 04 Apr 2006 17:42:20 -0700

>     David> You were using an interface in an unintended way.
> 
> There were a lot of opportunities to suggest a better way or even just
> raise the alarm when IPoIB was first being reviewed.  And I don't
> remember anyone giving any guidance or insight into the neighbour
> destructor design the three or four times Michael raised the issue of
> the IPoIB crash and posted this patch for review....

If I thought your change was appropriate for 2.6.16 I would have put
it into that tree back then.  Instead, I did not consider it
appropriate, that's why we decided to put it into 2.6.17

Nothing since then has changed the situation.

> If this patch is too risky for -stable, that's fine.  But let's be
> clear that it _does_ fix a panic people hit in practice, and as far as
> I know it doesn't break the ATM build

I think it's too risky.  It fixes a panic for infiniband.

I think you should not have submitted such a core networking change to
-stable without passing it by netdev CC:'ing me first.

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[Roland Dreier]

    David> I think it's too risky.  It fixes a panic for infiniband.

Fair enough.

    David> I think you should not have submitted such a core
    David> networking change to -stable without passing it by netdev
    David> CC:'ing me first.

Noted.  Glad I wasn't the one who submitted it ;)

 - R.

Re: [patch 11/26] IPOB: Move destructor from neigh->ops to neigh_param

[Michael S. Tsirkin]

Quoting r. David S. Miller <davem@davemloft.net>:
> I think it's too risky.  It fixes a panic for infiniband.

Fair enough.

> I think you should not have submitted such a core networking change to
> -stable without passing it by netdev CC:'ing me first.

OK, note taken.

-- 
Michael S. Tsirkin

[patch 12/26] Mark longhaul driver as broken.

[gregkh]

[-- Attachment #1: mark-longhaul-driver-as-broken.patch --]
[-- Type: text/plain, Size: 850 bytes --]

From: Dave Jones <davej@redhat.com>

[CPUFREQ] Mark longhaul driver as broken.
This seems to work for a short period of time, but when
used in conjunction with a userspace governor that changes
the frequency regularly, it's only a matter of time before
everything just locks up.

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/i386/kernel/cpu/cpufreq/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
+++ linux-2.6.16.1/arch/i386/kernel/cpu/cpufreq/Kconfig
@@ -203,6 +203,7 @@ config X86_LONGRUN
 config X86_LONGHAUL
 	tristate "VIA Cyrix III Longhaul"
 	select CPU_FREQ_TABLE
+	depends on BROKEN
 	help
 	  This adds the CPUFreq driver for VIA Samuel/CyrixIII, 
 	  VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T 

--

[patch 13/26] isicom must select FW_LOADER

[gregkh]

[-- Attachment #1: isicom-must-select-fw_loader.patch --]
[-- Type: text/plain, Size: 795 bytes --]

From: maximilian attems <maks@sternwelten.at>

The isicom driver uses request_firmware()
and thus needs to select FW_LOADER.

This patch was already included in Linus' tree.

Signed-off-by: maximilian attems <maks@sternwelten.at>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.1.orig/drivers/char/Kconfig
+++ linux-2.6.16.1/drivers/char/Kconfig
@@ -187,6 +187,7 @@ config MOXA_SMARTIO
 config ISI
 	tristate "Multi-Tech multiport card support (EXPERIMENTAL)"
 	depends on SERIAL_NONSTANDARD
+	select FW_LOADER
 	help
 	  This is a driver for the Multi-Tech cards which provide several
 	  serial ports.  The driver is experimental and can currently only be

--

[patch 14/26] {ip, nf}_conntrack_netlink: fix expectation notifier unregistration

[gregkh]

[-- Attachment #1: ip.patch --]
[-- Type: text/plain, Size: 1679 bytes --]


From: Martin Josefsson <gandalf@wlug.westbo.se>

[NETFILTER]: {ip,nf}_conntrack_netlink: fix expectation notifier unregistration

This patch fixes expectation notifier unregistration on module unload to
use ip_conntrack_expect_unregister_notifier(). This bug causes a soft
lockup at the first expectation created after a rmmod ; insmod of this
module.

Should go into -stable as well.

Signed-off-by: Martin Josefsson <gandalf@wlug.westbo.se>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ipv4/netfilter/ip_conntrack_netlink.c |    2 +-
 net/netfilter/nf_conntrack_netlink.c      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.16.1.orig/net/ipv4/netfilter/ip_conntrack_netlink.c
+++ linux-2.6.16.1/net/ipv4/netfilter/ip_conntrack_netlink.c
@@ -1619,7 +1619,7 @@ static void __exit ctnetlink_exit(void)
 	printk("ctnetlink: unregistering from nfnetlink.\n");
 
 #ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
-	ip_conntrack_unregister_notifier(&ctnl_notifier_exp);
+	ip_conntrack_expect_unregister_notifier(&ctnl_notifier_exp);
 	ip_conntrack_unregister_notifier(&ctnl_notifier);
 #endif
 
--- linux-2.6.16.1.orig/net/netfilter/nf_conntrack_netlink.c
+++ linux-2.6.16.1/net/netfilter/nf_conntrack_netlink.c
@@ -1641,7 +1641,7 @@ static void __exit ctnetlink_exit(void)
 	printk("ctnetlink: unregistering from nfnetlink.\n");
 
 #ifdef CONFIG_NF_CONNTRACK_EVENTS
-	nf_conntrack_unregister_notifier(&ctnl_notifier_exp);
+	nf_conntrack_expect_unregister_notifier(&ctnl_notifier_exp);
 	nf_conntrack_unregister_notifier(&ctnl_notifier);
 #endif
 

--

[patch 15/26] wrong error path in dup_fd() leading to oopses in RCU

[gregkh]

[-- Attachment #1: fw-wrong-error-path-in-dup_fd-leading-to-oopses.patch --]
[-- Type: text/plain, Size: 1437 bytes --]



From: Kirill Korotaev <dev@openvz.org>

[PATCH] wrong error path in dup_fd() leading to oopses in RCU

Wrong error path in dup_fd() - it should return NULL on error,
not an address of already freed memory :/

Triggered by OpenVZ stress test suite.

What is interesting is that it was causing different oopses in RCU like
below:
Call Trace:
   [<c013492c>] rcu_do_batch+0x2c/0x80
   [<c0134bdd>] rcu_process_callbacks+0x3d/0x70
   [<c0126cf3>] tasklet_action+0x73/0xe0
   [<c01269aa>] __do_softirq+0x10a/0x130
   [<c01058ff>] do_softirq+0x4f/0x60
   =======================
   [<c0113817>] smp_apic_timer_interrupt+0x77/0x110
   [<c0103b54>] apic_timer_interrupt+0x1c/0x24
  Code:  Bad EIP value.
   <0>Kernel panic - not syncing: Fatal exception in interrupt

Signed-Off-By: Pavel Emelianov <xemul@sw.ru>
Signed-Off-By: Dmitry Mishin <dim@openvz.org>
Signed-Off-By: Kirill Korotaev <dev@openvz.org>
Signed-Off-By: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/fork.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.1.orig/kernel/fork.c
+++ linux-2.6.16.1/kernel/fork.c
@@ -720,7 +720,7 @@ out_release:
 	free_fdset (new_fdt->open_fds, new_fdt->max_fdset);
 	free_fd_array(new_fdt->fd, new_fdt->max_fds);
 	kmem_cache_free(files_cachep, newf);
-	goto out;
+	return NULL;
 }
 
 static int copy_files(unsigned long clone_flags, struct task_struct * tsk)

--

[patch 16/26] Fix the p4-clockmod N60 errata workaround.

[gregkh]

[-- Attachment #1: fix-the-p4-clockmod-n60-errata-workaround.patch --]
[-- Type: text/plain, Size: 1103 bytes --]

From: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

[CPUFREQ] Fix the p4-clockmod N60 errata workaround.

Fix the code to disable freqs less than 2GHz in N60 errata.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/i386/kernel/cpu/cpufreq/p4-clockmod.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.1.orig/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
+++ linux-2.6.16.1/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
@@ -244,7 +244,7 @@ static int cpufreq_p4_cpu_init(struct cp
 	for (i=1; (p4clockmod_table[i].frequency != CPUFREQ_TABLE_END); i++) {
 		if ((i<2) && (has_N44_O17_errata[policy->cpu]))
 			p4clockmod_table[i].frequency = CPUFREQ_ENTRY_INVALID;
-		else if (has_N60_errata[policy->cpu] && p4clockmod_table[i].frequency < 2000000)
+		else if (has_N60_errata[policy->cpu] && ((stock_freq * i)/8) < 2000000)
 			p4clockmod_table[i].frequency = CPUFREQ_ENTRY_INVALID;
 		else
 			p4clockmod_table[i].frequency = (stock_freq * i)/8;

--

[patch 17/26] Fix module refcount leak in __set_personality()

[gregkh]

[-- Attachment #1: fix-module-refcount-leak-in.patch --]
[-- Type: text/plain, Size: 873 bytes --]

From: Sergey Vlasov <vsu@altlinux.ru>

If the change of personality does not lead to change of exec domain,
__set_personality() returned without releasing the module reference
acquired by lookup_exec_domain().

This patch was already included in Linus' tree.

Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/exec_domain.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.1.orig/kernel/exec_domain.c
+++ linux-2.6.16.1/kernel/exec_domain.c
@@ -140,6 +140,7 @@ __set_personality(u_long personality)
 	ep = lookup_exec_domain(personality);
 	if (ep == current_thread_info()->exec_domain) {
 		current->personality = personality;
+		module_put(ep->module);
 		return 0;
 	}
 

--

[patch 18/26] fib_trie.c node freeing fix

[gregkh]

[-- Attachment #1: fib_trie.c-node-freeing-fix.patch --]
[-- Type: text/plain, Size: 1365 bytes --]


Please apply to 2.6.{14,15,16} -stable, thanks a lot.

From: Robert Olsson <robert.olsson@its.uu.se>

[FIB_TRIE]: Fix leaf freeing.

Seems like leaf (end-nodes) has been freed by __tnode_free_rcu and not
by __leaf_free_rcu. This fixes the problem. Only tnode_free is now
used which checks for appropriate node type. free_leaf can be removed.

Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Signed-off-by: David Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ipv4/fib_trie.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.16.1.orig/net/ipv4/fib_trie.c
+++ linux-2.6.16.1/net/ipv4/fib_trie.c
@@ -314,11 +314,6 @@ static void __leaf_free_rcu(struct rcu_h
 	kfree(container_of(head, struct leaf, rcu));
 }
 
-static inline void free_leaf(struct leaf *leaf)
-{
-	call_rcu(&leaf->rcu, __leaf_free_rcu);
-}
-
 static void __leaf_info_free_rcu(struct rcu_head *head)
 {
 	kfree(container_of(head, struct leaf_info, rcu));
@@ -357,7 +352,12 @@ static void __tnode_free_rcu(struct rcu_
 
 static inline void tnode_free(struct tnode *tn)
 {
-	call_rcu(&tn->rcu, __tnode_free_rcu);
+	if(IS_LEAF(tn)) {
+		struct leaf *l = (struct leaf *) tn;
+		call_rcu_bh(&l->rcu, __leaf_free_rcu);
+	}
+        else
+		call_rcu(&tn->rcu, __tnode_free_rcu);
 }
 
 static struct leaf *leaf_new(void)

--

[patch 19/26] fbcon: Fix big-endian bogosity in slow_imageblit()

[gregkh]

[-- Attachment #1: fbcon-fix-big-endian-bogosity-in.patch --]
[-- Type: text/plain, Size: 1414 bytes --]

The monochrome->color expansion routine that handles bitmaps which have
(widths % 8) != 0 (slow_imageblit) produces corrupt characters in big-endian.
This is caused by a bogus bit test in slow_imageblit().

Fix.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Acked-by: Herbert Poetzl <herbert@13thfloor.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/cfbimgblt.c |    2 +-
 include/linux/fb.h        |    2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

--- linux-2.6.16.1.orig/drivers/video/cfbimgblt.c
+++ linux-2.6.16.1/drivers/video/cfbimgblt.c
@@ -169,7 +169,7 @@ static inline void slow_imageblit(const 
 
 		while (j--) {
 			l--;
-			color = (*s & 1 << (FB_BIT_NR(l))) ? fgcolor : bgcolor;
+			color = (*s & (1 << l)) ? fgcolor : bgcolor;
 			val |= FB_SHIFT_HIGH(color, shift);
 			
 			/* Did the bitshift spill bits to the next long? */
--- linux-2.6.16.1.orig/include/linux/fb.h
+++ linux-2.6.16.1/include/linux/fb.h
@@ -839,12 +839,10 @@ struct fb_info {
 #define FB_LEFT_POS(bpp)          (32 - bpp)
 #define FB_SHIFT_HIGH(val, bits)  ((val) >> (bits))
 #define FB_SHIFT_LOW(val, bits)   ((val) << (bits))
-#define FB_BIT_NR(b)              (7 - (b))
 #else
 #define FB_LEFT_POS(bpp)          (0)
 #define FB_SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define FB_SHIFT_LOW(val, bits)   ((val) >> (bits))
-#define FB_BIT_NR(b)              (b)
 #endif
 
     /*

--

[patch 20/26] drivers/net/wireless/ipw2200.c: fix an array overun

[gregkh]

[-- Attachment #1: drivers-net-wireless-ipw2200.c-fix-an.patch --]
[-- Type: text/plain, Size: 818 bytes --]

This patch fixes a big array overun found by the Coverity checker.

This was already fixed in Linus' tree.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/ipw2200.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-2.6.16.1.orig/drivers/net/wireless/ipw2200.c
+++ linux-2.6.16.1/drivers/net/wireless/ipw2200.c
@@ -9956,9 +9956,8 @@ static int ipw_ethtool_set_eeprom(struct
 		return -EINVAL;
 	down(&p->sem);
 	memcpy(&p->eeprom[eeprom->offset], bytes, eeprom->len);
-	for (i = IPW_EEPROM_DATA;
-	     i < IPW_EEPROM_DATA + IPW_EEPROM_IMAGE_SIZE; i++)
-		ipw_write8(p, i, p->eeprom[i]);
+	for (i = 0; i < IPW_EEPROM_IMAGE_SIZE; i++)
+		ipw_write8(p, i + IPW_EEPROM_DATA, p->eeprom[i]);
 	up(&p->sem);
 	return 0;
 }

--

[patch 21/26] Fix NULL pointer dereference in node_read_numastat()

[gregkh]

[-- Attachment #1: clameter-sgi.com-re-fw-2.6.16-crashes-when-running.patch --]
[-- Type: text/plain, Size: 840 bytes --]

From: Christoph Lameter <clameter@sgi.com>

Fix NULL pointer dereference in node_read_numastat()

zone_pcp() only returns valid values if the processor is online.

Change node_read_numastat() to only scan online processors.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/node.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.1.orig/drivers/base/node.c
+++ linux-2.6.16.1/drivers/base/node.c
@@ -106,7 +106,7 @@ static ssize_t node_read_numastat(struct
 	other_node = 0;
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		struct zone *z = &pg->node_zones[i];
-		for (cpu = 0; cpu < NR_CPUS; cpu++) {
+		for_each_online_cpu(cpu) {
 			struct per_cpu_pageset *ps = zone_pcp(z,cpu);
 			numa_hit += ps->numa_hit;
 			numa_miss += ps->numa_miss;

--

[patch 22/26] AIRO{,_CS} <-> CRYPTO fixes

[gregkh]

[-- Attachment #1: airo-_cs-crypto-fixes.patch --]
[-- Type: text/plain, Size: 1258 bytes --]

CRYPTO is a helper variable, and to make it easier for users, it should 
therefore select'ed and not be listed in the dependencies.

drivers/net/wireless/airo.c requires CONFIG_CRYPTO for compilations.

Therefore, AIRO_CS also has to select CRYPTO.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/Kconfig |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.16.1.orig/drivers/net/wireless/Kconfig
+++ linux-2.6.16.1/drivers/net/wireless/Kconfig
@@ -239,7 +239,8 @@ config IPW2200_DEBUG
 
 config AIRO
 	tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards"
-	depends on NET_RADIO && ISA_DMA_API && CRYPTO && (PCI || BROKEN)
+ 	depends on NET_RADIO && ISA_DMA_API && (PCI || BROKEN)
+	select CRYPTO
 	---help---
 	  This is the standard Linux driver to support Cisco/Aironet ISA and
 	  PCI 802.11 wireless cards.
@@ -388,6 +389,7 @@ config PCMCIA_SPECTRUM
 config AIRO_CS
 	tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards"
 	depends on NET_RADIO && PCMCIA && (BROKEN || !M32R)
+	select CRYPTO
 	---help---
 	  This is the standard Linux driver to support Cisco/Aironet PCMCIA
 	  802.11 wireless cards.  This driver is the same as the Aironet

--

[patch 23/26] Add default entry for CTL Travel Master U553W

[gregkh]

[-- Attachment #1: add-default-entry-for-ctl-travel-master.patch --]
[-- Type: text/plain, Size: 1024 bytes --]

From: Takashi Iwai <tiwai@suse.de>

Added the default entry of ALC880 configuration table for
CTL Travel Master U553W.

This patch was already included in Linus' tree.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/hda/patch_realtek.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.16.1.orig/sound/pci/hda/patch_realtek.c
+++ linux-2.6.16.1/sound/pci/hda/patch_realtek.c
@@ -2948,6 +2948,8 @@ static struct hda_board_config alc260_cf
 	{ .modelname = "basic", .config = ALC260_BASIC },
 	{ .pci_subvendor = 0x104d, .pci_subdevice = 0x81bb,
 	  .config = ALC260_BASIC }, /* Sony VAIO */
+	{ .pci_subvendor = 0x152d, .pci_subdevice = 0x0729,
+	  .config = ALC260_BASIC }, /* CTL Travel Master U553W */
 	{ .modelname = "hp", .config = ALC260_HP },
 	{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP },
 	{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3011, .config = ALC260_HP },

--

[patch 24/26] hostap: Fix EAPOL frame encryption

[gregkh]

[-- Attachment #1: hostap_fix_eapol_crypt.patch --]
[-- Type: text/plain, Size: 1002 bytes --]

Fixed encrypted of EAPOL frames from wlan#ap interface (hostapd). This
was broken when moving to use new frame control field defines in
net/ieee80211.h. hostapd uses Protected flag, not protocol version
(which was cleared in this function anyway). This fixes WPA group key
handshake and re-authentication.
http://hostap.epitest.fi/bugz/show_bug.cgi?id=126

Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>


---
 drivers/net/wireless/hostap/hostap_80211_tx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.1.orig/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ linux-2.6.16.1/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -469,7 +469,7 @@ int hostap_master_start_xmit(struct sk_b
 	}
 
 	if (local->ieee_802_1x && meta->ethertype == ETH_P_PAE && tx.crypt &&
-	    !(fc & IEEE80211_FCTL_VERS)) {
+	    !(fc & IEEE80211_FCTL_PROTECTED)) {
 		no_encrypt = 1;
 		PDEBUG(DEBUG_EXTRA2, "%s: TX: IEEE 802.1X - passing "
 		       "unencrypted EAPOL frame\n", dev->name);

--

[patch 25/26] knfsd: Correct reserved reply space for read requests.

[gregkh]

[-- Attachment #1: knfsd-correct-reserved-reply-space-for-read-requests.patch --]
[-- Type: text/plain, Size: 2796 bytes --]

From: NeilBrown <neilb@suse.de>


NFSd makes sure there is enough space to hold the maximum possible reply
before accepting a request.  The units for this maximum is (4byte) words. 
However in three places, particularly for read request, the number given is
a number of bytes.

This means too much space is reserved which is slightly wasteful.

This is the sort of patch that could uncover a deeper bug, and it is not
critical, so it would be best for it to spend a while in -mm before going
in to mainline.

(akpm: target 2.6.17-rc2, 2.6.16.3 (approx))

Discovered-by: "Eivind  Sarto" <ivan@kasenna.com>
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>

---
 fs/nfsd/nfs3proc.c |    2 +-
 fs/nfsd/nfs4proc.c |    2 +-
 fs/nfsd/nfsproc.c  |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.16.1.orig/fs/nfsd/nfs3proc.c
+++ linux-2.6.16.1/fs/nfsd/nfs3proc.c
@@ -682,7 +682,7 @@ static struct svc_procedure		nfsd_proced
   PROC(lookup,	 dirop,		dirop,		fhandle2, RC_NOCACHE, ST+FH+pAT+pAT),
   PROC(access,	 access,	access,		fhandle,  RC_NOCACHE, ST+pAT+1),
   PROC(readlink, readlink,	readlink,	fhandle,  RC_NOCACHE, ST+pAT+1+NFS3_MAXPATHLEN/4),
-  PROC(read,	 read,		read,		fhandle,  RC_NOCACHE, ST+pAT+4+NFSSVC_MAXBLKSIZE),
+  PROC(read,	 read,		read,		fhandle,  RC_NOCACHE, ST+pAT+4+NFSSVC_MAXBLKSIZE/4),
   PROC(write,	 write,		write,		fhandle,  RC_REPLBUFF, ST+WC+4),
   PROC(create,	 create,	create,		fhandle2, RC_REPLBUFF, ST+(1+FH+pAT)+WC),
   PROC(mkdir,	 mkdir,		create,		fhandle2, RC_REPLBUFF, ST+(1+FH+pAT)+WC),
--- linux-2.6.16.1.orig/fs/nfsd/nfs4proc.c
+++ linux-2.6.16.1/fs/nfsd/nfs4proc.c
@@ -975,7 +975,7 @@ struct nfsd4_voidargs { int dummy; };
  */
 static struct svc_procedure		nfsd_procedures4[2] = {
   PROC(null,	 void,		void,		void,	  RC_NOCACHE, 1),
-  PROC(compound, compound,	compound,	compound, RC_NOCACHE, NFSD_BUFSIZE)
+  PROC(compound, compound,	compound,	compound, RC_NOCACHE, NFSD_BUFSIZE/4)
 };
 
 struct svc_version	nfsd_version4 = {
--- linux-2.6.16.1.orig/fs/nfsd/nfsproc.c
+++ linux-2.6.16.1/fs/nfsd/nfsproc.c
@@ -553,7 +553,7 @@ static struct svc_procedure		nfsd_proced
   PROC(none,	 void,		void,		none,		RC_NOCACHE, ST),
   PROC(lookup,	 diropargs,	diropres,	fhandle,	RC_NOCACHE, ST+FH+AT),
   PROC(readlink, readlinkargs,	readlinkres,	none,		RC_NOCACHE, ST+1+NFS_MAXPATHLEN/4),
-  PROC(read,	 readargs,	readres,	fhandle,	RC_NOCACHE, ST+AT+1+NFSSVC_MAXBLKSIZE),
+  PROC(read,	 readargs,	readres,	fhandle,	RC_NOCACHE, ST+AT+1+NFSSVC_MAXBLKSIZE/4),
   PROC(none,	 void,		void,		none,		RC_NOCACHE, ST),
   PROC(write,	 writeargs,	attrstat,	fhandle,	RC_REPLBUFF, ST+AT),
   PROC(create,	 createargs,	diropres,	fhandle,	RC_REPLBUFF, ST+FH+AT),

--

[patch 26/26] kdump proc vmcore size oveflow fix

[gregkh]

[-- Attachment #1: kdump-proc-vmcore-size-oveflow-fix.patch --]
[-- Type: text/plain, Size: 1119 bytes --]

From: Vivek Goyal <vgoyal@in.ibm.com>

A couple of /proc/vmcore data structures overflow with 32bit systems having
memory more than 4G.  This patch fixes those.

Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 fs/proc/vmcore.c        |    4 ++--
 include/linux/proc_fs.h |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.16.1.orig/fs/proc/vmcore.c
+++ linux-2.6.16.1/fs/proc/vmcore.c
@@ -103,8 +103,8 @@ static ssize_t read_vmcore(struct file *
 				size_t buflen, loff_t *fpos)
 {
 	ssize_t acc = 0, tmp;
-	size_t tsz, nr_bytes;
-	u64 start;
+	size_t tsz;
+	u64 start, nr_bytes;
 	struct vmcore *curr_m = NULL;
 
 	if (buflen == 0 || *fpos >= vmcore_size)
--- linux-2.6.16.1.orig/include/linux/proc_fs.h
+++ linux-2.6.16.1/include/linux/proc_fs.h
@@ -78,7 +78,7 @@ struct kcore_list {
 struct vmcore {
 	struct list_head list;
 	unsigned long long paddr;
-	unsigned long size;
+	unsigned long long size;
 	loff_t offset;
 };
 

--