On Mon, 2015-10-19 at 19:24 +0200, William Dauchy wrote:
> On Mon, Oct 19, 2015 at 6:53 PM, William Dauchy
> wrote:
> > On Mon, Oct 19, 2015 at 6:44 PM, Jeff Layton <
> > jlay...@poochiereds.net> wrote:
> > > This should be fixed by this series of four commits that are
> > > already in
> > > mainl
On Mon, Oct 19, 2015 at 6:53 PM, William Dauchy wrote:
> On Mon, Oct 19, 2015 at 6:44 PM, Jeff Layton wrote:
>> This should be fixed by this series of four commits that are already in
>> mainline:
>> bcd7f78d078ff6197715c1ed070c92aca57ec12c..ee296d7c5709440f8abd36b5b65c6
>> b3e388538d9
>
> Am I m
Hi Jeff,
Thank you for you reply.
On Mon, Oct 19, 2015 at 6:44 PM, Jeff Layton wrote:
> This should be fixed by this series of four commits that are already in
> mainline:
> bcd7f78d078ff6197715c1ed070c92aca57ec12c..ee296d7c5709440f8abd36b5b65c6
> b3e388538d9
Am I missing something, I see three
On Mon, 2015-10-19 at 17:18 +0200, William Dauchy wrote:
> Hello Dmitry,
>
> On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton > wrote:
> > Ok, thanks for the explanation. Patch looks fine to me. I'll go
> > ahead
> > and merge it for v4.4. Let me know though if you think this needs
> > to go
> > in s
Hello Dmitry,
On Mon, Oct 19, 2015 at 5:27 PM, Dmitry Vyukov wrote:
> I would expect that you see something else.
> The issue that I fixed would fire very infrequently and unreproducibly.
Thanks for the quick reply. I will open another thread for this issue.
--
William
--
To unsubscribe from th
I would expect that you see something else.
The issue that I fixed would fire very infrequently and unreproducibly.
On Mon, Oct 19, 2015 at 5:18 PM, William Dauchy wrote:
> Hello Dmitry,
>
> On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton wrote:
>> Ok, thanks for the explanation. Patch looks fine
Hello Dmitry,
On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton wrote:
> Ok, thanks for the explanation. Patch looks fine to me. I'll go ahead
> and merge it for v4.4. Let me know though if you think this needs to go
> in sooner.
I am getting a null deref on a v4.1.x
Do you think your patch could fix
No hurry on my side.
Thanks
On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton wrote:
> On Mon, 21 Sep 2015 13:38:45 +0200
> Dmitry Vyukov wrote:
>
>> Yes. That processor is Alpha and that's documented in DATA DEPENDENCY
>> BARRIERS section of Documentation/memory-barriers.txt.
>>
>>
>
> Ok, thanks fo
On Mon, 21 Sep 2015 13:38:45 +0200
Dmitry Vyukov wrote:
> Yes. That processor is Alpha and that's documented in DATA DEPENDENCY
> BARRIERS section of Documentation/memory-barriers.txt.
>
>
Ok, thanks for the explanation. Patch looks fine to me. I'll go ahead
and merge it for v4.4. Let me know
Yes. That processor is Alpha and that's documented in DATA DEPENDENCY
BARRIERS section of Documentation/memory-barriers.txt.
On Mon, Sep 21, 2015 at 1:17 PM, Jeff Layton wrote:
> On Mon, 21 Sep 2015 13:00:04 +0200
> Dmitry Vyukov wrote:
>
>> On Mon, Sep 21, 2015 at 12:56 PM, Jeff Layton
>> w
On Mon, 21 Sep 2015 13:00:04 +0200
Dmitry Vyukov wrote:
> On Mon, Sep 21, 2015 at 12:56 PM, Jeff Layton wrote:
> > On Mon, 21 Sep 2015 12:53:40 +0200
> > Dmitry Vyukov wrote:
> >
> >> On Mon, Sep 21, 2015 at 12:50 PM, Jeff Layton
> >> wrote:
> >> > On Mon, 21 Sep 2015 09:43:06 +0200
> >> > Dm
On Mon, Sep 21, 2015 at 12:56 PM, Jeff Layton wrote:
> On Mon, 21 Sep 2015 12:53:40 +0200
> Dmitry Vyukov wrote:
>
>> On Mon, Sep 21, 2015 at 12:50 PM, Jeff Layton
>> wrote:
>> > On Mon, 21 Sep 2015 09:43:06 +0200
>> > Dmitry Vyukov wrote:
>> >
>> >> locks_get_lock_context() uses cmpxchg() to
On Mon, 21 Sep 2015 12:53:40 +0200
Dmitry Vyukov wrote:
> On Mon, Sep 21, 2015 at 12:50 PM, Jeff Layton wrote:
> > On Mon, 21 Sep 2015 09:43:06 +0200
> > Dmitry Vyukov wrote:
> >
> >> locks_get_lock_context() uses cmpxchg() to install i_flctx.
> >> cmpxchg() is a release operation which is corr
On Mon, Sep 21, 2015 at 12:50 PM, Jeff Layton wrote:
> On Mon, 21 Sep 2015 09:43:06 +0200
> Dmitry Vyukov wrote:
>
>> locks_get_lock_context() uses cmpxchg() to install i_flctx.
>> cmpxchg() is a release operation which is correct. But it uses
>> a plain load to load i_flctx. This is incorrect. S
On Mon, 21 Sep 2015 09:43:06 +0200
Dmitry Vyukov wrote:
> locks_get_lock_context() uses cmpxchg() to install i_flctx.
> cmpxchg() is a release operation which is correct. But it uses
> a plain load to load i_flctx. This is incorrect. Subsequent loads
> from i_flctx can hoist above the load of i_f
locks_get_lock_context() uses cmpxchg() to install i_flctx.
cmpxchg() is a release operation which is correct. But it uses
a plain load to load i_flctx. This is incorrect. Subsequent loads
from i_flctx can hoist above the load of i_flctx pointer itself
and observe uninitialized garbage there. This
16 matches
Mail list logo
