March 2021 - Linux-stable-mirror

[PATCH] drm/i915: Don't zero out the Y plane's watermarks

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Don't zero out the watermarks for the Y plane since we've already computed them when computing the UV plane's watermarks (since the UV plane always appears before ethe Y plane when iterating through the planes). This leads to allocating no DDB for the Y plane since .min_ddb_alloc also gets zeroed. And that of course leads to underruns when scanning out planar formats. We really need to re-enable the pre-merge pixel format tests or else I'll just keep breaking this stuff... Cc: stable(a)vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com> Fixes: dbf71381d733 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index b2aede2be89d..49c19acdb7c6 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5511,12 +5511,12 @@ static int icl_build_plane_wm(struct intel_crtc_state *crtc_state, struct skl_plane_wm *wm = &crtc_state->wm.skl.raw.planes[plane_id]; int ret; - memset(wm, 0, sizeof(*wm)); - /* Watermarks calculated in master */ if (plane_state->planar_slave) return 0; + memset(wm, 0, sizeof(*wm)); + if (plane_state->planar_linked_plane) { const struct drm_framebuffer *fb = plane_state->hw.fb; enum plane_id y_plane_id = plane_state->planar_linked_plane->id; -- 2.26.2

3 years, 8 months

2
1
0 0

[PATCH for-rc 3/4] IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS

by dennis.dalessandro＠cornelisnetworks.com

From: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> A panic can result when AIP is enabled: [ 8.644728] BUG: unable to handle kernel NULL pointer dereference at 000000000000000 [ 8.657708] PGD 0 P4D 0 [ 8.664488] Oops: 0000 1 SMP PTI [ 8.672190] CPU: 70 PID: 981 Comm: systemd-udevd Tainted: G OE --------- - - 4.18.0-240.el8.x86_64 #1 [ 8.687916] Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.01.01.0005.101720141054 10/17/2014 [ 8.703340] RIP: 0010:__bitmap_and+0x1b/0x70 [ 8.741702] RSP: 0018:ffff99aa0845f9f0 EFLAGS: 00010246 [ 8.751757] RAX: 0000000000000000 RBX: ffff8d5a6fc18000 RCX: 0000000000000048 [ 8.764203] RDX: 0000000000000000 RSI: ffffffffc06336f0 RDI: ffff8d5a8fa67750 [ 8.776990] RBP: 0000000000000079 R08: 0000000fffffffff R09: 0000000000000000 [ 8.789768] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffffc06336f0 [ 8.802007] R13: 00000000000000a0 R14: ffff8d5a6fc18000 R15: 0000000000000003 [ 8.814317] FS: 00007fec137a5980(0000) GS:ffff8d5a9fa80000(0000) knlGS:0000000000000000 [ 8.827629] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.838309] CR2: 0000000000000000 CR3: 0000000a04b48002 CR4: 00000000001606e0 [ 8.850502] Call Trace: [ 8.857950] hfi1_num_netdev_contexts+0x7c/0x110 [hfi1] [ 8.868295] hfi1_init_dd+0xd7f/0x1a90 [hfi1] [ 8.877681] ? pci_bus_read_config_dword+0x49/0x70 [ 8.887567] ? pci_mmcfg_read+0x3e/0xe0 [ 8.896797] do_init_one.isra.18+0x336/0x640 [hfi1] [ 8.906958] local_pci_probe+0x41/0x90 [ 8.915784] pci_device_probe+0x105/0x1c0 [ 8.925002] really_probe+0x212/0x440 [ 8.933687] driver_probe_device+0x49/0xc0 [ 8.942918] device_driver_attach+0x50/0x60 [ 8.952553] __driver_attach+0x61/0x130 [ 8.961553] ? device_driver_attach+0x60/0x60 [ 8.971122] bus_for_each_dev+0x77/0xc0 [ 8.979912] ? klist_add_tail+0x3b/0x70 [ 8.988886] bus_add_driver+0x14d/0x1e0 [ 8.998175] ? dev_init+0x10b/0x10b [hfi1] [ 9.007531] driver_register+0x6b/0xb0 [ 9.016757] ? dev_init+0x10b/0x10b [hfi1] [ 9.026220] hfi1_mod_init+0x1e6/0x20a [hfi1] [ 9.035601] do_one_initcall+0x46/0x1c3 [ 9.043958] ? free_unref_page_commit+0x91/0x100 [ 9.053460] ? _cond_resched+0x15/0x30 [ 9.062426] ? kmem_cache_alloc_trace+0x140/0x1c0 [ 9.071982] do_init_module+0x5a/0x220 [ 9.080574] load_module+0x14b4/0x17e0 [ 9.088911] ? __do_sys_finit_module+0xa8/0x110 [ 9.098231] __do_sys_finit_module+0xa8/0x110 [ 9.107307] do_syscall_64+0x5b/0x1a0 The issue happens when pcibus_to_node() returns NO_NUMA_NODE. Fix this issue by moving the initialization of dd->node to hfi1_devdata allocation and remove the other pcibus_to_node() calls in the probe path and use dd->node instead. Affinity logic is adjusted to use a new field dd->affinity_entry as a guard instead of dd->node. Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev") Cc: stable(a)vger.kernel.org Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)cornelisnetworks.com> --- drivers/infiniband/hw/hfi1/affinity.c | 21 +++++---------------- drivers/infiniband/hw/hfi1/hfi.h | 1 + drivers/infiniband/hw/hfi1/init.c | 10 +++++++++- drivers/infiniband/hw/hfi1/netdev_rx.c | 3 +-- 4 files changed, 16 insertions(+), 19 deletions(-) diff --git a/drivers/infiniband/hw/hfi1/affinity.c b/drivers/infiniband/hw/hfi1/affinity.c index 2a91b8d..04b1e8f 100644 --- a/drivers/infiniband/hw/hfi1/affinity.c +++ b/drivers/infiniband/hw/hfi1/affinity.c @@ -632,22 +632,11 @@ static void _dev_comp_vect_cpu_mask_clean_up(struct hfi1_devdata *dd, */ int hfi1_dev_affinity_init(struct hfi1_devdata *dd) { - int node = pcibus_to_node(dd->pcidev->bus); struct hfi1_affinity_node *entry; const struct cpumask *local_mask; int curr_cpu, possible, i, ret; bool new_entry = false; - /* - * If the BIOS does not have the NUMA node information set, select - * NUMA 0 so we get consistent performance. - */ - if (node < 0) { - dd_dev_err(dd, "Invalid PCI NUMA node. Performance may be affected\n"); - node = 0; - } - dd->node = node; - local_mask = cpumask_of_node(dd->node); if (cpumask_first(local_mask) >= nr_cpu_ids) local_mask = topology_core_cpumask(0); @@ -660,7 +649,7 @@ int hfi1_dev_affinity_init(struct hfi1_devdata *dd) * create an entry in the global affinity structure and initialize it. */ if (!entry) { - entry = node_affinity_allocate(node); + entry = node_affinity_allocate(dd->node); if (!entry) { dd_dev_err(dd, "Unable to allocate global affinity node\n"); @@ -751,6 +740,7 @@ int hfi1_dev_affinity_init(struct hfi1_devdata *dd) if (new_entry) node_affinity_add_tail(entry); + dd->affinity_entry = entry; mutex_unlock(&node_affinity.lock); return 0; @@ -766,10 +756,9 @@ void hfi1_dev_affinity_clean_up(struct hfi1_devdata *dd) { struct hfi1_affinity_node *entry; - if (dd->node < 0) - return; - mutex_lock(&node_affinity.lock); + if (!dd->affinity_entry) + goto unlock; entry = node_affinity_lookup(dd->node); if (!entry) goto unlock; @@ -780,8 +769,8 @@ void hfi1_dev_affinity_clean_up(struct hfi1_devdata *dd) */ _dev_comp_vect_cpu_mask_clean_up(dd, entry); unlock: + dd->affinity_entry = NULL; mutex_unlock(&node_affinity.lock); - dd->node = NUMA_NO_NODE; } /* diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h index 024ef6e..d341b8a 100644 --- a/drivers/infiniband/hw/hfi1/hfi.h +++ b/drivers/infiniband/hw/hfi1/hfi.h @@ -1403,6 +1403,7 @@ struct hfi1_devdata { spinlock_t irq_src_lock; int vnic_num_vports; struct net_device *dummy_netdev; + struct hfi1_affinity_node *affinity_entry; /* Keeps track of IPoIB RSM rule users */ atomic_t ipoib_rsm_usr_num; diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c index e4f8db4..6d03aa0 100644 --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -1277,7 +1277,6 @@ static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev, dd->pport = (struct hfi1_pportdata *)(dd + 1); dd->pcidev = pdev; pci_set_drvdata(pdev, dd); - dd->node = NUMA_NO_NODE; ret = xa_alloc_irq(&hfi1_dev_table, &dd->unit, dd, xa_limit_32b, GFP_KERNEL); @@ -1287,6 +1286,15 @@ static struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev, goto bail; } rvt_set_ibdev_name(&dd->verbs_dev.rdi, "%s_%d", class_name(), dd->unit); + /* + * If the BIOS does not have the NUMA node information set, select + * NUMA 0 so we get consistent performance. + */ + dd->node = pcibus_to_node(pdev->bus); + if (dd->node == NUMA_NO_NODE) { + dd_dev_err(dd, "Invalid PCI NUMA node. Performance may be affected\n"); + dd->node = 0; + } /* * Initialize all locks for the device. This needs to be as early as diff --git a/drivers/infiniband/hw/hfi1/netdev_rx.c b/drivers/infiniband/hw/hfi1/netdev_rx.c index cec02e8..c1fa53d 100644 --- a/drivers/infiniband/hw/hfi1/netdev_rx.c +++ b/drivers/infiniband/hw/hfi1/netdev_rx.c @@ -173,8 +173,7 @@ u32 hfi1_num_netdev_contexts(struct hfi1_devdata *dd, u32 available_contexts, return 0; } - cpumask_and(node_cpu_mask, cpu_mask, - cpumask_of_node(pcibus_to_node(dd->pcidev->bus))); + cpumask_and(node_cpu_mask, cpu_mask, cpumask_of_node(dd->node)); available_cpus = cpumask_weight(node_cpu_mask); -- 1.8.3.1

3 years, 8 months

2
1
0 0

[PATCH] ubifs: fix read fail but return ok

by wangfangpeng

do_readpage() may return err, but ubifs_readpage() always return ok. The vfs will ignore the err happen in ubifs. Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system") Cc: <stable(a)vger.kernel.org> #v2.6.27 Signed-off-by: wangfangpeng <wangfangpeng1(a)huawei.com> --- fs/ubifs/file.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 0e4b4be3aa26..001feec1d415 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -892,11 +892,13 @@ static int ubifs_bulk_read(struct page *page) static int ubifs_readpage(struct file *file, struct page *page) { + int ret; + if (ubifs_bulk_read(page)) return 0; - do_readpage(page); + ret = do_readpage(page); unlock_page(page); - return 0; + return ret; } static int do_writepage(struct page *page, int len) -- 2.12.3

3 years, 8 months

2
1
0 0

[PATCH AUTOSEL 5.10 01/33] ARM: dts: am33xx: add aliases for mmc interfaces

by Sasha Levin

From: Mans Rullgard <mans(a)mansr.com> [ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ] Without DT aliases, the numbering of mmc interfaces is unpredictable. Adding them makes it possible to refer to devices consistently. The popular suggestion to use UUIDs obviously doesn't work with a blank device fresh from the factory. See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") for more discussion. Signed-off-by: Mans Rullgard <mans(a)mansr.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/boot/dts/am33xx.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 4c2298024137..f09a61cac2dc 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -40,6 +40,9 @@ aliases { ethernet1 = &cpsw_emac1; spi0 = &spi0; spi1 = &spi1; + mmc0 = &mmc1; + mmc1 = &mmc2; + mmc2 = &mmc3; }; cpus { -- 2.30.1

3 years, 8 months

2
34
0 0

Re: [PATCH] Revert "iommu/amd: Fix performance counter initialization"

by Paul Menzel

Dear Jörg, dear Suravee, Am 03.03.21 um 15:10 schrieb Alexander Monakov: > On Wed, 3 Mar 2021, Suravee Suthikulpanit wrote: > >>> Additionally, alternative proposed solutions [1] were not considered or >>> discussed. >>> >>> [1]:https://lore.kernel.org/linux-iommu/alpine.LNX.2.20.13.2006030935570.318… >> >> This check has been introduced early on to detect a HW issue for >> certain platforms in the past, where the performance counters are not >> accessible and would result in silent failure when try to use the >> counters. This is considered legacy code, and can be removed if we >> decide to no longer provide sanity check for such case. > > Which platforms? There is no such information in the code or the commit > messages that introduced this. > > According to AMD's documentation, presence of performance counters is > indicated by "PCSup" bit in the "EFR" register. I don't think the driver > should second-guess that. If there were platforms where the CPU or the > firmware lied to the OS (EFR[PCSup] was 1, but counters were not present), > I think that should have been handled in a more explicit manner, e.g. > via matching broken CPUs by cpuid. Suravee, could you please answer the questions? Jörg, I know you are probably busy, but the patch was applied to the stable series (v5.11.7). There are still too many question open regarding the patch, and Suravee has not yet addressed the comments. It’d be great, if you could revert it. Kind regards, Paul Could you please

3 years, 8 months

2
1
0 0

[PATCH 1/2] lib/scatterlist: Fix NULL pointer deference

by Ricardo Ribalda

When sg_alloc_table_from_pages is called with n_pages = 0, we write in a non-allocated page. Fix it by checking early the error condition. [ 7.666801] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 7.667487] #PF: supervisor read access in kernel mode [ 7.667970] #PF: error_code(0x0000) - not-present page [ 7.668448] PGD 0 P4D 0 [ 7.668690] Oops: 0000 [#1] SMP NOPTI [ 7.669037] CPU: 0 PID: 184 Comm: modprobe Not tainted 5.11.0+ #2 [ 7.669606] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 7.670378] RIP: 0010:__sg_alloc_table_from_pages+0x2c5/0x4a0 [ 7.670924] Code: c9 01 48 c7 40 08 00 00 00 00 48 89 08 8b 47 0c 41 8d 44 00 ff 89 47 0c 48 81 fa 00 f0 ff ff 0f 87 d4 01 00 00 49 8b 16 89 d8 <4a> 8b 74 fd 00 4c 89 d1 44 29 f8 c1 e0 0c 44 29 d8 4c 39 d0 48 0f [ 7.672643] RSP: 0018:ffffba1e8028fb30 EFLAGS: 00010287 [ 7.673133] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000002 [ 7.673791] RDX: 0000000000000002 RSI: ffffffffada6d0ba RDI: ffff9afe01fff820 [ 7.674448] RBP: 0000000000000010 R08: 0000000000000001 R09: 0000000000000001 [ 7.675100] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 7.675754] R13: 00000000fffff000 R14: ffff9afe01fff800 R15: 0000000000000000 [ 7.676409] FS: 00007fb0f448f540(0000) GS:ffff9afe07a00000(0000) knlGS:0000000000000000 [ 7.677151] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.677681] CR2: 0000000000000010 CR3: 0000000002184001 CR4: 0000000000370ef0 [ 7.678342] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7.679019] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 7.680349] Call Trace: [ 7.680605] ? device_add+0x146/0x810 [ 7.681021] sg_alloc_table_from_pages+0x11/0x30 [ 7.681511] vb2_dma_sg_alloc+0x162/0x280 [videobuf2_dma_sg] Cc: stable(a)vger.kernel.org Fixes: efc42bc98058 ("scatterlist: add sg_alloc_table_from_pages function") Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- lib/scatterlist.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/scatterlist.c b/lib/scatterlist.c index a59778946404..1e83b6a3d930 100644 --- a/lib/scatterlist.c +++ b/lib/scatterlist.c @@ -435,6 +435,9 @@ struct scatterlist *__sg_alloc_table_from_pages(struct sg_table *sgt, unsigned int added_nents = 0; struct scatterlist *s = prv; + if (n_pages == 0) + return ERR_PTR(-EINVAL); + /* * The algorithm below requires max_segment to be aligned to PAGE_SIZE * otherwise it can overshoot. -- 2.30.1.766.gb4fecdf3b7-goog

3 years, 8 months

1
1
0 0

Re: [PATCH] media: em28xx: fix memory leak

by Muhammad Usama Anjum

On Wed, 2021-03-24 at 23:07 +0500, Muhammad Usama Anjum wrote: > If some error occurs, URB buffers should also be freed. If they aren't > freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB > buffers as dvb is set to NULL. The function in which error occurs should > do all the cleanup for the allocations it had done. > > Tested the patch with the reproducer provided by syzbot. This patch > fixes the memleak. > > Reported-by: syzbot+889397c820fa56adf25d(a)syzkaller.appspotmail.com > Signed-off-by: Muhammad Usama Anjum <musamaanjum(a)gmail.com> > --- > Resending the same path as some email addresses were missing from the > earlier email. > > syzbot found the following issue on: > > HEAD commit: 1a4431a5 Merge tag 'afs-fixes-20210315' of git://git.kerne.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11013a7cd00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=ff6b8b2e9d5a1227 > dashboard link: https://syzkaller.appspot.com/bug?extid=889397c820fa56adf25d > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1559ae3ad00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=176985c6d00000 > > drivers/media/usb/em28xx/em28xx-dvb.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c > index 526424279637..471bd74667e3 100644 > --- a/drivers/media/usb/em28xx/em28xx-dvb.c > +++ b/drivers/media/usb/em28xx/em28xx-dvb.c > @@ -2010,6 +2010,7 @@ static int em28xx_dvb_init(struct em28xx *dev) > return result; > > out_free: > + em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE); > kfree(dvb); > dev->dvb = NULL; > goto ret; I'd received the following notice and waiting for the review: On Thu, 2021-03-25 at 09:06 +0000, Patchwork wrote: > Hello, > > The following patch (submitted by you) has been updated in Patchwork: > > * linux-media: media: em28xx: fix memory leak > - http://patchwork.linuxtv.org/project/linux-media/patch/20210324180753.GA410… > - for: Linux Media kernel patches > was: New > now: Under Review > > This email is a notification only - you do not need to respond. > > Happy patchworking. > Thanks, Usama

3 years, 8 months

3
3
0 0

[PATCH] rfkill: revert back to old userspace API by default

by Johannes Berg

From: Johannes Berg <johannes.berg(a)intel.com> Recompiling with the new extended version of struct rfkill_event broke systemd in *two* ways: - It used "sizeof(struct rfkill_event)" to read the event, but then complained if it actually got something != 8, this broke it on new kernels (that include the updated API); - It used sizeof(struct rfkill_event) to write a command, but didn't implement the intended expansion protocol where the kernel returns only how many bytes it accepted, and errored out due to the unexpected smaller size on kernels that didn't include the updated API. Even though systemd has now been fixed, that fix may not be always deployed, and other applications could potentially have similar issues. As such, in the interest of avoiding regressions, revert the default API "struct rfkill_event" back to the original size. Instead, add a new "struct rfkill_event_ext" that extends it by the new field, and even more clearly document that applications should be prepared for extensions in two ways: * write might only accept fewer bytes on older kernels, and will return how many to let userspace know which data may have been ignored; * read might return anything between 8 (the original size) and whatever size the application sized its buffer at, indicating how much event data was supported by the kernel. Perhaps that will help avoid such issues in the future and we won't have to come up with another version of the struct if we ever need to extend it again. Applications that want to take advantage of the new field will have to be modified to use struct rfkill_event_ext instead now, which comes with the danger of them having already been updated to use it from 'struct rfkill_event', but I found no evidence of that, and it's still relatively new. Cc: stable(a)vger.kernel.org # 5.11 Reported-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- include/uapi/linux/rfkill.h | 80 +++++++++++++++++++++++++++++++------ net/rfkill/core.c | 7 ++-- 2 files changed, 72 insertions(+), 15 deletions(-) diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h index 03e8af87b364..9b77cfc42efa 100644 --- a/include/uapi/linux/rfkill.h +++ b/include/uapi/linux/rfkill.h @@ -86,34 +86,90 @@ enum rfkill_hard_block_reasons { * @op: operation code * @hard: hard state (0/1) * @soft: soft state (0/1) + * + * Structure used for userspace communication on /dev/rfkill, + * used for events from the kernel and control to the kernel. + */ +struct rfkill_event { + __u32 idx; + __u8 type; + __u8 op; + __u8 soft; + __u8 hard; +} __attribute__((packed)); + +/** + * struct rfkill_event_ext - events for userspace on /dev/rfkill + * @idx: index of dev rfkill + * @type: type of the rfkill struct + * @op: operation code + * @hard: hard state (0/1) + * @soft: soft state (0/1) * @hard_block_reasons: valid if hard is set. One or several reasons from * &enum rfkill_hard_block_reasons. * * Structure used for userspace communication on /dev/rfkill, * used for events from the kernel and control to the kernel. + * + * See the extensibility docs below. */ -struct rfkill_event { +struct rfkill_event_ext { __u32 idx; __u8 type; __u8 op; __u8 soft; __u8 hard; + + /* + * older kernels will accept/send only up to this point, + * and if extended further up to any chunk marked below + */ + __u8 hard_block_reasons; } __attribute__((packed)); -/* - * We are planning to be backward and forward compatible with changes - * to the event struct, by adding new, optional, members at the end. - * When reading an event (whether the kernel from userspace or vice - * versa) we need to accept anything that's at least as large as the - * version 1 event size, but might be able to accept other sizes in - * the future. +/** + * DOC: Extensibility + * + * Originally, we had planned to allow backward and forward compatible + * changes by just adding fields at the end of the structure that are + * then not reported on older kernels on read(), and not written to by + * older kernels on write(), with the kernel reporting the size it did + * accept as the result. + * + * This would have allowed userspace to detect on read() and write() + * which kernel structure version it was dealing with, and if was just + * recompiled it would have gotten the new fields, but obviously not + * accessed them, but things should've continued to work. + * + * Unfortunately, while actually exercising this mechanism to add the + * hard block reasons field, we found that userspace (notably systemd) + * did all kinds of fun things not in line with this scheme: + * + * 1. treat the (expected) short writes as an error; + * 2. ask to read sizeof(struct rfkill_event) but then compare the + * actual return value to RFKILL_EVENT_SIZE_V1 and treat any + * mismatch as an error. + * + * As a consequence, just recompiling with a new struct version caused + * things to no longer work correctly on old and new kernels. + * + * Hence, we've rolled back &struct rfkill_event to the original version + * and added &struct rfkill_event_ext. This effectively reverts to the + * old behaviour for all userspace, unless it explicitly opts in to the + * rules outlined here by using the new &struct rfkill_event_ext. + * + * Userspace using &struct rfkill_event_ext must adhere to the following + * rules * - * One exception is the kernel -- we already have two event sizes in - * that we've made the 'hard' member optional since our only option - * is to ignore it anyway. + * 1. accept short writes, optionally using them to detect that it's + * running on an older kernel; + * 2. accept short reads, knowing that this means it's running on an + * older kernel; + * 3. treat reads that are as long as requested as acceptable, not + * checking against RFKILL_EVENT_SIZE_V1 or such. */ -#define RFKILL_EVENT_SIZE_V1 8 +#define RFKILL_EVENT_SIZE_V1 sizeof(struct rfkill_event) /* ioctl for turning off rfkill-input (if present) */ #define RFKILL_IOC_MAGIC 'R' diff --git a/net/rfkill/core.c b/net/rfkill/core.c index 68d6ef9e59fc..ac15a944573f 100644 --- a/net/rfkill/core.c +++ b/net/rfkill/core.c @@ -69,7 +69,7 @@ struct rfkill { struct rfkill_int_event { struct list_head list; - struct rfkill_event ev; + struct rfkill_event_ext ev; }; struct rfkill_data { @@ -253,7 +253,8 @@ static void rfkill_global_led_trigger_unregister(void) } #endif /* CONFIG_RFKILL_LEDS */ -static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill, +static void rfkill_fill_event(struct rfkill_event_ext *ev, + struct rfkill *rfkill, enum rfkill_operation op) { unsigned long flags; @@ -1237,7 +1238,7 @@ static ssize_t rfkill_fop_write(struct file *file, const char __user *buf, size_t count, loff_t *pos) { struct rfkill *rfkill; - struct rfkill_event ev; + struct rfkill_event_ext ev; int ret; /* we don't need the 'hard' variable but accept it */ -- 2.30.2

3 years, 8 months

2
1
0 0

stable/linux-5.10.y - 5.10.27

by Patrick Mccormick

JOB ID : 29cbaf7acada1e4b67b23f0841955606b597319a JOB LOG : /home/ci-hypervisor/avocado/job-results/job-2021-03-30T18.59-29cbaf7/job.log (1/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_nptl: PASS (6.21 s) (2/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_math: PASS (2.01 s) (3/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_hugetlb: PASS (0.08 s) (4/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_ipc: PASS (20.08 s) (5/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_uevent: PASS (0.06 s) (6/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_containers: PASS (36.90 s) (7/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_filecaps: PASS (0.11 s) (8/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/ltp.py:LTP.test_hyperthreading: PASS (71.20 s) (9/9) /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/kpatch.sh: PASS (13.63 s) RESULTS : PASS 9 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0

3 years, 8 months

2
2
0 0

[PATCH 4.14 0/5] memcontrol follow-up patches

by Frank van der Linden

During the 4.14.214 timeframe, we submitted the following cherry-picks/backports: mm: memcontrol: eliminate raw access to stat and event counters mm: memcontrol: implement lruvec stat functions on top of each other mm: memcontrol: fix excessive complexity in memory.stat reporting They were accepted and part of linux-4.14.y since 4.14.214. These were valid fixes, but needed a few follow-ups, or regressions could occur. The regressions are described in the follow-up commits. This 4.14 series adds these follow-ups, fixing these regressions. Apologies for missing these commits. Two of them even had the proper Fixes tags. The other two didn't, but still mentioned the original commit in the description, so we should have caught them. They are all clean cherry-picks, with the exception of "mm: fix oom_kill event handling", which needed minor contextual massaging. ---- Aaron Lu (1): mem_cgroup: make sure moving_account, move_lock_task and stat_cpu in the same cacheline Greg Thelen (1): mm: writeback: use exact memcg dirty counts Johannes Weiner (2): mm: memcontrol: fix NR_WRITEBACK leak in memcg and system stats mm: memcg: make sure memory.events is uptodate when waking pollers Roman Gushchin (1): mm: fix oom_kill event handling include/linux/memcontrol.h | 111 ++++++++++++++++++++++++++----------- mm/memcontrol.c | 54 ++++++++++++------ mm/oom_kill.c | 2 +- mm/vmscan.c | 2 +- 4 files changed, 118 insertions(+), 51 deletions(-)

3 years, 8 months

3
7
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2021