2005-10-07 23:55:14

by Greg KH

[permalink] [raw]
Subject: [patch 0/7] -stable review

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 [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 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...)


2005-10-07 23:55:54

by Greg KH

[permalink] [raw]
Subject: [patch 4/7] sysfs: Signedness problem

From: Dave Jones <[email protected]>

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;

--

2005-10-07 23:55:15

by Greg KH

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

From: Stephen Hemminger <[email protected]>

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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;

--

2005-10-07 23:55:06

by Greg KH

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

From: Stefan Richter <[email protected]>

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 <[email protected]>
Cc: Ben Collins <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
+}
+


/*********************************************
@@ -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,

--

2005-10-07 23:56:38

by Greg KH

[permalink] [raw]
Subject: [patch 7/7] key: plug request_key_auth memleak

From: David Howells <[email protected]>

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

Signed-off-by: Chris Wright <[email protected]>
Signed-Off-By: David Howells <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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() */


--

2005-10-07 23:55:55

by Greg KH

[permalink] [raw]
Subject: [patch 6/7] Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

From: Linus Torvalds <[email protected]>

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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}


--

2005-10-07 23:56:38

by Greg KH

[permalink] [raw]
Subject: [patch 5/7] Fix userland FPU state corruption.

From: "David S. Miller" <[email protected]>

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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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

--

2005-10-07 23:55:15

by Greg KH

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

From: Pavel Roskin <[email protected]>

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 <[email protected]>

Signed-off-by: Pavel Roskin <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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",

--

2005-10-08 00:03:46

by Dave Jones

[permalink] [raw]
Subject: Re: [patch 4/7] sysfs: Signedness problem

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 <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2005-10-08 00:07:49

by Greg KH

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

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 <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> 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

2005-10-08 00:09:20

by Chris Wright

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

* Dave Jones ([email protected]) 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

2005-10-08 00:13:15

by Chris Wright

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

* Greg KH ([email protected]) wrote:
> Heh, ok, care to suggest a better Subject: ?

Let's go with what's upstream:

[PATCH] Fix drm 'debug' sysfs permissions

2005-10-08 00:14:59

by Dave Jones

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

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 <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > 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

2005-10-08 00:19:04

by Grant Coady

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

On Fri, 7 Oct 2005 16:54:22 -0700, Greg KH <[email protected]> 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;
>+}
>+
>
^^^^^ How did that 0x0c character sneak in there?

Grant.

2005-10-08 00:21:41

by Chris Wright

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

* Grant Coady ([email protected]) wrote:
> On Fri, 7 Oct 2005 16:54:22 -0700, Greg KH <[email protected]> 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;
> >+}
> >+
> >
> ^^^^^ 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

2005-10-08 10:19:41

by Stefan Richter

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

Chris Wright wrote:
> * Grant Coady ([email protected]) 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/