Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

2 participants
123725 discussions

[PATCH v3] xen: Fix x86 sched_clock() interface for xen

by Juergen Gross

Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") broke Xen guest time handling across migration: [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 187.251137] OOM killer disabled. [ 187.251137] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 187.252299] suspending xenstore... [ 187.266987] xen:grant_table: Grant tables using version 1 layout [18446743811.706476] OOM killer enabled. [18446743811.706478] Restarting tasks ... done. [18446743811.720505] Setting capacity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: <stable(a)vger.kernel.org> # 4.11 Reported-by: Hans van Kranenburg <hans(a)knorrie.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/xen/time.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 72bf446c3fee..6e29794573b7 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -361,8 +361,6 @@ void xen_timer_resume(void) { int cpu; - pvclock_resume(); - if (xen_clockevent != &xen_vcpuop_clockevent) return; @@ -379,12 +377,15 @@ static const struct pv_time_ops xen_time_ops __initconst = { }; static struct pvclock_vsyscall_time_info *xen_clock __read_mostly; +static u64 xen_clock_value_saved; void xen_save_time_memory_area(void) { struct vcpu_register_time_memory_area t; int ret; + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; + if (!xen_clock) return; @@ -404,7 +405,7 @@ void xen_restore_time_memory_area(void) int ret; if (!xen_clock) - return; + goto out; t.addr.v = &xen_clock->pvti; @@ -421,6 +422,11 @@ void xen_restore_time_memory_area(void) if (ret != 0) pr_notice("Cannot restore secondary vcpu_time_info (err %d)", ret); + +out: + /* Need pvclock_resume() before using xen_clocksource_read(). */ + pvclock_resume(); + xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved; } static void xen_setup_vsyscall_time_info(void) -- 2.16.4

6 years, 11 months

[PATCH] usb: phy: am335x: fix race condition in _probe

by Bin Liu

power off the phy should be done before populate the phy. Otherwise, am335x_init() could be called by the phy owner to power on the phy first, then am335x_phy_probe() turns off the phy again without the caller knowing it. Fixes: 2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup") Cc: stable(a)vger.kernel.org # v3.18+ Signed-off-by: Bin Liu <b-liu(a)ti.com> --- drivers/usb/phy/phy-am335x.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c index 27bdb7222527..f5f0568d8533 100644 --- a/drivers/usb/phy/phy-am335x.c +++ b/drivers/usb/phy/phy-am335x.c @@ -61,9 +61,6 @@ static int am335x_phy_probe(struct platform_device *pdev) if (ret) return ret; - ret = usb_add_phy_dev(&am_phy->usb_phy_gen.phy); - if (ret) - return ret; am_phy->usb_phy_gen.phy.init = am335x_init; am_phy->usb_phy_gen.phy.shutdown = am335x_shutdown; @@ -82,7 +79,7 @@ static int am335x_phy_probe(struct platform_device *pdev) device_set_wakeup_enable(dev, false); phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, am_phy->dr_mode, false); - return 0; + return usb_add_phy_dev(&am_phy->usb_phy_gen.phy); } static int am335x_phy_remove(struct platform_device *pdev) -- 2.17.1

6 years, 11 months

[PATCH] ipmi: fix use-after-free of user->release_barrier.rda

by Yang Yingliang

When we do the following test, we got oops in ipmi_msghandler driver while((1)) do service ipmievd restart & service ipmievd restart done --------------------------------------------------------------- [ 294.230186] Unable to handle kernel paging request at virtual address 0000803fea6ea008 [ 294.230188] Mem abort info: [ 294.230190] ESR = 0x96000004 [ 294.230191] Exception class = DABT (current EL), IL = 32 bits [ 294.230193] SET = 0, FnV = 0 [ 294.230194] EA = 0, S1PTW = 0 [ 294.230195] Data abort info: [ 294.230196] ISV = 0, ISS = 0x00000004 [ 294.230197] CM = 0, WnR = 0 [ 294.230199] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000a1c1b75a [ 294.230201] [0000803fea6ea008] pgd=0000000000000000 [ 294.230204] Internal error: Oops: 96000004 [#1] SMP [ 294.235211] Modules linked in: nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm iw_cm dm_mirror dm_region_hash dm_log dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce sha2_ce ses sha256_arm64 sha1_ce hibmc_drm hisi_sas_v2_hw enclosure sg hisi_sas_main sbsa_gwdt ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe ipmi_si mdio hns_dsaf ipmi_devintf ipmi_msghandler hns_enet_drv hns_mdio [ 294.277745] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.0.0-rc2+ #113 [ 294.285511] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017 [ 294.292835] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 294.297695] pc : __srcu_read_lock+0x38/0x58 [ 294.301940] lr : acquire_ipmi_user+0x2c/0x70 [ipmi_msghandler] [ 294.307853] sp : ffff00001001bc80 [ 294.311208] x29: ffff00001001bc80 x28: ffff0000117e5000 [ 294.316594] x27: 0000000000000000 x26: dead000000000100 [ 294.321980] x25: dead000000000200 x24: ffff803f6bd06800 [ 294.327366] x23: 0000000000000000 x22: 0000000000000000 [ 294.332752] x21: ffff00001001bd04 x20: ffff80df33d19018 [ 294.338137] x19: ffff80df33d19018 x18: 0000000000000000 [ 294.343523] x17: 0000000000000000 x16: 0000000000000000 [ 294.348908] x15: 0000000000000000 x14: 0000000000000002 [ 294.354293] x13: 0000000000000000 x12: 0000000000000000 [ 294.359679] x11: 0000000000000000 x10: 0000000000100000 [ 294.365065] x9 : 0000000000000000 x8 : 0000000000000004 [ 294.370451] x7 : 0000000000000000 x6 : ffff80df34558678 [ 294.375836] x5 : 000000000000000c x4 : 0000000000000000 [ 294.381221] x3 : 0000000000000001 x2 : 0000803fea6ea000 [ 294.386607] x1 : 0000803fea6ea008 x0 : 0000000000000001 [ 294.391994] Process swapper/3 (pid: 0, stack limit = 0x0000000083087293) [ 294.398791] Call trace: [ 294.401266] __srcu_read_lock+0x38/0x58 [ 294.405154] acquire_ipmi_user+0x2c/0x70 [ipmi_msghandler] [ 294.410716] deliver_response+0x80/0xf8 [ipmi_msghandler] [ 294.416189] deliver_local_response+0x28/0x68 [ipmi_msghandler] [ 294.422193] handle_one_recv_msg+0x158/0xcf8 [ipmi_msghandler] [ 294.432050] handle_new_recv_msgs+0xc0/0x210 [ipmi_msghandler] [ 294.441984] smi_recv_tasklet+0x8c/0x158 [ipmi_msghandler] [ 294.451618] tasklet_action_common.isra.5+0x88/0x138 [ 294.460661] tasklet_action+0x2c/0x38 [ 294.468191] __do_softirq+0x120/0x2f8 [ 294.475561] irq_exit+0x134/0x140 [ 294.482445] __handle_domain_irq+0x6c/0xc0 [ 294.489954] gic_handle_irq+0xb8/0x178 [ 294.497037] el1_irq+0xb0/0x140 [ 294.503381] arch_cpu_idle+0x34/0x1a8 [ 294.510096] do_idle+0x1d4/0x290 [ 294.516322] cpu_startup_entry+0x28/0x30 [ 294.523230] secondary_start_kernel+0x184/0x1d0 [ 294.530657] Code: d538d082 d2800023 8b010c81 8b020021 (c85f7c25) [ 294.539746] ---[ end trace 8a7a880dee570b29 ]--- [ 294.547341] Kernel panic - not syncing: Fatal exception in interrupt [ 294.556837] SMP: stopping secondary CPUs [ 294.563996] Kernel Offset: disabled [ 294.570515] CPU features: 0x002,21006008 [ 294.577638] Memory Limit: none [ 294.587178] Starting crashdump kernel... [ 294.594314] Bye! Because the user->release_barrier.rda is freed in ipmi_destroy_user(), but the refcount is not zero, when acquire_ipmi_user() uses user->release_barrier.rda in __srcu_read_lock(), it causes oops. Fix this by calling cleanup_srcu_struct() when the refcount is zero. Fixes: e86ee2d44b44 ("ipmi: Rework locking and shutdown for hot remove") Cc: stable(a)vger.kernel.org Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index a74ce88..6c26533 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -1183,6 +1183,7 @@ int ipmi_get_smi_info(int if_num, struct ipmi_smi_info *data) static void free_user(struct kref *ref) { struct ipmi_user *user = container_of(ref, struct ipmi_user, refcount); + cleanup_srcu_struct(&user->release_barrier); kfree(user); } @@ -1259,7 +1260,6 @@ int ipmi_destroy_user(struct ipmi_user *user) { _ipmi_destroy_user(user); - cleanup_srcu_struct(&user->release_barrier); kref_put(&user->refcount, free_user); return 0; -- 1.8.3

6 years, 11 months

[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, 11 months

[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, 11 months

[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, 11 months

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, 11 months

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, 11 months

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, 11 months

[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, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror