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

[PATCH STABLE v4.19.15] gpiolib: fix line event timestamps for nested irqs

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Nested interrupts run inside the calling thread's context and the top half handler is never called which means that we never read the timestamp. This issue came up when trying to read line events from a gpiochip using regmap_irq_chip for interrupts. Fix it by reading the timestamp from the irq thread function if it's still 0 by the time the second handler is called. Fixes: d58f2bf261fd ("gpio: Timestamp events in hardirq handler") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> --- Hi Sasha, this is a backport for v4.19.y series. The original patch didn't apply due to a conflict. drivers/gpio/gpiolib.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index a8e01d99919c..b3ab6c428423 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -817,7 +817,15 @@ static irqreturn_t lineevent_irq_thread(int irq, void *p) /* Do not leak kernel stack to userspace */ memset(&ge, 0, sizeof(ge)); - ge.timestamp = le->timestamp; + /* + * We may be running from a nested threaded interrupt in which case + * we didn't get the timestamp from lineevent_irq_handler(). + */ + if (!le->timestamp) + ge.timestamp = ktime_get_real_ns(); + else + ge.timestamp = le->timestamp; + level = gpiod_get_value_cansleep(le->desc); if (le->eflags & GPIOEVENT_REQUEST_RISING_EDGE -- 2.19.1

6 years, 7 months

3
2
0 0

[git:media_tree/fixes] media: vim2m: only cancel work if it is for right context

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: vim2m: only cancel work if it is for right context Author: Hans Verkuil <hverkuil(a)xs4all.nl> Date: Fri Jan 11 07:07:25 2019 -0500 cancel_delayed_work_sync() was called for any queue, but it should only be called for the queue that is associated with the currently running job. Otherwise, if two filehandles are streaming at the same time, then closing the first will cancel the work which might still be running for a job from the second filehandle. As a result the second filehandle will never be able to finish the job and an attempt to stop streaming on that second filehandle will stall. Fixes: 52117be68b82 ("media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work") Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Cc: <stable(a)vger.kernel.org> # for v4.20 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/platform/vim2m.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c index d01821a6906a..89d9c4c21037 100644 --- a/drivers/media/platform/vim2m.c +++ b/drivers/media/platform/vim2m.c @@ -807,7 +807,9 @@ static void vim2m_stop_streaming(struct vb2_queue *q) struct vb2_v4l2_buffer *vbuf; unsigned long flags; - cancel_delayed_work_sync(&dev->work_run); + if (v4l2_m2m_get_curr_priv(dev->m2m_dev) == ctx) + cancel_delayed_work_sync(&dev->work_run); + for (;;) { if (V4L2_TYPE_IS_OUTPUT(q->type)) vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);

6 years, 7 months

1
0
0 0

[git:media_tree/fixes] media: v4l: ioctl: Validate num_planes for debug messages

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: v4l: ioctl: Validate num_planes for debug messages Author: Sakari Ailus <sakari.ailus(a)linux.intel.com> Date: Thu Jan 10 09:24:26 2019 -0500 The num_planes field in struct v4l2_pix_format_mplane is used in a loop before validating it. As the use is printing a debug message in this case, just cap the value to the maximum allowed. Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Cc: stable(a)vger.kernel.org Reviewed-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Cc: <stable(a)vger.kernel.org> # for v4.12 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/v4l2-core/v4l2-ioctl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 44bc7c4f1c11..90aad465f9ed 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -287,6 +287,7 @@ static void v4l_print_format(const void *arg, bool write_only) const struct v4l2_window *win; const struct v4l2_sdr_format *sdr; const struct v4l2_meta_format *meta; + u32 planes; unsigned i; pr_cont("type=%s", prt_names(p->type, v4l2_type_names)); @@ -317,7 +318,8 @@ static void v4l_print_format(const void *arg, bool write_only) prt_names(mp->field, v4l2_field_names), mp->colorspace, mp->num_planes, mp->flags, mp->ycbcr_enc, mp->quantization, mp->xfer_func); - for (i = 0; i < mp->num_planes; i++) + planes = min_t(u32, mp->num_planes, VIDEO_MAX_PLANES); + for (i = 0; i < planes; i++) printk(KERN_DEBUG "plane %u: bytesperline=%u sizeimage=%u\n", i, mp->plane_fmt[i].bytesperline, mp->plane_fmt[i].sizeimage);

6 years, 7 months

1
0
0 0

Re: [PATCH v2] can: bcm: check timer values before ktime conversion

by Oliver Hartkopp

Hi Sasha, On 1/16/19 2:36 PM, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: 2.6.26+ > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150, v4.4.170, v3.18.132. > > v4.20.2: Build OK! > v4.19.15: Build OK! > v4.14.93: Build OK! > v4.9.150: Build OK! > v4.4.170: Failed to apply! Possible dependencies: > 2b5f5f5dc114 ("can: bcm: unify bcm_msg_head handling and prepare function parameters") > 6f3b911d5f29 ("can: bcm: add support for CAN FD frames") > 72c8a89ad2e4 ("can: bcm: use CAN frame instead of can_frame in comments") > 95acb490ec51 ("can: bcm: fix indention and other minor style issues") > > v3.18.132: Failed to apply! Possible dependencies: > 069f8457ae52 ("can: fix spelling errors") > 2b5f5f5dc114 ("can: bcm: unify bcm_msg_head handling and prepare function parameters") > 6ce8e9ce5989 ("new helper: memcpy_from_msg()") > 6f3b911d5f29 ("can: bcm: add support for CAN FD frames") > 72c8a89ad2e4 ("can: bcm: use CAN frame instead of can_frame in comments") > 95acb490ec51 ("can: bcm: fix indention and other minor style issues") > ba61a8d9d780 ("can: avoid using timeval for uapi") > > > How should we proceed with this patch? Applying the patch on e.g. 3.2.102 also leads to patching file net/can/bcm.c Hunk #1 FAILED at 67. Hunk #2 FAILED at 140. Hunk #3 succeeded at 847 with fuzz 2 (offset -26 lines). Hunk #4 succeeded at 1018 with fuzz 2 (offset -39 lines). 2 out of 4 hunks FAILED -- saving rejects to file net/can/bcm.c.rej The first two hunks just adding a define and and function *somewhere* at the top of the C file. I can provide patches for the requested stable kernels once we have a reference for the upstream commit hash. Would that be ok for you? Best regards, Oliver

6 years, 7 months

1
1
0 0

Re: [PATCH v2] gpiolib: fix line event timestamps for nested irqs

by Bartosz Golaszewski

śr., 16 sty 2019 o 14:35 Sasha Levin <sashal(a)kernel.org> napisał(a): > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: d58f2bf261fd gpio: Timestamp events in hardirq handler. > > The bot has tested the following trees: v4.20.2, v4.19.15. > > v4.20.2: Build OK! > v4.19.15: Failed to apply! Possible dependencies: > Unable to calculate > > > How should we proceed with this patch? > I sent a backport of this patch. Bart > -- > Thanks, > Sasha

6 years, 7 months

1
0
0 0

Re: [PATCH] ipmi: msghandler: Fix potential Spectre v1 vulnerabilities

by Corey Minyard

On 1/16/19 7:35 AM, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150, v4.4.170, v3.18.132. I'll pull these into my tree. It sounds like you want this in ASAP, I can do that, though this interface is lower priority, I would think, because it's generally root access only. -corey > > v4.20.2: Build OK! > v4.19.15: Build OK! > v4.14.93: Failed to apply! Possible dependencies: > 1c9f98d1bfbd ("ipmi: Make IPMI panic strings always available") > 3fd32f9ec84f ("ipmi: Convert IPMI GUID over to Linux guid_t") > 511d57dc71a2 ("ipmi: Get the device id through a function") > 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name") > 9ca15af3164f ("ipmi: Fix issues with BMC refcounts") > a2cb600fa22a ("ipmi: Rework BMC registration") > a9137c3dfae9 ("ipmi: Add a reference from BMC devices to their interfaces") > aa9c9ab2443e ("ipmi: allow dynamic BMC version information") > b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs") > c0734bd594d4 ("ipmi: Retry BMC registration on a failure") > f33e4df83e00 ("ipmi: Move bmc find routing to below bmc device type") > > v4.9.150: Failed to apply! Possible dependencies: > 1c9f98d1bfbd ("ipmi: Make IPMI panic strings always available") > 3fd32f9ec84f ("ipmi: Convert IPMI GUID over to Linux guid_t") > 511d57dc71a2 ("ipmi: Get the device id through a function") > 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name") > 9ca15af3164f ("ipmi: Fix issues with BMC refcounts") > a2cb600fa22a ("ipmi: Rework BMC registration") > a9137c3dfae9 ("ipmi: Add a reference from BMC devices to their interfaces") > aa9c9ab2443e ("ipmi: allow dynamic BMC version information") > b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs") > c0734bd594d4 ("ipmi: Retry BMC registration on a failure") > f33e4df83e00 ("ipmi: Move bmc find routing to below bmc device type") > > v4.4.170: Failed to apply! Possible dependencies: > 1c9f98d1bfbd ("ipmi: Make IPMI panic strings always available") > 3fd32f9ec84f ("ipmi: Convert IPMI GUID over to Linux guid_t") > 511d57dc71a2 ("ipmi: Get the device id through a function") > 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name") > 9ca15af3164f ("ipmi: Fix issues with BMC refcounts") > a2cb600fa22a ("ipmi: Rework BMC registration") > a9137c3dfae9 ("ipmi: Add a reference from BMC devices to their interfaces") > aa9c9ab2443e ("ipmi: allow dynamic BMC version information") > b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs") > bd85f4b37ddf ("ipmi: fix crash on reading version from proc after unregisted bmc") > c0734bd594d4 ("ipmi: Retry BMC registration on a failure") > f33e4df83e00 ("ipmi: Move bmc find routing to below bmc device type") > > v3.18.132: Failed to apply! Possible dependencies: > 16639eb08a69 ("ipmi: clean up the device handling for the bmc device") > 1c9f98d1bfbd ("ipmi: Make IPMI panic strings always available") > 3fd32f9ec84f ("ipmi: Convert IPMI GUID over to Linux guid_t") > 5a0e10ec4a82 ("ipmi: Remove useless sysfs_name parameters") > 9ca15af3164f ("ipmi: Fix issues with BMC refcounts") > a2cb600fa22a ("ipmi: Rework BMC registration") > a9137c3dfae9 ("ipmi: Add a reference from BMC devices to their interfaces") > aa9c9ab2443e ("ipmi: allow dynamic BMC version information") > b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs") > bd85f4b37ddf ("ipmi: fix crash on reading version from proc after unregisted bmc") > c0734bd594d4 ("ipmi: Retry BMC registration on a failure") > f33e4df83e00 ("ipmi: Move bmc find routing to below bmc device type") > > > How should we proceed with this patch? > > -- > Thanks, > Sasha

6 years, 7 months

1
0
0 0

[PATCH 1/4] xfs: eof trim writeback mapping as soon as it is cached

by Brian Foster

The cached writeback mapping is EOF trimmed to try and avoid races between post-eof block management and writeback that result in sending cached data to a stale location. The cached mapping is currently trimmed on the validation check, which leaves a race window between the time the mapping is cached and when it is trimmed against the current inode size. For example, if a new mapping is cached by delalloc conversion on a blocksize == page size fs, we could cycle various locks, perform memory allocations, etc. in the writeback codepath before the associated mapping is eventually trimmed to i_size. This leaves enough time for a post-eof truncate and file append before the cached mapping is trimmed. The former event essentially invalidates a range of the cached mapping and the latter bumps the inode size such the trim on the next writepage event won't trim all of the invalid blocks. fstest generic/464 reproduces this scenario occasionally and causes a lost writeback and stale delalloc blocks warning on inode inactivation. To work around this problem, trim the cached writeback mapping as soon as it is cached in addition to on subsequent validation checks. This is a minor tweak to tighten the race window as much as possible until a proper invalidation mechanism is available. Fixes: 40214d128e07 ("xfs: trim writepage mapping to within eof") Cc: <stable(a)vger.kernel.org> # v4.14+ Signed-off-by: Brian Foster <bfoster(a)redhat.com> --- fs/xfs/xfs_aops.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 338b9d9984e0..d9048bcea49c 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -449,6 +449,7 @@ xfs_map_blocks( } wpc->imap = imap; + xfs_trim_extent_eof(&wpc->imap, ip); trace_xfs_map_blocks_found(ip, offset, count, wpc->io_type, &imap); return 0; allocate_blocks: @@ -459,6 +460,7 @@ xfs_map_blocks( ASSERT(whichfork == XFS_COW_FORK || cow_fsb == NULLFILEOFF || imap.br_startoff + imap.br_blockcount <= cow_fsb); wpc->imap = imap; + xfs_trim_extent_eof(&wpc->imap, ip); trace_xfs_map_blocks_alloc(ip, offset, count, wpc->io_type, &imap); return 0; } -- 2.17.2

6 years, 7 months

2
2
0 0

Re: [PATCH 1/1] v4l: ioctl: Validate num_planes for debug messages

by Hans Verkuil

On 1/16/19 2:35 PM, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150, v4.4.170, v3.18.132. > > v4.20.2: Build OK! > v4.19.15: Build OK! > v4.14.93: Build OK! > v4.9.150: Failed to apply! Possible dependencies: > fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format") > > v4.4.170: Failed to apply! Possible dependencies: > 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces") > 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc") > 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build") > 234d549662a7 ("doc-rst: video: use reference for VIDIOC_ENUMINPUT") > 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)") > 7347081e8a52 ("doc-rst: linux_tv: simplify references") > 789818845202 ("doc-rst: audio: Fix some cross references") > 94fff0dc5333 ("doc-rst: dmx_fcalls: improve man-like format") > 9e00ffca8cc7 ("doc-rst: querycap: fix troubles on some references") > af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls") > c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables") > e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference") > fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format") > > v3.18.132: Failed to apply! Possible dependencies: > 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces") > 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc") > 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build") > 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)") > 5699f871d2d5 ("scripts/kernel-doc: Adding cross-reference links to html documentation.") > 7347081e8a52 ("doc-rst: linux_tv: simplify references") > af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls") > b479bfd00e46 ("DocBook: Use a fixed encoding for output") > c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables") > e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference") > fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format") > > > How should we proceed with this patch? The Cc to stable of this patch in the pending pull request has a 'for v4.12 and up': https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.0a&id=8015… So no need to patch pre-4.12 kernels. Regards, Hans

6 years, 7 months

1
0
0 0

[PATCH] m68k: Add -ffreestanding to CFLAGS

by Finn Thain

This patch fixes a build failure when using GCC 8.1: /usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': block/partitions/ldm.c:153: undefined reference to `strcmp' This is caused by a new optimization which effectively replaces a strncmp() call with a strcmp() call. This affects a number of strncmp() call sites in the kernel. The entire class of optimizations is avoided with -fno-builtin, which gets enabled by -ffreestanding. This may avoid possible future build failures in case new optimizations appear in future compilers. I haven't done any performance measurements with this patch but I did count the function calls in a defconfig build. For example, there are now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the other libc functions is smaller. If this harms performance we can tackle that regression by optimizing the call sites, ideally using semantic patches. That way, clang and ICC builds might benfit too. Cc: stable(a)vger.kernel.org Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2 Signed-off-by: Finn Thain <fthain(a)telegraphics.com.au> --- arch/m68k/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 997c9f20ea0f..0a99c276d9a4 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -58,7 +58,8 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200) cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) KBUILD_AFLAGS += $(cpuflags-y) -KBUILD_CFLAGS += $(cpuflags-y) -pipe +KBUILD_CFLAGS += $(cpuflags-y) + ifdef CONFIG_MMU # without -fno-strength-reduce the 53c7xx.c driver fails ;-( KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2 @@ -69,6 +70,8 @@ KBUILD_CFLAGS += -D__uClinux__ KBUILD_AFLAGS += -D__uClinux__ endif +KBUILD_CFLAGS += -pipe -ffreestanding + KBUILD_LDFLAGS := -m m68kelf KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -- 2.19.2

6 years, 7 months

1
0
0 0

boot stalls when booting sparc32 images on v3.16.y/v3.18.y in qemu

by Guenter Roeck

Hi, I recently updated the sparc32 root file system in my testbed with one generated with buildroot. As a result, sparc32 images no longer boot with v3.16.y and v3.18.y. The system starts to come up, but stalls while starting syslog. However, v3.16 and v3.18 do boot. I bisected v3.18.y and ended up with commit 16c193364b4 ("sparc: Harden signal return frame checks.") as culprit; bisect results below. Reverting this commit fixes the problem for both v3.16.y and v3.18.y. Is it worth spending any time on this, or should I just stop testing sparc32 boot tests with v3.16.y and v3.18.y ? Thanks, Guenter --- # bad: [fa42fea0d8b49ba65b49a999331950d74827a52d] Linux 3.18.131 # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18 git bisect start 'HEAD' 'v3.18' # bad: [6e64ac0957e06a81b22f95f3509cc39b07735d3d] usb: increase ohci watchdog delay to 275 msec git bisect bad 6e64ac0957e06a81b22f95f3509cc39b07735d3d # good: [3e2003cccc9fb5f73a0d251dbb595f4c6e3a08bd] USB: usbfs: allow URBs to be reaped after disconnection git bisect good 3e2003cccc9fb5f73a0d251dbb595f4c6e3a08bd # good: [d6a1481f7411425041271c3084f3c2e399dc6526] ASoC: wm8958: Fix enum ctl accesses in a wrong type git bisect good d6a1481f7411425041271c3084f3c2e399dc6526 # good: [bc4b57be51fa419cd870398624c763b7afb91154] Btrfs: make btrfs_abort_transaction consider existence of new block groups git bisect good bc4b57be51fa419cd870398624c763b7afb91154 # bad: [b4d9416d6388fb450b397484e0ab85a154471723] of: fix memory leak related to safe_name() git bisect bad b4d9416d6388fb450b397484e0ab85a154471723 # good: [35807de76e1c2b7d15eea2f947983fcd043a2db0] clk: rockchip: free memory in error cases when registering clock branches git bisect good 35807de76e1c2b7d15eea2f947983fcd043a2db0 # bad: [cae1c6c281d8728e98f7e7a8950d6e64746b5bbc] netfilter: arp_tables: simplify translate_compat_table args git bisect bad cae1c6c281d8728e98f7e7a8950d6e64746b5bbc # good: [f02212dd4bd88826afccc36146177589eccb699b] tty: vt, return error when con_startup fails git bisect good f02212dd4bd88826afccc36146177589eccb699b # bad: [16c193364b4d6ff58c38c209e1e2b5c6fd674123] sparc: Harden signal return frame checks. git bisect bad 16c193364b4d6ff58c38c209e1e2b5c6fd674123 # good: [09600dd82044bf676e875d3bd9c904193c31c1f0] sfc: on MC reset, clear PIO buffer linkage in TXQs git bisect good 09600dd82044bf676e875d3bd9c904193c31c1f0 # good: [0396a871c4e3fbbaabb4f2632c1d388a04b68c84] sparc64: Fix numa node distance initialization git bisect good 0396a871c4e3fbbaabb4f2632c1d388a04b68c84 # good: [2a3e4b3cbee2c53c53e82b6f593160fb6583b24e] sparc/PCI: Fix for panic while enabling SR-IOV git bisect good 2a3e4b3cbee2c53c53e82b6f593160fb6583b24e # good: [705de0f20b1751f5816952486589543aaaa0bcbe] sparc64: Take ctx_alloc_lock properly in hugetlb_setup(). git bisect good 705de0f20b1751f5816952486589543aaaa0bcbe # first bad commit: [16c193364b4d6ff58c38c209e1e2b5c6fd674123] sparc: Harden signal return frame checks.

6 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror