[00/07] -stable review

[00/07] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.12.2 release.  There
are 7 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 Wed, Jun 29, 23:00 UTC.  Anything received after
that time, might be too late.

thanks,

the -stable release team (i.e. the ones wearing the joker hat in the corner...)

[01/07] Fix typo in drivers/pci/pci-driver.c

[Chris Wright]

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

------------------

The git commit 794f5bfa77955c4455f6d72d8b0e2bee25f1ff0c
accidentally suffers from a previous typo in that file
(',' instead of ';' in end of line). Patch included.

Signed-off-by: Mika Kukkonen <mikukkon@iki.fi>
Signed-off-by: Chris Wright <chrisw@osdl.org>

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c	2005-06-18 22:05:42.642463416 +0300
+++ linux-2.6/drivers/pci/pci-driver.c	2005-06-18 22:10:37.486761280 +0300
@@ -396,7 +396,7 @@
 	/* FIXME, once all of the existing PCI drivers have been fixed to set
 	 * the pci shutdown function, this test can go away. */
 	if (!drv->driver.shutdown)
-		drv->driver.shutdown = pci_device_shutdown,
+		drv->driver.shutdown = pci_device_shutdown;
 	drv->driver.owner = drv->owner;
 	drv->driver.kobj.ktype = &pci_driver_kobj_type;
 	pci_init_dynids(&drv->dynids);

[02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Chris Wright]

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

------------------


Return to previous held-logic of calling scsi_add_host() only
after the board has been completely initialized.  Also return
pci_*() error-codes during probe failure paths.

This also corrects an issue where only lun 0 is being scanned for
a given port.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>

---
commit a1541d5af66d02426655b1498f814c52347dd7d3
tree 02d041e54ebaec744d30ebf6012e305b9673bec0
parent 27198d855abbfc82df69e81b6c8d2f333580114c
author Andrew Vasquez <andrew.vasquez@qlogic.com> Thu, 09 Jun 2005 17:21:28 -0700
committer James Bottomley <jejb@mulgrave.(none)> Sat, 11 Jun 2005 13:06:22 -0500

 drivers/scsi/qla2xxx/qla_os.c |   55 +++++++++++++++++++++--------------------
 1 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1150,7 +1150,7 @@ iospace_error_exit:
  */
 int qla2x00_probe_one(struct pci_dev *pdev, struct qla_board_info *brd_info)
 {
-	int	ret;
+	int	ret = -ENODEV;
 	device_reg_t __iomem *reg;
 	struct Scsi_Host *host;
 	scsi_qla_host_t *ha;
@@ -1161,7 +1161,7 @@ int qla2x00_probe_one(struct pci_dev *pd
 	fc_port_t *fcport;
 
 	if (pci_enable_device(pdev))
-		return -1;
+		goto probe_out;
 
 	host = scsi_host_alloc(&qla2x00_driver_template,
 	    sizeof(scsi_qla_host_t));
@@ -1183,9 +1183,8 @@ int qla2x00_probe_one(struct pci_dev *pd
 
 	/* Configure PCI I/O space */
 	ret = qla2x00_iospace_config(ha);
-	if (ret != 0) {
-		goto probe_alloc_failed;
-	}
+	if (ret)
+		goto probe_failed;
 
 	/* Sanitize the information from PCI BIOS. */
 	host->irq = pdev->irq;
@@ -1258,23 +1257,10 @@ int qla2x00_probe_one(struct pci_dev *pd
 		qla_printk(KERN_WARNING, ha,
 		    "[ERROR] Failed to allocate memory for adapter\n");
 
-		goto probe_alloc_failed;
+		ret = -ENOMEM;
+		goto probe_failed;
 	}
 
-	pci_set_drvdata(pdev, ha);
-	host->this_id = 255;
-	host->cmd_per_lun = 3;
-	host->unique_id = ha->instance;
-	host->max_cmd_len = MAX_CMDSZ;
-	host->max_channel = ha->ports - 1;
-	host->max_id = ha->max_targets;
-	host->max_lun = ha->max_luns;
-	host->transportt = qla2xxx_transport_template;
-	if (scsi_add_host(host, &pdev->dev))
-		goto probe_alloc_failed;
-
-	qla2x00_alloc_sysfs_attr(ha);
-
 	if (qla2x00_initialize_adapter(ha) &&
 	    !(ha->device_flags & DFLG_NO_CABLE)) {
 
@@ -1285,11 +1271,10 @@ int qla2x00_probe_one(struct pci_dev *pd
 		    "Adapter flags %x.\n",
 		    ha->host_no, ha->device_flags));
 
+		ret = -ENODEV;
 		goto probe_failed;
 	}
 
-	qla2x00_init_host_attr(ha);
-
 	/*
 	 * Startup the kernel thread for this host adapter
 	 */
@@ -1299,17 +1284,26 @@ int qla2x00_probe_one(struct pci_dev *pd
 		qla_printk(KERN_WARNING, ha,
 		    "Unable to start DPC thread!\n");
 
+		ret = -ENODEV;
 		goto probe_failed;
 	}
 	wait_for_completion(&ha->dpc_inited);
 
+	host->this_id = 255;
+	host->cmd_per_lun = 3;
+	host->unique_id = ha->instance;
+	host->max_cmd_len = MAX_CMDSZ;
+	host->max_channel = ha->ports - 1;
+	host->max_lun = MAX_LUNS;
+	host->transportt = qla2xxx_transport_template;
+
 	if (IS_QLA2100(ha) || IS_QLA2200(ha))
 		ret = request_irq(host->irq, qla2100_intr_handler,
 		    SA_INTERRUPT|SA_SHIRQ, ha->brd_info->drv_name, ha);
 	else
 		ret = request_irq(host->irq, qla2300_intr_handler,
 		    SA_INTERRUPT|SA_SHIRQ, ha->brd_info->drv_name, ha);
-	if (ret != 0) {
+	if (ret) {
 		qla_printk(KERN_WARNING, ha,
 		    "Failed to reserve interrupt %d already in use.\n",
 		    host->irq);
@@ -1363,9 +1357,18 @@ int qla2x00_probe_one(struct pci_dev *pd
 		msleep(10);
 	}
 
+	pci_set_drvdata(pdev, ha);
 	ha->flags.init_done = 1;
 	num_hosts++;
 
+	ret = scsi_add_host(host, &pdev->dev);
+	if (ret)
+		goto probe_failed;
+
+	qla2x00_alloc_sysfs_attr(ha);
+
+	qla2x00_init_host_attr(ha);
+
 	qla_printk(KERN_INFO, ha, "\n"
 	    " QLogic Fibre Channel HBA Driver: %s\n"
 	    "  QLogic %s - %s\n"
@@ -1384,9 +1387,6 @@ int qla2x00_probe_one(struct pci_dev *pd
 probe_failed:
 	fc_remove_host(ha->host);
 
-	scsi_remove_host(host);
-
-probe_alloc_failed:
 	qla2x00_free_device(ha);
 
 	scsi_host_put(host);
@@ -1394,7 +1394,8 @@ probe_alloc_failed:
 probe_disable_device:
 	pci_disable_device(pdev);
 
-	return -1;
+probe_out:
+	return ret;
 }
 EXPORT_SYMBOL_GPL(qla2x00_probe_one);
 

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Jean Delvare]

Hi Chris, all,

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

I have. This one patch is rather big and parts of it don't seem to
belong to -stable. Can't it be simplified? More below.

> Return to previous held-logic of calling scsi_add_host() only
> after the board has been completely initialized.

What real bug is it supposed to fix? (I guess some, but this leading
comment should give the datails.)

> Also return pci_*() error-codes during probe failure paths.

How does this belong to stable please? I don't see this fixing any
critical bug.

> This also corrects an issue where only lun 0 is being scanned for
> a given port.

This OTOH is probably OK.

> -	if (ret != 0) {
> -		goto probe_alloc_failed;
> -	}
> +	if (ret)
> +		goto probe_failed;

This change can be made smaller.

> -	if (ret != 0) {
> +	if (ret) {

This aint -stable material.

Thanks,
-- 
Jean Delvare

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Andrew Morton]

Jean Delvare <khali@linux-fr.org> wrote:
>
> Hi Chris, all,
> 
> > -stable review patch.  If anyone has any objections, please let us
> > know.
> 
> I have. This one patch is rather big and parts of it don't seem to
> belong to -stable. Can't it be simplified? More below.

The threshold for "what belongs in -stable" is a) set too high and b)
over-zealously enforced.

> > Return to previous held-logic of calling scsi_add_host() only
> > after the board has been completely initialized.
> 
> What real bug is it supposed to fix? (I guess some, but this leading
> comment should give the datails.)

If that's what was in the patch which went into 2.6.13 then we should be OK
with a full backport.  If the person who originally raised that patch put
unrelated things into a single patch then that's where the problem started.

Bear in mind that there is also risk in only part-applying a patch.

> > Also return pci_*() error-codes during probe failure paths.
> 
> How does this belong to stable please? I don't see this fixing any
> critical bug.

But it's obviously safe.

> > -	if (ret != 0) {
> > +	if (ret) {
> 
> This aint -stable material.

But it's obviously safe.  Let's use our brains on these patches and not
become beholden to doctrine, OK?

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Chris Wright]

* Andrew Morton (akpm@osdl.org) wrote:
> The threshold for "what belongs in -stable" is a) set too high and b)
> over-zealously enforced.

Do you have things you'd like to see in -stable that didn't make the
cut?

> > > Return to previous held-logic of calling scsi_add_host() only
> > > after the board has been completely initialized.
> > 
> > What real bug is it supposed to fix? (I guess some, but this leading
> > comment should give the datails.)
> 
> If that's what was in the patch which went into 2.6.13 then we should be OK
> with a full backport.  If the person who originally raised that patch put
> unrelated things into a single patch then that's where the problem started.

Agreed.

> Bear in mind that there is also risk in only part-applying a patch.

Yup, if it's only part of the patch, it needs to be re-tested to be sure
something important wasn't dropped in the chop up.

> > > Also return pci_*() error-codes during probe failure paths.
> > 
> > How does this belong to stable please? I don't see this fixing any
> > critical bug.
> 
> But it's obviously safe.
> 
> > > -	if (ret != 0) {
> > > +	if (ret) {
> > 
> > This aint -stable material.
> 
> But it's obviously safe.  Let's use our brains on these patches and not
> become beholden to doctrine, OK?

I agree.  The real fix only is 100% preferred, but not at the risk of
a patch that's less stable.  We've certainly asked for that as the rule
of thumb, but it is just that...a rule of thumb.

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Andrew Morton]

Chris Wright <chrisw@osdl.org> wrote:
>
> * Andrew Morton (akpm@osdl.org) wrote:
> > The threshold for "what belongs in -stable" is a) set too high and b)
> > over-zealously enforced.
> 
> Do you have things you'd like to see in -stable that didn't make the
> cut?

Nope - I'm just making vague unsubstantiated accusations ;)

<general handwaving> Given the number of bugs which are present in each
release (as evidenced by the amount of stuff we're fixing), there's a hell
of a lot of material which _could_ go into -stable.

I suspect some things are slipping through.  It's a big job though.

I didn't help much in 2.6.11.x and am paying more attention this time,
mainly by being more vigilant looking at the commits list.

2.6.11.x was the first time and things are still getting underway.

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Chris Wright]

* Andrew Morton (akpm@osdl.org) wrote:
> Nope - I'm just making vague unsubstantiated accusations ;)

Heh ;-)

> <general handwaving> Given the number of bugs which are present in each
> release (as evidenced by the amount of stuff we're fixing), there's a hell
> of a lot of material which _could_ go into -stable.
> 
> I suspect some things are slipping through.  It's a big job though.
> 
> I didn't help much in 2.6.11.x and am paying more attention this time,
> mainly by being more vigilant looking at the commits list.

It would really help if patch author (or committer) thought to send it on,
distributing the load...

Re: [stable] Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Greg KH]

On Tue, Jun 28, 2005 at 03:20:37PM -0700, Andrew Morton wrote:
> Jean Delvare <khali@linux-fr.org> wrote:
> >
> > Hi Chris, all,
> > 
> > > -stable review patch.  If anyone has any objections, please let us
> > > know.
> > 
> > I have. This one patch is rather big and parts of it don't seem to
> > belong to -stable. Can't it be simplified? More below.
> 
> The threshold for "what belongs in -stable" is a) set too high and b)
> over-zealously enforced.

Hm, are there patches that have been submitted to stable@ that have been
rejected for "over-zealous" enforcement?  I can't think of any ones
recently.

> > > Return to previous held-logic of calling scsi_add_host() only
> > > after the board has been completely initialized.
> > 
> > What real bug is it supposed to fix? (I guess some, but this leading
> > comment should give the datails.)
> 
> If that's what was in the patch which went into 2.6.13 then we should be OK
> with a full backport.  If the person who originally raised that patch put
> unrelated things into a single patch then that's where the problem started.
> 
> Bear in mind that there is also risk in only part-applying a patch.

I agree.  That's why I don't have a problem with this patch, it's better
to stay inline with upstream (meaning 2.6.12-git) than diverging.  Makes
my life easier when I try to figure out if stuff needs to be merged to
Linus :)

thanks,

greg k-h

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Jean Delvare]

Hi Andrew,

> If the person who originally raised that patch put unrelated things
> into a single patch then that's where the problem started.

Agreed.

> Bear in mind that there is also risk in only part-applying a patch.

If applying only a part of a given patch doesn't sound safe, then I
would question the supposed obvious correctness of this patch in the
first place.

Some times ago, Alan stated he liked -stable because "its small enough
that most of the add on patches people use aren't breaking against it"
[1]. I found this a sound statement, but if we now accept non-minimum
changes, this won't be true any longer (or at least this will tend to
become less true).

> > This aint -stable material.
> 
> But it's obviously safe.  Let's use our brains on these patches and
> not become beholden to doctrine, OK?

Why did we write down and discuss rules for -stable in the first place
then [2]? Of the 9 rules Greg first listed as conditions for a patch to
be accepted in -stable, this patch breaks 4 (it is bigger than 100
lines, if fixes more than one thing, including one that doesn't bother
people as far as I can see, and it has trivial fixes in it.) So I don't
think I am actually splitting hair as you seemed to suggest. I know some
of these rules were slightly reworded afterwards, but still.

I reviewed the latest stable series of patches with these rules in mind,
trying to help. If the rules have since changed - and it seems they did,
then instead of helping, I have been wasting your time, and mine. Where
were the new rules discussed? We better have a web page summarizing the
current rules for -stable if we want submitters and reviewers to do the
right thing.

Thanks.

[1] http://kerneltraffic.org/kernel-traffic/kt20050612_315.html#5
[2] http://kerneltraffic.org/kernel-traffic/kt20050403_303.html#9

-- 
Jean Delvare

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[James Bottomley]

On Wed, 2005-06-29 at 10:08 +0200, Jean Delvare wrote:
> this patch breaks 4 (it is bigger than 100
> lines, if fixes more than one thing, including one that doesn't bother
> people as far as I can see, and it has trivial fixes in it.) So I don't
> think I am actually splitting hair as you seemed to suggest. I know some
> of these rules were slightly reworded afterwards, but still.

Not according to my diffstat, it doesn't:

qla_os.c |   55 ++++++++++++++++++++++++++++---------------------------
 1 files changed, 28 insertions(+), 27 deletions(-)

The basic rationale for this one is that it corrects a late spotted
error in a driver update that went into 2.6.12.  Without this, the
qla2xxx driver crashes for numerous people on loading (linux-scsi has
all the bug reports).  Since it's clearly a bug fix correcting a major
feature failure, that qualifies it for -stable.  The two code cleanup
corrections look trivial and not worth delaying this over (also, as has
been pointed out, they make it identical with the patch applied upstream
of 2.6.12, so there wouldn't be any merge issues).

James

Re: [02/07] [SCSI] qla2xxx: Pull-down scsi-host-addition to follow board initialization.

[Jean Delvare]

Hi James,

> > this patch breaks 4 (it is bigger than 100 lines, (...)
>
> Not according to my diffstat, it doesn't:
> 
> qla_os.c |   55
> ++++++++++++++++++++++++++++---------------------------
>  1 files changed, 28 insertions(+), 27 deletions(-)

The original rule was including the context, diffstat doesn't. This
patch was 136 lines long including the context.

Anyway, it doesn't seem to matter anymore.

-- 
Jean Delvare

[03/07] fix remap_pte_range BUG

[Chris Wright]

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

------------------

Out-of-tree user of remap_pfn_range hit kernel BUG at mm/memory.c:1112!
It passes an unrounded size to remap_pfn_range, which was okay before
2.6.12, but misses remap_pte_range's new end condition.  An audit of
all the other ptwalks confirms that this is the only one so exposed.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>

--- 2.6.12/mm/memory.c	2005-06-17 20:48:29.000000000 +0100
+++ linux/mm/memory.c	2005-06-21 20:31:42.000000000 +0100
@@ -1164,7 +1164,7 @@ int remap_pfn_range(struct vm_area_struc
 {
 	pgd_t *pgd;
 	unsigned long next;
-	unsigned long end = addr + size;
+	unsigned long end = addr + PAGE_ALIGN(size);
 	struct mm_struct *mm = vma->vm_mm;
 	int err;
 

[04/07] e1000: fix spinlock bug

[Chris Wright]

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

------------------


This patch fixes an obvious and nasty bug where we could exit the transmit
routine while holding tx_lock.

Signed-off-by:  Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by:  Chris Wright <chrisw@osdl.org>
---


diff -urpN -X dontdiff linux-2.6.12-clean/drivers/net/e1000/e1000_main.c linux-2.6.12/drivers/net/e1000/e1000_main.c
--- linux-2.6.12-clean/drivers/net/e1000/e1000_main.c	2005-06-17 12:48:29.000000000 -0700
+++ linux-2.6.12/drivers/net/e1000/e1000_main.c	2005-06-21 10:42:29.000000000 -0700
@@ -2307,6 +2307,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
 	tso = e1000_tso(adapter, skb);
 	if (tso < 0) {
 		dev_kfree_skb_any(skb);
+		spin_unlock_irqrestore(&adapter->tx_lock, flags);
 		return NETDEV_TX_OK;
 	}

[05/07] Add "memory" clobbers to the x86 inline asm of strncmp and friends

[Chris Wright]

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

------------------


From: Linus Torvalds <torvalds@ppc970.osdl.org>

Add "memory" clobbers to the x86 inline asm of strncmp and friends

They don't actually clobber memory, but gcc doesn't even know they
_read_ memory, so can apparently re-order memory accesses around them.

Which obviously does the wrong thing if the memory access happens to
change the memory that the compare function is accessing..

Verified to fix a strange boot problem by Jens Axboe.

Signed-off-by: Chris Wright <chrisw@osdl.org>
---

 include/asm-i386/string.h |   32 ++++++++++++++++++++++----------
 1 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/include/asm-i386/string.h b/include/asm-i386/string.h
--- a/include/asm-i386/string.h
+++ b/include/asm-i386/string.h
@@ -116,7 +116,8 @@ __asm__ __volatile__(
 	"orb $1,%%al\n"
 	"3:"
 	:"=a" (__res), "=&S" (d0), "=&D" (d1)
-		     :"1" (cs),"2" (ct));
+	:"1" (cs),"2" (ct)
+	:"memory");
 return __res;
 }
 
@@ -138,8 +139,9 @@ __asm__ __volatile__(
 	"3:\tsbbl %%eax,%%eax\n\t"
 	"orb $1,%%al\n"
 	"4:"
-		     :"=a" (__res), "=&S" (d0), "=&D" (d1), "=&c" (d2)
-		     :"1" (cs),"2" (ct),"3" (count));
+	:"=a" (__res), "=&S" (d0), "=&D" (d1), "=&c" (d2)
+	:"1" (cs),"2" (ct),"3" (count)
+	:"memory");
 return __res;
 }
 
@@ -158,7 +160,9 @@ __asm__ __volatile__(
 	"movl $1,%1\n"
 	"2:\tmovl %1,%0\n\t"
 	"decl %0"
-	:"=a" (__res), "=&S" (d0) : "1" (s),"0" (c));
+	:"=a" (__res), "=&S" (d0)
+	:"1" (s),"0" (c)
+	:"memory");
 return __res;
 }
 
@@ -175,7 +179,9 @@ __asm__ __volatile__(
 	"leal -1(%%esi),%0\n"
 	"2:\ttestb %%al,%%al\n\t"
 	"jne 1b"
-	:"=g" (__res), "=&S" (d0), "=&a" (d1) :"0" (0),"1" (s),"2" (c));
+	:"=g" (__res), "=&S" (d0), "=&a" (d1)
+	:"0" (0),"1" (s),"2" (c)
+	:"memory");
 return __res;
 }
 
@@ -189,7 +195,9 @@ __asm__ __volatile__(
 	"scasb\n\t"
 	"notl %0\n\t"
 	"decl %0"
-	:"=c" (__res), "=&D" (d0) :"1" (s),"a" (0), "0" (0xffffffffu));
+	:"=c" (__res), "=&D" (d0)
+	:"1" (s),"a" (0), "0" (0xffffffffu)
+	:"memory");
 return __res;
 }
 
@@ -333,7 +341,9 @@ __asm__ __volatile__(
 	"je 1f\n\t"
 	"movl $1,%0\n"
 	"1:\tdecl %0"
-	:"=D" (__res), "=&c" (d0) : "a" (c),"0" (cs),"1" (count));
+	:"=D" (__res), "=&c" (d0)
+	:"a" (c),"0" (cs),"1" (count)
+	:"memory");
 return __res;
 }
 
@@ -369,7 +379,7 @@ __asm__ __volatile__(
 	"je 2f\n\t"
 	"stosb\n"
 	"2:"
-	: "=&c" (d0), "=&D" (d1)
+	:"=&c" (d0), "=&D" (d1)
 	:"a" (c), "q" (count), "0" (count/4), "1" ((long) s)
 	:"memory");
 return (s);	
@@ -392,7 +402,8 @@ __asm__ __volatile__(
 	"jne 1b\n"
 	"3:\tsubl %2,%0"
 	:"=a" (__res), "=&d" (d0)
-	:"c" (s),"1" (count));
+	:"c" (s),"1" (count)
+	:"memory");
 return __res;
 }
 /* end of additional stuff */
@@ -473,7 +484,8 @@ static inline void * memscan(void * addr
 		"dec %%edi\n"
 		"1:"
 		: "=D" (addr), "=c" (size)
-		: "0" (addr), "1" (size), "a" (c));
+		: "0" (addr), "1" (size), "a" (c)
+		: "memory");
 	return addr;
 }
 

Re: [05/07] Add "memory" clobbers to the x86 inline asm of strncmp and friends

[Jean Delvare]

Hi Chris,

> @@ -138,8 +139,9 @@ __asm__ __volatile__(
>  	"3:\tsbbl %%eax,%%eax\n\t"
>  	"orb $1,%%al\n"
>  	"4:"
> -		     :"=a" (__res), "=&S" (d0), "=&D" (d1), "=&c" (d2)
> -		     :"1" (cs),"2" (ct),"3" (count));
> +	:"=a" (__res), "=&S" (d0), "=&D" (d1), "=&c" (d2)
> +	:"1" (cs),"2" (ct),"3" (count)
> +	:"memory");
>  return __res;
>  }

Could be made shorter. As far as I remember, indentation fixes are not
-stable material.

> @@ -369,7 +379,7 @@ __asm__ __volatile__(
>  	"je 2f\n\t"
>  	"stosb\n"
>  	"2:"
> -	: "=&c" (d0), "=&D" (d1)
> +	:"=&c" (d0), "=&D" (d1)
>  	:"a" (c), "q" (count), "0" (count/4), "1" ((long) s)
>  	:"memory");
>  return (s);	

Doesn't belong there, unless -stable rules have changed.

Thanks,
-- 
Jean Delvare

[06/07] ACPI: Make sure we call acpi_register_gsi() even for default PCI interrupt assignment

[Chris Wright]

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

------------------


From: Linus Torvalds <torvalds@ppc970.osdl.org>

ACPI: Make sure we call acpi_register_gsi() even for default PCI interrupt assignment

That's the part that keeps track of the ELCR register, and we want to
make sure that the PCI interrupts are properly marked level/low.

Signed-off-by: Chris Wright <chrisw@osdl.org>
---

 drivers/acpi/pci_irq.c |    1 +
 1 files changed, 1 insertion(+)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -435,6 +435,7 @@ acpi_pci_irq_enable (
 		/* Interrupt Line values above 0xF are forbidden */
 		if (dev->irq >= 0 && (dev->irq <= 0xF)) {
 			printk(" - using IRQ %d\n", dev->irq);
+			acpi_register_gsi(dev->irq, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
 			return_VALUE(0);
 		}
 		else {

[07/07] [NETLINK]: Fix two socket hashing bugs.

[Chris Wright]

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

------------------


1) netlink_release() should only decrement the hash entry
   count if the socket was actually hashed.

   This was causing hash->entries to underflow, which
   resulting in all kinds of troubles.

   On 64-bit systems, this would cause the following
   conditional to erroneously trigger:

	err = -ENOMEM;
	if (BITS_PER_LONG > 32 && unlikely(hash->entries >= UINT_MAX))
		goto err;

2) netlink_autobind() needs to propagate the error return from
   netlink_insert().  Otherwise, callers will not see the error
   as they should and thus try to operate on a socket with a zero pid,
   which is very bad.

   However, it should not propagate -EBUSY.  If two threads race
   to autobind the socket, that is fine.  This is consistent with the
   autobind behavior in other protocols.

   So bug #1 above, combined with this one, resulted in hangs
   on netlink_sendmsg() calls to the rtnetlink socket.  We'd try
   to do the user sendmsg() with the socket's pid set to zero,
   later we do a socket lookup using that pid (via the value we
   stashed away in NETLINK_CB(skb).pid), but that won't give us the
   user socket, it will give us the rtnetlink socket.  So when we
   try to wake up the receive queue, we dive back into rtnetlink_rcv()
   which tries to recursively take the rtnetlink semaphore.

Thanks to Jakub Jelink for providing backtraces.  Also, thanks to
Herbert Xu for supplying debugging patches to help track this down,
and also finding a mistake in an earlier version of this fix.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---

--- 1/net/netlink/af_netlink.c.~1~	2005-06-26 15:30:20.000000000 -0700
+++ 2/net/netlink/af_netlink.c	2005-06-26 15:30:46.000000000 -0700
@@ -315,8 +315,8 @@
 static void netlink_remove(struct sock *sk)
 {
 	netlink_table_grab();
-	nl_table[sk->sk_protocol].hash.entries--;
-	sk_del_node_init(sk);
+	if (sk_del_node_init(sk))
+		nl_table[sk->sk_protocol].hash.entries--;
 	if (nlk_sk(sk)->groups)
 		__sk_del_bind_node(sk);
 	netlink_table_ungrab();
@@ -429,7 +429,12 @@
 	err = netlink_insert(sk, pid);
 	if (err == -EADDRINUSE)
 		goto retry;
-	return 0;
+
+	/* If 2 threads race to autobind, that is fine.  */
+	if (err == -EBUSY)
+		err = 0;
+
+	return err;
 }
 
 static inline int netlink_capable(struct socket *sock, unsigned int flag) 

Re: [00/07] -stable review

[Jim MacBaine]

On 6/28/05, Chris Wright <chrisw@osdl.org> wrote:

> Responses should be made by Wed, Jun 29, 23:00 UTC.  Anything received after
> that time, might be too late.

Will the fix for the iptables physdev match go into -stable?

I'd regard the aesthetic objections as secondary in a stable kernel
series.  If physdev match stays in the kernel, the fix should IMHO go
into -stable.

Regards,
Jim

Re: [stable] Re: [00/07] -stable review

[Chris Wright]

* Jim MacBaine (jmacbaine@gmail.com) wrote:
> On 6/28/05, Chris Wright <chrisw@osdl.org> wrote:
> 
> > Responses should be made by Wed, Jun 29, 23:00 UTC.  Anything received after
> > that time, might be too late.
> 
> Will the fix for the iptables physdev match go into -stable?

I assume you're referring to this fix:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111936734211687&w=2

If so, I expect it will.  Needs to hit mainline first and get pushed over
to -stable.

Re: [stable] Re: [00/07] -stable review

[Jim MacBaine]

On 6/28/05, Chris Wright <chrisw@osdl.org> wrote:

> I assume you're referring to this fix:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111936734211687&w=2
> 
> If so, I expect it will.  Needs to hit mainline first and get pushed over
> to -stable.
 
That's the one I'm referring to.  This patch works for me on 2.6.12.1.

Regards,
Jim

Re: [stable] Re: [00/07] -stable review

[Chris Wright]

* Jim MacBaine (jmacbaine@gmail.com) wrote:
> On 6/28/05, Chris Wright <chrisw@osdl.org> wrote:
> 
> > I assume you're referring to this fix:
> > 
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=111936734211687&w=2
> > 
> > If so, I expect it will.  Needs to hit mainline first and get pushed over
> > to -stable.
>  
> That's the one I'm referring to.  This patch works for me on 2.6.12.1.

Great, thanks.  As soon as net guys send it over we'll queue it up.

thanks,
-chris

Re: [00/07] -stable review

[David S. Miller]

From: Jim MacBaine <jmacbaine@gmail.com>
Date: Tue, 28 Jun 2005 14:10:18 +0200

> Will the fix for the iptables physdev match go into -stable?

I will submit it to stable@kernel.org, please be patient.

[00/07] -stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.11.8 release.  There
are 7 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 Bcc: line.
If you wish to be a reviewer, please email stable@linux.com to add your name to
the list.  If you want to be off the reviewer list, also email us.

Responses should be made by Friday, Apr 29 17:00 UTC.  Anything received after
that time, might be too late.

thanks,

the -stable release team

Re: [00/07] -stable review

[Chris Wright]

* Greg KH (gregkh@suse.de) wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release.  There
> are 7 patches in this series, all will be posted as a response to this one.

There are actually 10.  We missed 3 patches from DaveM (100% my fault,
somehow I messed up pushing them into the queue 10 days ago).  Those three
will follow-up shortly as 8/7, 9/7, and 10/7.  Sorry for the mix up.

thanks,
-chris

Re: [00/07] -stable review

[Nick Piggin]

Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.11.8 release.  There
> are 7 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 Bcc: line.
> If you wish to be a reviewer, please email stable@linux.com to add your name to
> the list.  If you want to be off the reviewer list, also email us.
> 
> Responses should be made by Friday, Apr 29 17:00 UTC.  Anything received after
> that time, might be too late.
> 
> thanks,
> 
> the -stable release team
> 

Wanna take some buffer fixes?

-- 
SUSE Labs, Novell Inc.

Re: [00/07] -stable review

[Chris Wright]

* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> Wanna take some buffer fixes?

Do they meet the -stable criteria?  If so, please send 'em over.

thanks,
-chris

Re: [00/07] -stable review

[Nick Piggin]

Chris Wright wrote:
> * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> 
>>Wanna take some buffer fixes?
> 
> 
> Do they meet the -stable criteria?  If so, please send 'em over.
> 

Where do I find the -stable criteria?

They are a little bit tested, reviewed by Andrew Morton.

To me they seem pretty important. But maybe they should wait until
they have at least seen an -mm release.

The first fix I think closes potential access to stale kernel memory
if you care about that sort of thing.

-- 
SUSE Labs, Novell Inc.

Re: [00/07] -stable review

[Zwane Mwaikambo]

On Wed, 27 Apr 2005, Chris Wright wrote:

> * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> > Wanna take some buffer fixes?
> 
> Do they meet the -stable criteria?  If so, please send 'em over.

Shouldn't they see testing time in a tree first?

Re: [00/07] -stable review

[Nick Piggin]

Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
> 
> 
>>* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
>>
>>>Wanna take some buffer fixes?
>>
>>Do they meet the -stable criteria?  If so, please send 'em over.
> 
> 
> Shouldn't they see testing time in a tree first?
> 

Yes they should.

-- 
SUSE Labs, Novell Inc.

Re: [00/07] -stable review

[Justin M. Forbes]

On Wed, Apr 27, 2005 at 07:51:35PM -0600, Zwane Mwaikambo wrote:
> On Wed, 27 Apr 2005, Chris Wright wrote:
> 
> > * Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> > > Wanna take some buffer fixes?
> > 
> > Do they meet the -stable criteria?  If so, please send 'em over.
> 
> Shouldn't they see testing time in a tree first?

I would say that if they meet the stable criteria, testing time in another
tree is not really necessary.  Stable should be simple bug fixes, easy to
test.  In this case, the fact that Nick seems to think they might need a
run in mm first would tell me that at least some of them probably should
not be in the stable tree at this point.

Justin

Re: [00/07] -stable review

[Gregor Jasny]

Hi Greg, hi Takashi,

I would suggest these two patches for inclusion into the stable tree. They 
both fix a keyboard lockup when unplugging USB audio hardware.

With the first one applied I can plug / unplug my webcam without losing my 
keyboard. I couldn't test the second one, but both patches are in ALSA CVS.

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usbaudio.c?r1=1.119&r2=1.120
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/usb/usx2y/usbusx2y.c?r1=1.9&r2=1.10

Cheers,
Gregor