[patch 0/7] -stable review

[patch 0/7] -stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.13.4
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 Sunday, October 9, 24:00: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...)

[patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

[Greg KH]

[-- Attachment #1: ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.patch --]
[-- Type: text/plain, Size: 3910 bytes --]

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Fixes for reference counting problems, deadlocks, and delays when SBP-2 devices
are unplugged or unbound from sbp2, or when unloading of sbp2/ ohci1394/ pcilynx
is attempted.

Most often reported symptoms were hotplugs remaining undetected once a FireWire
disk was unplugged since the knodemgrd kernel thread went to uninterruptible
sleep, and "modprobe -r sbp2" being unable to complete because still being in
use.

Patch is equivalent to commit abd559b1052e28d8b9c28aabde241f18fa89090b in
2.6.14-rc3 plus a fix which is necessary together with 2.6.13's scsi core API
(linux1394.org commit r1308 by Ben Collins).

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Ben Collins <bcollins@debian.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/ieee1394/sbp2.c |   38 +++++++++++++++++++++++++++++++++++---
 1 file changed, 35 insertions(+), 3 deletions(-)

--- linux-2.6.13.y.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.13.y/drivers/ieee1394/sbp2.c
@@ -596,6 +596,11 @@ static void sbp2util_mark_command_comple
 	spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 }
 
+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
+{
+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
+}
+
 \f
 
 /*********************************************
@@ -631,11 +636,23 @@ static int sbp2_remove(struct device *de
 {
 	struct unit_directory *ud;
 	struct scsi_id_instance_data *scsi_id;
+	struct scsi_device *sdev;
 
 	SBP2_DEBUG("sbp2_remove");
 
 	ud = container_of(dev, struct unit_directory, device);
 	scsi_id = ud->device.driver_data;
+	if (!scsi_id)
+		return 0;
+
+	/* Trigger shutdown functions in scsi's highlevel. */
+	if (scsi_id->scsi_host)
+		scsi_unblock_requests(scsi_id->scsi_host);
+	sdev = scsi_id->sdev;
+	if (sdev) {
+		scsi_id->sdev = NULL;
+		scsi_remove_device(sdev);
+	}
 
 	sbp2_logout_device(scsi_id);
 	sbp2_remove_device(scsi_id);
@@ -944,6 +961,7 @@ alloc_fail:
 		SBP2_ERR("scsi_add_device failed");
 		return PTR_ERR(sdev);
 	}
+	scsi_device_put(sdev);
 
 	return 0;
 }
@@ -2480,7 +2498,7 @@ static int sbp2scsi_queuecommand(struct 
 	 * If scsi_id is null, it means there is no device in this slot,
 	 * so we should return selection timeout.
 	 */
-	if (!scsi_id) {
+	if (!sbp2util_node_is_available(scsi_id)) {
 		SCpnt->result = DID_NO_CONNECT << 16;
 		done (SCpnt);
 		return 0;
@@ -2683,6 +2701,18 @@ static void sbp2scsi_complete_command(st
 }
 
 
+static int sbp2scsi_slave_alloc(struct scsi_device *sdev)
+{
+	((struct scsi_id_instance_data *)sdev->host->hostdata[0])->sdev = sdev;
+	return 0;
+}
+
+static void sbp2scsi_slave_destroy(struct scsi_device *sdev)
+{
+	((struct scsi_id_instance_data *)sdev->host->hostdata[0])->sdev = NULL;
+	return;
+}
+
 static int sbp2scsi_slave_configure (struct scsi_device *sdev)
 {
 	blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
@@ -2705,7 +2735,7 @@ static int sbp2scsi_abort(struct scsi_cm
 	SBP2_ERR("aborting sbp2 command");
 	scsi_print_command(SCpnt);
 
-	if (scsi_id) {
+	if (sbp2util_node_is_available(scsi_id)) {
 
 		/*
 		 * Right now, just return any matching command structures
@@ -2749,7 +2779,7 @@ static int __sbp2scsi_reset(struct scsi_
 
 	SBP2_ERR("reset requested");
 
-	if (scsi_id) {
+	if (sbp2util_node_is_available(scsi_id)) {
 		SBP2_ERR("Generating sbp2 fetch agent reset");
 		sbp2_agent_reset(scsi_id, 0);
 	}
@@ -2817,7 +2847,9 @@ static struct scsi_host_template scsi_dr
 	.eh_device_reset_handler =	sbp2scsi_reset,
 	.eh_bus_reset_handler =		sbp2scsi_reset,
 	.eh_host_reset_handler =	sbp2scsi_reset,
+	.slave_alloc =			sbp2scsi_slave_alloc,
 	.slave_configure =		sbp2scsi_slave_configure,
+	.slave_destroy =		sbp2scsi_slave_destroy,
 	.this_id =			-1,
 	.sg_tablesize =			SG_ALL,
 	.use_clustering =		ENABLE_CLUSTERING,

--

[patch 2/7] orinoco: Information leakage due to incorrect padding

[Greg KH]

[-- Attachment #1: orinoco-info-leak.patch --]
[-- Type: text/plain, Size: 1460 bytes --]

From: Pavel Roskin <proski@gnu.org>

The orinoco driver can send uninitialized data exposing random pieces of
the system memory.  This happens because data is not padded with zeroes
when its length needs to be increased.

Reported by Meder Kydyraliev <meder@o0o.nu>

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/net/wireless/orinoco.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- linux-2.6.13.y.orig/drivers/net/wireless/orinoco.c
+++ linux-2.6.13.y/drivers/net/wireless/orinoco.c
@@ -502,9 +502,14 @@ static int orinoco_xmit(struct sk_buff *
 		return 0;
 	}
 
-	/* Length of the packet body */
-	/* FIXME: what if the skb is smaller than this? */
-	len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
+	/* Check packet length, pad short packets, round up odd length */
+	len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
+	if (skb->len < len) {
+		skb = skb_padto(skb, len);
+		if (skb == NULL)
+			goto fail;
+	}
+	len -= ETH_HLEN;
 
 	eh = (struct ethhdr *)skb->data;
 
@@ -556,8 +561,7 @@ static int orinoco_xmit(struct sk_buff *
 		p = skb->data;
 	}
 
-	/* Round up for odd length packets */
-	err = hermes_bap_pwrite(hw, USER_BAP, p, ALIGN(data_len, 2),
+	err = hermes_bap_pwrite(hw, USER_BAP, p, data_len,
 				txfid, data_off);
 	if (err) {
 		printk(KERN_ERR "%s: Error %d writing packet to BAP\n",

--

[patch 3/7] [TCP]: BIC coding bug in Linux 2.6.13

[Greg KH]

[-- Attachment #1: tcp-congestion-control-bug.patch --]
[-- Type: text/plain, Size: 977 bytes --]

From: Stephen Hemminger <shemminger@osdl.org>

Please consider this change for 2.6.13-stable   Since BIC is
the default congestion control algorithm, this fix is quite
important.

Missing parenthesis in causes BIC to be slow in increasing congestion
window.

Spotted by Injong Rhee.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 net/ipv4/tcp_bic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.13.y.orig/net/ipv4/tcp_bic.c
+++ linux-2.6.13.y/net/ipv4/tcp_bic.c
@@ -136,7 +136,7 @@ static inline void bictcp_update(struct 
 		else if (cwnd < ca->last_max_cwnd + max_increment*(BICTCP_B-1))
 			/* slow start */
 			ca->cnt = (cwnd * (BICTCP_B-1))
-				/ cwnd-ca->last_max_cwnd;
+				/ (cwnd - ca->last_max_cwnd);
 		else
 			/* linear increase */
 			ca->cnt = cwnd / max_increment;

--

[patch 4/7] sysfs: Signedness problem

[Greg KH]

[-- Attachment #1: drm-module_param-permissions-fix.patch --]
[-- Type: text/plain, Size: 891 bytes --]

From: Dave Jones <davej@redhat.com>

Please consider for next 2.6.13, it is a minor security issue allowing
users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/drm/drm_stub.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.13.y.orig/drivers/char/drm/drm_stub.c
+++ linux-2.6.13.y/drivers/char/drm/drm_stub.c
@@ -47,7 +47,7 @@ MODULE_PARM_DESC(cards_limit, "Maximum n
 MODULE_PARM_DESC(debug, "Enable debug output");
 
 module_param_named(cards_limit, drm_cards_limit, int, 0444);
-module_param_named(debug, drm_debug, int, 0666);
+module_param_named(debug, drm_debug, int, 0600);
 
 drm_head_t **drm_heads;
 struct drm_sysfs_class *drm_class;

--

[patch 5/7] Fix userland FPU state corruption.

[Greg KH]

[-- Attachment #1: fix-sparc64-fpu-register-corruption.patch --]
[-- Type: text/plain, Size: 5355 bytes --]

From: "David S. Miller" <davem@davemloft.net>

We need to use stricter memory barriers around the block
load and store instructions we use to save and restore the
FPU register file.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/sparc64/kernel/entry.S |   39 +++++++++++++++++++++------------------
 arch/sparc64/kernel/rtrap.S |    7 ++++---
 arch/sparc64/lib/VISsave.S  |    8 +++++---
 3 files changed, 30 insertions(+), 24 deletions(-)

--- linux-2.6.13.y.orig/arch/sparc64/kernel/entry.S
+++ linux-2.6.13.y/arch/sparc64/kernel/entry.S
@@ -186,7 +186,7 @@ vmalloc_addr:
 	/* This is trivial with the new code... */
 	.globl		do_fpdis
 do_fpdis:
-	sethi		%hi(TSTATE_PEF), %g4					! IEU0
+	sethi		%hi(TSTATE_PEF), %g4
 	rdpr		%tstate, %g5
 	andcc		%g5, %g4, %g0
 	be,pt		%xcc, 1f
@@ -203,18 +203,18 @@ do_fpdis:
 	add		%g0, %g0, %g0
 	ba,a,pt		%xcc, rtrap_clr_l6
 
-1:	ldub		[%g6 + TI_FPSAVED], %g5					! Load	Group
-	wr		%g0, FPRS_FEF, %fprs					! LSU	Group+4bubbles
-	andcc		%g5, FPRS_FEF, %g0					! IEU1	Group
-	be,a,pt		%icc, 1f						! CTI
-	 clr		%g7							! IEU0
-	ldx		[%g6 + TI_GSR], %g7					! Load	Group
-1:	andcc		%g5, FPRS_DL, %g0					! IEU1
-	bne,pn		%icc, 2f						! CTI
-	 fzero		%f0							! FPA
-	andcc		%g5, FPRS_DU, %g0					! IEU1  Group
-	bne,pn		%icc, 1f						! CTI
-	 fzero		%f2							! FPA
+1:	ldub		[%g6 + TI_FPSAVED], %g5
+	wr		%g0, FPRS_FEF, %fprs
+	andcc		%g5, FPRS_FEF, %g0
+	be,a,pt		%icc, 1f
+	 clr		%g7
+	ldx		[%g6 + TI_GSR], %g7
+1:	andcc		%g5, FPRS_DL, %g0
+	bne,pn		%icc, 2f
+	 fzero		%f0
+	andcc		%g5, FPRS_DU, %g0
+	bne,pn		%icc, 1f
+	 fzero		%f2
 	faddd		%f0, %f2, %f4
 	fmuld		%f0, %f2, %f6
 	faddd		%f0, %f2, %f8
@@ -257,8 +257,10 @@ cplus_fptrap_insn_1:
 	add		%g6, TI_FPREGS + 0xc0, %g2
 	faddd		%f0, %f2, %f8
 	fmuld		%f0, %f2, %f10
-	ldda		[%g1] ASI_BLK_S, %f32	! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f32
 	ldda		[%g2] ASI_BLK_S, %f48
+	membar		#Sync
 	faddd		%f0, %f2, %f12
 	fmuld		%f0, %f2, %f14
 	faddd		%f0, %f2, %f16
@@ -269,7 +271,6 @@ cplus_fptrap_insn_1:
 	fmuld		%f0, %f2, %f26
 	faddd		%f0, %f2, %f28
 	fmuld		%f0, %f2, %f30
-	membar		#Sync
 	b,pt		%xcc, fpdis_exit
 	 nop
 2:	andcc		%g5, FPRS_DU, %g0
@@ -286,8 +287,10 @@ cplus_fptrap_insn_2:
 	add		%g6, TI_FPREGS + 0x40, %g2
 	faddd		%f32, %f34, %f36
 	fmuld		%f32, %f34, %f38
-	ldda		[%g1] ASI_BLK_S, %f0	! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f0
 	ldda		[%g2] ASI_BLK_S, %f16
+	membar		#Sync
 	faddd		%f32, %f34, %f40
 	fmuld		%f32, %f34, %f42
 	faddd		%f32, %f34, %f44
@@ -300,7 +303,6 @@ cplus_fptrap_insn_2:
 	fmuld		%f32, %f34, %f58
 	faddd		%f32, %f34, %f60
 	fmuld		%f32, %f34, %f62
-	membar		#Sync
 	ba,pt		%xcc, fpdis_exit
 	 nop
 3:	mov		SECONDARY_CONTEXT, %g3
@@ -311,7 +313,8 @@ cplus_fptrap_insn_3:
 	stxa		%g2, [%g3] ASI_DMMU
 	membar		#Sync
 	mov		0x40, %g2
-	ldda		[%g1] ASI_BLK_S, %f0		! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f0
 	ldda		[%g1 + %g2] ASI_BLK_S, %f16
 	add		%g1, 0x80, %g1
 	ldda		[%g1] ASI_BLK_S, %f32
--- linux-2.6.13.y.orig/arch/sparc64/kernel/rtrap.S
+++ linux-2.6.13.y/arch/sparc64/kernel/rtrap.S
@@ -310,32 +310,33 @@ kern_fpucheck:	ldub			[%g6 + TI_FPDEPTH]
 		wr			%g1, FPRS_FEF, %fprs
 		ldx			[%o1 + %o5], %g1
 		add			%g6, TI_XFSR, %o1
-		membar			#StoreLoad | #LoadLoad
 		sll			%o0, 8, %o2
 		add			%g6, TI_FPREGS, %o3
 		brz,pn			%l6, 1f
 		 add			%g6, TI_FPREGS+0x40, %o4
 
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f0
 		ldda			[%o4 + %o2] ASI_BLK_P, %f16
+		membar			#Sync
 1:		andcc			%l2, FPRS_DU, %g0
 		be,pn			%icc, 1f
 		 wr			%g1, 0, %gsr
 		add			%o2, 0x80, %o2
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f32
 		ldda			[%o4 + %o2] ASI_BLK_P, %f48
-
 1:		membar			#Sync
 		ldx			[%o1 + %o5], %fsr
 2:		stb			%l5, [%g6 + TI_FPDEPTH]
 		ba,pt			%xcc, rt_continue
 		 nop
 5:		wr			%g0, FPRS_FEF, %fprs
-		membar			#StoreLoad | #LoadLoad
 		sll			%o0, 8, %o2
 
 		add			%g6, TI_FPREGS+0x80, %o3
 		add			%g6, TI_FPREGS+0xc0, %o4
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f32
 		ldda			[%o4 + %o2] ASI_BLK_P, %f48
 		membar			#Sync
--- linux-2.6.13.y.orig/arch/sparc64/lib/VISsave.S
+++ linux-2.6.13.y/arch/sparc64/lib/VISsave.S
@@ -59,15 +59,17 @@ vis1:	ldub		[%g6 + TI_FPSAVED], %g3
 	be,pn		%icc, 9b
 	 add		%g6, TI_FPREGS, %g2
 	andcc		%o5, FPRS_DL, %g0
-	membar		#StoreStore | #LoadStore
 
 	be,pn		%icc, 4f
 	 add		%g6, TI_FPREGS+0x40, %g3
+	membar		#Sync
 	stda		%f0, [%g2 + %g1] ASI_BLK_P
 	stda		%f16, [%g3 + %g1] ASI_BLK_P
+	membar		#Sync
 	andcc		%o5, FPRS_DU, %g0
 	be,pn		%icc, 5f
 4:	 add		%g1, 128, %g1
+	membar		#Sync
 	stda		%f32, [%g2 + %g1] ASI_BLK_P
 
 	stda		%f48, [%g3 + %g1] ASI_BLK_P
@@ -87,7 +89,7 @@ vis1:	ldub		[%g6 + TI_FPSAVED], %g3
 	sll		%g1, 5, %g1
 	add		%g6, TI_FPREGS+0xc0, %g3
 	wr		%g0, FPRS_FEF, %fprs
-	membar		#StoreStore | #LoadStore
+	membar		#Sync
 	stda		%f32, [%g2 + %g1] ASI_BLK_P
 	stda		%f48, [%g3 + %g1] ASI_BLK_P
 	membar		#Sync
@@ -128,8 +130,8 @@ VISenterhalf:
 	be,pn		%icc, 4f
 	 add		%g6, TI_FPREGS, %g2
 
-	membar		#StoreStore | #LoadStore
 	add		%g6, TI_FPREGS+0x40, %g3
+	membar		#Sync
 	stda		%f0, [%g2 + %g1] ASI_BLK_P
 	stda		%f16, [%g3 + %g1] ASI_BLK_P
 	membar		#Sync

--

[patch 6/7] Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

[Greg KH]

[-- Attachment #1: plug-names_cache-memleak.patch --]
[-- Type: text/plain, Size: 1373 bytes --]

From: Linus Torvalds <torvalds@osdl.org>

Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

The nameidata "last.name" is always allocated with "__getname()", and
should always be free'd with "__putname()".

Using "putname()" without the underscores will leak memory, because the
allocation will have been hidden from the AUDITSYSCALL code.

Arguably the real bug is that the AUDITSYSCALL code is really broken,
but in the meantime this fixes the problem people see.

Reported by Robert Derr, patch by Rick Lindsley.

Acked-by: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/namei.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.13.y.orig/fs/namei.c
+++ linux-2.6.13.y/fs/namei.c
@@ -1557,19 +1557,19 @@ do_link:
 	if (nd->last_type != LAST_NORM)
 		goto exit;
 	if (nd->last.name[nd->last.len]) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	error = -ELOOP;
 	if (count++==32) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	dir = nd->dentry;
 	down(&dir->d_inode->i_sem);
 	path.dentry = __lookup_hash(&nd->last, nd->dentry, nd);
 	path.mnt = nd->mnt;
-	putname(nd->last.name);
+	__putname(nd->last.name);
 	goto do_last;
 }
 

--

[patch 7/7] key: plug request_key_auth memleak

[Greg KH]

[-- Attachment #1: key-rka-memleak.patch --]
[-- Type: text/plain, Size: 657 bytes --]

From: David Howells <dhowells@redhat.com>

Plug request_key_auth memleak.  This can be triggered by unprivileged
users, so is local DoS.

Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 security/keys/request_key_auth.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.13.y.orig/security/keys/request_key_auth.c
+++ linux-2.6.13.y/security/keys/request_key_auth.c
@@ -96,6 +96,7 @@ static void request_key_auth_destroy(str
 	kenter("{%d}", key->serial);
 
 	key_put(rka->target_key);
+	kfree(rka);
 
 } /* end request_key_auth_destroy() */
 

--

Re: [patch 4/7] sysfs: Signedness problem

[Dave Jones]

On Fri, Oct 07, 2005 at 04:54:50PM -0700, Greg KH wrote:

 > Please consider for next 2.6.13, it is a minor security issue allowing
 > users to turn on drm debugging when they shouldn't...
 > 
 > This fell through the cracks. Until Josh pointed me at
 > http://bugs.gentoo.org/show_bug.cgi?id=107893
 > 
 > Signed-off-by: Chris Wright <chrisw@osdl.org>
 > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

For those scratching their heads, the subject line came
about as a result of my following up an older issue.
This has nothing to do with signedness of course :-)

		Dave

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

[Greg KH]

On Fri, Oct 07, 2005 at 08:02:52PM -0400, Dave Jones wrote:
> On Fri, Oct 07, 2005 at 04:54:50PM -0700, Greg KH wrote:
> 
>  > Please consider for next 2.6.13, it is a minor security issue allowing
>  > users to turn on drm debugging when they shouldn't...
>  > 
>  > This fell through the cracks. Until Josh pointed me at
>  > http://bugs.gentoo.org/show_bug.cgi?id=107893
>  > 
>  > Signed-off-by: Chris Wright <chrisw@osdl.org>
>  > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> For those scratching their heads, the subject line came
> about as a result of my following up an older issue.
> This has nothing to do with signedness of course :-)

Heh, ok, care to suggest a better Subject: ?

thanks,

greg k-h

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

[Chris Wright]

* Dave Jones (davej@redhat.com) wrote:
> For those scratching their heads, the subject line came
> about as a result of my following up an older issue.
> This has nothing to do with signedness of course :-)

Yes, you're right.  That's my fault for not editing the patch better
before adding it to the queue.

thanks,
-chris

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

[Chris Wright]

* Greg KH (greg@kroah.com) wrote:
> Heh, ok, care to suggest a better Subject: ?

Let's go with what's upstream:

[PATCH] Fix drm 'debug' sysfs permissions

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

[Dave Jones]

On Fri, Oct 07, 2005 at 05:07:20PM -0700, Greg Kroah-Hartman wrote:
 > On Fri, Oct 07, 2005 at 08:02:52PM -0400, Dave Jones wrote:
 > > On Fri, Oct 07, 2005 at 04:54:50PM -0700, Greg KH wrote:
 > > 
 > >  > Please consider for next 2.6.13, it is a minor security issue allowing
 > >  > users to turn on drm debugging when they shouldn't...
 > >  > 
 > >  > This fell through the cracks. Until Josh pointed me at
 > >  > http://bugs.gentoo.org/show_bug.cgi?id=107893
 > >  > 
 > >  > Signed-off-by: Chris Wright <chrisw@osdl.org>
 > >  > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
 > > 
 > > For those scratching their heads, the subject line came
 > > about as a result of my following up an older issue.
 > > This has nothing to do with signedness of course :-)
 > 
 > Heh, ok, care to suggest a better Subject: ?

"Fix incorrect permissions on DRM debug sysfs entry"  ?

		Dave

Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

[Grant Coady]

On Fri, 7 Oct 2005 16:54:22 -0700, Greg KH <gregkh@suse.de> wrote:

>+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
>+{
>+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
>+}
>+
> \f
^^^^^ How did that 0x0c character sneak in there?

Grant.

Re: [stable] Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

[Chris Wright]

* Grant Coady (grant_lkml@dodo.com.au) wrote:
> On Fri, 7 Oct 2005 16:54:22 -0700, Greg KH <gregkh@suse.de> wrote:
> 
> >+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
> >+{
> >+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
> >+}
> >+
> > \f
> ^^^^^ How did that 0x0c character sneak in there?

It's from the patched file (predating the patch, yes it should go, but
that's another story).

thanks,
-chris

Re: [stable] Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

[Stefan Richter]

Chris Wright wrote:
> * Grant Coady (grant_lkml@dodo.com.au) wrote:
>>^^^^^ How did that 0x0c character sneak in there?
> 
> It's from the patched file (predating the patch, yes it should go, but
> that's another story).

Thanks. A code formatting cleanup is on my todo list.
-- 
Stefan Richter
-=====-=-=-= =-=- -=---
http://arcgraph.de/sr/