Re: backport of patches 8238b4579866b7c1bb99883cfe102a43db5506ff and d6ffe6067a54972564552ea45d320fb98db1ac5e

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Oct 03, 2022 at 08:28:06AM -0400, Mikulas Patocka wrote:
> 
> 
> On Sat, 1 Oct 2022, Greg KH wrote:
> 
> > On Fri, Sep 30, 2022 at 11:32:30AM -0400, Mikulas Patocka wrote:
> > > Hi
> > > 
> > > Here I'm submitting backport of patches 
> > > 8238b4579866b7c1bb99883cfe102a43db5506ff and 
> > > d6ffe6067a54972564552ea45d320fb98db1ac5e to the stable branches.
> > 
> > Thanks, but you provide no information as to why these are needed.
> > 
> > What needs them?  They are just adding new functions to the tree from
> > what I can tell.
> > 
> > thanks,
> > 
> > greg k-h
> 
> There's a race condition in wait_on_bit. wait_on_bit tests a bit using the 
> "test_bit" function, however this function doesn't do any memory barrier, 
> so the memory accesses that follow wait_on_bit may be reordered before it 
> and return invalid data.
> 
> Linus didn't want to add a memory barrier to wait_on_bit, he instead 
> wanted to introduce a new function test_bit_acquire that performs the 
> "acquire" memory barrier and use it in wait_on_bit.
> 
> The patch d6ffe6067a54972564552ea45d320fb98db1ac5e fixes an oversight in 
> the patch 8238b4579866b7c1bb99883cfe102a43db5506ff where the function 
> test_bit_acquire was not defined for some architectures and this caused 
> compile failure.
> 
> The backport of the patch 8238b4579866b7c1bb99883cfe102a43db5506ff should 
> be applied first and the backport of the patch 
> d6ffe6067a54972564552ea45d320fb98db1ac5e afterwards.

All now queued up, thanks.

greg k-h