This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 5.2.6-rc1
Yan, Zheng zyan@redhat.com ceph: hold i_ceph_lock when removing caps for freeing inode
Yoshinori Sato ysato@users.sourceforge.jp Fix allyesconfig output.
Miroslav Lichvar mlichvar@redhat.com drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl
Linus Torvalds torvalds@linux-foundation.org /proc/<pid>/cmdline: add back the setproctitle() special case
Linus Torvalds torvalds@linux-foundation.org /proc/<pid>/cmdline: remove all the special cases
Jann Horn jannh@google.com sched/fair: Use RCU accessors consistently for ->numa_group
Jann Horn jannh@google.com sched/fair: Don't free p->numa_faults with concurrent readers
Vladis Dronov vdronov@redhat.com Bluetooth: hci_uart: check for missing tty operations
Marta Rybczynska mrybczyn@kalray.eu nvme: fix multipath crash when ANA is deactivated
Florian Westphal fw@strlen.de xfrm: policy: fix bydst hlist corruption on hash rebuild
Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu media: radio-raremono: change devm_k*alloc to k*alloc
Benjamin Coddington bcodding@redhat.com NFS: Cleanup if nfs_match_client is interrupted
Andrey Konovalov andreyknvl@google.com media: pvrusb2: use a different format for warnings
Oliver Neukum oneukum@suse.com media: cpia2_usb: first wake up, then free in disconnect
Fabio Estevam festevam@gmail.com ath10k: Change the warning message string
Sean Young sean@mess.org media: au0828: fix null dereference in error path
Stanislav Fomichev sdf@google.com bpf: fix NULL deref in btf_type_is_resolve_source_only
Takashi Iwai tiwai@suse.de ALSA: usb-audio: Sanity checks for each pipe and EP types
Phong Tran tranmanphong@gmail.com ISDN: hfcsusb: checking idx of ep configuration
Sunil Muthuswamy sunilmut@microsoft.com vsock: correct removal of socket from the list
-------------
Diffstat:
Makefile | 4 +- arch/sh/boards/Kconfig | 14 +-- drivers/bluetooth/hci_ath.c | 3 + drivers/bluetooth/hci_bcm.c | 3 + drivers/bluetooth/hci_intel.c | 3 + drivers/bluetooth/hci_ldisc.c | 13 +++ drivers/bluetooth/hci_mrvl.c | 3 + drivers/bluetooth/hci_qca.c | 3 + drivers/bluetooth/hci_uart.h | 1 + drivers/isdn/hardware/mISDN/hfcsusb.c | 3 + drivers/media/radio/radio-raremono.c | 30 ++++-- drivers/media/usb/au0828/au0828-core.c | 12 +-- drivers/media/usb/cpia2/cpia2_usb.c | 3 +- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 4 +- drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 6 +- drivers/media/usb/pvrusb2/pvrusb2-std.c | 2 +- drivers/net/wireless/ath/ath10k/usb.c | 2 +- drivers/nvme/host/multipath.c | 8 +- drivers/nvme/host/nvme.h | 6 +- drivers/pps/pps.c | 8 ++ fs/ceph/caps.c | 10 +- fs/ceph/inode.c | 2 +- fs/ceph/super.h | 2 +- fs/exec.c | 2 +- fs/nfs/client.c | 4 +- fs/proc/base.c | 132 +++++++++++++----------- include/linux/sched.h | 10 +- include/linux/sched/numa_balancing.h | 4 +- kernel/bpf/btf.c | 12 +-- kernel/fork.c | 2 +- kernel/sched/fair.c | 144 +++++++++++++++++++-------- net/vmw_vsock/af_vsock.c | 38 ++----- net/xfrm/xfrm_policy.c | 12 ++- sound/usb/helper.c | 17 ++++ sound/usb/helper.h | 1 + sound/usb/quirks.c | 18 +++- tools/testing/selftests/net/xfrm_policy.sh | 27 ++++- 37 files changed, 368 insertions(+), 200 deletions(-)
From: Sunil Muthuswamy sunilmut@microsoft.com
commit d5afa82c977ea06f7119058fa0eb8519ea501031 upstream.
The current vsock code for removal of socket from the list is both subject to race and inefficient. It takes the lock, checks whether the socket is in the list, drops the lock and if the socket was on the list, deletes it from the list. This is subject to race because as soon as the lock is dropped once it is checked for presence, that condition cannot be relied upon for any decision. It is also inefficient because if the socket is present in the list, it takes the lock twice.
Signed-off-by: Sunil Muthuswamy sunilmut@microsoft.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- net/vmw_vsock/af_vsock.c | 38 +++++++------------------------------- 1 file changed, 7 insertions(+), 31 deletions(-)
--- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -274,7 +274,8 @@ EXPORT_SYMBOL_GPL(vsock_insert_connected void vsock_remove_bound(struct vsock_sock *vsk) { spin_lock_bh(&vsock_table_lock); - __vsock_remove_bound(vsk); + if (__vsock_in_bound_table(vsk)) + __vsock_remove_bound(vsk); spin_unlock_bh(&vsock_table_lock); } EXPORT_SYMBOL_GPL(vsock_remove_bound); @@ -282,7 +283,8 @@ EXPORT_SYMBOL_GPL(vsock_remove_bound); void vsock_remove_connected(struct vsock_sock *vsk) { spin_lock_bh(&vsock_table_lock); - __vsock_remove_connected(vsk); + if (__vsock_in_connected_table(vsk)) + __vsock_remove_connected(vsk); spin_unlock_bh(&vsock_table_lock); } EXPORT_SYMBOL_GPL(vsock_remove_connected); @@ -318,35 +320,10 @@ struct sock *vsock_find_connected_socket } EXPORT_SYMBOL_GPL(vsock_find_connected_socket);
-static bool vsock_in_bound_table(struct vsock_sock *vsk) -{ - bool ret; - - spin_lock_bh(&vsock_table_lock); - ret = __vsock_in_bound_table(vsk); - spin_unlock_bh(&vsock_table_lock); - - return ret; -} - -static bool vsock_in_connected_table(struct vsock_sock *vsk) -{ - bool ret; - - spin_lock_bh(&vsock_table_lock); - ret = __vsock_in_connected_table(vsk); - spin_unlock_bh(&vsock_table_lock); - - return ret; -} - void vsock_remove_sock(struct vsock_sock *vsk) { - if (vsock_in_bound_table(vsk)) - vsock_remove_bound(vsk); - - if (vsock_in_connected_table(vsk)) - vsock_remove_connected(vsk); + vsock_remove_bound(vsk); + vsock_remove_connected(vsk); } EXPORT_SYMBOL_GPL(vsock_remove_sock);
@@ -477,8 +454,7 @@ static void vsock_pending_work(struct wo * incoming packets can't find this socket, and to reduce the reference * count. */ - if (vsock_in_connected_table(vsk)) - vsock_remove_connected(vsk); + vsock_remove_connected(vsk);
sk->sk_state = TCP_CLOSE;
From: Phong Tran tranmanphong@gmail.com
commit f384e62a82ba5d85408405fdd6aeff89354deaa9 upstream.
The syzbot test with random endpoint address which made the idx is overflow in the table of endpoint configuations.
this adds the checking for fixing the error report from syzbot
KASAN: stack-out-of-bounds Read in hfcsusb_probe [1] The patch tested by syzbot [2]
Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
[1]: https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb91352... [2]: https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
Signed-off-by: Phong Tran tranmanphong@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c +++ b/drivers/isdn/hardware/mISDN/hfcsusb.c @@ -1955,6 +1955,9 @@ hfcsusb_probe(struct usb_interface *intf
/* get endpoint base */ idx = ((ep_addr & 0x7f) - 1) * 2; + if (idx > 15) + return -EIO; + if (ep_addr & 0x80) idx++; attr = ep->desc.bmAttributes;
From: Takashi Iwai tiwai@suse.de
commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 upstream.
The recent USB core code performs sanity checks for the given pipe and EP types, and it can be hit by manipulated USB descriptors by syzbot. For making syzbot happier, this patch introduces a local helper for a sanity check in the driver side and calls it at each place before the message handling, so that we can avoid the WARNING splats.
Reported-by: syzbot+d952e5e28f5fb7718d23@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- sound/usb/helper.c | 17 +++++++++++++++++ sound/usb/helper.h | 1 + sound/usb/quirks.c | 18 +++++++++++++++--- 3 files changed, 33 insertions(+), 3 deletions(-)
--- a/sound/usb/helper.c +++ b/sound/usb/helper.c @@ -63,6 +63,20 @@ void *snd_usb_find_csint_desc(void *buff return NULL; }
+/* check the validity of pipe and EP types */ +int snd_usb_pipe_sanity_check(struct usb_device *dev, unsigned int pipe) +{ + static const int pipetypes[4] = { + PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT + }; + struct usb_host_endpoint *ep; + + ep = usb_pipe_endpoint(dev, pipe); + if (usb_pipetype(pipe) != pipetypes[usb_endpoint_type(&ep->desc)]) + return -EINVAL; + return 0; +} + /* * Wrapper for usb_control_msg(). * Allocates a temp buffer to prevent dmaing from/to the stack. @@ -75,6 +89,9 @@ int snd_usb_ctl_msg(struct usb_device *d void *buf = NULL; int timeout;
+ if (snd_usb_pipe_sanity_check(dev, pipe)) + return -EINVAL; + if (size > 0) { buf = kmemdup(data, size, GFP_KERNEL); if (!buf) --- a/sound/usb/helper.h +++ b/sound/usb/helper.h @@ -7,6 +7,7 @@ unsigned int snd_usb_combine_bytes(unsig void *snd_usb_find_desc(void *descstart, int desclen, void *after, u8 dtype); void *snd_usb_find_csint_desc(void *descstart, int desclen, void *after, u8 dsubtype);
+int snd_usb_pipe_sanity_check(struct usb_device *dev, unsigned int pipe); int snd_usb_ctl_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8 requesttype, __u16 value, __u16 index, void *data, __u16 size); --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -828,11 +828,13 @@ static int snd_usb_novation_boot_quirk(s static int snd_usb_accessmusic_boot_quirk(struct usb_device *dev) { int err, actual_length; - /* "midi send" enable */ static const u8 seq[] = { 0x4e, 0x73, 0x52, 0x01 }; + void *buf;
- void *buf = kmemdup(seq, ARRAY_SIZE(seq), GFP_KERNEL); + if (snd_usb_pipe_sanity_check(dev, usb_sndintpipe(dev, 0x05))) + return -EINVAL; + buf = kmemdup(seq, ARRAY_SIZE(seq), GFP_KERNEL); if (!buf) return -ENOMEM; err = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x05), buf, @@ -857,7 +859,11 @@ static int snd_usb_accessmusic_boot_quir
static int snd_usb_nativeinstruments_boot_quirk(struct usb_device *dev) { - int ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), + int ret; + + if (snd_usb_pipe_sanity_check(dev, usb_sndctrlpipe(dev, 0))) + return -EINVAL; + ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), 0xaf, USB_TYPE_VENDOR | USB_RECIP_DEVICE, 1, 0, NULL, 0, 1000);
@@ -964,6 +970,8 @@ static int snd_usb_axefx3_boot_quirk(str
dev_dbg(&dev->dev, "Waiting for Axe-Fx III to boot up...\n");
+ if (snd_usb_pipe_sanity_check(dev, usb_sndctrlpipe(dev, 0))) + return -EINVAL; /* If the Axe-Fx III has not fully booted, it will timeout when trying * to enable the audio streaming interface. A more generous timeout is * used here to detect when the Axe-Fx III has finished booting as the @@ -996,6 +1004,8 @@ static int snd_usb_motu_microbookii_comm { int err, actual_length;
+ if (snd_usb_pipe_sanity_check(dev, usb_sndintpipe(dev, 0x01))) + return -EINVAL; err = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x01), buf, *length, &actual_length, 1000); if (err < 0) @@ -1006,6 +1016,8 @@ static int snd_usb_motu_microbookii_comm
memset(buf, 0, buf_size);
+ if (snd_usb_pipe_sanity_check(dev, usb_rcvintpipe(dev, 0x82))) + return -EINVAL; err = usb_interrupt_msg(dev, usb_rcvintpipe(dev, 0x82), buf, buf_size, &actual_length, 1000); if (err < 0)
On Fri, Aug 02, 2019 at 11:39:57AM +0200, Greg Kroah-Hartman wrote:
From: Takashi Iwai tiwai@suse.de
commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 upstream.
The recent USB core code performs sanity checks for the given pipe and EP types, and it can be hit by manipulated USB descriptors by syzbot. For making syzbot happier, this patch introduces a local helper for a sanity check in the driver side and calls it at each place before the message handling, so that we can avoid the WARNING splats.
Reported-by: syzbot+d952e5e28f5fb7718d23@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
This commit has a fix: 5d78e1c2b7f4b ("ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check") which was not pulled by Linus yet.
I'm going to drop this commit and re-queue it together with it's fix once it makes it upstream.
-- Thanks, Sasha
On Fri, Aug 02, 2019 at 09:48:28AM -0400, Sasha Levin wrote:
On Fri, Aug 02, 2019 at 11:39:57AM +0200, Greg Kroah-Hartman wrote:
From: Takashi Iwai tiwai@suse.de
commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 upstream.
The recent USB core code performs sanity checks for the given pipe and EP types, and it can be hit by manipulated USB descriptors by syzbot. For making syzbot happier, this patch introduces a local helper for a sanity check in the driver side and calls it at each place before the message handling, so that we can avoid the WARNING splats.
Reported-by: syzbot+d952e5e28f5fb7718d23@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
This commit has a fix: 5d78e1c2b7f4b ("ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check") which was not pulled by Linus yet.
I'm going to drop this commit and re-queue it together with it's fix once it makes it upstream.
Ah, thanks for doing that.
greg k-h
On Fri, Aug 02, 2019 at 05:51:54PM +0200, Greg Kroah-Hartman wrote:
On Fri, Aug 02, 2019 at 09:48:28AM -0400, Sasha Levin wrote:
On Fri, Aug 02, 2019 at 11:39:57AM +0200, Greg Kroah-Hartman wrote:
From: Takashi Iwai tiwai@suse.de
commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 upstream.
The recent USB core code performs sanity checks for the given pipe and EP types, and it can be hit by manipulated USB descriptors by syzbot. For making syzbot happier, this patch introduces a local helper for a sanity check in the driver side and calls it at each place before the message handling, so that we can avoid the WARNING splats.
Reported-by: syzbot+d952e5e28f5fb7718d23@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
This commit has a fix: 5d78e1c2b7f4b ("ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check") which was not pulled by Linus yet.
I'm going to drop this commit and re-queue it together with it's fix once it makes it upstream.
Ah, thanks for doing that.
Now queued these two commits for 5.2.
-- Thanks, Sasha
From: Stanislav Fomichev sdf@google.com
commit e4f07120210a1794c1f1ae64d209a2fbc7bd2682 upstream.
Commit 1dc92851849c ("bpf: kernel side support for BTF Var and DataSec") added invocations of btf_type_is_resolve_source_only before btf_type_nosize_or_null which checks for the NULL pointer. Swap the order of btf_type_nosize_or_null and btf_type_is_resolve_source_only to make sure the do the NULL pointer check first.
Fixes: 1dc92851849c ("bpf: kernel side support for BTF Var and DataSec") Reported-by: syzbot syzkaller@googlegroups.com Signed-off-by: Stanislav Fomichev sdf@google.com Acked-by: Andrii Nakryiko andriin@fb.com Signed-off-by: Daniel Borkmann daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- kernel/bpf/btf.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
--- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -1928,8 +1928,8 @@ static int btf_array_resolve(struct btf_ /* Check array->index_type */ index_type_id = array->index_type; index_type = btf_type_by_id(btf, index_type_id); - if (btf_type_is_resolve_source_only(index_type) || - btf_type_nosize_or_null(index_type)) { + if (btf_type_nosize_or_null(index_type) || + btf_type_is_resolve_source_only(index_type)) { btf_verifier_log_type(env, v->t, "Invalid index"); return -EINVAL; } @@ -1948,8 +1948,8 @@ static int btf_array_resolve(struct btf_ /* Check array->type */ elem_type_id = array->type; elem_type = btf_type_by_id(btf, elem_type_id); - if (btf_type_is_resolve_source_only(elem_type) || - btf_type_nosize_or_null(elem_type)) { + if (btf_type_nosize_or_null(elem_type) || + btf_type_is_resolve_source_only(elem_type)) { btf_verifier_log_type(env, v->t, "Invalid elem"); return -EINVAL; @@ -2170,8 +2170,8 @@ static int btf_struct_resolve(struct btf const struct btf_type *member_type = btf_type_by_id(env->btf, member_type_id);
- if (btf_type_is_resolve_source_only(member_type) || - btf_type_nosize_or_null(member_type)) { + if (btf_type_nosize_or_null(member_type) || + btf_type_is_resolve_source_only(member_type)) { btf_verifier_log_member(env, v->t, member, "Invalid member"); return -EINVAL;
From: Sean Young sean@mess.org
commit 6d0d1ff9ff21fbb06b867c13a1d41ce8ddcd8230 upstream.
au0828_usb_disconnect() gets the au0828_dev struct via usb_get_intfdata, so it needs to set up for the error paths.
Reported-by: syzbot+357d86bcb4cca1a2f572@syzkaller.appspotmail.com Signed-off-by: Sean Young sean@mess.org Signed-off-by: Mauro Carvalho Chehab mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/usb/au0828/au0828-core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/media/usb/au0828/au0828-core.c +++ b/drivers/media/usb/au0828/au0828-core.c @@ -719,6 +719,12 @@ static int au0828_usb_probe(struct usb_i /* Setup */ au0828_card_setup(dev);
+ /* + * Store the pointer to the au0828_dev so it can be accessed in + * au0828_usb_disconnect + */ + usb_set_intfdata(interface, dev); + /* Analog TV */ retval = au0828_analog_register(dev, interface); if (retval) { @@ -737,12 +743,6 @@ static int au0828_usb_probe(struct usb_i /* Remote controller */ au0828_rc_register(dev);
- /* - * Store the pointer to the au0828_dev so it can be accessed in - * au0828_usb_disconnect - */ - usb_set_intfdata(interface, dev); - pr_info("Registered device AU0828 [%s]\n", dev->board.name == NULL ? "Unset" : dev->board.name);
From: Fabio Estevam festevam@gmail.com
commit 265df32eae5845212ad9f55f5ae6b6dcb68b187b upstream.
The "WARNING" string confuses syzbot, which thinks it found a crash [1].
Change the string to avoid such problem.
[1] https://lkml.org/lkml/2019/5/9/243
Reported-by: syzbot+c1b25598aa60dcd47e78@syzkaller.appspotmail.com Suggested-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Fabio Estevam festevam@gmail.com Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/net/wireless/ath/ath10k/usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/usb.c +++ b/drivers/net/wireless/ath/ath10k/usb.c @@ -1016,7 +1016,7 @@ static int ath10k_usb_probe(struct usb_i }
/* TODO: remove this once USB support is fully implemented */ - ath10k_warn(ar, "WARNING: ath10k USB support is incomplete, don't expect anything to work!\n"); + ath10k_warn(ar, "Warning: ath10k USB support is incomplete, don't expect anything to work!\n");
return 0;
From: Oliver Neukum oneukum@suse.com
commit eff73de2b1600ad8230692f00bc0ab49b166512a upstream.
Kasan reported a use after free in cpia2_usb_disconnect() It first freed everything and then woke up those waiting. The reverse order is correct.
Fixes: 6c493f8b28c67 ("[media] cpia2: major overhaul to get it in a working state again")
Signed-off-by: Oliver Neukum oneukum@suse.com Reported-by: syzbot+0c90fc937c84f97d0aa6@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/usb/cpia2/cpia2_usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/media/usb/cpia2/cpia2_usb.c +++ b/drivers/media/usb/cpia2/cpia2_usb.c @@ -893,7 +893,6 @@ static void cpia2_usb_disconnect(struct cpia2_unregister_camera(cam); v4l2_device_disconnect(&cam->v4l2_dev); mutex_unlock(&cam->v4l2_lock); - v4l2_device_put(&cam->v4l2_dev);
if(cam->buffers) { DBG("Wakeup waiting processes\n"); @@ -902,6 +901,8 @@ static void cpia2_usb_disconnect(struct wake_up_interruptible(&cam->wq_stream); }
+ v4l2_device_put(&cam->v4l2_dev); + LOG("CPiA2 camera disconnected.\n"); }
From: Andrey Konovalov andreyknvl@google.com
commit 1753c7c4367aa1201e1e5d0a601897ab33444af1 upstream.
When the pvrusb2 driver detects that there's something wrong with the device, it prints a warning message. Right now those message are printed in two different formats:
1. ***WARNING*** message here 2. WARNING: message here
There's an issue with the second format. Syzkaller recognizes it as a message produced by a WARN_ON(), which is used to indicate a bug in the kernel. However pvrusb2 prints those warnings to indicate an issue with the device, not the bug in the kernel.
This patch changes the pvrusb2 driver to consistently use the first warning message format. This will unblock syzkaller testing of this driver.
Reported-by: syzbot+af8f8d2ac0d39b0ed3a0@syzkaller.appspotmail.com Reported-by: syzbot+170a86bf206dd2c6217e@syzkaller.appspotmail.com Signed-off-by: Andrey Konovalov andreyknvl@google.com Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 4 ++-- drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 6 +++--- drivers/media/usb/pvrusb2/pvrusb2-std.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c @@ -1670,7 +1670,7 @@ static int pvr2_decoder_enable(struct pv } if (!hdw->flag_decoder_missed) { pvr2_trace(PVR2_TRACE_ERROR_LEGS, - "WARNING: No decoder present"); + "***WARNING*** No decoder present"); hdw->flag_decoder_missed = !0; trace_stbit("flag_decoder_missed", hdw->flag_decoder_missed); @@ -2356,7 +2356,7 @@ struct pvr2_hdw *pvr2_hdw_create(struct if (hdw_desc->flag_is_experimental) { pvr2_trace(PVR2_TRACE_INFO, "**********"); pvr2_trace(PVR2_TRACE_INFO, - "WARNING: Support for this device (%s) is experimental.", + "***WARNING*** Support for this device (%s) is experimental.", hdw_desc->description); pvr2_trace(PVR2_TRACE_INFO, "Important functionality might not be entirely working."); --- a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c @@ -333,11 +333,11 @@ static int i2c_hack_cx25840(struct pvr2_
if ((ret != 0) || (*rdata == 0x04) || (*rdata == 0x0a)) { pvr2_trace(PVR2_TRACE_ERROR_LEGS, - "WARNING: Detected a wedged cx25840 chip; the device will not work."); + "***WARNING*** Detected a wedged cx25840 chip; the device will not work."); pvr2_trace(PVR2_TRACE_ERROR_LEGS, - "WARNING: Try power cycling the pvrusb2 device."); + "***WARNING*** Try power cycling the pvrusb2 device."); pvr2_trace(PVR2_TRACE_ERROR_LEGS, - "WARNING: Disabling further access to the device to prevent other foul-ups."); + "***WARNING*** Disabling further access to the device to prevent other foul-ups."); // This blocks all further communication with the part. hdw->i2c_func[0x44] = NULL; pvr2_hdw_render_useless(hdw); --- a/drivers/media/usb/pvrusb2/pvrusb2-std.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-std.c @@ -343,7 +343,7 @@ struct v4l2_standard *pvr2_std_create_en bcnt = pvr2_std_id_to_str(buf,sizeof(buf),fmsk); pvr2_trace( PVR2_TRACE_ERROR_LEGS, - "WARNING: Failed to classify the following standard(s): %.*s", + "***WARNING*** Failed to classify the following standard(s): %.*s", bcnt,buf); }
From: Benjamin Coddington bcodding@redhat.com
commit 9f7761cf0409465075dadb875d5d4b8ef2f890c8 upstream.
Don't bail out before cleaning up a new allocation if the wait for searching for a matching nfs client is interrupted. Memory leaks.
Reported-by: syzbot+7fe11b49c1cc30e3fce2@syzkaller.appspotmail.com Fixes: 950a578c6128 ("NFS: make nfs_match_client killable") Signed-off-by: Benjamin Coddington bcodding@redhat.com Signed-off-by: Trond Myklebust trond.myklebust@hammerspace.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/nfs/client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -406,10 +406,10 @@ struct nfs_client *nfs_get_client(const clp = nfs_match_client(cl_init); if (clp) { spin_unlock(&nn->nfs_client_lock); - if (IS_ERR(clp)) - return clp; if (new) new->rpc_ops->free_client(new); + if (IS_ERR(clp)) + return clp; return nfs_found_client(cl_init, clp); } if (new) {
From: Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu
commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream.
Change devm_k*alloc to k*alloc to manually allocate memory
The manual allocation and freeing of memory is necessary because when the USB radio is disconnected, the memory associated with devm_k*alloc is freed. Meaning if we still have unresolved references to the radio device, then we get use-after-free errors.
This patch fixes this by manually allocating memory, and freeing it in the v4l2.release callback that gets called when the last radio device exits.
Reported-and-tested-by: syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com
Signed-off-by: Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings] [hverkuil-cisco@xs4all.nl: prefix subject with driver name] Signed-off-by: Mauro Carvalho Chehab mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/radio/radio-raremono.c | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-)
--- a/drivers/media/radio/radio-raremono.c +++ b/drivers/media/radio/radio-raremono.c @@ -271,6 +271,14 @@ static int vidioc_g_frequency(struct fil return 0; }
+static void raremono_device_release(struct v4l2_device *v4l2_dev) +{ + struct raremono_device *radio = to_raremono_dev(v4l2_dev); + + kfree(radio->buffer); + kfree(radio); +} + /* File system interface */ static const struct v4l2_file_operations usb_raremono_fops = { .owner = THIS_MODULE, @@ -295,12 +303,14 @@ static int usb_raremono_probe(struct usb struct raremono_device *radio; int retval = 0;
- radio = devm_kzalloc(&intf->dev, sizeof(struct raremono_device), GFP_KERNEL); - if (radio) - radio->buffer = devm_kmalloc(&intf->dev, BUFFER_LENGTH, GFP_KERNEL); - - if (!radio || !radio->buffer) + radio = kzalloc(sizeof(*radio), GFP_KERNEL); + if (!radio) + return -ENOMEM; + radio->buffer = kmalloc(BUFFER_LENGTH, GFP_KERNEL); + if (!radio->buffer) { + kfree(radio); return -ENOMEM; + }
radio->usbdev = interface_to_usbdev(intf); radio->intf = intf; @@ -324,7 +334,8 @@ static int usb_raremono_probe(struct usb if (retval != 3 || (get_unaligned_be16(&radio->buffer[1]) & 0xfff) == 0x0242) { dev_info(&intf->dev, "this is not Thanko's Raremono.\n"); - return -ENODEV; + retval = -ENODEV; + goto free_mem; }
dev_info(&intf->dev, "Thanko's Raremono connected: (%04X:%04X)\n", @@ -333,7 +344,7 @@ static int usb_raremono_probe(struct usb retval = v4l2_device_register(&intf->dev, &radio->v4l2_dev); if (retval < 0) { dev_err(&intf->dev, "couldn't register v4l2_device\n"); - return retval; + goto free_mem; }
mutex_init(&radio->lock); @@ -345,6 +356,7 @@ static int usb_raremono_probe(struct usb radio->vdev.ioctl_ops = &usb_raremono_ioctl_ops; radio->vdev.lock = &radio->lock; radio->vdev.release = video_device_release_empty; + radio->v4l2_dev.release = raremono_device_release;
usb_set_intfdata(intf, &radio->v4l2_dev);
@@ -360,6 +372,10 @@ static int usb_raremono_probe(struct usb } dev_err(&intf->dev, "could not register video device\n"); v4l2_device_unregister(&radio->v4l2_dev); + +free_mem: + kfree(radio->buffer); + kfree(radio); return retval; }
On Fri, 2019-08-02 at 11:40 +0200, Greg Kroah-Hartman wrote:
From: Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu
commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream.
Change devm_k*alloc to k*alloc to manually allocate memory
The manual allocation and freeing of memory is necessary because when the USB radio is disconnected, the memory associated with devm_k*alloc is freed. Meaning if we still have unresolved references to the radio device, then we get use-after-free errors.
This patch fixes this by manually allocating memory, and freeing it in the v4l2.release callback that gets called when the last radio device exits.
This really should be commented in the code and not just in the commit changelog as some unsuspecting person will likely undo this in the future without one.
Reported-and-tested-by: syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com
Signed-off-by: Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings] [hverkuil-cisco@xs4all.nl: prefix subject with driver name] Signed-off-by: Mauro Carvalho Chehab mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
drivers/media/radio/radio-raremono.c | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-)
--- a/drivers/media/radio/radio-raremono.c +++ b/drivers/media/radio/radio-raremono.c @@ -271,6 +271,14 @@ static int vidioc_g_frequency(struct fil return 0; } +static void raremono_device_release(struct v4l2_device *v4l2_dev) +{
- struct raremono_device *radio = to_raremono_dev(v4l2_dev);
- kfree(radio->buffer);
- kfree(radio);
+}
/* File system interface */ static const struct v4l2_file_operations usb_raremono_fops = { .owner = THIS_MODULE, @@ -295,12 +303,14 @@ static int usb_raremono_probe(struct usb struct raremono_device *radio; int retval = 0;
- radio = devm_kzalloc(&intf->dev, sizeof(struct raremono_device), GFP_KERNEL);
- if (radio)
radio->buffer = devm_kmalloc(&intf->dev, BUFFER_LENGTH, GFP_KERNEL);
- if (!radio || !radio->buffer)
- radio = kzalloc(sizeof(*radio), GFP_KERNEL);
- if (!radio)
return -ENOMEM;
- radio->buffer = kmalloc(BUFFER_LENGTH, GFP_KERNEL);
- if (!radio->buffer) {
return -ENOMEM;kfree(radio);
- }
radio->usbdev = interface_to_usbdev(intf); radio->intf = intf; @@ -324,7 +334,8 @@ static int usb_raremono_probe(struct usb if (retval != 3 || (get_unaligned_be16(&radio->buffer[1]) & 0xfff) == 0x0242) { dev_info(&intf->dev, "this is not Thanko's Raremono.\n");
return -ENODEV;
retval = -ENODEV;
}goto free_mem;
dev_info(&intf->dev, "Thanko's Raremono connected: (%04X:%04X)\n", @@ -333,7 +344,7 @@ static int usb_raremono_probe(struct usb retval = v4l2_device_register(&intf->dev, &radio->v4l2_dev); if (retval < 0) { dev_err(&intf->dev, "couldn't register v4l2_device\n");
return retval;
}goto free_mem;
mutex_init(&radio->lock); @@ -345,6 +356,7 @@ static int usb_raremono_probe(struct usb radio->vdev.ioctl_ops = &usb_raremono_ioctl_ops; radio->vdev.lock = &radio->lock; radio->vdev.release = video_device_release_empty;
- radio->v4l2_dev.release = raremono_device_release;
usb_set_intfdata(intf, &radio->v4l2_dev); @@ -360,6 +372,10 @@ static int usb_raremono_probe(struct usb } dev_err(&intf->dev, "could not register video device\n"); v4l2_device_unregister(&radio->v4l2_dev);
+free_mem:
- kfree(radio->buffer);
- kfree(radio); return retval;
}
Hi there,
On Fri, Aug 02, 2019 at 03:04:25AM -0700, Joe Perches wrote:
On Fri, 2019-08-02 at 11:40 +0200, Greg Kroah-Hartman wrote:
From: Luke Nowakowski-Krijger lnowakow@eng.ucsd.edu
commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream.
Change devm_k*alloc to k*alloc to manually allocate memory
The manual allocation and freeing of memory is necessary because when the USB radio is disconnected, the memory associated with devm_k*alloc is freed. Meaning if we still have unresolved references to the radio device, then we get use-after-free errors.
This patch fixes this by manually allocating memory, and freeing it in the v4l2.release callback that gets called when the last radio device exits.
This really should be commented in the code and not just in the commit changelog as some unsuspecting person will likely undo this in the future without one.
You reckon I should submit a patch with the necessary parts commented?
Thanks, - Luke
From: Florian Westphal fw@strlen.de
commit fd709721352dd5239056eacaded00f2244e6ef58 upstream.
syzbot reported following spat:
BUG: KASAN: use-after-free in __write_once_size include/linux/compiler.h:221 BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455 BUG: KASAN: use-after-free in xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318 Write of size 8 at addr ffff888095e79c00 by task kworker/1:3/8066 Workqueue: events xfrm_hash_rebuild Call Trace: __write_once_size include/linux/compiler.h:221 [inline] hlist_del_rcu include/linux/rculist.h:455 [inline] xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318 process_one_work+0x814/0x1130 kernel/workqueue.c:2269 Allocated by task 8064: __kmalloc+0x23c/0x310 mm/slab.c:3669 kzalloc include/linux/slab.h:742 [inline] xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21 xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline] xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120 ops_init+0x336/0x420 net/core/net_namespace.c:130 setup_net+0x212/0x690 net/core/net_namespace.c:316
The faulting address is the address of the old chain head, free'd by xfrm_hash_resize().
In xfrm_hash_rehash(), chain heads get re-initialized without any hlist_del_rcu:
for (i = hmask; i >= 0; i--) INIT_HLIST_HEAD(odst + i);
Then, hlist_del_rcu() gets called on the about to-be-reinserted policy when iterating the per-net list of policies.
hlist_del_rcu() will then make chain->first be nonzero again:
static inline void __hlist_del(struct hlist_node *n) { struct hlist_node *next = n->next; // address of next element in list struct hlist_node **pprev = n->pprev;// location of previous elem, this // can point at chain->first WRITE_ONCE(*pprev, next); // chain->first points to next elem if (next) next->pprev = pprev;
Then, when we walk chainlist to find insertion point, we may find a non-empty list even though we're supposedly reinserting the first policy to an empty chain.
To fix this first unlink all exact and inexact policies instead of zeroing the list heads.
Add the commands equivalent to the syzbot reproducer to xfrm_policy.sh, without fix KASAN catches the corruption as it happens, SLUB poisoning detects it a bit later.
Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com Fixes: 1548bc4e0512 ("xfrm: policy: delete inexact policies from inexact list on hash rebuild") Signed-off-by: Florian Westphal fw@strlen.de Signed-off-by: Steffen Klassert steffen.klassert@secunet.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- net/xfrm/xfrm_policy.c | 12 +++++++----- tools/testing/selftests/net/xfrm_policy.sh | 27 ++++++++++++++++++++++++++- 2 files changed, 33 insertions(+), 6 deletions(-)
--- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1280,13 +1280,17 @@ static void xfrm_hash_rebuild(struct wor
hlist_for_each_entry_safe(policy, n, &net->xfrm.policy_inexact[dir], - bydst_inexact_list) + bydst_inexact_list) { + hlist_del_rcu(&policy->bydst); hlist_del_init(&policy->bydst_inexact_list); + }
hmask = net->xfrm.policy_bydst[dir].hmask; odst = net->xfrm.policy_bydst[dir].table; - for (i = hmask; i >= 0; i--) - INIT_HLIST_HEAD(odst + i); + for (i = hmask; i >= 0; i--) { + hlist_for_each_entry_safe(policy, n, odst + i, bydst) + hlist_del_rcu(&policy->bydst); + } if ((dir & XFRM_POLICY_MASK) == XFRM_POLICY_OUT) { /* dir out => dst = remote, src = local */ net->xfrm.policy_bydst[dir].dbits4 = rbits4; @@ -1315,8 +1319,6 @@ static void xfrm_hash_rebuild(struct wor chain = policy_hash_bysel(net, &policy->selector, policy->family, dir);
- hlist_del_rcu(&policy->bydst); - if (!chain) { void *p = xfrm_policy_inexact_insert(policy, dir, 0);
--- a/tools/testing/selftests/net/xfrm_policy.sh +++ b/tools/testing/selftests/net/xfrm_policy.sh @@ -257,6 +257,29 @@ check_exceptions() return $lret }
+check_hthresh_repeat() +{ + local log=$1 + i=0 + + for i in $(seq 1 10);do + ip -net ns1 xfrm policy update src e000:0001::0000 dst ff01::0014:0000:0001 dir in tmpl src :: dst :: proto esp mode tunnel priority 100 action allow || break + ip -net ns1 xfrm policy set hthresh6 0 28 || break + + ip -net ns1 xfrm policy update src e000:0001::0000 dst ff01::01 dir in tmpl src :: dst :: proto esp mode tunnel priority 100 action allow || break + ip -net ns1 xfrm policy set hthresh6 0 28 || break + done + + if [ $i -ne 10 ] ;then + echo "FAIL: $log" 1>&2 + ret=1 + return 1 + fi + + echo "PASS: $log" + return 0 +} + #check for needed privileges if [ "$(id -u)" -ne 0 ];then echo "SKIP: Need root privileges" @@ -404,7 +427,9 @@ for n in ns3 ns4;do ip -net $n xfrm policy set hthresh4 32 32 hthresh6 128 128 sleep $((RANDOM%5)) done -check_exceptions "exceptions and block policies after hresh change to normal" +check_exceptions "exceptions and block policies after htresh change to normal" + +check_hthresh_repeat "policies with repeated htresh change"
for i in 1 2 3 4;do ip netns del ns$i;done
From: Marta Rybczynska mrybczyn@kalray.eu
commit 66b20ac0a1a10769d059d6903202f53494e3d902 upstream.
Fix a crash with multipath activated. It happends when ANA log page is larger than MDTS and because of that ANA is disabled. The driver then tries to access unallocated buffer when connecting to a nvme target. The signature is as follows:
[ 300.433586] nvme nvme0: ANA log page size (8208) larger than MDTS (8192). [ 300.435387] nvme nvme0: disabling ANA support. [ 300.437835] nvme nvme0: creating 4 I/O queues. [ 300.459132] nvme nvme0: new ctrl: NQN "nqn.0.0.0", addr 10.91.0.1:8009 [ 300.464609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 300.466342] #PF error: [normal kernel read fault] [ 300.467385] PGD 0 P4D 0 [ 300.467987] Oops: 0000 [#1] SMP PTI [ 300.468787] CPU: 3 PID: 50 Comm: kworker/u8:1 Not tainted 5.0.20kalray+ #4 [ 300.470264] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 300.471532] Workqueue: nvme-wq nvme_scan_work [nvme_core] [ 300.472724] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.474038] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.477374] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296 [ 300.478334] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000 [ 300.479784] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258 [ 300.481488] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 [ 300.483203] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0 [ 300.484928] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0 [ 300.486626] FS: 0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000 [ 300.488538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 300.489907] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0 [ 300.491612] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 300.493303] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 300.494991] Call Trace: [ 300.495645] nvme_mpath_add_disk+0x5c/0xb0 [nvme_core] [ 300.496880] nvme_validate_ns+0x2ef/0x550 [nvme_core] [ 300.498105] ? nvme_identify_ctrl.isra.45+0x6a/0xb0 [nvme_core] [ 300.499539] nvme_scan_work+0x2b4/0x370 [nvme_core] [ 300.500717] ? __switch_to_asm+0x35/0x70 [ 300.501663] process_one_work+0x171/0x380 [ 300.502340] worker_thread+0x49/0x3f0 [ 300.503079] kthread+0xf8/0x130 [ 300.503795] ? max_active_store+0x80/0x80 [ 300.504690] ? kthread_bind+0x10/0x10 [ 300.505502] ret_from_fork+0x35/0x40 [ 300.506280] Modules linked in: nvme_tcp nvme_rdma rdma_cm iw_cm ib_cm ib_core nvme_fabrics nvme_core xt_physdev ip6table_raw ip6table_mangle ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_CHECKSUM iptable_mangle iptable_filter veth ebtable_filter ebtable_nat ebtables iptable_raw vxlan ip6_udp_tunnel udp_tunnel sunrpc joydev pcspkr virtio_balloon br_netfilter bridge stp llc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net virtio_console net_failover virtio_blk failover ata_piix serio_raw libata virtio_pci virtio_ring virtio [ 300.514984] CR2: 0000000000000008 [ 300.515569] ---[ end trace faa2eefad7e7f218 ]--- [ 300.516354] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.517330] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.520353] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296 [ 300.521229] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000 [ 300.522399] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258 [ 300.523560] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 [ 300.524734] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0 [ 300.525915] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0 [ 300.527084] FS: 0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000 [ 300.528396] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 300.529440] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0 [ 300.530739] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 300.531989] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 300.533264] Kernel panic - not syncing: Fatal exception [ 300.534338] Kernel Offset: 0x17c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 300.536227] ---[ end Kernel panic - not syncing: Fatal exception ]---
Condition check refactoring from Christoph Hellwig.
Signed-off-by: Marta Rybczynska marta.rybczynska@kalray.eu Tested-by: Jean-Baptiste Riaux jbriaux@kalray.eu Signed-off-by: Christoph Hellwig hch@lst.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/nvme/host/multipath.c | 8 ++------ drivers/nvme/host/nvme.h | 6 +++++- 2 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -12,11 +12,6 @@ module_param(multipath, bool, 0444); MODULE_PARM_DESC(multipath, "turn on native support for multiple controllers per subsystem");
-inline bool nvme_ctrl_use_ana(struct nvme_ctrl *ctrl) -{ - return multipath && ctrl->subsys && (ctrl->subsys->cmic & (1 << 3)); -} - /* * If multipathing is enabled we need to always use the subsystem instance * number for numbering our devices to avoid conflicts between subsystems that @@ -614,7 +609,8 @@ int nvme_mpath_init(struct nvme_ctrl *ct { int error;
- if (!nvme_ctrl_use_ana(ctrl)) + /* check if multipath is enabled and we have the capability */ + if (!multipath || !ctrl->subsys || !(ctrl->subsys->cmic & (1 << 3))) return 0;
ctrl->anacap = id->anacap; --- a/drivers/nvme/host/nvme.h +++ b/drivers/nvme/host/nvme.h @@ -472,7 +472,11 @@ extern const struct attribute_group *nvm extern const struct block_device_operations nvme_ns_head_ops;
#ifdef CONFIG_NVME_MULTIPATH -bool nvme_ctrl_use_ana(struct nvme_ctrl *ctrl); +static inline bool nvme_ctrl_use_ana(struct nvme_ctrl *ctrl) +{ + return ctrl->ana_log_buf != NULL; +} + void nvme_set_disk_name(char *disk_name, struct nvme_ns *ns, struct nvme_ctrl *ctrl, int *flags); void nvme_failover_req(struct request *req);
From: Vladis Dronov vdronov@redhat.com
commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream.
Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset() functions which are called by the certain HCI UART protocols (hci_ath, hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control() or directly. This leads to an execution at NULL and can be triggered by an unprivileged user. Fix this by adding a helper function and a check for the missing tty operations in the protocols code.
This fixes CVE-2019-10207. The Fixes: lines list commits where calls to tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART protocols.
Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa5... Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org # v2.6.36+ Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip") Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions") Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support") Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Vladis Dronov vdronov@redhat.com Signed-off-by: Marcel Holtmann marcel@holtmann.org Reviewed-by: Yu-Chen, Cho acho@suse.com Tested-by: Yu-Chen, Cho acho@suse.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/bluetooth/hci_ath.c | 3 +++ drivers/bluetooth/hci_bcm.c | 3 +++ drivers/bluetooth/hci_intel.c | 3 +++ drivers/bluetooth/hci_ldisc.c | 13 +++++++++++++ drivers/bluetooth/hci_mrvl.c | 3 +++ drivers/bluetooth/hci_qca.c | 3 +++ drivers/bluetooth/hci_uart.h | 1 + 7 files changed, 29 insertions(+)
--- a/drivers/bluetooth/hci_ath.c +++ b/drivers/bluetooth/hci_ath.c @@ -98,6 +98,9 @@ static int ath_open(struct hci_uart *hu)
BT_DBG("hu %p", hu);
+ if (!hci_uart_has_flow_control(hu)) + return -EOPNOTSUPP; + ath = kzalloc(sizeof(*ath), GFP_KERNEL); if (!ath) return -ENOMEM; --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -406,6 +406,9 @@ static int bcm_open(struct hci_uart *hu)
bt_dev_dbg(hu->hdev, "hu %p", hu);
+ if (!hci_uart_has_flow_control(hu)) + return -EOPNOTSUPP; + bcm = kzalloc(sizeof(*bcm), GFP_KERNEL); if (!bcm) return -ENOMEM; --- a/drivers/bluetooth/hci_intel.c +++ b/drivers/bluetooth/hci_intel.c @@ -391,6 +391,9 @@ static int intel_open(struct hci_uart *h
BT_DBG("hu %p", hu);
+ if (!hci_uart_has_flow_control(hu)) + return -EOPNOTSUPP; + intel = kzalloc(sizeof(*intel), GFP_KERNEL); if (!intel) return -ENOMEM; --- a/drivers/bluetooth/hci_ldisc.c +++ b/drivers/bluetooth/hci_ldisc.c @@ -284,6 +284,19 @@ static int hci_uart_send_frame(struct hc return 0; }
+/* Check the underlying device or tty has flow control support */ +bool hci_uart_has_flow_control(struct hci_uart *hu) +{ + /* serdev nodes check if the needed operations are present */ + if (hu->serdev) + return true; + + if (hu->tty->driver->ops->tiocmget && hu->tty->driver->ops->tiocmset) + return true; + + return false; +} + /* Flow control or un-flow control the device */ void hci_uart_set_flow_control(struct hci_uart *hu, bool enable) { --- a/drivers/bluetooth/hci_mrvl.c +++ b/drivers/bluetooth/hci_mrvl.c @@ -52,6 +52,9 @@ static int mrvl_open(struct hci_uart *hu
BT_DBG("hu %p", hu);
+ if (!hci_uart_has_flow_control(hu)) + return -EOPNOTSUPP; + mrvl = kzalloc(sizeof(*mrvl), GFP_KERNEL); if (!mrvl) return -ENOMEM; --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -458,6 +458,9 @@ static int qca_open(struct hci_uart *hu)
BT_DBG("hu %p qca_open", hu);
+ if (!hci_uart_has_flow_control(hu)) + return -EOPNOTSUPP; + qca = kzalloc(sizeof(struct qca_data), GFP_KERNEL); if (!qca) return -ENOMEM; --- a/drivers/bluetooth/hci_uart.h +++ b/drivers/bluetooth/hci_uart.h @@ -103,6 +103,7 @@ int hci_uart_tx_wakeup(struct hci_uart * int hci_uart_init_ready(struct hci_uart *hu); void hci_uart_init_work(struct work_struct *work); void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed); +bool hci_uart_has_flow_control(struct hci_uart *hu); void hci_uart_set_flow_control(struct hci_uart *hu, bool enable); void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed, unsigned int oper_speed);
From: Jann Horn jannh@google.com
commit 16d51a590a8ce3befb1308e0e7ab77f3b661af33 upstream.
When going through execve(), zero out the NUMA fault statistics instead of freeing them.
During execve, the task is reachable through procfs and the scheduler. A concurrent /proc/*/sched reader can read data from a freed ->numa_faults allocation (confirmed by KASAN) and write it back to userspace. I believe that it would also be possible for a use-after-free read to occur through a race between a NUMA fault and execve(): task_numa_fault() can lead to task_numa_compare(), which invokes task_weight() on the currently running task of a different CPU.
Another way to fix this would be to make ->numa_faults RCU-managed or add extra locking, but it seems easier to wipe the NUMA fault statistics on execve.
Signed-off-by: Jann Horn jannh@google.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Peter Zijlstra peterz@infradead.org Cc: Petr Mladek pmladek@suse.com Cc: Sergey Senozhatsky sergey.senozhatsky@gmail.com Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will@kernel.org Fixes: 82727018b0d3 ("sched/numa: Call task_numa_free() from do_execve()") Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/exec.c | 2 +- include/linux/sched/numa_balancing.h | 4 ++-- kernel/fork.c | 2 +- kernel/sched/fair.c | 24 ++++++++++++++++++++---- 4 files changed, 24 insertions(+), 8 deletions(-)
--- a/fs/exec.c +++ b/fs/exec.c @@ -1828,7 +1828,7 @@ static int __do_execve_file(int fd, stru membarrier_execve(current); rseq_execve(current); acct_update_integrals(current); - task_numa_free(current); + task_numa_free(current, false); free_bprm(bprm); kfree(pathbuf); if (filename) --- a/include/linux/sched/numa_balancing.h +++ b/include/linux/sched/numa_balancing.h @@ -19,7 +19,7 @@ extern void task_numa_fault(int last_node, int node, int pages, int flags); extern pid_t task_numa_group_id(struct task_struct *p); extern void set_numabalancing_state(bool enabled); -extern void task_numa_free(struct task_struct *p); +extern void task_numa_free(struct task_struct *p, bool final); extern bool should_numa_migrate_memory(struct task_struct *p, struct page *page, int src_nid, int dst_cpu); #else @@ -34,7 +34,7 @@ static inline pid_t task_numa_group_id(s static inline void set_numabalancing_state(bool enabled) { } -static inline void task_numa_free(struct task_struct *p) +static inline void task_numa_free(struct task_struct *p, bool final) { } static inline bool should_numa_migrate_memory(struct task_struct *p, --- a/kernel/fork.c +++ b/kernel/fork.c @@ -727,7 +727,7 @@ void __put_task_struct(struct task_struc WARN_ON(tsk == current);
cgroup_free(tsk); - task_numa_free(tsk); + task_numa_free(tsk, true); security_task_free(tsk); exit_creds(tsk); delayacct_tsk_free(tsk); --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2336,13 +2336,23 @@ no_join: return; }
-void task_numa_free(struct task_struct *p) +/* + * Get rid of NUMA staticstics associated with a task (either current or dead). + * If @final is set, the task is dead and has reached refcount zero, so we can + * safely free all relevant data structures. Otherwise, there might be + * concurrent reads from places like load balancing and procfs, and we should + * reset the data back to default state without freeing ->numa_faults. + */ +void task_numa_free(struct task_struct *p, bool final) { struct numa_group *grp = p->numa_group; - void *numa_faults = p->numa_faults; + unsigned long *numa_faults = p->numa_faults; unsigned long flags; int i;
+ if (!numa_faults) + return; + if (grp) { spin_lock_irqsave(&grp->lock, flags); for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++) @@ -2355,8 +2365,14 @@ void task_numa_free(struct task_struct * put_numa_group(grp); }
- p->numa_faults = NULL; - kfree(numa_faults); + if (final) { + p->numa_faults = NULL; + kfree(numa_faults); + } else { + p->total_numa_faults = 0; + for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++) + numa_faults[i] = 0; + } }
/*
From: Jann Horn jannh@google.com
commit cb361d8cdef69990f6b4504dc1fd9a594d983c97 upstream.
The old code used RCU annotations and accessors inconsistently for ->numa_group, which can lead to use-after-frees and NULL dereferences.
Let all accesses to ->numa_group use proper RCU helpers to prevent such issues.
Signed-off-by: Jann Horn jannh@google.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Peter Zijlstra peterz@infradead.org Cc: Petr Mladek pmladek@suse.com Cc: Sergey Senozhatsky sergey.senozhatsky@gmail.com Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will@kernel.org Fixes: 8c8a743c5087 ("sched/numa: Use {cpu, pid} to create task groups for shared faults") Link: https://lkml.kernel.org/r/20190716152047.14424-3-jannh@google.com Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- include/linux/sched.h | 10 +++- kernel/sched/fair.c | 120 +++++++++++++++++++++++++++++++++----------------- 2 files changed, 90 insertions(+), 40 deletions(-)
--- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1026,7 +1026,15 @@ struct task_struct { u64 last_sum_exec_runtime; struct callback_head numa_work;
- struct numa_group *numa_group; + /* + * This pointer is only modified for current in syscall and + * pagefault context (and for tasks being destroyed), so it can be read + * from any of the following contexts: + * - RCU read-side critical section + * - current->numa_group from everywhere + * - task's runqueue locked, task not running + */ + struct numa_group __rcu *numa_group;
/* * numa_faults is an array split into four regions: --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1067,6 +1067,21 @@ struct numa_group { unsigned long faults[0]; };
+/* + * For functions that can be called in multiple contexts that permit reading + * ->numa_group (see struct task_struct for locking rules). + */ +static struct numa_group *deref_task_numa_group(struct task_struct *p) +{ + return rcu_dereference_check(p->numa_group, p == current || + (lockdep_is_held(&task_rq(p)->lock) && !READ_ONCE(p->on_cpu))); +} + +static struct numa_group *deref_curr_numa_group(struct task_struct *p) +{ + return rcu_dereference_protected(p->numa_group, p == current); +} + static inline unsigned long group_faults_priv(struct numa_group *ng); static inline unsigned long group_faults_shared(struct numa_group *ng);
@@ -1110,10 +1125,12 @@ static unsigned int task_scan_start(stru { unsigned long smin = task_scan_min(p); unsigned long period = smin; + struct numa_group *ng;
/* Scale the maximum scan period with the amount of shared memory. */ - if (p->numa_group) { - struct numa_group *ng = p->numa_group; + rcu_read_lock(); + ng = rcu_dereference(p->numa_group); + if (ng) { unsigned long shared = group_faults_shared(ng); unsigned long private = group_faults_priv(ng);
@@ -1121,6 +1138,7 @@ static unsigned int task_scan_start(stru period *= shared + 1; period /= private + shared + 1; } + rcu_read_unlock();
return max(smin, period); } @@ -1129,13 +1147,14 @@ static unsigned int task_scan_max(struct { unsigned long smin = task_scan_min(p); unsigned long smax; + struct numa_group *ng;
/* Watch for min being lower than max due to floor calculations */ smax = sysctl_numa_balancing_scan_period_max / task_nr_scan_windows(p);
/* Scale the maximum scan period with the amount of shared memory. */ - if (p->numa_group) { - struct numa_group *ng = p->numa_group; + ng = deref_curr_numa_group(p); + if (ng) { unsigned long shared = group_faults_shared(ng); unsigned long private = group_faults_priv(ng); unsigned long period = smax; @@ -1167,7 +1186,7 @@ void init_numa_balancing(unsigned long c p->numa_scan_period = sysctl_numa_balancing_scan_delay; p->numa_work.next = &p->numa_work; p->numa_faults = NULL; - p->numa_group = NULL; + RCU_INIT_POINTER(p->numa_group, NULL); p->last_task_numa_placement = 0; p->last_sum_exec_runtime = 0;
@@ -1214,7 +1233,16 @@ static void account_numa_dequeue(struct
pid_t task_numa_group_id(struct task_struct *p) { - return p->numa_group ? p->numa_group->gid : 0; + struct numa_group *ng; + pid_t gid = 0; + + rcu_read_lock(); + ng = rcu_dereference(p->numa_group); + if (ng) + gid = ng->gid; + rcu_read_unlock(); + + return gid; }
/* @@ -1239,11 +1267,13 @@ static inline unsigned long task_faults(
static inline unsigned long group_faults(struct task_struct *p, int nid) { - if (!p->numa_group) + struct numa_group *ng = deref_task_numa_group(p); + + if (!ng) return 0;
- return p->numa_group->faults[task_faults_idx(NUMA_MEM, nid, 0)] + - p->numa_group->faults[task_faults_idx(NUMA_MEM, nid, 1)]; + return ng->faults[task_faults_idx(NUMA_MEM, nid, 0)] + + ng->faults[task_faults_idx(NUMA_MEM, nid, 1)]; }
static inline unsigned long group_faults_cpu(struct numa_group *group, int nid) @@ -1381,12 +1411,13 @@ static inline unsigned long task_weight( static inline unsigned long group_weight(struct task_struct *p, int nid, int dist) { + struct numa_group *ng = deref_task_numa_group(p); unsigned long faults, total_faults;
- if (!p->numa_group) + if (!ng) return 0;
- total_faults = p->numa_group->total_faults; + total_faults = ng->total_faults;
if (!total_faults) return 0; @@ -1400,7 +1431,7 @@ static inline unsigned long group_weight bool should_numa_migrate_memory(struct task_struct *p, struct page * page, int src_nid, int dst_cpu) { - struct numa_group *ng = p->numa_group; + struct numa_group *ng = deref_curr_numa_group(p); int dst_nid = cpu_to_node(dst_cpu); int last_cpupid, this_cpupid;
@@ -1583,13 +1614,14 @@ static bool load_too_imbalanced(long src static void task_numa_compare(struct task_numa_env *env, long taskimp, long groupimp, bool maymove) { + struct numa_group *cur_ng, *p_ng = deref_curr_numa_group(env->p); struct rq *dst_rq = cpu_rq(env->dst_cpu); + long imp = p_ng ? groupimp : taskimp; struct task_struct *cur; long src_load, dst_load; - long load; - long imp = env->p->numa_group ? groupimp : taskimp; - long moveimp = imp; int dist = env->dist; + long moveimp = imp; + long load;
if (READ_ONCE(dst_rq->numa_migrate_on)) return; @@ -1628,21 +1660,22 @@ static void task_numa_compare(struct tas * If dst and source tasks are in the same NUMA group, or not * in any group then look only at task weights. */ - if (cur->numa_group == env->p->numa_group) { + cur_ng = rcu_dereference(cur->numa_group); + if (cur_ng == p_ng) { imp = taskimp + task_weight(cur, env->src_nid, dist) - task_weight(cur, env->dst_nid, dist); /* * Add some hysteresis to prevent swapping the * tasks within a group over tiny differences. */ - if (cur->numa_group) + if (cur_ng) imp -= imp / 16; } else { /* * Compare the group weights. If a task is all by itself * (not part of a group), use the task weight instead. */ - if (cur->numa_group && env->p->numa_group) + if (cur_ng && p_ng) imp += group_weight(cur, env->src_nid, dist) - group_weight(cur, env->dst_nid, dist); else @@ -1740,11 +1773,12 @@ static int task_numa_migrate(struct task .best_imp = 0, .best_cpu = -1, }; + unsigned long taskweight, groupweight; struct sched_domain *sd; + long taskimp, groupimp; + struct numa_group *ng; struct rq *best_rq; - unsigned long taskweight, groupweight; int nid, ret, dist; - long taskimp, groupimp;
/* * Pick the lowest SD_NUMA domain, as that would have the smallest @@ -1790,7 +1824,8 @@ static int task_numa_migrate(struct task * multiple NUMA nodes; in order to better consolidate the group, * we need to check other locations. */ - if (env.best_cpu == -1 || (p->numa_group && p->numa_group->active_nodes > 1)) { + ng = deref_curr_numa_group(p); + if (env.best_cpu == -1 || (ng && ng->active_nodes > 1)) { for_each_online_node(nid) { if (nid == env.src_nid || nid == p->numa_preferred_nid) continue; @@ -1823,7 +1858,7 @@ static int task_numa_migrate(struct task * A task that migrated to a second choice node will be better off * trying for a better one later. Do not set the preferred node here. */ - if (p->numa_group) { + if (ng) { if (env.best_cpu == -1) nid = env.src_nid; else @@ -2118,6 +2153,7 @@ static void task_numa_placement(struct t unsigned long total_faults; u64 runtime, period; spinlock_t *group_lock = NULL; + struct numa_group *ng;
/* * The p->mm->numa_scan_seq field gets updated without @@ -2135,8 +2171,9 @@ static void task_numa_placement(struct t runtime = numa_get_avg_runtime(p, &period);
/* If the task is part of a group prevent parallel updates to group stats */ - if (p->numa_group) { - group_lock = &p->numa_group->lock; + ng = deref_curr_numa_group(p); + if (ng) { + group_lock = &ng->lock; spin_lock_irq(group_lock); }
@@ -2177,7 +2214,7 @@ static void task_numa_placement(struct t p->numa_faults[cpu_idx] += f_diff; faults += p->numa_faults[mem_idx]; p->total_numa_faults += diff; - if (p->numa_group) { + if (ng) { /* * safe because we can only change our own group * @@ -2185,14 +2222,14 @@ static void task_numa_placement(struct t * nid and priv in a specific region because it * is at the beginning of the numa_faults array. */ - p->numa_group->faults[mem_idx] += diff; - p->numa_group->faults_cpu[mem_idx] += f_diff; - p->numa_group->total_faults += diff; - group_faults += p->numa_group->faults[mem_idx]; + ng->faults[mem_idx] += diff; + ng->faults_cpu[mem_idx] += f_diff; + ng->total_faults += diff; + group_faults += ng->faults[mem_idx]; } }
- if (!p->numa_group) { + if (!ng) { if (faults > max_faults) { max_faults = faults; max_nid = nid; @@ -2203,8 +2240,8 @@ static void task_numa_placement(struct t } }
- if (p->numa_group) { - numa_group_count_active_nodes(p->numa_group); + if (ng) { + numa_group_count_active_nodes(ng); spin_unlock_irq(group_lock); max_nid = preferred_group_nid(p, max_nid); } @@ -2238,7 +2275,7 @@ static void task_numa_group(struct task_ int cpu = cpupid_to_cpu(cpupid); int i;
- if (unlikely(!p->numa_group)) { + if (unlikely(!deref_curr_numa_group(p))) { unsigned int size = sizeof(struct numa_group) + 4*nr_node_ids*sizeof(unsigned long);
@@ -2274,7 +2311,7 @@ static void task_numa_group(struct task_ if (!grp) goto no_join;
- my_grp = p->numa_group; + my_grp = deref_curr_numa_group(p); if (grp == my_grp) goto no_join;
@@ -2345,7 +2382,8 @@ no_join: */ void task_numa_free(struct task_struct *p, bool final) { - struct numa_group *grp = p->numa_group; + /* safe: p either is current or is being freed by current */ + struct numa_group *grp = rcu_dereference_raw(p->numa_group); unsigned long *numa_faults = p->numa_faults; unsigned long flags; int i; @@ -2425,7 +2463,7 @@ void task_numa_fault(int last_cpupid, in * actively using should be counted as local. This allows the * scan rate to slow down when a workload has settled down. */ - ng = p->numa_group; + ng = deref_curr_numa_group(p); if (!priv && !local && ng && ng->active_nodes > 1 && numa_is_active_node(cpu_node, ng) && numa_is_active_node(mem_node, ng)) @@ -10724,18 +10762,22 @@ void show_numa_stats(struct task_struct { int node; unsigned long tsf = 0, tpf = 0, gsf = 0, gpf = 0; + struct numa_group *ng;
+ rcu_read_lock(); + ng = rcu_dereference(p->numa_group); for_each_online_node(node) { if (p->numa_faults) { tsf = p->numa_faults[task_faults_idx(NUMA_MEM, node, 0)]; tpf = p->numa_faults[task_faults_idx(NUMA_MEM, node, 1)]; } - if (p->numa_group) { - gsf = p->numa_group->faults[task_faults_idx(NUMA_MEM, node, 0)], - gpf = p->numa_group->faults[task_faults_idx(NUMA_MEM, node, 1)]; + if (ng) { + gsf = ng->faults[task_faults_idx(NUMA_MEM, node, 0)], + gpf = ng->faults[task_faults_idx(NUMA_MEM, node, 1)]; } print_numa_stats(m, node, tsf, tpf, gsf, gpf); } + rcu_read_unlock(); } #endif /* CONFIG_NUMA_BALANCING */ #endif /* CONFIG_SCHED_DEBUG */
From: Linus Torvalds torvalds@linux-foundation.org
commit 3d712546d8ba9f25cdf080d79f90482aa4231ed4 upstream.
Start off with a clean slate that only reads exactly from arg_start to arg_end, without any oddities. This simplifies the code and in the process removes the case that caused us to potentially leak an uninitialized byte from the temporary kernel buffer.
Note that in order to start from scratch with an understandable base, this simplifies things _too_ much, and removes all the legacy logic to handle setproctitle() having changed the argument strings.
We'll add back those special cases very differently in the next commit.
Link: https://lore.kernel.org/lkml/20190712160913.17727-1-izbyshev@ispras.ru/ Fixes: f5b65348fd77 ("proc: fix missing final NUL in get_mm_cmdline() rewrite") Cc: Alexey Izbyshev izbyshev@ispras.ru Cc: Alexey Dobriyan adobriyan@gmail.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/proc/base.c | 71 ++++++--------------------------------------------------- 1 file changed, 8 insertions(+), 63 deletions(-)
--- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -212,7 +212,7 @@ static int proc_root_link(struct dentry static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf, size_t count, loff_t *ppos) { - unsigned long arg_start, arg_end, env_start, env_end; + unsigned long arg_start, arg_end; unsigned long pos, len; char *page;
@@ -223,36 +223,18 @@ static ssize_t get_mm_cmdline(struct mm_ spin_lock(&mm->arg_lock); arg_start = mm->arg_start; arg_end = mm->arg_end; - env_start = mm->env_start; - env_end = mm->env_end; spin_unlock(&mm->arg_lock);
if (arg_start >= arg_end) return 0;
- /* - * We have traditionally allowed the user to re-write - * the argument strings and overflow the end result - * into the environment section. But only do that if - * the environment area is contiguous to the arguments. - */ - if (env_start != arg_end || env_start >= env_end) - env_start = env_end = arg_end; - - /* .. and limit it to a maximum of one page of slop */ - if (env_end >= arg_end + PAGE_SIZE) - env_end = arg_end + PAGE_SIZE - 1; - /* We're not going to care if "*ppos" has high bits set */ - pos = arg_start + *ppos; - /* .. but we do check the result is in the proper range */ - if (pos < arg_start || pos >= env_end) + pos = arg_start + *ppos; + if (pos < arg_start || pos >= arg_end) return 0; - - /* .. and we never go past env_end */ - if (env_end - pos < count) - count = env_end - pos; + if (count > arg_end - pos) + count = arg_end - pos;
page = (char *)__get_free_page(GFP_KERNEL); if (!page) @@ -262,48 +244,11 @@ static ssize_t get_mm_cmdline(struct mm_ while (count) { int got; size_t size = min_t(size_t, PAGE_SIZE, count); - long offset; - - /* - * Are we already starting past the official end? - * We always include the last byte that is *supposed* - * to be NUL - */ - offset = (pos >= arg_end) ? pos - arg_end + 1 : 0;
- got = access_remote_vm(mm, pos - offset, page, size + offset, FOLL_ANON); - if (got <= offset) + got = access_remote_vm(mm, pos, page, size, FOLL_ANON); + if (got <= 0) break; - got -= offset; - - /* Don't walk past a NUL character once you hit arg_end */ - if (pos + got >= arg_end) { - int n = 0; - - /* - * If we started before 'arg_end' but ended up - * at or after it, we start the NUL character - * check at arg_end-1 (where we expect the normal - * EOF to be). - * - * NOTE! This is smaller than 'got', because - * pos + got >= arg_end - */ - if (pos < arg_end) - n = arg_end - pos - 1; - - /* Cut off at first NUL after 'n' */ - got = n + strnlen(page+n, offset+got-n); - if (got < offset) - break; - got -= offset; - - /* Include the NUL if it existed */ - if (got < size) - got++; - } - - got -= copy_to_user(buf, page+offset, got); + got -= copy_to_user(buf, page, got); if (unlikely(!got)) { if (!len) len = -EFAULT;
From: Linus Torvalds torvalds@linux-foundation.org
commit d26d0cd97c88eb1a5704b42e41ab443406807810 upstream.
This makes the setproctitle() special case very explicit indeed, and handles it with a separate helper function entirely. In the process, it re-instates the original semantics of simply stopping at the first NUL character when the original last NUL character is no longer there.
[ The original semantics can still be seen in mm/util.c: get_cmdline() that is limited to a fixed-size buffer ]
This makes the logic about when we use the string lengths etc much more obvious, and makes it easier to see what we do and what the two very different cases are.
Note that even when we allow walking past the end of the argument array (because the setproctitle() might have overwritten and overflowed the original argv[] strings), we only allow it when it overflows into the environment region if it is immediately adjacent.
[ Fixed for missing 'count' checks noted by Alexey Izbyshev ]
Link: https://lore.kernel.org/lkml/alpine.LNX.2.21.1904052326230.3249@kich.toxcorp... Fixes: 5ab827189965 ("fs/proc: simplify and clarify get_mm_cmdline() function") Cc: Jakub Jankowski shasta@toxcorp.com Cc: Alexey Dobriyan adobriyan@gmail.com Cc: Alexey Izbyshev izbyshev@ispras.ru Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/proc/base.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 77 insertions(+), 4 deletions(-)
--- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -209,12 +209,53 @@ static int proc_root_link(struct dentry return result; }
+/* + * If the user used setproctitle(), we just get the string from + * user space at arg_start, and limit it to a maximum of one page. + */ +static ssize_t get_mm_proctitle(struct mm_struct *mm, char __user *buf, + size_t count, unsigned long pos, + unsigned long arg_start) +{ + char *page; + int ret, got; + + if (pos >= PAGE_SIZE) + return 0; + + page = (char *)__get_free_page(GFP_KERNEL); + if (!page) + return -ENOMEM; + + ret = 0; + got = access_remote_vm(mm, arg_start, page, PAGE_SIZE, FOLL_ANON); + if (got > 0) { + int len = strnlen(page, got); + + /* Include the NUL character if it was found */ + if (len < got) + len++; + + if (len > pos) { + len -= pos; + if (len > count) + len = count; + len -= copy_to_user(buf, page+pos, len); + if (!len) + len = -EFAULT; + ret = len; + } + } + free_page((unsigned long)page); + return ret; +} + static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf, size_t count, loff_t *ppos) { - unsigned long arg_start, arg_end; + unsigned long arg_start, arg_end, env_start, env_end; unsigned long pos, len; - char *page; + char *page, c;
/* Check if process spawned far enough to have cmdline. */ if (!mm->env_end) @@ -223,14 +264,46 @@ static ssize_t get_mm_cmdline(struct mm_ spin_lock(&mm->arg_lock); arg_start = mm->arg_start; arg_end = mm->arg_end; + env_start = mm->env_start; + env_end = mm->env_end; spin_unlock(&mm->arg_lock);
if (arg_start >= arg_end) return 0;
+ /* + * We allow setproctitle() to overwrite the argument + * strings, and overflow past the original end. But + * only when it overflows into the environment area. + */ + if (env_start != arg_end || env_end < env_start) + env_start = env_end = arg_end; + len = env_end - arg_start; + /* We're not going to care if "*ppos" has high bits set */ - /* .. but we do check the result is in the proper range */ - pos = arg_start + *ppos; + pos = *ppos; + if (pos >= len) + return 0; + if (count > len - pos) + count = len - pos; + if (!count) + return 0; + + /* + * Magical special case: if the argv[] end byte is not + * zero, the user has overwritten it with setproctitle(3). + * + * Possible future enhancement: do this only once when + * pos is 0, and set a flag in the 'struct file'. + */ + if (access_remote_vm(mm, arg_end-1, &c, 1, FOLL_ANON) == 1 && c) + return get_mm_proctitle(mm, buf, count, pos, arg_start); + + /* + * For the non-setproctitle() case we limit things strictly + * to the [arg_start, arg_end[ range. + */ + pos += arg_start; if (pos < arg_start || pos >= arg_end) return 0; if (count > arg_end - pos)
From: Miroslav Lichvar mlichvar@redhat.com
commit 5515e9a6273b8c02034466bcbd717ac9f53dab99 upstream.
The PPS assert/clear offset corrections are set by the PPS_SETPARAMS ioctl in the pps_ktime structs, which also contain flags. The flags are not initialized by applications (using the timepps.h header) and they are not used by the kernel for anything except returning them back in the PPS_GETPARAMS ioctl.
Set the flags to zero to make it clear they are unused and avoid leaking uninitialized data of the PPS_SETPARAMS caller to other applications that have a read access to the PPS device.
Link: http://lkml.kernel.org/r/20190702092251.24303-1-mlichvar@redhat.com Signed-off-by: Miroslav Lichvar mlichvar@redhat.com Reviewed-by: Thomas Gleixner tglx@linutronix.de Acked-by: Rodolfo Giometti giometti@enneenne.com Cc: Greg KH greg@kroah.com Cc: Dan Carpenter dan.carpenter@oracle.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/pps/pps.c | 8 ++++++++ 1 file changed, 8 insertions(+)
--- a/drivers/pps/pps.c +++ b/drivers/pps/pps.c @@ -152,6 +152,14 @@ static long pps_cdev_ioctl(struct file * pps->params.mode |= PPS_CANWAIT; pps->params.api_version = PPS_API_VERS;
+ /* + * Clear unused fields of pps_kparams to avoid leaking + * uninitialized data of the PPS_SETPARAMS caller via + * PPS_GETPARAMS + */ + pps->params.assert_off_tu.flags = 0; + pps->params.clear_off_tu.flags = 0; + spin_unlock_irq(&pps->lock);
break;
From: Yoshinori Sato ysato@users.sourceforge.jp
commit 1b496469d0c020e09124e03e66a81421c21272a7 upstream.
Conflict JCore-SoC and SolutionEngine 7619.
Signed-off-by: Yoshinori Sato ysato@users.sourceforge.jp Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/sh/boards/Kconfig | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-)
--- a/arch/sh/boards/Kconfig +++ b/arch/sh/boards/Kconfig @@ -8,27 +8,19 @@ config SH_ALPHA_BOARD bool
config SH_DEVICE_TREE - bool "Board Described by Device Tree" + bool select OF select OF_EARLY_FLATTREE select TIMER_OF select COMMON_CLK select GENERIC_CALIBRATE_DELAY - help - Select Board Described by Device Tree to build a kernel that - does not hard-code any board-specific knowledge but instead uses - a device tree blob provided by the boot-loader. You must enable - drivers for any hardware you want to use separately. At this - time, only boards based on the open-hardware J-Core processors - have sufficient driver coverage to use this option; do not - select it if you are using original SuperH hardware.
config SH_JCORE_SOC bool "J-Core SoC" - depends on SH_DEVICE_TREE && (CPU_SH2 || CPU_J2) + select SH_DEVICE_TREE select CLKSRC_JCORE_PIT select JCORE_AIC - default y if CPU_J2 + depends on CPU_J2 help Select this option to include drivers core components of the J-Core SoC, including interrupt controllers and timers.
From: Yan, Zheng zyan@redhat.com
commit d6e47819721ae2d9d090058ad5570a66f3c42e39 upstream.
ceph_d_revalidate(, LOOKUP_RCU) may call __ceph_caps_issued_mask() on a freeing inode.
Signed-off-by: "Yan, Zheng" zyan@redhat.com Reviewed-by: Jeff Layton jlayton@redhat.com Signed-off-by: Ilya Dryomov idryomov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- fs/ceph/caps.c | 10 ++++++---- fs/ceph/inode.c | 2 +- fs/ceph/super.h | 2 +- 3 files changed, 8 insertions(+), 6 deletions(-)
--- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -1263,20 +1263,22 @@ static int send_cap_msg(struct cap_msg_a }
/* - * Queue cap releases when an inode is dropped from our cache. Since - * inode is about to be destroyed, there is no need for i_ceph_lock. + * Queue cap releases when an inode is dropped from our cache. */ -void __ceph_remove_caps(struct inode *inode) +void __ceph_remove_caps(struct ceph_inode_info *ci) { - struct ceph_inode_info *ci = ceph_inode(inode); struct rb_node *p;
+ /* lock i_ceph_lock, because ceph_d_revalidate(..., LOOKUP_RCU) + * may call __ceph_caps_issued_mask() on a freeing inode. */ + spin_lock(&ci->i_ceph_lock); p = rb_first(&ci->i_caps); while (p) { struct ceph_cap *cap = rb_entry(p, struct ceph_cap, ci_node); p = rb_next(p); __ceph_remove_cap(cap, true); } + spin_unlock(&ci->i_ceph_lock); }
/* --- a/fs/ceph/inode.c +++ b/fs/ceph/inode.c @@ -536,7 +536,7 @@ void ceph_evict_inode(struct inode *inod
ceph_fscache_unregister_inode_cookie(ci);
- __ceph_remove_caps(inode); + __ceph_remove_caps(ci);
if (__ceph_has_any_quota(ci)) ceph_adjust_quota_realms_count(inode, false); --- a/fs/ceph/super.h +++ b/fs/ceph/super.h @@ -1000,7 +1000,7 @@ extern void ceph_add_cap(struct inode *i unsigned cap, unsigned seq, u64 realmino, int flags, struct ceph_cap **new_cap); extern void __ceph_remove_cap(struct ceph_cap *cap, bool queue_release); -extern void __ceph_remove_caps(struct inode* inode); +extern void __ceph_remove_caps(struct ceph_inode_info *ci); extern void ceph_put_cap(struct ceph_mds_client *mdsc, struct ceph_cap *cap); extern int ceph_is_any_caps(struct inode *inode);
From: Thierry Reding treding@nvidia.com
On Fri, 02 Aug 2019 11:39:54 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.2: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 fail
Linux version: 5.2.6-rc1-gbe893953fcc2 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Thierry
On Fri, Aug 02, 2019 at 07:21:05PM +0200, Thierry Reding wrote:
From: Thierry Reding treding@nvidia.com
On Fri, 02 Aug 2019 11:39:54 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.2: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 fail
Linux version: 5.2.6-rc1-gbe893953fcc2 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Great! Thanks for testing all of these and letting me know.
greg k-h
On Sat, Aug 03, 2019 at 09:09:32AM +0200, Greg Kroah-Hartman wrote:
On Fri, Aug 02, 2019 at 07:21:05PM +0200, Thierry Reding wrote:
From: Thierry Reding treding@nvidia.com
On Fri, 02 Aug 2019 11:39:54 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.2: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 fail
Linux version: 5.2.6-rc1-gbe893953fcc2 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Great! Thanks for testing all of these and letting me know.
Hi Greg,
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
Thierry
On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
Hi Greg,
Sorry for the delay, this got pushed down my queue...
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
You aren't being pedantic, I think you are missing exactly what the linux-stable-rc tree is for and how it is created.
Granted, it's not really documented anywhere so it's not your fault :)
The linux-stable-rc tree is there ONLY for people who want to test the -rc kernels and can not, or do not want to, use the quilt tree of patches in the stable-queue.git tree on kernel.org. I generate the branches there from a script that throws away the current -rc branch and rebuilds it "from scratch" by applying the patches that are in the stable-quilt tree and then adds the -rc patch as well. This tree is generated multiple times when I am working on the queues and then when I want to do a "real" -rc release.
The branches are constantly rebased, so you can not rely on 'git pull' doing the right thing (unless you add --rebase to it), and are there for testing only.
Yes, you will see different results of a "-rc1" release in the tree depending on the time of day/week when I created the tree, and sometimes I generate them multiple times a day just to have some of the auto-builders give me results quickly (Linaro does pull from it and sends me results within the hour usually).
So does that help? Ideally everyone would just use the quilt trees from stable-queue.git, but no everyone likes that, so the -rc git tree is there to make automated testing "easier". If that works with your workflow, wonderful, feel free to use it. If not, then go with the stable-quilt.git tree, or the tarballs on kernel.org.
And as for the SHA1 being in the emails, that doesn't make all that much sense as that SHA1 doesn't live very long. When I create the trees locally, I instantly delete them after pushing them to kernel.org so I can't regenerate them or do anything with them.
DOes that help explain things better?
thanks,
greg k-h
On Fri, Aug 09, 2019 at 10:52:53AM +0200, Greg Kroah-Hartman wrote:
On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
Hi Greg,
Sorry for the delay, this got pushed down my queue...
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
You aren't being pedantic, I think you are missing exactly what the linux-stable-rc tree is for and how it is created.
Granted, it's not really documented anywhere so it's not your fault :)
The linux-stable-rc tree is there ONLY for people who want to test the -rc kernels and can not, or do not want to, use the quilt tree of patches in the stable-queue.git tree on kernel.org. I generate the branches there from a script that throws away the current -rc branch and rebuilds it "from scratch" by applying the patches that are in the stable-quilt tree and then adds the -rc patch as well. This tree is generated multiple times when I am working on the queues and then when I want to do a "real" -rc release.
The branches are constantly rebased, so you can not rely on 'git pull' doing the right thing (unless you add --rebase to it), and are there for testing only.
Yes, you will see different results of a "-rc1" release in the tree depending on the time of day/week when I created the tree, and sometimes I generate them multiple times a day just to have some of the auto-builders give me results quickly (Linaro does pull from it and sends me results within the hour usually).
So does that help? Ideally everyone would just use the quilt trees from stable-queue.git, but no everyone likes that, so the -rc git tree is there to make automated testing "easier". If that works with your workflow, wonderful, feel free to use it. If not, then go with the stable-quilt.git tree, or the tarballs on kernel.org.
I'll have to look into that, to see if that'd work. I have to admit that having a git tree to point scripts at is rather convenient for automation.
And as for the SHA1 being in the emails, that doesn't make all that much sense as that SHA1 doesn't live very long. When I create the trees locally, I instantly delete them after pushing them to kernel.org so I can't regenerate them or do anything with them.
Fair enough. I suppose the worst thing that could happen is that we may fail to test a couple of commits occasionally. In the rare case where this actually matters we'll likely end up reporting the failure for the stable release, in which case it can be fixed in the next one.
DOes that help explain things better?
Yes, makes a lot more sense now. Thanks for taking the time to explain it. Do you want me to snapshot this and submit it as documentation somewhere for later reference?
Thierry
On Fri, Aug 09, 2019 at 03:04:49PM +0200, Thierry Reding wrote:
On Fri, Aug 09, 2019 at 10:52:53AM +0200, Greg Kroah-Hartman wrote:
On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
Hi Greg,
Sorry for the delay, this got pushed down my queue...
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
You aren't being pedantic, I think you are missing exactly what the linux-stable-rc tree is for and how it is created.
Granted, it's not really documented anywhere so it's not your fault :)
The linux-stable-rc tree is there ONLY for people who want to test the -rc kernels and can not, or do not want to, use the quilt tree of patches in the stable-queue.git tree on kernel.org. I generate the branches there from a script that throws away the current -rc branch and rebuilds it "from scratch" by applying the patches that are in the stable-quilt tree and then adds the -rc patch as well. This tree is generated multiple times when I am working on the queues and then when I want to do a "real" -rc release.
The branches are constantly rebased, so you can not rely on 'git pull' doing the right thing (unless you add --rebase to it), and are there for testing only.
Yes, you will see different results of a "-rc1" release in the tree depending on the time of day/week when I created the tree, and sometimes I generate them multiple times a day just to have some of the auto-builders give me results quickly (Linaro does pull from it and sends me results within the hour usually).
So does that help? Ideally everyone would just use the quilt trees from stable-queue.git, but no everyone likes that, so the -rc git tree is there to make automated testing "easier". If that works with your workflow, wonderful, feel free to use it. If not, then go with the stable-quilt.git tree, or the tarballs on kernel.org.
I'll have to look into that, to see if that'd work. I have to admit that having a git tree to point scripts at is rather convenient for automation.
And as for the SHA1 being in the emails, that doesn't make all that much sense as that SHA1 doesn't live very long. When I create the trees locally, I instantly delete them after pushing them to kernel.org so I can't regenerate them or do anything with them.
Fair enough. I suppose the worst thing that could happen is that we may fail to test a couple of commits occasionally. In the rare case where this actually matters we'll likely end up reporting the failure for the stable release, in which case it can be fixed in the next one.
DOes that help explain things better?
Yes, makes a lot more sense now. Thanks for taking the time to explain it. Do you want me to snapshot this and submit it as documentation somewhere for later reference?
It probably should go somewhere, but as the number of people that do "test stable kernels in an automated way" is very low, so far I've been doing ok with a one-by-one explaination. I guess if it's more obvious, more people would test, so sure, this should be cleaned up...
thanks,
greg k-h
On Fri, Aug 09, 2019 at 05:49:59PM +0200, Greg Kroah-Hartman wrote:
On Fri, Aug 09, 2019 at 03:04:49PM +0200, Thierry Reding wrote:
On Fri, Aug 09, 2019 at 10:52:53AM +0200, Greg Kroah-Hartman wrote:
On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
Hi Greg,
Sorry for the delay, this got pushed down my queue...
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
You aren't being pedantic, I think you are missing exactly what the linux-stable-rc tree is for and how it is created.
Granted, it's not really documented anywhere so it's not your fault :)
The linux-stable-rc tree is there ONLY for people who want to test the -rc kernels and can not, or do not want to, use the quilt tree of patches in the stable-queue.git tree on kernel.org. I generate the branches there from a script that throws away the current -rc branch and rebuilds it "from scratch" by applying the patches that are in the stable-quilt tree and then adds the -rc patch as well. This tree is generated multiple times when I am working on the queues and then when I want to do a "real" -rc release.
The branches are constantly rebased, so you can not rely on 'git pull' doing the right thing (unless you add --rebase to it), and are there for testing only.
Yes, you will see different results of a "-rc1" release in the tree depending on the time of day/week when I created the tree, and sometimes I generate them multiple times a day just to have some of the auto-builders give me results quickly (Linaro does pull from it and sends me results within the hour usually).
So does that help? Ideally everyone would just use the quilt trees from stable-queue.git, but no everyone likes that, so the -rc git tree is there to make automated testing "easier". If that works with your workflow, wonderful, feel free to use it. If not, then go with the stable-quilt.git tree, or the tarballs on kernel.org.
I'll have to look into that, to see if that'd work. I have to admit that having a git tree to point scripts at is rather convenient for automation.
And as for the SHA1 being in the emails, that doesn't make all that much sense as that SHA1 doesn't live very long. When I create the trees locally, I instantly delete them after pushing them to kernel.org so I can't regenerate them or do anything with them.
Fair enough. I suppose the worst thing that could happen is that we may fail to test a couple of commits occasionally. In the rare case where this actually matters we'll likely end up reporting the failure for the stable release, in which case it can be fixed in the next one.
DOes that help explain things better?
Yes, makes a lot more sense now. Thanks for taking the time to explain it. Do you want me to snapshot this and submit it as documentation somewhere for later reference?
It probably should go somewhere, but as the number of people that do "test stable kernels in an automated way" is very low, so far I've been doing ok with a one-by-one explaination. I guess if it's more obvious, more people would test, so sure, this should be cleaned up...
How about something like the below. It applies to the stable-queue.git repository.
Thierry
--- >8 --- From 4083add6ccb4a1c23edeba650170470bcc5d5205 Mon Sep 17 00:00:00 2001 From: Thierry Reding treding@nvidia.com Date: Mon, 12 Aug 2019 10:58:35 +0200 Subject: [PATCH] Describe the stable-queue release process
Add a README file that describes how release candidates for stable kernels are created and how users are expected to use them. This is reworded from Greg's reply here:
https://lore.kernel.org/stable/20190809085253.GA25046@kroah.com/ --- README | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 README
diff --git a/README b/README new file mode 100644 index 000000000000..868469a73f68 --- /dev/null +++ b/README @@ -0,0 +1,31 @@ +This repository is the canonical source for patches that make up the stable +kernel releases. It consists of a set of directories for each of the stable +kernels, as well as a directory that contains a snapshot of the patches for +each stable release. + +The patches for each release can be found along with a complete tarball of +a release in the following location: + + https://kernel.org/pub/linux/kernel/vX.Y/ + +For each stable release candidate, a patch representing the diff of all the +patches in the stable queue is uploaded here: + + https://kernel.org/pub/linux/kernel/vX.Y/stable-review/ + +As a convenience for people that want to test release candidates of stable +releases, a branch of the kernel git tree is created containing all of the +patches in the given stable queue. These branches are available in the +following repository: + + git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git + +A branch exists for each of the stable releases. Note, though, that these +branches are recreated from scratch by applying the queued stable patches +on top of the prior release. As a consequence, the branches are not fast- +forward and can change after a release candidate has been announced. The +contents of the branch may therefore not match exactly what was released +as the release candidate, depending on when you fetch it. No tags are +created to track individual release candidates. If you're interested in +exact reproducibility of a stable release candidate, please use the patches +from the location mentioned above.
On Mon, Aug 12, 2019 at 11:05:53AM +0200, Thierry Reding wrote:
On Fri, Aug 09, 2019 at 05:49:59PM +0200, Greg Kroah-Hartman wrote:
On Fri, Aug 09, 2019 at 03:04:49PM +0200, Thierry Reding wrote:
On Fri, Aug 09, 2019 at 10:52:53AM +0200, Greg Kroah-Hartman wrote:
On Mon, Aug 05, 2019 at 01:48:21PM +0200, Thierry Reding wrote:
Hi Greg,
Sorry for the delay, this got pushed down my queue...
I stumbled across something as I was attempting to automate more parts of our process to generate these reports. The original test results were from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect that's the same thing that you were discussing with Pavel regarding the IP tunnel patch that was added subsequent to the announcement.
Just for my understanding, does this mean that the patch still makes it into the 5.2.6 release, or was it supposed to go into 5.2.7?
One problem that I ran into was that when I tried to correlate the test results with your announcement email, there's no indication other than the branch name and the release candidate name (5.2.6-rc1 in this case), so there's no way to uniquely identify which test run belongs to the announcement. Given that there are no tags for the release candidates means that that's also not an option to uniquely associate with the builds and tests.
While the differences between the two builds are very minor here, I wonder if there could perhaps in the future be a problem where I report successful results for a test, but the same tests would be broken by a patch added to the stable-rc branch subsequent to the announcement. The test report would be misleading in that case.
I noticed that you do add a couple of X-KernelTest-* headers to your announcement emails, so I'm wondering if perhaps it was possible for you to add another one that contains the exact SHA1 that corresponds to the snapshot that's the release candidate. That would allow everyone to uniquely associate test results with a specific release candidate.
That said, perhaps I've just got this all wrong and there's already a way to connect all the dots that I'm not aware of. Or maybe I'm being too pedantic here?
You aren't being pedantic, I think you are missing exactly what the linux-stable-rc tree is for and how it is created.
Granted, it's not really documented anywhere so it's not your fault :)
The linux-stable-rc tree is there ONLY for people who want to test the -rc kernels and can not, or do not want to, use the quilt tree of patches in the stable-queue.git tree on kernel.org. I generate the branches there from a script that throws away the current -rc branch and rebuilds it "from scratch" by applying the patches that are in the stable-quilt tree and then adds the -rc patch as well. This tree is generated multiple times when I am working on the queues and then when I want to do a "real" -rc release.
The branches are constantly rebased, so you can not rely on 'git pull' doing the right thing (unless you add --rebase to it), and are there for testing only.
Yes, you will see different results of a "-rc1" release in the tree depending on the time of day/week when I created the tree, and sometimes I generate them multiple times a day just to have some of the auto-builders give me results quickly (Linaro does pull from it and sends me results within the hour usually).
So does that help? Ideally everyone would just use the quilt trees from stable-queue.git, but no everyone likes that, so the -rc git tree is there to make automated testing "easier". If that works with your workflow, wonderful, feel free to use it. If not, then go with the stable-quilt.git tree, or the tarballs on kernel.org.
I'll have to look into that, to see if that'd work. I have to admit that having a git tree to point scripts at is rather convenient for automation.
And as for the SHA1 being in the emails, that doesn't make all that much sense as that SHA1 doesn't live very long. When I create the trees locally, I instantly delete them after pushing them to kernel.org so I can't regenerate them or do anything with them.
Fair enough. I suppose the worst thing that could happen is that we may fail to test a couple of commits occasionally. In the rare case where this actually matters we'll likely end up reporting the failure for the stable release, in which case it can be fixed in the next one.
DOes that help explain things better?
Yes, makes a lot more sense now. Thanks for taking the time to explain it. Do you want me to snapshot this and submit it as documentation somewhere for later reference?
It probably should go somewhere, but as the number of people that do "test stable kernels in an automated way" is very low, so far I've been doing ok with a one-by-one explaination. I guess if it's more obvious, more people would test, so sure, this should be cleaned up...
How about something like the below. It applies to the stable-queue.git repository.
Thierry
--- >8 --- From 4083add6ccb4a1c23edeba650170470bcc5d5205 Mon Sep 17 00:00:00 2001 From: Thierry Reding treding@nvidia.com Date: Mon, 12 Aug 2019 10:58:35 +0200 Subject: [PATCH] Describe the stable-queue release process
Add a README file that describes how release candidates for stable kernels are created and how users are expected to use them. This is reworded from Greg's reply here:
https://lore.kernel.org/stable/20190809085253.GA25046@kroah.com/
README | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 README
diff --git a/README b/README new file mode 100644 index 000000000000..868469a73f68 --- /dev/null +++ b/README @@ -0,0 +1,31 @@ +This repository is the canonical source for patches that make up the stable +kernel releases. It consists of a set of directories for each of the stable +kernels, as well as a directory that contains a snapshot of the patches for +each stable release.
+The patches for each release can be found along with a complete tarball of +a release in the following location:
+For each stable release candidate, a patch representing the diff of all the +patches in the stable queue is uploaded here:
+As a convenience for people that want to test release candidates of stable +releases, a branch of the kernel git tree is created containing all of the +patches in the given stable queue. These branches are available in the +following repository:
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
+A branch exists for each of the stable releases. Note, though, that these +branches are recreated from scratch by applying the queued stable patches +on top of the prior release. As a consequence, the branches are not fast- +forward and can change after a release candidate has been announced. The +contents of the branch may therefore not match exactly what was released +as the release candidate, depending on when you fetch it. No tags are +created to track individual release candidates. If you're interested in +exact reproducibility of a stable release candidate, please use the patches
+from the location mentioned above.
Sorry for the very long delay, cleaning out old emails...
This looks really good, thanks for writing it up, I've now applied it to the stable-queue tree.
greg k-h
On 8/2/19 3:39 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Fri, Aug 02, 2019 at 05:25:40PM -0600, shuah wrote:
On 8/2/19 3:39 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
On Fri, 2 Aug 2019 at 15:28, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Summary ------------------------------------------------------------------------
kernel: 5.2.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.2.y git commit: 44397d30b22dd93340c705ef34bb61c16f43503b git describe: v5.2.4-235-g44397d30b22d Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.4-235-g...
No regressions (compared to build v5.2.4)
No fixes (compared to build v5.2.4)
Ran 21444 total tests in the following environments and test suites.
Environments -------------- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86
Test Suites ----------- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite
On Sat, Aug 03, 2019 at 11:20:05AM +0530, Naresh Kamboju wrote:
On Fri, 2 Aug 2019 at 15:28, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
On 8/2/19 2:39 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
Build results: total: 159 pass: 159 fail: 0 Qemu test results: total: 364 pass: 364 fail: 0
Guenter
On Sat, Aug 03, 2019 at 09:00:11AM -0700, Guenter Roeck wrote:
On 8/2/19 2:39 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.6 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late.
Build results: total: 159 pass: 159 fail: 0 Qemu test results: total: 364 pass: 364 fail: 0
Great! Thanks for testing all of these and letting me know.
greg k-h
linux-stable-mirror@lists.linaro.org