4.19.217-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.19.217-rc1 review
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. 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/v4.x/stable-review/patch-4.19.217-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.217-rc1
Johan Hovold <[email protected]>
rsi: fix control-message timeout
Johan Hovold <[email protected]>
staging: rtl8192u: fix control-message timeouts
Johan Hovold <[email protected]>
staging: r8712u: fix control-message timeout
Johan Hovold <[email protected]>
comedi: vmk80xx: fix bulk and interrupt message timeouts
Johan Hovold <[email protected]>
comedi: vmk80xx: fix bulk-buffer overflow
Johan Hovold <[email protected]>
comedi: vmk80xx: fix transfer-buffer overflows
Johan Hovold <[email protected]>
comedi: ni_usb6501: fix NULL-deref in command paths
Johan Hovold <[email protected]>
comedi: dt9812: fix DMA buffers on stack
Jan Kara <[email protected]>
isofs: Fix out of bound access for corrupted isofs image
Petr Mladek <[email protected]>
printk/console: Allow to disable console output by using console="" or console=null
James Buren <[email protected]>
usb-storage: Add compatibility quirk flags for iODD 2531/2541
Viraj Shah <[email protected]>
usb: musb: Balance list entry in musb_gadget_queue
Geert Uytterhoeven <[email protected]>
usb: gadget: Mark USB_FSL_QE broken on 64-bit
Neal Liu <[email protected]>
usb: ehci: handshake CMD_RUN instead of STS_HALT
Juergen Gross <[email protected]>
Revert "x86/kvm: fix vcpu-id indexed array sizes"
Ming Lei <[email protected]>
block: introduce multi-page bvec helpers
-------------
Diffstat:
Makefile | 4 +- arch/x86/kvm/ioapic.c | 2 +- arch/x86/kvm/ioapic.h | 4 +- drivers/net/wireless/rsi/rsi_91x_usb.c | 2 +- drivers/staging/comedi/drivers/dt9812.c | 115 +++++++++++++++++++++------- drivers/staging/comedi/drivers/ni_usb6501.c | 10 +++ drivers/staging/comedi/drivers/vmk80xx.c | 28 +++---- drivers/staging/rtl8192u/r8192U_core.c | 18 ++--- drivers/staging/rtl8712/usb_ops_linux.c | 2 +- drivers/usb/gadget/udc/Kconfig | 1 + drivers/usb/host/ehci-hcd.c | 11 ++- drivers/usb/host/ehci-platform.c | 6 ++ drivers/usb/host/ehci.h | 1 + drivers/usb/musb/musb_gadget.c | 4 +- drivers/usb/storage/unusual_devs.h | 10 +++ fs/isofs/inode.c | 2 + include/linux/bvec.h | 30 +++++++- kernel/printk/printk.c | 9 ++- 18 files changed, 195 insertions(+), 64 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/16 block: introduce multi-page bvec helpers
From: Ming Lei <[email protected]>
commit 3d75ca0adef4280650c6690a0c4702a74a6f3c95 upstream.
This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec support.
The introduced helpers treate one bvec as real multi-page segment, which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current bvec iterator which is thought as single-page by drivers, fs, dm and etc. These introduced helpers will build single-page bvec in flight, so this way won't break current bio/bvec users, which needn't any change.
Follows some multi-page bvec background:
- bvecs stored in bio->bi_io_vec is always multi-page style
- bvec(struct bio_vec) represents one physically contiguous I/O buffer, now the buffer may include more than one page after multi-page bvec is supported, and all these pages represented by one bvec is physically contiguous. Before multi-page bvec support, at most one page is included in one bvec, we call it single-page bvec.
- .bv_page of the bvec points to the 1st page in the multi-page bvec
- .bv_offset of the bvec is the offset of the buffer in the bvec
The effect on the current drivers/filesystem/dm/bcache/...:
- almost everyone supposes that one bvec only includes one single page, so we keep the sp interface not changed, for example, bio_for_each_segment() still returns single-page bvec
- bio_for_each_segment_all() will return single-page bvec too
- during iterating, iterator variable(struct bvec_iter) is always updated in multi-page bvec style, and bvec_iter_advance() is kept not changed
- returned(copied) single-page bvec is built in flight by bvec helpers from the stored multi-page bvec
--- include/linux/bvec.h | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
include/linux/bvec.h +27 -3
@@ -23,6 +23,7 @@#include <linux/kernel.h> #include <linux/bug.h> #include <linux/errno.h> +#include <linux/mm.h> /* * was unsigned short, but we might as well be ready for > 64kB I/O pages
@@ -52,16 +53,39 @@ struct bvec_iter {*/ #define __bvec_iter_bvec (bvec, iter) (&(bvec)[(iter).bi_idx]) -#define bvec_iter_page (bvec, iter) \ +/* multi-page (mp_bvec) helpers */ +#define mp_bvec_iter_page (bvec, iter) \ (__bvec_iter_bvec((bvec), (iter))->bv_page) -#define bvec_iter_len (bvec, iter) \ +#define mp_bvec_iter_len (bvec, iter) \ min((iter).bi_size, \ __bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done) -#define bvec_iter_offset (bvec, iter) \ +#define mp_bvec_iter_offset (bvec, iter) \ (__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done) +#define mp_bvec_iter_page_idx (bvec, iter) \ + (mp_bvec_iter_offset((bvec), (iter)) / PAGE_SIZE) + +#define mp_bvec_iter_bvec (bvec, iter) \ +((struct bio_vec) { \ + .bv_page = mp_bvec_iter_page((bvec), (iter)), \ + .bv_len = mp_bvec_iter_len((bvec), (iter)), \ + .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \ +}) + +/* For building single-page bvec in flight */ +#define bvec_iter_offset (bvec, iter) \ + (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE) + +#define bvec_iter_len (bvec, iter) \ + min_t(unsigned, mp_bvec_iter_len((bvec), (iter)), \ + PAGE_SIZE - bvec_iter_offset((bvec), (iter))) + +#define bvec_iter_page (bvec, iter) \ + nth_page(mp_bvec_iter_page((bvec), (iter)), \ + mp_bvec_iter_page_idx((bvec), (iter))) +#define bvec_iter_bvec (bvec, iter) \ ((struct bio_vec) { \ .bv_page = bvec_iter_page((bvec), (iter)), \
Re: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
Hi!
Quoted 7 lines
From: Ming Lei <[email protected]>
commit
3d75ca0adef4280650c6690a0c4702a74a6f3c95upstream.This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec support.
Quoted 8 lines
The introduced helpers treate one bvec as real multi-page segment, which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current bvec iterator which is thought as single-page by drivers, fs, dm and etc. These introduced helpers will build single-page bvec in flight, so this way won't break current bio/bvec users, which needn't any change.
I don't understand why we have this in 4.19-stable. I don't see followup patches needing it, and it does not claim to fix a bug.
include/linux/bvec.h struct bvec_iter { · line 80
Quoted 11 lines
include/linux/bvec.h +11
-0+#define mp_bvec_iter_bvec (bvec, iter) \ +((struct bio_vec) { \ + .bv_page = mp_bvec_iter_page((bvec), (iter)), \ + .bv_len = mp_bvec_iter_len((bvec), (iter)), \ + .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \ +}) + +/* For building single-page bvec in flight */ +#define bvec_iter_offset (bvec, iter) \ + (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE) +
Plus this one is strange. IIRC preprocessor directives have to put # in column zero?
Best regards,
Pavel
Signature · 1 line
http://www.livejournal.com/~pavelmachek
Re: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
Quoted 12 lines · Pavel Machek
Hi!
Quoted 10 lines
From: Ming Lei <[email protected]>
commit
3d75ca0adef4280650c6690a0c4702a74a6f3c95upstream.This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec support.
The introduced helpers treate one bvec as real multi-page segment, which may include more than one pages.
Quoted 8 lines
Quoted 5 lines
The existed helpers of bvec_iter_* are interfaces for supporting current bvec iterator which is thought as single-page by drivers, fs, dm and etc. These introduced helpers will build single-page bvec in flight, so this way won't break current bio/bvec users, which needn't any change.
I don't understand why we have this in 4.19-stable. I don't see followup patches needing it, and it does not claim to fix a bug.
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#u
Thanks,
- Zubin
Quoted 20 lines
include/linux/bvec.h struct bvec_iter { · line 80
Quoted 12 lines
include/linux/bvec.h +11
-0+#define mp_bvec_iter_bvec (bvec, iter) \ +((struct bio_vec) { \ + .bv_page = mp_bvec_iter_page((bvec), (iter)), \ + .bv_len = mp_bvec_iter_len((bvec), (iter)), \ + .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \ +}) + +/* For building single-page bvec in flight */ +#define bvec_iter_offset (bvec, iter) \ + (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE) +Plus this one is strange. IIRC preprocessor directives have to put # in column zero?
Best regards,
PavelSignature · 1 line
http://www.livejournal.com/~pavelmachek
Re: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
Hi!
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec support.
The introduced helpers treate one bvec as real multi-page segment, which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current bvec iterator which is thought as single-page by drivers, fs, dm and etc. These introduced helpers will build single-page bvec in flight, so this way won't break current bio/bvec users, which needn't any change.
Quoted 8 lines
Quoted 2 lines
I don't understand why we have this in 4.19-stable. I don't see followup patches needing it, and it does not claim to fix a bug.
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#u
Thank you!
Pavel
Signature · 1 line
http://www.livejournal.com/~pavelmachek
Re: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
Quoted 6 lines · Pavel Machek
Quoted 4 lines
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#uThank you!
Honestly, this looks broken to me. multipage-bvec was a big invasive series with a lot of latter fixups. While taking this patch on it's own should be save by itself, but also useless. So if it is needed to make a KASAN warning go away we need to dig deeper and back something else out that should not have been backported to rely on multipage bvec becasue without the other patches they don't exist and can't acually work.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Pavel Machek
Quoted 4 lines
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#uThank you!
Quoted 7 lines
Honestly, this looks broken to me. multipage-bvec was a big invasive series with a lot of latter fixups. While taking this patch on it's own should be save by itself, but also useless. So if it is needed to make a KASAN warning go away we need to dig deeper and back something else out that should not have been backported to rely on multipage bvec becasue without the other patches they don't exist and can't acually work.
Ok, let me drop this for now.
Zubin, can you provide a better report as to what driver is causing the problem and what exactly resolves it? Has this issue always been in 4.19 since 4.19.0?
thanks,
greg k-h
Re: [PATCH 4.19 01/16] block: introduce multi-page bvec helpers
In reply to Christoph HellwigQuoted 8 lines · Christoph Hellwig
Quoted 6 lines · Pavel Machek
Quoted 4 lines
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#uThank you!
Quoted 7 lines
Honestly, this looks broken to me. multipage-bvec was a big invasive series with a lot of latter fixups. While taking this patch on it's own should be save by itself, but also useless. So if it is needed to make a KASAN warning go away we need to dig deeper and back something else out that should not have been backported to rely on multipage bvec becasue without the other patches they don't exist and can't acually work.
Yeah it makes no sense to me, to be honest. We're most certainly not backporting multipage bvecs to stable, and if this particular patch fixes something, it's by happy accident and we should find out why.
Signature · 1 line
Jens Axboe
Greg Kroah-Hartman
maintainerPATCH 2/16 Revert "x86/kvm: fix vcpu-id indexed array sizes"
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit 1e254d0d86a0f2efd4190a89d5204b37c18c6381 upstream.
This reverts commit 76b4f357d0e7d8f6f0013c733e6cba1773c266d3.
The commit has the wrong reasoning, as KVM_MAX_VCPU_ID is not defining the maximum allowed vcpu-id as its name suggests, but the number of vcpu-ids. So revert this patch again.
Message-Id: <[email protected]>
--- arch/x86/kvm/ioapic.c | 2 +- arch/x86/kvm/ioapic.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kvm/ioapic.c +1 -1
@@ -96,7 +96,7 @@ static unsigned long ioapic_read_indirecstatic void rtc_irq_eoi_tracking_reset (struct kvm_ioapic *ioapic) { ioapic->rtc_status.pending_eoi =0 ; -bitmap_zero (ioapic->rtc_status.dest_map.map,KVM_MAX_VCPU_ID +1 ); +bitmap_zero (ioapic->rtc_status.dest_map.map,KVM_MAX_VCPU_ID ); }static void kvm_rtc_eoi_tracking_restore_all (struct kvm_ioapic *ioapic);
arch/x86/kvm/ioapic.h +2 -2
@@ -43,13 +43,13 @@ struct kvm_vcpu;struct dest_map {/* vcpu bitmap where IRQ has been sent */ - DECLARE_BITMAP(map, KVM_MAX_VCPU_ID + 1); + DECLARE_BITMAP(map, KVM_MAX_VCPU_ID);/* * Vector sent to a given vcpu, only valid when * the vcpu's bit in map is set */ -u8 vectors[KVM_MAX_VCPU_ID +1 ]; +u8 vectors[KVM_MAX_VCPU_ID ]; };
Greg Kroah-Hartman
maintainerPATCH 3/16 usb: ehci: handshake CMD_RUN instead of STS_HALT
In reply to Greg Kroah-HartmanFrom: Neal Liu <[email protected]>
commit 7f2d73788d9067fd4f677ac5f60ffd25945af7af upstream.
For Aspeed, HCHalted status depends on not only Run/Stop but also ASS/PSS status.
Handshake CMD_RUN on startup instead.
--- drivers/usb/host/ehci-hcd.c | 11 ++++++++++- drivers/usb/host/ehci-platform.c | 6 ++++++ drivers/usb/host/ehci.h | 1 + 3 files changed, 17 insertions(+), 1 deletion(-)
drivers/usb/host/ehci-hcd.c +10 -1
@@ -634,7 +634,16 @@ static int ehci_run (struct usb_hcd *hcd/* Wait until HC become operational */ ehci_readl (ehci, &ehci->regs->command);/* unblock posted writes */ msleep (5 ); - rc =ehci_handshake (ehci, &ehci->regs->status,STS_HALT ,0 ,100 *1000 ); + +/* For Aspeed, STS_HALT also depends on ASS/PSS status. +* Check CMD_RUN instead. +*/ +if (ehci->is_aspeed) + rc =ehci_handshake (ehci, &ehci->regs->command,CMD_RUN , +1 ,100 *1000 ); +else + rc =ehci_handshake (ehci, &ehci->regs->status,STS_HALT , +0 ,100 *1000 );up_write (&ehci_cf_port_reset_rwsem);
drivers/usb/host/ehci-platform.c +6 -0
@@ -288,6 +288,12 @@ static int ehci_platform_probe(struct pl "has-transaction-translator")) hcd->has_tt =1 ; +if (of_device_is_compatible (dev->dev.of_node, +"aspeed,ast2500-ehci" ) || +of_device_is_compatible (dev->dev.of_node, +"aspeed,ast2600-ehci" )) + ehci->is_aspeed =1 ; +if (soc_device_match (quirk_poll_match)) priv->quirk_poll = true;
drivers/usb/host/ehci.h +1 -0
@@ -218,6 +218,7 @@ struct ehci_hcd { /* one per controlle unsigned frame_index_bug:1; /* MosChip (AKA NetMos) */ unsigned need_oc_pp_cycle:1; /* MPC834X port power */ unsigned imx28_write_fix:1; /* For Freescale i.MX28 */ + unsigned is_aspeed:1;/* required for usb32 quirk */ #define OHCI_CTRL_HCFS (3 << 6)
Greg Kroah-Hartman
maintainerPATCH 4/16 usb: gadget: Mark USB_FSL_QE broken on 64-bit
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit a0548b26901f082684ad1fb3ba397d2de3a1406a upstream.
On 64-bit:
drivers/usb/gadget/udc/fsl_qe_udc.c: In function ‘qe_ep0_rx’:
drivers/usb/gadget/udc/fsl_qe_udc.c:842:13: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
842 | vaddr = (u32)phys_to_virt(in_be32(&bd->buf));
| ^
In file included from drivers/usb/gadget/udc/fsl_qe_udc.c:41:
drivers/usb/gadget/udc/fsl_qe_udc.c:843:28: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
843 | frame_set_data(pframe, (u8 *)vaddr);
| ^
The driver assumes physical and virtual addresses are 32-bit, hence it cannot work on 64-bit platforms.
--- drivers/usb/gadget/udc/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/udc/Kconfig +1 -0
@@ -328,6 +328,7 @@ config USB_AMD5536UDC config USB_FSL_QE tristate "Freescale QE/CPM USB Device Controller" depends on FSL_SOC && (QUICC_ENGINE || CPM) + depends on !64BIT || BROKEN help Some of Freescale PowerPC processors have a Full Speed QE/CPM2 USB controller, which support device mode with 4
Greg Kroah-Hartman
maintainerPATCH 5/16 usb: musb: Balance list entry in musb_gadget_queue
In reply to Greg Kroah-HartmanFrom: Viraj Shah <[email protected]>
commit 21b5fcdccb32ff09b6b63d4a83c037150665a83f upstream.
musb_gadget_queue() adds the passed request to musb_ep::req_list. If the endpoint is idle and it is the first request then it invokes musb_queue_resume_work(). If the function returns an error then the error is passed to the caller without any clean-up and the request remains enqueued on the list. If the caller enqueues the request again then the list corrupts.
Remove the request from the list on error.
--- drivers/usb/musb/musb_gadget.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/musb/musb_gadget.c +3 -1
@@ -1248,9 +1248,11 @@ static int musb_gadget_queue(struct usb_ status =musb_queue_resume_work (musb, musb_ep_restart_resume_work, request); -if (status <0 ) +if (status <0 ) {dev_err (musb->controller,"%s resume work: %i\n" , __func__, status); +list_del (&request->list); + } } unlock:
Greg Kroah-Hartman
maintainerPATCH 6/16 usb-storage: Add compatibility quirk flags for iODD 2531/2541
In reply to Greg Kroah-HartmanFrom: James Buren <[email protected]>
commit 05c8f1b67e67dcd786ae3fe44492bbc617b4bd12 upstream.
These drive enclosures have firmware bugs that make it impossible to mount a new virtual ISO image after Linux ejects the old one if the device is locked by Linux. Windows bypasses this problem by the fact that they do not lock the device. Add a quirk to disable device locking for these drive enclosures.
--- drivers/usb/storage/unusual_devs.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/usb/storage/unusual_devs.h +10 -0
@@ -407,6 +407,16 @@ UNUSUAL_DEV( 0x04b8, 0x0602, 0x0110, 0x USB_SC_SCSI, USB_PR_BULK, NULL, US_FL_SINGLE_LUN),/* +* Reported by James Buren <[email protected]> +* Virtual ISOs cannot be remounted if ejected while the device is locked +* Disable locking to mimic Windows behavior that bypasses the issue +*/ +UNUSUAL_DEV (0x04c5 ,0x2028 ,0x0001 ,0x0001 , +"iODD" , +"2531/2541" , + USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NOT_LOCKABLE), + +/* * Not sure who reported this originally but * Pavel Machek <[email protected]> reported that the extra US_FL_SINGLE_LUN * flag be added */
Greg Kroah-Hartman
maintainerPATCH 7/16 printk/console: Allow to disable console output by using console="" or console=null
In reply to Greg Kroah-HartmanFrom: Petr Mladek <[email protected]>
commit 3cffa06aeef7ece30f6b5ac0ea51f264e8fea4d0 upstream.
The commit 48021f98130880dd74 ("printk: handle blank console arguments passed in.") prevented crash caused by empty console= parameter value.
Unfortunately, this value is widely used on Chromebooks to disable the console output. The above commit caused performance regression because the messages were pushed on slow console even though nobody was watching it.
Use ttynull driver explicitly for console="" and console=null parameters. It has been created for exactly this purpose.
It causes that preferred_console is set. As a result, ttySX and ttyX are not used as a fallback. And only ttynull console gets registered by default.
It still allows to register other consoles either by additional console= parameters or SPCR. It prevents regression because it worked this way even before. Also it is a sane semantic. Preventing output on all consoles should be done another way, for example, by introducing mute_console parameter.
--- kernel/printk/printk.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
kernel/printk/printk.c +8 -1
@@ -2148,8 +2148,15 @@ static int __init console_setup(char *stchar *s, *options, *brl_options =NULL ;int idx; -if (str[0 ] ==0 ) +/* +* console="" or console=null have been suggested as a way to +* disable console output. Use ttynull that has been created +* for exacly this purpose. +*/ +if (str[0 ] ==0 ||strcmp (str,"null" ) ==0 ) { +__add_preferred_console ("ttynull" ,0 ,NULL ,NULL );return 1 ; + }if (_braille_console_setup (&str, &brl_options))return 1 ;
Greg Kroah-Hartman
maintainerPATCH 8/16 isofs: Fix out of bound access for corrupted isofs image
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit e96a1866b40570b5950cda8602c2819189c62a48 upstream.
When isofs image is suitably corrupted isofs_read_inode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.
--- fs/isofs/inode.c | 2 ++ 1 file changed, 2 insertions(+)
fs/isofs/inode.c +2 -0
@@ -1326,6 +1326,8 @@ static int isofs_read_inode(struct inode de = (struct iso_directory_record *) (bh->b_data + offset); de_len = *(unsigned char *) de; +if (de_len <sizeof (struct iso_directory_record )) + goto fail;if (offset + de_len > bufsize) {int frag1 = bufsize - offset;
Greg Kroah-Hartman
maintainerPATCH 9/16 comedi: dt9812: fix DMA buffers on stack
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 536de747bc48262225889a533db6650731ab25d3 upstream.
USB transfer buffers are typically mapped for DMA and must not be allocated on the stack or transfers will fail.
Allocate proper transfer buffers in the various command helpers and return an error on short transfers instead of acting on random stack data.
Note that this also fixes a stack info leak on systems where DMA is not used as 32 bytes are always sent to the device regardless of how short the command is.
--- drivers/staging/comedi/drivers/dt9812.c | 115 +++++++++++++++++++++++--------- 1 file changed, 86 insertions(+), 29 deletions(-)
drivers/staging/comedi/drivers/dt9812.c +86 -29
@@ -32,6 +32,7 @@#include <linux/kernel.h> #include <linux/module.h> #include <linux/errno.h> +#include <linux/slab.h> #include <linux/uaccess.h> #include "../comedi_usb.h"
@@ -237,22 +238,42 @@ static int dt9812_read_info(struct comed {struct usb_device *usb =comedi_to_usb_dev (dev);struct dt9812_private *devpriv = dev->private; -struct dt9812_usb_cmd cmd; +struct dt9812_usb_cmd *cmd; +size_t tbuf_size;int count, ret; +void *tbuf; - cmd.cmd =cpu_to_le32 (DT9812_R_FLASH_DATA ); - cmd.u.flash_data_info.address = + tbuf_size =max (sizeof (*cmd), buf_size); + + tbuf =kzalloc (tbuf_size,GFP_KERNEL ); +if (!tbuf) +return -ENOMEM ; + + cmd = tbuf; + + cmd->cmd =cpu_to_le32 (DT9812_R_FLASH_DATA ); + cmd->u.flash_data_info.address =cpu_to_le16 (DT9812_DIAGS_BOARD_INFO_ADDR + offset); - cmd.u.flash_data_info.numbytes =cpu_to_le16 (buf_size); + cmd->u.flash_data_info.numbytes =cpu_to_le16 (buf_size);/* DT9812 only responds to 32 byte writes!! */ ret =usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), - &cmd,32 , &count,DT9812_USB_TIMEOUT ); + cmd,sizeof (*cmd), &count,DT9812_USB_TIMEOUT );if (ret) -return ret; + goto out; + + ret =usb_bulk_msg (usb,usb_rcvbulkpipe (usb, devpriv->cmd_rd.addr), + tbuf, buf_size, &count,DT9812_USB_TIMEOUT ); +if (!ret) { +if (count == buf_size) +memcpy (buf, tbuf, buf_size); +else + ret = -EREMOTEIO ; + } +out: +kfree (tbuf); -return usb_bulk_msg (usb,usb_rcvbulkpipe (usb, devpriv->cmd_rd.addr), - buf, buf_size, &count,DT9812_USB_TIMEOUT ); +return ret; } static int dt9812_read_multiple_registers(struct comedi_device *dev,
@@ -261,22 +282,42 @@ static int dt9812_read_multiple_register {struct usb_device *usb =comedi_to_usb_dev (dev);struct dt9812_private *devpriv = dev->private; -struct dt9812_usb_cmd cmd; +struct dt9812_usb_cmd *cmd;int i, count, ret; +size_t buf_size; +void *buf; + + buf_size =max_t (size_t,sizeof (*cmd), reg_count); + + buf =kzalloc (buf_size,GFP_KERNEL ); +if (!buf) +return -ENOMEM ; + + cmd = buf; - cmd.cmd =cpu_to_le32 (DT9812_R_MULTI_BYTE_REG ); - cmd.u.read_multi_info.count = reg_count; + cmd->cmd =cpu_to_le32 (DT9812_R_MULTI_BYTE_REG ); + cmd->u.read_multi_info.count = reg_count;for (i =0 ; i < reg_count; i++) - cmd.u.read_multi_info.address[i] = address[i]; + cmd->u.read_multi_info.address[i] = address[i];/* DT9812 only responds to 32 byte writes!! */ ret =usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), - &cmd,32 , &count,DT9812_USB_TIMEOUT ); + cmd,sizeof (*cmd), &count,DT9812_USB_TIMEOUT );if (ret) -return ret; + goto out; -return usb_bulk_msg (usb,usb_rcvbulkpipe (usb, devpriv->cmd_rd.addr), - value, reg_count, &count,DT9812_USB_TIMEOUT ); + ret =usb_bulk_msg (usb,usb_rcvbulkpipe (usb, devpriv->cmd_rd.addr), + buf, reg_count, &count,DT9812_USB_TIMEOUT ); +if (!ret) { +if (count == reg_count) +memcpy (value, buf, reg_count); +else + ret = -EREMOTEIO ; + } +out: +kfree (buf); + +return ret; } static int dt9812_write_multiple_registers(struct comedi_device *dev,
@@ -285,19 +326,27 @@ static int dt9812_write_multiple_registe {struct usb_device *usb =comedi_to_usb_dev (dev);struct dt9812_private *devpriv = dev->private; -struct dt9812_usb_cmd cmd; +struct dt9812_usb_cmd *cmd;int i, count; +int ret; - cmd.cmd =cpu_to_le32 (DT9812_W_MULTI_BYTE_REG ); - cmd.u.read_multi_info.count = reg_count; + cmd =kzalloc (sizeof (*cmd),GFP_KERNEL ); +if (!cmd) +return -ENOMEM ; + + cmd->cmd =cpu_to_le32 (DT9812_W_MULTI_BYTE_REG ); + cmd->u.read_multi_info.count = reg_count;for (i =0 ; i < reg_count; i++) { - cmd.u.write_multi_info.write[i].address = address[i]; - cmd.u.write_multi_info.write[i].value = value[i]; + cmd->u.write_multi_info.write[i].address = address[i]; + cmd->u.write_multi_info.write[i].value = value[i]; }/* DT9812 only responds to 32 byte writes!! */ -return usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), - &cmd,32 , &count,DT9812_USB_TIMEOUT ); + ret =usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), + cmd,sizeof (*cmd), &count,DT9812_USB_TIMEOUT ); +kfree (cmd); + +return ret; } static int dt9812_rmw_multiple_registers(struct comedi_device *dev,
@@ -306,17 +355,25 @@ static int dt9812_rmw_multiple_registers {struct usb_device *usb =comedi_to_usb_dev (dev);struct dt9812_private *devpriv = dev->private; -struct dt9812_usb_cmd cmd; +struct dt9812_usb_cmd *cmd;int i, count; +int ret; + + cmd =kzalloc (sizeof (*cmd),GFP_KERNEL ); +if (!cmd) +return -ENOMEM ; - cmd.cmd =cpu_to_le32 (DT9812_RMW_MULTI_BYTE_REG ); - cmd.u.rmw_multi_info.count = reg_count; + cmd->cmd =cpu_to_le32 (DT9812_RMW_MULTI_BYTE_REG ); + cmd->u.rmw_multi_info.count = reg_count;for (i =0 ; i < reg_count; i++) - cmd.u.rmw_multi_info.rmw[i] = rmw[i]; + cmd->u.rmw_multi_info.rmw[i] = rmw[i];/* DT9812 only responds to 32 byte writes!! */ -return usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), - &cmd,32 , &count,DT9812_USB_TIMEOUT ); + ret =usb_bulk_msg (usb,usb_sndbulkpipe (usb, devpriv->cmd_wr.addr), + cmd,sizeof (*cmd), &count,DT9812_USB_TIMEOUT ); +kfree (cmd); + +return ret; }static int dt9812_digital_in (struct comedi_device *dev,u8 *bits)
Greg Kroah-Hartman
maintainerPATCH 10/16 comedi: ni_usb6501: fix NULL-deref in command paths
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 907767da8f3a925b060c740e0b5c92ea7dbec440 upstream.
The driver uses endpoint-sized USB transfer buffers but had no sanity checks on the sizes. This can lead to zero-size-pointer dereferences or overflowed transfer buffers in ni6501_port_command() and ni6501_counter_command() if a (malicious) device has smaller max-packet sizes than expected (or when doing descriptor fuzz testing).
Add the missing sanity checks to probe().
--- drivers/staging/comedi/drivers/ni_usb6501.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/staging/comedi/drivers/ni_usb6501.c +10 -0
@@ -144,6 +144,10 @@ static const u8 READ_COUNTER_RESPONSE[]0x00 ,0x00 ,0x00 ,0x02 , 0x00, 0x00, 0x00, 0x00}; +/* Largest supported packets */ +static const size_t TX_MAX_SIZE =sizeof (SET_PORT_DIR_REQUEST ); +static const size_t RX_MAX_SIZE =sizeof (READ_PORT_RESPONSE ); +enum commands {READ_PORT , WRITE_PORT,
@@ -501,6 +505,12 @@ static int ni6501_find_endpoints(structif (!devpriv->ep_rx || !devpriv->ep_tx)return -ENODEV ; +if (usb_endpoint_maxp (devpriv->ep_rx) <RX_MAX_SIZE ) +return -ENODEV ; + +if (usb_endpoint_maxp (devpriv->ep_tx) <TX_MAX_SIZE ) +return -ENODEV ; +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 11/16 comedi: vmk80xx: fix transfer-buffer overflows
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit a23461c47482fc232ffc9b819539d1f837adf2b1 upstream.
The driver uses endpoint-sized USB transfer buffers but up until recently had no sanity checks on the sizes.
Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize of usb endpoints found") inadvertently fixed NULL-pointer dereferences when accessing the transfer buffers in case a malicious device has a zero wMaxPacketSize.
Make sure to allocate buffers large enough to handle also the other accesses that are done without a size check (e.g. byte 18 in vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond the buffers, for example, when doing descriptor fuzzing.
The original driver was for a low-speed device with 8-byte buffers. Support was later added for a device that uses bulk transfers and is presumably a full-speed device with a maximum 64-byte wMaxPacketSize.
--- drivers/staging/comedi/drivers/vmk80xx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/staging/comedi/drivers/vmk80xx.c +4 -2
@@ -90,6 +90,8 @@ enum {#define IC3_VERSION BIT(0)#define IC6_VERSION BIT(1) +#define MIN_BUF_SIZE 64 +enum vmk80xx_model {VMK8055_MODEL ,VMK8061_MODEL
@@ -678,12 +680,12 @@ static int vmk80xx_alloc_usb_buffers(strstruct vmk80xx_private *devpriv = dev->private;size_t size; - size =usb_endpoint_maxp (devpriv->ep_rx); + size =max (usb_endpoint_maxp (devpriv->ep_rx),MIN_BUF_SIZE ); devpriv->usb_rx_buf =kzalloc (size,GFP_KERNEL );if (!devpriv->usb_rx_buf)return -ENOMEM ; - size =usb_endpoint_maxp (devpriv->ep_tx); + size =max (usb_endpoint_maxp (devpriv->ep_rx),MIN_BUF_SIZE ); devpriv->usb_tx_buf =kzalloc (size,GFP_KERNEL );if (!devpriv->usb_tx_buf)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 12/16 comedi: vmk80xx: fix bulk-buffer overflow
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 78cdfd62bd54af615fba9e3ca1ba35de39d3871d upstream.
The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers.
--- drivers/staging/comedi/drivers/vmk80xx.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-)
drivers/staging/comedi/drivers/vmk80xx.c +7 -9
@@ -159,22 +159,20 @@ static void vmk80xx_do_bulk_msg(struct c__u8 rx_addr;unsigned int tx_pipe;unsigned int rx_pipe; -size_t size; +size_t tx_size; +size_t rx_size; tx_addr = devpriv->ep_tx->bEndpointAddress; rx_addr = devpriv->ep_rx->bEndpointAddress; tx_pipe =usb_sndbulkpipe (usb, tx_addr); rx_pipe =usb_rcvbulkpipe (usb, rx_addr); - -/* -* The max packet size attributes of the K8061 -* input/output endpoints are identical -*/ - size =usb_endpoint_maxp (devpriv->ep_tx); + tx_size =usb_endpoint_maxp (devpriv->ep_tx); + rx_size =usb_endpoint_maxp (devpriv->ep_rx);usb_bulk_msg (usb, tx_pipe, devpriv->usb_tx_buf, - size,NULL , devpriv->ep_tx->bInterval); -usb_bulk_msg (usb, rx_pipe, devpriv->usb_rx_buf, size,NULL ,HZ *10 ); + tx_size,NULL , devpriv->ep_tx->bInterval); + +usb_bulk_msg (usb, rx_pipe, devpriv->usb_rx_buf, rx_size,NULL ,HZ *10 ); }static int vmk80xx_read_packet (struct comedi_device *dev)
Greg Kroah-Hartman
maintainerPATCH 13/16 comedi: vmk80xx: fix bulk and interrupt message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit a56d3e40bda460edf3f8d6aac00ec0b322b4ab83 upstream.
USB bulk and interrupt message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
Note that the bulk-out transfer timeout was set to the endpoint bInterval value, which should be ignored for bulk endpoints and is typically set to zero. This meant that a failing bulk-out transfer would never time out.
Assume that the 10 second timeout used for all other transfers is more than enough also for the bulk-out endpoint.
--- drivers/staging/comedi/drivers/vmk80xx.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/staging/comedi/drivers/vmk80xx.c +7 -5
@@ -91,6 +91,7 @@ enum {#define IC6_VERSION BIT(1)#define MIN_BUF_SIZE 64 +#define PACKET_TIMEOUT 10000/* ms */ enum vmk80xx_model {VMK8055_MODEL ,
@@ -169,10 +170,11 @@ static void vmk80xx_do_bulk_msg(struct c tx_size =usb_endpoint_maxp (devpriv->ep_tx); rx_size =usb_endpoint_maxp (devpriv->ep_rx); -usb_bulk_msg (usb, tx_pipe, devpriv->usb_tx_buf, - tx_size,NULL , devpriv->ep_tx->bInterval); +usb_bulk_msg (usb, tx_pipe, devpriv->usb_tx_buf, tx_size,NULL , +PACKET_TIMEOUT ); -usb_bulk_msg (usb, rx_pipe, devpriv->usb_rx_buf, rx_size,NULL ,HZ *10 ); +usb_bulk_msg (usb, rx_pipe, devpriv->usb_rx_buf, rx_size,NULL , +PACKET_TIMEOUT ); }static int vmk80xx_read_packet (struct comedi_device *dev)
@@ -191,7 +193,7 @@ static int vmk80xx_read_packet(struct co pipe =usb_rcvintpipe (usb, ep->bEndpointAddress);return usb_interrupt_msg (usb, pipe, devpriv->usb_rx_buf,usb_endpoint_maxp (ep),NULL , -HZ *10 ); +PACKET_TIMEOUT ); }static int vmk80xx_write_packet (struct comedi_device *dev,int cmd)
@@ -212,7 +214,7 @@ static int vmk80xx_write_packet(struct c pipe =usb_sndintpipe (usb, ep->bEndpointAddress);return usb_interrupt_msg (usb, pipe, devpriv->usb_tx_buf,usb_endpoint_maxp (ep),NULL , -HZ *10 ); +PACKET_TIMEOUT ); }static int vmk80xx_reset_device (struct comedi_device *dev)
Greg Kroah-Hartman
maintainerPATCH 14/16 staging: r8712u: fix control-message timeout
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit ce4940525f36ffdcf4fa623bcedab9c2a6db893a upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/staging/rtl8712/usb_ops_linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/rtl8712/usb_ops_linux.c +1 -1
@@ -505,7 +505,7 @@ int r8712_usbctrl_vendorreq(struct intf_memcpy (pIo_buf, pdata, len); } status =usb_control_msg (udev, pipe, request, reqtype, value, index, - pIo_buf, len,HZ /2 ); + pIo_buf, len,500 );if (status >0 ) {/* Success this control transfer. */ if (requesttype ==0x01 ) {/* For Control read transfer, we have to copy the read
Greg Kroah-Hartman
maintainerPATCH 15/16 staging: rtl8192u: fix control-message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 4cfa36d312d6789448b59a7aae770ac8425017a3 upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/staging/rtl8192u/r8192U_core.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/staging/rtl8192u/r8192U_core.c +9 -9
@@ -266,7 +266,7 @@ int write_nic_byte_E(struct net_device * status =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ),RTL8187_REQ_SET_REGS ,RTL8187_REQT_WRITE , - indx |0xfe00 ,0 , usbdata,1 ,HZ /2 ); + indx |0xfe00 ,0 , usbdata,1 ,500 );kfree (usbdata);if (status <0 ) {
@@ -288,7 +288,7 @@ int read_nic_byte_E(struct net_device *d status =usb_control_msg (udev,usb_rcvctrlpipe (udev,0 ),RTL8187_REQ_GET_REGS ,RTL8187_REQT_READ , - indx |0xfe00 ,0 , usbdata,1 ,HZ /2 ); + indx |0xfe00 ,0 , usbdata,1 ,500 ); *data = *usbdata;kfree (usbdata);
@@ -316,7 +316,7 @@ int write_nic_byte(struct net_device *de status =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ),RTL8187_REQ_SET_REGS ,RTL8187_REQT_WRITE , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,1 ,HZ /2 ); + usbdata,1 ,500 );kfree (usbdata);if (status <0 ) {
@@ -343,7 +343,7 @@ int write_nic_word(struct net_device *de status =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ),RTL8187_REQ_SET_REGS ,RTL8187_REQT_WRITE , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,2 ,HZ /2 ); + usbdata,2 ,500 );kfree (usbdata);if (status <0 ) {
@@ -370,7 +370,7 @@ int write_nic_dword(struct net_device *d status =usb_control_msg (udev,usb_sndctrlpipe (udev,0 ),RTL8187_REQ_SET_REGS ,RTL8187_REQT_WRITE , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,4 ,HZ /2 ); + usbdata,4 ,500 );kfree (usbdata);
@@ -397,7 +397,7 @@ int read_nic_byte(struct net_device *dev status =usb_control_msg (udev,usb_rcvctrlpipe (udev,0 ),RTL8187_REQ_GET_REGS ,RTL8187_REQT_READ , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,1 ,HZ /2 ); + usbdata,1 ,500 ); *data = *usbdata;kfree (usbdata);
@@ -424,7 +424,7 @@ int read_nic_word(struct net_device *dev status =usb_control_msg (udev,usb_rcvctrlpipe (udev,0 ),RTL8187_REQ_GET_REGS ,RTL8187_REQT_READ , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,2 ,HZ /2 ); + usbdata,2 ,500 ); *data = *usbdata;kfree (usbdata);
@@ -448,7 +448,7 @@ static int read_nic_word_E(struct net_de status =usb_control_msg (udev,usb_rcvctrlpipe (udev,0 ),RTL8187_REQ_GET_REGS ,RTL8187_REQT_READ , - indx |0xfe00 ,0 , usbdata,2 ,HZ /2 ); + indx |0xfe00 ,0 , usbdata,2 ,500 ); *data = *usbdata;kfree (usbdata);
@@ -474,7 +474,7 @@ int read_nic_dword(struct net_device *de status =usb_control_msg (udev,usb_rcvctrlpipe (udev,0 ),RTL8187_REQ_GET_REGS ,RTL8187_REQT_READ , (indx &0xff ) |0xff00 , (indx >>8 ) &0x0f , - usbdata,4 ,HZ /2 ); + usbdata,4 ,500 ); *data = *usbdata;kfree (usbdata);
Greg Kroah-Hartman
maintainerPATCH 16/16 rsi: fix control-message timeout
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 541fd20c3ce5b0bc39f0c6a52414b6b92416831c upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
Use the common control-message timeout define for the five-second timeout.
--- drivers/net/wireless/rsi/rsi_91x_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/rsi/rsi_91x_usb.c +1 -1
@@ -61,7 +61,7 @@ static int rsi_usb_card_write(struct rsi (void *)seg, (int )len, &transfer, - HZ * 5); + USB_CTRL_SET_TIMEOUT);if (status <0 ) { rsi_dbg(ERR_ZONE,
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. Anything received after that time might be too late.
Build test:
mips (gcc version 11.2.1 20211104): 63 configs -> no failure arm (gcc version 11.2.1 20211104): 116 configs -> no new failure arm64 (gcc version 11.2.1 20211104): 2 configs -> no failure x86_64 (gcc version 11.2.1 20211104): 4 configs -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/363
--
Regards
Sudip
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.217-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.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.
## Build
* kernel: 4.19.217-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.19.y
* git commit: f1ca790424bdd0693e501e24dc3300f01460cfed
* git describe: v4.19.216-17-gf1ca790424bd
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.216-17-gf1ca790424bd
## No regressions (compared to v4.19.216)
## No fixes (compared to v4.19.216)
## Test result summary
total: 83189, pass: 66945, fail: 783, skip: 13526, xfail: 1935
## Build Summary
* arm: 130 total, 108 passed, 22 failed
* arm64: 38 total, 38 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 27 total, 27 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 22 total, 22 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-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-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.217-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 441 pass: 441 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.217 release. There are 16 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 Fri, 12 Nov 2021 18:19:54 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.217-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.19:
10 builds: 10 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 failLinux version: 4.19.217-rc1-gf1ca790424bd
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Jon