The documented call sequence for removing a host is to call the
transport xxx_remove_host() prior to scsi_remove_host(). The SRP
transport used to crash when that order was followed, but as it is now
fixed, use the documented order.
Signed-off-by: David Dillow <[EMAIL PROTECTED]>
Acked-by: FUJITA
When removing the ib_srp module, srp_remove_one() does not release the
SRP transport class when it is releasing the SCSI host. This leads to
dangling references to kfree()'d memory, and an eventual oops.
Signed-off-by: David Dillow <[EMAIL PROTECTED]>
---
On Fri, 2008-01-04 at 09:47 +0900, FUJITA
The SCSI SRP transport class currently iterates over all children
devices of the host that is being removed in srp_remove_host(). However,
not all of those children were created by the SRP transport, and
removing them will cause corruption and an oops when their creator tries
to remove them.
On Thu, 2008-01-03 at 18:11 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 15:20:09 -0500
> David Dillow <[EMAIL PROTECTED]> wrote:
>
> > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
> > b/drivers/infiniband/ulp/srp/ib_srp.c
> > index 950228f..6e7e3c8 100644
> > ---
The SCSI SRP transport class currently iterates over all children
devices of the host that is being removed in srp_remove_host(). However,
not all of those children were created by the SRP transport, and
removing them will cause corruption and an oops when their creator tries
to remove them.
When removing the ib_srp module, srp_remove_one() does not release the
SRP transport class when it is releasing the SCSI host. This leads to
dangling references to kfree()'d memory, and an eventual oops.
Signed-off-by: David Dillow [EMAIL PROTECTED]
---
On Fri, 2008-01-04 at 09:47 +0900, FUJITA
On Sun, 2007-12-23 at 01:41 +0900, FUJITA Tomonori wrote:
> I think that as Pete pointed out, srp_remove_one needs to call
> srp_remove_host.
>
> Can you try this?
If I need to escape family during the holidays, I'll test it from home.
Otherwise I'll be able to test on Wednesday.
Thanks for the
On Sun, 2007-12-23 at 01:41 +0900, FUJITA Tomonori wrote:
I think that as Pete pointed out, srp_remove_one needs to call
srp_remove_host.
Can you try this?
If I need to escape family during the holidays, I'll test it from home.
Otherwise I'll be able to test on Wednesday.
Thanks for the
On Sun, 2007-08-12 at 23:21 -0700, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Acked-by: Dave Dillow <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Sun, 2007-08-12 at 23:21 -0700, [EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Acked-by: Dave Dillow [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote:
> On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > TODO list currently includes following main items:
> > * redundancy algorithm (drop me a request of your own, but it is highly
> > unlikley that Reed-Solomon based
On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote:
On 7/31/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
TODO list currently includes following main items:
* redundancy algorithm (drop me a request of your own, but it is highly
unlikley that Reed-Solomon based will ever be
On Sat, 2007-05-26 at 16:56 -0400, Jeff Garzik wrote:
> Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different
> hard drive? Preferably a non-Maxtor, or at least not another Maxtor
> 6L200S0. If that's a big deal, don't worry about it. I just want to
> rule out buggy
On Sat, 2007-05-26 at 16:56 -0400, Jeff Garzik wrote:
Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different
hard drive? Preferably a non-Maxtor, or at least not another Maxtor
6L200S0. If that's a big deal, don't worry about it. I just want to
rule out buggy firmware
On Mon, 2007-04-09 at 21:27 -0400, Dave Jones wrote:
> On Mon, Apr 09, 2007 at 06:22:10PM -0400, Dave Dillow wrote:
> > On Mon, 2007-04-09 at 23:35 +0200, Jan Engelhardt wrote:
> > > On Apr 9 2007 15:38, Gene Heskett wrote:
> > > >On Monday 09 April 2007, H. P
ve the reserve-LANANA numbers patch, his incremental
dumps become full ones because device-mapper gets a different dynamic
major.
--
Dave Dillow <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
he initrd, as I don't have a machine
that uses LVM for the root.
--
Dave Dillow <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
for the root.
--
Dave Dillow [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
changes the kernel config, adding any block device that uses
a dynamic major (and is loaded before device-mapper), or goes between
kernels that have the reserve-LANANA numbers patch, his incremental
dumps become full ones because device-mapper gets a different dynamic
major.
--
Dave Dillow [EMAIL
On Mon, 2007-04-09 at 21:27 -0400, Dave Jones wrote:
On Mon, Apr 09, 2007 at 06:22:10PM -0400, Dave Dillow wrote:
On Mon, 2007-04-09 at 23:35 +0200, Jan Engelhardt wrote:
On Apr 9 2007 15:38, Gene Heskett wrote:
On Monday 09 April 2007, H. Peter Anvin wrote:
Jan Engelhardt wrote
On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
> On Wed, 04 Apr 2007 14:17:13 -0400
> Dave Dillow <[EMAIL PROTECTED]> wrote:
> > The thing is, it's been broken for a long time -- this change just
> > highlighted it. This isn't the first time that
On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
> On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Dave Dillow <[EMAIL PROTECTED]> wrote:
> >
> > > > Then it is a matter of figuring out why th
On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
* Dave Dillow [EMAIL PROTECTED] wrote:
Then it is a matter of figuring out why the device number changed --
I'm thinking it is device-mapper
On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
On Wed, 04 Apr 2007 14:17:13 -0400
Dave Dillow [EMAIL PROTECTED] wrote:
The thing is, it's been broken for a long time -- this change just
highlighted it. This isn't the first time that device-mapper has moved
-- the introduction
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
> > [EMAIL PROTECTED] music]# stat .
> > Device: fd00h/64768dInode: 10354963Links: 39
> > Now rebooted to 2.6.21-rc5:
> > De
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
[EMAIL PROTECTED] music]# stat .
Device: fd00h/64768dInode: 10354963Links: 39
Now rebooted to 2.6.21-rc5:
Device: ee00h/60928dInode: 10354963
On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
> >From another email I sent Dave an hour or so ago:
>
> For a good kernel, 2.6.20.3-rdsl-0.31:
> [EMAIL PROTECTED] bad-kernel]# cd /usr/music
> [EMAIL PROTECTED] music]# stat .
> File: `.'
> Size: 4096Blocks: 16 IO
On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
From another email I sent Dave an hour or so ago:
For a good kernel, 2.6.20.3-rdsl-0.31:
[EMAIL PROTECTED] bad-kernel]# cd /usr/music
[EMAIL PROTECTED] music]# stat .
File: `.'
Size: 4096Blocks: 16 IO Block:
ke good notes, especially about avenues of
exploration that come time mind as you chase one code path. It's not
very hard, it's how I learned.
--
Dave Dillow <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
that come time mind as you chase one code path. It's not
very hard, it's how I learned.
--
Dave Dillow [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
30 matches
Mail list logo
