Dan Aloni writes:
> I like your extension to the test program. I have a suggestion for
> the integration inside libaio's harness, since the original issue
> depended on the size of the ring buffer, let's have max_ios be picked
> from {ring->nr + 1, ring->nr - 1, ring->nr}*{1,2,3,4} for the
Dan Aloni d...@kernelim.com writes:
I like your extension to the test program. I have a suggestion for
the integration inside libaio's harness, since the original issue
depended on the size of the ring buffer, let's have max_ios be picked
from {ring-nr + 1, ring-nr - 1, ring-nr}*{1,2,3,4} for
On Fri, Aug 22, 2014 at 02:43:56PM -0700, Linus Torvalds wrote:
> On Fri, Aug 22, 2014 at 11:51 AM, Dan Aloni wrote:
> >
> > Ben, seems that the test program needs some twidling to make the bug
> > appear still by setting MAX_IOS to 256 (and it still passes on a
> > kernel with the original patch
On Mon, Aug 25, 2014 at 03:06:12PM +, Elliott, Robert (Server Storage)
wrote:
> Using this version of the patch, I ran into this crash after 36
> hours of scsi-mq testing over the weekend.
...
>
> local_irq_save(flags);
> kcpu = this_cpu_ptr(ctx->cpu);
>
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Benjamin LaHaise
> Sent: Friday, 22 August, 2014 11:27 AM
...
> Ah, that was missing a hunk then. Try this version instead.
>
...
> diff --git a/fs/aio.c
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Benjamin LaHaise
Sent: Friday, 22 August, 2014 11:27 AM
...
Ah, that was missing a hunk then. Try this version instead.
...
diff --git a/fs/aio.c b/fs/aio.c
On Mon, Aug 25, 2014 at 03:06:12PM +, Elliott, Robert (Server Storage)
wrote:
Using this version of the patch, I ran into this crash after 36
hours of scsi-mq testing over the weekend.
...
local_irq_save(flags);
kcpu = this_cpu_ptr(ctx-cpu);
kcpu-reqs_available
On Fri, Aug 22, 2014 at 02:43:56PM -0700, Linus Torvalds wrote:
On Fri, Aug 22, 2014 at 11:51 AM, Dan Aloni d...@kernelim.com wrote:
Ben, seems that the test program needs some twidling to make the bug
appear still by setting MAX_IOS to 256 (and it still passes on a
kernel with the
On Sun, Aug 24, 2014 at 02:05:31PM -0400, Benjamin LaHaise wrote:
> On Fri, Aug 22, 2014 at 09:51:10PM +0300, Dan Aloni wrote:
> > Ben, seems that the test program needs some twidling to make the bug
> > appear still by setting MAX_IOS to 256 (and it still passes on a
> > kernel with the original
On Fri, Aug 22, 2014 at 02:43:56PM -0700, Linus Torvalds wrote:
> Ugh.
>
> Ben, at this point my gut feel is that we should just revert the
> original "fix", and you should take a much deeper look at this all.
> The original "fix" was more broken then the leak it purported to fix,
> and now the
On Fri, Aug 22, 2014 at 09:51:10PM +0300, Dan Aloni wrote:
> Ben, seems that the test program needs some twidling to make the bug
> appear still by setting MAX_IOS to 256 (and it still passes on a
> kernel with the original patch reverted). Under this condition the
> ring buffer size remains 128
On Fri, Aug 22, 2014 at 09:51:10PM +0300, Dan Aloni wrote:
Ben, seems that the test program needs some twidling to make the bug
appear still by setting MAX_IOS to 256 (and it still passes on a
kernel with the original patch reverted). Under this condition the
ring buffer size remains 128
On Fri, Aug 22, 2014 at 02:43:56PM -0700, Linus Torvalds wrote:
Ugh.
Ben, at this point my gut feel is that we should just revert the
original fix, and you should take a much deeper look at this all.
The original fix was more broken then the leak it purported to fix,
and now the patch to
On Sun, Aug 24, 2014 at 02:05:31PM -0400, Benjamin LaHaise wrote:
On Fri, Aug 22, 2014 at 09:51:10PM +0300, Dan Aloni wrote:
Ben, seems that the test program needs some twidling to make the bug
appear still by setting MAX_IOS to 256 (and it still passes on a
kernel with the original patch
On Fri, Aug 22, 2014 at 11:51 AM, Dan Aloni wrote:
>
> Ben, seems that the test program needs some twidling to make the bug
> appear still by setting MAX_IOS to 256 (and it still passes on a
> kernel with the original patch reverted). Under this condition the
> ring buffer size remains 128 (here,
On Fri, Aug 22, 2014 at 12:26:30PM -0400, Benjamin LaHaise wrote:
> On Fri, Aug 22, 2014 at 07:15:02PM +0300, Dan Aloni wrote:
> > Sorry, I was waiting for a new patch from your direction, I should
> > have replied earlier. What bothered me about the patch you sent is that
> > completed_events is
On Fri, Aug 22, 2014 at 07:15:02PM +0300, Dan Aloni wrote:
> Sorry, I was waiting for a new patch from your direction, I should
> have replied earlier. What bothered me about the patch you sent is that
> completed_events is added as a new field but nothing assigns to it, so I
> wonder how it can
On Fri, Aug 22, 2014 at 12:01:11PM -0400, Benjamin LaHaise wrote:
> On Tue, Aug 19, 2014 at 08:46:51PM -0400, Benjamin LaHaise wrote:
> > You can trigger the behaviour with fio by using userspace event reaping.
> > Adding a test case for that behaviour to libaio would be a good idea.
>
> > I
On Tue, Aug 19, 2014 at 08:46:51PM -0400, Benjamin LaHaise wrote:
> You can trigger the behaviour with fio by using userspace event reaping.
> Adding a test case for that behaviour to libaio would be a good idea.
> I thought about how to fix this, and it isn't actually that hard. Move
> the
On Tue, Aug 19, 2014 at 08:46:51PM -0400, Benjamin LaHaise wrote:
You can trigger the behaviour with fio by using userspace event reaping.
Adding a test case for that behaviour to libaio would be a good idea.
I thought about how to fix this, and it isn't actually that hard. Move
the
On Fri, Aug 22, 2014 at 12:01:11PM -0400, Benjamin LaHaise wrote:
On Tue, Aug 19, 2014 at 08:46:51PM -0400, Benjamin LaHaise wrote:
You can trigger the behaviour with fio by using userspace event reaping.
Adding a test case for that behaviour to libaio would be a good idea.
I thought
On Fri, Aug 22, 2014 at 07:15:02PM +0300, Dan Aloni wrote:
Sorry, I was waiting for a new patch from your direction, I should
have replied earlier. What bothered me about the patch you sent is that
completed_events is added as a new field but nothing assigns to it, so I
wonder how it can be
On Fri, Aug 22, 2014 at 12:26:30PM -0400, Benjamin LaHaise wrote:
On Fri, Aug 22, 2014 at 07:15:02PM +0300, Dan Aloni wrote:
Sorry, I was waiting for a new patch from your direction, I should
have replied earlier. What bothered me about the patch you sent is that
completed_events is added
On Fri, Aug 22, 2014 at 11:51 AM, Dan Aloni d...@kernelim.com wrote:
Ben, seems that the test program needs some twidling to make the bug
appear still by setting MAX_IOS to 256 (and it still passes on a
kernel with the original patch reverted). Under this condition the
ring buffer size
On Tue, Aug 19, 2014 at 08:14:26PM +0300, Dan Aloni wrote:
> On Tue, Aug 19, 2014 at 12:54:04PM -0400, Benjamin LaHaise wrote:
> > On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
> > > Some testing I've done today indicates that the original commit broke
> > > AIO with regard to users
On Tue, Aug 19, 2014 at 12:54:04PM -0400, Benjamin LaHaise wrote:
> On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
> > Some testing I've done today indicates that the original commit broke
> > AIO with regard to users that overflow the maximum number of request
> > per IO context
On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
> Some testing I've done today indicates that the original commit broke
> AIO with regard to users that overflow the maximum number of request
> per IO context (where -EAGAIN is returned).
>
> In fact, it did worse - the attached C
Some testing I've done today indicates that the original commit broke
AIO with regard to users that overflow the maximum number of request
per IO context (where -EAGAIN is returned).
In fact, it did worse - the attached C program can easily overrun the
ring buffer that is responsible for managing
On Tue, Aug 19, 2014 at 08:14:26PM +0300, Dan Aloni wrote:
On Tue, Aug 19, 2014 at 12:54:04PM -0400, Benjamin LaHaise wrote:
On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
Some testing I've done today indicates that the original commit broke
AIO with regard to users that
Some testing I've done today indicates that the original commit broke
AIO with regard to users that overflow the maximum number of request
per IO context (where -EAGAIN is returned).
In fact, it did worse - the attached C program can easily overrun the
ring buffer that is responsible for managing
On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
Some testing I've done today indicates that the original commit broke
AIO with regard to users that overflow the maximum number of request
per IO context (where -EAGAIN is returned).
In fact, it did worse - the attached C program can
On Tue, Aug 19, 2014 at 12:54:04PM -0400, Benjamin LaHaise wrote:
On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
Some testing I've done today indicates that the original commit broke
AIO with regard to users that overflow the maximum number of request
per IO context (where
32 matches
Mail list logo
