Skip to contentSkip to conversation

2.6.22-stable review cycle again

PATCH In review Greg KH 6 participants 39 messages Aug 23, 2007 – Aug 31, 2007

Subsystems (16)
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 2.6.22-stable review cycle again

This is the start of the stable review cycle for the 2.6.22.6 release. There are 28 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 [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by August 25 22:00:00 UTC 2007. Anything received after that time might be too late.

thanks,

greg k-h

author
#1 lore raw

PATCH 1/28 ocfs2: Fix bad source start calculation during kernel writes

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

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

From: Mark Fasheh <[email protected]>

[PATCH] ocfs2: Fix bad source start calculation during kernel writes

For in-kernel writes ocfs2_get_write_source() should be starting the buffer at a page boundary as the math in ocfs2_map_and_write_user_data() will pad it back out to the correct write offset. Instead, we were passing the raw offset, which caused ocfs2_map_and_write_user_data() start too far into the buffer, resulting in corruptions from nfs client writes.

---
 fs/ocfs2/file.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/file.c +1 -1
@@ -1353,7 +1353,7 @@ static struct page * ocfs2_get_write_sou
 		else
 			src_page = ERR_PTR(-EFAULT);
 	} else {
-		bp->b_src_buf = buf;
+		bp->b_src_buf = (char *)((unsigned long)buf & PAGE_CACHE_MASK);
 	}
 
 	return src_page;
author
#2 lore raw

PATCH 2/28 NET: Share correct feature code between bridging and bonding

In reply to Greg KH

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

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

[NET]: Share correct feature code between bridging and bonding

http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the bonding driver may produce bogus combinations of the checksum flags and SG/TSO.

For example, if you bond devices with NETIF_F_HW_CSUM and NETIF_F_IP_CSUM you'll end up with a bonding device that has neither flag set. If both have TSO then this produces an illegal combination.

The bridge device on the other hand has the correct code to deal with this.

In fact, the same code can be used for both. So this patch moves that logic into net/core/dev.c and uses it for both bonding and bridging.

In the process I've made small adjustments such as only setting GSO_ROBUST if at least one constituent device supports it.

---
 drivers/net/bonding/bond_main.c |   30 +++++++++---------------------
 include/linux/netdevice.h       |    2 ++
 net/bridge/br_device.c          |    3 ++-
 net/bridge/br_if.c              |   28 ++++------------------------
 net/core/dev.c                  |   38 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+), 46 deletions(-)
drivers/net/bonding/bond_main.c +9 -21
@@ -1233,43 +1233,31 @@ int bond_sethwaddr(struct net_device *bo
 	return 0;
 }
 
-#define BOND_INTERSECT_FEATURES \
-	(NETIF_F_SG | NETIF_F_ALL_CSUM | NETIF_F_TSO | NETIF_F_UFO)
+#define BOND_VLAN_FEATURES \
+	(NETIF_F_VLAN_CHALLENGED | NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_TX | \
+	 NETIF_F_HW_VLAN_FILTER)
 
 /* 
  * Compute the common dev->feature set available to all slaves.  Some
- * feature bits are managed elsewhere, so preserve feature bits set on
- * master device that are not part of the examined set.
+ * feature bits are managed elsewhere, so preserve those feature bits
+ * on the master device.
  */
 static int bond_compute_features(struct bonding *bond)
 {
-	unsigned long features = BOND_INTERSECT_FEATURES;
 	struct slave *slave;
 	struct net_device *bond_dev = bond->dev;
+	unsigned long features = bond_dev->features & ~BOND_VLAN_FEATURES;
 	unsigned short max_hard_header_len = ETH_HLEN;
 	int i;
 
 	bond_for_each_slave(bond, slave, i) {
-		features &= (slave->dev->features & BOND_INTERSECT_FEATURES);
+		features = netdev_compute_features(features,
+						   slave->dev->features);
 		if (slave->dev->hard_header_len > max_hard_header_len)
 			max_hard_header_len = slave->dev->hard_header_len;
 	}
 
-	if ((features & NETIF_F_SG) && 
-	    !(features & NETIF_F_ALL_CSUM))
-		features &= ~NETIF_F_SG;
-
-	/* 
-	 * features will include NETIF_F_TSO (NETIF_F_UFO) iff all 
-	 * slave devices support NETIF_F_TSO (NETIF_F_UFO), which 
-	 * implies that all slaves also support scatter-gather 
-	 * (NETIF_F_SG), which implies that features also includes 
-	 * NETIF_F_SG. So no need to check whether we have an  
-	 * illegal combination of NETIF_F_{TSO,UFO} and 
-	 * !NETIF_F_SG 
-	 */
-
-	features |= (bond_dev->features & ~BOND_INTERSECT_FEATURES);
+	features |= (bond_dev->features & BOND_VLAN_FEATURES);
 	bond_dev->features = features;
 	bond_dev->hard_header_len = max_hard_header_len;
 
include/linux/netdevice.h +2 -0
@@ -1032,6 +1032,8 @@ extern void dev_seq_stop(struct seq_file
 
 extern void linkwatch_run_queue(void);
 
+extern int netdev_compute_features(unsigned long all, unsigned long one);
+
 static inline int net_gso_ok(int features, int gso_type)
 {
 	int feature = gso_type << NETIF_F_GSO_SHIFT;
net/bridge/br_device.c +2 -1
@@ -179,5 +179,6 @@ void br_dev_setup(struct net_device *dev
 	dev->priv_flags = IFF_EBRIDGE;
 
 	dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA |
-			NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_GSO_ROBUST;
+			NETIF_F_GSO_SOFTWARE | NETIF_F_NO_CSUM |
+			NETIF_F_GSO_ROBUST | NETIF_F_LLTX;
 }
net/bridge/br_if.c +4 -24
@@ -360,35 +360,15 @@ int br_min_mtu(const struct net_bridge *
 void br_features_recompute(struct net_bridge *br)
 {
 	struct net_bridge_port *p;
-	unsigned long features, checksum;
+	unsigned long features;
 
-	checksum = br->feature_mask & NETIF_F_ALL_CSUM ? NETIF_F_NO_CSUM : 0;
-	features = br->feature_mask & ~NETIF_F_ALL_CSUM;
+	features = br->feature_mask;
 
 	list_for_each_entry(p, &br->port_list, list) {
-		unsigned long feature = p->dev->features;
-
-		if (checksum & NETIF_F_NO_CSUM && !(feature & NETIF_F_NO_CSUM))
-			checksum ^= NETIF_F_NO_CSUM | NETIF_F_HW_CSUM;
-		if (checksum & NETIF_F_HW_CSUM && !(feature & NETIF_F_HW_CSUM))
-			checksum ^= NETIF_F_HW_CSUM | NETIF_F_IP_CSUM;
-		if (!(feature & NETIF_F_IP_CSUM))
-			checksum = 0;
-
-		if (feature & NETIF_F_GSO)
-			feature |= NETIF_F_GSO_SOFTWARE;
-		feature |= NETIF_F_GSO;
-
-		features &= feature;
+		features = netdev_compute_features(features, p->dev->features);
 	}
 
-	if (!(checksum & NETIF_F_ALL_CSUM))
-		features &= ~NETIF_F_SG;
-	if (!(features & NETIF_F_SG))
-		features &= ~NETIF_F_GSO_MASK;
-
-	br->dev->features = features | checksum | NETIF_F_LLTX |
-			    NETIF_F_GSO_ROBUST;
+	br->dev->features = features;
 }
 
 /* called with RTNL */
net/core/dev.c +38 -0
@@ -3635,6 +3635,44 @@ static int __init netdev_dma_register(vo
 static int __init netdev_dma_register(void) { return -ENODEV; }
 #endif /* CONFIG_NET_DMA */
 
+/**
+ *	netdev_compute_feature - compute conjunction of two feature sets
+ *	@all: first feature set
+ *	@one: second feature set
+ *
+ *	Computes a new feature set after adding a device with feature set
+ *	@one to the master device with current feature set @all.  Returns
+ *	the new feature set.
+ */
+int netdev_compute_features(unsigned long all, unsigned long one)
+{
+	/* if device needs checksumming, downgrade to hw checksumming */
+	if (all & NETIF_F_NO_CSUM && !(one & NETIF_F_NO_CSUM))
+		all ^= NETIF_F_NO_CSUM | NETIF_F_HW_CSUM;
+
+	/* if device can't do all checksum, downgrade to ipv4 */
+	if (all & NETIF_F_HW_CSUM && !(one & NETIF_F_HW_CSUM))
+		all ^= NETIF_F_HW_CSUM | NETIF_F_IP_CSUM;
+
+	if (one & NETIF_F_GSO)
+		one |= NETIF_F_GSO_SOFTWARE;
+	one |= NETIF_F_GSO;
+
+	/* If even one device supports robust GSO, enable it for all. */
+	if (one & NETIF_F_GSO_ROBUST)
+		all |= NETIF_F_GSO_ROBUST;
+
+	all &= one | NETIF_F_LLTX;
+
+	if (!(all & NETIF_F_ALL_CSUM))
+		all &= ~NETIF_F_SG;
+	if (!(all & NETIF_F_SG))
+		all &= ~NETIF_F_GSO_MASK;
+
+	return all;
+}
+EXPORT_SYMBOL(netdev_compute_features);
+
 /*
  *	Initialize the DEV module. At boot time this walks the device list and
  *	unhooks any devices that fail to initialise (normally hardware not
author
#3 lore raw

PATCH 3/28 sky2: dont clear phy power bits

In reply to Greg KH

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

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

There are special PHY settings available on Yukon EC-U chip that should not get cleared. This should solve mysterious errors on some motherboards (like Gigabyte DS-3).

---
 drivers/net/sky2.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/sky2.c +2 -2
@@ -657,8 +657,8 @@ static void sky2_mac_init(struct sky2_hw
 	int i;
 	const u8 *addr = hw->dev[port]->dev_addr;
 
-	sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
-	sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
+	sky2_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
+	sky2_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
 
 	sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_RST_CLR);
 
author
#4 lore raw

PATCH 4/28 uml: fix previous request size limit fix

In reply to Greg KH

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

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

From: Jeff Dike <[email protected]>

The previous patch which limited the number of sectors in a single request to a COWed device was correct in concept, but the limit was implemented in the wrong place.

By putting it in ubd_add, it covered the cases where the COWing was specified on the command line. However, when the command line only has the COW file specified, the fact that it's a COW file isn't known until it's opened, so the limit is missed in these cases.

This patch moves the sector limit from ubd_add to ubd_open_dev.

---
 arch/um/drivers/ubd_kern.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/um/drivers/ubd_kern.c +2 -2
@@ -612,6 +612,8 @@ static int ubd_open_dev(struct ubd *ubd_
 	ubd_dev->fd = fd;
 
 	if(ubd_dev->cow.file != NULL){
+		blk_queue_max_sectors(ubd_dev->queue, 8 * sizeof(long));
+
 		err = -ENOMEM;
 		ubd_dev->cow.bitmap = (void *) vmalloc(ubd_dev->cow.bitmap_len);
 		if(ubd_dev->cow.bitmap == NULL){
@@ -712,8 +714,6 @@ static int ubd_add(int n, char **error_o
 	ubd_dev->queue->queuedata = ubd_dev;
 
 	blk_queue_max_hw_segments(ubd_dev->queue, MAX_SG);
-	if(ubd_dev->cow.file != NULL)
-		blk_queue_max_sectors(ubd_dev->queue, 8 * sizeof(long));
 	err = ubd_disk_register(MAJOR_NR, ubd_dev->size, n, &ubd_gendisk[n]);
 	if(err){
 		*error_out = "Failed to register device";
author
#5 lore raw

PATCH 5/28 i386: fix lazy mode vmalloc synchronization for paravirt

In reply to Greg KH

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

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

From: Zachary Amsden <[email protected]>

Found this looping Ubuntu installs with VMI.

If unlucky enough to hit a vmalloc sync fault during a lazy mode operation (from an IRQ handler for a module which was not yet populated in current page directory, or from inside copy_one_pte, which touches swap_map, and hit in an unused 4M region), the required PDE update would never get flushed, causing an infinite page fault loop.

This bug affects any paravirt-ops backend which uses lazy updates, I believe that makes it a bug in Xen, VMI and lguest. It only happens on LOWMEM kernels.

Touching vmalloc memory in the middle of a lazy mode update can generate a kernel PDE update, which must be flushed immediately. The fix is to leave lazy mode when doing a vmalloc sync.

---
 arch/i386/mm/fault.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/i386/mm/fault.c +3 -2
@@ -249,9 +249,10 @@ static inline pmd_t *vmalloc_sync_one(pg
 	pmd_k = pmd_offset(pud_k, address);
 	if (!pmd_present(*pmd_k))
 		return NULL;
-	if (!pmd_present(*pmd))
+	if (!pmd_present(*pmd)) {
 		set_pmd(pmd, *pmd_k);
-	else
+		arch_flush_lazy_mmu_mode();
+	} else
 		BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k));
 	return pmd_k;
 }
author
#6 lore raw

PATCH 6/28 signalfd: fix interaction with posix-timers

In reply to Greg KH

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

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

From: Oleg Nesterov <[email protected]>

dequeue_signal:

	if (__SI_TIMER) {
		spin_unlock(&tsk->sighand->siglock);
		do_schedule_next_timer(info);
		spin_lock(&tsk->sighand->siglock);
	}

Unless tsk == curent, this is absolutely unsafe: nothing prevents tsk from exiting. If signalfd was passed to another process, do_schedule_next_timer() is just wrong.

Add yet another "tsk == current" check into dequeue_signal().

This patch fixes an oopsable bug, but breaks the scheduling of posix timers if the shared __SI_TIMER signal was fetched via signalfd attached to another sub-thread. Mostly fixed by the next patch.

Cc Benjamin Herrenschmidt <[email protected]>
Cc Davide Libenzi <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Michael Kerrisk <[email protected]>
Cc Roland McGrath <[email protected]>
Cc Thomas Gleixner <[email protected]>
---
 kernel/signal.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/signal.c +2 -2
@@ -368,7 +368,7 @@ int dequeue_signal(struct task_struct *t
 	/* We only dequeue private signals from ourselves, we don't let
 	 * signalfd steal them
 	 */
-	if (tsk == current)
+	if (likely(tsk == current))
 		signr = __dequeue_signal(&tsk->pending, mask, info);
 	if (!signr) {
 		signr = __dequeue_signal(&tsk->signal->shared_pending,
@@ -415,7 +415,7 @@ int dequeue_signal(struct task_struct *t
 		if (!(tsk->signal->flags & SIGNAL_GROUP_EXIT))
 			tsk->signal->flags |= SIGNAL_STOP_DEQUEUED;
 	}
-	if ( signr &&
+	if (signr && likely(tsk == current) &&
 	     ((info->si_code & __SI_MASK) == __SI_TIMER) &&
 	     info->si_sys_private){
 		/*
author
#7 lore raw

PATCH 7/28 signalfd: make it group-wide, fix posix-timers scheduling

In reply to Greg KH

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

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

From: Oleg Nesterov <[email protected]>

With this patch any thread can dequeue its own private signals via signalfd, even if it was created by another sub-thread.

To do so, we pass "current" to dequeue_signal() if the caller is from the same thread group. This also fixes the scheduling of posix timers broken by the previous patch.

If the caller doesn't belong to this thread group, we can't handle __SI_TIMER case properly anyway. Perhaps we should forbid the cross-process signalfd usage and convert ctx->tsk to ctx->sighand.

Cc Benjamin Herrenschmidt <[email protected]>
Cc Davide Libenzi <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Michael Kerrisk <[email protected]>
Cc Roland McGrath <[email protected]>
Cc Thomas Gleixner <[email protected]>
---
 fs/exec.c     |    9 ++-------
 fs/signalfd.c |   14 ++++++++++----
 2 files changed, 12 insertions(+), 11 deletions(-)
fs/exec.c +2 -7
@@ -586,18 +586,12 @@ static int de_thread(struct task_struct 
 	int count;
 
 	/*
-	 * Tell all the sighand listeners that this sighand has
-	 * been detached. The signalfd_detach() function grabs the
-	 * sighand lock, if signal listeners are present on the sighand.
-	 */
-	signalfd_detach(tsk);
-
-	/*
 	 * If we don't share sighandlers, then we aren't sharing anything
 	 * and we can just re-use it all.
 	 */
 	if (atomic_read(&oldsighand->count) <= 1) {
 		BUG_ON(atomic_read(&sig->count) != 1);
+		signalfd_detach(tsk);
 		exit_itimers(sig);
 		return 0;
 	}
@@ -736,6 +730,7 @@ static int de_thread(struct task_struct 
 	sig->flags = 0;
 
 no_thread_group:
+	signalfd_detach(tsk);
 	exit_itimers(sig);
 	if (leader)
 		release_task(leader);
fs/signalfd.c +10 -4
@@ -56,12 +56,18 @@ static int signalfd_lock(struct signalfd
 		sighand = lock_task_sighand(lk->tsk, &lk->flags);
 	rcu_read_unlock();
 
-	if (sighand && !ctx->tsk) {
+	if (!sighand)
+		return 0;
+
+	if (!ctx->tsk) {
 		unlock_task_sighand(lk->tsk, &lk->flags);
-		sighand = NULL;
+		return 0;
 	}
 
-	return sighand != NULL;
+	if (lk->tsk->tgid == current->tgid)
+		lk->tsk = current;
+
+	return 1;
 }
 
 static void signalfd_unlock(struct signalfd_lockctx *lk)
@@ -331,7 +337,7 @@ asmlinkage long sys_signalfd(int ufd, si
 
 		init_waitqueue_head(&ctx->wqh);
 		ctx->sigmask = sigmask;
-		ctx->tsk = current;
+		ctx->tsk = current->group_leader;
 
 		sighand = current->sighand;
 		/*
author
#8 lore raw

PATCH 8/28 DCCP: Fix DCCP GFP_KERNEL allocation in atomic context

In reply to Greg KH

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

------------------
From: Gerrit Renker <[email protected]>

This fixes the following bug reported in syslog:

[ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032
[ 4039.051668] in_atomic():1, irqs_disabled():0
[ 4039.051670] INFO: lockdep is turned off.
[ 4039.051674]  [<c0104c0f>] show_trace_log_lvl+0x1a/0x30
[ 4039.051687]  [<c0104d4d>] show_trace+0x12/0x14
[ 4039.051691]  [<c0104d65>] dump_stack+0x16/0x18
[ 4039.051695]  [<c011371e>] __might_sleep+0xaf/0xbe
[ 4039.051700]  [<c0157b66>] __kmalloc+0xb1/0xd0
[ 4039.051706]  [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2]
[ 4039.051717]  [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2]
[ 4039.051723]  [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp]
[ 4039.051741]  [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp]
[ 4039.051750]  [<c03907fc>] inet_sendmsg+0x2e/0x4c
[ 4039.051758]  [<c033a47d>] sock_aio_write+0xd5/0x107
[ 4039.051766]  [<c015abc1>] do_sync_write+0xcd/0x11c
[ 4039.051772]  [<c015b296>] vfs_write+0x118/0x11f
[ 4039.051840]  [<c015b932>] sys_write+0x3d/0x64
[ 4039.051845]  [<c0103e7c>] syscall_call+0x7/0xb
[ 4039.051848]  =======================

The problem was that GFP_KERNEL was used; fixed by using gfp_any().

---
 net/dccp/ccids/ccid2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/dccp/ccids/ccid2.c +1 -1
@@ -298,7 +298,7 @@ static void ccid2_hc_tx_packet_sent(stru
 		int rc;
 
 		ccid2_pr_debug("allocating more space in history\n");
-		rc = ccid2_hc_tx_alloc_seq(hctx, CCID2_SEQBUF_LEN, GFP_KERNEL);
+		rc = ccid2_hc_tx_alloc_seq(hctx, CCID2_SEQBUF_LEN, gfp_any());
 		BUG_ON(rc); /* XXX what do we do? */
 
 		next = hctx->ccid2hctx_seqh->ccid2s_next;
author
#9 lore raw

PATCH 9/28 IPV6: Fix kernel panic while send SCTP data with IP fragments

In reply to Greg KH

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

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

From: Wei Yongjun <[email protected]>

If ICMP6 message with "Packet Too Big" is received after send SCTP DATA, kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A Endpoint B

                               <-------  SCTP DATA (size=1432)
ICMP6 message ------->
(Packet Too Big pmtu=1280)
                               <-------  Resend SCTP DATA (size=1432)

------------kernel panic---------------

printing eip:
c05be62a
*pde = 00000000

Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[<c05be62a>]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)

EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0 ebx: ce12a980 ecx: 00000134 edx: cfd5a880
esi: c8246858 edi: 00000000 ebp: c0759b14 esp: c0759adc
ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)

Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f
 [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3
 [<c040608d>] show_registers+0x1b8/0x289
 [<c0406271>] die+0x113/0x246
 [<c0625dbc>] do_page_fault+0x4ad/0x57e
 [<c0624642>] error_code+0x72/0x78
 [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6]
 [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp]
 [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp]
 [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp]
 [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp]
 [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6]
 [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [<d09be240>] ip6_input+0x1dc/0x310 [ipv6]
 [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6]
 [<c05c3789>] netif_receive_skb+0x2d2/0x335
 [<c05c5733>] process_backlog+0x7f/0xd0
 [<c05c58f6>] net_rx_action+0x96/0x17e
 [<c042e722>] __do_softirq+0x64/0xcd
 [<c0406f37>] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [<c05be62a>] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;

====================

---
 net/ipv6/ip6_output.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ip6_output.c +1 -1
@@ -790,7 +790,7 @@ slow_path:
 		/*
 		 *	Copy a block of the IP datagram.
 		 */
-		if (skb_copy_bits(skb, ptr, skb_transport_header(skb), len))
+		if (skb_copy_bits(skb, ptr, skb_transport_header(frag), len))
 			BUG();
 		left -= len;
 
author
#10 lore raw

PATCH 10/28 IPv6: Invalid semicolon after if statement

In reply to Greg KH

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

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

From: Ilpo J�rvinen <[email protected]>

A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid.

---
 net/ipv6/ipv6_sockglue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ipv6_sockglue.c +1 -1
@@ -825,7 +825,7 @@ static int ipv6_getsockopt_sticky(struct
 		return 0;
 
 	len = min_t(unsigned int, len, ipv6_optlen(hdr));
-	if (copy_to_user(optval, hdr, len));
+	if (copy_to_user(optval, hdr, len))
 		return -EFAULT;
 	return ipv6_optlen(hdr);
 }
author
#11 lore raw

PATCH 11/28 Fix soft-fp underflow handling.

In reply to Greg KH

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

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

From: David Miller <[email protected]>

The underflow exception cases were wrong.

This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description:

--------------------
If UFM = 0: Underflow occurs if a nonzero result is tiny and a
loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result.

If UFM = 1: Underflow occurs if a nonzero result is tiny.
Tininess may be detected before or after rounding.
--------------------

What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true:

1) rounding sets inexact
2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too
3) underflow is set in FPU control register trap-enable mask

The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr.

Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above.

However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in

arch/sparc{,64}/math-emu/math.c:record_exception().

Based upon a report and test case from Jakub Jelinek.

---
 include/asm-sparc/sfp-machine.h   |    6 ++++++
 include/asm-sparc64/sfp-machine.h |    2 ++
 include/math-emu/op-common.h      |    5 ++++-
 include/math-emu/soft-fp.h        |    7 +++++++
 4 files changed, 19 insertions(+), 1 deletion(-)
include/asm-sparc/sfp-machine.h +6 -0
@@ -203,4 +203,10 @@ extern struct task_struct *last_task_use
 #define FP_INHIBIT_RESULTS ((last_task_used_math->thread.fsr >> 23) & _fex)
 #endif
 
+#ifdef CONFIG_SMP
+#define FP_TRAPPING_EXCEPTIONS ((current->thread.fsr >> 23) & 0x1f)
+#else
+#define FP_TRAPPING_EXCEPTIONS ((last_task_used_math->thread.fsr >> 23) & 0x1f)
+#endif
+
 #endif
include/asm-sparc64/sfp-machine.h +2 -0
@@ -88,4 +88,6 @@
 
 #define FP_INHIBIT_RESULTS ((current_thread_info()->xfsr[0] >> 23) & _fex)
 
+#define FP_TRAPPING_EXCEPTIONS ((current_thread_info()->xfsr[0] >> 23) & 0x1f)
+
 #endif
include/math-emu/op-common.h +4 -1
@@ -145,13 +145,16 @@ do {								\
 	      {							\
 	        X##_e = 1;					\
 	        _FP_FRAC_SET_##wc(X, _FP_ZEROFRAC_##wc);	\
+	        FP_SET_EXCEPTION(FP_EX_INEXACT);		\
 	      }							\
 	    else						\
 	      {							\
 		X##_e = 0;					\
 		_FP_FRAC_SRL_##wc(X, _FP_WORKBITS);		\
-		FP_SET_EXCEPTION(FP_EX_UNDERFLOW);		\
 	      }							\
+	    if ((FP_CUR_EXCEPTIONS & FP_EX_INEXACT) ||		\
+		(FP_TRAPPING_EXCEPTIONS & FP_EX_UNDERFLOW))	\
+		FP_SET_EXCEPTION(FP_EX_UNDERFLOW);		\
 	  }							\
 	else							\
 	  {							\
include/math-emu/soft-fp.h +7 -0
@@ -97,12 +97,19 @@
 #define FP_INHIBIT_RESULTS 0
 #endif
 
+#ifndef FP_TRAPPING_EXCEPTIONS
+#define FP_TRAPPING_EXCEPTIONS 0
+#endif
+
 #define FP_SET_EXCEPTION(ex)				\
   _fex |= (ex)
   
 #define FP_UNSET_EXCEPTION(ex)				\
   _fex &= ~(ex)
 
+#define FP_CUR_EXCEPTIONS				\
+  (_fex)
+
 #define FP_CLEAR_EXCEPTIONS				\
   _fex = 0
 
author
#12 lore raw

PATCH 12/28 Netfilter: Missing Kbuild entry for netfilter

In reply to Greg KH

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

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

From: Chuck Ebbert <[email protected]>

Add xt_statistic.h to the list of headers to install.

Apparently needed to build newer versions of iptables.

---
 include/linux/netfilter/Kbuild |    1 +
 1 file changed, 1 insertion(+)
include/linux/netfilter/Kbuild +1 -0
@@ -28,6 +28,7 @@ header-y += xt_policy.h
 header-y += xt_realm.h
 header-y += xt_sctp.h
 header-y += xt_state.h
+header-y += xt_statistic.h
 header-y += xt_string.h
 header-y += xt_tcpmss.h
 header-y += xt_tcpudp.h
author
#13 lore raw

PATCH 13/28 SNAP: Fix SNAP protocol header accesses.

In reply to Greg KH

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

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

From: Herbert Xu <[email protected]>

The snap_rcv code reads 5 bytes so we should make sure that we have 5 bytes in the head before proceeding.

Based on diagnosis and fix by Evgeniy Polyakov, reported by Alan J. Wylie.

Patch also kills the skb->sk assignment before kfree_skb since it's redundant.

---
 net/802/psnap.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)
net/802/psnap.c +12 -5
@@ -55,6 +55,9 @@ static int snap_rcv(struct sk_buff *skb,
 		.type = __constant_htons(ETH_P_SNAP),
 	};
 
+	if (unlikely(!pskb_may_pull(skb, 5)))
+		goto drop;
+
 	rcu_read_lock();
 	proto = find_snap_client(skb_transport_header(skb));
 	if (proto) {
@@ -62,14 +65,18 @@ static int snap_rcv(struct sk_buff *skb,
 		skb->transport_header += 5;
 		skb_pull_rcsum(skb, 5);
 		rc = proto->rcvfunc(skb, dev, &snap_packet_type, orig_dev);
-	} else {
-		skb->sk = NULL;
-		kfree_skb(skb);
-		rc = 1;
 	}
-
 	rcu_read_unlock();
+
+	if (unlikely(!proto))
+		goto drop;
+
+out:
 	return rc;
+
+drop:
+	kfree_skb(skb);
+	goto out;
 }
 
 /*
author
#14 lore raw

PATCH 14/28 NET: Fix missing rcu unlock in __sock_create()

In reply to Greg KH

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

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

From: Herbert Xu <[email protected]>

[NET]: Fix unbalanced rcu_read_unlock in __sock_create

The recent RCU work created an unbalanced rcu_read_unlock in __sock_create. This patch fixes that. Reported by oleg 123.

---
 net/socket.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/socket.c +1 -1
@@ -1169,7 +1169,7 @@ static int __sock_create(int family, int
 	module_put(pf->owner);
 	err = security_socket_post_create(sock, family, type, protocol, kern);
 	if (err)
-		goto out_release;
+		goto out_sock_release;
 	*res = sock;
 
 	return 0;
author
#15 lore raw

PATCH 15/28 SPARC64: Fix sparc64 task stack traces.

In reply to Greg KH

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

------------------
From: David Miller <[email protected]>

It didn't handle that case at all, and now dump_stack() can be implemented directly as show_stack(current, NULL)

---
 arch/sparc64/kernel/traps.c |   18 +++++++++++-------
 arch/sparc64/mm/fault.c     |    5 +----
 2 files changed, 12 insertions(+), 11 deletions(-)
arch/sparc64/kernel/traps.c +11 -7
@@ -2134,12 +2134,20 @@ static void user_instruction_dump (unsig
 void show_stack(struct task_struct *tsk, unsigned long *_ksp)
 {
 	unsigned long pc, fp, thread_base, ksp;
-	void *tp = task_stack_page(tsk);
+	struct thread_info *tp;
 	struct reg_window *rw;
 	int count = 0;
 
 	ksp = (unsigned long) _ksp;
-
+	if (!tsk)
+		tsk = current;
+	tp = task_thread_info(tsk);
+	if (ksp == 0UL) {
+		if (tsk == current)
+			asm("mov %%fp, %0" : "=r" (ksp));
+		else
+			ksp = tp->ksp;
+	}
 	if (tp == current_thread_info())
 		flushw_all();
 
@@ -2168,11 +2176,7 @@ void show_stack(struct task_struct *tsk,
 
 void dump_stack(void)
 {
-	unsigned long *ksp;
-
-	__asm__ __volatile__("mov	%%fp, %0"
-			     : "=r" (ksp));
-	show_stack(current, ksp);
+	show_stack(current, NULL);
 }
 
 EXPORT_SYMBOL(dump_stack);
arch/sparc64/mm/fault.c +1 -4
@@ -112,15 +112,12 @@ static void __kprobes unhandled_fault(un
 
 static void bad_kernel_pc(struct pt_regs *regs, unsigned long vaddr)
 {
-	unsigned long *ksp;
-
 	printk(KERN_CRIT "OOPS: Bogus kernel PC [%016lx] in fault handler\n",
 	       regs->tpc);
 	printk(KERN_CRIT "OOPS: RPC [%016lx]\n", regs->u_regs[15]);
 	print_symbol("RPC: <%s>\n", regs->u_regs[15]);
 	printk(KERN_CRIT "OOPS: Fault was to vaddr[%lx]\n", vaddr);
-	__asm__("mov %%sp, %0" : "=r" (ksp));
-	show_stack(current, ksp);
+	dump_stack();
 	unhandled_fault(regs->tpc, current, regs);
 }
 
author
#16 lore raw

PATCH 16/28 SPARC64: Fix sparc64 PCI config accesses on sun4u

In reply to Greg KH

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

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

From: David Miller <[email protected]>

[SPARC64]: Fix sun4u PCI config space accesses on sun4u.

Don't provide fake PCI config space for sun4u.

Also, put back the funny host controller space handling that at least Sabre needs. You have to read PCI host controller registers at their nature size otherwise you get zeros instead of correct values.

---
 arch/sparc64/kernel/pci.c        |   15 +++-
 arch/sparc64/kernel/pci_common.c |  123 ++++++++++++++++++++++++++++++++++++---
 2 files changed, 126 insertions(+), 12 deletions(-)
arch/sparc64/kernel/pci.c +10 -5
@@ -422,10 +422,15 @@ struct pci_dev *of_create_pci_dev(struct
 	dev->multifunction = 0;		/* maybe a lie? */
 
 	if (host_controller) {
-		dev->vendor = 0x108e;
-		dev->device = 0x8000;
-		dev->subsystem_vendor = 0x0000;
-		dev->subsystem_device = 0x0000;
+		if (tlb_type != hypervisor) {
+			pci_read_config_word(dev, PCI_VENDOR_ID,
+					     &dev->vendor);
+			pci_read_config_word(dev, PCI_DEVICE_ID,
+					     &dev->device);
+		} else {
+			dev->vendor = PCI_VENDOR_ID_SUN;
+			dev->device = 0x80f0;
+		}
 		dev->cfg_size = 256;
 		dev->class = PCI_CLASS_BRIDGE_HOST << 8;
 		sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
@@ -817,7 +822,7 @@ int pci_host_bridge_read_pci_cfg(struct 
 {
 	static u8 fake_pci_config[] = {
 		0x8e, 0x10, /* Vendor: 0x108e (Sun) */
-		0x00, 0x80, /* Device: 0x8000 (PBM) */
+		0xf0, 0x80, /* Device: 0x80f0 (Fire) */
 		0x46, 0x01, /* Command: 0x0146 (SERR, PARITY, MASTER, MEM) */
 		0xa0, 0x22, /* Status: 0x02a0 (DEVSEL_MED, FB2B, 66MHZ) */
 		0x00, 0x00, 0x00, 0x06, /* Class: 0x06000000 host bridge */
arch/sparc64/kernel/pci_common.c +116 -7

153 lines not on this page · raw message

author
#17 lore raw

PATCH 17/28 TCP: Do not autobind ports for TCP sockets

In reply to Greg KH

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

------------------
From: David Miller <[email protected]>

[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the socket, but we should never do that for TCP. Instead we should just go straight into TCP's sendmsg() code which will do all of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this merely brings sendmsg() in line with that.

---
 include/net/tcp.h   |    2 +-
 net/ipv4/af_inet.c  |    2 +-
 net/ipv4/tcp.c      |    3 ++-
 net/ipv4/tcp_ipv4.c |    1 -
 net/ipv6/af_inet6.c |    2 +-
 net/ipv6/tcp_ipv6.c |    1 -
 6 files changed, 5 insertions(+), 6 deletions(-)
include/net/tcp.h +1 -1
@@ -281,7 +281,7 @@ extern int			tcp_v4_remember_stamp(struc
 
 extern int		    	tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw);
 
-extern int			tcp_sendmsg(struct kiocb *iocb, struct sock *sk,
+extern int			tcp_sendmsg(struct kiocb *iocb, struct socket *sock,
 					    struct msghdr *msg, size_t size);
 extern ssize_t			tcp_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags);
 
net/ipv4/af_inet.c +1 -1
@@ -831,7 +831,7 @@ const struct proto_ops inet_stream_ops =
 	.shutdown	   = inet_shutdown,
 	.setsockopt	   = sock_common_setsockopt,
 	.getsockopt	   = sock_common_getsockopt,
-	.sendmsg	   = inet_sendmsg,
+	.sendmsg	   = tcp_sendmsg,
 	.recvmsg	   = sock_common_recvmsg,
 	.mmap		   = sock_no_mmap,
 	.sendpage	   = tcp_sendpage,
net/ipv4/tcp.c +2 -1
@@ -658,9 +658,10 @@ static inline int select_size(struct soc
 	return tmp;
 }
 
-int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
+int tcp_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
 		size_t size)
 {
+	struct sock *sk = sock->sk;
 	struct iovec *iov;
 	struct tcp_sock *tp = tcp_sk(sk);
 	struct sk_buff *skb;
net/ipv4/tcp_ipv4.c +0 -1
@@ -2434,7 +2434,6 @@ struct proto tcp_prot = {
 	.shutdown		= tcp_shutdown,
 	.setsockopt		= tcp_setsockopt,
 	.getsockopt		= tcp_getsockopt,
-	.sendmsg		= tcp_sendmsg,
 	.recvmsg		= tcp_recvmsg,
 	.backlog_rcv		= tcp_v4_do_rcv,
 	.hash			= tcp_v4_hash,
net/ipv6/af_inet6.c +1 -1
@@ -487,7 +487,7 @@ const struct proto_ops inet6_stream_ops 
 	.shutdown	   = inet_shutdown,		/* ok		*/
 	.setsockopt	   = sock_common_setsockopt,	/* ok		*/
 	.getsockopt	   = sock_common_getsockopt,	/* ok		*/
-	.sendmsg	   = inet_sendmsg,		/* ok		*/
+	.sendmsg	   = tcp_sendmsg,		/* ok		*/
 	.recvmsg	   = sock_common_recvmsg,	/* ok		*/
 	.mmap		   = sock_no_mmap,
 	.sendpage	   = tcp_sendpage,
net/ipv6/tcp_ipv6.c +0 -1
@@ -2135,7 +2135,6 @@ struct proto tcpv6_prot = {
 	.shutdown		= tcp_shutdown,
 	.setsockopt		= tcp_setsockopt,
 	.getsockopt		= tcp_getsockopt,
-	.sendmsg		= tcp_sendmsg,
 	.recvmsg		= tcp_recvmsg,
 	.backlog_rcv		= tcp_v6_do_rcv,
 	.hash			= tcp_v6_hash,
author
#18 lore raw

PATCH 18/28 TCP: Fix TCP rate-halving on bidirectional flows.

In reply to Greg KH

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

------------------
From: Ilpo J�rvinen <[email protected]>

Actually, the ratehalving seems to work too well, as cwnd is reduced on every second ACK even though the packets in flight remains unchanged. Recoveries in a bidirectional flows suffer quite badly because of this, both NewReno and SACK are affected.

After this patch, rate halving is performed for ACK only if packets in flight was supposedly changed too.

---
 net/ipv4/tcp_input.c |   21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)
net/ipv4/tcp_input.c +12 -9
@@ -1851,19 +1851,22 @@ static inline u32 tcp_cwnd_min(const str
 }
 
 /* Decrease cwnd each second ack. */
-static void tcp_cwnd_down(struct sock *sk)
+static void tcp_cwnd_down(struct sock *sk, int flag)
 {
 	struct tcp_sock *tp = tcp_sk(sk);
 	int decr = tp->snd_cwnd_cnt + 1;
 
-	tp->snd_cwnd_cnt = decr&1;
-	decr >>= 1;
+	if ((flag&FLAG_FORWARD_PROGRESS) ||
+	    (IsReno(tp) && !(flag&FLAG_NOT_DUP))) {
+		tp->snd_cwnd_cnt = decr&1;
+		decr >>= 1;
 
-	if (decr && tp->snd_cwnd > tcp_cwnd_min(sk))
-		tp->snd_cwnd -= decr;
+		if (decr && tp->snd_cwnd > tcp_cwnd_min(sk))
+			tp->snd_cwnd -= decr;
 
-	tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1);
-	tp->snd_cwnd_stamp = tcp_time_stamp;
+		tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1);
+		tp->snd_cwnd_stamp = tcp_time_stamp;
+	}
 }
 
 /* Nothing was retransmitted or returned timestamp is less
@@ -2060,7 +2063,7 @@ static void tcp_try_to_open(struct sock 
 		}
 		tcp_moderate_cwnd(tp);
 	} else {
-		tcp_cwnd_down(sk);
+		tcp_cwnd_down(sk, flag);
 	}
 }
 
@@ -2260,7 +2263,7 @@ tcp_fastretrans_alert(struct sock *sk, u
 
 	if (is_dupack || tcp_head_timedout(sk))
 		tcp_update_scoreboard(sk);
-	tcp_cwnd_down(sk);
+	tcp_cwnd_down(sk, flag);
 	tcp_xmit_retransmit_queue(sk);
 }
 
author
#19 lore raw

PATCH 19/28 TCP: Fix TCP handling of SACK in bidirectional flows.

In reply to Greg KH

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

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

From: Ilpo J�rvinen <[email protected]>

It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too).

I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-)

---
 net/ipv4/tcp_input.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv4/tcp_input.c +4 -1
@@ -2112,7 +2112,10 @@ tcp_fastretrans_alert(struct sock *sk, u
 {
 	struct inet_connection_sock *icsk = inet_csk(sk);
 	struct tcp_sock *tp = tcp_sk(sk);
-	int is_dupack = (tp->snd_una == prior_snd_una && !(flag&FLAG_NOT_DUP));
+	int is_dupack = (tp->snd_una == prior_snd_una &&
+			 (!(flag&FLAG_NOT_DUP) ||
+			  ((flag&FLAG_DATA_SACKED) &&
+			   (tp->fackets_out > tp->reordering))));
 
 	/* Some technical things:
 	 * 1. Reno does not count dupacks (sacked_out) automatically. */
author
#20 lore raw

PATCH 20/28 PPP: Fix PPP buffer sizing.

In reply to Greg KH

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

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

From: Konstantin Sharlaimov <[email protected]>

This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine.

--------------------
As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that.
--------------------

---
 drivers/net/ppp_generic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ppp_generic.c +1 -1
@@ -1726,7 +1726,7 @@ ppp_decompress_frame(struct ppp *ppp, st
 		}
 		/* the decompressor still expects the A/C bytes in the hdr */
 		len = ppp->rcomp->decompress(ppp->rc_state, skb->data - 2,
-				skb->len + 2, ns->data, ppp->mru + PPP_HDRLEN);
+				skb->len + 2, ns->data, obuff_size);
 		if (len < 0) {
 			/* Pass the compressed frame to pppd as an
 			   error indication. */
author
#21 lore raw

PATCH 21/28 PCI: lets kill the PCI hidden behind bridge message

In reply to Greg KH

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

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

From: Bernhard Kaindl <[email protected]>

Quoted 9 lines · Adrian Bunk

Alois Nešpor wrote

Quoted 6 lines

PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently"

dmesg:
"Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e" without pci=assign-busses and nothing with pci=assign-busses.

Bernhard?

Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta, so PCI does not have to warn about it. PCI could still warn about it if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have not seen a report where this would have been the case so I think we can spare the kernel of that check (removes ~300 lines of asm) unless debugging is done.

History: The whole check was added in the days before we had the fixup for this in Yenta and pci=assign-busses was the only way to get CardBus cards detected on many (not all) of the machines which give this warning.

In theory, there could be cases when this warning would be triggered and it's not cardbus, then the warning should still apply, but I think this should only be the case when working on a completely broken PCI setup, but one may have already enabled the debug code in drivers/pci and the patched check would then trigger.

I do not sign this off yet because it's completely untested so far, but everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and pr_debug( changed to printk(.

We may also dump the whole check (remove everything within the #ifdef from the source) if that's perferred.

On Alois Nešpor's machine this would then (only when debugging) this message:

"PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)"

"partially" should be in the message on his machine because #0b of #0b-#0e is reachable behind #0a-#0b, but not #0c-#0e.

But that differentiation is now moot anyway because the fixup in Yenta takes care of it as far as I could see so far, which means that unless somebody is debugging a totally broken PCI setup, this message is not needed anymore, not even for debugging PCI.

Ok, here the patch with the following changes:

* Refined to say that the bus is only partially hidden when the parent bus numbers are not totally way off (outside of) the child bus range
* remove the reference to pci=assign-busses and the plea to report it

We could add a pure source code-only comment to keep a reference to pci=assign-busses the in case when this is triggered by someone who is debugging the cause of this message and looking the way to solve it.

From: Bernhard Kaindl <[email protected]>

---
 drivers/pci/probe.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/pci/probe.c +9 -9
@@ -643,20 +643,20 @@ int pci_scan_bridge(struct pci_bus *bus,
 
 	sprintf(child->name, (is_cardbus ? "PCI CardBus #%02x" : "PCI Bus #%02x"), child->number);
 
+	/* Has only triggered on CardBus, fixup is in yenta_socket */
 	while (bus->parent) {
 		if ((child->subordinate > bus->subordinate) ||
 		    (child->number > bus->subordinate) ||
 		    (child->number < bus->number) ||
 		    (child->subordinate < bus->number)) {
-			printk(KERN_WARNING "PCI: Bus #%02x (-#%02x) is "
-			       "hidden behind%s bridge #%02x (-#%02x)%s\n",
-			       child->number, child->subordinate,
-			       bus->self->transparent ? " transparent" : " ",
-			       bus->number, bus->subordinate,
-			       pcibios_assign_all_busses() ? " " :
-			       " (try 'pci=assign-busses')");
-			printk(KERN_WARNING "Please report the result to "
-			       "linux-kernel to fix this permanently\n");
+			pr_debug("PCI: Bus #%02x (-#%02x) is %s"
+				"hidden behind%s bridge #%02x (-#%02x)\n",
+				child->number, child->subordinate,
+				(bus->number > child->subordinate &&
+				 bus->subordinate < child->number) ?
+					"wholly " : " partially",
+				bus->self->transparent ? " transparent" : " ",
+				bus->number, bus->subordinate);
 		}
 		bus = bus->parent;
 	}
author
#22 lore raw

PATCH 22/28 PCI: disable MSI on RS690

In reply to Greg KH

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

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

From: Tejun Heo <[email protected]>

RS690 can't do MSI like its predecessors. Disable MSI on RS690.

---
 drivers/pci/quirks.c    |    1 +
 include/linux/pci_ids.h |    1 +
 2 files changed, 2 insertions(+)
drivers/pci/quirks.c +1 -0
@@ -1640,6 +1640,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SE
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi);
 
 /* Disable MSI on chipsets that are known to not support it */
include/linux/pci_ids.h +1 -0
@@ -357,6 +357,7 @@
 #define PCI_DEVICE_ID_ATI_RS400_166     0x5a32
 #define PCI_DEVICE_ID_ATI_RS400_200     0x5a33
 #define PCI_DEVICE_ID_ATI_RS480         0x5950
+#define PCI_DEVICE_ID_ATI_RS690		0x7910
 /* ATI IXP Chipset */
 #define PCI_DEVICE_ID_ATI_IXP200_IDE	0x4349
 #define PCI_DEVICE_ID_ATI_IXP200_SMBUS	0x4353
author
#23 lore raw

PATCH 23/28 PCI: disable MSI on RD580

In reply to Greg KH

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

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

From: Tejun Heo <[email protected]>

RD580 can't do MSI like its predecessors. Disable MSI on RD580.

---
 drivers/pci/quirks.c    |    1 +
 include/linux/pci_ids.h |    1 +
 2 files changed, 2 insertions(+)
drivers/pci/quirks.c +1 -0
@@ -1640,6 +1640,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SE
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi);
 
include/linux/pci_ids.h +1 -0
@@ -357,6 +357,7 @@
 #define PCI_DEVICE_ID_ATI_RS400_166     0x5a32
 #define PCI_DEVICE_ID_ATI_RS400_200     0x5a33
 #define PCI_DEVICE_ID_ATI_RS480         0x5950
+#define PCI_DEVICE_ID_ATI_RD580		0x5952
 #define PCI_DEVICE_ID_ATI_RS690		0x7910
 /* ATI IXP Chipset */
 #define PCI_DEVICE_ID_ATI_IXP200_IDE	0x4349
author
#24 lore raw

PATCH 24/28 PCI: disable MSI on RX790

In reply to Greg KH

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

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

From: Tejun Heo <[email protected]>

RX790 can't do MSI like its predecessors. Disable MSI on RX790.

---
 drivers/pci/quirks.c    |    1 +
 include/linux/pci_ids.h |    1 +
 2 files changed, 2 insertions(+)
drivers/pci/quirks.c +1 -0
@@ -1641,6 +1641,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SE
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RX790, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi);
 
include/linux/pci_ids.h +1 -0
@@ -358,6 +358,7 @@
 #define PCI_DEVICE_ID_ATI_RS400_200     0x5a33
 #define PCI_DEVICE_ID_ATI_RS480         0x5950
 #define PCI_DEVICE_ID_ATI_RD580		0x5952
+#define PCI_DEVICE_ID_ATI_RX790		0x5957
 #define PCI_DEVICE_ID_ATI_RS690		0x7910
 /* ATI IXP Chipset */
 #define PCI_DEVICE_ID_ATI_IXP200_IDE	0x4349
author
#25 lore raw

PATCH 25/28 USB: cdc-acm: fix sysfs attribute registration bug

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

This patch (as950) fixes a bug in the cdc-acm driver. It doesn't keep track of which interface (control or data) the sysfs attributes get registered for, and as a result, during disconnect it will sometimes attempt to remove the attributes from the wrong interface. The left-over attributes can cause a crash later on, particularly if the driver module has been unloaded.

---
 drivers/usb/class/cdc-acm.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/usb/class/cdc-acm.c +4 -0
@@ -900,6 +900,10 @@ next_desc:
 			return -ENODEV;
 		}
 	}
+
+	/* Accept probe requests only for the control interface */
+	if (intf != control_interface)
+		return -ENODEV;
 	
 	if (data_interface_num != call_interface_num)
 		dev_dbg(&intf->dev,"Seperate call control interface. That is not fully supported.");
#26 lore raw

Re: [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

Quoted 25 lines · Greg KH

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

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

From: Alan Stern <[email protected]>

This patch (as950) fixes a bug in the cdc-acm driver. It doesn't keep track of which interface (control or data) the sysfs attributes get registered for, and as a result, during disconnect it will sometimes attempt to remove the attributes from the wrong interface. The left-over attributes can cause a crash later on, particularly if the driver module has been unloaded.

---
 drivers/usb/class/cdc-acm.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/class/cdc-acm.c next_desc: · line 909

Quoted 10 lines
drivers/usb/class/cdc-acm.c +4 -0
@@ -900,6 +900,10 @@ next_desc:
 			return -ENODEV;
 		}
 	}
+
+	/* Accept probe requests only for the control interface */
+	if (intf != control_interface)
+		return -ENODEV;
 
 	if (data_interface_num != call_interface_num)
 		dev_dbg(&intf->dev,"Seperate call control interface. That is not fully supported.");

Odd. This doesn't include the entire patch; the second hunk is missing. It should go on to say:

@@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_interface *intf)
return;
}
if (acm->country_codes){
- device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
- device_remove_file(&intf->dev, &dev_attr_iCountryCodeRelDate);
+ device_remove_file(&acm->control->dev,
+ &dev_attr_wCountryCodes);
+ device_remove_file(&acm->control->dev,
+ &dev_attr_iCountryCodeRelDate);
}
- device_remove_file(&intf->dev, &dev_attr_bmCapabilities);
+ device_remove_file(&acm->control->dev, &dev_attr_bmCapabilities);
acm->dev = NULL;
usb_set_intfdata(acm->control, NULL); usb_set_intfdata(acm->data, NULL);

Alan Stern

#27 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

Quoted 44 lines · Alan Stern
Quoted 25 lines · Greg KH

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

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

From: Alan Stern <[email protected]>

This patch (as950) fixes a bug in the cdc-acm driver. It doesn't keep track of which interface (control or data) the sysfs attributes get registered for, and as a result, during disconnect it will sometimes attempt to remove the attributes from the wrong interface. The left-over attributes can cause a crash later on, particularly if the driver module has been unloaded.

---
 drivers/usb/class/cdc-acm.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/class/cdc-acm.c next_desc: · line 909

Quoted 10 lines
drivers/usb/class/cdc-acm.c +4 -0
@@ -900,6 +900,10 @@ next_desc:
 			return -ENODEV;
 		}
 	}
+
+	/* Accept probe requests only for the control interface */
+	if (intf != control_interface)
+		return -ENODEV;
 
 	if (data_interface_num != call_interface_num)
 		dev_dbg(&intf->dev,"Seperate call control interface. That is not fully supported.");

Odd. This doesn't include the entire patch; the second hunk is missing. It should go on to say:

(quoted diff) +0 -0
@@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_interface *intf)
 		return;
 	}

Review static void acm_disconnect(struct usb_interface *intf) · line 1121

Quoted 10 lines
(quoted diff) +5 -3
 	if (acm->country_codes){
-		device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
-		device_remove_file(&intf->dev, &dev_attr_iCountryCodeRelDate);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_wCountryCodes);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_iCountryCodeRelDate);
 	}
-	device_remove_file(&intf->dev, &dev_attr_bmCapabilities);
+	device_remove_file(&acm->control->dev, &dev_attr_bmCapabilities);

I thought so too, untill you look at the 2.6.22.5 release, which already has that change in it for some reason.

So that part of the patch drops out, it turns out you just reverted things back to the way things used to be here :)

thanks,

greg k-h

#28 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

Quoted 21 lines · Greg KH
Quoted 6 lines

Odd. This doesn't include the entire patch; the second hunk is missing. It should go on to say:

(quoted diff) +0 -0
@@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_interface *intf)
 		return;
 	}

Review static void acm_disconnect(struct usb_interface *intf) · line 1121

Quoted 10 lines
(quoted diff) +5 -3
 	if (acm->country_codes){
-		device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
-		device_remove_file(&intf->dev, &dev_attr_iCountryCodeRelDate);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_wCountryCodes);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_iCountryCodeRelDate);
 	}
-	device_remove_file(&intf->dev, &dev_attr_bmCapabilities);
+	device_remove_file(&acm->control->dev, &dev_attr_bmCapabilities);

I thought so too, untill you look at the 2.6.22.5 release, which already has that change in it for some reason.

Quoted 2 lines

So that part of the patch drops out, it turns out you just reverted things back to the way things used to be here :)

I don't understand. The history for stable/linux-2.6.22.y.git at
http://git.kernel.org shows that the commit for my patch, labelled

	6b30a4e1c357410a78d7bcb831743b0e99bab4ad,

includes both hunks. And patch-2.6.22.5.bz2 includes both as well. Something's fishy.

Alan Stern

author
#29 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

Quoted 26 lines · Alan Stern
Quoted 21 lines · Greg KH
Quoted 6 lines

Odd. This doesn't include the entire patch; the second hunk is missing. It should go on to say:

(quoted diff) +0 -0
@@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_interface *intf)
 		return;
 	}

Review static void acm_disconnect(struct usb_interface *intf) · line 1121

Quoted 10 lines
(quoted diff) +5 -3
 	if (acm->country_codes){
-		device_remove_file(&intf->dev, &dev_attr_wCountryCodes);
-		device_remove_file(&intf->dev, &dev_attr_iCountryCodeRelDate);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_wCountryCodes);
+		device_remove_file(&acm->control->dev,
+				&dev_attr_iCountryCodeRelDate);
 	}
-	device_remove_file(&intf->dev, &dev_attr_bmCapabilities);
+	device_remove_file(&acm->control->dev, &dev_attr_bmCapabilities);

I thought so too, untill you look at the 2.6.22.5 release, which already has that change in it for some reason.

Quoted 2 lines

So that part of the patch drops out, it turns out you just reverted things back to the way things used to be here :)

Quoted 7 lines

I don't understand. The history for stable/linux-2.6.22.y.git at
http://git.kernel.org shows that the commit for my patch, labelled

	6b30a4e1c357410a78d7bcb831743b0e99bab4ad,

includes both hunks. And patch-2.6.22.5.bz2 includes both as well. Something's fishy.

Ah crap, I see it now, this was already applied, I tried to apply it again, it went with some fuzz for one chunk, which I ignored.

I'm starting to really appreciate Linus's hate for patch-fuzz :)

I'll drop this from the queue as it's already in the -stable series. Thanks for pointing out my mistake, I appreciate it.

greg k-h

#30 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

Quoted 3 lines · Greg KH

I'm starting to really appreciate Linus's hate for patch-fuzz :)

If you're using quilt, add this to .quiltrc:

QUILT_PATCH_OPTS="--fuzz=1"

#31 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

In reply to Greg KH
Quoted 8 lines · Greg KH
Quoted 7 lines

I don't understand. The history for stable/linux-2.6.22.y.git at
http://git.kernel.org shows that the commit for my patch, labelled

	6b30a4e1c357410a78d7bcb831743b0e99bab4ad,

includes both hunks. And patch-2.6.22.5.bz2 includes both as well. Something's fishy.

*sigh*

The stable-queue tree does not match what got released for 2.6.22.5.

$ pwd
/home/me/git/stable-queue
$ grep cdc releases/2.6.22.5/*
$ 
$ bzcat patch-2.6.22.5.bz2 | grep cdc
index acdc3be..e2b9ca4 100644
drivers/usb/class/cdc-acm.c +0 -0
#32 lore raw

Re: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug

drivers/usb/class/cdc-acm.c

Quoted 25 lines · Chuck Ebbert
Quoted 8 lines · Greg KH
Quoted 7 lines

I don't understand. The history for stable/linux-2.6.22.y.git at
http://git.kernel.org shows that the commit for my patch, labelled

	6b30a4e1c357410a78d7bcb831743b0e99bab4ad,

includes both hunks. And patch-2.6.22.5.bz2 includes both as well. Something's fishy.

*sigh*

The stable-queue tree does not match what got released for 2.6.22.5.

$ pwd
/home/me/git/stable-queue
$ grep cdc releases/2.6.22.5/*
$ 
$ bzcat patch-2.6.22.5.bz2 | grep cdc
index acdc3be..e2b9ca4 100644
drivers/usb/class/cdc-acm.c +0 -0

That is because the cdc-acm patch went into an earlier .22.y release, look at the git tree to see that. It was not in the 2.6.22.5 release.

thanks,

greg k-h

author
#33 lore raw

PATCH 26/28 USB: allow retry on descriptor fetch errors

In reply to Greg KH

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

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

From: Alan Stern <[email protected]>

This patch (as964) was suggested by Steffen Koepf. It makes usb_get_descriptor() retry on all errors other than ETIMEDOUT, instead of only on EPIPE. This helps with some devices.

---
 drivers/usb/core/message.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/core/message.c +2 -2
@@ -623,12 +623,12 @@ int usb_get_descriptor(struct usb_device
 	memset(buf,0,size);	// Make sure we parse really received data
 
 	for (i = 0; i < 3; ++i) {
-		/* retry on length 0 or stall; some devices are flakey */
+		/* retry on length 0 or error; some devices are flakey */
 		result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
 				USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
 				(type << 8) + index, 0, buf, size,
 				USB_CTRL_GET_TIMEOUT);
-		if (result == 0 || result == -EPIPE)
+		if (result <= 0 && result != -ETIMEDOUT)
 			continue;
 		if (result > 1 && ((u8 *)buf)[1] != type) {
 			result = -EPROTO;
author
#34 lore raw

PATCH 27/28 USB: fix DoS in pwc USB video driver

In reply to Greg KH

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

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

From: Oliver Neukum <[email protected]>

the pwc driver has a disconnect method that waits for user space to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close if an opened device is disconnected.

---
 drivers/media/video/pwc/pwc-if.c |   52 ++++++++++++++++++++++++++-------------
 drivers/media/video/pwc/pwc.h    |    1 
 2 files changed, 36 insertions(+), 17 deletions(-)
drivers/media/video/pwc/pwc-if.c +35 -17
@@ -1196,12 +1196,19 @@ static int pwc_video_open(struct inode *
 	return 0;
 }
 
+
+static void pwc_cleanup(struct pwc_device *pdev)
+{
+	pwc_remove_sysfs_files(pdev->vdev);
+	video_unregister_device(pdev->vdev);
+}
+
 /* Note that all cleanup is done in the reverse order as in _open */
 static int pwc_video_close(struct inode *inode, struct file *file)
 {
 	struct video_device *vdev = file->private_data;
 	struct pwc_device *pdev;
-	int i;
+	int i, hint;
 
 	PWC_DEBUG_OPEN(">> video_close called(vdev = 0x%p).\n", vdev);
 
@@ -1224,8 +1231,9 @@ static int pwc_video_close(struct inode 
 	pwc_isoc_cleanup(pdev);
 	pwc_free_buffers(pdev);
 
+	lock_kernel();
 	/* Turn off LEDS and power down camera, but only when not unplugged */
-	if (pdev->error_status != EPIPE) {
+	if (!pdev->unplugged) {
 		/* Turn LEDs off */
 		if (pwc_set_leds(pdev, 0, 0) < 0)
 			PWC_DEBUG_MODULE("Failed to set LED on/off time.\n");
@@ -1234,9 +1242,19 @@ static int pwc_video_close(struct inode 
 			if (i < 0)
 				PWC_ERROR("Failed to power down camera (%d)\n", i);
 		}
+		pdev->vopen--;
+		PWC_DEBUG_OPEN("<< video_close() vopen=%d\n", i);
+	} else {
+		pwc_cleanup(pdev);
+		/* Free memory (don't set pdev to 0 just yet) */
+		kfree(pdev);
+		/* search device_hint[] table if we occupy a slot, by any chance */
+		for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+			if (device_hint[hint].pdev == pdev)
+				device_hint[hint].pdev = NULL;
 	}
-	pdev->vopen--;
-	PWC_DEBUG_OPEN("<< video_close() vopen=%d\n", pdev->vopen);
+	unlock_kernel();
+
 	return 0;
 }
 
@@ -1791,21 +1809,21 @@ static void usb_pwc_disconnect(struct us
 	/* Alert waiting processes */
 	wake_up_interruptible(&pdev->frameq);
 	/* Wait until device is closed */
-	while (pdev->vopen)
-		schedule();
-	/* Device is now closed, so we can safely unregister it */
-	PWC_DEBUG_PROBE("Unregistering video device in disconnect().\n");
-	pwc_remove_sysfs_files(pdev->vdev);
-	video_unregister_device(pdev->vdev);
-
-	/* Free memory (don't set pdev to 0 just yet) */
-	kfree(pdev);
+	if(pdev->vopen) {
+		pdev->unplugged = 1;
+	} else {
+		/* Device is closed, so we can safely unregister it */
+		PWC_DEBUG_PROBE("Unregistering video device in disconnect().\n");
+		pwc_cleanup(pdev);
+		/* Free memory (don't set pdev to 0 just yet) */
+		kfree(pdev);
 
 disconnect_out:
-	/* search device_hint[] table if we occupy a slot, by any chance */
-	for (hint = 0; hint < MAX_DEV_HINTS; hint++)
-		if (device_hint[hint].pdev == pdev)
-			device_hint[hint].pdev = NULL;
+		/* search device_hint[] table if we occupy a slot, by any chance */
+		for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+			if (device_hint[hint].pdev == pdev)
+				device_hint[hint].pdev = NULL;
+	}
 
 	unlock_kernel();
 }
drivers/media/video/pwc/pwc.h +1 -0
@@ -193,6 +193,7 @@ struct pwc_device
    char vsnapshot;		/* snapshot mode */
    char vsync;			/* used by isoc handler */
    char vmirror;		/* for ToUCaM series */
+	char unplugged;
 
    int cmd_len;
    unsigned char cmd_buf[13];
author
#35 lore raw

PATCH 28/28 usb: add PRODUCT, TYPE to usb-interface events

In reply to Greg KH

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

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

From: Kay Sievers <[email protected]>

This fixes a regression for userspace programs that were relying on these events.

---
 drivers/usb/core/message.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
drivers/usb/core/message.c +24 -0
@@ -1344,6 +1344,30 @@ static int usb_if_uevent(struct device *
 	usb_dev = interface_to_usbdev(intf);
 	alt = intf->cur_altsetting;
 
+#ifdef CONFIG_USB_DEVICEFS
+	if (add_uevent_var(envp, num_envp, &i,
+			   buffer, buffer_size, &length,
+			   "DEVICE=/proc/bus/usb/%03d/%03d",
+			   usb_dev->bus->busnum, usb_dev->devnum))
+		return -ENOMEM;
+#endif
+
+	if (add_uevent_var(envp, num_envp, &i,
+			   buffer, buffer_size, &length,
+			   "PRODUCT=%x/%x/%x",
+			   le16_to_cpu(usb_dev->descriptor.idVendor),
+			   le16_to_cpu(usb_dev->descriptor.idProduct),
+			   le16_to_cpu(usb_dev->descriptor.bcdDevice)))
+		return -ENOMEM;
+
+	if (add_uevent_var(envp, num_envp, &i,
+			   buffer, buffer_size, &length,
+			   "TYPE=%d/%d/%d",
+			   usb_dev->descriptor.bDeviceClass,
+			   usb_dev->descriptor.bDeviceSubClass,
+			   usb_dev->descriptor.bDeviceProtocol))
+		return -ENOMEM;
+
 	if (add_uevent_var(envp, num_envp, &i,
 		   buffer, buffer_size, &length,
 		   "INTERFACE=%d/%d/%d",
author
#36 lore raw
In reply to Greg KH
Quoted 5 lines · Greg KH

This is the start of the stable review cycle for the 2.6.22.6 release. There are 28 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.

A rolled-up patch with all changes in it can be found at:

	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.22.6-rc1.gz

thanks,

greg k-h

#37 lore raw
In reply to Greg KH

Greg KH skrev:

Quoted 6 lines

This is the start of the stable review cycle for the 2.6.22.6 release. There are 28 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.

Quoted 8 lines

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

Responses should be made by August 25 22:00:00 UTC 2007. Anything received after that time might be too late.

What happend to this ??

--
Thomas

#38 lore raw
Quoted 12 lines · Thomas Backlund

Greg KH skrev:

Quoted 11 lines

This is the start of the stable review cycle for the 2.6.22.6 release. There are 28 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 [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Quoted 5 lines
Quoted 3 lines

Responses should be made by August 25 22:00:00 UTC 2007. Anything received after that time might be too late.

What happend to this ??

probably that Greg is currently very busy, as he has not posted for the last 5 days. I can attest it's not always easy to find the time needed to release on time. Give him a few more days. People have seen 2.4.35 drifting by nearly one month after I announced -rc1, so 5 days is really not much here ;-)

Willy