November 2024 - Linux-stable-mirror

[merged mm-hotfixes-stable] ucounts-fix-counter-leak-in-inc_rlimit_get_ucounts.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ucounts: fix counter leak in inc_rlimit_get_ucounts() has been removed from the -mm tree. Its filename was ucounts-fix-counter-leak-in-inc_rlimit_get_ucounts.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Andrei Vagin <avagin(a)google.com> Subject: ucounts: fix counter leak in inc_rlimit_get_ucounts() Date: Fri, 1 Nov 2024 19:19:40 +0000 The inc_rlimit_get_ucounts() increments the specified rlimit counter and then checks its limit. If the value exceeds the limit, the function returns an error without decrementing the counter. Link: https://lkml.kernel.org/r/20241101191940.3211128-1-roman.gushchin@linux.dev Fixes: 15bc01effefe ("ucounts: Fix signal ucount refcounting") Signed-off-by: Andrei Vagin <avagin(a)google.com> Co-developed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Signed-off-by: Roman Gushchin <roman.gushchin(a)linux.dev> Tested-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Alexey Gladkov <legion(a)kernel.org> Cc: Kees Cook <kees(a)kernel.org> Cc: Andrei Vagin <avagin(a)google.com> Cc: "Eric W. Biederman" <ebiederm(a)xmission.com> Cc: Alexey Gladkov <legion(a)kernel.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/ucount.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/ucount.c~ucounts-fix-counter-leak-in-inc_rlimit_get_ucounts +++ a/kernel/ucount.c @@ -317,7 +317,7 @@ long inc_rlimit_get_ucounts(struct ucoun for (iter = ucounts; iter; iter = iter->ns->ucounts) { long new = atomic_long_add_return(1, &iter->rlimit[type]); if (new < 0 || new > max) - goto unwind; + goto dec_unwind; if (iter == ucounts) ret = new; max = get_userns_rlimit_max(iter->ns, type); @@ -334,7 +334,6 @@ long inc_rlimit_get_ucounts(struct ucoun dec_unwind: dec = atomic_long_sub_return(1, &iter->rlimit[type]); WARN_ON_ONCE(dec < 0); -unwind: do_dec_rlimit_put_ucounts(ucounts, iter, type); return 0; } _ Patches currently in -mm which might be from avagin(a)google.com are

5 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] selftests-hugetlb_dio-check-for-initial-conditions-to-skip-in-the-start.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests: hugetlb_dio: check for initial conditions to skip in the start has been removed from the -mm tree. Its filename was selftests-hugetlb_dio-check-for-initial-conditions-to-skip-in-the-start.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Subject: selftests: hugetlb_dio: check for initial conditions to skip in the start Date: Fri, 1 Nov 2024 19:15:57 +0500 The test should be skipped if initial conditions aren't fulfilled in the start instead of failing and outputting non-compliant TAP logs. This kind of failure pollutes the results. The initial conditions are: - The test should only execute if /tmp file can be allocated. - The test should only execute if huge pages are free. Before: TAP version 13 1..4 Bail out! Error opening file : Read-only file system (30) # Planned tests != run tests (4 != 0) # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 After: TAP version 13 1..0 # SKIP Unable to allocate file: Read-only file system Link: https://lkml.kernel.org/r/20241101141557.3159432-1-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Fixes: 3a103b5315b7 ("selftest: mm: Test if hugepage does not get leaked during __bio_release_pages()") Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Donet Tom <donettom(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/hugetlb_dio.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) --- a/tools/testing/selftests/mm/hugetlb_dio.c~selftests-hugetlb_dio-check-for-initial-conditions-to-skip-in-the-start +++ a/tools/testing/selftests/mm/hugetlb_dio.c @@ -44,13 +44,6 @@ void run_dio_using_hugetlb(unsigned int if (fd < 0) ksft_exit_fail_perror("Error opening file\n"); - /* Get the free huge pages before allocation */ - free_hpage_b = get_free_hugepages(); - if (free_hpage_b == 0) { - close(fd); - ksft_exit_skip("No free hugepage, exiting!\n"); - } - /* Allocate a hugetlb page */ orig_buffer = mmap(NULL, h_pagesize, mmap_prot, mmap_flags, -1, 0); if (orig_buffer == MAP_FAILED) { @@ -94,8 +87,20 @@ void run_dio_using_hugetlb(unsigned int int main(void) { size_t pagesize = 0; + int fd; ksft_print_header(); + + /* Open the file to DIO */ + fd = open("/tmp", O_TMPFILE | O_RDWR | O_DIRECT, 0664); + if (fd < 0) + ksft_exit_skip("Unable to allocate file: %s\n", strerror(errno)); + close(fd); + + /* Check if huge pages are free */ + if (!get_free_hugepages()) + ksft_exit_skip("No free hugepage, exiting\n"); + ksft_set_plan(4); /* Get base page size */ _ Patches currently in -mm which might be from usama.anjum(a)collabora.com are

5 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-avoid-overflow-in-damon_feed_loop_next_input.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: avoid overflow in damon_feed_loop_next_input() has been removed from the -mm tree. Its filename was mm-damon-core-avoid-overflow-in-damon_feed_loop_next_input.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: avoid overflow in damon_feed_loop_next_input() Date: Thu, 31 Oct 2024 09:12:03 -0700 damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. Link: https://lkml.kernel.org/r/20241031161203.47751-1-sj@kernel.org Fixes: 9294a037c015 ("mm/damon/core: implement goal-oriented feedback-driven quota auto-tuning") Signed-off-by: SeongJae Park <sj(a)kernel.org> Reported-by: Guenter Roeck <linux(a)roeck-us.net> Closes: https://lore.kernel.org/944f3d5b-9177-48e7-8ec9-7f1331a3fea3@roeck-us.net Tested-by: Guenter Roeck <linux(a)roeck-us.net> Cc: <stable(a)vger.kernel.org> [6.8.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) --- a/mm/damon/core.c~mm-damon-core-avoid-overflow-in-damon_feed_loop_next_input +++ a/mm/damon/core.c @@ -1456,17 +1456,31 @@ static unsigned long damon_feed_loop_nex unsigned long score) { const unsigned long goal = 10000; - unsigned long score_goal_diff = max(goal, score) - min(goal, score); - unsigned long score_goal_diff_bp = score_goal_diff * 10000 / goal; - unsigned long compensation = last_input * score_goal_diff_bp / 10000; /* Set minimum input as 10000 to avoid compensation be zero */ const unsigned long min_input = 10000; + unsigned long score_goal_diff, compensation; + bool over_achieving = score > goal; - if (goal > score) + if (score == goal) + return last_input; + if (score >= goal * 2) + return min_input; + + if (over_achieving) + score_goal_diff = score - goal; + else + score_goal_diff = goal - score; + + if (last_input < ULONG_MAX / score_goal_diff) + compensation = last_input * score_goal_diff / goal; + else + compensation = last_input / goal * score_goal_diff; + + if (over_achieving) + return max(last_input - compensation, min_input); + if (last_input < ULONG_MAX - compensation) return last_input + compensation; - if (last_input > compensation + min_input) - return last_input - compensation; - return min_input; + return ULONG_MAX; } #ifdef CONFIG_PSI _ Patches currently in -mm which might be from sj(a)kernel.org are selftests-damon-huge_count_read_write-remove-unnecessary-debugging-message.patch selftests-damon-_debugfs_common-hide-expected-error-message-from-test_write_result.patch selftests-damon-debugfs_duplicate_context_creation-hide-errors-from-expected-file-write-failures.patch mm-damon-kconfig-update-dbgfs_kunit-prompt-copy-for-sysfs_kunit.patch mm-damon-tests-dbgfs-kunit-fix-the-header-double-inclusion-guarding-ifdef-comment.patch docs-mm-damon-recommend-academic-papers-to-read-and-or-cite.patch maintainers-memory-management-add-document-files-for-mm.patch

5 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-handle-zero-schemes-apply-interval.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: handle zero schemes apply interval has been removed from the -mm tree. Its filename was mm-damon-core-handle-zero-schemes-apply-interval.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: handle zero schemes apply interval Date: Thu, 31 Oct 2024 11:37:57 -0700 DAMON's logics to determine if this is the time to apply damos schemes assumes next_apply_sis is always set larger than current passed_sample_intervals. And therefore assume continuously incrementing passed_sample_intervals will make it reaches to the next_apply_sis in future. The logic hence does apply the scheme and update next_apply_sis only if passed_sample_intervals is same to next_apply_sis. If Schemes apply interval is set as zero, however, next_apply_sis is set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_apply_sis check. Hence, next_apply_sis becomes larger than next_apply_sis, and the logic says it is not the time to apply schemes and update next_apply_sis. In other words, DAMON stops applying schemes until passed_sample_intervals overflows. Based on the documents and the common sense, a reasonable behavior for such inputs would be applying the schemes for every sampling interval. Handle the case by removing the assumption. Link: https://lkml.kernel.org/r/20241031183757.49610-3-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/damon/core.c~mm-damon-core-handle-zero-schemes-apply-interval +++ a/mm/damon/core.c @@ -1412,7 +1412,7 @@ static void damon_do_apply_schemes(struc damon_for_each_scheme(s, c) { struct damos_quota *quota = &s->quota; - if (c->passed_sample_intervals != s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; if (!s->wmarks.activated) @@ -1622,7 +1622,7 @@ static void kdamond_apply_schemes(struct bool has_schemes_to_apply = false; damon_for_each_scheme(s, c) { - if (c->passed_sample_intervals != s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; if (!s->wmarks.activated) @@ -1642,9 +1642,9 @@ static void kdamond_apply_schemes(struct } damon_for_each_scheme(s, c) { - if (c->passed_sample_intervals != s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; - s->next_apply_sis += + s->next_apply_sis = c->passed_sample_intervals + (s->apply_interval_us ? s->apply_interval_us : c->attrs.aggr_interval) / sample_interval; } _ Patches currently in -mm which might be from sj(a)kernel.org are selftests-damon-huge_count_read_write-remove-unnecessary-debugging-message.patch selftests-damon-_debugfs_common-hide-expected-error-message-from-test_write_result.patch selftests-damon-debugfs_duplicate_context_creation-hide-errors-from-expected-file-write-failures.patch mm-damon-kconfig-update-dbgfs_kunit-prompt-copy-for-sysfs_kunit.patch mm-damon-tests-dbgfs-kunit-fix-the-header-double-inclusion-guarding-ifdef-comment.patch docs-mm-damon-recommend-academic-papers-to-read-and-or-cite.patch maintainers-memory-management-add-document-files-for-mm.patch

5 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-handle-zero-aggregationops_update-intervals.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: handle zero {aggregation,ops_update} intervals has been removed from the -mm tree. Its filename was mm-damon-core-handle-zero-aggregationops_update-intervals.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: handle zero {aggregation,ops_update} intervals Date: Thu, 31 Oct 2024 11:37:56 -0700 Patch series "mm/damon/core: fix handling of zero non-sampling intervals". DAMON's internal intervals accounting logic is not correctly handling non-sampling intervals of zero values for a wrong assumption. This could cause unexpected monitoring behavior, and even result in infinite hang of DAMON sysfs interface user threads in case of zero aggregation interval. Fix those by updating the intervals accounting logic. For details of the root case and solutions, please refer to commit messages of fixes. This patch (of 2): DAMON's logics to determine if this is the time to do aggregation and ops update assumes next_{aggregation,ops_update}_sis are always set larger than current passed_sample_intervals. And therefore it further assumes continuously incrementing passed_sample_intervals every sampling interval will make it reaches to the next_{aggregation,ops_update}_sis in future. The logic therefore make the action and update next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same to the counts, respectively. If Aggregation interval or Ops update interval are zero, however, next_aggregation_sis or next_ops_update_sis are set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_{aggregation,ops_update}_sis check. Hence, passed_sample_intervals becomes larger than next_{aggregation,ops_update}_sis, and the logic says it is not the time to do the action and update next_{aggregation,ops_update}_sis forever, until an overflow happens. In other words, DAMON stops doing aggregations or ops updates effectively forever, and users cannot get monitoring results. Based on the documents and the common sense, a reasonable behavior for such inputs is doing an aggregation and an ops update for every sampling interval. Handle the case by removing the assumption. Note that this could incur particular real issue for DAMON sysfs interface users, in case of zero Aggregation interval. When user starts DAMON with zero Aggregation interval and asks online DAMON parameter tuning via DAMON sysfs interface, the request is handled by the aggregation callback. Until the callback finishes the work, the user who requested the online tuning just waits. Hence, the user will be stuck until the passed_sample_intervals overflows. Link: https://lkml.kernel.org/r/20241031183757.49610-1-sj@kernel.org Link: https://lkml.kernel.org/r/20241031183757.49610-2-sj@kernel.org Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling as a timer") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.7.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/damon/core.c~mm-damon-core-handle-zero-aggregationops_update-intervals +++ a/mm/damon/core.c @@ -2000,7 +2000,7 @@ static int kdamond_fn(void *data) if (ctx->ops.check_accesses) max_nr_accesses = ctx->ops.check_accesses(ctx); - if (ctx->passed_sample_intervals == next_aggregation_sis) { + if (ctx->passed_sample_intervals >= next_aggregation_sis) { kdamond_merge_regions(ctx, max_nr_accesses / 10, sz_limit); @@ -2018,7 +2018,7 @@ static int kdamond_fn(void *data) sample_interval = ctx->attrs.sample_interval ? ctx->attrs.sample_interval : 1; - if (ctx->passed_sample_intervals == next_aggregation_sis) { + if (ctx->passed_sample_intervals >= next_aggregation_sis) { ctx->next_aggregation_sis = next_aggregation_sis + ctx->attrs.aggr_interval / sample_interval; @@ -2028,7 +2028,7 @@ static int kdamond_fn(void *data) ctx->ops.reset_aggregated(ctx); } - if (ctx->passed_sample_intervals == next_ops_update_sis) { + if (ctx->passed_sample_intervals >= next_ops_update_sis) { ctx->next_ops_update_sis = next_ops_update_sis + ctx->attrs.ops_update_interval / sample_interval; _ Patches currently in -mm which might be from sj(a)kernel.org are selftests-damon-huge_count_read_write-remove-unnecessary-debugging-message.patch selftests-damon-_debugfs_common-hide-expected-error-message-from-test_write_result.patch selftests-damon-debugfs_duplicate_context_creation-hide-errors-from-expected-file-write-failures.patch mm-damon-kconfig-update-dbgfs_kunit-prompt-copy-for-sysfs_kunit.patch mm-damon-tests-dbgfs-kunit-fix-the-header-double-inclusion-guarding-ifdef-comment.patch docs-mm-damon-recommend-academic-papers-to-read-and-or-cite.patch maintainers-memory-management-add-document-files-for-mm.patch

5 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-mlock-set-the-correct-prev-on-failure.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/mlock: set the correct prev on failure has been removed from the -mm tree. Its filename was mm-mlock-set-the-correct-prev-on-failure.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Wei Yang <richard.weiyang(a)gmail.com> Subject: mm/mlock: set the correct prev on failure Date: Sun, 27 Oct 2024 12:33:21 +0000 After commit 94d7d9233951 ("mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al."), if vma_modify_flags() return error, the vma is set to an error code. This will lead to an invalid prev be returned. Generally this shouldn't matter as the caller should treat an error as indicating state is now invalidated, however unfortunately apply_mlockall_flags() does not check for errors and assumes that mlock_fixup() correctly maintains prev even if an error were to occur. This patch fixes that assumption. [lorenzo.stoakes(a)oracle.com: provide a better fix and rephrase the log] Link: https://lkml.kernel.org/r/20241027123321.19511-1-richard.weiyang@gmail.com Fixes: 94d7d9233951 ("mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al.") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Jann Horn <jannh(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mlock.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/mm/mlock.c~mm-mlock-set-the-correct-prev-on-failure +++ a/mm/mlock.c @@ -725,14 +725,17 @@ static int apply_mlockall_flags(int flag } for_each_vma(vmi, vma) { + int error; vm_flags_t newflags; newflags = vma->vm_flags & ~VM_LOCKED_MASK; newflags |= to_add; - /* Ignore errors */ - mlock_fixup(&vmi, vma, &prev, vma->vm_start, vma->vm_end, - newflags); + error = mlock_fixup(&vmi, vma, &prev, vma->vm_start, vma->vm_end, + newflags); + /* Ignore errors, but prev needs fixing up. */ + if (error) + prev = vma; cond_resched(); } out: _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are maple_tree-print-empty-for-an-empty-tree-on-mt_dump.patch maple_tree-the-return-value-of-mas_root_expand-is-not-used.patch maple_tree-not-necessary-to-check-index-last-again.patch maple_tree-refine-mas_store_root-on-storing-null.patch maple_tree-add-a-test-checking-storing-null.patch

5 months, 3 weeks

1
0
0 0

[PATCH v6] media: uvcvideo: Fix crash during unbind if gpio unit is in use

by Ricardo Ribalda

We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error. Cc: stable(a)vger.kernel.org Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v6: - Rename cleanup as deinit - Move cleanup to the beginning of the uvc_unregister_video. - Fix commit message. - Link to v5: https://lore.kernel.org/r/20241105-uvc-crashrmmod-v5-1-8623fa51a74f@chromiu… Changes in v5: - Revert non refcount, that belongs to a different set - Move cleanup to a different function - Link to v4: https://lore.kernel.org/r/20241105-uvc-crashrmmod-v4-0-410e548f097a@chromiu… Changes in v4: Thanks Laurent. - Remove refcounted cleaup to support devres. - Link to v3: https://lore.kernel.org/r/20241105-uvc-crashrmmod-v3-1-c0959c8906d3@chromiu… Changes in v3: Thanks Sakari. - Rename variable to initialized. - Other CodeStyle. - Link to v2: https://lore.kernel.org/r/20241105-uvc-crashrmmod-v2-1-547ce6a6962e@chromiu… Changes in v2: Thanks to Laurent. - The main structure is not allocated with devres so there is a small period of time where we can get an irq with the structure free. Do not use devres for the IRQ. - Link to v1: https://lore.kernel.org/r/20241031-uvc-crashrmmod-v1-1-059fe593b1e6@chromiu… --- drivers/media/usb/uvc/uvc_driver.c | 28 +++++++++++++++++++++------- drivers/media/usb/uvc/uvcvideo.h | 1 + 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index a96f6ca0889f..cd13bf01265d 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1295,14 +1295,14 @@ static int uvc_gpio_parse(struct uvc_device *dev) struct gpio_desc *gpio_privacy; int irq; - gpio_privacy = devm_gpiod_get_optional(&dev->udev->dev, "privacy", + gpio_privacy = devm_gpiod_get_optional(&dev->intf->dev, "privacy", GPIOD_IN); if (IS_ERR_OR_NULL(gpio_privacy)) return PTR_ERR_OR_ZERO(gpio_privacy); irq = gpiod_to_irq(gpio_privacy); if (irq < 0) - return dev_err_probe(&dev->udev->dev, irq, + return dev_err_probe(&dev->intf->dev, irq, "No IRQ for privacy GPIO\n"); unit = uvc_alloc_new_entity(dev, UVC_EXT_GPIO_UNIT, @@ -1329,15 +1329,27 @@ static int uvc_gpio_parse(struct uvc_device *dev) static int uvc_gpio_init_irq(struct uvc_device *dev) { struct uvc_entity *unit = dev->gpio_unit; + int ret; if (!unit || unit->gpio.irq < 0) return 0; - return devm_request_threaded_irq(&dev->udev->dev, unit->gpio.irq, NULL, - uvc_gpio_irq, - IRQF_ONESHOT | IRQF_TRIGGER_FALLING | - IRQF_TRIGGER_RISING, - "uvc_privacy_gpio", dev); + ret = request_threaded_irq(unit->gpio.irq, NULL, uvc_gpio_irq, + IRQF_ONESHOT | IRQF_TRIGGER_FALLING | + IRQF_TRIGGER_RISING, + "uvc_privacy_gpio", dev); + + unit->gpio.initialized = !ret; + + return ret; +} + +static void uvc_gpio_deinit(struct uvc_device *dev) +{ + if (!dev->gpio_unit || !dev->gpio_unit->gpio.initialized) + return; + + free_irq(dev->gpio_unit->gpio.irq, dev); } /* ------------------------------------------------------------------------ @@ -1934,6 +1946,8 @@ static void uvc_unregister_video(struct uvc_device *dev) { struct uvc_streaming *stream; + uvc_gpio_deinit(dev); + list_for_each_entry(stream, &dev->streams, list) { /* Nothing to do here, continue. */ if (!video_is_registered(&stream->vdev)) diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 07f9921d83f2..965a789ed03e 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -234,6 +234,7 @@ struct uvc_entity { u8 *bmControls; struct gpio_desc *gpio_privacy; int irq; + bool initialized; } gpio; }; --- base-commit: c7ccf3683ac9746b263b0502255f5ce47f64fe0a change-id: 20241031-uvc-crashrmmod-666de3fc9141 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

5 months, 3 weeks

2
1
0 0

[to-be-updated] mm-fix-__wp_page_copy_user-fallback-path-for-remote-mm.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: fix __wp_page_copy_user fallback path for remote mm has been removed from the -mm tree. Its filename was mm-fix-__wp_page_copy_user-fallback-path-for-remote-mm.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Asahi Lina <lina(a)asahilina.net> Subject: mm: fix __wp_page_copy_user fallback path for remote mm Date: Fri, 01 Nov 2024 21:08:02 +0900 If the source page is a PFN mapping, we copy back from userspace. However, if this fault is a remote access, we cannot use __copy_from_user_inatomic. Instead, use access_remote_vm() in this case. Fixes WARN and incorrect zero-filling when writing to CoW mappings in a remote process, such as when using gdb on a binary present on a DAX filesystem. [ 143.683782] ------------[ cut here ]------------ [ 143.683784] WARNING: CPU: 1 PID: 350 at mm/memory.c:2904 __wp_page_copy_user+0x120/0x2bc [ 143.683793] CPU: 1 PID: 350 Comm: gdb Not tainted 6.6.52 #1 [ 143.683794] Hardware name: linux,dummy-virt (DT) [ 143.683795] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 143.683796] pc : __wp_page_copy_user+0x120/0x2bc [ 143.683798] lr : __wp_page_copy_user+0x254/0x2bc [ 143.683799] sp : ffff80008272b8b0 [ 143.683799] x29: ffff80008272b8b0 x28: 0000000000000000 x27: ffff000083bad580 [ 143.683801] x26: 0000000000000000 x25: 0000fffff7fd5000 x24: ffff000081db04c0 [ 143.683802] x23: ffff00014f24b000 x22: fffffc00053c92c0 x21: ffff000083502150 [ 143.683803] x20: 0000fffff7fd5000 x19: ffff80008272b9d0 x18: 0000000000000000 [ 143.683804] x17: ffff000081db0500 x16: ffff800080fe52a0 x15: 0000fffff7fd5000 [ 143.683804] x14: 0000000000bb1845 x13: 0000000000000080 x12: ffff80008272b880 [ 143.683805] x11: ffff000081d13600 x10: ffff000081d13608 x9 : ffff000081d1360c [ 143.683806] x8 : ffff000083a16f00 x7 : 0000000000000010 x6 : ffff00014f24b000 [ 143.683807] x5 : ffff00014f24c000 x4 : 0000000000000000 x3 : ffff000083582000 [ 143.683807] x2 : 0000000000000f80 x1 : 0000fffff7fd5000 x0 : 0000000000001000 [ 143.683808] Call trace: [ 143.683809] __wp_page_copy_user+0x120/0x2bc [ 143.683810] wp_page_copy+0x98/0x5c0 [ 143.683813] do_wp_page+0x250/0x530 [ 143.683814] __handle_mm_fault+0x278/0x284 [ 143.683817] handle_mm_fault+0x64/0x1e8 [ 143.683819] faultin_page+0x5c/0x110 [ 143.683820] __get_user_pages+0xc8/0x2f4 [ 143.683821] get_user_pages_remote+0xac/0x30c [ 143.683823] __access_remote_vm+0xb4/0x368 [ 143.683824] access_remote_vm+0x10/0x1c [ 143.683826] mem_rw.isra.0+0xc4/0x218 [ 143.683831] mem_write+0x18/0x24 [ 143.683831] vfs_write+0xa0/0x37c [ 143.683834] ksys_pwrite64+0x7c/0xc0 [ 143.683834] __arm64_sys_pwrite64+0x20/0x2c [ 143.683835] invoke_syscall+0x48/0x10c [ 143.683837] el0_svc_common.constprop.0+0x40/0xe0 [ 143.683839] do_el0_svc+0x1c/0x28 [ 143.683841] el0_svc+0x3c/0xdc [ 143.683846] el0t_64_sync_handler+0x120/0x12c [ 143.683848] el0t_64_sync+0x194/0x198 [ 143.683849] ---[ end trace 0000000000000000 ]--- [akpm(a)linux-foundation.org: coding style tweaks] Link: https://lkml.kernel.org/r/20241101-mm-remote-pfn-v1-1-080b609270b7@asahilin… Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Signed-off-by: Asahi Lina <lina(a)asahilina.net> Cc: Jia He <justin.he(a)arm.com> Cc: Yibo Cai <Yibo.Cai(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Asahi Lina <lina(a)asahilina.net> Cc: Sergio Lopez Pascual <slp(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) --- a/mm/memory.c~mm-fix-__wp_page_copy_user-fallback-path-for-remote-mm +++ a/mm/memory.c @@ -3082,12 +3082,19 @@ static inline int __wp_page_copy_user(st } /* - * This really shouldn't fail, because the page is there - * in the page tables. But it might just be unreadable, - * in which case we just give up and fill the result with - * zeroes. + * If the mm is a remote mm, copy in the page using access_remote_vm() */ - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + if (current->mm != mm) { + if (access_remote_vm(mm, (unsigned long)uaddr, kaddr, + PAGE_SIZE, 0) != PAGE_SIZE) + goto warn; + } else if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + /* + * This really shouldn't fail, because the page is there + * in the page tables. But it might just be unreadable, + * in which case we just give up and fill the result with + * zeroes. + */ if (vmf->pte) goto warn; _ Patches currently in -mm which might be from lina(a)asahilina.net are

5 months, 3 weeks

1
0
0 0

[PATCH net v2] net: phy: dp83869: fix status reporting for 1000base-x autonegotiation

by Romain Gantois

The DP83869 PHY transceiver supports converting from RGMII to 1000base-x. In this operation mode, autonegotiation can be performed, as described in IEEE802.3. The DP83869 has a set of fiber-specific registers located at offset 0xc00. When the transceiver is configured in RGMII-to-1000base-x mode, these registers are mapped onto offset 0, which should, in theory, make reading the autonegotiation status transparent. However, the fiber registers at offset 0xc04 and 0xc05 do not follow the bit layout of their standard counterparts. Thus, genphy_read_status() doesn't properly read the capabilities advertised by the link partner, resulting in incorrect link parameters. Similarly, genphy_config_aneg() doesn't properly write advertised capabilities. Fix the 1000base-x autonegotiation procedure by replacing genphy_read_status() and genphy_config_aneg() with driver-specific functions which take into account the nonstandard bit layout of the DP83869 registers in 1000base-x mode. Fixes: a29de52ba2a1 ("net: dp83869: Add ability to advertise Fiber connection") Cc: stable(a)vger.kernel.org Signed-off-by: Romain Gantois <romain.gantois(a)bootlin.com> --- Changes in v2: - Fixed an uninitialized use. - Link to v1: https://lore.kernel.org/r/20241029-dp83869-1000base-x-v1-1-fcafe360bd98@boo… --- drivers/net/phy/dp83869.c | 130 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 127 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c index 5f056d7db83eed23f1cab42365fdc566a0d8e47f..ca1c247d478ced890a3c7ae97b855f20056eb916 100644 --- a/drivers/net/phy/dp83869.c +++ b/drivers/net/phy/dp83869.c @@ -41,6 +41,8 @@ #define DP83869_IO_MUX_CFG 0x0170 #define DP83869_OP_MODE 0x01df #define DP83869_FX_CTRL 0x0c00 +#define DP83869_FX_ANADV 0x0c04 +#define DP83869_FX_LPABL 0x0c05 #define DP83869_SW_RESET BIT(15) #define DP83869_SW_RESTART BIT(14) @@ -135,6 +137,17 @@ #define DP83869_DOWNSHIFT_4_COUNT 4 #define DP83869_DOWNSHIFT_8_COUNT 8 +/* FX_ANADV bits */ +#define DP83869_BP_FULL_DUPLEX BIT(5) +#define DP83869_BP_PAUSE BIT(7) +#define DP83869_BP_ASYMMETRIC_PAUSE BIT(8) + +/* FX_LPABL bits */ +#define DP83869_LPA_1000FULL BIT(5) +#define DP83869_LPA_PAUSE_CAP BIT(7) +#define DP83869_LPA_PAUSE_ASYM BIT(8) +#define DP83869_LPA_LPACK BIT(14) + enum { DP83869_PORT_MIRRORING_KEEP, DP83869_PORT_MIRRORING_EN, @@ -153,19 +166,129 @@ struct dp83869_private { int mode; }; +static int dp83869_config_aneg(struct phy_device *phydev) +{ + struct dp83869_private *dp83869 = phydev->priv; + unsigned long *advertising; + int err, changed = false; + u32 adv = 0; + + if (dp83869->mode != DP83869_RGMII_1000_BASE) + return genphy_config_aneg(phydev); + + /* Forcing speed or duplex isn't supported in 1000base-x mode */ + if (phydev->autoneg != AUTONEG_ENABLE) + return 0; + + /* In fiber modes, register locations 0xc0... get mapped to offset 0. + * Unfortunately, the fiber-specific autonegotiation advertisement + * register at address 0xc04 does not have the same bit layout as the + * corresponding standard MII_ADVERTISE register. Thus, functions such + * as genphy_config_advert() will write the advertisement register + * incorrectly. + */ + advertising = phydev->advertising; + + /* Only allow advertising what this PHY supports */ + linkmode_and(advertising, advertising, + phydev->supported); + + if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT, advertising)) + adv |= DP83869_BP_FULL_DUPLEX; + if (linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT, advertising)) + adv |= DP83869_BP_PAUSE; + if (linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, advertising)) + adv |= DP83869_BP_ASYMMETRIC_PAUSE; + + err = phy_modify_changed(phydev, DP83869_FX_ANADV, + DP83869_BP_FULL_DUPLEX | DP83869_BP_PAUSE | + DP83869_BP_ASYMMETRIC_PAUSE, + adv); + + if (err < 0) + return err; + else if (err) + changed = true; + + return genphy_check_and_restart_aneg(phydev, changed); +} + +static int dp83869_read_status_fiber(struct phy_device *phydev) +{ + int err, lpa, old_link = phydev->link; + unsigned long *lp_advertising; + + err = genphy_update_link(phydev); + if (err) + return err; + + if (phydev->autoneg == AUTONEG_ENABLE && old_link && phydev->link) + return 0; + + phydev->speed = SPEED_UNKNOWN; + phydev->duplex = DUPLEX_UNKNOWN; + phydev->pause = 0; + phydev->asym_pause = 0; + + lp_advertising = phydev->lp_advertising; + + if (phydev->autoneg != AUTONEG_ENABLE) { + linkmode_zero(lp_advertising); + + phydev->duplex = DUPLEX_FULL; + phydev->speed = SPEED_1000; + + return 0; + } + + if (!phydev->autoneg_complete) { + linkmode_zero(lp_advertising); + return 0; + } + + /* In fiber modes, register locations 0xc0... get mapped to offset 0. + * Unfortunately, the fiber-specific link partner capabilities register + * at address 0xc05 does not have the same bit layout as the + * corresponding standard MII_LPA register. Thus, functions such as + * genphy_read_lpa() will read autonegotiation results incorrectly. + */ + + lpa = phy_read(phydev, DP83869_FX_LPABL); + if (lpa < 0) + return lpa; + + linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT, + lp_advertising, lpa & DP83869_LPA_1000FULL); + + linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT, lp_advertising, + lpa & DP83869_LPA_PAUSE_CAP); + + linkmode_mod_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, lp_advertising, + lpa & DP83869_LPA_PAUSE_ASYM); + + linkmode_mod_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, + lp_advertising, lpa & DP83869_LPA_LPACK); + + phy_resolve_aneg_linkmode(phydev); + + return 0; +} + static int dp83869_read_status(struct phy_device *phydev) { struct dp83869_private *dp83869 = phydev->priv; int ret; + if (dp83869->mode == DP83869_RGMII_1000_BASE) + return dp83869_read_status_fiber(phydev); + ret = genphy_read_status(phydev); if (ret) return ret; - if (linkmode_test_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, phydev->supported)) { + if (dp83869->mode == DP83869_RGMII_100_BASE) { if (phydev->link) { - if (dp83869->mode == DP83869_RGMII_100_BASE) - phydev->speed = SPEED_100; + phydev->speed = SPEED_100; } else { phydev->speed = SPEED_UNKNOWN; phydev->duplex = DUPLEX_UNKNOWN; @@ -898,6 +1021,7 @@ static int dp83869_phy_reset(struct phy_device *phydev) .soft_reset = dp83869_phy_reset, \ .config_intr = dp83869_config_intr, \ .handle_interrupt = dp83869_handle_interrupt, \ + .config_aneg = dp83869_config_aneg, \ .read_status = dp83869_read_status, \ .get_tunable = dp83869_get_tunable, \ .set_tunable = dp83869_set_tunable, \ --- base-commit: 5ccdcdf186aec6b9111845fd37e1757e9b413e2f change-id: 20241025-dp83869-1000base-x-0f0a61725784 Best regards, -- Romain Gantois <romain.gantois(a)bootlin.com>

5 months, 3 weeks

3
2
0 0

[PATCH] drm/panthor: Be stricter about IO mapping flags

by Jann Horn

The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it. Cc: stable(a)vger.kernel.org Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Signed-off-by: Jann Horn <jannh(a)google.com> --- First testcase (can write to the FLUSH_ID): ``` typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) int main(void) { int fd = SYSCHK(open(GPU_PATH, O_RDWR)); // sanity-check that PROT_WRITE+MAP_SHARED fails void *mmap_write_res = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET); if (mmap_write_res == MAP_FAILED) { perror("mmap() with PROT_WRITE+MAP_SHARED failed as expected"); } else { errx(1, "mmap() with PROT_WRITE+MAP_SHARED worked???"); } // make a PROT_READ+MAP_SHARED mapping, and upgrade it to writable void *mmio_page = SYSCHK(mmap(NULL, 0x1000, PROT_READ, MAP_SHARED, fd, DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET)); SYSCHK(mprotect(mmio_page, 0x1000, PROT_READ|PROT_WRITE)); volatile uint32_t *flush_counter = (volatile uint32_t*)mmio_page; uint32_t last_old = -1; while (1) { uint32_t old_val = *flush_counter; *flush_counter = 1111; uint32_t new_val = *flush_counter; if (old_val != last_old) printf("flush counter: old=%u, new=%u\n", old_val, new_val); last_old = old_val; } } ``` Second testcase (triggers BUG() splat): ``` typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) int main(void) { int fd = SYSCHK(open(GPU_PATH, O_RDWR)); // make a PROT_READ+**MAP_PRIVATE** mapping void *ptr = SYSCHK(mmap(NULL, 0x1000, PROT_READ, MAP_PRIVATE, fd, DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET)); // trigger a read fault *(volatile char *)ptr; } ``` The second testcase splats like this: ``` [ 2918.411814] ------------[ cut here ]------------ [ 2918.411857] kernel BUG at mm/memory.c:2220! [ 2918.411955] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [...] [ 2918.416147] CPU: 3 PID: 2934 Comm: private_user_fl Tainted: G O 6.1.43-19-rk2312 #428a0a5e6 [ 2918.417043] Hardware name: Radxa ROCK 5B (DT) [ 2918.417464] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2918.418119] pc : vmf_insert_pfn_prot+0x40/0xe4 [ 2918.418567] lr : panthor_mmio_vm_fault+0xb0/0x12c [panthor] [...] [ 2918.425746] Call trace: [ 2918.425972] vmf_insert_pfn_prot+0x40/0xe4 [ 2918.426342] __do_fault+0x38/0x7c [ 2918.426648] __handle_mm_fault+0x404/0x6dc [ 2918.427018] handle_mm_fault+0x13c/0x18c [ 2918.427374] do_page_fault+0x194/0x33c [ 2918.427716] do_translation_fault+0x60/0x7c [ 2918.428095] do_mem_abort+0x44/0x90 [ 2918.428410] el0_da+0x40/0x68 [ 2918.428685] el0t_64_sync_handler+0x9c/0xf8 [ 2918.429067] el0t_64_sync+0x174/0x178 ``` --- drivers/gpu/drm/panthor/panthor_device.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c index 4082c8f2951dfdace7f73a24d6fe34e9e7f920eb..6fbff516c1c1f047fcb4dee17b87d8263616dc0c 100644 --- a/drivers/gpu/drm/panthor/panthor_device.c +++ b/drivers/gpu/drm/panthor/panthor_device.c @@ -390,11 +390,15 @@ int panthor_device_mmap_io(struct panthor_device *ptdev, struct vm_area_struct * { u64 offset = (u64)vma->vm_pgoff << PAGE_SHIFT; + if ((vma->vm_flags & VM_SHARED) == 0) + return -EINVAL; + switch (offset) { case DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET: if (vma->vm_end - vma->vm_start != PAGE_SIZE || (vma->vm_flags & (VM_WRITE | VM_EXEC))) return -EINVAL; + vm_flags_clear(vma, VM_MAYWRITE); break; --- base-commit: d78f0ee0406803cda8801fd5201746ccf89e5e4a change-id: 20241104-panthor-flush-page-fixes-fe4202bb18c0 -- Jann Horn <jannh(a)google.com>

5 months, 3 weeks

4
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024