* [PATCH 4.4 01/10] can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 02/10] Revert "USB: serial: ch341: fix character loss at high transfer rates" Greg Kroah-Hartman
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Mätje, Marc Kleine-Budde
From: Stefan Mätje <stefan.maetje@esd.eu>
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].
Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Link: https://lore.kernel.org/r/20210825215227.4947-2-stefan.maetje@esd.eu
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/usb/esd_usb2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/can/usb/esd_usb2.c
+++ b/drivers/net/can/usb/esd_usb2.c
@@ -236,8 +236,8 @@ static void esd_usb2_rx_event(struct esd
if (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) {
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 4.4 02/10] Revert "USB: serial: ch341: fix character loss at high transfer rates"
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 01/10] can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 03/10] USB: serial: option: add new VID/PID to support Fibocom FG150 Greg Kroah-Hartman
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Größel, Willy Tarreau,
Johan Hovold
From: Johan Hovold <johan@kernel.org>
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.
Reported-by: Paul Größel <pb.g@gmx.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131
Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates")
Cc: stable@vger.kernel.org
Cc: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ch341.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -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,
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 4.4 03/10] USB: serial: option: add new VID/PID to support Fibocom FG150
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 01/10] can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 02/10] Revert "USB: serial: ch341: fix character loss at high transfer rates" Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 04/10] e1000e: Fix the max snoop/no-snoop latency for 10M Greg Kroah-Hartman
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Zhengjun Zhang, Johan Hovold
From: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
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:
> 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.20
> bDeviceClass 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 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 0x00e6
> bNumInterfaces 5
> bConfigurationValue 1
> iConfiguration 4 RNDIS_DUN_DIAG_ADB
> bmAttributes 0xa0
> (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
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 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
> bEndpointAddress 0x8e EP 14 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 6
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x0f EP 15 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 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
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x000a 1x 10 bytes
> bInterval 9
> bMaxBurst 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 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
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 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
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x85 EP 5 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 0
> Binary Object Store Descriptor:
> bLength 5
> bDescriptorType 15
> wTotalLength 0x0016
> bNumDeviceCaps 2
> USB 2.0 Extension Device Capability:
> bLength 7
> bDescriptorType 16
> bDevCapabilityType 2
> bmAttributes 0x00000006
> BESL Link Power Management (LPM) Supported
> SuperSpeed USB Device Capability:
> bLength 10
> bDescriptorType 16
> bDevCapabilityType 3
> bmAttributes 0x00
> wSpeedsSupported 0x000f
> Device can operate at Low Speed (1Mbps)
> Device can operate at Full Speed (12Mbps)
> 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)
Signed-off-by: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -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 */
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 4.4 04/10] e1000e: Fix the max snoop/no-snoop latency for 10M
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 03/10] USB: serial: option: add new VID/PID to support Fibocom FG150 Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 05/10] net: marvell: fix MVNETA_TX_IN_PRGRS bit number Greg Kroah-Hartman
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yee Li, Sasha Neftin,
Dvora Fuxbrumer, Tony Nguyen, Sasha Levin
From: Sasha Neftin <sasha.neftin@intel.com>
[ 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)
>> 10)))
Fixes: cf8fb73c23aa ("e1000e: add support for LTR on I217/I218")
Suggested-by: Yee Li <seven.yi.lee@gmail.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 14 +++++++++++++-
drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 485b9cc53f8b..cd7403d09c3d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -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;
}
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index 34c551e322eb..3a16c457c8dd 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -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)
--
2.30.2
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4.4 05/10] net: marvell: fix MVNETA_TX_IN_PRGRS bit number
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 04/10] e1000e: Fix the max snoop/no-snoop latency for 10M Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 06/10] virtio: Improve vq->broken access to avoid any compiler optimization Greg Kroah-Hartman
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maxim Kiselev, David S. Miller, Sasha Levin
From: Maxim Kiselev <bigunclemax@gmail.com>
[ Upstream commit 359f4cdd7d78fdf8c098713b05fee950a730f131 ]
According to Armada XP datasheet bit at 0 position is corresponding for
TxInProg indication.
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 575da945f151..d6b25aba4004 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -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
--
2.30.2
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4.4 06/10] virtio: Improve vq->broken access to avoid any compiler optimization
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 05/10] net: marvell: fix MVNETA_TX_IN_PRGRS bit number Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 07/10] vringh: Use wiov->used to check for read/write desc order Greg Kroah-Hartman
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Parav Pandit, Michael S. Tsirkin,
Sasha Levin
From: Parav Pandit <parav@nvidia.com>
[ 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.
Signed-off-by: Parav Pandit <parav@nvidia.com>
Link: https://lore.kernel.org/r/20210721142648.1525924-2-parav@nvidia.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/virtio/virtio_ring.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 6b3565feddb2..b15c24c4d91f 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -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);
--
2.30.2
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4.4 07/10] vringh: Use wiov->used to check for read/write desc order
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 06/10] virtio: Improve vq->broken access to avoid any compiler optimization Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 08/10] vt_kdsetmode: extend console locking Greg Kroah-Hartman
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Wang, Stefano Garzarella,
Neeraj Upadhyay, Michael S. Tsirkin, Sasha Levin
From: Neeraj Upadhyay <neeraju@codeaurora.org>
[ 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.
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Link: https://lore.kernel.org/r/1624591502-4827-1-git-send-email-neeraju@codeaurora.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vhost/vringh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index d56736655dec..da47542496cc 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -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;
--
2.30.2
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4.4 08/10] vt_kdsetmode: extend console locking
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 07/10] vringh: Use wiov->used to check for read/write desc order Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 09/10] fbmem: add margin check to fb_check_caps() Greg Kroah-Hartman
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Minh Yuan, Jiri Slaby, Linus Torvalds
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 2287a51ba822384834dafc1c798453375d1107c7 upstream.
As per the long-suffering comment.
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt_ioctl.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -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
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 4.4 09/10] fbmem: add margin check to fb_check_caps()
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 08/10] vt_kdsetmode: extend console locking Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 12:26 ` [PATCH 4.4 10/10] Revert "floppy: reintroduce O_NDELAY fix" Greg Kroah-Hartman
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, George Kennedy,
syzbot+e5fd3e65515b48c02a30, Dan Carpenter, Dhaval Giani,
Bartlomiej Zolnierkiewicz
From: George Kennedy <george.kennedy@oracle.com>
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.
Signed-off-by: George Kennedy <george.kennedy@oracle.com>
Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dhaval Giani <dhaval.giani@oracle.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbmem.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -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)
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 4.4 10/10] Revert "floppy: reintroduce O_NDELAY fix"
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 09/10] fbmem: add margin check to fb_check_caps() Greg Kroah-Hartman
@ 2021-09-01 12:26 ` Greg Kroah-Hartman
2021-09-01 19:21 ` [PATCH 4.4 00/10] 4.4.283-rc1 review Jon Hunter
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2021-09-01 12:26 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Hounschell, Jiri Kosina,
Wim Osterholt, Kurt Garloff, Denis Efremov
From: Denis Efremov <efremov@linux.com>
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.
Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@compro.net/
Reported-by: Mark Hounschell <markh@compro.net>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Wim Osterholt <wim@djo.tudelft.nl>
Cc: Kurt Garloff <kurt@garloff.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/floppy.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4066,22 +4066,21 @@ static int floppy_open(struct block_devi
if (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;
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-09-01 12:26 ` [PATCH 4.4 10/10] Revert "floppy: reintroduce O_NDELAY fix" Greg Kroah-Hartman
@ 2021-09-01 19:21 ` Jon Hunter
2021-09-01 19:21 ` Jon Hunter
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Jon Hunter @ 2021-09-01 19:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, stable, linux-tegra
On Wed, 01 Sep 2021 14:26:14 +0200, Greg Kroah-Hartman wrote:
> 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
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 fail
Linux version: 4.4.283-rc1-gd0f43d936dd1
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-09-01 19:21 ` [PATCH 4.4 00/10] 4.4.283-rc1 review Jon Hunter
@ 2021-09-01 19:21 ` Jon Hunter
2021-09-01 20:06 ` Pavel Machek
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Jon Hunter @ 2021-09-01 19:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, stable, linux-tegra
On Wed, 01 Sep 2021 14:26:14 +0200, Greg Kroah-Hartman wrote:
> 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
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 fail
Linux version: 4.4.283-rc1-gd0f43d936dd1
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-09-01 19:21 ` Jon Hunter
@ 2021-09-01 20:06 ` Pavel Machek
2021-09-01 21:26 ` Shuah Khan
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Pavel Machek @ 2021-09-01 20:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, stable
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi!
> 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
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-09-01 20:06 ` Pavel Machek
@ 2021-09-01 21:26 ` Shuah Khan
2021-09-02 16:35 ` Naresh Kamboju
2021-09-02 21:49 ` Guenter Roeck
15 siblings, 0 replies; 17+ messages in thread
From: Shuah Khan @ 2021-09-01 21:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable, Shuah Khan
On 9/1/21 6:26 AM, Greg Kroah-Hartman wrote:
> 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.
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-09-01 21:26 ` Shuah Khan
@ 2021-09-02 16:35 ` Naresh Kamboju
2021-09-02 21:49 ` Guenter Roeck
15 siblings, 0 replies; 17+ messages in thread
From: Naresh Kamboju @ 2021-09-02 16:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, Florian Fainelli, patches, lkft-triage,
Jon Hunter, linux-stable, Pavel Machek, Andrew Morton,
Linus Torvalds, Guenter Roeck
On Wed, 1 Sept 2021 at 17:57, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> 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
>
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## 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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 4.4 00/10] 4.4.283-rc1 review
2021-09-01 12:26 [PATCH 4.4 00/10] 4.4.283-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-09-02 16:35 ` Naresh Kamboju
@ 2021-09-02 21:49 ` Guenter Roeck
15 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-09-02 21:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable
On Wed, Sep 01, 2021 at 02:26:14PM +0200, Greg Kroah-Hartman wrote:
> 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
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread