4.4.283-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.4.283-rc1 review
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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, 03 Sep 2021 12:22:41 +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.4.283-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.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.283-rc1
Denis Efremov <[email protected]>
Revert "floppy: reintroduce O_NDELAY fix"
George Kennedy <[email protected]>
fbmem: add margin check to fb_check_caps()
Linus Torvalds <[email protected]>
vt_kdsetmode: extend console locking
Neeraj Upadhyay <[email protected]>
vringh: Use wiov->used to check for read/write desc order
Parav Pandit <[email protected]>
virtio: Improve vq->broken access to avoid any compiler optimization
Maxim Kiselev <[email protected]>
net: marvell: fix MVNETA_TX_IN_PRGRS bit number
Sasha Neftin <[email protected]>
e1000e: Fix the max snoop/no-snoop latency for 10M
Zhengjun Zhang <[email protected]>
USB: serial: option: add new VID/PID to support Fibocom FG150
Johan Hovold <[email protected]>
Revert "USB: serial: ch341: fix character loss at high transfer rates"
Stefan Mätje <[email protected]>
can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters
-------------
Diffstat:
Makefile | 4 ++-- drivers/block/floppy.c | 27 +++++++++++++-------------- drivers/net/can/usb/esd_usb2.c | 4 ++-- drivers/net/ethernet/intel/e1000e/ich8lan.c | 14 +++++++++++++- drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 +++ drivers/net/ethernet/marvell/mvneta.c | 2 +- drivers/tty/vt/vt_ioctl.c | 11 +++++++---- drivers/usb/serial/ch341.c | 1 - drivers/usb/serial/option.c | 2 ++ drivers/vhost/vringh.c | 2 +- drivers/video/fbdev/core/fbmem.c | 4 ++++ drivers/virtio/virtio_ring.c | 6 ++++-- 12 files changed, 52 insertions(+), 28 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/10 can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters
From: Stefan Mätje <[email protected]>
commit 044012b52029204900af9e4230263418427f4ba4 upstream.
This patch fixes the interchanged fetch of the CAN RX and TX error counters from the ESD_EV_CAN_ERROR_EXT message. The RX error counter is really in struct rx_msg::data[2] and the TX error counter is in struct rx_msg::data[3].
--- drivers/net/can/usb/esd_usb2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/can/usb/esd_usb2.c +2 -2
@@ -236,8 +236,8 @@ static void esd_usb2_rx_event(struct esdif (id ==ESD_EV_CAN_ERROR_EXT ) {u8 state = msg->msg.rx.data[0 ];u8 ecc = msg->msg.rx.data[1 ]; -u8 txerr = msg->msg.rx.data[2 ]; -u8 rxerr = msg->msg.rx.data[3 ]; +u8 rxerr = msg->msg.rx.data[2 ]; +u8 txerr = msg->msg.rx.data[3 ]; skb =alloc_can_err_skb (priv->netdev, &cf);if (skb ==NULL ) {
Greg Kroah-Hartman
maintainerPATCH 2/10 Revert "USB: serial: ch341: fix character loss at high transfer rates"
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit df7b16d1c00ecb3da3a30c999cdb39f273c99a2f upstream.
This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b.
These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size. This means that incoming data may not be processed by the driver until a short packet is received or the receive buffer is full.
Revert back to using endpoint-sized receive buffers to avoid stalled reads.
--- drivers/usb/serial/ch341.c | 1 - 1 file changed, 1 deletion(-)
drivers/usb/serial/ch341.c +0 -1
@@ -585,7 +585,6 @@ static struct usb_serial_driver ch341_de .owner = THIS_MODULE, .name = "ch341-uart", }, - .bulk_in_size = 512, .id_table = id_table, .num_ports = 1, .open = ch341_open,
Greg Kroah-Hartman
maintainerPATCH 3/10 USB: serial: option: add new VID/PID to support Fibocom FG150
In reply to Greg Kroah-HartmanFrom: Zhengjun Zhang <[email protected]>
commit 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a upstream.
Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform, support Sub-6G band.
Here are the outputs of lsusb -v and usb-devices:
Quoted 236 lines
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2cb7 ProdID=010b Rev=04.14 S: Manufacturer=Fibocom S: Product=Fibocom Modem_SN:XXXXXXXX S: SerialNumber=XXXXXXXX C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2cb7 Fibocom idProduct 0x010b bcdDevice 4.14 iManufacturer 1 Fibocom iProduct 2 Fibocom Modem_SN:XXXXXXXX iSerial 3 XXXXXXXX bNumConfigurations 1Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength0x00e6
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 4RNDIS_DUN_DIAG_ADB
bmAttributes0xa0
(Bus Powered)
Remote Wakeup
MaxPower 896mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 239 Miscellaneous Device
bFunctionSubClass 4
bFunctionProtocol 1
iFunction 7 RNDIS
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 239 Miscellaneous Device
bInterfaceSubClass 4
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 01
** UNRECOGNIZED: 04 24 02 00
** UNRECOGNIZED: 05 24 06 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x81EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x00081x 8 bytes
bInterval 9
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x8eEP 14 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 6
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x0fEP 15 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 6
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x83EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x000a1x 10 bytes
bInterval 9
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x82EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x01EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 48
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x84EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x02EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize0x04001x 1024 bytes
bInterval 0
bMaxBurst 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes0x00000006
BESL Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes0x00
wSpeedsSupported0x000f
Device can operate at Low Speed (1Mbps)
Device can operate at Full Speed (12Mbps)
Quoted 8 lines
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 1 micro seconds
bU2DevExitLat 500 micro seconds
Device Status:0x0000
(Bus Powered)
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -2058,6 +2058,8 @@ static const struct usb_device_id option .driver_info = RSVD(4) | RSVD(5) }, { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */ .driver_info = RSVD(6) }, + { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0xff, 0x30) }, /* Fibocom FG150 Diag */ + { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0, 0) }, /* Fibocom FG150 AT */ { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x01a0, 0xff) }, /* Fibocom NL668-AM/NL652-EU (laptop MBIM) */ { USB_DEVICE_INTERFACE_CLASS(0x2df3, 0x9d03, 0xff) }, /* LongSung M5710 */ { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1404, 0xff) }, /* GosunCn GM500 RNDIS */
Greg Kroah-Hartman
maintainerPATCH 4/10 e1000e: Fix the max snoop/no-snoop latency for 10M
In reply to Greg Kroah-HartmanFrom: Sasha Neftin <[email protected]>
[ Upstream commit 44a13a5d99c71bf9e1676d9e51679daf4d7b3d73 ]
We should decode the latency and the max_latency before directly compare. The latency should be presented as lat_enc = scale x value:lat_enc_d = (lat_enc & 0x0x3ff) x (1U << (5*((max_ltr_enc & 0x1c00)
Quoted 1 line
Quoted 1 line
10)))
--- drivers/net/ethernet/intel/e1000e/ich8lan.c | 14 +++++++++++++- drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 +++ 2 files changed, 16 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/e1000e/ich8lan.c +13 -1
@@ -1010,6 +1010,8 @@ static s32 e1000_platform_pm_pch_lpt(struct e1000_hw *hw, bool link) {u32 reg = link << (E1000_LTRV_REQ_SHIFT +E1000_LTRV_NOSNOOP_SHIFT ) | link <<E1000_LTRV_REQ_SHIFT |E1000_LTRV_SEND ; +u16 max_ltr_enc_d =0 ;/* maximum LTR decoded by platform */ +u16 lat_enc_d =0 ;/* latency decoded */ u16 lat_enc =0 ;/* latency encoded */ if (link) {
@@ -1063,7 +1065,17 @@ static s32 e1000_platform_pm_pch_lpt(struct e1000_hw *hw, bool link) E1000_PCI_LTR_CAP_LPT + 2, &max_nosnoop); max_ltr_enc =max_t (u16, max_snoop, max_nosnoop); -if (lat_enc > max_ltr_enc) + lat_enc_d = (lat_enc &E1000_LTRV_VALUE_MASK ) * + (1U << (E1000_LTRV_SCALE_FACTOR * + ((lat_enc &E1000_LTRV_SCALE_MASK ) + >>E1000_LTRV_SCALE_SHIFT ))); + + max_ltr_enc_d = (max_ltr_enc &E1000_LTRV_VALUE_MASK ) * + (1U << (E1000_LTRV_SCALE_FACTOR * + ((max_ltr_enc &E1000_LTRV_SCALE_MASK ) + >>E1000_LTRV_SCALE_SHIFT ))); + +if (lat_enc_d > max_ltr_enc_d) lat_enc = max_ltr_enc; }
drivers/net/ethernet/intel/e1000e/ich8lan.h +3 -0
@@ -284,8 +284,11 @@/* Latency Tolerance Reporting */ #define E1000_LTRV 0x000F8 +#define E1000_LTRV_VALUE_MASK 0x000003FF#define E1000_LTRV_SCALE_MAX 5#define E1000_LTRV_SCALE_FACTOR 5 +#define E1000_LTRV_SCALE_SHIFT 10 +#define E1000_LTRV_SCALE_MASK 0x00001C00#define E1000_LTRV_REQ_SHIFT 15#define E1000_LTRV_NOSNOOP_SHIFT 16#define E1000_LTRV_SEND (1 << 30)
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 5/10 net: marvell: fix MVNETA_TX_IN_PRGRS bit number
In reply to Greg Kroah-HartmanFrom: Maxim Kiselev <[email protected]>
[ Upstream commit 359f4cdd7d78fdf8c098713b05fee950a730f131 ]
According to Armada XP datasheet bit at 0 position is corresponding for TxInProg indication.
--- drivers/net/ethernet/marvell/mvneta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/mvneta.c +1 -1
@@ -90,7 +90,7 @@#define MVNETA_DESC_SWAP BIT(6)#define MVNETA_TX_BRST_SZ_MASK (burst) ((burst) << 22)#define MVNETA_PORT_STATUS 0x2444 -#define MVNETA_TX_IN_PRGRS BIT(1) +#define MVNETA_TX_IN_PRGRS BIT(0)#define MVNETA_TX_FIFO_EMPTY BIT(8)#define MVNETA_RX_MIN_FRAME_SIZE 0x247c#define MVNETA_SERDES_CFG 0x24A0
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 6/10 virtio: Improve vq->broken access to avoid any compiler optimization
In reply to Greg Kroah-HartmanFrom: Parav Pandit <[email protected]>
[ Upstream commit 60f0779862e4ab943810187752c462e85f5fa371 ]
Currently vq->broken field is read by virtqueue_is_broken() in busy loop in one context by virtnet_send_command().
vq->broken is set to true in other process context by virtio_break_device(). Reader and writer are accessing it without any synchronization. This may lead to a compiler optimization which may result to optimize reading vq->broken only once.
Hence, force reading vq->broken on each invocation of virtqueue_is_broken() and also force writing it so that such update is visible to the readers.
It is a theoretical fix that isn't yet encountered in the field.
--- drivers/virtio/virtio_ring.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/virtio/virtio_ring.c +4 -2
@@ -840,7 +840,7 @@ bool virtqueue_is_broken(struct virtqueue *_vq) {struct vring_virtqueue *vq =to_vvq (_vq); -return vq->broken; +return READ_ONCE (vq->broken); }EXPORT_SYMBOL_GPL (virtqueue_is_broken);
@@ -854,7 +854,9 @@ void virtio_break_device(struct virtio_device *dev)list_for_each_entry (_vq, &dev->vqs, list) {struct vring_virtqueue *vq =to_vvq (_vq); - vq->broken = true; + +/* Pairs with READ_ONCE() in virtqueue_is_broken(). */ +WRITE_ONCE (vq->broken, true); } }EXPORT_SYMBOL_GPL (virtio_break_device);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 7/10 vringh: Use wiov->used to check for read/write desc order
In reply to Greg Kroah-HartmanFrom: Neeraj Upadhyay <[email protected]>
[ Upstream commit e74cfa91f42c50f7f649b0eca46aa049754ccdbd ]
As __vringh_iov() traverses a descriptor chain, it populates each descriptor entry into either read or write vring iov and increments that iov's ->used member. So, as we iterate over a descriptor chain, at any point, (riov/wriov)->used value gives the number of descriptor enteries available, which are to be read or written by the device. As all read iovs must precede the write iovs, wiov->used should be zero when we are traversing a read descriptor. Current code checks for wiov->i, to figure out whether any previous entry in the current descriptor chain was a write descriptor. However, iov->i is only incremented, when these vring iovs are consumed, at a later point, and remain 0 in __vringh_iov(). So, correct the check for read and write descriptor order, to use wiov->used.
--- drivers/vhost/vringh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vhost/vringh.c +1 -1
@@ -329,7 +329,7 @@ __vringh_iov(struct vringh *vrh, u16 i, iov = wiov; else { iov = riov; -if (unlikely (wiov && wiov->i)) { +if (unlikely (wiov && wiov->used)) {vringh_bad ("Readable desc %p after writable" , &descs[i]); err = -EINVAL ;
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 8/10 vt_kdsetmode: extend console locking
In reply to Greg Kroah-HartmanFrom: Linus Torvalds <[email protected]>
commit 2287a51ba822384834dafc1c798453375d1107c7 upstream.
As per the long-suffering comment.
--- drivers/tty/vt/vt_ioctl.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/tty/vt/vt_ioctl.c +7 -4
@@ -487,16 +487,19 @@ int vt_ioctl(struct tty_struct *tty, ret = -EINVAL ; goto out; } -/* FIXME: this needs the console lock extending */ -if (vc->vc_mode == (unsigned char ) arg) +console_lock (); +if (vc->vc_mode == (unsigned char ) arg) { +console_unlock ();break ; + } vc->vc_mode = (unsigned char ) arg; -if (console != fg_console) +if (console != fg_console) { +console_unlock ();break ; + }/* * explicitly blank/unblank the screen if switching modes */ -console_lock ();if (arg ==KD_TEXT )do_unblank_screen (1 );else
Greg Kroah-Hartman
maintainerPATCH 9/10 fbmem: add margin check to fb_check_caps()
In reply to Greg Kroah-HartmanFrom: George Kennedy <[email protected]>
commit a49145acfb975d921464b84fe00279f99827d816 upstream.
A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a
KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur.
Add a margin check to validate xres and yres settings.
--- drivers/video/fbdev/core/fbmem.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/video/fbdev/core/fbmem.c +4 -0
@@ -1001,6 +1001,10 @@ fb_set_var(struct fb_info *info, struct goto done; } +/* bitfill_aligned() assumes that it's at least 8x8 */ +if (var->xres <8 || var->yres <8 ) +return -EINVAL ; + ret = info->fbops->fb_check_var (var, info);if (ret)
Greg Kroah-Hartman
maintainerPATCH 10/10 Revert "floppy: reintroduce O_NDELAY fix"
In reply to Greg Kroah-HartmanFrom: Denis Efremov <[email protected]>
commit c7e9d0020361f4308a70cdfd6d5335e273eb8717 upstream.
The patch breaks userspace implementations (e.g. fdutils) and introduces regressions in behaviour. Previously, it was possible to O_NDELAY open a floppy device with no media inserted or with write protected media without an error. Some userspace tools use this particular behavior for probing.
It's not the first time when we revert this patch. Previous revert is in commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
--- drivers/block/floppy.c | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-)
drivers/block/floppy.c +13 -14
@@ -4066,22 +4066,21 @@ static int floppy_open(struct block_deviif (UFDCS ->rawcmd ==1 )UFDCS ->rawcmd =2 ; -if (mode & (FMODE_READ |FMODE_WRITE )) { -UDRS ->last_checked =0 ; -clear_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags); -check_disk_change (bdev); -if (test_bit (FD_DISK_CHANGED_BIT , &UDRS ->flags)) - goto out; -if (test_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags)) +if (!(mode &FMODE_NDELAY )) { +if (mode & (FMODE_READ |FMODE_WRITE )) { +UDRS ->last_checked =0 ; +clear_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags); +check_disk_change (bdev); +if (test_bit (FD_DISK_CHANGED_BIT , &UDRS ->flags)) + goto out; +if (test_bit (FD_OPEN_SHOULD_FAIL_BIT , &UDRS ->flags)) + goto out; + } + res = -EROFS ; +if ((mode &FMODE_WRITE ) && + !test_bit (FD_DISK_WRITABLE_BIT , &UDRS ->flags)) goto out; } - - res = -EROFS ; - -if ((mode &FMODE_WRITE ) && - !test_bit (FD_DISK_WRITABLE_BIT , &UDRS ->flags)) - goto out; -mutex_unlock (&open_lock);mutex_unlock (&floppy_mutex);return 0 ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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, 03 Sep 2021 12:22:41 +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.4.283-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
30 tests: 30 pass, 0 failLinux version: 4.4.283-rc1-gd0f43d936dd1
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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, 03 Sep 2021 12:22:41 +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.4.283-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
30 tests: 30 pass, 0 failLinux version: 4.4.283-rc1-gd0f43d936dd1
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Jon
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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.4.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 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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.
Quoted 9 lines
Responses should be made by Fri, 03 Sep 2021 12:22:41 +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.4.283-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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, 03 Sep 2021 12:22:41 +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.4.283-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.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.4.283-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.4.y
* git commit: d0f43d936dd1700f7b90bcf6ee0b333159a0feb3
* git describe: v4.4.282-11-gd0f43d936dd1
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.282-11-gd0f43d936dd1
## No regressions (compared to v4.4.282-6-gdeced08a3ab0)
## No fixes (compared to v4.4.282-6-gdeced08a3ab0)
## Test result summary
total: 53253, pass: 42320, fail: 257, skip: 9391, xfail: 1285
## Build Summary
* arm: 97 total, 97 passed, 0 failed
* arm64: 30 total, 30 passed, 0 failed
* i386: 14 total, 14 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 14 total, 14 passed, 0 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* 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-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* 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
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.283 release. There are 10 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, 03 Sep 2021 12:22:41 +0000. Anything received after that time might be too late.
Build results:
total: 160 pass: 160 fail: 0 Qemu test results: total: 338 pass: 338 fail: 0
Guenter