On Thu, Oct 18 2007, David Miller wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Date: Thu, 18 Oct 2007 12:55:17 +0200
>
> > Things have progressed a lot since, see my recent posting based on
> > Davem's proposal. Will post another patch soonish, that is also
> > tested.
>
> One core issue here
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Thu, 18 Oct 2007 12:55:17 +0200
> Things have progressed a lot since, see my recent posting based on
> Davem's proposal. Will post another patch soonish, that is also
> tested.
One core issue here is that we need to decide whether this thing to be
On Thu, Oct 18 2007, Benny Halevy wrote:
> On Oct. 17, 2007, 20:22 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 17 2007, Linus Torvalds wrote:
> >>
> >> On Wed, 17 Oct 2007, Jens Axboe wrote:
> So avoiding the "sg_next()" on the last entry is pointless.
> >>> Yeah, I didn't
On Oct. 17, 2007, 20:22 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 17 2007, Linus Torvalds wrote:
>>
>> On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the "sg_next()" on the last entry is pointless.
>>> Yeah, I didn't quite understand why if sg was valid, why
On Oct. 17, 2007, 20:22 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the sg_next() on the last entry is pointless.
Yeah, I didn't quite understand why if sg was valid, why dereferencing
*(sg +
On Thu, Oct 18 2007, Benny Halevy wrote:
On Oct. 17, 2007, 20:22 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the sg_next() on the last entry is pointless.
Yeah, I didn't quite understand why if
From: Jens Axboe [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 12:55:17 +0200
Things have progressed a lot since, see my recent posting based on
Davem's proposal. Will post another patch soonish, that is also
tested.
One core issue here is that we need to decide whether this thing to be
iterated
On Thu, Oct 18 2007, David Miller wrote:
From: Jens Axboe [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 12:55:17 +0200
Things have progressed a lot since, see my recent posting based on
Davem's proposal. Will post another patch soonish, that is also
tested.
One core issue here is that we
Il Wed, Oct 17, 2007 at 07:29:32PM +0200, Jens Axboe ha scritto:
> OK, it is fine, as long as the sglist is cleared initially. And I don't
> think there's anyway around that, clearly I didn't think long enough
> before including the memset() removal from Tomo.
>
> Ingo, please try this rolled up
On Wed, 17 Oct 2007, Jens Axboe wrote:
>
> Ah ok, I see why you are confused. The SCSI case is one, it allocs and
> frees the sg table each time. The entries are thus always initialized
> when they end up in blk_rq_map_sg(). However, other drivers allocate one
> at driver init time and use that
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> >
> > For the chain elements - yes, definitely! But we also want to clear dma
> > mapping output values, at least sparc64 wants that. You could argue that
> > the IOMMU code should be fixed up, but I don't
On Wed, 17 Oct 2007, Jens Axboe wrote:
>
> For the chain elements - yes, definitely! But we also want to clear dma
> mapping output values, at least sparc64 wants that. You could argue that
> the IOMMU code should be fixed up, but I don't think we should mix the
> two.
>
> So we need the
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Linus Torvalds wrote:
> >
> > So I think your change to use "sg_next()" only when you actually need a
> > next pointer is the correct one after all.
>
> That still leaves the initialization issue. The link pointers need to
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> > >
> > > So avoiding the "sg_next()" on the last entry is pointless.
> >
> > Yeah, I didn't quite understand why if sg was valid, why dereferencing
> > *(sg + 1)->page would crap out :/
>
> Actually, I
On Wed, 17 Oct 2007, Linus Torvalds wrote:
>
> So I think your change to use "sg_next()" only when you actually need a
> next pointer is the correct one after all.
That still leaves the initialization issue. The link pointers need to all
be initialized at SG allocation time (and not just the
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> > >
> > > - remove the "memset()" you had added earlier. It's bogus. It cannot be
> > >the right thing. If the sg list wasn't initialized correctly much
> > >earlier, trying to initialize it late
On Wed, 17 Oct 2007, Jens Axboe wrote:
> >
> > So avoiding the "sg_next()" on the last entry is pointless.
>
> Yeah, I didn't quite understand why if sg was valid, why dereferencing
> *(sg + 1)->page would crap out :/
Actually, I take that back. If 'sg' is the last entry in a *non*linked
On Wed, 17 Oct 2007, Ingo Molnar wrote:
>
> built and booted your patch (removed Jens's) but it still crashes in
> blk_rq_map_sg() - see below. Should i have left something from Jens's
> patch?
The *real* fix in Jens' patch (and the only thing that really matters) is
the one to
On Wed, 17 Oct 2007, Jens Axboe wrote:
> >
> > - remove the "memset()" you had added earlier. It's bogus. It cannot be
> >the right thing. If the sg list wasn't initialized correctly much
> >earlier, trying to initialize it late is pointless - it contains crap.
>
> It's required to
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But I think the rest of your changes are simply bad.
>
> The fix to block/ll_rw_block.c should likely be something like the
> appended instead:
>
> - remove the "memset()" you had added earlier. It's bogus. It cannot be
>the right thing. If
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> >
> > OK, it is fine, as long as the sglist is cleared initially. And I don't
> > think there's anyway around that, clearly I didn't think long enough
> > before including the memset() removal from Tomo.
>
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Jens Axboe wrote:
> >
> > OK, the below should actually be safe, I don't know why I talked myself
> > into the next_sg stuff in the beginning. It's always safe to zero sg,
> > since it's a valid entry - nothing to save in
On Wed, 17 Oct 2007, Jens Axboe wrote:
>
> OK, it is fine, as long as the sglist is cleared initially. And I don't
> think there's anyway around that, clearly I didn't think long enough
> before including the memset() removal from Tomo.
Ok, I think that one-liner fixes the real bug.
But I
On Wed, 17 Oct 2007, Jens Axboe wrote:
>
> OK, the below should actually be safe, I don't know why I talked myself
> into the next_sg stuff in the beginning. It's always safe to zero sg,
> since it's a valid entry - nothing to save in ->page. Ingo, does this
> work for you?
I really don't
On Wed, Oct 17 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > OK, it is fine, as long as the sglist is cleared initially. And I
> > don't think there's anyway around that, clearly I didn't think long
> > enough before including the memset() removal from Tomo.
> >
>
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> OK, it is fine, as long as the sglist is cleared initially. And I
> don't think there's anyway around that, clearly I didn't think long
> enough before including the memset() removal from Tomo.
>
> Ingo, please try this rolled up version.
>
> Linus,
On Wed, Oct 17 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > - sg = next_sg;
> > > - next_sg = sg_next(sg);
> > > + if (!sg)
> > > + sg = sglist;
> > > + else
> > > +
On Wed, Oct 17 2007, Jens Axboe wrote:
> On Wed, Oct 17 2007, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Jens Axboe wrote:
> > > On Wed, Oct 17 2007, Linus Torvalds wrote:
> > > >
> > > >
> > > > On Wed, 17 Oct 2007, Ingo Molnar wrote:
> > > > >
> > > > > Jens, just got this crash on a testbox:
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > - sg = next_sg;
> > - next_sg = sg_next(sg);
> > + if (!sg)
> > + sg = sglist;
> > + else
> > + sg = sg_next(sg);
> >
> >
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> [...] It's always safe to zero sg, since it's a valid entry - nothing
> to save in ->page. Ingo, does this work for you?
with that patch it not crashes on NULL dereference - see crashlog below.
Compiler bug perhaps?
Ingo
>
[
On Wed, Oct 17 2007, Jens Axboe wrote:
> On Wed, Oct 17 2007, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Linus Torvalds wrote:
> > >
> > >
> > > On Wed, 17 Oct 2007, Ingo Molnar wrote:
> > > >
> > > > Jens, just got this crash on a testbox:
> > >
> > > The code in question is:
> > >
> > >
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > and the oopsing instruction is that load of "sg->page" in the assembly
> > code:
> >
> > mov0x10(%esi),%eax # %eax = sg->page
> > lea0x10(%esi),%edx # %edx = sg+1;
> > test $0x1,%al # if
On Wed, Oct 17 2007, Jens Axboe wrote:
> On Wed, Oct 17 2007, Linus Torvalds wrote:
> >
> >
> > On Wed, 17 Oct 2007, Ingo Molnar wrote:
> > >
> > > Jens, just got this crash on a testbox:
> >
> > The code in question is:
> >
> > mov%edx,0xc(%esp)
> > mov(%ebx),%edi
> >
On Wed, Oct 17 2007, Linus Torvalds wrote:
>
>
> On Wed, 17 Oct 2007, Ingo Molnar wrote:
> >
> > Jens, just got this crash on a testbox:
>
> The code in question is:
>
> mov%edx,0xc(%esp)
> mov(%ebx),%edi
> mov%edi,%edx
> sub%eax,%edx
> mov
On Wed, 17 Oct 2007, Ingo Molnar wrote:
>
> Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp)
mov(%ebx),%edi
mov%edi,%edx
sub%eax,%edx
mov%edx,%eax
sar$0x5,%eax
shl$0xc,%eax
add
On Wed, Oct 17 2007, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i tried another bootup with the same kernel and the crash did not
> > reoccur, so it seems to be spurious. This crash could be related to
> > the scsi or block merges done in the past few days - never
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i tried another bootup with the same kernel and the crash did not
> reoccur, so it seems to be spurious. This crash could be related to
> the scsi or block merges done in the past few days - never saw this
> before.
managed to trigger it a second
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp)
* Jens Axboe [EMAIL PROTECTED] wrote:
[...] It's always safe to zero sg, since it's a valid entry - nothing
to save in -page. Ingo, does this work for you?
with that patch it not crashes on NULL dereference - see crashlog below.
Compiler bug perhaps?
Ingo
[
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in
* Jens Axboe [EMAIL PROTECTED] wrote:
- sg = next_sg;
- next_sg = sg_next(sg);
+ if (!sg)
+ sg = sglist;
+ else
+ sg = sg_next(sg);
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
- sg = next_sg;
- next_sg = sg_next(sg);
+ if (!sg)
+ sg = sglist;
+ else
+ sg =
* Jens Axboe [EMAIL PROTECTED] wrote:
OK, it is fine, as long as the sglist is cleared initially. And I
don't think there's anyway around that, clearly I didn't think long
enough before including the memset() removal from Tomo.
Ingo, please try this rolled up version.
Linus, this
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
OK, it is fine, as long as the sglist is cleared initially. And I
don't think there's anyway around that, clearly I didn't think long
enough before including the memset() removal from Tomo.
Ingo, please
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, the below should actually be safe, I don't know why I talked myself
into the next_sg stuff in the beginning. It's always safe to zero sg,
since it's a valid entry - nothing to save in -page. Ingo, does this
work for you?
I really don't think this
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ok, I
* Linus Torvalds [EMAIL PROTECTED] wrote:
But I think the rest of your changes are simply bad.
The fix to block/ll_rw_block.c should likely be something like the
appended instead:
- remove the memset() you had added earlier. It's bogus. It cannot be
the right thing. If the sg list
On Wed, 17 Oct 2007, Jens Axboe wrote:
- remove the memset() you had added earlier. It's bogus. It cannot be
the right thing. If the sg list wasn't initialized correctly much
earlier, trying to initialize it late is pointless - it contains crap.
It's required to clear output
On Wed, 17 Oct 2007, Ingo Molnar wrote:
built and booted your patch (removed Jens's) but it still crashes in
blk_rq_map_sg() - see below. Should i have left something from Jens's
patch?
The *real* fix in Jens' patch (and the only thing that really matters) is
the one to
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, the below should actually be safe, I don't know why I talked myself
into the next_sg stuff in the beginning. It's always safe to zero sg,
since it's a valid entry - nothing to save in -page. Ingo,
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ok, I think that one-liner fixes the real bug.
But I think
On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the sg_next() on the last entry is pointless.
Yeah, I didn't quite understand why if sg was valid, why dereferencing
*(sg + 1)-page would crap out :/
Actually, I take that back. If 'sg' is the last entry in a *non*linked
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
- remove the memset() you had added earlier. It's bogus. It cannot be
the right thing. If the sg list wasn't initialized correctly much
earlier, trying to initialize it late is pointless -
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the sg_next() on the last entry is pointless.
Yeah, I didn't quite understand why if sg was valid, why dereferencing
*(sg + 1)-page would crap out :/
Actually, I take that back. If
On Wed, 17 Oct 2007, Linus Torvalds wrote:
So I think your change to use sg_next() only when you actually need a
next pointer is the correct one after all.
That still leaves the initialization issue. The link pointers need to all
be initialized at SG allocation time (and not just the last
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Linus Torvalds wrote:
So I think your change to use sg_next() only when you actually need a
next pointer is the correct one after all.
That still leaves the initialization issue. The link pointers need to all
be
On Wed, 17 Oct 2007, Jens Axboe wrote:
For the chain elements - yes, definitely! But we also want to clear dma
mapping output values, at least sparc64 wants that. You could argue that
the IOMMU code should be fixed up, but I don't think we should mix the
two.
So we need the memset() in
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
For the chain elements - yes, definitely! But we also want to clear dma
mapping output values, at least sparc64 wants that. You could argue that
the IOMMU code should be fixed up, but I don't think we
On Wed, 17 Oct 2007, Jens Axboe wrote:
Ah ok, I see why you are confused. The SCSI case is one, it allocs and
frees the sg table each time. The entries are thus always initialized
when they end up in blk_rq_map_sg(). However, other drivers allocate one
at driver init time and use that one
Il Wed, Oct 17, 2007 at 07:29:32PM +0200, Jens Axboe ha scritto:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ingo, please try this rolled up
* Ingo Molnar [EMAIL PROTECTED] wrote:
i tried another bootup with the same kernel and the crash did not
reoccur, so it seems to be spurious. This crash could be related to
the scsi or block merges done in the past few days - never saw this
before.
managed to trigger it a second time, so
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
i tried another bootup with the same kernel and the crash did not
reoccur, so it seems to be spurious. This crash could be related to
the scsi or block merges done in the past few days - never saw this
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp)
mov(%ebx),%edi
mov%edi,%edx
sub%eax,%edx
mov%edx,%eax
sar$0x5,%eax
shl$0xc,%eax
add
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp)
mov(%ebx),%edi
mov%edi,%edx
sub%eax,%edx
mov%edx,%eax
sar
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp)
mov(%ebx),%edi
mov%edi,%edx
* Jens Axboe [EMAIL PROTECTED] wrote:
and the oopsing instruction is that load of sg-page in the assembly
code:
mov0x10(%esi),%eax # %eax = sg-page
lea0x10(%esi),%edx # %edx = sg+1;
test $0x1,%al # if (unlikely(sg_is_chain()))
66 matches
Mail list logo
