The upstram commit 65d8fc777f6d ("futex: Remove requirement
for lock_page() in get_futex_key()") use variable 'page' as
the page head, when merge it to stable branch, the variable
`page_head` is page head.
In the stable branch, the variable `page` not means the page
head, when lock the page head, we should lock 'page_head',
rather than 'page'.
It maybe lead a hung task problem.
Signed-off-by: ZhangXiaoxu <[email protected]>
Cc: [email protected]
---
kernel/futex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index ec9df5b..15d850f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -593,8 +593,8 @@ again:
* applies. If this is really a shmem page then the page lock
* will prevent unexpected transitions.
*/
- lock_page(page);
- shmem_swizzled = PageSwapCache(page) || page->mapping;
+ lock_page(page_head);
+ shmem_swizzled = PageSwapCache(page_head) || page_head->mapping;
unlock_page(page_head);
put_page(page_head);
--
2.7.4
This patch is for stable branch linux-4.4-y.
On 2019/6/12 9:54, ZhangXiaoxu wrote:
> The upstram commit 65d8fc777f6d ("futex: Remove requirement
> for lock_page() in get_futex_key()") use variable 'page' as
> the page head, when merge it to stable branch, the variable
> `page_head` is page head.
>
> In the stable branch, the variable `page` not means the page
> head, when lock the page head, we should lock 'page_head',
> rather than 'page'.
>
> It maybe lead a hung task problem.
>
> Signed-off-by: ZhangXiaoxu <[email protected]>
> Cc: [email protected]
> ---
> kernel/futex.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index ec9df5b..15d850f 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -593,8 +593,8 @@ again:
> * applies. If this is really a shmem page then the page lock
> * will prevent unexpected transitions.
> */
> - lock_page(page);
> - shmem_swizzled = PageSwapCache(page) || page->mapping;
> + lock_page(page_head);
> + shmem_swizzled = PageSwapCache(page_head) || page_head->mapping;
> unlock_page(page_head);
> put_page(page_head);
>
>
On Wed, Jun 12, 2019 at 09:50:25AM +0800, zhangxiaoxu (A) wrote:
> This patch is for stable branch linux-4.4-y.
>
> On 2019/6/12 9:54, ZhangXiaoxu wrote:
> > The upstram commit 65d8fc777f6d ("futex: Remove requirement
> > for lock_page() in get_futex_key()") use variable 'page' as
> > the page head, when merge it to stable branch, the variable
> > `page_head` is page head.
> >
> > In the stable branch, the variable `page` not means the page
> > head, when lock the page head, we should lock 'page_head',
> > rather than 'page'.
> >
> > It maybe lead a hung task problem.
> >
> > Signed-off-by: ZhangXiaoxu <[email protected]>
> > Cc: [email protected]
> > ---
> > kernel/futex.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
I do not understand.
Please read
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to submit a patch to the stable trees properly.
If the commit is not in Linus's tree, then we can not take it, unless
something is _very_ broken and it is the only way it can be resolved.
thanks,
greg k-h
On Wed, 12 Jun 2019, Greg KH wrote:
> On Wed, Jun 12, 2019 at 09:50:25AM +0800, zhangxiaoxu (A) wrote:
> > This patch is for stable branch linux-4.4-y.
> >
> > On 2019/6/12 9:54, ZhangXiaoxu wrote:
> > > The upstram commit 65d8fc777f6d ("futex: Remove requirement
> > > for lock_page() in get_futex_key()") use variable 'page' as
> > > the page head, when merge it to stable branch, the variable
> > > `page_head` is page head.
> > >
> > > In the stable branch, the variable `page` not means the page
> > > head, when lock the page head, we should lock 'page_head',
> > > rather than 'page'.
> > >
> > > It maybe lead a hung task problem.
> > >
> > > Signed-off-by: ZhangXiaoxu <[email protected]>
> > > Cc: [email protected]
> > > ---
> > > kernel/futex.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> I do not understand.
>
> Please read
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to submit a patch to the stable trees properly.
>
> If the commit is not in Linus's tree, then we can not take it, unless
> something is _very_ broken and it is the only way it can be resolved.
There is something _very_ broken. Upstream is correct but the 4.4. backport
of the above commit is broken (93dcb09e29bb24a86aa7b7eff65e424f7dc98af2) in
the way Zhang described. So it's a 4.4. only issue.
Thanks,
tglx
On Wed, Jun 12, 2019 at 09:29:48AM +0200, Thomas Gleixner wrote:
> On Wed, 12 Jun 2019, Greg KH wrote:
> > On Wed, Jun 12, 2019 at 09:50:25AM +0800, zhangxiaoxu (A) wrote:
> > > This patch is for stable branch linux-4.4-y.
> > >
> > > On 2019/6/12 9:54, ZhangXiaoxu wrote:
> > > > The upstram commit 65d8fc777f6d ("futex: Remove requirement
> > > > for lock_page() in get_futex_key()") use variable 'page' as
> > > > the page head, when merge it to stable branch, the variable
> > > > `page_head` is page head.
> > > >
> > > > In the stable branch, the variable `page` not means the page
> > > > head, when lock the page head, we should lock 'page_head',
> > > > rather than 'page'.
> > > >
> > > > It maybe lead a hung task problem.
> > > >
> > > > Signed-off-by: ZhangXiaoxu <[email protected]>
> > > > Cc: [email protected]
> > > > ---
> > > > kernel/futex.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > I do not understand.
> >
> > Please read
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to submit a patch to the stable trees properly.
> >
> > If the commit is not in Linus's tree, then we can not take it, unless
> > something is _very_ broken and it is the only way it can be resolved.
>
> There is something _very_ broken. Upstream is correct but the 4.4. backport
> of the above commit is broken (93dcb09e29bb24a86aa7b7eff65e424f7dc98af2) in
> the way Zhang described. So it's a 4.4. only issue.
That wasn't obvious at all, and wasn't cc:ed to stable to start with...
Anyway, I'll go queue this up to the 4.4.y tree if no one objects...
thanks,
greg k-h