[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160116080650.GB566@swordfish>
Date: Sat, 16 Jan 2016 17:06:50 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Minchan Kim <minchan@...nel.org>,
Junil Lee <junil0814.lee@....com>, ngupta@...are.org,
sergey.senozhatsky.work@...il.com, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] zsmalloc: fix migrate_zspage-zs_free race condition
On (01/16/16 08:44), Vlastimil Babka wrote:
> On 16.1.2016 5:09, Sergey Senozhatsky wrote:
> > On (01/15/16 16:49), Vlastimil Babka wrote:
> > [..]
> >>
> >> Could you please also help making the changelog more clear?
> >>
> >>>
> >>>> + free_obj |= BIT(HANDLE_PIN_BIT);
> >>>> record_obj(handle, free_obj);
> >>
> >> I think record_obj() should use WRITE_ONCE() or something like that.
> >> Otherwise the compiler is IMHO allowed to reorder this, i.e. first to assign
> >> free_obj to handle, and then add the PIN bit there.
> >
> > good note.
> >
> > ... or do both things in record_obj() (per Minchan)
> >
> > record_obj(handle, obj)
> > {
> > *(unsigned long)handle = obj & ~(1<<HANDLE_PIN_BIT);
>
> Hmm but that's an unpin, not a pin? A mistake or I'm missing something?
I'm sure it's just a compose-in-mail-app typo.
-ss
> Anyway the compiler can do the same thing here without a WRITE_ONCE().
Powered by blists - more mailing lists