October 2021 - Linux-stable-mirror

[tip: x86/urgent] x86/fpu: Restore the masking out of reserved MXCSR bits

by tip-bot2 for Borislav Petkov

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: d298b03506d3e161f7492c440babb0bfae35e650 Gitweb: https://git.kernel.org/tip/d298b03506d3e161f7492c440babb0bfae35e650 Author: Borislav Petkov <bp(a)suse.de> AuthorDate: Wed, 06 Oct 2021 18:33:52 +02:00 Committer: Borislav Petkov <bp(a)suse.de> CommitterDate: Fri, 08 Oct 2021 11:12:17 +02:00 x86/fpu: Restore the masking out of reserved MXCSR bits Ser Olmy reported a boot failure: init[1] bad frame in sigreturn frame:(ptrval) ip:b7c9fbe6 sp:bf933310 orax:ffffffff \ in libc-2.33.so[b7bed000+156000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU: 0 PID: 1 Comm: init Tainted: G W 5.14.9 #1 Hardware name: Hewlett-Packard HP PC/HP Board, BIOS JD.00.06 12/06/2001 Call Trace: dump_stack_lvl dump_stack panic do_exit.cold do_group_exit get_signal arch_do_signal_or_restart ? force_sig_info_to_task ? force_sig exit_to_user_mode_prepare syscall_exit_to_user_mode do_int80_syscall_32 entry_INT80_32 on an old 32-bit Intel CPU: vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping : 5 microcode : 0x3 Ser bisected the problem to the commit in Fixes. tglx suggested reverting the rejection of invalid MXCSR values which this commit introduced and replacing it with what the old code did - simply masking them out to zero. Further debugging confirmed his suggestion: fpu->state.fxsave.mxcsr: 0xb7be13b4, mxcsr_feature_mask: 0xffbf WARNING: CPU: 0 PID: 1 at arch/x86/kernel/fpu/signal.c:384 __fpu_restore_sig+0x51f/0x540 so restore the original behavior only for 32-bit kernels where you have ancient machines with buggy hardware. For 32-bit programs on 64-bit kernels, user space which supplies wrong MXCSR values is considered malicious so fail the sigframe restoration there. Fixes: 6f9866a166cd ("x86/fpu/signal: Let xrstor handle the features to init") Reported-by: Ser Olmy <ser.olmy(a)protonmail.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Tested-by: Ser Olmy <ser.olmy(a)protonmail.com> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/YVtA67jImg3KlBTw@zn.tnic --- arch/x86/kernel/fpu/signal.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index 445c57c..fa17a27 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -379,9 +379,14 @@ static int __fpu_restore_sig(void __user *buf, void __user *buf_fx, sizeof(fpu->state.fxsave))) return -EFAULT; - /* Reject invalid MXCSR values. */ - if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask) - return -EINVAL; + if (IS_ENABLED(CONFIG_X86_64)) { + /* Reject invalid MXCSR values. */ + if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask) + return -EINVAL; + } else { + /* Mask invalid bits out for historical reasons (broken hardware). */ + fpu->state.fxsave.mxcsr &= ~mxcsr_feature_mask; + } /* Enforce XFEATURE_MASK_FPSSE when XSAVE is enabled */ if (use_xsave())

3 years, 3 months

1
0
0 0

[PATCH 5/5] xhci: Enable trust tx length quirk for Fresco FL11 USB controller

by Mathias Nyman

From: Nikolay Martynov <mar.kolya(a)gmail.com> Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth. Signed-off-by: Nikolay Martynov <mar.kolya(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 633413d78380..2484a9d38ce2 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -30,6 +30,7 @@ #define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73 #define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000 #define PCI_DEVICE_ID_FRESCO_LOGIC_FL1009 0x1009 +#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 0x1100 #define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400 #define PCI_VENDOR_ID_ETRON 0x1b6f @@ -113,6 +114,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) /* Look for vendor-specific quirks */ if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC && (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK || + pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 || pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1400)) { if (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK && pdev->revision == 0x0) { -- 2.25.1

3 years, 3 months

1
0
0 0

[PATCH 3/5] USB: xhci: dbc: fix tty registration race

by Mathias Nyman

From: Johan Hovold <johan(a)kernel.org> Make sure to allocate resources before registering the tty device to avoid having a racing open() and write() fail to enable rx or dereference a NULL pointer when accessing the uninitialised fifo. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: stable(a)vger.kernel.org # 4.16 Cc: Lu Baolu <baolu.lu(a)linux.intel.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-dbgtty.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index 6e784f2fc26d..eb46e642e87a 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -408,40 +408,38 @@ static int xhci_dbc_tty_register_device(struct xhci_dbc *dbc) return -EBUSY; xhci_dbc_tty_init_port(dbc, port); - tty_dev = tty_port_register_device(&port->port, - dbc_tty_driver, 0, NULL); - if (IS_ERR(tty_dev)) { - ret = PTR_ERR(tty_dev); - goto register_fail; - } ret = kfifo_alloc(&port->write_fifo, DBC_WRITE_BUF_SIZE, GFP_KERNEL); if (ret) - goto buf_alloc_fail; + goto err_exit_port; ret = xhci_dbc_alloc_requests(dbc, BULK_IN, &port->read_pool, dbc_read_complete); if (ret) - goto request_fail; + goto err_free_fifo; ret = xhci_dbc_alloc_requests(dbc, BULK_OUT, &port->write_pool, dbc_write_complete); if (ret) - goto request_fail; + goto err_free_requests; + + tty_dev = tty_port_register_device(&port->port, + dbc_tty_driver, 0, NULL); + if (IS_ERR(tty_dev)) { + ret = PTR_ERR(tty_dev); + goto err_free_requests; + } port->registered = true; return 0; -request_fail: +err_free_requests: xhci_dbc_free_requests(&port->read_pool); xhci_dbc_free_requests(&port->write_pool); +err_free_fifo: kfifo_free(&port->write_fifo); - -buf_alloc_fail: - tty_unregister_device(dbc_tty_driver, 0); - -register_fail: +err_exit_port: xhci_dbc_tty_exit_port(port); dev_err(dbc->dev, "can't register tty port, err %d\n", ret); -- 2.25.1

3 years, 3 months

1
0
0 0

[PATCH 2/5] xhci: add quirk for host controllers that don't update endpoint DCS

by Mathias Nyman

From: Jonathan Bell <jonathan(a)raspberrypi.org> Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. [ bjorn: rebased to v5.14-rc2 ] Cc: stable(a)vger.kernel.org Link: https://github.com/raspberrypi/linux/issues/3060 Signed-off-by: Jonathan Bell <jonathan(a)raspberrypi.org> Signed-off-by: Bjørn Mork <bjorn(a)mork.no> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 4 +++- drivers/usb/host/xhci-ring.c | 25 ++++++++++++++++++++++++- drivers/usb/host/xhci.h | 1 + 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 2c9f25ca8edd..633413d78380 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -279,8 +279,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) pdev->device == 0x3432) xhci->quirks |= XHCI_BROKEN_STREAMS; - if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) + if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) { xhci->quirks |= XHCI_LPM_SUPPORT; + xhci->quirks |= XHCI_EP_CTX_BROKEN_DCS; + } if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index e676749f543b..7dbd26a9bc24 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -559,8 +559,11 @@ static int xhci_move_dequeue_past_td(struct xhci_hcd *xhci, struct xhci_ring *ep_ring; struct xhci_command *cmd; struct xhci_segment *new_seg; + struct xhci_segment *halted_seg = NULL; union xhci_trb *new_deq; int new_cycle; + union xhci_trb *halted_trb; + int index = 0; dma_addr_t addr; u64 hw_dequeue; bool cycle_found = false; @@ -598,7 +601,27 @@ static int xhci_move_dequeue_past_td(struct xhci_hcd *xhci, hw_dequeue = xhci_get_hw_deq(xhci, dev, ep_index, stream_id); new_seg = ep_ring->deq_seg; new_deq = ep_ring->dequeue; - new_cycle = hw_dequeue & 0x1; + + /* + * Quirk: xHC write-back of the DCS field in the hardware dequeue + * pointer is wrong - use the cycle state of the TRB pointed to by + * the dequeue pointer. + */ + if (xhci->quirks & XHCI_EP_CTX_BROKEN_DCS && + !(ep->ep_state & EP_HAS_STREAMS)) + halted_seg = trb_in_td(xhci, td->start_seg, + td->first_trb, td->last_trb, + hw_dequeue & ~0xf, false); + if (halted_seg) { + index = ((dma_addr_t)(hw_dequeue & ~0xf) - halted_seg->dma) / + sizeof(*halted_trb); + halted_trb = &halted_seg->trbs[index]; + new_cycle = halted_trb->generic.field[3] & 0x1; + xhci_dbg(xhci, "Endpoint DCS = %d TRB index = %d cycle = %d\n", + (u8)(hw_dequeue & 0x1), index, new_cycle); + } else { + new_cycle = hw_dequeue & 0x1; + } /* * We want to find the pointer, segment and cycle state of the new trb diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index dca6181c33fd..5a75fe563123 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1899,6 +1899,7 @@ struct xhci_hcd { #define XHCI_SG_TRB_CACHE_SIZE_QUIRK BIT_ULL(39) #define XHCI_NO_SOFT_RETRY BIT_ULL(40) #define XHCI_BROKEN_D3COLD BIT_ULL(41) +#define XHCI_EP_CTX_BROKEN_DCS BIT_ULL(42) unsigned int num_active_eps; unsigned int limit_active_eps; -- 2.25.1

3 years, 3 months

1
0
0 0

[PATCH 1/5] xhci: guard accesses to ep_state in xhci_endpoint_reset()

by Mathias Nyman

From: Jonathan Bell <jonathan(a)raspberrypi.com> See https://github.com/raspberrypi/linux/issues/3981 Two read-modify-write cycles on ep->ep_state are not guarded by xhci->lock. Fix these. Signed-off-by: Jonathan Bell <jonathan(a)raspberrypi.com> Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 93c38b557afd..541fe4dcc43a 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3214,10 +3214,13 @@ static void xhci_endpoint_reset(struct usb_hcd *hcd, return; /* Bail out if toggle is already being cleared by a endpoint reset */ + spin_lock_irqsave(&xhci->lock, flags); if (ep->ep_state & EP_HARD_CLEAR_TOGGLE) { ep->ep_state &= ~EP_HARD_CLEAR_TOGGLE; + spin_unlock_irqrestore(&xhci->lock, flags); return; } + spin_unlock_irqrestore(&xhci->lock, flags); /* Only interrupt and bulk ep's use data toggle, USB2 spec 5.5.4-> */ if (usb_endpoint_xfer_control(&host_ep->desc) || usb_endpoint_xfer_isoc(&host_ep->desc)) @@ -3303,8 +3306,10 @@ static void xhci_endpoint_reset(struct usb_hcd *hcd, xhci_free_command(xhci, cfg_cmd); cleanup: xhci_free_command(xhci, stop_cmd); + spin_lock_irqsave(&xhci->lock, flags); if (ep->ep_state & EP_SOFT_CLEAR_TOGGLE) ep->ep_state &= ~EP_SOFT_CLEAR_TOGGLE; + spin_unlock_irqrestore(&xhci->lock, flags); } static int xhci_check_streams_endpoint(struct xhci_hcd *xhci, -- 2.25.1

3 years, 3 months

1
0
0 0

[RFC/PATCH for 4.14 and 4.19] lib/timerqueue: Rely on rbtree semantics for next timer

by Nobuhiro Iwamatsu

From: Davidlohr Bueso <dave(a)stgolabs.net> commit 511885d7061eda3eb1faf3f57dcc936ff75863f1 upstream. Simplify the timerqueue code by using cached rbtrees and rely on the tree leftmost node semantics to get the timer with earliest expiration time. This is a drop in conversion, and therefore semantics remain untouched. The runtime overhead of cached rbtrees is be pretty much the same as the current head->next method, noting that when removing the leftmost node, a common operation for the timerqueue, the rb_next(leftmost) is O(1) as well, so the next timer will either be the right node or its parent. Therefore no extra pointer chasing. Finally, the size of the struct timerqueue_head remains the same. Passes several hours of rcutorture. Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lkml.kernel.org/r/20190724152323.bojciei3muvfxalm@linux-r8p5 Reference: CVE-2021-20317 Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu(a)toshiba.co.jp> --- include/linux/timerqueue.h | 13 ++++++------- lib/timerqueue.c | 30 ++++++++++++------------------ 2 files changed, 18 insertions(+), 25 deletions(-) diff --git a/include/linux/timerqueue.h b/include/linux/timerqueue.h index 78b8cc73f12fc9..aff122f1062a83 100644 --- a/include/linux/timerqueue.h +++ b/include/linux/timerqueue.h @@ -12,8 +12,7 @@ struct timerqueue_node { }; struct timerqueue_head { - struct rb_root head; - struct timerqueue_node *next; + struct rb_root_cached rb_root; }; @@ -29,13 +28,14 @@ extern struct timerqueue_node *timerqueue_iterate_next( * * @head: head of timerqueue * - * Returns a pointer to the timer node that has the - * earliest expiration time. + * Returns a pointer to the timer node that has the earliest expiration time. */ static inline struct timerqueue_node *timerqueue_getnext(struct timerqueue_head *head) { - return head->next; + struct rb_node *leftmost = rb_first_cached(&head->rb_root); + + return rb_entry(leftmost, struct timerqueue_node, node); } static inline void timerqueue_init(struct timerqueue_node *node) @@ -45,7 +45,6 @@ static inline void timerqueue_init(struct timerqueue_node *node) static inline void timerqueue_init_head(struct timerqueue_head *head) { - head->head = RB_ROOT; - head->next = NULL; + head->rb_root = RB_ROOT_CACHED; } #endif /* _LINUX_TIMERQUEUE_H */ diff --git a/lib/timerqueue.c b/lib/timerqueue.c index 0d54bcbc8170c7..7a8ae3d5fd4057 100644 --- a/lib/timerqueue.c +++ b/lib/timerqueue.c @@ -39,9 +39,10 @@ */ bool timerqueue_add(struct timerqueue_head *head, struct timerqueue_node *node) { - struct rb_node **p = &head->head.rb_node; + struct rb_node **p = &head->rb_root.rb_root.rb_node; struct rb_node *parent = NULL; - struct timerqueue_node *ptr; + struct timerqueue_node *ptr; + bool leftmost = true; /* Make sure we don't add nodes that are already added */ WARN_ON_ONCE(!RB_EMPTY_NODE(&node->node)); @@ -49,19 +50,17 @@ bool timerqueue_add(struct timerqueue_head *head, struct timerqueue_node *node) while (*p) { parent = *p; ptr = rb_entry(parent, struct timerqueue_node, node); - if (node->expires < ptr->expires) + if (node->expires < ptr->expires) { p = &(*p)->rb_left; - else + } else { p = &(*p)->rb_right; + leftmost = false; + } } rb_link_node(&node->node, parent, p); - rb_insert_color(&node->node, &head->head); + rb_insert_color_cached(&node->node, &head->rb_root, leftmost); - if (!head->next || node->expires < head->next->expires) { - head->next = node; - return true; - } - return false; + return leftmost; } EXPORT_SYMBOL_GPL(timerqueue_add); @@ -78,15 +77,10 @@ bool timerqueue_del(struct timerqueue_head *head, struct timerqueue_node *node) { WARN_ON_ONCE(RB_EMPTY_NODE(&node->node)); - /* update next pointer */ - if (head->next == node) { - struct rb_node *rbn = rb_next(&node->node); - - head->next = rb_entry_safe(rbn, struct timerqueue_node, node); - } - rb_erase(&node->node, &head->head); + rb_erase_cached(&node->node, &head->rb_root); RB_CLEAR_NODE(&node->node); - return head->next != NULL; + + return !RB_EMPTY_ROOT(&head->rb_root.rb_root); } EXPORT_SYMBOL_GPL(timerqueue_del); -- 2.33.0

3 years, 3 months

2
1
0 0

Re: Can we add both Samsung NCQ fixes (7a8526a5cd51cf5f070310c6c37dd7293334ac49 and 8a6430ab9c9c87cb64c512e505e8690bbaee190b) to the -stable trees

by Krzysztof Olędzki

Third Time's the Charm, now with the proper stable@ address. ;) On 2021-09-26 at 21:10, Krzysztof Olędzki wrote: > (fixed Greg's e-mail) > > Hi, > > On 2021-09-20 at 19:32, Krzysztof Olędzki wrote: >> Hi Greg, Sasha, >> >> On 2021-09-14 at 19:58, Krzysztof Olędzki wrote: >>> Hi, >>> >>> Would it be possible to add both: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… >>> into the -stable trees? >>> >>> Right now only the second patch (8a6430ab9c9c87cb64c512e505e8690bbaee190b) is tagged with "Cc: stable(a)vger.kernel.org", but has not been include into 5.4.146-rc1 and is also not in stable-queue.git. >>> >>> If it helps, I have tested both of them on 5.4.145 and they apply cleanly. >> >> >> Looks like 8a6430ab9c9c87cb64c512e505e8690bbaee190b - "libata: add ATA_HORKAGE_NO_NCQ_TRIM for Samsung 860 and 870 SSDs" has been included into the most recent wave of -stable kernels. >> >> Can we include 7a8526a5cd51cf5f070310c6c37dd7293334ac49 - "libata: Add ATA_HORKAGE_NO_NCQ_ON_ATI for Samsung 860 and 870 SSD." in the next releases, pretty please? > > With the new set of -stable kernel just released, is this a good moment to re-ask for 7a8526a5cd51cf5f070310c6c37dd7293334ac49? > > Thanks, > Krzysztof >

3 years, 3 months

2
1
0 0

Re: Backporting "silence nfscache allocation warnings with kvzalloc" - 8c38b705b4f4ca4e7f9cc116141bc38391917c30 into 5.4-stable and potentially older stable kernels?

by Krzysztof Olędzki

(re-sent with the proper stable@ address) On 2021-06-10 at 16:37, Krzysztof Olędzki wrote: > Hi, > > I noticed sporadic "page allocation failure" errors in my systems > running 5.4-stable kernels, that look like this: > > [1530107.418557] emerge: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 > [1530107.418575] CPU: 7 PID: 673 Comm: emerge Not tainted 5.4.121-o3 #1 > [1530107.418576] Hardware name: Dell Inc. PowerEdge T110 II/0PM2CW, BIOS 2.10.0 05/24/2018 > [1530107.418577] Call Trace: > [1530107.418585] dump_stack+0x50/0x63 > [1530107.418589] warn_alloc+0xde/0x15c > [1530107.418591] __alloc_pages_slowpath+0x759/0x786 > [1530107.418594] ? kernfs_add_one+0xf6/0x10d > [1530107.418597] ? preempt_latency_start+0x2b/0x3e > [1530107.418600] ? ida_alloc_range+0x2bc/0x378 > [1530107.418602] __alloc_pages_nodemask+0x17d/0x243 > [1530107.418605] kmalloc_order+0x1b/0x69 > [1530107.418607] kmalloc_order_trace+0x18/0xa1 > [1530107.418609] nfsd_reply_cache_init+0xae/0x13a > [1530107.418612] nfsd_init_net+0x66/0xfe > [1530107.418615] ops_init+0xa9/0xd5 > [1530107.418617] setup_net+0xb3/0x19b > [1530107.418619] copy_net_ns+0xec/0x140 > [1530107.418621] create_new_namespaces+0x125/0x19a > [1530107.418623] unshare_nsproxy_namespaces+0x86/0x9c > [1530107.418626] ksys_unshare+0x14b/0x2e3 > [1530107.418628] __x64_sys_unshare+0x9/0xc > [1530107.418630] do_syscall_64+0x72/0x7f > [1530107.418633] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [1530107.418636] RIP: 0033:0x7f47d7161f97 > [1530107.418638] Code: 73 01 c3 48 8b 0d d1 fe 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 10 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 fe 0b 00 f7 d8 64 89 01 48 > [1530107.418639] RSP: 002b:00007ffd9a1f61f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 > [1530107.418641] RAX: ffffffffffffffda RBX: 00007ffd9a1f6200 RCX: 00007f47d7161f97 > [1530107.418642] RDX: 0000000000000000 RSI: 00007f47c95d2800 RDI: 000000006c020000 > [1530107.418643] RBP: 00007ffd9a1f6200 R08: 0000000000000000 R09: 00007ffd9a1f6250 > [1530107.418643] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd9a1f6348 > [1530107.418644] R13: 0000000000000000 R14: 00007ffd9a1f62c0 R15: 00007ffd9a1f6328 > [1530107.418646] Mem-Info: > [1530107.418650] active_anon:507099 inactive_anon:153606 isolated_anon:0 > active_file:2413575 inactive_file:4701878 isolated_file:0 > unevictable:2557 dirty:2354 writeback:0 unstable:0 > slab_reclaimable:275977 slab_unreclaimable:23789 > mapped:27516 shmem:12726 pagetables:5087 bounce:0 > free:83786 free_pcp:0 free_cma:0 > [1530107.418653] Node 0 active_anon:2028396kB inactive_anon:614424kB active_file:9654300kB inactive_file:18807512kB unevictable:10228kB isolated(anon):0kB isolated(file):0kB mapped:110064kB dirty:9416kB writeback:0kB shmem:50904kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no > [1530107.418656] DMA free:15888kB min:8kB low:20kB high:32kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [1530107.418657] lowmem_reserve[]: 0 2422 32068 32068 > [1530107.418661] DMA32 free:248688kB min:1728kB low:4208kB high:6688kB active_anon:94588kB inactive_anon:108056kB active_file:976696kB inactive_file:792500kB unevictable:104kB writepending:2744kB present:2574428kB managed:2549240kB mlocked:104kB kernel_stack:192kB pagetables:968kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [1530107.418662] lowmem_reserve[]: 0 0 29645 29645 > [1530107.418666] Normal free:70568kB min:21180kB low:51536kB high:81892kB active_anon:1934340kB inactive_anon:506132kB active_file:8677844kB inactive_file:18015144kB unevictable:10124kB writepending:6672kB present:30932992kB managed:30357820kB mlocked:10124kB kernel_stack:5732kB pagetables:19380kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [1530107.418666] lowmem_reserve[]: 0 0 0 0 > [1530107.418668] DMA: 0*4kB 0*8kB 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15888kB > [1530107.418674] DMA32: 10702*4kB (UME) 3914*8kB (UME) 4900*16kB (UME) 1794*32kB (UME) 623*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 249800kB > [1530107.418680] Normal: 1795*4kB (UMEH) 635*8kB (UMEH) 284*16kB (UMH) 297*32kB (UMEH) 703*64kB (MEH) 3*128kB (H) 0*256kB 1*512kB (H) 0*1024kB 0*2048kB 0*4096kB = 72196kB > [1530107.418687] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB > [1530107.418688] 7129905 total pagecache pages > [1530107.418690] 13 pages in swap cache > [1530107.418691] Swap cache stats: add 121, delete 108, find 15/20 > [1530107.418692] Free swap = 4191732kB > [1530107.418692] Total swap = 4193276kB > [1530107.418693] 8380852 pages RAM > [1530107.418694] 0 pages HighMem/MovableOnly > [1530107.418694] 150111 pages reserved > > If I'm not mistaken, 5.10 and newer kernels have a fix for this: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > I wonder if it would be possible to include it in 5.4-stable and potentially older stable kernels? > > From 8c38b705b4f4ca4e7f9cc116141bc38391917c30 Mon Sep 17 00:00:00 2001 > From: Rik van Riel <riel(a)surriel.com> > Date: Mon, 14 Sep 2020 13:07:19 -0400 > Subject: silence nfscache allocation warnings with kvzalloc > > silence nfscache allocation warnings with kvzalloc > > Currently nfsd_reply_cache_init attempts hash table allocation through > kmalloc, and manually falls back to vzalloc if that fails. This makes > the code a little larger than needed, and creates a significant amount > of serial console spam if you have enough systems. > > Switching to kvzalloc gets rid of the allocation warnings, and makes > the code a little cleaner too as a side effect. > > Freeing of nn->drc_hashtbl is already done using kvfree currently. > > Signed-off-by: Rik van Riel <riel(a)surriel.com> > Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> > --- > fs/nfsd/nfscache.c | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c > index 0a0cf1fd77d33..80c90fc231a53 100644 > --- a/fs/nfsd/nfscache.c > +++ b/fs/nfsd/nfscache.c > @@ -172,14 +172,10 @@ int nfsd_reply_cache_init(struct nfsd_net *nn) > if (status) > goto out_nomem; > > - nn->drc_hashtbl = kcalloc(hashsize, > - sizeof(*nn->drc_hashtbl), GFP_KERNEL); > - if (!nn->drc_hashtbl) { > - nn->drc_hashtbl = vzalloc(array_size(hashsize, > - sizeof(*nn->drc_hashtbl))); > - if (!nn->drc_hashtbl) > - goto out_shrinker; > - } > + nn->drc_hashtbl = kvzalloc(array_size(hashsize, > + sizeof(*nn->drc_hashtbl)), GFP_KERNEL); > + if (!nn->drc_hashtbl) > + goto out_shrinker; > > for (i = 0; i < hashsize; i++) { > INIT_LIST_HEAD(&nn->drc_hashtbl[i].lru_head); >

3 years, 3 months

2
1
0 0

Requesting stable merge for commit 02d029a41dc986e2d5a77ecca45803857b346829

by Anand K. Mistry

I'd like to request commit 02d029a41dc986e2d5a77ecca45803857b346829 ("perf/x86: Reset destroy callback on event init failure") be merged to the 5.10 stable branch. This fixes a bug which was exposed by commit f11dd0d80555 ("perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op") merged into 5.10.65 (as commit bafece6cd1f9), and partially broke perf on AMD StoneyRidge systems. I've tested this patch locally on 5.10.70 on an AMD StoneyRidge (A4-9120C) system.

3 years, 3 months

2
1
0 0

stable-rc/queue/5.10 baseline: 145 runs, 2 regressions (v5.10.71-27-g0503cdd00c93)

by kernelci.org bot

stable-rc/queue/5.10 baseline: 145 runs, 2 regressions (v5.10.71-27-g0503cdd00c93) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ------------+-------+---------------+----------+----------------+------------ hip07-d05 | arm64 | lab-collabora | gcc-8 | defconfig | 1 i945gsex-qs | i386 | lab-clabbe | gcc-8 | i386_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.10/kernel/v5.10.71… Test: baseline Tree: stable-rc Branch: queue/5.10 Describe: v5.10.71-27-g0503cdd00c93 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 0503cdd00c93cd43022c0f86563ac6c27aac7ca2 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ------------+-------+---------------+----------+----------------+------------ hip07-d05 | arm64 | lab-collabora | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/615fbc40d8c70d455999a336 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.71-27-g0503cdd00c9… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.71-27-g0503cdd00c9… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615fbc40d8c70d455999a337 failing since 98 days (last pass: v5.10.46-100-gce5b41f85637, first fail: v5.10.46-100-g3b96099161c8b) platform | arch | lab | compiler | defconfig | regressions ------------+-------+---------------+----------+----------------+------------ i945gsex-qs | i386 | lab-clabbe | gcc-8 | i386_defconfig | 1 Details: https://kernelci.org/test/plan/id/615fb9dc980a6699df99a2e4 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: i386_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.71-27-g0503cdd00c9… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.71-27-g0503cdd00c9… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615fb9dc980a6699df99a2e5 new failure (last pass: v5.10.71-28-g2f55a27c87e9)

3 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2021