June 2024 - Linux-stable-mirror

[git:media_stage/master] media: i2c: alvium: Move V4L2_CID_GAIN to V4L2_CID_ANALOG_GAIN

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: i2c: alvium: Move V4L2_CID_GAIN to V4L2_CID_ANALOG_GAIN Author: Tommaso Merciai <tomm.merciai(a)gmail.com> Date: Mon Jun 10 10:10:34 2024 +0200 Into alvium cameras REG_BCRM_GAIN_RW control the analog gain. Let's use the right V4L2_CID_ANALOGUE_GAIN ctrl. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable(a)vger.kernel.org Signed-off-by: Tommaso Merciai <tomm.merciai(a)gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/i2c/alvium-csi2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- diff --git a/drivers/media/i2c/alvium-csi2.c b/drivers/media/i2c/alvium-csi2.c index c27c6fcaede4..5ddfd3dcb188 100644 --- a/drivers/media/i2c/alvium-csi2.c +++ b/drivers/media/i2c/alvium-csi2.c @@ -1998,7 +1998,7 @@ static int alvium_g_volatile_ctrl(struct v4l2_ctrl *ctrl) int val; switch (ctrl->id) { - case V4L2_CID_GAIN: + case V4L2_CID_ANALOGUE_GAIN: val = alvium_get_gain(alvium); if (val < 0) return val; @@ -2030,7 +2030,7 @@ static int alvium_s_ctrl(struct v4l2_ctrl *ctrl) return 0; switch (ctrl->id) { - case V4L2_CID_GAIN: + case V4L2_CID_ANALOGUE_GAIN: ret = alvium_set_ctrl_gain(alvium, ctrl->val); break; case V4L2_CID_AUTOGAIN: @@ -2159,7 +2159,7 @@ static int alvium_ctrl_init(struct alvium_dev *alvium) if (alvium->avail_ft.gain) { ctrls->gain = v4l2_ctrl_new_std(hdl, ops, - V4L2_CID_GAIN, + V4L2_CID_ANALOGUE_GAIN, alvium->min_gain, alvium->max_gain, alvium->inc_gain,

8 months, 2 weeks

1
0
0 0

[PATCH 6.6.y 0/2] Fix missing lib.sh for net/unicast_extensions.sh and net/pmtu.sh tests

by Po-Hsu Lin

Since upstream commit: * 0f4765d0 "selftests/net: convert unicast_extensions.sh to run it in unique namespace" * 378f082e "selftests/net: convert pmtu.sh to run it in unique namespace" The lib.sh from commit 25ae948b "selftests/net: add lib.sh" will be needed. Otherwise these test will complain about missing files and fail: $ sudo ./unicast_extensions.sh ./unicast_extensions.sh: line 31: lib.sh: No such file or directory ... $ sudo ./pmtu.sh ./pmtu.sh: line 201: lib.sh: No such file or directory ./pmtu.sh: line 941: cleanup_all_ns: command not found ... Another commit b6925b4e "selftests/net: add variable NS_LIST for lib.sh" is needed to add support for the cleanup_all_ns above. Hangbin Liu (2): selftests/net: add lib.sh selftests/net: add variable NS_LIST for lib.sh tools/testing/selftests/net/Makefile | 2 +- tools/testing/selftests/net/forwarding/lib.sh | 27 +------- tools/testing/selftests/net/lib.sh | 93 +++++++++++++++++++++++++++ 3 files changed, 95 insertions(+), 27 deletions(-) create mode 100644 tools/testing/selftests/net/lib.sh -- 2.7.4

8 months, 2 weeks

2
3
0 0

+ ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: fix DIO failure due to insufficient transaction credits has been added to the -mm mm-hotfixes-unstable branch. Its filename is ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Jan Kara <jack(a)suse.cz> Subject: ocfs2: fix DIO failure due to insufficient transaction credits Date: Fri, 14 Jun 2024 16:52:43 +0200 The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Link: https://lkml.kernel.org/r/20240614145243.8837-1-jack@suse.cz Signed-off-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Heming Zhao <heming.zhao(a)suse.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/aops.c | 5 +++++ fs/ocfs2/journal.c | 17 +++++++++++++++++ fs/ocfs2/journal.h | 2 ++ fs/ocfs2/ocfs2_trace.h | 2 ++ 4 files changed, 26 insertions(+) --- a/fs/ocfs2/aops.c~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/aops.c @@ -2366,6 +2366,11 @@ static int ocfs2_dio_end_io_write(struct } list_for_each_entry(ue, &dwc->dw_zero_list, ue_node) { + ret = ocfs2_assure_trans_credits(handle, credits); + if (ret < 0) { + mlog_errno(ret); + break; + } ret = ocfs2_mark_extent_written(inode, &et, handle, ue->ue_cpos, 1, ue->ue_phys, --- a/fs/ocfs2/journal.c~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/journal.c @@ -446,6 +446,23 @@ bail: } /* + * Make sure handle has at least 'nblocks' credits available. If it does not + * have that many credits available, we will try to extend the handle to have + * enough credits. If that fails, we will restart transaction to have enough + * credits. Similar notes regarding data consistency and locking implications + * as for ocfs2_extend_trans() apply here. + */ +int ocfs2_assure_trans_credits(handle_t *handle, int nblocks) +{ + int old_nblks = jbd2_handle_buffer_credits(handle); + + trace_ocfs2_assure_trans_credits(old_nblks); + if (old_nblks >= nblocks) + return 0; + return ocfs2_extend_trans(handle, nblocks - old_nblks); +} + +/* * If we have fewer than thresh credits, extend by OCFS2_MAX_TRANS_DATA. * If that fails, restart the transaction & regain write access for the * buffer head which is used for metadata modifications. --- a/fs/ocfs2/journal.h~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/journal.h @@ -243,6 +243,8 @@ handle_t *ocfs2_start_trans(struct int ocfs2_commit_trans(struct ocfs2_super *osb, handle_t *handle); int ocfs2_extend_trans(handle_t *handle, int nblocks); +int ocfs2_assure_trans_credits(handle_t *handle, + int nblocks); int ocfs2_allocate_extend_trans(handle_t *handle, int thresh); --- a/fs/ocfs2/ocfs2_trace.h~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/ocfs2_trace.h @@ -2577,6 +2577,8 @@ DEFINE_OCFS2_ULL_UINT_EVENT(ocfs2_commit DEFINE_OCFS2_INT_INT_EVENT(ocfs2_extend_trans); +DEFINE_OCFS2_INT_EVENT(ocfs2_assure_trans_credits); + DEFINE_OCFS2_INT_EVENT(ocfs2_extend_trans_restart); DEFINE_OCFS2_INT_INT_EVENT(ocfs2_allocate_extend_trans); _ Patches currently in -mm which might be from jack(a)suse.cz are ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch

8 months, 2 weeks

1
0
0 0

[PATCH 1/2] docs: stable-kernel-rules: provide example of specifying target series

by Shung-Hsi Yu

Provide a concrete example of how to specify what stable series should be targeted for change inclusion. Looking around on the stable mailing list this seems like a common practice already, so let's mention that in the documentation as well (but worded so it is not interpreted as the only way to do so). Signed-off-by: Shung-Hsi Yu <shung-hsi.yu(a)suse.com> --- Documentation/process/stable-kernel-rules.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index edf90bbe30f4..daa542988095 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -57,10 +57,13 @@ options for cases where a mainlined patch needs adjustments to apply in older series (for example due to API changes). When using option 2 or 3 you can ask for your change to be included in specific -stable series. When doing so, ensure the fix or an equivalent is applicable, -submitted, or already present in all newer stable trees still supported. This is -meant to prevent regressions that users might later encounter on updating, if -e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y. +stable series, one way to do so is by specifying the target series in the +subject prefix (e.g. '[PATCH stable 5.15 5.10]' asks that the patch to be +included in both 5.10.y and 5.15.y). When doing so, ensure the fix or an +equivalent is applicable, submitted, or already present in all newer stable +trees still supported. This is meant to prevent regressions that users might +later encounter on updating, if e.g. a fix merged for 5.19-rc1 would be +backported to 5.10.y, but not to 5.15.y. .. _option_1: -- 2.45.1

8 months, 2 weeks

3
5
0 0

+ kasan-fix-bad-call-to-unpoison_slab_object.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kasan: fix bad call to unpoison_slab_object has been added to the -mm mm-hotfixes-unstable branch. Its filename is kasan-fix-bad-call-to-unpoison_slab_object.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Andrey Konovalov <andreyknvl(a)gmail.com> Subject: kasan: fix bad call to unpoison_slab_object Date: Fri, 14 Jun 2024 16:32:38 +0200 Commit 29d7355a9d05 ("kasan: save alloc stack traces for mempool") messed up one of the calls to unpoison_slab_object: the last two arguments are supposed to be GFP flags and whether to init the object memory. Fix the call. Without this fix, __kasan_mempool_unpoison_object provides the object's size as GFP flags to unpoison_slab_object, which can cause LOCKDEP reports (and probably other issues). Link: https://lkml.kernel.org/r/20240614143238.60323-1-andrey.konovalov@linux.dev Fixes: 29d7355a9d05 ("kasan: save alloc stack traces for mempool") Signed-off-by: Andrey Konovalov <andreyknvl(a)gmail.com> Reported-by: Brad Spengler <spender(a)grsecurity.net> Acked-by: Marco Elver <elver(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/kasan/common.c~kasan-fix-bad-call-to-unpoison_slab_object +++ a/mm/kasan/common.c @@ -532,7 +532,7 @@ void __kasan_mempool_unpoison_object(voi return; /* Unpoison the object and save alloc info for non-kmalloc() allocations. */ - unpoison_slab_object(slab->slab_cache, ptr, size, flags); + unpoison_slab_object(slab->slab_cache, ptr, flags, false); /* Poison the redzone and save alloc info for kmalloc() allocations. */ if (is_kmalloc_cache(slab->slab_cache)) _ Patches currently in -mm which might be from andreyknvl(a)gmail.com are kasan-fix-bad-call-to-unpoison_slab_object.patch

8 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] io_uring: check for non-NULL file pointer in" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 5fc16fa5f13b3c06fdb959ef262050bd810416a2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061318-hypocrite-elude-31f3@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 5fc16fa5f13b ("io_uring: check for non-NULL file pointer in io_file_can_poll()") 95041b93e90a ("io_uring: add io_file_can_poll() helper") 521223d7c229 ("io_uring/cancel: don't default to setting req->work.cancel_seq") 4bcb982cce74 ("io_uring: expand main struct io_kiocb flags to 64-bits") 595e52284d24 ("io_uring/poll: don't enable lazy wake for POLLEXCLUSIVE") 4de520f1fcef ("Merge tag 'io_uring-futex-2023-10-30' of git://git.kernel.dk/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5fc16fa5f13b3c06fdb959ef262050bd810416a2 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sat, 1 Jun 2024 12:25:35 -0600 Subject: [PATCH] io_uring: check for non-NULL file pointer in io_file_can_poll() In earlier kernels, it was possible to trigger a NULL pointer dereference off the forced async preparation path, if no file had been assigned. The trace leading to that looks as follows: BUG: kernel NULL pointer dereference, address: 00000000000000b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 RIP: 0010:io_buffer_select+0xc3/0x210 Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x14d/0x420 ? do_user_addr_fault+0x61/0x6a0 ? exc_page_fault+0x6c/0x150 ? asm_exc_page_fault+0x22/0x30 ? io_buffer_select+0xc3/0x210 __io_import_iovec+0xb5/0x120 io_readv_prep_async+0x36/0x70 io_queue_sqe_fallback+0x20/0x260 io_submit_sqes+0x314/0x630 __do_sys_io_uring_enter+0x339/0xbc0 ? __do_sys_io_uring_register+0x11b/0xc50 ? vm_mmap_pgoff+0xce/0x160 do_syscall_64+0x5f/0x180 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6 because the request is marked forced ASYNC and has a bad file fd, and hence takes the forced async prep path. Current kernels with the request async prep cleaned up can no longer hit this issue, but for ease of backporting, let's add this safety check in here too as it really doesn't hurt. For both cases, this will inevitably end with a CQE posted with -EBADF. Cc: stable(a)vger.kernel.org Fixes: a76c0b31eef5 ("io_uring: commit non-pollable provided mapped buffers upfront") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h index 624ca9076a50..726e6367af4d 100644 --- a/io_uring/io_uring.h +++ b/io_uring/io_uring.h @@ -433,7 +433,7 @@ static inline bool io_file_can_poll(struct io_kiocb *req) { if (req->flags & REQ_F_CAN_POLL) return true; - if (file_can_poll(req->file)) { + if (req->file && file_can_poll(req->file)) { req->flags |= REQ_F_CAN_POLL; return true; }

8 months, 2 weeks

2
1
0 0

Re: [PATCH 6.9 000/157] 6.9.5-rc1 review

by Ronald Warsow

Hi Greg +++ Update +++ the below crash seems to only to happen with mesa-24.1.x mesa-24.0.9 is fine filled a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2292434 ==== Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: Call Trace: Jun 13 18:49:22 obelix.fritz.box kernel: <TASK> Jun 13 18:49:22 obelix.fritz.box kernel: ? __die_body.cold+0x19/0x2c Jun 13 18:49:22 obelix.fritz.box kernel: ? page_fault_oops+0x155/0x280 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_module_extables+0x10/0x50 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_bpf_extables+0x56/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? exc_page_fault+0x7a/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? asm_exc_page_fault+0x22/0x30 Jun 13 18:49:22 obelix.fritz.box kernel: ? drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: xe_migrate_update_pgtables+0x692/0x9b0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? kmalloc_trace+0x11f/0x2d0 Jun 13 18:49:22 obelix.fritz.box kernel: __xe_pt_bind_vma+0x492/0xbe0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_vma+0xa6/0x2e0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind+0xf3/0x200 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __xe_vma_op_execute+0x278/0x490 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_ioctl+0x1ce0/0x1f20 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl_kernel+0xa7/0x100 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl+0x312/0x5c0 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __x64_sys_ioctl+0x40d/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: do_syscall_64+0x7a/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? __x64_sys_ioctl+0x13e/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: ? __count_memcg_events+0x43/0xb0 Jun 13 18:49:22 obelix.fritz.box kernel: ? handle_mm_fault+0x1f9/0x300 Jun 13 18:49:22 obelix.fritz.box kernel: ? syscall_exit_to_user_mode+0x68/0x1e0 Jun 13 18:49:22 obelix.fritz.box kernel: ? do_syscall_64+0x86/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0033:0x7fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 002b:00007fff94738650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: ffffffffffffffda RBX: 00007fff94738710 RCX: 00007fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00007fff94738710 RSI: 0000000040886445 RDI: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: 00007fff947386a0 R08: 0000000000001000 R09: 0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000555a7a0fded0 R11: 0000000000000246 R12: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: R13: 0000000000000000 R14: 0000555a78671160 R15: 0000555a7a234fa0 Jun 13 18:49:22 obelix.fritz.box kernel: </TASK> Jun 13 18:49:22 obelix.fritz.box kernel: Modules linked in: vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables bnep iwlmvm mac80211 libarc4 snd_hda_codec_hdmi intel_rapl_common kvm_intel iwlwifi snd_hda_codec_realtek kvm btusb snd_hda_codec_generic btintel snd_hda_scodec_component bluetooth snd_hda_intel cfg80211 snd_intel_dspcfg snd_hda_codec snd_hda_core mei_hdcp mei_pxp rfkill nfnetlink xe drm_ttm_helper ttm agpgart i2c_algo_bit gpu_sched drm_buddy drm_suballoc_helper drm_gpuvm drm_exec drm_display_helper drm_kms_helper drm Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 Jun 13 18:49:22 obelix.fritz.box kernel: ---[ end trace 0000000000000000 ]--- Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: note: Xorg[3657] exited with irqs disabled

8 months, 2 weeks

1
0
0 0

[PATCH] net: usb: ax88179_178a: fix link status when link is set to down/up

by Jose Ignacio Tornos Martinez

The idea was to keep only one reset at initialization stage in order to reduce the total delay, or the reset from usbnet_probe or the reset from usbnet_open. I have seen that restarting from usbnet_probe is necessary to avoid doing too complex things. But when the link is set to down/up (for example to configure a different mac address) the link is not correctly recovered unless a reset is commanded from usbnet_open. So, detect the initialization stage (first call) to not reset from usbnet_open after the reset from usbnet_probe and after this stage, always reset from usbnet_open too (when the link needs to be rechecked). Apply to all the possible devices, the behavior now is going to be the same. cc: stable(a)vger.kernel.org # 6.6+ Fixes: 56f78615bcb1 ("net: usb: ax88179_178a: avoid writing the mac address before first reading") Reported-by: Isaac Ganoung <inventor500(a)vivaldi.net> Reported-by: Yongqin Liu <yongqin.liu(a)linaro.org> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> --- drivers/net/usb/ax88179_178a.c | 37 ++++++++++++++++++++++++---------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c index 377be0d9ef14..a0edb410f746 100644 --- a/drivers/net/usb/ax88179_178a.c +++ b/drivers/net/usb/ax88179_178a.c @@ -174,6 +174,7 @@ struct ax88179_data { u32 wol_supported; u32 wolopts; u8 disconnecting; + u8 initialized; }; struct ax88179_int_data { @@ -1672,6 +1673,18 @@ static int ax88179_reset(struct usbnet *dev) return 0; } +static int ax88179_net_reset(struct usbnet *dev) +{ + struct ax88179_data *ax179_data = dev->driver_priv; + + if (ax179_data->initialized) + ax88179_reset(dev); + else + ax179_data->initialized = 1; + + return 0; +} + static int ax88179_stop(struct usbnet *dev) { u16 tmp16; @@ -1691,6 +1704,7 @@ static const struct driver_info ax88179_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1703,6 +1717,7 @@ static const struct driver_info ax88178a_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1715,7 +1730,7 @@ static const struct driver_info cypress_GX3_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1728,7 +1743,7 @@ static const struct driver_info dlink_dub1312_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1741,7 +1756,7 @@ static const struct driver_info sitecom_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1754,7 +1769,7 @@ static const struct driver_info samsung_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1767,7 +1782,7 @@ static const struct driver_info lenovo_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1780,7 +1795,7 @@ static const struct driver_info belkin_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1793,7 +1808,7 @@ static const struct driver_info toshiba_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1806,7 +1821,7 @@ static const struct driver_info mct_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1819,7 +1834,7 @@ static const struct driver_info at_umc2000_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1832,7 +1847,7 @@ static const struct driver_info at_umc200_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1845,7 +1860,7 @@ static const struct driver_info at_umc2000sp_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, + .reset = ax88179_net_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, -- 2.44.0

8 months, 2 weeks

4
12
0 0

[PATCH 6.6] backport: fix 6.6 backport of changes to fork

by Leah Rumancik

The original backport didn't move the code to link the vma into the MT and also the code to increment the map_count causing ~15 xfstests (including ext4/303 generic/051 generic/054 generic/069) to hard fail on some platforms. This patch resolves test failures. Fixes: cec11fa2eb51 ("fork: defer linking file vma until vma is fully initialized") Signed-off-by: Leah Rumancik <leah.rumancik(a)gmail.com> --- kernel/fork.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 2eab916b504b..3bf0203c2195 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -733,6 +733,12 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, if (is_vm_hugetlb_page(tmp)) hugetlb_dup_vma_private(tmp); + /* Link the vma into the MT */ + if (vma_iter_bulk_store(&vmi, tmp)) + goto fail_nomem_vmi_store; + + mm->map_count++; + if (tmp->vm_ops && tmp->vm_ops->open) tmp->vm_ops->open(tmp); @@ -752,11 +758,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, i_mmap_unlock_write(mapping); } - /* Link the vma into the MT */ - if (vma_iter_bulk_store(&vmi, tmp)) - goto fail_nomem_vmi_store; - - mm->map_count++; if (!(tmp->vm_flags & VM_WIPEONFORK)) retval = copy_page_range(tmp, mpnt); -- 2.45.1.288.g0e0cd299f1-goog

8 months, 2 weeks

3
6
0 0

[PATCH v2] kcov: don't lose track of remote references during softirqs

by Aleksandr Nogikh

In kcov_remote_start()/kcov_remote_stop(), we swap the previous KCOV metadata of the current task into a per-CPU variable. However, the kcov_mode_enabled(mode) check is not sufficient in the case of remote KCOV coverage: current->kcov_mode always remains KCOV_MODE_DISABLED for remote KCOV objects. If the original task that has invoked the KCOV_REMOTE_ENABLE ioctl happens to get interrupted and kcov_remote_start() is called, it ultimately leads to kcov_remote_stop() NOT restoring the original KCOV reference. So when the task exits, all registered remote KCOV handles remain active forever. Fix it by introducing a special kcov_mode that is assigned to the task that owns a KCOV remote object. It makes kcov_mode_enabled() return true and yet does not trigger coverage collection in __sanitizer_cov_trace_pc() and write_comp_data(). Cc: stable(a)vger.kernel.org Signed-off-by: Aleksandr Nogikh <nogikh(a)google.com> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Reviewed-by: Andrey Konovalov <andreyknvl(a)gmail.com> Tested-by: Andrey Konovalov <andreyknvl(a)gmail.com> Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts") --- Changes v1 -> v2: * Replaced WRITE_ONCE() with an ordinary assignment. * Added stable(a)vger.kernel.org to the Cc list. --- include/linux/kcov.h | 2 ++ kernel/kcov.c | 1 + 2 files changed, 3 insertions(+) diff --git a/include/linux/kcov.h b/include/linux/kcov.h index b851ba415e03..3b479a3d235a 100644 --- a/include/linux/kcov.h +++ b/include/linux/kcov.h @@ -21,6 +21,8 @@ enum kcov_mode { KCOV_MODE_TRACE_PC = 2, /* Collecting comparison operands mode. */ KCOV_MODE_TRACE_CMP = 3, + /* The process owns a KCOV remote reference. */ + KCOV_MODE_REMOTE = 4, }; #define KCOV_IN_CTXSW (1 << 30) diff --git a/kernel/kcov.c b/kernel/kcov.c index c3124f6d5536..f0a69d402066 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -632,6 +632,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, return -EINVAL; kcov->mode = mode; t->kcov = kcov; + t->kcov_mode = KCOV_MODE_REMOTE; kcov->t = t; kcov->remote = true; kcov->remote_size = remote_arg->area_size; -- 2.45.2.627.g7a2c4fd464-goog

8 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024