February 2023 - Linux-stable-mirror

[PATCH v1 1/2] gpio: Restrict usage of GPIO chip irq members before initialization

by Asmaa Mnebhi

From: Shreeya Patel <shreeya.patel(a)collabora.com> BugLink: https://bugs.launchpad.net/bugs/2007581 GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized. Signed-off-by: Shreeya Patel <shreeya.patel(a)collabora.com> Cc: stable(a)vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> (backported from commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320) Signed-off-by: Asmaa Mnebhi <asmaa(a)nvidia.com> --- drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ include/linux/gpio/driver.h | 9 +++++++++ 2 files changed, 28 insertions(+) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index abdf448b11a3..e4d47e00c392 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -2146,6 +2146,16 @@ static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) { struct irq_domain *domain = chip->irq.domain; +#ifdef CONFIG_GPIOLIB_IRQCHIP + /* + * Avoid race condition with other code, which tries to lookup + * an IRQ before the irqchip has been properly registered, + * i.e. while gpiochip is still being brought up. + */ + if (!chip->irq.initialized) + return -EPROBE_DEFER; +#endif + if (!gpiochip_irqchip_irq_valid(chip, offset)) return -ENXIO; @@ -2321,6 +2331,15 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, acpi_gpiochip_request_interrupts(gpiochip); + /* + * Using barrier() here to prevent compiler from reordering + * gc->irq.initialized before initialization of above + * GPIO chip irq members. + */ + barrier(); + + gpiochip->irq.initialized = true; + return 0; } diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h index 5dd9c982e2cb..15418caf76fc 100644 --- a/include/linux/gpio/driver.h +++ b/include/linux/gpio/driver.h @@ -201,6 +201,15 @@ struct gpio_irq_chip { */ bool threaded; + /** + * @initialized: + * + * Flag to track GPIO chip irq member's initialization. + * This flag will make sure GPIO chip irq members are not used + * before they are initialized. + */ + bool initialized; + /** * @init_hw: optional routine to initialize hardware before * an IRQ chip will be added. This is quite useful when -- 2.30.1

1 year, 10 months

1
0
0 0

[PATCH] hugetlb: check for undefined shift on 32 bit architectures

by Mike Kravetz

Users can specify the hugetlb page size in the mmap, shmget and memfd_create system calls. This is done by using 6 bits within the flags argument to encode the base-2 logarithm of the desired page size. The routine hstate_sizelog() uses the log2 value to find the corresponding hugetlb hstate structure. Converting the log2 value (page_size_log) to potential hugetlb page size is the simple statement: 1UL << page_size_log Because only 6 bits are used for page_size_log, the left shift can not be greater than 63. This is fine on 64 bit architectures where a long is 64 bits. However, if a value greater than 31 is passed on a 32 bit architecture (where long is 32 bits) the shift will result in undefined behavior. This was generally not an issue as the result of the undefined shift had to exactly match hugetlb page size to proceed. Recent improvements in runtime checking have resulted in this undefined behavior throwing errors such as reported below. Fix by comparing page_size_log to BITS_PER_LONG before doing shift. Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Link: https://lore.kernel.org/lkml/CA+G9fYuei_Tr-vN9GS7SfFyU1y9hNysnf=PB7kT0=yv4M… Fixes: 42d7395feb56 ("mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB") Cc: <stable(a)vger.kernel.org> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> --- include/linux/hugetlb.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index df6dd624ccfe..8b45720f9475 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -781,7 +781,10 @@ static inline struct hstate *hstate_sizelog(int page_size_log) if (!page_size_log) return &default_hstate; - return size_to_hstate(1UL << page_size_log); + if (page_size_log < BITS_PER_LONG) + return size_to_hstate(1UL << page_size_log); + + return NULL; } static inline struct hstate *hstate_vma(struct vm_area_struct *vma) -- 2.39.1

1 year, 10 months

4
3
0 0

[PATCH 4/4] brd: mark as nowait compatible

by Jens Axboe

By default, non-mq drivers do not support nowait. This causes io_uring to use a slower path as the driver cannot be trust not to block. brd can safely set the nowait flag, as worst case all it does is a NOIO allocation. For io_uring, this makes a substantial difference. Before: submitter=0, tid=453, file=/dev/ram0, node=-1 polled=0, fixedbufs=1/0, register_files=1, buffered=0, QD=128 Engine=io_uring, sq_ring=128, cq_ring=128 IOPS=440.03K, BW=1718MiB/s, IOS/call=32/31 IOPS=428.96K, BW=1675MiB/s, IOS/call=32/32 IOPS=442.59K, BW=1728MiB/s, IOS/call=32/31 IOPS=419.65K, BW=1639MiB/s, IOS/call=32/32 IOPS=426.82K, BW=1667MiB/s, IOS/call=32/31 and after: submitter=0, tid=354, file=/dev/ram0, node=-1 polled=0, fixedbufs=1/0, register_files=1, buffered=0, QD=128 Engine=io_uring, sq_ring=128, cq_ring=128 IOPS=3.37M, BW=13.15GiB/s, IOS/call=32/31 IOPS=3.45M, BW=13.46GiB/s, IOS/call=32/31 IOPS=3.43M, BW=13.42GiB/s, IOS/call=32/32 IOPS=3.43M, BW=13.39GiB/s, IOS/call=32/31 IOPS=3.43M, BW=13.38GiB/s, IOS/call=32/31 or about an 8x in difference. Now that brd is prepared to deal with REQ_NOWAIT reads/writes, mark it as supporting that. Cc: stable(a)vger.kernel.org # 5.10+ Link: https://lore.kernel.org/linux-block/20230203103005.31290-1-p.raghav@samsung… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> --- drivers/block/brd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/brd.c b/drivers/block/brd.c index 6019ef23344f..522530a6ebca 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -418,6 +418,7 @@ static int brd_alloc(int i) /* Tell the block layer that this is not a rotational device */ blk_queue_flag_set(QUEUE_FLAG_NONROT, disk->queue); blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, disk->queue); + blk_queue_flag_set(QUEUE_FLAG_NOWAIT, disk->queue); err = add_disk(disk); if (err) goto out_cleanup_disk; -- 2.39.1

1 year, 10 months

1
0
0 0

Re: Resume after suspend broken, reboots instead on kernel 6.1 onwards x86_64 RTW88

by Linux kernel regression tracking (Thorsten Leemhuis)

[adding Chih-Kang Chang (author), Kalle (committer) and LKML to the list of recipients] [anyone who replies to this: feel free to remove stable(a)vger.kernel.org from the recipients, this is a mainline regression] [TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 09.02.23 20:59, Paul Gover wrote: > Suspend/Resume was working OK on kernel 6.0.13, broken since 6.1.1 > (I've not tried kernels between those, except in the bisect below.) > All subsequent 6,1 kernels exhibit the same behaviour. > > Suspend works OK, but on Resume, there's a flicker, and then it reboots. > Sometimes the screen gets restored to its contents at the time of suspend. but > less than a second later, it starts rebooting. > To reproduce, simply boot, suspend, and resume. > > Git bisect blames RTW88 > commit 6bf3a083407b5d404d70efc3a5ac75b472e5efa9 TWIMC, that's "wifi: rtw88: add flag check before enter or leave IPS" > I'll attach bisect log, dmesg and configs to the bug I've opened > https://bugzilla.kernel.org/show_bug.cgi?id=217016 > > dmesg from the following boot show a hardware error. > It's not there when the system resumes or reboots with 6.0.13, > and if I don't suspend & resume, there are no reported errors. > > The problem occurs under both Wayland and X11, and from the command line via > echo mem>/sys/power.state > > > Vanilla kernels, untainted, compiled with GCC; my system is Gentoo FWIW, but I > do my own kernels direct from a git clone of stable. > > Couldn't find anything similar with Google or the mailing lists. > > **Hardware:** > > HP Laptop 15-bw0xx > AMD A9-9420 RADEON R5, 5 COMPUTE CORES > Stoney [Radeon R2/R3/R4/R5 Graphics] > 4 GB memory > RTL8723DE PCIe adapter > > **Kernel** > > Kernel command line: > psmouse.synaptics_intertouch=1 pcie_aspm=force rdrand=force rootfstype=f2fs > root=LABEL=gentoo > > CONFIG_RTW88=m > CONFIG_RTW88_CORE=m > CONFIG_RTW88_PCI=m > CONFIG_RTW88_8723D=m > # CONFIG_RTW88_8822BE is not set > # CONFIG_RTW88_8822CE is not set > CONFIG_RTW88_8723DE=m > # CONFIG_RTW88_8821CE is not set > # CONFIG_RTW88_DEBUG is not set > # CONFIG_RTW88_DEBUGFS is not set > # CONFIG_RTW89 is not set Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced 6bf3a083407b #regzbot title wifi: rtw88: resume broken (reboot) #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.

1 year, 10 months

2
1
0 0

[PATCH v2 0/2] kprobes: Fix issues related to optkprobe

by Yang Jihong

Fixed optkprobe issues, mainly related to the x86 architecture. Yang Jihong (2): x86/kprobes: Fix __recover_optprobed_insn check optimizing logic x86/kprobes: Fix arch_check_optimized_kprobe check within optimized_kprobe range arch/x86/kernel/kprobes/opt.c | 6 +++--- include/linux/kprobes.h | 2 ++ kernel/kprobes.c | 4 ++-- 3 files changed, 7 insertions(+), 5 deletions(-) -- Changes since v1: - Remove patch1 since there is already a fix patch. - Add "cc stable" and modify comment for patch2. - Use "kprobe_disarmed" instead of "kprobe_disabled" for patch3. - Add fix commmit and "cc stable" for patch3. 2.30.GIT

1 year, 10 months

2
3
0 0

JÓ REGGELT KÍVÁNOK

by SFG Finance

-- Az SFG Finance struktúra pénzügyi segítséget nyújt a világ bármely pontján lakóhellyel rendelkező természetes vagy jogi személynek. Segítségre van szüksége a napi finanszírozási problémák megoldásához? Mennyire van szükséged ? Most vagy soha. Lépjen kapcsolatba finanszírozási csoportunkkal a Facebook Messengeren: https://www.facebook.com/sfg.finances VAGY E-mailben: sg.finance(a)gmail.com

1 year, 10 months

1
0
0 0

[PATCH v2 2/2] drm/i915: Don't use BAR mappings for ring buffers with LLC

by John.C.Harrison＠Intel.com

From: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Direction from hardware is that ring buffers should never be mapped via the BAR on systems with LLC. There are too many caching pitfalls due to the way BAR accesses are routed. So it is safest to just not use it. Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.9+ --- drivers/gpu/drm/i915/gt/intel_ring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c index fb1d2595392ed..8675ec8ead353 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring.c +++ b/drivers/gpu/drm/i915/gt/intel_ring.c @@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ring, struct i915_gem_ww_ctx *ww) if (unlikely(ret)) goto err_unpin; - if (i915_vma_is_map_and_fenceable(vma)) { + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) { addr = (void __force *)i915_vma_pin_iomap(vma); } else { int type = i915_coherent_map_type(vma->vm->i915, vma->obj, false); @@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring *ring) return; i915_vma_unset_ggtt_write(vma); - if (i915_vma_is_map_and_fenceable(vma)) + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) { i915_vma_unpin_iomap(vma); else i915_gem_object_unpin_map(vma->obj); -- 2.39.1

1 year, 10 months

2
2
0 0

[PATCH v2] f2fs: fix uninitialized skipped_gc_rwsem

by Yonggil Song

When f2fs skipped a gc round during victim migration, there was a bug which would skip all upcoming gc rounds unconditionally because skipped_gc_rwsem was not initialized. It fixes the bug by correctly initializing the skipped_gc_rwsem inside the gc loop. Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Signed-off-by: Yonggil Song <yonggil.song(a)samsung.com> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index b22f49a6f128..81d326abaac1 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1786,8 +1786,8 @@ int f2fs_gc(struct f2fs_sb_info *sbi, struct f2fs_gc_control *gc_control) prefree_segments(sbi)); cpc.reason = __get_cp_reason(sbi); - sbi->skipped_gc_rwsem = 0; gc_more: + sbi->skipped_gc_rwsem = 0; if (unlikely(!(sbi->sb->s_flags & SB_ACTIVE))) { ret = -EINVAL; goto stop; -- 2.34.1

1 year, 10 months

2
1
0 0

[PATCH stable v5.15.y 0/1] crypto: add __init/__exit annotations to init/exit funcs

by Saeed Mirzamohammadi

Add missing patch in stable v5.15.y that fixes missing __init/__exit macros for crypto algorithms. Commit Data: commit-id : 33837be33367172d66d1f2bd6964cc41448e6e7c subject : crypto: add __init/__exit annotations to init/exit funcs author : xiujianfeng(a)huawei.com author date : 2022-09-15 03:36:15 Xiu Jianfeng (1): crypto: add __init/__exit annotations to init/exit funcs crypto/async_tx/raid6test.c | 4 ++-- crypto/curve25519-generic.c | 4 ++-- crypto/dh.c | 4 ++-- crypto/ecdh.c | 4 ++-- crypto/ecdsa.c | 4 ++-- crypto/rsa.c | 4 ++-- crypto/sm2.c | 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) -- 2.39.1

1 year, 10 months

2
4
0 0

RE: Hello Dear

by Miss Reacheal

Cześć, Otrzymałeś moją poprzednią wiadomość? Skontaktowałem się z tobą wcześniej, ale wiadomość nie wróciła, więc postanowiłem napisać ponownie. Potwierdź, czy to otrzymasz, abym mógł kontynuować, czekam na Twoją odpowiedź. Pozdrowienia, Pani Reacheal

1 year, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2023