- Linux-stable-mirror - lists.linaro.org

[PATCH v2] gpio: regmap: Fix memleak in gpio_remap_register

by Wentao Guan

We should call gpiochip_remove(chip) to free the resource alloced by gpiochip_add_data(chip, gpio) after the err path. Fixes: 553b75d4bfe9 ("gpio: regmap: Allow to allocate regmap-irq device") CC: stable(a)vger.kernel.org Co-developed-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> --- changelog in v2: 1. format commit message. 2. rebase to mainline now. --- --- drivers/gpio/gpio-regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c index f4267af00027e..c64805dcb9f88 100644 --- a/drivers/gpio/gpio-regmap.c +++ b/drivers/gpio/gpio-regmap.c @@ -328,7 +328,7 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config config->regmap_irq_line, config->regmap_irq_flags, 0, config->regmap_irq_chip, &gpio->irq_chip_data); if (ret) - goto err_free_bitmap; + goto err_remove_gpiochip; irq_domain = regmap_irq_get_domain(gpio->irq_chip_data); } else base-commit: 3f9f0252130e7dd60d41be0802bf58f6471c691d -- 2.20.1

4 hours, 51 minutes

2
3
0 0

RE: [PATCH 5.15 136/392] drm/amd: add more cyan skillfish PCI ids

by Deucher, Alexander

[Public] > -----Original Message----- > From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Sent: Wednesday, December 3, 2025 10:25 AM > To: stable(a)vger.kernel.org > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>; > patches(a)lists.linux.dev; Deucher, Alexander <Alexander.Deucher(a)amd.com>; > Sasha Levin <sashal(a)kernel.org> > Subject: [PATCH 5.15 136/392] drm/amd: add more cyan skillfish PCI ids > > 5.15-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Alex Deucher <alexander.deucher(a)amd.com> > > [ Upstream commit 1e18746381793bef7c715fc5ec5611a422a75c4c ] > > Add additional PCI IDs to the cyan skillfish family. > > Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> There is no need to backport this patch to stable. It depends on a bunch of changes which are not in older kernels. Please drop for stable. Alex > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index adcf3adc5ca51..7abcb5db9ae26 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -1942,6 +1942,11 @@ static const struct pci_device_id pciidlist[] = { > {0x1002, 0x7410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ALDEBARAN}, > > /* CYAN_SKILLFISH */ > + {0x1002, 0x13DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > + {0x1002, 0x13F9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > + {0x1002, 0x13FA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > + {0x1002, 0x13FB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > + {0x1002, 0x13FC, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > {0x1002, 0x13FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, > CHIP_CYAN_SKILLFISH|AMD_IS_APU}, > > /* BEIGE_GOBY */ > -- > 2.51.0 > >

4 hours, 59 minutes

1
0
0 0

FAILED: patch "[PATCH] drm, fbcon, vga_switcheroo: Avoid race condition in fbcon" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x eb76d0f5553575599561010f24c277cc5b31d003 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120119-edgy-recycled-bcfe@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eb76d0f5553575599561010f24c277cc5b31d003 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann <tzimmermann(a)suse.de> Date: Wed, 5 Nov 2025 17:14:49 +0100 Subject: [PATCH] drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://elixir.bootlin.com/linux/v6.17/source/drivers/video/fbdev/core/fbco… # [1] Fixes: 6a9ee8af344e ("vga_switcheroo: initial implementation (v15)") Acked-by: Javier Martinez Canillas <javierm(a)redhat.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: nouveau(a)lists.freedesktop.org Cc: amd-gfx(a)lists.freedesktop.org Cc: linux-fbdev(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v2.6.34+ Link: https://patch.msgid.link/20251105161549.98836-1-tzimmermann@suse.de diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 11a5b60cb9ce..0b3ee008523d 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -31,9 +31,7 @@ #include <linux/console.h> #include <linux/export.h> -#include <linux/pci.h> #include <linux/sysrq.h> -#include <linux/vga_switcheroo.h> #include <drm/drm_atomic.h> #include <drm/drm_drv.h> @@ -566,11 +564,6 @@ EXPORT_SYMBOL(drm_fb_helper_release_info); */ void drm_fb_helper_unregister_info(struct drm_fb_helper *fb_helper) { - struct fb_info *info = fb_helper->info; - struct device *dev = info->device; - - if (dev_is_pci(dev)) - vga_switcheroo_client_fb_set(to_pci_dev(dev), NULL); unregister_framebuffer(fb_helper->info); } EXPORT_SYMBOL(drm_fb_helper_unregister_info); @@ -1632,7 +1625,6 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper) struct drm_client_dev *client = &fb_helper->client; struct drm_device *dev = fb_helper->dev; struct drm_fb_helper_surface_size sizes; - struct fb_info *info; int ret; if (drm_WARN_ON(dev, !dev->driver->fbdev_probe)) @@ -1653,12 +1645,6 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper) strcpy(fb_helper->fb->comm, "[fbcon]"); - info = fb_helper->info; - - /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */ - if (dev_is_pci(info->device)) - vga_switcheroo_client_fb_set(to_pci_dev(info->device), info); - return 0; } diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 9bd3c3814b5c..e7e07eb2142e 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -66,6 +66,7 @@ #include <linux/string.h> #include <linux/kd.h> #include <linux/panic.h> +#include <linux/pci.h> #include <linux/printk.h> #include <linux/slab.h> #include <linux/fb.h> @@ -78,6 +79,7 @@ #include <linux/interrupt.h> #include <linux/crc32.h> /* For counting font checksums */ #include <linux/uaccess.h> +#include <linux/vga_switcheroo.h> #include <asm/irq.h> #include "fbcon.h" @@ -2899,6 +2901,9 @@ void fbcon_fb_unregistered(struct fb_info *info) console_lock(); + if (info->device && dev_is_pci(info->device)) + vga_switcheroo_client_fb_set(to_pci_dev(info->device), NULL); + fbcon_registered_fb[info->node] = NULL; fbcon_num_registered_fb--; @@ -3032,6 +3037,10 @@ static int do_fb_registered(struct fb_info *info) } } + /* Set the fb info for vga_switcheroo clients. Does nothing otherwise. */ + if (info->device && dev_is_pci(info->device)) + vga_switcheroo_client_fb_set(to_pci_dev(info->device), info); + return ret; }

4 hours, 59 minutes

4
5
0 0

LDI Show 2025 Data

by Rachel Porter

Hi, Ahead of LDI Show 2025 (Dec 3–9, Las Vegas), we have access to a verified audience of 16,594 and a strong exhibitor roster of 312 top suppliers and vendors. This includes lighting & audio equipment manufacturers, staging/rigging vendors, media-server / projection / video providers, production houses, rental companies, sound & lighting engineers, stage managers ,other live-event technology stakeholders and many. If interested, reply “Send Pricing” to receive the details. Best regards, Rachel Porter Head of Client Relations To opt-out, reply “Not Interested”.

5 hours

1
0
0 0

[PATCH] perf build: build BPF skeletons with fPIC

by Jon Kohler

Fix Makefile.perf to ensure that bpf skeletons are built with fPIC. When building with BUILD_BPF_SKEL=1, bpf_skel's was not getting built with fPIC, seeing compilation failures like: /usr/bin/ld: /builddir/.../tools/perf/util/bpf_skel/.tmp/bootstrap/main.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE Bisected down to 6.18 commit a39516805992 ("tools build: Don't assume libtracefs-devel is always available"). Fixes: a39516805992 ("tools build: Don't assume libtracefs-devel is always available") Cc: stable(a)vger.kernel.org Signed-off-by: Jon Kohler <jon(a)nutanix.com> --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 02f87c49801f..4557c2e89e88 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -1211,7 +1211,7 @@ endif $(BPFTOOL): | $(SKEL_TMP_OUT) $(Q)CFLAGS= $(MAKE) -C ../bpf/bpftool \ - OUTPUT=$(SKEL_TMP_OUT)/ bootstrap + EXTRA_CFLAGS="-fPIC" OUTPUT=$(SKEL_TMP_OUT)/ bootstrap # Paths to search for a kernel to generate vmlinux.h from. VMLINUX_BTF_ELF_PATHS ?= $(if $(O),$(O)/vmlinux) \ -- 2.43.0

5 hours, 1 minute

2
2
0 0

Re: [PATCH 6.1 406/568] ALSA: usb-audio: Fix potential overflow of PCM transfer buffer

by Takashi Iwai

On Wed, 03 Dec 2025 16:26:48 +0100, Greg Kroah-Hartman wrote: > > 6.1-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Takashi Iwai <tiwai(a)suse.de> > > commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf upstream. > > The PCM stream data in USB-audio driver is transferred over USB URB > packet buffers, and each packet size is determined dynamically. The > packet sizes are limited by some factors such as wMaxPacketSize USB > descriptor. OTOH, in the current code, the actually used packet sizes > are determined only by the rate and the PPS, which may be bigger than > the size limit above. This results in a buffer overflow, as reported > by syzbot. > > Basically when the limit is smaller than the calculated packet size, > it implies that something is wrong, most likely a weird USB > descriptor. So the best option would be just to return an error at > the parameter setup time before doing any further operations. > > This patch introduces such a sanity check, and returns -EINVAL when > the packet size is greater than maxpacksize. The comparison with > ep->packsize[1] alone should suffice since it's always equal or > greater than ep->packsize[0]. > > Reported-by: syzbot+bfd77469c8966de076f7(a)syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7 > Link: https://lore.kernel.org/690b6b46.050a0220.3d0d33.0054.GAE@google.com > Cc: Lizhi Xu <lizhi.xu(a)windriver.com> > Cc: <stable(a)vger.kernel.org> > Link: https://patch.msgid.link/20251109091211.12739-1-tiwai@suse.de > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > sound/usb/endpoint.c | 5 +++++ > 1 file changed, 5 insertions(+) > > --- a/sound/usb/endpoint.c > +++ b/sound/usb/endpoint.c > @@ -1379,6 +1379,11 @@ int snd_usb_endpoint_set_params(struct s > ep->sample_rem = ep->cur_rate % ep->pps; > ep->packsize[0] = ep->cur_rate / ep->pps; > ep->packsize[1] = (ep->cur_rate + (ep->pps - 1)) / ep->pps; > + if (ep->packsize[1] > ep->maxpacksize) { > + usb_audio_dbg(chip, "Too small maxpacksize %u for rate %u / pps %u\n", > + ep->maxpacksize, ep->cur_rate, ep->pps); > + return -EINVAL; > + } > > /* calculate the frequency in 16.16 format */ > ep->freqm = ep->freqn; This one requires the same workaround again, just as mentioned for 5.15.y: https://lore.kernel.org/87ecpbsfbj.wl-tiwai@suse.de thanks, Takashi

5 hours, 1 minute

1
0
0 0

RE: [PATCH 6.17 129/146] drm/amdgpu: attach tlb fence to the PTs update

by Deucher, Alexander

[Public] > -----Original Message----- > From: Koenig, Christian <Christian.Koenig(a)amd.com> > Sent: Wednesday, December 3, 2025 11:03 AM > To: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>; > stable(a)vger.kernel.org > Cc: patches(a)lists.linux.dev; Liang, Prike <Prike.Liang(a)amd.com>; Deucher, > Alexander <Alexander.Deucher(a)amd.com> > Subject: Re: [PATCH 6.17 129/146] drm/amdgpu: attach tlb fence to the PTs > update > > Oh, wait a second, that one should clearly *not* be backported! > > @Alex or do we have userqueue support working on 6.17? I don't think so. > Yes, userq support is available in 6.17. That said, this patch did end up causing a regression on SI parts. I've got a fix for that which will land soon. Alex > Regards, > Christian. > > On 12/3/25 16:28, Greg Kroah-Hartman wrote: > > 6.17-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Prike Liang <Prike.Liang(a)amd.com> > > > > commit b4a7f4e7ad2b120a94f3111f92a11520052c762d upstream. > > > > Ensure the userq TLB flush is emitted only after the VM update > > finishes and the PT BOs have been annotated with bookkeeping fences. > > > > Suggested-by: Christian König <christian.koenig(a)amd.com> > > Signed-off-by: Prike Liang <Prike.Liang(a)amd.com> > > Reviewed-by: Christian König <christian.koenig(a)amd.com> > > Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked > > from commit f3854e04b708d73276c4488231a8bd66d30b4671) > > Cc: stable(a)vger.kernel.org > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > @@ -1056,7 +1056,7 @@ amdgpu_vm_tlb_flush(struct amdgpu_vm_upd > > } > > > > /* Prepare a TLB flush fence to be attached to PTs */ > > - if (!params->unlocked && vm->is_compute_context) { > > + if (!params->unlocked) { > > amdgpu_vm_tlb_fence_create(params->adev, vm, fence); > > > > /* Makes sure no PD/PT is freed before the flush */ > > > >

5 hours, 1 minute

1
0
0 0

Performance regressions introduced via Revert "cpuidle: menu: Avoid discarding useful information" on 5.15 LTS

by Harshvardhan Jha

Hi there, While running performance benchmarks for the 5.15.196 LTS tags , it was observed that several regressions across different benchmarks is being introduced when compared to the previous 5.15.193 kernel tag. Running an automated bisect on both of them narrowed down the culprit commit to: - 5666bcc3c00f7 Revert "cpuidle: menu: Avoid discarding useful information" for 5.15 Regressions on 5.15.196 include: -9.3% : Phoronix pts/sqlite using 2 processes on OnPrem X6-2 -6.3% : Phoronix system/sqlite on OnPrem X6-2 -18% : rds-stress -M 1 (readonly rdma-mode) metrics with 1 depth & 1 thread & 1M buffer size on OnPrem X6-2 -4 -> -8% : rds-stress -M 2 (writeonly rdma-mode) metrics with 1 depth & 1 thread & 1M buffer size on OnPrem X6-2 Up to -30% : Some Netpipe metrics on OnPrem X5-2 The culprit commits' messages mention that these reverts were done due to performance regressions introduced in Intel Jasper Lake systems but this revert is causing issues in other systems unfortunately. I wanted to know the maintainers' opinion on how we should proceed in order to fix this. If we reapply it'll bring back the previous regressions on Jasper Lake systems and if we don't revert it then it's stuck with current regressions. If this problem has been reported before and a fix is in the works then please let me know I shall follow developments to that mail thread. Thanks & Regards, Harshvardhan

5 hours, 5 minutes

2
1
0 0

Re: [PATCH v2 1/2] kasan: Refactor pcpu kasan vmalloc unpoison

by Maciej Wieczór-Retman

On 2025-12-03 at 16:53:04 +0100, Andrey Konovalov wrote: >On Tue, Dec 2, 2025 at 3:29 PM Maciej Wieczor-Retman ><m.wieczorretman(a)pm.me> wrote: >> >> From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> >> ... >> diff --git a/mm/kasan/common.c b/mm/kasan/common.c >> index d4c14359feaf..7884ea7d13f9 100644 >> --- a/mm/kasan/common.c >> +++ b/mm/kasan/common.c >> @@ -28,6 +28,7 @@ >> #include <linux/string.h> >> #include <linux/types.h> >> #include <linux/bug.h> >> +#include <linux/vmalloc.h> >> >> #include "kasan.h" >> #include "../slab.h" >> @@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip) >> } >> return true; >> } >> + >> +#ifdef CONFIG_KASAN_VMALLOC >> +void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, >> + kasan_vmalloc_flags_t flags) > >kasan_unpoison_vmap_areas() needs to be defined in >inclunde/linux/kasan.h and call __kasan_unpoison_vmap_areas() when >kasan_enabled() == true, similar to the other wrappers. > >And check my comment for patch #2: with that, you should not need to >add so many new __helpers: just __kasan_unpoison_vmalloc and >__kasan_unpoison_vmap_areas should suffice. Okay, I think I see what you mean. I was trying to avoid using __kasan_unpoison_vmalloc() here so that it compiled properly, but that was before I added the ifdef guard. Now there is not reason not to use it here. I'll make the changes you mentioned. Kind regards Maciej Wieczór-Retman > >> +{ >> + unsigned long size; >> + void *addr; >> + int area; >> + >> + for (area = 0 ; area < nr_vms ; area++) { >> + size = vms[area]->size; >> + addr = vms[area]->addr; >> + vms[area]->addr = __kasan_unpoison_vmap_areas(addr, size, flags); >> + } >> +} >> +#endif

5 hours, 6 minutes

1
0
0 0

Re: [PATCH 6.1 240/568] jfs: fix uninitialized waitqueue in transaction manager

by syzbot

> 6.1-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> > > [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ] > > The transaction manager initialization in txInit() was not properly > initializing TxBlock[0].waitor waitqueue, causing a crash when > txEnd(0) is called on read-only filesystems. > > When a filesystem is mounted read-only, txBegin() returns tid=0 to > indicate no transaction. However, txEnd(0) still gets called and > tries to access TxBlock[0].waitor via tid_to_tblock(0), but this > waitqueue was never initialized because the initialization loop > started at index 1 instead of 0. > > This causes a 'non-static key' lockdep warning and system crash: > INFO: trying to register non-static key in txEnd > > Fix by ensuring all transaction blocks including TxBlock[0] have > their waitqueues properly initialized during txInit(). > > Reported-by: syzbot+c4f3462d8b2ad7977bea(a)syzkaller.appspotmail.com > > Signed-off-by: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> > Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > --- > fs/jfs/jfs_txnmgr.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c > index dccc8b3f10459..42fb833ef2834 100644 > --- a/fs/jfs/jfs_txnmgr.c > +++ b/fs/jfs/jfs_txnmgr.c > @@ -272,14 +272,15 @@ int txInit(void) > if (TxBlock == NULL) > return -ENOMEM; > > - for (k = 1; k < nTxBlock - 1; k++) { > - TxBlock[k].next = k + 1; > + for (k = 0; k < nTxBlock; k++) { > init_waitqueue_head(&TxBlock[k].gcwait); > init_waitqueue_head(&TxBlock[k].waitor); > } > + > + for (k = 1; k < nTxBlock - 1; k++) { > + TxBlock[k].next = k + 1; > + } > TxBlock[k].next = 0; > - init_waitqueue_head(&TxBlock[k].gcwait); > - init_waitqueue_head(&TxBlock[k].waitor); > > TxAnchor.freetid = 1; > init_waitqueue_head(&TxAnchor.freewait); > -- > 2.51.0 > > > I see the command but can't find the corresponding bug. The email is sent to syzbot+HASH(a)syzkaller.appspotmail.com address but the HASH does not correspond to any known bug. Please double check the address.

5 hours, 20 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror