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

[Question] A UBSAN problem in stable-4.4

by Tan Xiaojun

Hi, all, I found the following problem (attached to the end) when testing stable-4.4 with Syzkaller. This is not an easy-to-trigger problem, so the tool does not generate code for recurring problems. >From the call stack, it is because the first parameter in ktime_sub is large, and the second parameter offset is a negative number, causing the final result to overflow into the sign bit and become a large negative number. -------------- ... ktime_t expires = ktime_sub(hrtimer_get_expires(timer), base->offset); ... -------------- But I don't know how to fix this problem. The mainline code is also different from stable-4.4, and I have not found a patch to fix this problem in the mainline repository. So I am a bit confused about how to fix it. Can anyone give me some advice? Thanks. Xiaojun. ================================================================================ UBSAN: Undefined behaviour in kernel/time/hrtimer.c:615:20 signed integer overflow: 9223372036854775807 - -495588161 cannot be represented in type 'long long int' CPU: 0 PID: 4542 Comm: syz-executor0 Not tainted 4.4.156-514.55.6.9.x86_64+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 1ffff100391dbf45 ad071d3307b76e03 ffff8801c8edfab0 ffffffff81c9f586 0000000041b58ab3 ffffffff831fd4e6 ffffffff81c9f478 ffff8801c8edfad8 ffff8801c8edfa78 00000000000014a9 ad071d3307b76e03 ffffffff837fd660 Call Trace: [<ffffffff81c9f586>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffffff81c9f586>] dump_stack+0x10e/0x1a8 lib/dump_stack.c:51 [<ffffffff81d814a6>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164 [<ffffffff81d830a1>] handle_overflow+0x23e/0x299 lib/ubsan.c:195 [<ffffffff81d83157>] __ubsan_handle_sub_overflow+0x2a/0x31 lib/ubsan.c:211 [<ffffffff813d8c33>] hrtimer_reprogram kernel/time/hrtimer.c:615 [inline] [<ffffffff813d8c33>] hrtimer_start_range_ns+0x1083/0x1580 kernel/time/hrtimer.c:1024 [<ffffffff813fde1f>] hrtimer_start include/linux/hrtimer.h:393 [inline] [<ffffffff813fde1f>] alarm_start+0xcf/0x130 kernel/time/alarmtimer.c:328 [<ffffffff813fed66>] alarm_timer_set+0x296/0x4a0 kernel/time/alarmtimer.c:632 [<ffffffff813e1a3e>] SYSC_timer_settime kernel/time/posix-timers.c:914 [inline] [<ffffffff813e1a3e>] SyS_timer_settime+0x2be/0x3d0 kernel/time/posix-timers.c:885 [<ffffffff82c2fb61>] entry_SYSCALL_64_fastpath+0x1e/0x9e ================================================================================ ================================================================================ UBSAN: Undefined behaviour in kernel/time/hrtimer.c:490:13 signed integer overflow: 9223372036854775807 - -495588161 cannot be represented in type 'long long int' CPU: 0 PID: 4542 Comm: syz-executor0 Not tainted 4.4.156-514.55.6.9.x86_64+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 1ffff1003ed40f8b ad071d3307b76e03 ffff8801f6a07ce0 ffffffff81c9f586 0000000041b58ab3 ffffffff831fd4e6 ffffffff81c9f478 ffff8801f6a07d08 ffff8801f6a07ca8 000000000000000a ad071d3307b76e03 ffffffff837fd660 Call Trace: <IRQ> [<ffffffff81c9f586>] __dump_stack lib/dump_stack.c:15 [inline] <IRQ> [<ffffffff81c9f586>] dump_stack+0x10e/0x1a8 lib/dump_stack.c:51 [<ffffffff81d814a6>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164 [<ffffffff81d830a1>] handle_overflow+0x23e/0x299 lib/ubsan.c:195 [<ffffffff81d83157>] __ubsan_handle_sub_overflow+0x2a/0x31 lib/ubsan.c:211 [<ffffffff813d43ea>] __hrtimer_get_next_event+0x1da/0x2b0 kernel/time/hrtimer.c:490 [<ffffffff813d9532>] hrtimer_interrupt+0x202/0x580 kernel/time/hrtimer.c:1361 [<ffffffff8113e7ad>] local_apic_timer_interrupt+0x9d/0x150 arch/x86/kernel/apic/apic.c:901 [<ffffffff82c32ea0>] smp_apic_timer_interrupt+0x80/0xb0 arch/x86/kernel/apic/apic.c:925 [<ffffffff82c30ac5>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:563 <EOI> [<ffffffff82c2f0fb>] ? arch_local_irq_restore arch/x86/include/asm/paravirt.h:812 [inline] <EOI> [<ffffffff82c2f0fb>] ? __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:162 [inline] <EOI> [<ffffffff82c2f0fb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60 kernel/locking/spinlock.c:191 [<ffffffff813e1a4f>] unlock_timer include/linux/spinlock.h:362 [inline] [<ffffffff813e1a4f>] SYSC_timer_settime kernel/time/posix-timers.c:916 [inline] [<ffffffff813e1a4f>] SyS_timer_settime+0x2cf/0x3d0 kernel/time/posix-timers.c:885 [<ffffffff82c2fb61>] entry_SYSCALL_64_fastpath+0x1e/0x9e ================================================================================

7 years

1
0
0 0

patch "termios, tty/tty_baudrate.c: fix buffer overrun" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled termios, tty/tty_baudrate.c: fix buffer overrun to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 991a25194097006ec1e0d2e0814ff920e59e3465 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" <hpa(a)zytor.com> Date: Mon, 22 Oct 2018 09:19:04 -0700 Subject: termios, tty/tty_baudrate.c: fix buffer overrun On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does not do any limit checking on the tty_baudrate[] array, and in fact a buffer overrun is possible on both architectures. Add a limit check to prevent that situation. This will be followed by a much bigger cleanup/simplification patch. Signed-off-by: H. Peter Anvin (Intel) <hpa(a)zytor.com> Requested-by: Cc: Johan Hovold <johan(a)kernel.org> Cc: Jiri Slaby <jslaby(a)suse.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Richard Henderson <rth(a)twiddle.net> Cc: Ivan Kokshaysky <ink(a)jurassic.park.msu.ru> Cc: Matt Turner <mattst88(a)gmail.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Kate Stewart <kstewart(a)linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne(a)nexb.com> Cc: Eugene Syromiatnikov <esyr(a)redhat.com> Cc: Alan Cox <alan(a)lxorguk.ukuu.org.uk> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_baudrate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/tty_baudrate.c b/drivers/tty/tty_baudrate.c index 7576ceace571..f438eaa68246 100644 --- a/drivers/tty/tty_baudrate.c +++ b/drivers/tty/tty_baudrate.c @@ -77,7 +77,7 @@ speed_t tty_termios_baud_rate(struct ktermios *termios) else cbaud += 15; } - return baud_table[cbaud]; + return cbaud >= n_baud_table ? 0 : baud_table[cbaud]; } EXPORT_SYMBOL(tty_termios_baud_rate); @@ -113,7 +113,7 @@ speed_t tty_termios_input_baud_rate(struct ktermios *termios) else cbaud += 15; } - return baud_table[cbaud]; + return cbaud >= n_baud_table ? 0 : baud_table[cbaud]; #else /* IBSHIFT */ return tty_termios_baud_rate(termios); #endif /* IBSHIFT */ -- 2.19.1

7 years

1
0
0 0

[PATCH] HID: Add quirk for Microsoft PIXART OEM mouse

by Sebastian Parschauer

The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this one as well. References: https://www.spinics.net/lists/linux-usb/msg88965.html http://linet.gr.jp/~kojima/PlamoWeb/ML/htdocs/201808/msg00019.html Signed-off-by: Sebastian Parschauer <sparschauer(a)suse.de> CC: stable(a)vger.kernel.org --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index f63489c882bb..4f8104cbc7f0 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -805,6 +805,7 @@ #define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9 #define USB_DEVICE_ID_MS_POWER_COVER 0x07da #define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd +#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb #define USB_VENDOR_ID_MOJO 0x8282 #define USB_DEVICE_ID_RETRO_ADAPTER 0x3201 diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index 52c3b01917e7..c0c2537beff1 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -108,6 +108,7 @@ static const struct hid_device_id hid_quirks[] = { { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_MCS, USB_DEVICE_ID_MCS_GAMEPADBLOCK), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS), HID_QUIRK_NOGET }, + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PIXART_MOUSE), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER), HID_QUIRK_NO_INIT_REPORTS }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_SURFACE_PRO_2), HID_QUIRK_NO_INIT_REPORTS }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2), HID_QUIRK_NO_INIT_REPORTS }, -- 2.13.7

7 years

2
1
0 0

[PATCH v2] of, numa: Validate some distance map rules

by John Garry

Currently the NUMA distance map parsing does not validate the distance table for the distance-matrix rules 1-2 in [1]. However the arch NUMA code may enforce some of these rules, but not all. Such is the case for the arm64 port, which does not enforce the rule that the distance between separates nodes cannot equal LOCAL_DISTANCE. The patch adds the following rules validation: - distance of node to self equals LOCAL_DISTANCE - distance of separate nodes > LOCAL_DISTANCE This change avoids a yet-unresolved crash reported in [2]. A note on dealing with symmetrical distances between nodes: Validating symmetrical distances between nodes is difficult. If it were mandated in the bindings that every distance must be recorded in the table, then it would be easy. However, it isn't. In addition to this, it is also possible to record [b, a] distance only (and not [a, b]). So, when processing the table for [b, a], we cannot assert that current distance of [a, b] != [b, a] as invalid, as [a, b] distance may not be present in the table and current distance would be default at REMOTE_DISTANCE. As such, we maintain the policy that we overwrite distance [a, b] = [b, a] for b > a. This policy is different to kernel ACPI SLIT validation, which allows non-symmetrical distances (ACPI spec SLIT rules allow it). However, the distance debug message is dropped as it may be misleading (for a distance which is later overwritten). Some final notes on semantics: - It is implied that it is the responsibility of the arch NUMA code to reset the NUMA distance map for an error in distance map parsing. - It is the responsibility of the FW NUMA topology parsing (whether OF or ACPI) to enforce NUMA distance rules, and not arch NUMA code. [1] Documents/devicetree/bindings/numa.txt [2] https://www.spinics.net/lists/arm-kernel/msg683304.html Cc: stable(a)vger.kernel.org Signed-off-by: John Garry <john.garry(a)huawei.com> Acked-by: Will Deacon <will.deacon(a)arm.com> --- Change from v1: - A note of masking crash reported - Add Will's tag - Add cc stable diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c index 35c64a4295e0..fe6b13608e51 100644 --- a/drivers/of/of_numa.c +++ b/drivers/of/of_numa.c @@ -104,9 +104,14 @@ static int __init of_numa_parse_distance_map_v1(struct device_node *map) distance = of_read_number(matrix, 1); matrix++; + if ((nodea == nodeb && distance != LOCAL_DISTANCE) || + (nodea != nodeb && distance <= LOCAL_DISTANCE)) { + pr_err("Invalid distance[node%d -> node%d] = %d\n", + nodea, nodeb, distance); + return -EINVAL; + } + numa_set_distance(nodea, nodeb, distance); - pr_debug("distance[node%d -> node%d] = %d\n", - nodea, nodeb, distance); /* Set default distance of node B->A same as A->B */ if (nodeb > nodea) -- 1.9.1

7 years

1
1
0 0

[PATCH 1/3] drm/vc4: Set PPF scaling when the source image is only vertically scaled

by Boris Brezillon

The source image might be only vertically scaled, and in this case ->is_unity will be false, but we'd still have to force ->x_scaling[0] to VC4_SCALING_PPF for YUV conversion to work properly. Let's replace the ->is_unity test by->x_scaling[0] == VC4_SCALING_NONE to cope with that. Fixes: 658d8cbd07da ("drm/vc4: Fix the "no scaling" case on multi-planar YUV formats") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> --- drivers/gpu/drm/vc4/vc4_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 60d5ad19cedd..32b7b9f47c5d 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -318,7 +318,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) * even on a plane that's otherwise 1:1. Looks like only PPF * works in that case, so let's pick that one. */ - if (vc4_state->is_unity) + if (vc4_state->x_scaling[0] == VC4_SCALING_NONE) vc4_state->x_scaling[0] = VC4_SCALING_PPF; } else { vc4_state->is_yuv = false; -- 2.17.1

7 years

2
3
0 0

[PATCH v2] drm: Check if primary mst is null

by Stanislav Lisovskiy

Unfortunately drm_dp_get_mst_branch_device which is called from both drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely on that mgr->mst_primary is not NULL, which seem to be wrong as it can be cleared with simultaneous mode set, if probing fails or in other case. mgr->lock mutex doesn't protect against that as it might just get assigned to NULL right before, not simultaneously. There are currently bugs 107738, 108616 bugs which crash in drm_dp_get_mst_branch_device, caused by this issue. v2: Refactored the code, as it was nicely noticed. Fixed Bugzilla bug numbers(second was 108616, but not 108816) and added links. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 5ff1d79b86c4..0e0df398222d 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1275,6 +1275,9 @@ static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct drm_dp_mst_ mutex_lock(&mgr->lock); mstb = mgr->mst_primary; + if (!mstb) + goto out; + for (i = 0; i < lct - 1; i++) { int shift = (i % 2) ? 0 : 4; int port_num = (rad[i / 2] >> shift) & 0xf; -- 2.17.1

7 years

2
1
0 0

[PATCH 4.4] s390/mm: Check for valid vma before zapping in gmap_discard

by Janosch Frank

From: Janosch Frank <frankja(a)de.ibm.com> Userspace could have munmapped the area before doing unmapping from the gmap. This would leave us with a valid vmaddr, but an invalid vma from which we would try to zap memory. Let's check before using the vma. Function was moved with 1e133ab296f3 in v4.6. Is 1843abd upstream. Fixes: 388186b ("kvm: Handle diagnose 0x10 (release pages)") Signed-off-by: Janosch Frank <frankja(a)de.ibm.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> CC: <stable(a)vger.kernel.org> # 4.4 --- arch/s390/mm/pgtable.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c index 05ae254..1866b6a 100644 --- a/arch/s390/mm/pgtable.c +++ b/arch/s390/mm/pgtable.c @@ -637,6 +637,8 @@ void gmap_discard(struct gmap *gmap, unsigned long from, unsigned long to) vmaddr |= gaddr & ~PMD_MASK; /* Find vma in the parent mm */ vma = find_vma(gmap->mm, vmaddr); + if (!vma) + continue; size = min(to - gaddr, PMD_SIZE - (gaddr & ~PMD_MASK)); zap_page_range(vma, vmaddr, size, NULL); } -- 2.7.4

7 years

1
0
0 0

[PATCH 4.4/4.9] configfs: replace strncpy with memcpy

by Nobuhiro Iwamatsu

From: Guenter Roeck <linux(a)roeck-us.net> commit 1823342a1f2b47a4e6f5667f67cd28ab6bc4d6cd upstream. gcc 8.1.0 complains: fs/configfs/symlink.c:67:3: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length fs/configfs/symlink.c: In function 'configfs_get_link': fs/configfs/symlink.c:63:13: note: length computed here Using strncpy() is indeed less than perfect since the length of data to be copied has already been determined with strlen(). Replace strncpy() with memcpy() to address the warning and optimize the code a little. Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu(a)cybertrust.co.jp> --- fs/configfs/symlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c index 0525ebc3aea2..66e8c5d58b21 100644 --- a/fs/configfs/symlink.c +++ b/fs/configfs/symlink.c @@ -64,7 +64,7 @@ static void fill_item_path(struct config_item * item, char * buffer, int length) /* back up enough to print this bus id with '/' */ length -= cur; - strncpy(buffer + length,config_item_name(p),cur); + memcpy(buffer + length, config_item_name(p), cur); *(buffer + --length) = '/'; } } -- 2.18.0

7 years

1
0
0 0

[PATCH] xfs: truncate transaction does not modify the inobt

by Amir Goldstein

From: Brian Foster <bfoster(a)redhat.com> The truncate transaction does not ever modify the inode btree, but includes an associated log reservation. Update xfs_calc_itruncate_reservation() to remove the reservation associated with inobt updates. [Amir: This commit was merged for kernel v4.16 and a twin commit was merged for xfsprogs v4.16. As a result, a small xfs filesystem formatted with features -m rmapbt=1,reflink=1 using mkfs.xfs version >= v4.16 cannot be mounted with kernel < v4.16. For example, xfstests generic/17{1,2,3} format a small fs and when trying to mount it, they fail with an assert on this very demonic line: XFS (vdc): Log size 3075 blocks too small, minimum size is 3717 blocks XFS (vdc): AAIEEE! Log failed size checks. Abort! XFS: Assertion failed: 0, file: src/linux/fs/xfs/xfs_log.c, line: 666 The simple solution for stable kernels is to apply this patch, because mkfs.xfs v4.16 is already in the wild, so we have to assume that xfs filesystems with a "too small" log exist. Regardless, xfsprogs maintainers should also consider reverting the twin patch to stop creating those filesystems for the sake of users with unpatched kernels.] Signed-off-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Cc: <stable(a)vger.kernel.org> # v4.9+ Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> --- Darrick/Dave, It took me a while to figure out what was going on with my test systems when small test partitions (10G) stopped working with older kernels. Please bless this change for stable and consider the remedie for mkfs.xfs I verified that patch cleanly applies to stable kernels 4.14.y and 4.9.y and that I can mount a filsystem created with new mkfs.xfs. I am now running quick tests on stable 4.14.y with configs 4k, 1k, reflink,reflink+overlay to verify no regressions from this patch. Thanks, Amir. fs/xfs/libxfs/xfs_trans_resv.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c index 6bd916bd35e2..48eff18c5496 100644 --- a/fs/xfs/libxfs/xfs_trans_resv.c +++ b/fs/xfs/libxfs/xfs_trans_resv.c @@ -232,8 +232,6 @@ xfs_calc_write_reservation( * the super block to reflect the freed blocks: sector size * worst case split in allocation btrees per extent assuming 4 extents: * 4 exts * 2 trees * (2 * max depth - 1) * block size - * the inode btree: max depth * blocksize - * the allocation btrees: 2 trees * (max depth - 1) * block size */ STATIC uint xfs_calc_itruncate_reservation( @@ -245,12 +243,7 @@ xfs_calc_itruncate_reservation( XFS_FSB_TO_B(mp, 1))), (xfs_calc_buf_res(9, mp->m_sb.sb_sectsize) + xfs_calc_buf_res(xfs_allocfree_log_count(mp, 4), - XFS_FSB_TO_B(mp, 1)) + - xfs_calc_buf_res(5, 0) + - xfs_calc_buf_res(xfs_allocfree_log_count(mp, 1), - XFS_FSB_TO_B(mp, 1)) + - xfs_calc_buf_res(2 + mp->m_ialloc_blks + - mp->m_in_maxlevels, 0))); + XFS_FSB_TO_B(mp, 1)))); } /* -- 2.17.1

7 years, 1 month

3
5
0 0

[PATCH] libnvdimm: Fix __nd_ioctl() to check error in cmd_rc

by Toshi Kani

ndctl zero-labels completes with a large number of zeroed nmems when it fails to do zeroing on a protected NVDIMM. # ndctl zero-labels nmem1 zeroed 65504 nmems When an ACPI call completes with error, xlat_status() called from acpi_nfit_ctl() sets error to *cmd_rc. __nd_ioctl(), however, does not check this error and returns with success. Fix __nd_ioctl() to check this error in cmd_rc. Fixes: 006358b35c73a ("libnvdimm: add support for clear poison list and badblocks for device dax") Reported-by: Robert Elliott <elliott(a)hpe.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Vishal Verma <vishal.l.verma(a)intel.com> Cc: Dave Jiang <dave.jiang(a)intel.com> Cc: <stable(a)vger.kernel.org> --- drivers/nvdimm/bus.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c index f1fb39921236..af12817d8a02 100644 --- a/drivers/nvdimm/bus.c +++ b/drivers/nvdimm/bus.c @@ -1050,6 +1050,10 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm, rc = nd_desc->ndctl(nd_desc, nvdimm, cmd, buf, buf_len, &cmd_rc); if (rc < 0) goto out_unlock; + if (cmd_rc < 0) { + rc = cmd_rc; + goto out_unlock; + } if (!nvdimm && cmd == ND_CMD_CLEAR_ERROR && cmd_rc >= 0) { struct nd_cmd_clear_error *clear_err = buf;

7 years, 1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror