March 2022 - Linux-stable-mirror

FAILED: patch "[PATCH] tracing: Dump stacktrace trigger to the corresponding" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ce33c845b030c9cf768370c951bc699470b09fa7 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira <bristot(a)kernel.org> Date: Sun, 20 Feb 2022 23:49:57 +0100 Subject: [PATCH] tracing: Dump stacktrace trigger to the corresponding instance The stacktrace event trigger is not dumping the stacktrace to the instance where it was enabled, but to the global "instance." Use the private_data, pointing to the trigger file, to figure out the corresponding trace instance, and use it in the trigger action, like snapshot_trigger does. Link: https://lkml.kernel.org/r/afbb0b4f18ba92c276865bc97204d438473f4ebc.16453962… Cc: stable(a)vger.kernel.org Fixes: ae63b31e4d0e2 ("tracing: Separate out trace events from global variables") Reviewed-by: Tom Zanussi <zanussi(a)kernel.org> Tested-by: Tom Zanussi <zanussi(a)kernel.org> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index d00fee705f9c..e0d50c9577f3 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1540,7 +1540,12 @@ stacktrace_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { - trace_dump_stack(STACK_SKIP); + struct trace_event_file *file = data->private_data; + + if (file) + __trace_stack(file->tr, tracing_gen_ctx(), STACK_SKIP); + else + trace_dump_stack(STACK_SKIP); } static void

2 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] tracing: Have traceon and traceoff trigger honor the instance" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 302e9edd54985f584cfc180098f3554774126969 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Wed, 23 Feb 2022 22:38:37 -0500 Subject: [PATCH] tracing: Have traceon and traceoff trigger honor the instance If a trigger is set on an event to disable or enable tracing within an instance, then tracing should be disabled or enabled in the instance and not at the top level, which is confusing to users. Link: https://lkml.kernel.org/r/20220223223837.14f94ec3@rorschach.local.home Cc: stable(a)vger.kernel.org Fixes: ae63b31e4d0e2 ("tracing: Separate out trace events from global variables") Tested-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> Reviewed-by: Tom Zanussi <zanussi(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index e0d50c9577f3..efe563140f27 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1295,6 +1295,16 @@ traceon_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { + struct trace_event_file *file = data->private_data; + + if (file) { + if (tracer_tracing_is_on(file->tr)) + return; + + tracer_tracing_on(file->tr); + return; + } + if (tracing_is_on()) return; @@ -1306,8 +1316,15 @@ traceon_count_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { - if (tracing_is_on()) - return; + struct trace_event_file *file = data->private_data; + + if (file) { + if (tracer_tracing_is_on(file->tr)) + return; + } else { + if (tracing_is_on()) + return; + } if (!data->count) return; @@ -1315,7 +1332,10 @@ traceon_count_trigger(struct event_trigger_data *data, if (data->count != -1) (data->count)--; - tracing_on(); + if (file) + tracer_tracing_on(file->tr); + else + tracing_on(); } static void @@ -1323,6 +1343,16 @@ traceoff_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { + struct trace_event_file *file = data->private_data; + + if (file) { + if (!tracer_tracing_is_on(file->tr)) + return; + + tracer_tracing_off(file->tr); + return; + } + if (!tracing_is_on()) return; @@ -1334,8 +1364,15 @@ traceoff_count_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { - if (!tracing_is_on()) - return; + struct trace_event_file *file = data->private_data; + + if (file) { + if (!tracer_tracing_is_on(file->tr)) + return; + } else { + if (!tracing_is_on()) + return; + } if (!data->count) return; @@ -1343,7 +1380,10 @@ traceoff_count_trigger(struct event_trigger_data *data, if (data->count != -1) (data->count)--; - tracing_off(); + if (file) + tracer_tracing_off(file->tr); + else + tracing_off(); } static int

2 years, 8 months

2
1
0 0

[PATCH v2] usb: gadget: uvc: Fix crash when encoding data for usb request

by Dan Vacura

During the uvcg_video_pump() process, if an error occurs and uvcg_queue_cancel() is called, the buffer queue will be cleared out, but the current marker (queue->buf_used) of the active buffer (no longer active) is not reset. On the next iteration of uvcg_video_pump() the stale buf_used count will be used and the logic of min((unsigned int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a nbytes size, causing an invalid memory access. [80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. [80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. ... uvcg_queue_cancel() is called and the queue is cleared out, but the marker queue->buf_used is not reset. ... [80802.262328][ T8682] Unable to handle kernel paging request at virtual address ffffffc03af9f000 ... ... [80802.263138][ T8682] Call trace: [80802.263146][ T8682] __memcpy+0x12c/0x180 [80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0 [80802.263165][ T8682] process_one_work+0x2cc/0x568 [80802.263173][ T8682] worker_thread+0x28c/0x518 [80802.263181][ T8682] kthread+0x160/0x170 [80802.263188][ T8682] ret_from_fork+0x10/0x18 [80802.263198][ T8682] Code: a8c12829 a88130cb a8c130 Fixes: d692522577c0 ("usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework") Signed-off-by: Dan Vacura <w36195(a)motorola.com> --- Changes in v2: - Add Fixes tag drivers/usb/gadget/function/uvc_queue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c index d852ac9e47e7..2cda982f3765 100644 --- a/drivers/usb/gadget/function/uvc_queue.c +++ b/drivers/usb/gadget/function/uvc_queue.c @@ -264,6 +264,8 @@ void uvcg_queue_cancel(struct uvc_video_queue *queue, int disconnect) buf->state = UVC_BUF_STATE_ERROR; vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_ERROR); } + queue->buf_used = 0; + /* This must be protected by the irqlock spinlock to avoid race * conditions between uvc_queue_buffer and the disconnection event that * could result in an interruptible wait in uvc_dequeue_buffer. Do not -- 2.32.0

2 years, 8 months

3
4
0 0

[PATCH v1 2/4] ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()

by Mark Brown

When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/soc-ops.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 73c9d53de25b..f0d1aeb38346 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -413,6 +413,7 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, int min = mc->min; unsigned int mask = (1U << (fls(min + max) - 1)) - 1; int err = 0; + int ret; unsigned int val, val_mask; val_mask = mask << shift; @@ -422,6 +423,7 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, err = snd_soc_component_update_bits(component, reg, val_mask, val); if (err < 0) return err; + ret = err; if (snd_soc_volsw_is_stereo(mc)) { unsigned int val2; @@ -432,6 +434,11 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, err = snd_soc_component_update_bits(component, reg2, val_mask, val2); + + /* Don't discard any error code or drop change flag */ + if (ret == 0 || err < 0) { + ret = err; + } } return err; } -- 2.30.2

2 years, 8 months

2
2
0 0

[PATCH v2] thermal: devfreq_cooling: use local ops instead of global ops

by Kant Fan

Fix access illegal address problem in following condition: There are muti devfreq cooling devices in system, some of them has em model but other does not, energy model ops such as state2power will append to global devfreq_cooling_ops when the cooling device with em model register. It makes the cooling device without em model also use devfreq_cooling_ops after appending when register later by of_devfreq_cooling_register_power() or of_devfreq_cooling_register(). IPA governor regards the cooling devices without em model as a power actor because they also have energy model ops, and will access illegal address at dfc->em_pd when execute cdev->ops->get_requested_power, cdev->ops->state2power or cdev->ops->power2state. Fixes: 615510fe13bd2 ("thermal: devfreq_cooling: remove old power model and use EM") Cc: stable(a)vger.kernel.org # 5.13+ Signed-off-by: Kant Fan <kant(a)allwinnertech.com> --- drivers/thermal/devfreq_cooling.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/thermal/devfreq_cooling.c b/drivers/thermal/devfreq_cooling.c index 4310cb342a9f..d38a80adec73 100644 --- a/drivers/thermal/devfreq_cooling.c +++ b/drivers/thermal/devfreq_cooling.c @@ -358,21 +358,28 @@ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df, struct thermal_cooling_device *cdev; struct device *dev = df->dev.parent; struct devfreq_cooling_device *dfc; + struct thermal_cooling_device_ops *ops; char *name; int err, num_opps; - dfc = kzalloc(sizeof(*dfc), GFP_KERNEL); - if (!dfc) + ops = kmemdup(&devfreq_cooling_ops, sizeof(*ops), GFP_KERNEL); + if (!ops) return ERR_PTR(-ENOMEM); + dfc = kzalloc(sizeof(*dfc), GFP_KERNEL); + if (!dfc) { + err = -ENOMEM; + goto free_ops; + } + dfc->devfreq = df; dfc->em_pd = em_pd_get(dev); if (dfc->em_pd) { - devfreq_cooling_ops.get_requested_power = + ops->get_requested_power = devfreq_cooling_get_requested_power; - devfreq_cooling_ops.state2power = devfreq_cooling_state2power; - devfreq_cooling_ops.power2state = devfreq_cooling_power2state; + ops->state2power = devfreq_cooling_state2power; + ops->power2state = devfreq_cooling_power2state; dfc->power_ops = dfc_power; @@ -407,8 +414,7 @@ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df, if (!name) goto remove_qos_req; - cdev = thermal_of_cooling_device_register(np, name, dfc, - &devfreq_cooling_ops); + cdev = thermal_of_cooling_device_register(np, name, dfc, ops); kfree(name); if (IS_ERR(cdev)) { @@ -429,6 +435,8 @@ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df, kfree(dfc->freq_table); free_dfc: kfree(dfc); +free_ops: + kfree(ops); return ERR_PTR(err); } @@ -510,11 +518,13 @@ EXPORT_SYMBOL_GPL(devfreq_cooling_em_register); void devfreq_cooling_unregister(struct thermal_cooling_device *cdev) { struct devfreq_cooling_device *dfc; + const struct thermal_cooling_device_ops *ops; struct device *dev; if (IS_ERR_OR_NULL(cdev)) return; + ops = cdev->ops; dfc = cdev->devdata; dev = dfc->devfreq->dev.parent; @@ -525,5 +535,6 @@ void devfreq_cooling_unregister(struct thermal_cooling_device *cdev) kfree(dfc->freq_table); kfree(dfc); + kfree(ops); } EXPORT_SYMBOL_GPL(devfreq_cooling_unregister); -- 2.29.0

2 years, 8 months

3
4
0 0

Re: [tip: sched/core] sched/tracing: Don't re-read p->state when emitting sched_switch event

by Qais Yousef

+CC stable On 03/01/22 15:24, tip-bot2 for Valentin Schneider wrote: > The following commit has been merged into the sched/core branch of tip: > > Commit-ID: fa2c3254d7cfff5f7a916ab928a562d1165f17bb > Gitweb: https://git.kernel.org/tip/fa2c3254d7cfff5f7a916ab928a562d1165f17bb > Author: Valentin Schneider <valentin.schneider(a)arm.com> > AuthorDate: Thu, 20 Jan 2022 16:25:19 > Committer: Peter Zijlstra <peterz(a)infradead.org> > CommitterDate: Tue, 01 Mar 2022 16:18:39 +01:00 > > sched/tracing: Don't re-read p->state when emitting sched_switch event > > As of commit > > c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") > > the following sequence becomes possible: > > p->__state = TASK_INTERRUPTIBLE; > __schedule() > deactivate_task(p); > ttwu() > READ !p->on_rq > p->__state=TASK_WAKING > trace_sched_switch() > __trace_sched_switch_state() > task_state_index() > return 0; > > TASK_WAKING isn't in TASK_REPORT, so the task appears as TASK_RUNNING in > the trace event. > > Prevent this by pushing the value read from __schedule() down the trace > event. > > Reported-by: Abhijeet Dharmapurikar <adharmap(a)quicinc.com> > Signed-off-by: Valentin Schneider <valentin.schneider(a)arm.com> > Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> > Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> > Link: https://lore.kernel.org/r/20220120162520.570782-2-valentin.schneider@arm.com Any objection to picking this for stable? I'm interested in this one for some Android users but prefer if it can be taken by stable rather than backport it individually. I think it makes sense to pick the next one in the series too. Thanks! -- Qais Yousef

2 years, 8 months

3
11
0 0

[PATCH] mm/secretmem: fix panic when growing a memfd_secret

by Axel Rasmussen

When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the direct map (i.e. we call set_direct_map_invalid_noflush() on every fault). So the address returned by page_address() isn't useful, and when we try to memset() with it we panic. This patch avoids the panic by implementing a custom setattr for memfd_secret, which detects resizes specifically (setting the size for the first time works just fine, since there are no existing pages to try to zero), and rejects them as not supported (ENOTSUP). One could argue growing should be supported, but I think that will require a significantly more lengthy change. So, I propose a minimal fix for the benefit of stable kernels, and then perhaps to extend memfd_secret to support growing in a separate patch. [1]: [ 774.320433] BUG: unable to handle page fault for address: ffffa0a889277028 [ 774.322297] #PF: supervisor write access in kernel mode [ 774.323306] #PF: error_code(0x0002) - not-present page [ 774.324296] PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 [ 774.325841] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 774.326934] CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 [ 774.328074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 774.329732] RIP: 0010:memset_erms+0x9/0x10 [ 774.330474] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.333543] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.334404] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.335545] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.336685] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.337929] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.339236] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.340356] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.341635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.342535] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.343651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.344780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.345938] Call Trace: [ 774.346334] <TASK> [ 774.346671] ? zero_user_segments+0x82/0x190 [ 774.347346] truncate_inode_partial_folio+0xd4/0x2a0 [ 774.348128] truncate_inode_pages_range+0x380/0x830 [ 774.348904] truncate_setsize+0x63/0x80 [ 774.349530] simple_setattr+0x37/0x60 [ 774.350102] notify_change+0x3d8/0x4d0 [ 774.350681] do_sys_ftruncate+0x162/0x1d0 [ 774.351302] __x64_sys_ftruncate+0x1c/0x20 [ 774.351936] do_syscall_64+0x44/0xa0 [ 774.352486] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 774.353284] RIP: 0033:0x7f72947c392b [ 774.354001] Code: 77 05 c3 0f 1f 40 00 48 8b 15 41 85 0c 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 4d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 11 85 0c 00 f7 d8 [ 774.357938] RSP: 002b:00007ffcad62a1a8 EFLAGS: 00000202 ORIG_RAX: 000000000000004d [ 774.359116] RAX: ffffffffffffffda RBX: 000055f47662b440 RCX: 00007f72947c392b [ 774.360186] RDX: 0000000000000028 RSI: 0000000000000028 RDI: 0000000000000003 [ 774.361246] RBP: 00007ffcad62a1c0 R08: 0000000000000003 R09: 0000000000000000 [ 774.362324] R10: 00007f72946dc230 R11: 0000000000000202 R12: 000055f47662b0e0 [ 774.363393] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 774.364470] </TASK> [ 774.364807] Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet [ 774.367325] CR2: ffffa0a889277028 [ 774.367838] ---[ end trace 0000000000000000 ]--- [ 774.368543] RIP: 0010:memset_erms+0x9/0x10 [ 774.369187] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.372282] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.373372] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.374814] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.376248] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.377687] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.379135] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.380550] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.382177] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.383329] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.384763] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.386229] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.387664] Kernel panic - not syncing: Fatal exception [ 774.388863] Kernel Offset: 0x8000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 774.391014] ---[ end Kernel panic - not syncing: Fatal exception ]--- Signed-off-by: Axel Rasmussen <axelrasmussen(a)google.com> Cc: stable(a)vger.kernel.org --- mm/secretmem.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/mm/secretmem.c b/mm/secretmem.c index 098638d3b8a4..a83e98aa3a7b 100644 --- a/mm/secretmem.c +++ b/mm/secretmem.c @@ -158,6 +158,22 @@ const struct address_space_operations secretmem_aops = { .isolate_page = secretmem_isolate_page, }; +static int secretmem_setattr(struct user_namespace *mnt_userns, + struct dentry *dentry, struct iattr *iattr) +{ + struct inode *inode = d_inode(dentry); + unsigned int ia_valid = iattr->ia_valid; + + if ((ia_valid & ATTR_SIZE) && inode->i_size) + return -EOPNOTSUPP; + + return simple_setattr(mnt_userns, dentry, iattr); +} + +const struct inode_operations secretmem_iops = { + .setattr = secretmem_setattr, +}; + static struct vfsmount *secretmem_mnt; static struct file *secretmem_file_create(unsigned long flags) @@ -177,6 +193,7 @@ static struct file *secretmem_file_create(unsigned long flags) mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); mapping_set_unevictable(inode->i_mapping); + inode->i_op = &secretmem_iops; inode->i_mapping->a_ops = &secretmem_aops; /* pretend we are a normal file with zero size */ -- 2.35.1.1021.g381101b075-goog

2 years, 8 months

3
5
0 0

[PATCH v2 0/2] TSX update

by Pawan Gupta

v2: - Added patch to disable TSX development mode (Andrew, Boris) - Rebased to v5.17-rc7 v1: https://lore.kernel.org/lkml/5bd785a1d6ea0b572250add0c6617b4504bc24d1.16444… Hi, After a recent microcode update some Intel processors will always abort Transactional Synchronization Extensions (TSX) transactions [*]. On these processors a new CPUID bit, CPUID.07H.0H.EDX[11](RTM_ALWAYS_ABORT), will be enumerated to indicate that the loaded microcode is forcing Restricted Transactional Memory (RTM) abort. If the processor enumerated support for RTM previously, the CPUID enumeration bits for TSX (CPUID.RTM and CPUID.HLE) continue to be set by default after the microcode update. First patch in this series clears CPUID.RTM and CPUID.HLE so that userspace doesn't enumerate TSX feature. Microcode also added support to re-enable TSX for development purpose, doing so is not recommended for production deployments, because MD_CLEAR flows for the mitigation of TSX Asynchronous Abort (TAA) may not be effective on these processors when TSX is enabled with updated microcode. Second patch unconditionally disables this TSX development mode, in case it was enabled by the software running before kernel boot. Thanks, Pawan [*] Intel Transactional Synchronization Extension (Intel TSX) Disable Update for Selected Processors https://cdrdv2.intel.com/v1/dl/getContent/643557 Pawan Gupta (2): x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits x86/tsx: Disable TSX development mode at boot arch/x86/include/asm/msr-index.h | 4 +- arch/x86/kernel/cpu/cpu.h | 1 + arch/x86/kernel/cpu/intel.c | 5 ++ arch/x86/kernel/cpu/tsx.c | 88 ++++++++++++++++++++++++-- tools/arch/x86/include/asm/msr-index.h | 4 +- 5 files changed, 91 insertions(+), 11 deletions(-) base-commit: ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2 -- 2.25.1

2 years, 8 months

4
9
0 0

[PATCH] block: aoe: fix page fault in freedev()

by Valentin Kleibel

There is a bug in the aoe driver module where every forcible removal of an aoe device (eg. "rmmod aoe" with aoe devices available or "aoe-flush ex.x") leads to a page fault. The code in freedev() calls blk_mq_free_tag_set() before running blk_cleanup_queue() which leads to this issue (drivers/block/aoe/aoedev.c L281ff). This issue was fixed upstream in commit 6560ec9 (aoe: use blk_mq_alloc_disk and blk_cleanup_disk) with the introduction and use of the function blk_cleanup_disk(). This patch applies to kernels 5.4 and 5.10. The function calls are reordered to match the behavior of blk_cleanup_disk() to mitigate this issue. Fixes: 3582dd2 (aoe: convert aoeblk to blk-mq) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215647 Signed-off-by: Valentin Kleibel <valentin(a)vrvis.at> --- drivers/block/aoe/aoedev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c index e2ea2356da06..08c98ea724ea 100644 --- a/drivers/block/aoe/aoedev.c +++ b/drivers/block/aoe/aoedev.c @@ -277,9 +277,9 @@ freedev(struct aoedev *d) if (d->gd) { aoedisk_rm_debugfs(d); del_gendisk(d->gd); + blk_cleanup_queue(d->blkq); put_disk(d->gd); blk_mq_free_tag_set(&d->tag_set); - blk_cleanup_queue(d->blkq); } t = d->targets; e = t + d->ntargets;

2 years, 8 months

2
9
0 0

[PATCH] dma: at_xdmac: fix a missing check on list iterator

by Xiaomeng Tong

The bug is here: __func__, desc, &desc->tx_dma_desc.phys, ret, cookie, residue); The list iterator 'desc' will point to a bogus position containing HEAD if the list is empty or no element is found. To avoid dev_dbg() prints a invalid address, use a new variable 'iter' as the list iterator, while use the origin variable 'desc' as a dedicated pointer to point to the found element. Cc: stable(a)vger.kernel.org Fixes: 82e2424635f4c ("dmaengine: xdmac: fix print warning on dma_addr_t variable") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- drivers/dma/at_xdmac.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c index 1476156af74b..def564d1e8fa 100644 --- a/drivers/dma/at_xdmac.c +++ b/drivers/dma/at_xdmac.c @@ -1453,7 +1453,7 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie, { struct at_xdmac_chan *atchan = to_at_xdmac_chan(chan); struct at_xdmac *atxdmac = to_at_xdmac(atchan->chan.device); - struct at_xdmac_desc *desc, *_desc; + struct at_xdmac_desc *desc, *_desc, *iter; struct list_head *descs_list; enum dma_status ret; int residue, retry; @@ -1568,11 +1568,13 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie, * microblock. */ descs_list = &desc->descs_list; - list_for_each_entry_safe(desc, _desc, descs_list, desc_node) { - dwidth = at_xdmac_get_dwidth(desc->lld.mbr_cfg); - residue -= (desc->lld.mbr_ubc & 0xffffff) << dwidth; - if ((desc->lld.mbr_nda & 0xfffffffc) == cur_nda) + list_for_each_entry_safe(iter, _desc, descs_list, desc_node) { + dwidth = at_xdmac_get_dwidth(iter->lld.mbr_cfg); + residue -= (iter->lld.mbr_ubc & 0xffffff) << dwidth; + if ((iter->lld.mbr_nda & 0xfffffffc) == cur_nda) { + desc = iter; break; + } } residue += cur_ubc << dwidth; -- 2.17.1

2 years, 8 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2022