On Mon, 2017-08-28 at 10:05 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Jeffy Chen <[email protected]> > > commit 5da8e47d849d3d37b14129f038782a095b9ad049 upstream. > > It looks like hidp_session_thread has same pattern as the issue reported in > old rfcomm: > > while (1) { > set_current_state(TASK_INTERRUPTIBLE); > if (condition) > break; > // may call might_sleep here > schedule(); > } > __set_current_state(TASK_RUNNING); > > Which fixed at: > dfb2fae Bluetooth: Fix nested sleeps > > So let's fix it at the same way, also follow the suggestion of: > https://lwn.net/Articles/628628/ > > Signed-off-by: Jeffy Chen <[email protected]> > Tested-by: AL Yu-Chen Cho <[email protected]> > Tested-by: Rohit Vaswani <[email protected]> > Signed-off-by: Marcel Holtmann <[email protected]> > Cc: Jiri Slaby <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > --- > net/bluetooth/hidp/core.c | 33 ++++++++++++++++++++++----------- > 1 file changed, 22 insertions(+), 11 deletions(-) > > --- a/net/bluetooth/hidp/core.c > +++ b/net/bluetooth/hidp/core.c [...] > + /* Ensure session->terminate is updated */ > + smp_mb__before_atomic(); > if (atomic_read(&session->terminate)) > break; [...]
smp_mb__before_atomic() is only meant to avoid adding a redundant barrier next to an atomic RMW operation if it already includes one (which is arch-dependent). atomic_read() is not an RMW operation and never includes a barrier, so it needs an smp_mb() before it. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.
