I'm announcing the release of the 4.9.258 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 9
arch/arm/boot/dts/lpc32xx.dtsi | 3
arch/arm/xen/p2m.c | 6
arch/h8300/kernel/asm-offsets.c | 3
arch/x86/Makefile | 6
arch/x86/xen/p2m.c | 15 -
drivers/block/xen-blkback/blkback.c | 30 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 3
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 5
drivers/net/xen-netback/netback.c | 4
drivers/net/xen-netback/rx.c | 9
drivers/remoteproc/qcom_q6v5_pil.c | 6
drivers/scsi/qla2xxx/qla_tmpl.c | 9
drivers/scsi/qla2xxx/qla_tmpl.h | 2
drivers/usb/dwc3/ulpi.c | 20 +
drivers/xen/gntdev.c | 33 +-
drivers/xen/xen-scsiback.c | 4
fs/fs-writeback.c | 2
fs/overlayfs/copy_up.c | 15 -
fs/squashfs/export.c | 41 ++-
fs/squashfs/id.c | 40 ++-
fs/squashfs/squashfs_fs_sb.h | 1
fs/squashfs/super.c | 6
fs/squashfs/xattr.h | 10
fs/squashfs/xattr_id.c | 66 ++++-
include/linux/backing-dev.h | 10
include/linux/ftrace.h | 4
include/linux/memcontrol.h | 33 ++
include/linux/netdevice.h | 2
include/linux/string.h | 4
include/linux/sunrpc/xdr.h | 3
include/trace/events/writeback.h | 35 +-
include/xen/grant_table.h | 1
kernel/bpf/stackmap.c | 2
kernel/futex.c | 233 +++++++++++++++----
kernel/trace/ftrace.c | 2
kernel/trace/trace.c | 2
kernel/trace/trace_events.c | 3
lib/string.c | 47 +++
mm/backing-dev.c | 1
mm/memblock.c | 48 ---
mm/memcontrol.c | 43 ++-
mm/page-writeback.c | 14 -
net/key/af_key.c | 6
net/netfilter/nf_conntrack_core.c | 3
net/netfilter/xt_recent.c | 12
net/sunrpc/auth_gss/auth_gss.c | 30 --
net/sunrpc/auth_gss/auth_gss_internal.h | 45 +++
net/sunrpc/auth_gss/gss_krb5_mech.c | 31 --
net/vmw_vsock/af_vsock.c | 13 -
net/vmw_vsock/virtio_transport_common.c | 4
scripts/Makefile.build | 3
virt/kvm/kvm_main.c | 3
54 files changed, 680 insertions(+), 308 deletions(-)
Alexandre Belloni (1):
ARM: dts: lpc32xx: Revert set default clock rate of HCLK PLL
Amir Goldstein (1):
ovl: skip getxattr of security labels
Andi Kleen (1):
trace: Use -mcount-record for dynamic ftrace
Arun Easi (1):
scsi: qla2xxx: Fix crash during driver load on big endian machines
Borislav Petkov (1):
x86/build: Disable CET instrumentation in the kernel for 32-bit too
Bui Quang Minh (1):
bpf: Check for integer overflow when using roundup_pow_of_two()
Cong Wang (1):
af_key: relax availability checks for skb size calculation
Dave Wysochanski (2):
SUNRPC: Move simple_get_bytes and simple_get_netobj into private header
SUNRPC: Handle 0 length opaque XDR object data properly
Edwin Peer (1):
net: watchdog: hold device global xmit lock during tx disable
Emmanuel Grumbach (1):
iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap
Felipe Balbi (1):
usb: dwc3: ulpi: fix checkpatch warning
Florian Westphal (1):
netfilter: conntrack: skip identical origin tuple in same zone only
Greg Kroah-Hartman (1):
Linux 4.9.258
Greg Thelen (1):
tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount
Jan Beulich (8):
Xen/x86: don't bail early from clear_foreign_p2m_mapping()
Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
Xen/gntdev: correct error checking in gntdev_map_grant_pages()
xen-blkback: don't "handle" error by BUG()
xen-netback: don't "handle" error by BUG()
xen-scsiback: don't "handle" error by BUG()
xen-blkback: fix error handling in xen_blkbk_map()
Johannes Berg (2):
iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time()
iwlwifi: mvm: guard against device removal in reprobe
Johannes Weiner (1):
mm: memcontrol: fix NULL pointer crash in test_clear_page_writeback()
Jozsef Kadlecsik (1):
netfilter: xt_recent: Fix attempt to update deleted entry
Juergen Gross (1):
xen/netback: avoid race in xenvif_rx_ring_slots_available()
Lai Jiangshan (1):
kvm: check tlbs_dirty directly
Norbert Slusarek (1):
net/vmw_vsock: improve locking in vsock_connect_timeout()
Peter Zijlstra (1):
futex: Change locking rules
Phillip Lougher (3):
squashfs: add more sanity checks in id lookup
squashfs: add more sanity checks in inode lookup
squashfs: add more sanity checks in xattr id lookup
Qian Cai (1):
include/trace/events/writeback.h: fix -Wstringop-truncation warnings
Randy Dunlap (1):
h8300: fix PREEMPTION build, TI_PRE_COUNT undefined
Roman Gushchin (1):
memblock: do not start bottom-up allocations with kernel_end
Serge Semin (1):
usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
Sibi Sankar (1):
remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load
Stefano Garzarella (2):
vsock/virtio: update credit only if socket is not closed
vsock: fix locking in vsock_shutdown()
Stefano Stabellini (1):
xen/arm: don't ignore return errors from set_phys_to_machine
Steven Rostedt (VMware) (3):
fgraph: Initialize tracing_graph_pause at task creation
tracing: Do not count ftrace events in top level enable output
tracing: Check length before giving out the filter buffer
Theodore Ts'o (1):
memcg: fix a crash in wb_workfn when a device disappears
Thomas Gleixner (2):
futex: Ensure the correct return value from futex_lock_pi()
futex: Cure exit race
Tobin C. Harding (1):
lib/string: Add strscpy_pad() function
Vasily Gorbik (1):
tracing: Avoid calling cc-option -mrecord-mcount for every Makefile
On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> I'm announcing the release of the 4.9.258 kernel.
>
> All users of the 4.9 kernel series must upgrade.
>
> The updated 4.9.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> and can be browsed at the normal kernel.org git web browser:
>
The backported futex fixes are still incomplete/broken in this version.
If I enable lockdep and run the futex self-tests (from 5.10):
- on 4.9.246, they pass with no lockdep output
- on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
lockdep splat
I have a local branch that essentially updates futex and rtmutex in
4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
is happy.
Unfortunately, that branch has about another 60 commits. Further, the
more we change futex in 4.9, the more difficult it is going to be to
update the 4.9-rt branch. But I don't see any better option available
at the moment.
Thoughts?
Ben.
--
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett
On Mon, Mar 01, 2021 at 01:13:08AM +0100, Ben Hutchings wrote:
> On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 4.9.258 kernel.
> >
> > All users of the 4.9 kernel series must upgrade.
> >
> > The updated 4.9.y git tree can be found at:
> > ????????git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> > and can be browsed at the normal kernel.org git web browser:
> > ????????
>
> The backported futex fixes are still incomplete/broken in this version.
> If I enable lockdep and run the futex self-tests (from 5.10):
>
> - on 4.9.246, they pass with no lockdep output
> - on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
> lockdep splat
>
> I have a local branch that essentially updates futex and rtmutex in
> 4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
> is happy.
>
> Unfortunately, that branch has about another 60 commits. Further, the
> more we change futex in 4.9, the more difficult it is going to be to
> update the 4.9-rt branch. But I don't see any better option available
> at the moment.
>
> Thoughts?
There were some posted futex fixes for 4.9 (and 4.4) on the stable list
that I have not gotten to yet.
Hopefully after these are merged (this week), these issues will be
resolved.
If not, then yes, they need to be fixed and any help you can provide
would be appreciated.
As for "difficulty", yes, it's rough, but the changes backported were
required, for obvious reasons :(
thanks,
greg k-h
On Mon, 01 Mar 2021, Greg Kroah-Hartman wrote:
> On Mon, Mar 01, 2021 at 01:13:08AM +0100, Ben Hutchings wrote:
> > On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> > > I'm announcing the release of the 4.9.258 kernel.
> > >
> > > All users of the 4.9 kernel series must upgrade.
> > >
> > > The updated 4.9.y git tree can be found at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> > > and can be browsed at the normal kernel.org git web browser:
> > >
> >
> > The backported futex fixes are still incomplete/broken in this version.
> > If I enable lockdep and run the futex self-tests (from 5.10):
> >
> > - on 4.9.246, they pass with no lockdep output
> > - on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
> > lockdep splat
> >
> > I have a local branch that essentially updates futex and rtmutex in
> > 4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
> > is happy.
> >
> > Unfortunately, that branch has about another 60 commits. Further, the
> > more we change futex in 4.9, the more difficult it is going to be to
> > update the 4.9-rt branch. But I don't see any better option available
> > at the moment.
> >
> > Thoughts?
>
> There were some posted futex fixes for 4.9 (and 4.4) on the stable list
> that I have not gotten to yet.
>
> Hopefully after these are merged (this week), these issues will be
> resolved.
>
> If not, then yes, they need to be fixed and any help you can provide
> would be appreciated.
>
> As for "difficulty", yes, it's rough, but the changes backported were
> required, for obvious reasons :(
Apologies for the fuss.
The back-port become more complex the further back it was taken..
Had I known about the self-tests, I would have ensured those were
passing too, as well as the the build/boot/auto-builder tests
actually carried out.
Let me know if there's anything further I can do to help.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Mon, Mar 01, 2021 at 09:07:03AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 01, 2021 at 01:13:08AM +0100, Ben Hutchings wrote:
> > On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> > > I'm announcing the release of the 4.9.258 kernel.
> > >
> > > All users of the 4.9 kernel series must upgrade.
> > >
> > > The updated 4.9.y git tree can be found at:
> > > ????????git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> > > and can be browsed at the normal kernel.org git web browser:
> > > ????????
> >
> > The backported futex fixes are still incomplete/broken in this version.
> > If I enable lockdep and run the futex self-tests (from 5.10):
> >
> > - on 4.9.246, they pass with no lockdep output
> > - on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
> > lockdep splat
> >
> > I have a local branch that essentially updates futex and rtmutex in
> > 4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
> > is happy.
> >
> > Unfortunately, that branch has about another 60 commits.
I have now rebased that on top of 4.9.258, and there are "only" 39
commits.
> > Further, the
> > more we change futex in 4.9, the more difficult it is going to be to
> > update the 4.9-rt branch. But I don't see any better option available
> > at the moment.
> >
> > Thoughts?
>
> There were some posted futex fixes for 4.9 (and 4.4) on the stable list
> that I have not gotten to yet.
>
> Hopefully after these are merged (this week), these issues will be
> resolved.
I'm afraid they are not sufficient.
> If not, then yes, they need to be fixed and any help you can provide
> would be appreciated.
>
> As for "difficulty", yes, it's rough, but the changes backported were
> required, for obvious reasons :(
I had another look at the locking bug and I was able to make a series
of 7 commits (on top of the 2 already queued) that is sufficient to
make lockdep happy. But I am not very confident that there won't be
other regressions. I'll send that over shortly.
Ben.
--
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett
On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
> On Mon, Mar 01, 2021 at 09:07:03AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 01, 2021 at 01:13:08AM +0100, Ben Hutchings wrote:
> > > On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> > > > I'm announcing the release of the 4.9.258 kernel.
> > > >
> > > > All users of the 4.9 kernel series must upgrade.
> > > >
> > > > The updated 4.9.y git tree can be found at:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> > > > and can be browsed at the normal kernel.org git web browser:
> > > >
> > >
> > > The backported futex fixes are still incomplete/broken in this version.
> > > If I enable lockdep and run the futex self-tests (from 5.10):
> > >
> > > - on 4.9.246, they pass with no lockdep output
> > > - on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
> > > lockdep splat
> > >
> > > I have a local branch that essentially updates futex and rtmutex in
> > > 4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
> > > is happy.
> > >
> > > Unfortunately, that branch has about another 60 commits.
>
> I have now rebased that on top of 4.9.258, and there are "only" 39
> commits.
>
> > > Further, the
> > > more we change futex in 4.9, the more difficult it is going to be to
> > > update the 4.9-rt branch. But I don't see any better option available
> > > at the moment.
> > >
> > > Thoughts?
> >
> > There were some posted futex fixes for 4.9 (and 4.4) on the stable list
> > that I have not gotten to yet.
> >
> > Hopefully after these are merged (this week), these issues will be
> > resolved.
>
> I'm afraid they are not sufficient.
>
> > If not, then yes, they need to be fixed and any help you can provide
> > would be appreciated.
> >
> > As for "difficulty", yes, it's rough, but the changes backported were
> > required, for obvious reasons :(
>
> I had another look at the locking bug and I was able to make a series
> of 7 commits (on top of the 2 already queued) that is sufficient to
> make lockdep happy. But I am not very confident that there won't be
> other regressions. I'll send that over shortly.
This is all I had to do to make 4.4-stable a happy camper again.
futex: fix 4.4-stable 34c8e1c2c025 backport inspired lockdep complaint
1. 34c8e1c2c025 "futex: Provide and use pi_state_update_owner()" was backported
to stable, leading to the therein assertion that pi_state->pi_mutex.wait_lock
be held triggering in 4.4-stable. Fixing that leads to lockdep moan part 2.
2: b4abf91047cf "rtmutex: Make wait_lock irq safe" is absent in 4.4-stable, but
wake_futex_pi() nonetheless managed to acquire an unbalanced raw_spin_lock()
raw_spin_inlock_irq() pair, which inspires lockdep to moan after aforementioned
assert has been appeased.
With this applied, futex tests pass, and no longer inspire lockdep gripeage.
Not-Signed-off-by: Mike Galbraith <[email protected]>
---
kernel/futex.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
* and has cleaned up the pi_state already
*/
if (pi_state->owner) {
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);
pi_state_update_owner(pi_state, NULL);
rt_mutex_proxy_unlock(&pi_state->pi_mutex);
+ raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);
}
if (current->pi_state_cache)
@@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
if (pi_state->owner != current)
return -EINVAL;
- raw_spin_lock(&pi_state->pi_mutex.wait_lock);
+ raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
/*
On Thu, 2021-03-04 at 14:11 +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 04, 2021 at 10:12:56AM +0100, Mike Galbraith wrote:
>
> > futex: fix 4.4-stable 34c8e1c2c025 backport inspired lockdep complaint
> >
> > 1. 34c8e1c2c025 "futex: Provide and use pi_state_update_owner()" was backported
> > to stable, leading to the therein assertion that pi_state->pi_mutex.wait_lock
> > be held triggering in 4.4-stable. Fixing that leads to lockdep moan part 2.
> >
> > 2: b4abf91047cf "rtmutex: Make wait_lock irq safe" is absent in 4.4-stable, but
> > wake_futex_pi() nonetheless managed to acquire an unbalanced raw_spin_lock()
> > raw_spin_inlock_irq() pair, which inspires lockdep to moan after aforementioned
> > assert has been appeased.
> >
> > With this applied, futex tests pass, and no longer inspire lockdep gripeage.
> >
> > Not-Signed-off-by: Mike Galbraith <[email protected]>
> > ---
> > kernel/futex.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
> > * and has cleaned up the pi_state already
> > */
> > if (pi_state->owner) {
> > + unsigned long flags;
> > +
> > + raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);
> > pi_state_update_owner(pi_state, NULL);
> > rt_mutex_proxy_unlock(&pi_state->pi_mutex);
> > + raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);
> > }
> >
> > if (current->pi_state_cache)
> > @@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
> > if (pi_state->owner != current)
> > return -EINVAL;
> >
> > - raw_spin_lock(&pi_state->pi_mutex.wait_lock);
> > + raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
> > new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
> >
> > /*
> >
>
> Care to sign-off on it so that if this is correct, I can apply it? :)
Consider it signed off iff Thomas acks it. I think it's correct.. just
like the guys who have installed every other bug in the damn things,
just a wee bit less over-confident :)
-Mike
On Thu, Mar 04, 2021 at 10:12:56AM +0100, Mike Galbraith wrote:
> On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
> > On Mon, Mar 01, 2021 at 09:07:03AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 01, 2021 at 01:13:08AM +0100, Ben Hutchings wrote:
> > > > On Tue, 2021-02-23 at 15:00 +0100, Greg Kroah-Hartman wrote:
> > > > > I'm announcing the release of the 4.9.258 kernel.
> > > > >
> > > > > All users of the 4.9 kernel series must upgrade.
> > > > >
> > > > > The updated 4.9.y git tree can be found at:
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> > > > > and can be browsed at the normal kernel.org git web browser:
> > > > >
> > > >
> > > > The backported futex fixes are still incomplete/broken in this version.
> > > > If I enable lockdep and run the futex self-tests (from 5.10):
> > > >
> > > > - on 4.9.246, they pass with no lockdep output
> > > > - on 4.9.257 and 4.9.258, they pass but futex_requeue_pi trigers a
> > > > lockdep splat
> > > >
> > > > I have a local branch that essentially updates futex and rtmutex in
> > > > 4.9-stable to match 4.14-stable. With this, the tests pass and lockdep
> > > > is happy.
> > > >
> > > > Unfortunately, that branch has about another 60 commits.
> >
> > I have now rebased that on top of 4.9.258, and there are "only" 39
> > commits.
> >
> > > > Further, the
> > > > more we change futex in 4.9, the more difficult it is going to be to
> > > > update the 4.9-rt branch. But I don't see any better option available
> > > > at the moment.
> > > >
> > > > Thoughts?
> > >
> > > There were some posted futex fixes for 4.9 (and 4.4) on the stable list
> > > that I have not gotten to yet.
> > >
> > > Hopefully after these are merged (this week), these issues will be
> > > resolved.
> >
> > I'm afraid they are not sufficient.
> >
> > > If not, then yes, they need to be fixed and any help you can provide
> > > would be appreciated.
> > >
> > > As for "difficulty", yes, it's rough, but the changes backported were
> > > required, for obvious reasons :(
> >
> > I had another look at the locking bug and I was able to make a series
> > of 7 commits (on top of the 2 already queued) that is sufficient to
> > make lockdep happy. But I am not very confident that there won't be
> > other regressions. I'll send that over shortly.
>
> This is all I had to do to make 4.4-stable a happy camper again.
>
> futex: fix 4.4-stable 34c8e1c2c025 backport inspired lockdep complaint
>
> 1. 34c8e1c2c025 "futex: Provide and use pi_state_update_owner()" was backported
> to stable, leading to the therein assertion that pi_state->pi_mutex.wait_lock
> be held triggering in 4.4-stable. Fixing that leads to lockdep moan part 2.
>
> 2: b4abf91047cf "rtmutex: Make wait_lock irq safe" is absent in 4.4-stable, but
> wake_futex_pi() nonetheless managed to acquire an unbalanced raw_spin_lock()
> raw_spin_inlock_irq() pair, which inspires lockdep to moan after aforementioned
> assert has been appeased.
>
> With this applied, futex tests pass, and no longer inspire lockdep gripeage.
>
> Not-Signed-off-by: Mike Galbraith <[email protected]>
> ---
> kernel/futex.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
> * and has cleaned up the pi_state already
> */
> if (pi_state->owner) {
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);
> pi_state_update_owner(pi_state, NULL);
> rt_mutex_proxy_unlock(&pi_state->pi_mutex);
> + raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);
> }
>
> if (current->pi_state_cache)
> @@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
> if (pi_state->owner != current)
> return -EINVAL;
>
> - raw_spin_lock(&pi_state->pi_mutex.wait_lock);
> + raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
> new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
>
> /*
>
Care to sign-off on it so that if this is correct, I can apply it? :)
thanks,
greg k-h
On Thu, Mar 04 2021 at 10:12, Mike Galbraith wrote:
> On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
>
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
> * and has cleaned up the pi_state already
> */
> if (pi_state->owner) {
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);
> pi_state_update_owner(pi_state, NULL);
> rt_mutex_proxy_unlock(&pi_state->pi_mutex);
> + raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);
This hunk is missing in 4.9 as well.
> }
>
> if (current->pi_state_cache)
> @@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
> if (pi_state->owner != current)
> return -EINVAL;
>
> - raw_spin_lock(&pi_state->pi_mutex.wait_lock);
> + raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
> new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
>
> /*
That looks correct.
Thanks,
tglx
On Thu, 2021-03-04 at 19:47 +0100, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 10:12, Mike Galbraith wrote:
> > On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
> >
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
> > * and has cleaned up the pi_state already
> > */
> > if (pi_state->owner) {
> > + unsigned long flags;
> > +
> > + raw_spin_lock_irqsave(&pi_state->pi_mutex.wait_lock, flags);
> > pi_state_update_owner(pi_state, NULL);
> > rt_mutex_proxy_unlock(&pi_state->pi_mutex);
> > + raw_spin_unlock_irqrestore(&pi_state->pi_mutex.wait_lock, flags);
>
> This hunk is missing in 4.9 as well.
>
> > }
> >
> > if (current->pi_state_cache)
> > @@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
> > if (pi_state->owner != current)
> > return -EINVAL;
> >
> > - raw_spin_lock(&pi_state->pi_mutex.wait_lock);
> > + raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
> > new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);
> >
> > /*
>
> That looks correct.
Thanks for the eyeballs. FWIW, updated 4.4.259-rt214 on top of that is
a happy camper as well.
-Mike