August 2023 - Linux-stable-mirror

[PATCH] mm: Fix access_remote_vm() regression on tagged addresses

by Kirill A. Shutemov

GDB uses /proc/PID/mem to access memory of the target process. GDB doesn't untag addresses manually, but relies on kernel to do the right thing. mem_rw() of procfs uses access_remote_vm() to get data from the target process. It worked fine until recent changes in __access_remote_vm() that now checks if there's VMA at target address using raw address. Untag the address before looking up the VMA. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reported-by: Christina Schimpe <christina.schimpe(a)intel.com> Fixes: eee9c708cc89 ("gup: avoid stack expansion warning for known-good case") Cc: stable(a)vger.kernel.org --- mm/memory.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index 01f39e8144ef..3be9db30db32 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5701,6 +5701,9 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf, if (mmap_read_lock_killable(mm)) return 0; + /* Untag the address before looking up the VMA */ + addr = untagged_addr_remote(mm, addr); + /* Avoid triggering the temporary warning in __get_user_pages */ if (!vma_lookup(mm, addr) && !expand_stack(mm, addr)) return 0; -- 2.41.0

1 year, 5 months

3
3
0 0

[PATCH net 0/5] Netfilter fixes for net

by Pablo Neira Ayuso

Hi, The following patchset contains Netfilter fixes for net. The existing attempt to resolve races between control plane and GC work is error prone, as reported by Bien Pham <phamnnb(a)sea.com>, some places forgot to call nft_set_elem_mark_busy(), leading to double-deactivation of elements. This series contains the following patches: 1) Do not skip expired elements during walk otherwise elements might never decrement the reference counter on data, leading to memleak. 2) Add a GC transaction API to replace the former attempt to deal with races between control plane and GC. GC worker sets on NFT_SET_ELEM_DEAD_BIT on elements and it creates a GC transaction to remove the expired elements, GC transaction could abort in case of interference with control plane and retried later (GC async). Set backends such as rbtree and pipapo also perform GC from control plane (GC sync), in such case, element deactivation and removal is safe because mutex is held then collected elements are released via call_rcu(). 3) Adapt existing set backends to use the GC transaction API. 4) Update rhash set backend to set on _DEAD bit to report deleted elements from datapath for GC. 5) Remove old GC batch API and the NFT_SET_ELEM_BUSY_BIT. Florian Westphal (1): netfilter: nf_tables: don't skip expired elements during walk Pablo Neira Ayuso (4): netfilter: nf_tables: GC transaction API to avoid race with control plane netfilter: nf_tables: adapt set backend to use GC transaction API netfilter: nft_set_hash: mark set element as dead when deleting from packet path netfilter: nf_tables: remove busy mark and gc batch API Please, pull these changes from: git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git nf-23-08-10 Thanks. ---------------------------------------------------------------- The following changes since commit c5ccff70501d92db445a135fa49cf9bc6b98c444: Merge branch 'net-sched-bind-logic-fixes-for-cls_fw-cls_u32-and-cls_route' (2023-07-31 20:10:39 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-23-08-10 for you to fetch changes up to a2dd0233cbc4d8a0abb5f64487487ffc9265beb5: netfilter: nf_tables: remove busy mark and gc batch API (2023-08-10 08:25:27 +0200) ---------------------------------------------------------------- netfilter pull request 23-08-10 ---------------------------------------------------------------- Florian Westphal (1): netfilter: nf_tables: don't skip expired elements during walk Pablo Neira Ayuso (4): netfilter: nf_tables: GC transaction API to avoid race with control plane netfilter: nf_tables: adapt set backend to use GC transaction API netfilter: nft_set_hash: mark set element as dead when deleting from packet path netfilter: nf_tables: remove busy mark and gc batch API include/net/netfilter/nf_tables.h | 120 ++++++--------- net/netfilter/nf_tables_api.c | 307 ++++++++++++++++++++++++++++++-------- net/netfilter/nft_set_hash.c | 85 +++++++---- net/netfilter/nft_set_pipapo.c | 66 +++++--- net/netfilter/nft_set_rbtree.c | 146 ++++++++++-------- 5 files changed, 476 insertions(+), 248 deletions(-)

1 year, 5 months

5
10
0 0

[PATCH V8 net] net: mana: Fix MANA VF unload when hardware is unresponsive

by Souradeep Chakrabarti

When unloading the MANA driver, mana_dealloc_queues() waits for the MANA hardware to complete any inflight packets and set the pending send count to zero. But if the hardware has failed, mana_dealloc_queues() could wait forever. Fix this by adding a timeout to the wait. Set the timeout to 120 seconds, which is a somewhat arbitrary value that is more than long enough for functional hardware to complete any sends. Cc: stable(a)vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Souradeep Chakrabarti <schakrabarti(a)linux.microsoft.com> --- V7 -> V8: * Replaced dev_consume_skb_any with dev_kfree_skb_any. * Added extra braces to use assignment as truth value. V6 -> V7: * Optimized the while loop for freeing skb. V5 -> V6: * Added pcie_flr to reset the pci after timeout. * Fixed the position of changelog. * Removed unused variable like cq. V4 -> V5: * Added fixes tag * Changed the usleep_range from static to incremental value. * Initialized timeout in the begining. V3 -> V4: * Removed the unnecessary braces from mana_dealloc_queues(). V2 -> V3: * Removed the unnecessary braces from mana_dealloc_queues(). V1 -> V2: * Added net branch * Removed the typecasting to (struct mana_context*) of void pointer * Repositioned timeout variable in mana_dealloc_queues() * Repositioned vf_unload_timeout in mana_context struct, to utilise the 6 bytes hole --- drivers/net/ethernet/microsoft/mana/mana_en.c | 37 +++++++++++++++++-- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index a499e460594b..c2ad0921e893 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -8,6 +8,7 @@ #include <linux/ethtool.h> #include <linux/filter.h> #include <linux/mm.h> +#include <linux/pci.h> #include <net/checksum.h> #include <net/ip6_checksum.h> @@ -2345,9 +2346,12 @@ int mana_attach(struct net_device *ndev) static int mana_dealloc_queues(struct net_device *ndev) { struct mana_port_context *apc = netdev_priv(ndev); + unsigned long timeout = jiffies + 120 * HZ; struct gdma_dev *gd = apc->ac->gdma_dev; struct mana_txq *txq; + struct sk_buff *skb; int i, err; + u32 tsleep; if (apc->port_is_up) return -EINVAL; @@ -2363,15 +2367,40 @@ static int mana_dealloc_queues(struct net_device *ndev) * to false, but it doesn't matter since mana_start_xmit() drops any * new packets due to apc->port_is_up being false. * - * Drain all the in-flight TX packets + * Drain all the in-flight TX packets. + * A timeout of 120 seconds for all the queues is used. + * This will break the while loop when h/w is not responding. + * This value of 120 has been decided here considering max + * number of queues. */ + for (i = 0; i < apc->num_queues; i++) { txq = &apc->tx_qp[i].txq; - - while (atomic_read(&txq->pending_sends) > 0) - usleep_range(1000, 2000); + tsleep = 1000; + while (atomic_read(&txq->pending_sends) > 0 && + time_before(jiffies, timeout)) { + usleep_range(tsleep, tsleep + 1000); + tsleep <<= 1; + } + if (atomic_read(&txq->pending_sends)) { + err = pcie_flr(to_pci_dev(gd->gdma_context->dev)); + if (err) { + netdev_err(ndev, "flr failed %d with %d pkts pending in txq %u\n", + err, atomic_read(&txq->pending_sends), + txq->gdma_txq_id); + } + break; + } } + for (i = 0; i < apc->num_queues; i++) { + txq = &apc->tx_qp[i].txq; + while ((skb = skb_dequeue(&txq->pending_skbs))) { + mana_unmap_skb(skb, apc); + dev_kfree_skb_any(skb); + } + atomic_set(&txq->pending_sends, 0); + } /* We're 100% sure the queues can no longer be woken up, because * we're sure now mana_poll_tx_cq() can't be running. */ -- 2.34.1

1 year, 5 months

2
1
0 0

get_maintainer, b4, and CC: stable

by Nick Desaulniers

Hi Joe, A recent mistake I made when using b4 was that I added a fixes tag, but forgot to Cc: stable in the commit message. Speaking with Konstantine, it seems that b4 may just be importing the recommendations from get_maintainer.pl. I suspect that either b4 or get_maintainer could see the Fixes tag and then suggest to Cc stable for me. Should get_maintainer.pl make such recommendations? -- Thanks, ~Nick Desaulniers

1 year, 5 months

4
3
0 0

Re: [PATCH 1/2] drm/i915: fix display probe for IVB Q and IVB D GT2 server

by Jani Nikula

On Fri, 04 Aug 2023, Jani Nikula <jani.nikula(a)intel.com> wrote: > The current display probe is unable to differentiate between IVB Q and > IVB D GT2 server, as they both have the same device id, but different > subvendor and subdevice. This leads to the latter being misidentified as > the former, and should just end up not having a display. However, the no > display case returns a NULL as the display device info, and promptly > oopses. > > As the IVB Q case is rare, and we're anyway moving towards GMD ID, > handle the identification requiring subvendor and subdevice as a special > case first, instead of unnecessarily growing the intel_display_ids[] > array with subvendor and subdevice. > > [ 5.425298] BUG: kernel NULL pointer dereference, address: 0000000000000000 > [ 5.426059] #PF: supervisor read access in kernel mode > [ 5.426810] #PF: error_code(0x0000) - not-present page > [ 5.427570] PGD 0 P4D 0 > [ 5.428285] Oops: 0000 [#1] PREEMPT SMP PTI > [ 5.429035] CPU: 0 PID: 137 Comm: (udev-worker) Not tainted 6.4.0-1-amd64 #1 Debian 6.4.4-1 > [ 5.429759] Hardware name: HP HP Z220 SFF Workstation/HP Z220 SFF Workstation, BIOS 4.19-218-gb184e6e0a1 02/02/2023 > [ 5.430485] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] > [ 5.431338] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b > [ 5.432920] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 > [ 5.433707] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 > [ 5.434494] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a > [ 5.435277] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 > [ 5.436055] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 > [ 5.436867] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 > [ 5.437646] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 > [ 5.438434] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 5.439218] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 > [ 5.440009] Call Trace: > [ 5.440824] <TASK> > [ 5.441611] ? __die+0x23/0x70 > [ 5.442394] ? page_fault_oops+0x17d/0x4c0 > [ 5.443173] ? exc_page_fault+0x7f/0x180 > [ 5.443949] ? asm_exc_page_fault+0x26/0x30 > [ 5.444756] ? intel_device_info_driver_create+0xf1/0x120 [i915] > [ 5.445652] ? intel_device_info_driver_create+0xea/0x120 [i915] > [ 5.446545] i915_driver_probe+0x7f/0xb60 [i915] > [ 5.447431] ? drm_privacy_screen_get+0x15c/0x1a0 [drm] > [ 5.448240] local_pci_probe+0x45/0xa0 > [ 5.449013] pci_device_probe+0xc7/0x240 > [ 5.449748] really_probe+0x19e/0x3e0 > [ 5.450464] ? __pfx___driver_attach+0x10/0x10 > [ 5.451172] __driver_probe_device+0x78/0x160 > [ 5.451870] driver_probe_device+0x1f/0x90 > [ 5.452601] __driver_attach+0xd2/0x1c0 > [ 5.453293] bus_for_each_dev+0x88/0xd0 > [ 5.453989] bus_add_driver+0x116/0x220 > [ 5.454672] driver_register+0x59/0x100 > [ 5.455336] i915_init+0x25/0xc0 [i915] > [ 5.456104] ? __pfx_i915_init+0x10/0x10 [i915] > [ 5.456882] do_one_initcall+0x5d/0x240 > [ 5.457511] do_init_module+0x60/0x250 > [ 5.458126] __do_sys_finit_module+0xac/0x120 > [ 5.458721] do_syscall_64+0x60/0xc0 > [ 5.459314] ? syscall_exit_to_user_mode+0x1b/0x40 > [ 5.459897] ? do_syscall_64+0x6c/0xc0 > [ 5.460510] entry_SYSCALL_64_after_hwframe+0x72/0xdc > [ 5.461082] RIP: 0033:0x7febd20b0eb9 > [ 5.461648] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2f 1f 0d 00 f7 d8 64 89 01 48 > [ 5.462905] RSP: 002b:00007fffabb1ba78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 > [ 5.463554] RAX: ffffffffffffffda RBX: 0000561e6304f410 RCX: 00007febd20b0eb9 > [ 5.464201] RDX: 0000000000000000 RSI: 00007febd2244f0d RDI: 0000000000000015 > [ 5.464869] RBP: 00007febd2244f0d R08: 0000000000000000 R09: 000000000000000a > [ 5.465512] R10: 0000000000000015 R11: 0000000000000246 R12: 0000000000020000 > [ 5.466124] R13: 0000000000000000 R14: 0000561e63032b60 R15: 000000000000000a > [ 5.466700] </TASK> > [ 5.467271] Modules linked in: i915(+) drm_buddy video crc32_pclmul sr_mod hid_generic wmi crc32c_intel i2c_algo_bit sd_mod cdrom drm_display_helper cec usbhid rc_core ghash_clmulni_intel hid sha512_ssse3 ttm sha512_generic xhci_pci ehci_pci xhci_hcd ehci_hcd nvme ahci drm_kms_helper nvme_core libahci t10_pi libata psmouse aesni_intel scsi_mod crypto_simd i2c_i801 scsi_common crc64_rocksoft_generic cryptd i2c_smbus drm lpc_ich crc64_rocksoft crc_t10dif e1000e usbcore crct10dif_generic usb_common crct10dif_pclmul crc64 crct10dif_common button > [ 5.469750] CR2: 0000000000000000 > [ 5.470364] ---[ end trace 0000000000000000 ]--- > [ 5.470971] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] > [ 5.471699] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b > [ 5.473034] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 > [ 5.473698] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 > [ 5.474371] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a > [ 5.475045] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 > [ 5.475725] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 > [ 5.476405] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 > [ 5.477124] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 > [ 5.477811] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 5.478499] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 > > Fixes: 69d439818fe5 ("drm/i915/display: Make display responsible for probing its own IP") Sasha, after pushing this fix, I realized the bug report was against 6.4.4, but the above commit hit upstream in v6.5-rc1. Turns out it was automatically backported as a dependency: commit be2caaed96c55bb1fcd55a25e60d7b309ff49f2d Author: Matt Roper <matthew.d.roper(a)intel.com> Date: Tue May 23 12:56:07 2023 -0700 drm/i915/display: Make display responsible for probing its own IP [ Upstream commit 69d439818fe501e8c9e50d963a53cb596e36f9f7 ] Rather than selecting the display IP and feature flags at the same time the general PCI probing happens, move this step into the display code itself so that it can be more easily re-used outside of i915 (i.e., by the Xe driver). v2: - Make intel_display_device_probe() always return a non-NULL pointer and simplify copying of runtime_defaults. (Andrzej) v3: - Redefine INTEL_VGA_DEVICE/INTEL_QUANTA_DEVICE to eliminate a cast and an include of linux/mod_devicetable.h. (Jani) - Keep explicit memcpy for runtime defaults. (Jani) Cc: Andrzej Hajda <andrzej.hajda(a)intel.com> Signed-off-by: Matt Roper <matthew.d.roper(a)intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com> Acked-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-5-matthe… Stable-dep-of: 19db2062094c ("drm/i915: No 10bit gamma on desktop gen3 parts") Signed-off-by: Sasha Levin <sashal(a)kernel.org> I'm a bit surprised and scared this kind of refactoring commit got backported to stable. Do you have automation in place to backport the fixes to backported commits too? I didn't think to add Cc: stable in the commit. BR, Jani. > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8991 > Cc: Matt Roper <matthew.d.roper(a)intel.com> > Cc: Andrzej Hajda <andrzej.hajda(a)intel.com> > Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> > --- > .../drm/i915/display/intel_display_device.c | 24 ++++++++++++++++--- > 1 file changed, 21 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c > index 8286e79522d1..3d6a262e037f 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_device.c > +++ b/drivers/gpu/drm/i915/display/intel_display_device.c > @@ -724,10 +724,24 @@ static const struct intel_display_device_info xe_lpdp_display = { > BIT(PORT_TC1) | BIT(PORT_TC2) | BIT(PORT_TC3) | BIT(PORT_TC4), > }; > > +/* > + * Separate detection for no display cases to keep the display id array simple. > + * > + * IVB Q requires subvendor and subdevice matching to differentiate from IVB D > + * GT2 server. > + */ > +static bool has_no_display(struct pci_dev *pdev) > +{ > + static const struct pci_device_id ids[] = { > + INTEL_IVB_Q_IDS(0), > + {} > + }; > + > + return pci_match_id(ids, pdev); > +} > + > #undef INTEL_VGA_DEVICE > -#undef INTEL_QUANTA_VGA_DEVICE > #define INTEL_VGA_DEVICE(id, info) { id, info } > -#define INTEL_QUANTA_VGA_DEVICE(info) { 0x16a, info } > > static const struct { > u32 devid; > @@ -752,7 +766,6 @@ static const struct { > INTEL_IRONLAKE_M_IDS(&ilk_m_display), > INTEL_SNB_D_IDS(&snb_display), > INTEL_SNB_M_IDS(&snb_display), > - INTEL_IVB_Q_IDS(NULL), /* must be first IVB in list */ > INTEL_IVB_M_IDS(&ivb_display), > INTEL_IVB_D_IDS(&ivb_display), > INTEL_HSW_IDS(&hsw_display), > @@ -837,6 +850,11 @@ intel_display_device_probe(struct drm_i915_private *i915, bool has_gmdid, > if (has_gmdid) > return probe_gmdid_display(i915, gmdid_ver, gmdid_rel, gmdid_step); > > + if (has_no_display(pdev)) { > + drm_dbg_kms(&i915->drm, "Device doesn't have display\n"); > + return &no_display; > + } > + > for (i = 0; i < ARRAY_SIZE(intel_display_ids); i++) { > if (intel_display_ids[i].devid == pdev->device) > return intel_display_ids[i].info; -- Jani Nikula, Intel Open Source Graphics Center

1 year, 5 months

2
1
0 0

[PATCH v2] media: vcodec: Fix potential array out-of-bounds in encoder queue_setup

by Wei Chen

variable *nplanes is provided by user via system call argument. The possible value of q_data->fmt->num_planes is 1-3, while the value of *nplanes can be 1-8. The array access by index i can cause array out-of-bounds. Fix this bug by checking *nplanes against the array size. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Signed-off-by: Wei Chen <harperchen1110(a)gmail.com> Cc: stable(a)vger.kernel.org --- Changes in v2: - Add Fixes tag and CC stable email address - Change the title to be more expressive drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c index 9ff439a50f53..9e8817863cb8 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c @@ -821,6 +821,8 @@ static int vb2ops_venc_queue_setup(struct vb2_queue *vq, return -EINVAL; if (*nplanes) { + if (*nplanes != q_data->fmt->num_planes) + return -EINVAL; for (i = 0; i < *nplanes; i++) if (sizes[i] < q_data->sizeimage[i]) return -EINVAL; -- 2.25.1

1 year, 5 months

5
4
0 0

RE: lists Learning, Training, Talent decision makers

by Julia Anderson

Hi, Just wanted to make sure you received my last email regarding a customized list of Learning, Training, Talent Development, Corporate Training etc contacts. I’m looking to find the right person who looks after your prospecting and lead generation. We help companies grow sales with our highly targeted email lists. Please let us know your target industries and job titles so we can send you the numbers of contacts. Regards, Julia On Tue, 21-06-2023 11:43 AM, Julia Anderson wrote: Hi, Would you be interested in reaching out to top level decisions makers to promote/sell your services? Learning/Training/Talent Development CVD Human Resource CVD Learning Corporate Training Meeting & Events Owners, CEO, Presidents etc We would be happy to customize your list accordingly for any other requirements that you have. Industries: Information Technology |Finance |Advertising & Marketing |Construction and Real estate |Charity and NGO’s |Education |Publishing |Retail | Consumer | Manufacturing |Government & public agencies |Electronics and Telecommunications |Industry associations |Healthcare | Hospitality |Legal Services |Food & Beverages |Media & Entertainment |Energy and chemicals |Aerospace and Defense |Transportation and Logistics ETC. Appreciate your response. Regards, Julia Julia Anderson | Marketing Consultant Reply only opt-out in the subject line to remove from the mailing list.

1 year, 5 months

1
0
0 0

WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c in 5.4.252 kernel

by RAJESH DASARI

Hi , We are noticing the below warning in the latest 5.4.252 kernel bootup logs. WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:878 get_xsave_addr+0x83/0x90 and relevant call trace in the logs , after updating to kernel 5.4.252. I see that issue is due to this commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… This is seen in the qemu instance which is emulating the host cpu and was deployed on Intel(R) Xeon(R) Gold 5218 processor. I revert the commit and there is no WARNING and call trace in the logs , Is this issue already reported and a fix is available? Could you please provide your inputs. Regards, Rajesh.

1 year, 5 months

2
2
0 0

Success! Your order is on its way Registered Shipping details Preparing for shipment Satisfied

by Approval Notice Send

Good evening stable(a)vger.kernel.org Please view the order-invoice #478274 Thanks a lots

1 year, 5 months

1
0
0 0

[PATCH v2] blk-crypto: dynamically allocate fallback profile

by Sweet Tea Dorminy

blk_crypto_profile_init() calls lockdep_register_key(), which warns and does not register if the provided memory is a static object. blk-crypto-fallback currently has a static blk_crypto_profile and calls blk_crypto_profile_init() thereupon, resulting in the warning and failure to register. Fortunately it is simple enough to use a dynamically allocated profile and make lockdep function correctly. Fixes: 2fb48d88e77f ("blk-crypto: use dynamic lock class for blk_crypto_profile::lock") Cc: stable(a)vger.kernel.org Signed-off-by: Sweet Tea Dorminy <sweettea-kernel(a)dorminy.me> --- v2: reworded commit message, fixed Fixes tag, as pointed out by Eric Biggers. block/blk-crypto-fallback.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c index ad9844c5b40c..de94e9bffec6 100644 --- a/block/blk-crypto-fallback.c +++ b/block/blk-crypto-fallback.c @@ -78,7 +78,7 @@ static struct blk_crypto_fallback_keyslot { struct crypto_skcipher *tfms[BLK_ENCRYPTION_MODE_MAX]; } *blk_crypto_keyslots; -static struct blk_crypto_profile blk_crypto_fallback_profile; +static struct blk_crypto_profile *blk_crypto_fallback_profile; static struct workqueue_struct *blk_crypto_wq; static mempool_t *blk_crypto_bounce_page_pool; static struct bio_set crypto_bio_split; @@ -292,7 +292,7 @@ static bool blk_crypto_fallback_encrypt_bio(struct bio **bio_ptr) * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for * this bio's algorithm and key. */ - blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile, + blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile, bc->bc_key, &slot); if (blk_st != BLK_STS_OK) { src_bio->bi_status = blk_st; @@ -395,7 +395,7 @@ static void blk_crypto_fallback_decrypt_bio(struct work_struct *work) * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for * this bio's algorithm and key. */ - blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile, + blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile, bc->bc_key, &slot); if (blk_st != BLK_STS_OK) { bio->bi_status = blk_st; @@ -499,7 +499,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr) return false; } - if (!__blk_crypto_cfg_supported(&blk_crypto_fallback_profile, + if (!__blk_crypto_cfg_supported(blk_crypto_fallback_profile, &bc->bc_key->crypto_cfg)) { bio->bi_status = BLK_STS_NOTSUPP; return false; @@ -526,7 +526,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr) int blk_crypto_fallback_evict_key(const struct blk_crypto_key *key) { - return __blk_crypto_evict_key(&blk_crypto_fallback_profile, key); + return __blk_crypto_evict_key(blk_crypto_fallback_profile, key); } static bool blk_crypto_fallback_inited; @@ -534,29 +534,32 @@ static int blk_crypto_fallback_init(void) { int i; int err; - struct blk_crypto_profile *profile = &blk_crypto_fallback_profile; if (blk_crypto_fallback_inited) return 0; get_random_bytes(blank_key, BLK_CRYPTO_MAX_KEY_SIZE); + blk_crypto_fallback_profile = + kzalloc(sizeof(*blk_crypto_fallback_profile), GFP_KERNEL); + err = bioset_init(&crypto_bio_split, 64, 0, 0); if (err) goto out; - err = blk_crypto_profile_init(profile, blk_crypto_num_keyslots); + err = blk_crypto_profile_init(blk_crypto_fallback_profile, + blk_crypto_num_keyslots); if (err) goto fail_free_bioset; err = -ENOMEM; - profile->ll_ops = blk_crypto_fallback_ll_ops; - profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE; + blk_crypto_fallback_profile->ll_ops = blk_crypto_fallback_ll_ops; + blk_crypto_fallback_profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE; /* All blk-crypto modes have a crypto API fallback. */ for (i = 0; i < BLK_ENCRYPTION_MODE_MAX; i++) - profile->modes_supported[i] = 0xFFFFFFFF; - profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0; + blk_crypto_fallback_profile->modes_supported[i] = 0xFFFFFFFF; + blk_crypto_fallback_profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0; blk_crypto_wq = alloc_workqueue("blk_crypto_wq", WQ_UNBOUND | WQ_HIGHPRI | @@ -597,7 +600,7 @@ static int blk_crypto_fallback_init(void) fail_free_wq: destroy_workqueue(blk_crypto_wq); fail_destroy_profile: - blk_crypto_profile_destroy(profile); + blk_crypto_profile_destroy(blk_crypto_fallback_profile); fail_free_bioset: bioset_exit(&crypto_bio_split); out: -- 2.41.0

1 year, 5 months

5
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023