5.15.11-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 171/177 selftests/damon: test debugfs file reads/writes with huge count
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit b4a002889d24979295ed3c2bf1d5fcfb3901026a upstream.
DAMON debugfs interface users were able to trigger warning by writing some files with arbitrarily large 'count' parameter. The issue is fixed with commit db7a347b26fe ("mm/damon/dbgfs: use '__GFP_NOWARN' for user-specified size buffer allocation"). This commit adds a test case for the issue in DAMON selftests to avoid future regressions.
--- tools/testing/selftests/damon/.gitignore | 2 tools/testing/selftests/damon/Makefile | 2 tools/testing/selftests/damon/debugfs_attrs.sh | 18 ++++++++ tools/testing/selftests/damon/huge_count_read_write.c | 39 ++++++++++++++++++ 4 files changed, 61 insertions(+) create mode 100644 tools/testing/selftests/damon/.gitignore create mode 100644 tools/testing/selftests/damon/huge_count_read_write.c
tools/testing/selftests/damon/.gitignore new file +2 -0
@@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +huge_count_read_write
tools/testing/selftests/damon/Makefile +2 -0
@@ -1,6 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for damon selftests +TEST_GEN_FILES += huge_count_read_write + TEST_FILES = _chk_dependency.sh TEST_PROGS = debugfs_attrs.sh
tools/testing/selftests/damon/debugfs_attrs.sh +18 -0
@@ -72,4 +72,22 @@ test_write_succ "$file" "" "$orig_conten test_content "$file" "$orig_content" "" "empty input written" echo "$orig_content" > "$file" +# Test huge count read write +# ========================== + +dmesg -C + +for file in "$DBGFS/"* +do + ./huge_count_read_write "$file" +done + +if dmesg | grep -q WARNING +then + dmesg + exit 1 +else + exit 0 +fi + echo "PASS"
tools/testing/selftests/damon/huge_count_read_write.c new file +39 -0
@@ -0,0 +1,39 @@ +// SPDX-License-Identifier: GPL-2.0 +/* +* Author: SeongJae Park <[email protected]> +*/ + +#include <fcntl.h> +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> + +void write_read_with_huge_count (char *file) +{ +int filedesc =open (file,O_RDWR ); +char buf[25 ]; +int ret; + +printf ("%s %s\n" , __func__, file); +if (filedesc <0 ) { +fprintf (stderr,"failed opening %s\n" , file); +exit (1 ); + } + +write (filedesc,"" ,0xfffffffful ); +perror ("after write: " ); + ret =read (filedesc, buf,0xfffffffful ); +perror ("after read: " ); +close (filedesc); +} + +int main (int argc,char *argv[]) +{ +if (argc !=2 ) { +fprintf (stderr,"Usage: %s <file>\n" , argv[0 ]); +exit (1 ); + } +write_read_with_huge_count (argv[1 ]); + +return 0 ; +}
Greg Kroah-Hartman
maintainerPATCH 172/177 Revert "xsk: Do not sleep in poll() when need_wakeup set"
In reply to Greg Kroah-HartmanFrom: Magnus Karlsson <[email protected]>
commit 0706a78f31c4217ca144f630063ec9561a21548d upstream.
This reverts commit bd0687c18e635b63233dc87f38058cd728802ab4.
This patch causes a Tx only workload to go to sleep even when it does not have to, leading to misserable performance in skb mode. It fixed one rare problem but created a much worse one, so this need to be reverted while I try to craft a proper solution to the original problem.
--- net/xdp/xsk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/xdp/xsk.c +2 -2
@@ -692,6 +692,8 @@ static __poll_t xsk_poll(struct file *fistruct xdp_sock *xs =xdp_sk (sk);struct xsk_buff_pool *pool; +sock_poll_wait (file, sock, wait); +if (unlikely (!xsk_is_bound (xs)))return mask;
@@ -703,8 +705,6 @@ static __poll_t xsk_poll(struct file *fielse /* Poll needs to drive Tx also in copy mode */ __xsk_sendmsg (sk); - }else { -sock_poll_wait (file, sock, wait); }if (xs->rx && !xskq_prod_is_empty (xs->rx))
Greg Kroah-Hartman
maintainerPATCH 173/177 xen/blkfront: harden blkfront against event channel storms
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit 0fd08a34e8e3b67ec9bd8287ac0facf8374b844a upstream.
The Xen blkfront driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using lateeoi event channels.
This is part of XSA-391
--- drivers/block/xen-blkfront.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/block/xen-blkfront.c +12 -3
@@ -1511,9 +1511,12 @@ static irqreturn_t blkif_interrupt(int iunsigned long flags;struct blkfront_ring_info *rinfo = (struct blkfront_ring_info *)dev_id;struct blkfront_info *info = rinfo->dev_info; +unsigned int eoiflag =XEN_EOI_FLAG_SPURIOUS ; -if (unlikely (info->connected !=BLKIF_STATE_CONNECTED )) +if (unlikely (info->connected !=BLKIF_STATE_CONNECTED )) { +xen_irq_lateeoi (irq,XEN_EOI_FLAG_SPURIOUS );return IRQ_HANDLED ; + }spin_lock_irqsave (&rinfo->ring_lock, flags); again:
@@ -1529,6 +1532,8 @@ static irqreturn_t blkif_interrupt(int iunsigned long id;unsigned int op; + eoiflag =0 ; +RING_COPY_RESPONSE (&rinfo->ring, i, &bret); id = bret.id;
@@ -1645,6 +1650,8 @@ static irqreturn_t blkif_interrupt(int ispin_unlock_irqrestore (&rinfo->ring_lock, flags); +xen_irq_lateeoi (irq, eoiflag); +return IRQ_HANDLED ; err:
@@ -1652,6 +1659,8 @@ static irqreturn_t blkif_interrupt(int ispin_unlock_irqrestore (&rinfo->ring_lock, flags); +/* No EOI in order to avoid further interrupts. */ +pr_alert ("%s disabled for further use\n" , info->gd->disk_name);return IRQ_HANDLED ; }
@@ -1691,8 +1700,8 @@ static int setup_blkring(struct xenbus_dif (err) goto fail; - err =bind_evtchn_to_irqhandler (rinfo->evtchn, blkif_interrupt,0 , -"blkif" , rinfo); + err =bind_evtchn_to_irqhandler_lateeoi (rinfo->evtchn, blkif_interrupt, +0 ,"blkif" , rinfo);if (err <=0 ) {xenbus_dev_fatal (dev, err,"bind_evtchn_to_irqhandler failed" );
Greg Kroah-Hartman
maintainerPATCH 174/177 xen/netfront: harden netfront against event channel storms
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit b27d47950e481f292c0a5ad57357edb9d95d03ba upstream.
The Xen netfront driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using lateeoi event channels.
For being able to detect the case of no rx responses being added while the carrier is down a new lock is needed in order to update and test rsp_cons and the number of seen unconsumed responses atomically.
This is part of XSA-391
--- drivers/net/xen-netfront.c | 125 +++++++++++++++++++++++++++++++++------------ 1 file changed, 94 insertions(+), 31 deletions(-)
drivers/net/xen-netfront.c +94 -31
@@ -148,6 +148,9 @@ struct netfront_queue {grant_ref_t gref_rx_head;grant_ref_t grant_rx_ref[NET_RX_RING_SIZE ]; +unsigned int rx_rsp_unconsumed; +spinlock_t rx_cons_lock; +struct page_pool *page_pool;struct xdp_rxq_info xdp_rxq; };
@@ -376,12 +379,13 @@ static int xennet_open(struct net_devicereturn 0 ; } -static void xennet_tx_buf_gc (struct netfront_queue *queue) +static bool xennet_tx_buf_gc (struct netfront_queue *queue) {RING_IDX cons, prod;unsigned short id;struct sk_buff *skb;bool more_to_do; +bool work_done = false;const struct device *dev = &queue->info->netdev->dev;BUG_ON (!netif_carrier_ok (queue->info->netdev));
@@ -398,6 +402,8 @@ static void xennet_tx_buf_gc(struct netffor (cons = queue->tx.rsp_cons; cons != prod; cons++) {struct xen_netif_tx_response txrsp; + work_done = true; +RING_COPY_RESPONSE (&queue->tx, cons, &txrsp);if (txrsp.status ==XEN_NETIF_RSP_NULL )continue ;
@@ -441,11 +447,13 @@ static void xennet_tx_buf_gc(struct netfxennet_maybe_wake_tx (queue); -return ; +return work_done; err: queue->info->broken = true;dev_alert (dev,"Disabled for further use\n" ); + +return work_done; }struct xennet_gnttab_make_txreq {
@@ -834,6 +842,16 @@ static int xennet_close(struct net_devicreturn 0 ; } +static void xennet_set_rx_rsp_cons (struct netfront_queue *queue,RING_IDX val) +{ +unsigned long flags; + +spin_lock_irqsave (&queue->rx_cons_lock, flags); + queue->rx.rsp_cons = val; + queue->rx_rsp_unconsumed =RING_HAS_UNCONSUMED_RESPONSES (&queue->rx); +spin_unlock_irqrestore (&queue->rx_cons_lock, flags); +} +static void xennet_move_rx_slot (struct netfront_queue *queue,struct sk_buff *skb,grant_ref_t ref) {
@@ -885,7 +903,7 @@ static int xennet_get_extras(struct netfxennet_move_rx_slot (queue, skb, ref); }while (extra.flags &XEN_NETIF_EXTRA_FLAG_MORE ); - queue->rx.rsp_cons = cons; +xennet_set_rx_rsp_cons (queue, cons);return err; }
@@ -1039,7 +1057,7 @@ next: }if (unlikely (err)) - queue->rx.rsp_cons = cons + slots; +xennet_set_rx_rsp_cons (queue, cons + slots);return err; }
@@ -1093,7 +1111,8 @@ static int xennet_fill_frags(struct netf__pskb_pull_tail (skb, pull_to -skb_headlen (skb)); }if (unlikely (skb_shinfo (skb)->nr_frags >=MAX_SKB_FRAGS )) { - queue->rx.rsp_cons = ++cons +skb_queue_len (list); +xennet_set_rx_rsp_cons (queue, + ++cons +skb_queue_len (list));kfree_skb (nskb);return -ENOENT ; }
@@ -1106,7 +1125,7 @@ static int xennet_fill_frags(struct netfkfree_skb (nskb); } - queue->rx.rsp_cons = cons; +xennet_set_rx_rsp_cons (queue, cons);return 0 ; }
@@ -1229,7 +1248,9 @@ err:if (unlikely (xennet_set_skb_gso (skb, gso))) {__skb_queue_head (&tmpq, skb); - queue->rx.rsp_cons +=skb_queue_len (&tmpq); +xennet_set_rx_rsp_cons (queue, + queue->rx.rsp_cons + +skb_queue_len (&tmpq)); goto err; } }
@@ -1253,7 +1274,8 @@ err:__skb_queue_tail (&rxq, skb); - i = ++queue->rx.rsp_cons; + i = queue->rx.rsp_cons +1 ; +xennet_set_rx_rsp_cons (queue, i); work_done++; }if (need_xdp_flush)
@@ -1417,40 +1439,79 @@ static int xennet_set_features(struct nereturn 0 ; } -static irqreturn_t xennet_tx_interrupt (int irq,void *dev_id) +static bool xennet_handle_tx (struct netfront_queue *queue,unsigned int *eoi) { -struct netfront_queue *queue = dev_id;unsigned long flags; -if (queue->info->broken) -return IRQ_HANDLED ; +if (unlikely (queue->info->broken)) +return false;spin_lock_irqsave (&queue->tx_lock, flags); -xennet_tx_buf_gc (queue); +if (xennet_tx_buf_gc (queue)) + *eoi =0 ;spin_unlock_irqrestore (&queue->tx_lock, flags); +return true; +} + +static irqreturn_t xennet_tx_interrupt (int irq,void *dev_id) +{ +unsigned int eoiflag =XEN_EOI_FLAG_SPURIOUS ; + +if (likely (xennet_handle_tx (dev_id, &eoiflag))) +xen_irq_lateeoi (irq, eoiflag); +return IRQ_HANDLED ; } -static irqreturn_t xennet_rx_interrupt (int irq,void *dev_id) +static bool xennet_handle_rx (struct netfront_queue *queue,unsigned int *eoi) { -struct netfront_queue *queue = dev_id; -struct net_device *dev = queue->info->netdev; +unsigned int work_queued; +unsigned long flags; + +if (unlikely (queue->info->broken)) +return false; -if (queue->info->broken) -return IRQ_HANDLED ; +spin_lock_irqsave (&queue->rx_cons_lock, flags); + work_queued =RING_HAS_UNCONSUMED_RESPONSES (&queue->rx); +if (work_queued > queue->rx_rsp_unconsumed) { + queue->rx_rsp_unconsumed = work_queued; + *eoi =0 ; + }else if (unlikely (work_queued < queue->rx_rsp_unconsumed)) { +const struct device *dev = &queue->info->netdev->dev; + +spin_unlock_irqrestore (&queue->rx_cons_lock, flags); +dev_alert (dev,"RX producer index going backwards\n" ); +dev_alert (dev,"Disabled for further use\n" ); + queue->info->broken = true; +return false; + } +spin_unlock_irqrestore (&queue->rx_cons_lock, flags); -if (likely (netif_carrier_ok (dev) && -RING_HAS_UNCONSUMED_RESPONSES (&queue->rx))) +if (likely (netif_carrier_ok (queue->info->netdev) && work_queued))napi_schedule (&queue->napi); +return true; +} + +static irqreturn_t xennet_rx_interrupt (int irq,void *dev_id) +{ +unsigned int eoiflag =XEN_EOI_FLAG_SPURIOUS ; + +if (likely (xennet_handle_rx (dev_id, &eoiflag))) +xen_irq_lateeoi (irq, eoiflag); +return IRQ_HANDLED ; }static irqreturn_t xennet_interrupt (int irq,void *dev_id) { -xennet_tx_interrupt (irq, dev_id); -xennet_rx_interrupt (irq, dev_id); +unsigned int eoiflag =XEN_EOI_FLAG_SPURIOUS ; + +if (xennet_handle_tx (dev_id, &eoiflag) && +xennet_handle_rx (dev_id, &eoiflag)) +xen_irq_lateeoi (irq, eoiflag); +return IRQ_HANDLED ; }
@@ -1768,9 +1829,10 @@ static int setup_netfront_single(structif (err <0 ) goto fail; - err =bind_evtchn_to_irqhandler (queue->tx_evtchn, - xennet_interrupt, -0 , queue->info->netdev->name, queue); + err =bind_evtchn_to_irqhandler_lateeoi (queue->tx_evtchn, + xennet_interrupt,0 , + queue->info->netdev->name, + queue);if (err <0 ) goto bind_fail; queue->rx_evtchn = queue->tx_evtchn;
@@ -1798,18 +1860,18 @@ static int setup_netfront_split(struct nsnprintf (queue->tx_irq_name,sizeof (queue->tx_irq_name),"%s-tx" , queue->name); - err =bind_evtchn_to_irqhandler (queue->tx_evtchn, - xennet_tx_interrupt, -0 , queue->tx_irq_name, queue); + err =bind_evtchn_to_irqhandler_lateeoi (queue->tx_evtchn, + xennet_tx_interrupt,0 , + queue->tx_irq_name, queue);if (err <0 ) goto bind_tx_fail; queue->tx_irq = err;snprintf (queue->rx_irq_name,sizeof (queue->rx_irq_name),"%s-rx" , queue->name); - err =bind_evtchn_to_irqhandler (queue->rx_evtchn, - xennet_rx_interrupt, -0 , queue->rx_irq_name, queue); + err =bind_evtchn_to_irqhandler_lateeoi (queue->rx_evtchn, + xennet_rx_interrupt,0 , + queue->rx_irq_name, queue);if (err <0 ) goto bind_rx_fail; queue->rx_irq = err;
@@ -1911,6 +1973,7 @@ static int xennet_init_queue(struct netfspin_lock_init (&queue->tx_lock);spin_lock_init (&queue->rx_lock); +spin_lock_init (&queue->rx_cons_lock);timer_setup (&queue->rx_refill_timer, rx_refill_timeout,0 );
Greg Kroah-Hartman
maintainerPATCH 175/177 xen/console: harden hvc_xen against event channel storms
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit fe415186b43df0db1f17fa3a46275fd92107fe71 upstream.
The Xen console driver is still vulnerable for an attack via excessive number of events sent by the backend. Fix that by using a lateeoi event channel.
For the normal domU initial console this requires the introduction of bind_evtchn_to_irq_lateeoi() as there is no xenbus device available at the time the event channel is bound to the irq.
As the decision whether an interrupt was spurious or not requires to test for bytes having been read from the backend, move sending the event into the if statement, as sending an event without having found any bytes to be read is making no sense at all.
This is part of XSA-391
--- drivers/tty/hvc/hvc_xen.c | 30 +++++++++++++++++++++++++++--- drivers/xen/events/events_base.c | 6 ++++++ include/xen/events.h | 1 + 3 files changed, 34 insertions(+), 3 deletions(-)
drivers/tty/hvc/hvc_xen.c +27 -3
@@ -37,6 +37,8 @@ struct xencons_info {struct xenbus_device *xbdev;struct xencons_interface *intf;unsigned int evtchn; +XENCONS_RING_IDX out_cons; +unsigned int out_cons_same;struct hvc_struct *hvc;int irq;int vtermno;
@@ -138,6 +140,8 @@ static int domU_read_console(uint32_t vtXENCONS_RING_IDX cons, prod;int recv =0 ;struct xencons_info *xencons =vtermno_to_xencons (vtermno); +unsigned int eoiflag =0 ; +if (xencons ==NULL )return -EINVAL ; intf = xencons->intf;
@@ -157,7 +161,27 @@ static int domU_read_console(uint32_t vtmb ();/* read ring before consuming */ intf->in_cons = cons; -notify_daemon (xencons); +/* +* When to mark interrupt having been spurious: +* - there was no new data to be read, and +* - the backend did not consume some output bytes, and +* - the previous round with no read data didn't see consumed bytes +* (we might have a race with an interrupt being in flight while +* updating xencons->out_cons, so account for that by allowing one +* round without any visible reason) +*/ +if (intf->out_cons != xencons->out_cons) { + xencons->out_cons = intf->out_cons; + xencons->out_cons_same =0 ; + } +if (recv) { +notify_daemon (xencons); + }else if (xencons->out_cons_same++ >1 ) { + eoiflag =XEN_EOI_FLAG_SPURIOUS ; + } + +xen_irq_lateeoi (xencons->irq, eoiflag); +return recv; }
@@ -386,7 +410,7 @@ static int xencons_connect_backend(strucif (ret)return ret; info->evtchn = evtchn; - irq =bind_evtchn_to_irq (evtchn); + irq =bind_interdomain_evtchn_to_irq_lateeoi (dev, evtchn);if (irq <0 )return irq; info->irq = irq;
@@ -550,7 +574,7 @@ static int __init xen_hvc_init(void)return r; info =vtermno_to_xencons (HVC_COOKIE ); - info->irq =bind_evtchn_to_irq (info->evtchn); + info->irq =bind_evtchn_to_irq_lateeoi (info->evtchn); }if (info->irq <0 ) info->irq =0 ;/* NO_IRQ */
drivers/xen/events/events_base.c +6 -0
@@ -1251,6 +1251,12 @@ int bind_evtchn_to_irq(evtchn_port_t evt }EXPORT_SYMBOL_GPL (bind_evtchn_to_irq); +int bind_evtchn_to_irq_lateeoi (evtchn_port_t evtchn) +{ +return bind_evtchn_to_irq_chip (evtchn, &xen_lateeoi_chip,NULL ); +} +EXPORT_SYMBOL_GPL (bind_evtchn_to_irq_lateeoi); +static int bind_ipi_to_irq (unsigned int ipi,unsigned int cpu) {struct evtchn_bind_ipi bind_ipi;
include/xen/events.h +1 -0
@@ -17,6 +17,7 @@ struct xenbus_device;unsigned xen_evtchn_nr_channels (void );int bind_evtchn_to_irq (evtchn_port_t evtchn); +int bind_evtchn_to_irq_lateeoi (evtchn_port_t evtchn); int bind_evtchn_to_irqhandler(evtchn_port_t evtchn, irq_handler_t handler, unsigned long irqflags, const char *devname,
Greg Kroah-Hartman
maintainerPATCH 176/177 xen/netback: fix rx queue stall detection
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit 6032046ec4b70176d247a71836186d47b25d1684 upstream.
Commit 1d5d48523900a4b ("xen-netback: require fewer guest Rx slots when not using GSO") introduced a security problem in netback, as an interface would only be regarded to be stalled if no slot is available in the rx queue ring page. In case the SKB at the head of the queued requests will need more than one rx slot and only one slot is free the stall detection logic will never trigger, as the test for that is only looking for at least one slot to be free.
Fix that by testing for the needed number of slots instead of only one slot being available.
In order to not have to take the rx queue lock that often, store the number of needed slots in the queue data. As all SKB dequeue operations happen in the rx queue kernel thread this is safe, as long as the number of needed slots is accessed via READ/WRITE_ONCE() only and updates are always done with the rx queue lock held.
Add a small helper for obtaining the number of free slots.
This is part of XSA-392
--- drivers/net/xen-netback/common.h | 1 drivers/net/xen-netback/rx.c | 65 ++++++++++++++++++++++++--------------- 2 files changed, 42 insertions(+), 24 deletions(-)
drivers/net/xen-netback/common.h +1 -0
@@ -203,6 +203,7 @@ struct xenvif_queue { /* Per-queue dataunsigned int rx_queue_max;unsigned int rx_queue_len;unsigned long last_rx_time; +unsigned int rx_slots_needed;bool stalled;struct xenvif_copy_state rx_copy;
drivers/net/xen-netback/rx.c +41 -24
108 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 177/177 xen/netback: dont queue unlimited number of packages
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit be81992f9086b230623ae3ebbc85ecee4d00a3d3 upstream.
In case a guest isn't consuming incoming network traffic as fast as it is coming in, xen-netback is buffering network packages in unlimited numbers today. This can result in host OOM situations.
Commit f48da8b14d04ca8 ("xen-netback: fix unlimited guest Rx internal queue and carrier flapping") meant to introduce a mechanism to limit the amount of buffered data by stopping the Tx queue when reaching the data limit, but this doesn't work for cases like UDP.
When hitting the limit don't queue further SKBs, but drop them instead. In order to be able to tell Rx packages have been dropped increment the rx_dropped statistics counter in this case.
It should be noted that the old solution to continue queueing SKBs had the additional problem of an overflow of the 32-bit rx_queue_len value would result in intermittent Tx queue enabling.
This is part of XSA-392
--- drivers/net/xen-netback/rx.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/net/xen-netback/rx.c +11 -7
@@ -88,16 +88,19 @@ void xenvif_rx_queue_tail(struct xenvif_spin_lock_irqsave (&queue->rx_queue.lock, flags); -if (skb_queue_empty (&queue->rx_queue)) -xenvif_update_needed_slots (queue, skb); - -__skb_queue_tail (&queue->rx_queue, skb); - - queue->rx_queue_len += skb->len; -if (queue->rx_queue_len > queue->rx_queue_max) { +if (queue->rx_queue_len >= queue->rx_queue_max) {struct net_device *dev = queue->vif->dev;netif_tx_stop_queue (netdev_get_tx_queue (dev, queue->id)); +kfree_skb (skb); + queue->vif->dev->stats.rx_dropped++; + }else { +if (skb_queue_empty (&queue->rx_queue)) +xenvif_update_needed_slots (queue, skb); + +__skb_queue_tail (&queue->rx_queue, skb); + + queue->rx_queue_len += skb->len; }spin_unlock_irqrestore (&queue->rx_queue.lock, flags);
@@ -147,6 +150,7 @@ static void xenvif_rx_queue_drop_expiredbreak ;xenvif_rx_dequeue (queue);kfree_skb (skb); + queue->vif->dev->stats.rx_dropped++; } }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +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/v5.x/stable-review/patch-5.15.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 failLinux version: 5.15.11-rc1-g6c3eb74f1432
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +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/v5.x/stable-review/patch-5.15.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +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/v5.x/stable-review/patch-5.15.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.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: 5.15.11-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 6c3eb74f1432213bade7ca82a6a7638d1ad826a5
* git describe: v5.15.10-178-g6c3eb74f1432
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.10-178-g6c3eb74f1432
## No Test Regressions (compared to v5.15.7-171-ge18bff95c819)
## No Test Fixes (compared to v5.15.7-171-ge18bff95c819)
## Test result summary
total: 99084, pass: 84368, fail: 937, skip: 12857, xfail: 922
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 263 total, 257 passed, 6 failed
* arm64: 42 total, 40 passed, 2 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 40 total, 37 passed, 3 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 31 passed, 6 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 56 total, 50 passed, 6 failed
* riscv: 28 total, 19 passed, 9 failed
* s390: 22 total, 20 passed, 2 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 42 total, 40 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +0000. Anything received after that time might be too late.
Hi Greg,
Looking good.
Run tested on:
- Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition: build tested on:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- Allwinner H6
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +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/v5.x/stable-review/patch-5.15.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.11 release. There are 177 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, 22 Dec 2021 14:30:09 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 480 pass: 480 fail: 0
Guenter