* [PATCH 4.9 01/14] mm/slub: add missing TID updates on slab deactivation
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 02/14] can: grcan: grcan_probe(): remove extra of_node_get() Greg Kroah-Hartman
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jann Horn, Christoph Lameter,
David Rientjes, Muchun Song, Hyeonggon Yoo, Vlastimil Babka
From: Jann Horn <jannh@google.com>
commit eeaa345e128515135ccb864c04482180c08e3259 upstream.
The fastpath in slab_alloc_node() assumes that c->slab is stable as long as
the TID stays the same. However, two places in __slab_alloc() currently
don't update the TID when deactivating the CPU slab.
If multiple operations race the right way, this could lead to an object
getting lost; or, in an even more unlikely situation, it could even lead to
an object being freed onto the wrong slab's freelist, messing up the
`inuse` counter and eventually causing a page to be freed to the page
allocator while it still contains slab objects.
(I haven't actually tested these cases though, this is just based on
looking at the code. Writing testcases for this stuff seems like it'd be
a pain...)
The race leading to state inconsistency is (all operations on the same CPU
and kmem_cache):
- task A: begin do_slab_free():
- read TID
- read pcpu freelist (==NULL)
- check `slab == c->slab` (true)
- [PREEMPT A->B]
- task B: begin slab_alloc_node():
- fastpath fails (`c->freelist` is NULL)
- enter __slab_alloc()
- slub_get_cpu_ptr() (disables preemption)
- enter ___slab_alloc()
- take local_lock_irqsave()
- read c->freelist as NULL
- get_freelist() returns NULL
- write `c->slab = NULL`
- drop local_unlock_irqrestore()
- goto new_slab
- slub_percpu_partial() is NULL
- get_partial() returns NULL
- slub_put_cpu_ptr() (enables preemption)
- [PREEMPT B->A]
- task A: finish do_slab_free():
- this_cpu_cmpxchg_double() succeeds()
- [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL]
>From there, the object on c->freelist will get lost if task B is allowed to
continue from here: It will proceed to the retry_load_slab label,
set c->slab, then jump to load_freelist, which clobbers c->freelist.
But if we instead continue as follows, we get worse corruption:
- task A: run __slab_free() on object from other struct slab:
- CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)
- task A: run slab_alloc_node() with NUMA node constraint:
- fastpath fails (c->slab is NULL)
- call __slab_alloc()
- slub_get_cpu_ptr() (disables preemption)
- enter ___slab_alloc()
- c->slab is NULL: goto new_slab
- slub_percpu_partial() is non-NULL
- set c->slab to slub_percpu_partial(c)
- [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects
from slab-2]
- goto redo
- node_match() fails
- goto deactivate_slab
- existing c->freelist is passed into deactivate_slab()
- inuse count of slab-1 is decremented to account for object from
slab-2
At this point, the inuse count of slab-1 is 1 lower than it should be.
This means that if we free all allocated objects in slab-1 except for one,
SLUB will think that slab-1 is completely unused, and may free its page,
leading to use-after-free.
Fixes: c17dda40a6a4e ("slub: Separate out kmem_cache_cpu processing from deactivate_slab")
Fixes: 03e404af26dc2 ("slub: fast release on full slab")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Link: https://lore.kernel.org/r/20220608182205.2945720-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/slub.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2556,6 +2556,7 @@ redo:
deactivate_slab(s, page, c->freelist);
c->page = NULL;
c->freelist = NULL;
+ c->tid = next_tid(c->tid);
goto new_slab;
}
}
@@ -2569,6 +2570,7 @@ redo:
deactivate_slab(s, page, c->freelist);
c->page = NULL;
c->freelist = NULL;
+ c->tid = next_tid(c->tid);
goto new_slab;
}
@@ -2581,6 +2583,7 @@ redo:
if (!freelist) {
c->page = NULL;
+ c->tid = next_tid(c->tid);
stat(s, DEACTIVATE_BYPASS);
goto new_slab;
}
@@ -2605,6 +2608,7 @@ new_slab:
c->partial = page->next;
stat(s, CPU_PARTIAL_ALLOC);
c->freelist = NULL;
+ c->tid = next_tid(c->tid);
goto redo;
}
@@ -2627,6 +2631,7 @@ new_slab:
deactivate_slab(s, page, get_freepointer(s, freelist));
c->page = NULL;
c->freelist = NULL;
+ c->tid = next_tid(c->tid);
return freelist;
}
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 02/14] can: grcan: grcan_probe(): remove extra of_node_get()
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 01/14] mm/slub: add missing TID updates on slab deactivation Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 03/14] can: gs_usb: gs_usb_open/close(): fix memory leak Greg Kroah-Hartman
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andreas Larsson, Liang He,
Marc Kleine-Budde
From: Liang He <windhl@126.com>
commit 562fed945ea482833667f85496eeda766d511386 upstream.
In grcan_probe(), of_find_node_by_path() has already increased the
refcount. There is no need to call of_node_get() again, so remove it.
Link: https://lore.kernel.org/all/20220619070257.4067022-1-windhl@126.com
Fixes: 1e93ed26acf0 ("can: grcan: grcan_probe(): fix broken system id check for errata workaround needs")
Cc: stable@vger.kernel.org # v5.18
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Liang He <windhl@126.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/grcan.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/net/can/grcan.c
+++ b/drivers/net/can/grcan.c
@@ -1669,7 +1669,6 @@ static int grcan_probe(struct platform_d
*/
sysid_parent = of_find_node_by_path("/ambapp0");
if (sysid_parent) {
- of_node_get(sysid_parent);
err = of_property_read_u32(sysid_parent, "systemid", &sysid);
if (!err && ((sysid & GRLIB_VERSION_MASK) >=
GRCAN_TXBUG_SAFE_GRLIB_VERSION))
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 03/14] can: gs_usb: gs_usb_open/close(): fix memory leak
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 01/14] mm/slub: add missing TID updates on slab deactivation Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 02/14] can: grcan: grcan_probe(): remove extra of_node_get() Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 04/14] usbnet: fix memory leak in error case Greg Kroah-Hartman
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rhett Aultman, Marc Kleine-Budde
From: Rhett Aultman <rhett.aultman@samsara.com>
commit 2bda24ef95c0311ab93bda00db40486acf30bd0a upstream.
The gs_usb driver appears to suffer from a malady common to many USB
CAN adapter drivers in that it performs usb_alloc_coherent() to
allocate a number of USB request blocks (URBs) for RX, and then later
relies on usb_kill_anchored_urbs() to free them, but this doesn't
actually free them. As a result, this may be leaking DMA memory that's
been used by the driver.
This commit is an adaptation of the techniques found in the esd_usb2
driver where a similar design pattern led to a memory leak. It
explicitly frees the RX URBs and their DMA memory via a call to
usb_free_coherent(). Since the RX URBs were allocated in the
gs_can_open(), we remove them in gs_can_close() rather than in the
disconnect function as was done in esd_usb2.
For more information, see the 928150fad41b ("can: esd_usb2: fix memory
leak").
Link: https://lore.kernel.org/all/alpine.DEB.2.22.394.2206031547001.1630869@thelappy
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Cc: stable@vger.kernel.org
Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/usb/gs_usb.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -192,6 +192,8 @@ struct gs_can {
struct usb_anchor tx_submitted;
atomic_t active_tx_urbs;
+ void *rxbuf[GS_MAX_RX_URBS];
+ dma_addr_t rxbuf_dma[GS_MAX_RX_URBS];
};
/* usb interface struct */
@@ -601,6 +603,7 @@ static int gs_can_open(struct net_device
for (i = 0; i < GS_MAX_RX_URBS; i++) {
struct urb *urb;
u8 *buf;
+ dma_addr_t buf_dma;
/* alloc rx urb */
urb = usb_alloc_urb(0, GFP_KERNEL);
@@ -611,7 +614,7 @@ static int gs_can_open(struct net_device
buf = usb_alloc_coherent(dev->udev,
sizeof(struct gs_host_frame),
GFP_KERNEL,
- &urb->transfer_dma);
+ &buf_dma);
if (!buf) {
netdev_err(netdev,
"No memory left for USB buffer\n");
@@ -619,6 +622,8 @@ static int gs_can_open(struct net_device
return -ENOMEM;
}
+ urb->transfer_dma = buf_dma;
+
/* fill, anchor, and submit rx urb */
usb_fill_bulk_urb(urb,
dev->udev,
@@ -642,10 +647,17 @@ static int gs_can_open(struct net_device
rc);
usb_unanchor_urb(urb);
+ usb_free_coherent(dev->udev,
+ sizeof(struct gs_host_frame),
+ buf,
+ buf_dma);
usb_free_urb(urb);
break;
}
+ dev->rxbuf[i] = buf;
+ dev->rxbuf_dma[i] = buf_dma;
+
/* Drop reference,
* USB core will take care of freeing it
*/
@@ -710,13 +722,20 @@ static int gs_can_close(struct net_devic
int rc;
struct gs_can *dev = netdev_priv(netdev);
struct gs_usb *parent = dev->parent;
+ unsigned int i;
netif_stop_queue(netdev);
/* Stop polling */
parent->active_channels--;
- if (!parent->active_channels)
+ if (!parent->active_channels) {
usb_kill_anchored_urbs(&parent->rx_submitted);
+ for (i = 0; i < GS_MAX_RX_URBS; i++)
+ usb_free_coherent(dev->udev,
+ sizeof(struct gs_host_frame),
+ dev->rxbuf[i],
+ dev->rxbuf_dma[i]);
+ }
/* Stop sending URBs */
usb_kill_anchored_urbs(&dev->tx_submitted);
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 04/14] usbnet: fix memory leak in error case
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 03/14] can: gs_usb: gs_usb_open/close(): fix memory leak Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 05/14] net: rose: fix UAF bug caused by rose_t0timer_expiry Greg Kroah-Hartman
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Oliver Neukum, Jakub Kicinski
From: Oliver Neukum <oneukum@suse.com>
commit b55a21b764c1e182014630fa5486d717484ac58f upstream.
usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.
v2: add Fixes tag
v3: fix uninitialized buf pointer
Fixes: 877bd862f32b8 ("usbnet: introduce usbnet 3 command helpers")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/usbnet.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2085,7 +2085,7 @@ static void usbnet_async_cmd_cb(struct u
int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data, u16 size)
{
- struct usb_ctrlrequest *req = NULL;
+ struct usb_ctrlrequest *req;
struct urb *urb;
int err = -ENOMEM;
void *buf = NULL;
@@ -2103,7 +2103,7 @@ int usbnet_write_cmd_async(struct usbnet
if (!buf) {
netdev_err(dev->net, "Error allocating buffer"
" in %s!\n", __func__);
- goto fail_free;
+ goto fail_free_urb;
}
}
@@ -2127,14 +2127,21 @@ int usbnet_write_cmd_async(struct usbnet
if (err < 0) {
netdev_err(dev->net, "Error submitting the control"
" message: status=%d\n", err);
- goto fail_free;
+ goto fail_free_all;
}
return 0;
+fail_free_all:
+ kfree(req);
fail_free_buf:
kfree(buf);
-fail_free:
- kfree(req);
+ /*
+ * avoid a double free
+ * needed because the flag can be set only
+ * after filling the URB
+ */
+ urb->transfer_flags = 0;
+fail_free_urb:
usb_free_urb(urb);
fail:
return err;
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 05/14] net: rose: fix UAF bug caused by rose_t0timer_expiry
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 04/14] usbnet: fix memory leak in error case Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 06/14] iommu/vt-d: Fix PCI bus rescan device hot add Greg Kroah-Hartman
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Duoming Zhou, Jakub Kicinski
From: Duoming Zhou <duoming@zju.edu.cn>
commit 148ca04518070910739dfc4eeda765057856403d upstream.
There are UAF bugs caused by rose_t0timer_expiry(). The
root cause is that del_timer() could not stop the timer
handler that is running and there is no synchronization.
One of the race conditions is shown below:
(thread 1) | (thread 2)
| rose_device_event
| rose_rt_device_down
| rose_remove_neigh
rose_t0timer_expiry | rose_stop_t0timer(rose_neigh)
... | del_timer(&neigh->t0timer)
| kfree(rose_neigh) //[1]FREE
neigh->dce_mode //[2]USE |
The rose_neigh is deallocated in position [1] and use in
position [2].
The crash trace triggered by POC is like below:
BUG: KASAN: use-after-free in expire_timers+0x144/0x320
Write of size 8 at addr ffff888009b19658 by task swapper/0/0
...
Call Trace:
<IRQ>
dump_stack_lvl+0xbf/0xee
print_address_description+0x7b/0x440
print_report+0x101/0x230
? expire_timers+0x144/0x320
kasan_report+0xed/0x120
? expire_timers+0x144/0x320
expire_timers+0x144/0x320
__run_timers+0x3ff/0x4d0
run_timer_softirq+0x41/0x80
__do_softirq+0x233/0x544
...
This patch changes rose_stop_ftimer() and rose_stop_t0timer()
in rose_remove_neigh() to del_timer_sync() in order that the
timer handler could be finished before the resources such as
rose_neigh and so on are deallocated. As a result, the UAF
bugs could be mitigated.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Link: https://lore.kernel.org/r/20220705125610.77971-1-duoming@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -230,8 +230,8 @@ static void rose_remove_neigh(struct ros
{
struct rose_neigh *s;
- rose_stop_ftimer(rose_neigh);
- rose_stop_t0timer(rose_neigh);
+ del_timer_sync(&rose_neigh->ftimer);
+ del_timer_sync(&rose_neigh->t0timer);
skb_queue_purge(&rose_neigh->queue);
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 06/14] iommu/vt-d: Fix PCI bus rescan device hot add
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 05/14] net: rose: fix UAF bug caused by rose_t0timer_expiry Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 07/14] video: of_display_timing.h: include errno.h Greg Kroah-Hartman
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zhang, Bernice, Jacob Pan, Yian Chen,
Joerg Roedel, Zhang
From: Yian Chen <yian.chen@intel.com>
commit 316f92a705a4c2bf4712135180d56f3cca09243a upstream.
Notifier calling chain uses priority to determine the execution
order of the notifiers or listeners registered to the chain.
PCI bus device hot add utilizes the notification mechanism.
The current code sets low priority (INT_MIN) to Intel
dmar_pci_bus_notifier and postpones DMAR decoding after adding
new device into IOMMU. The result is that struct device pointer
cannot be found in DRHD search for the new device's DMAR/IOMMU.
Subsequently, the device is put under the "catch-all" IOMMU
instead of the correct one. This could cause system hang when
device TLB invalidation is sent to the wrong IOMMU. Invalidation
timeout error and hard lockup have been observed and data
inconsistency/crush may occur as well.
This patch fixes the issue by setting a positive priority(1) for
dmar_pci_bus_notifier while the priority of IOMMU bus notifier
uses the default value(0), therefore DMAR decoding will be in
advance of DRHD search for a new device to find the correct IOMMU.
Following is a 2-step example that triggers the bug by simulating
PCI device hot add behavior in Intel Sapphire Rapids server.
echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove
echo 1 > /sys/bus/pci/rescan
Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Cc: stable@vger.kernel.org # v3.15+
Reported-by: Zhang, Bernice <bernice.zhang@intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Yian Chen <yian.chen@intel.com>
Link: https://lore.kernel.org/r/20220521002115.1624069-1-yian.chen@intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -373,7 +373,7 @@ static int dmar_pci_bus_notifier(struct
static struct notifier_block dmar_pci_bus_nb = {
.notifier_call = dmar_pci_bus_notifier,
- .priority = INT_MIN,
+ .priority = 1,
};
static struct dmar_drhd_unit *
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 07/14] video: of_display_timing.h: include errno.h
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 06/14] iommu/vt-d: Fix PCI bus rescan device hot add Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 08/14] xfs: remove incorrect ASSERT in xfs_rename Greg Kroah-Hartman
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Boyd, Hsin-Yi Wang,
Helge Deller
From: Hsin-Yi Wang <hsinyi@chromium.org>
commit 3663a2fb325b8782524f3edb0ae32d6faa615109 upstream.
If CONFIG_OF is not enabled, default of_get_display_timing() returns an
errno, so include the header.
Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF")
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/video/of_display_timing.h | 2 ++
1 file changed, 2 insertions(+)
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -9,6 +9,8 @@
#ifndef __LINUX_OF_DISPLAY_TIMING_H
#define __LINUX_OF_DISPLAY_TIMING_H
+#include <linux/errno.h>
+
struct device_node;
struct display_timing;
struct display_timings;
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 08/14] xfs: remove incorrect ASSERT in xfs_rename
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 07/14] video: of_display_timing.h: include errno.h Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 09/14] pinctrl: sunxi: a83t: Fix NAND function name for some pins Greg Kroah-Hartman
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paolo Bonzini, Eric Sandeen,
Darrick J. Wong, Kuniyuki Iwashima
From: Eric Sandeen <sandeen@redhat.com>
commit e445976537ad139162980bee015b7364e5b64fff upstream.
This ASSERT in xfs_rename is a) incorrect, because
(RENAME_WHITEOUT|RENAME_NOREPLACE) is a valid combination, and
b) unnecessary, because actual invalid flag combinations are already
handled at the vfs level in do_renameat2() before we get called.
So, remove it.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Fixes: 7dcf5c3e4527 ("xfs: add RENAME_WHITEOUT support")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_inode.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2973,7 +2973,6 @@ xfs_rename(
* appropriately.
*/
if (flags & RENAME_WHITEOUT) {
- ASSERT(!(flags & (RENAME_NOREPLACE | RENAME_EXCHANGE)));
error = xfs_rename_alloc_whiteout(target_dp, &wip);
if (error)
return error;
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 09/14] pinctrl: sunxi: a83t: Fix NAND function name for some pins
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 08/14] xfs: remove incorrect ASSERT in xfs_rename Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 10/14] i2c: cadence: Unregister the clk notifier in error path Greg Kroah-Hartman
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Samuel Holland, Jernej Skrabec,
Linus Walleij, Sasha Levin
From: Samuel Holland <samuel@sholland.org>
[ Upstream commit aaefa29270d9551b604165a08406543efa9d16f5 ]
The other NAND pins on Port C use the "nand0" function name.
"nand0" also matches all of the other Allwinner SoCs.
Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20220526024956.49500-1-samuel@sholland.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c
index 383977ea3a3c..0b5aba4bf338 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c
@@ -158,26 +158,26 @@ static const struct sunxi_desc_pin sun8i_a83t_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand"), /* DQ6 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand"), /* DQ7 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand"), /* DQS */
+ SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
SUNXI_FUNCTION(0x3, "mmc2")), /* RST */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 17),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand")), /* CE2 */
+ SUNXI_FUNCTION(0x2, "nand0")), /* CE2 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 18),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand")), /* CE3 */
+ SUNXI_FUNCTION(0x2, "nand0")), /* CE3 */
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
--
2.35.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 4.9 10/14] i2c: cadence: Unregister the clk notifier in error path
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 09/14] pinctrl: sunxi: a83t: Fix NAND function name for some pins Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 11/14] ida: dont use BUG_ON() for debugging Greg Kroah-Hartman
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Satish Nagireddy, Lars-Peter Clausen,
Michal Simek, Wolfram Sang, Sasha Levin
From: Satish Nagireddy <satish.nagireddy@getcruise.com>
[ Upstream commit 3501f0c663063513ad604fb1b3f06af637d3396d ]
This patch ensures that the clock notifier is unregistered
when driver probe is returning error.
Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
Signed-off-by: Satish Nagireddy <satish.nagireddy@getcruise.com>
Tested-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-cadence.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -992,6 +992,7 @@ static int cdns_i2c_probe(struct platfor
return 0;
err_clk_dis:
+ clk_notifier_unregister(id->clk, &id->clk_rate_change_nb);
clk_disable_unprepare(id->clk);
pm_runtime_set_suspended(&pdev->dev);
pm_runtime_disable(&pdev->dev);
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 11/14] ida: dont use BUG_ON() for debugging
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 10/14] i2c: cadence: Unregister the clk notifier in error path Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 12/14] dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctly Greg Kroah-Hartman
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Itay Iellin, Matthew Wilcox,
Linus Torvalds
From: Linus Torvalds <torvalds@linux-foundation.org>
commit fc82bbf4dede758007763867d0282353c06d1121 upstream.
This is another old BUG_ON() that just shouldn't exist (see also commit
a382f8fee42c: "signal handling: don't use BUG_ON() for debugging").
In fact, as Matthew Wilcox points out, this condition shouldn't really
even result in a warning, since a negative id allocation result is just
a normal allocation failure:
"I wonder if we should even warn here -- sure, the caller is trying to
free something that wasn't allocated, but we don't warn for
kfree(NULL)"
and goes on to point out how that current error check is only causing
people to unnecessarily do their own index range checking before freeing
it.
This was noted by Itay Iellin, because the bluetooth HCI socket cookie
code does *not* do that range checking, and ends up just freeing the
error case too, triggering the BUG_ON().
The HCI code requires CAP_NET_RAW, and seems to just result in an ugly
splat, but there really is no reason to BUG_ON() here, and we have
generally striven for allocation models where it's always ok to just do
free(alloc());
even if the allocation were to fail for some random reason (usually
obviously that "random" reason being some resource limit).
Fixes: 88eca0207cf1 ("ida: simplified functions for id allocation")
Reported-by: Itay Iellin <ieitayie@gmail.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/idr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -1124,7 +1124,9 @@ void ida_simple_remove(struct ida *ida,
{
unsigned long flags;
- BUG_ON((int)id < 0);
+ if ((int)id < 0)
+ return;
+
spin_lock_irqsave(&simple_ida_lock, flags);
ida_remove(ida, id);
spin_unlock_irqrestore(&simple_ida_lock, flags);
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 12/14] dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctly
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 11/14] ida: dont use BUG_ON() for debugging Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 13/14] dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate Greg Kroah-Hartman
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Walle, Vinod Koul
From: Michael Walle <michael@walle.cc>
commit 3770d92bd5237d686e49da7b2fb86f53ee6ed259 upstream.
It seems that it is valid to have less than the requested number of
descriptors. But what is not valid and leads to subsequent errors is to
have zero descriptors. In that case, abort the probing.
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20220526135111.1470926-1-michael@walle.cc
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma/at_xdmac.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1806,6 +1806,11 @@ static int at_xdmac_alloc_chan_resources
for (i = 0; i < init_nr_desc_per_channel; i++) {
desc = at_xdmac_alloc_desc(chan, GFP_ATOMIC);
if (!desc) {
+ if (i == 0) {
+ dev_warn(chan2dev(chan),
+ "can't allocate any descriptors\n");
+ return -EIO;
+ }
dev_warn(chan2dev(chan),
"only %d descriptors have been allocated\n", i);
break;
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 13/14] dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 12/14] dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctly Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 9:06 ` [PATCH 4.9 14/14] dmaengine: ti: Add missing put_device " Greg Kroah-Hartman
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Miaoqian Lin, Vinod Koul
From: Miaoqian Lin <linmq006@gmail.com>
commit c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a upstream.
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not needed anymore.
Add missing of_node_put() in to fix this.
Fixes: ec9bfa1e1a79 ("dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220605042723.17668-2-linmq006@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -274,6 +274,7 @@ static void *ti_dra7_xbar_route_allocate
mutex_unlock(&xbar->mutex);
dev_err(&pdev->dev, "Run out of free DMA requests\n");
kfree(map);
+ of_node_put(dma_spec->np);
return ERR_PTR(-ENOMEM);
}
set_bit(map->xbar_out, xbar->dma_inuse);
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 4.9 14/14] dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 13/14] dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate Greg Kroah-Hartman
@ 2022-07-11 9:06 ` Greg Kroah-Hartman
2022-07-11 11:08 ` [PATCH 4.9 00/14] 4.9.323-rc1 review Pavel Machek
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Miaoqian Lin, Peter Ujfalusi,
Vinod Koul
From: Miaoqian Lin <linmq006@gmail.com>
commit 615a4bfc426e11dba05c2cf343f9ac752fb381d2 upstream.
of_find_device_by_node() takes reference, we should use put_device()
to release it when not need anymore.
Fixes: a074ae38f859 ("dmaengine: Add driver for TI DMA crossbar on DRA7x")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20220605042723.17668-1-linmq006@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -251,6 +251,7 @@ static void *ti_dra7_xbar_route_allocate
if (dma_spec->args[0] >= xbar->xbar_requests) {
dev_err(&pdev->dev, "Invalid XBAR request number: %d\n",
dma_spec->args[0]);
+ put_device(&pdev->dev);
return ERR_PTR(-EINVAL);
}
@@ -258,12 +259,14 @@ static void *ti_dra7_xbar_route_allocate
dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
if (!dma_spec->np) {
dev_err(&pdev->dev, "Can't get DMA master\n");
+ put_device(&pdev->dev);
return ERR_PTR(-EINVAL);
}
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (!map) {
of_node_put(dma_spec->np);
+ put_device(&pdev->dev);
return ERR_PTR(-ENOMEM);
}
@@ -275,6 +278,7 @@ static void *ti_dra7_xbar_route_allocate
dev_err(&pdev->dev, "Run out of free DMA requests\n");
kfree(map);
of_node_put(dma_spec->np);
+ put_device(&pdev->dev);
return ERR_PTR(-ENOMEM);
}
set_bit(map->xbar_out, xbar->dma_inuse);
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2022-07-11 9:06 ` [PATCH 4.9 14/14] dmaengine: ti: Add missing put_device " Greg Kroah-Hartman
@ 2022-07-11 11:08 ` Pavel Machek
2022-07-11 17:55 ` Florian Fainelli
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2022-07-11 11:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Hi!
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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.9.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] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2022-07-11 11:08 ` [PATCH 4.9 00/14] 4.9.323-rc1 review Pavel Machek
@ 2022-07-11 17:55 ` Florian Fainelli
2022-07-12 1:11 ` Guenter Roeck
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Florian Fainelli @ 2022-07-11 17:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, sudipm.mukherjee, slade
On 7/11/22 02:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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 Wed, 13 Jul 2022 09:05:28 +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.9.323-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2022-07-11 17:55 ` Florian Fainelli
@ 2022-07-12 1:11 ` Guenter Roeck
2022-07-12 2:46 ` Shuah Khan
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Guenter Roeck @ 2022-07-12 1:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, slade
On Mon, Jul 11, 2022 at 11:06:19AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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 Wed, 13 Jul 2022 09:05:28 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 164 pass: 164 fail: 0
Qemu test results:
total: 397 pass: 397 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2022-07-12 1:11 ` Guenter Roeck
@ 2022-07-12 2:46 ` Shuah Khan
2022-07-12 8:59 ` Naresh Kamboju
2022-07-12 9:18 ` Jon Hunter
19 siblings, 0 replies; 21+ messages in thread
From: Shuah Khan @ 2022-07-12 2:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, sudipm.mukherjee, slade, Shuah Khan
On 7/11/22 3:06 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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 Wed, 13 Jul 2022 09:05:28 +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.9.323-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2022-07-12 2:46 ` Shuah Khan
@ 2022-07-12 8:59 ` Naresh Kamboju
2022-07-12 9:18 ` Jon Hunter
19 siblings, 0 replies; 21+ messages in thread
From: Naresh Kamboju @ 2022-07-12 8:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade
On Mon, 11 Jul 2022 at 14:37, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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 Wed, 13 Jul 2022 09:05:28 +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.9.323-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.9.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.9.323-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.9.y
* git commit: 7df08530a33bb6dc5074e43d56c71476ca2b4455
* git describe: v4.9.322-15-g7df08530a33b
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.322-15-g7df08530a33b
## Test Regressions (compared to v4.9.322)
No test regressions found.
## Metric Regressions (compared to v4.9.322)
No metric regressions found.
## Test Fixes (compared to v4.9.322)
No test fixes found.
## Metric Fixes (compared to v4.9.322)
No metric fixes found.
## Test result summary
total: 88746, pass: 78270, fail: 325, skip: 9033, xfail: 1118
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 254 total, 249 passed, 5 failed
* arm64: 50 total, 43 passed, 7 failed
* i386: 26 total, 23 passed, 3 failed
* mips: 33 total, 33 passed, 0 failed
* parisc: 12 total, 0 passed, 12 failed
* powerpc: 36 total, 16 passed, 20 failed
* s390: 12 total, 9 passed, 3 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 45 total, 44 passed, 1 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 4.9 00/14] 4.9.323-rc1 review
2022-07-11 9:06 [PATCH 4.9 00/14] 4.9.323-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2022-07-12 8:59 ` Naresh Kamboju
@ 2022-07-12 9:18 ` Jon Hunter
19 siblings, 0 replies; 21+ messages in thread
From: Jon Hunter @ 2022-07-12 9:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade, linux-tegra
On Mon, 11 Jul 2022 11:06:19 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.323 release.
> There are 14 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 Wed, 13 Jul 2022 09:05:28 +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.9.323-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 fail
Linux version: 4.9.323-rc1-g7df08530a33b
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 21+ messages in thread