The patch titled
Subject: mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-khugepaged-fix-collapse_pte_mapped_thp-to-allow-anon_vma.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: Hugh Dickins <hughd(a)google.com>
Subject: mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
Date: Thu, 22 Dec 2022 12:41:50 -0800 (PST)
uprobe_write_opcode() uses collapse_pte_mapped_thp() to restore huge pmd,
when removing a breakpoint from hugepage text: vma->anon_vma is always set
in that case, so undo the prohibition. And MADV_COLLAPSE ought to be able
to collapse some page tables in a vma which happens to have anon_vma set
from CoWing elsewhere.
Is anon_vma lock required? Almost not: if any page other than expected
subpage of the non-anon huge page is found in the page table, collapse is
aborted without making any change. However, it is possible that an anon
page was CoWed from this extent in another mm or vma, in which case a
concurrent lookup might look here: so keep it away while clearing pmd (but
perhaps we shall go back to using pmd_lock() there in future).
Note that collapse_pte_mapped_thp() is exceptional in freeing a page table
without having cleared its ptes: I'm uneasy about that, and had thought
pte_clear()ing appropriate; but exclusive i_mmap lock does fix the
problem, and we would have to move the mmu_notification if clearing those
ptes.
What this fixes is not a dangerous instability. But I suggest Cc stable
because uprobes "healing" has regressed in that way, so this should follow
8d3c106e19e8 into those stable releases where it was backported (and may
want adjustment there - I'll supply backports as needed).
Link: https://lkml.kernel.org/r/b740c9fb-edba-92ba-59fb-7a5592e5dfc@google.com
Fixes: 8d3c106e19e8 ("mm/khugepaged: take the right locks for page table retraction")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Cc: Jann Horn <jannh(a)google.com>
Cc: Yang Shi <shy828301(a)gmail.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Zach O'Keefe <zokeefe(a)google.com>
Cc: Song Liu <songliubraving(a)fb.com>
Cc: <stable(a)vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/khugepaged.c~mm-khugepaged-fix-collapse_pte_mapped_thp-to-allow-anon_vma
+++ a/mm/khugepaged.c
@@ -1460,14 +1460,6 @@ int collapse_pte_mapped_thp(struct mm_st
if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false))
return SCAN_VMA_CHECK;
- /*
- * Symmetry with retract_page_tables(): Exclude MAP_PRIVATE mappings
- * that got written to. Without this, we'd have to also lock the
- * anon_vma if one exists.
- */
- if (vma->anon_vma)
- return SCAN_VMA_CHECK;
-
/* Keep pmd pgtable for uffd-wp; see comment in retract_page_tables() */
if (userfaultfd_wp(vma))
return SCAN_PTE_UFFD_WP;
@@ -1567,8 +1559,14 @@ int collapse_pte_mapped_thp(struct mm_st
}
/* step 4: remove pte entries */
+ /* we make no change to anon, but protect concurrent anon page lookup */
+ if (vma->anon_vma)
+ anon_vma_lock_write(vma->anon_vma);
+
collapse_and_free_pmd(mm, vma, haddr, pmd);
+ if (vma->anon_vma)
+ anon_vma_unlock_write(vma->anon_vma);
i_mmap_unlock_write(vma->vm_file->f_mapping);
maybe_install_pmd:
_
Patches currently in -mm which might be from hughd(a)google.com are
mm-khugepaged-fix-collapse_pte_mapped_thp-to-allow-anon_vma.patch
The patch titled
Subject: mm/hugetlb: fix uffd-wp handling for migration entries in hugetlb_change_protection()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-hugetlb-fix-uffd-wp-handling-for-migration-entries-in-hugetlb_change_protection.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: David Hildenbrand <david(a)redhat.com>
Subject: mm/hugetlb: fix uffd-wp handling for migration entries in hugetlb_change_protection()
Date: Thu, 22 Dec 2022 21:55:11 +0100
We have to update the uffd-wp SWP PTE bit independent of the type of
migration entry. Currently, if we're unlucky and we want to install/clear
the uffd-wp bit just while we're migrating a read-only mapped hugetlb
page, we would miss to set/clear the uffd-wp bit.
Further, if we're processing a readable-exclusive migration entry and
neither want to set or clear the uffd-wp bit, we could currently end up
losing the uffd-wp bit. Note that the same would hold for writable
migrating entries, however, having a writable migration entry with the
uffd-wp bit set would already mean that something went wrong.
Note that the change from !is_readable_migration_entry ->
writable_migration_entry is harmless and actually cleaner, as raised by
Miaohe Lin and discussed in [1].
[1] https://lkml.kernel.org/r/90dd6a93-4500-e0de-2bf0-bf522c311b0c@huawei.com
Link: https://lkml.kernel.org/r/20221222205511.675832-3-david@redhat.com
Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Cc: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Muchun Song <muchun.song(a)linux.dev>
Cc: Peter Xu <peterx(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/hugetlb.c~mm-hugetlb-fix-uffd-wp-handling-for-migration-entries-in-hugetlb_change_protection
+++ a/mm/hugetlb.c
@@ -6662,10 +6662,9 @@ unsigned long hugetlb_change_protection(
} else if (unlikely(is_hugetlb_entry_migration(pte))) {
swp_entry_t entry = pte_to_swp_entry(pte);
struct page *page = pfn_swap_entry_to_page(entry);
+ pte_t newpte = pte;
- if (!is_readable_migration_entry(entry)) {
- pte_t newpte;
-
+ if (is_writable_migration_entry(entry)) {
if (PageAnon(page))
entry = make_readable_exclusive_migration_entry(
swp_offset(entry));
@@ -6673,13 +6672,15 @@ unsigned long hugetlb_change_protection(
entry = make_readable_migration_entry(
swp_offset(entry));
newpte = swp_entry_to_pte(entry);
- if (uffd_wp)
- newpte = pte_swp_mkuffd_wp(newpte);
- else if (uffd_wp_resolve)
- newpte = pte_swp_clear_uffd_wp(newpte);
- set_huge_pte_at(mm, address, ptep, newpte);
pages++;
}
+
+ if (uffd_wp)
+ newpte = pte_swp_mkuffd_wp(newpte);
+ else if (uffd_wp_resolve)
+ newpte = pte_swp_clear_uffd_wp(newpte);
+ if (!pte_same(pte, newpte))
+ set_huge_pte_at(mm, address, ptep, newpte);
} else if (unlikely(is_pte_marker(pte))) {
/* No other markers apply for now. */
WARN_ON_ONCE(!pte_marker_uffd_wp(pte));
_
Patches currently in -mm which might be from david(a)redhat.com are
mm-hugetlb-fix-pte-marker-handling-in-hugetlb_change_protection.patch
mm-hugetlb-fix-uffd-wp-handling-for-migration-entries-in-hugetlb_change_protection.patch
The patch titled
Subject: mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-hugetlb-fix-pte-marker-handling-in-hugetlb_change_protection.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: David Hildenbrand <david(a)redhat.com>
Subject: mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()
Date: Thu, 22 Dec 2022 21:55:10 +0100
Patch series "mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()".
Playing with virtio-mem and background snapshots (using uffd-wp) on
hugetlb in QEMU, I managed to trigger a VM_BUG_ON(). Looking into the
details, hugetlb_change_protection() seems to not handle uffd-wp correctly
in all cases.
Patch #1 fixes my test case. I don't have reproducers for patch #2, as it
requires running into migration entries.
I did not yet check in detail yet if !hugetlb code requires similar care.
This patch (of 2):
There are two problematic cases when stumbling over a PTE marker in
hugetlb_change_protection():
(1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will
end up in the "!huge_pte_none(pte)" case and mess up the PTE marker.
(2) We unprotect a uffd-wp PTE marker: we will similarly end up in the
"!huge_pte_none(pte)" case even though we cleared the PTE, because
the "pte" variable is stale. We'll mess up the PTE marker.
For example, if we later stumble over such a "wrongly modified" PTE marker,
we'll treat it like a present PTE that maps some garbage page.
This can, for example, be triggered by mapping a memfd backed by huge
pages, registering uffd-wp, uffd-wp'ing an unmapped page and (a)
uffd-wp'ing it a second time; or (b) uffd-unprotecting it; or (c)
unregistering uffd-wp. Then, ff we trigger fallocate(FALLOC_FL_PUNCH_HOLE)
on that file range, we will run into a VM_BUG_ON:
[ 195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0
[ 195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff)
[ 195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 0000000000000000
[ 195.039569] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 195.039569] page dumped because: VM_BUG_ON_PAGE(compound && !PageHead(page))
[ 195.039573] ------------[ cut here ]------------
[ 195.039574] kernel BUG at mm/rmap.c:1346!
[ 195.039579] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 Not tainted 6.0.12-200.fc36.x86_64 #1
[ 195.039583] Hardware name: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50 ) 09/15/2022
[ 195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550
[ 195.039588] Code: [...]
[ 195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292
[ 195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000
[ 195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff
[ 195.039592] RBP: 0000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08
[ 195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0
[ 195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100
[ 195.039595] FS: 00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000
[ 195.039596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0
[ 195.039598] PKRU: 55555554
[ 195.039599] Call Trace:
[ 195.039600] <TASK>
[ 195.039602] __unmap_hugepage_range+0x33b/0x7d0
[ 195.039605] unmap_hugepage_range+0x55/0x70
[ 195.039608] hugetlb_vmdelete_list+0x77/0xa0
[ 195.039611] hugetlbfs_fallocate+0x410/0x550
[ 195.039612] ? _raw_spin_unlock_irqrestore+0x23/0x40
[ 195.039616] vfs_fallocate+0x12e/0x360
[ 195.039618] __x64_sys_fallocate+0x40/0x70
[ 195.039620] do_syscall_64+0x58/0x80
[ 195.039623] ? syscall_exit_to_user_mode+0x17/0x40
[ 195.039624] ? do_syscall_64+0x67/0x80
[ 195.039626] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 195.039628] RIP: 0033:0x7fc7b590651f
[ 195.039653] Code: [...]
[ 195.039654] RSP: 002b:00007fc7aaf66e70 EFLAGS: 00000293 ORIG_RAX: 000000000000011d
[ 195.039655] RAX: ffffffffffffffda RBX: 0000558ef4b7f370 RCX: 00007fc7b590651f
[ 195.039656] RDX: 0000000018000000 RSI: 0000000000000003 RDI: 000000000000000c
[ 195.039657] RBP: 0000000008000000 R08: 0000000000000000 R09: 0000000000000073
[ 195.039658] R10: 0000000008000000 R11: 0000000000000293 R12: 0000000018000000
[ 195.039658] R13: 00007fb8bbe00000 R14: 000000000000000c R15: 0000000000001000
[ 195.039661] </TASK>
Fix it by not going into the "!huge_pte_none(pte)" case if we stumble over
an exclusive marker. spin_unlock() + continue would get the job done.
However, instead, make it clearer that there are no fall-through
statements: we process each case (hwpoison, migration, marker, !none,
none) and then unlock the page table to continue with the next PTE. Let's
avoid "continue" statements and use a single spin_unlock() at the end.
Link: https://lkml.kernel.org/r/20221222205511.675832-1-david@redhat.com
Link: https://lkml.kernel.org/r/20221222205511.675832-2-david@redhat.com
Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Cc: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Muchun Song <muchun.song(a)linux.dev>
Cc: Peter Xu <peterx(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/hugetlb.c~mm-hugetlb-fix-pte-marker-handling-in-hugetlb_change_protection
+++ a/mm/hugetlb.c
@@ -6658,10 +6658,8 @@ unsigned long hugetlb_change_protection(
}
pte = huge_ptep_get(ptep);
if (unlikely(is_hugetlb_entry_hwpoisoned(pte))) {
- spin_unlock(ptl);
- continue;
- }
- if (unlikely(is_hugetlb_entry_migration(pte))) {
+ /* Nothing to do. */
+ } else if (unlikely(is_hugetlb_entry_migration(pte))) {
swp_entry_t entry = pte_to_swp_entry(pte);
struct page *page = pfn_swap_entry_to_page(entry);
@@ -6682,18 +6680,13 @@ unsigned long hugetlb_change_protection(
set_huge_pte_at(mm, address, ptep, newpte);
pages++;
}
- spin_unlock(ptl);
- continue;
- }
- if (unlikely(pte_marker_uffd_wp(pte))) {
- /*
- * This is changing a non-present pte into a none pte,
- * no need for huge_ptep_modify_prot_start/commit().
- */
+ } else if (unlikely(is_pte_marker(pte))) {
+ /* No other markers apply for now. */
+ WARN_ON_ONCE(!pte_marker_uffd_wp(pte));
if (uffd_wp_resolve)
+ /* Safe to modify directly (non-present->none). */
huge_pte_clear(mm, address, ptep, psize);
- }
- if (!huge_pte_none(pte)) {
+ } else if (!huge_pte_none(pte)) {
pte_t old_pte;
unsigned int shift = huge_page_shift(hstate_vma(vma));
_
Patches currently in -mm which might be from david(a)redhat.com are
mm-hugetlb-fix-pte-marker-handling-in-hugetlb_change_protection.patch
mm-hugetlb-fix-uffd-wp-handling-for-migration-entries-in-hugetlb_change_protection.patch
Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be
restricted on asymmetric systems"), the setting and clearing of
user_cpus_ptr are done under pi_lock for arm64 architecture. However,
dup_user_cpus_ptr() accesses user_cpus_ptr without any lock
protection. When racing with the clearing of user_cpus_ptr in
__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and
double-free in arm64 kernel.
Commit 8f9ea86fdf99 ("sched: Always preserve the user requested
cpumask") fixes this problem as user_cpus_ptr, once set, will never
be cleared in a task's lifetime. However, this bug was re-introduced
in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in
do_set_cpus_allowed(). This time, it will affect all arches.
Fix this bug by always clearing the user_cpus_ptr of the newly
cloned/forked task before the copying process starts and check the
user_cpus_ptr state of the source task under pi_lock.
Note to stable, this patch won't be applicable to stable releases.
Just copy the new dup_user_cpus_ptr() function over.
Fixes: 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems")
Fixes: 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()")
CC: stable(a)vger.kernel.org
Reported-by: David Wang 王标 <wangbiao3(a)xiaomi.com>
Signed-off-by: Waiman Long <longman(a)redhat.com>
---
kernel/sched/core.c | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
[v2: Use data_race() macro as suggested by Will]
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b2d5cabcc5..57e5932f81a9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2612,19 +2612,43 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
int node)
{
+ cpumask_t *user_mask;
unsigned long flags;
- if (!src->user_cpus_ptr)
+ /*
+ * Always clear dst->user_cpus_ptr first as their user_cpus_ptr's
+ * may differ by now due to racing.
+ */
+ dst->user_cpus_ptr = NULL;
+
+ /*
+ * This check is racy and losing the race is a valid situation.
+ * It is not worth the extra overhead of taking the pi_lock on
+ * every fork/clone.
+ */
+ if (data_race(!src->user_cpus_ptr))
return 0;
- dst->user_cpus_ptr = kmalloc_node(cpumask_size(), GFP_KERNEL, node);
- if (!dst->user_cpus_ptr)
+ user_mask = kmalloc_node(cpumask_size(), GFP_KERNEL, node);
+ if (!user_mask)
return -ENOMEM;
- /* Use pi_lock to protect content of user_cpus_ptr */
+ /*
+ * Use pi_lock to protect content of user_cpus_ptr
+ *
+ * Though unlikely, user_cpus_ptr can be reset to NULL by a concurrent
+ * do_set_cpus_allowed().
+ */
raw_spin_lock_irqsave(&src->pi_lock, flags);
- cpumask_copy(dst->user_cpus_ptr, src->user_cpus_ptr);
+ if (src->user_cpus_ptr) {
+ swap(dst->user_cpus_ptr, user_mask);
+ cpumask_copy(dst->user_cpus_ptr, src->user_cpus_ptr);
+ }
raw_spin_unlock_irqrestore(&src->pi_lock, flags);
+
+ if (unlikely(user_mask))
+ kfree(user_mask);
+
return 0;
}
--
2.31.1
Hi,
It was reported that on 5.15.y there are problems with S3 suspend root
caused to a W6400 problem. [1]
These are fixed by this commit:
a9a1ac44074f ("drm/amd/display: Manually adjust strobe for DCN303")
Can you please bring it to 5.15.y?
Thanks,
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2000299
The memory for "llcc_driv_data" is allocated by the LLCC driver. But when
it is passed as "pvt_info" to the EDAC core, it will get freed during the
qcom_edac driver release. So when the qcom_edac driver gets probed again,
it will try to use the freed data leading to the use-after-free bug.
Fix this by not passing "llcc_driv_data" as pvt_info but rather reference
it using the "platform_data" in the qcom_edac driver.
Cc: <stable(a)vger.kernel.org> # 4.20
Fixes: 27450653f1db ("drivers: edac: Add EDAC driver support for QCOM SoCs")
Reported-by: Steev Klimaszewski <steev(a)kali.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/edac/qcom_edac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
index 9e77fa84e84f..3256254c3722 100644
--- a/drivers/edac/qcom_edac.c
+++ b/drivers/edac/qcom_edac.c
@@ -252,7 +252,7 @@ dump_syn_reg_values(struct llcc_drv_data *drv, u32 bank, int err_type)
static int
dump_syn_reg(struct edac_device_ctl_info *edev_ctl, int err_type, u32 bank)
{
- struct llcc_drv_data *drv = edev_ctl->pvt_info;
+ struct llcc_drv_data *drv = edev_ctl->dev->platform_data;
int ret;
ret = dump_syn_reg_values(drv, bank, err_type);
@@ -289,7 +289,7 @@ static irqreturn_t
llcc_ecc_irq_handler(int irq, void *edev_ctl)
{
struct edac_device_ctl_info *edac_dev_ctl = edev_ctl;
- struct llcc_drv_data *drv = edac_dev_ctl->pvt_info;
+ struct llcc_drv_data *drv = edac_dev_ctl->dev->platform_data;
irqreturn_t irq_rc = IRQ_NONE;
u32 drp_error, trp_error, i;
int ret;
@@ -358,7 +358,6 @@ static int qcom_llcc_edac_probe(struct platform_device *pdev)
edev_ctl->dev_name = dev_name(dev);
edev_ctl->ctl_name = "llcc";
edev_ctl->panic_on_ue = LLCC_ERP_PANIC_ON_UE;
- edev_ctl->pvt_info = llcc_driv_data;
rc = edac_device_add_device(edev_ctl);
if (rc)
--
2.25.1
Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral
if extcon is present") Dual Role support on Intel Merrifield platform
broke due to rearranging the call to dwc3_get_extcon().
It appears to be caused by ulpi_read_id() on the first test write failing
with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy via
DT when the test write fails and returns 0 in that case, even if DT does not
provide the phy. As a result usb probe completes without phy.
Make ulpi_read_id() return -ETIMEDOUT to its user if the first test write
fails. The user should then handle it appropriately. A follow up patch
will make dwc3_core_init() set -EPROBE_DEFER in this case and bail out.
Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ferry Toth <ftoth(a)exalondelft.nl>
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index d7c8461976ce..60e8174686a1 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -207,7 +207,7 @@ static int ulpi_read_id(struct ulpi *ulpi)
/* Test the interface */
ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
if (ret < 0)
- goto err;
+ return ret;
ret = ulpi_read(ulpi, ULPI_SCRATCH);
if (ret < 0)
--
2.37.2
From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
This is the fix proposed by Chuansheng Liu <chuansheng.liu(a)intel.com> to
close a memory leak caused by refactoring done in 786555987207
("drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list").
Original commit text from Liu was this:
>
> The below memory leak information is caught:
>
> unreferenced object 0xffff997dd4e3b240 (size 64):
> comm "gem_tiled_fence", pid 10332, jiffies 4294959326 (age 220778.420s)
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 be f2 d4 7d 99 ff ff ............}...
> backtrace:
> [<ffffffffa0f04365>] kmem_cache_alloc_trace+0x2e5/0x450
> [<ffffffffc062f3ac>] drm_vma_node_allow+0x2c/0xe0 [drm]
> [<ffffffffc13149ea>] __assign_mmap_offset_handle+0x1da/0x4a0 [i915]
> [<ffffffffc1315235>] i915_gem_mmap_offset_ioctl+0x55/0xb0 [i915]
> [<ffffffffc06207e4>] drm_ioctl_kernel+0xb4/0x140 [drm]
> [<ffffffffc0620ac7>] drm_ioctl+0x257/0x410 [drm]
> [<ffffffffa0f553ae>] __x64_sys_ioctl+0x8e/0xc0
> [<ffffffffa1821128>] do_syscall_64+0x38/0xc0
> [<ffffffffa1a0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> The issue is always reproduced with the test:
> gem_tiled_fence_blits --run-subtest basic
>
> It tries to mmap_gtt the same object several times, it is like:
> create BO
> mmap_gtt BO
> unmap BO
> mmap_gtt BO <== second time mmap_gtt
> unmap
> close BO
>
> The leak happens at the second time mmap_gtt in function
> mmap_offset_attach(),it will simply increase the reference
> count to 2 by calling drm_vma_node_allow() directly since
> the mmo has been created at the first time.
>
> However the driver just revokes the vma_node only one time
> when closing the object, it leads to memory leak easily.
>
> This patch is to fix the memory leak by calling drm_vma_node_allow() one
> time also.
Issue was later also reported by Mirsad:
>
> The problem is a kernel memory leak that is repeatedly occurring
> triggered during the execution of Chrome browser under the latest
> 6.1.0+ kernel of this morning and Almalinux 8.6 on a Lenovo
> desktop box with Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz CPU.
>
> The build is with KMEMLEAK, KASAN and MGLRU turned on during the
> build, on a vanilla mainline kernel from Mr. Torvalds' tree.
>
> The leaks look like this one:
>
> unreferenced object 0xffff888131754880 (size 64):
> comm "chrome", pid 13058, jiffies 4298568878 (age 3708.084s)
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 80 1e 3e 83 88 ff ff ...........>....
> backtrace:
> [<ffffffff9e9b5542>] slab_post_alloc_hook+0xb2/0x340
> [<ffffffff9e9bbf5f>] __kmem_cache_alloc_node+0x1bf/0x2c0
> [<ffffffff9e8f767a>] kmalloc_trace+0x2a/0xb0
> [<ffffffffc08dfde5>] drm_vma_node_allow+0x45/0x150 [drm]
> [<ffffffffc0b33315>] __assign_mmap_offset_handle+0x615/0x820 [i915]
> [<ffffffffc0b34057>] i915_gem_mmap_offset_ioctl+0x77/0x110 [i915]
> [<ffffffffc08bc5e1>] drm_ioctl_kernel+0x181/0x280 [drm]
> [<ffffffffc08bc9cd>] drm_ioctl+0x2dd/0x6a0 [drm]
> [<ffffffff9ea54744>] __x64_sys_ioctl+0xc4/0x100
> [<ffffffff9fbc0178>] do_syscall_64+0x58/0x80
> [<ffffffff9fc000aa>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
Root cause is that 786555987207 started caching (and sharing) the
i915_mmap_offset objects per object and same mmap type. This means that
reference count incremented by drm_vma_node_allow could grow beyond one,
while the object closure path calls drm_vma_node_revoke only once and
so the structure leaks.
Secondary effect from this, which is also different than what we had
before 786555987207 is that it is now possible to mmap an offset belonging
to a closed object.
Fix here is to partially revert to behaviour before 786555987207 - that is
to disallow mmap of closed objects and to only increment the mmap offset
ref count once per object-type.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Co-developed-by: Chuansheng Liu <chuansheng.liu(a)intel.com>
Fixes: 786555987207 ("drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list")
Reported-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Tested-by: Mirsad Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Testcase: igt@gem_mmap_gtt@mmap-closed-bo
Cc: Matthew Auld <matthew.auld(a)intel.com>
Cc: "Thomas Hellström" <thomas.hellstrom(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v5.7+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
---
Test-with: 20221222100403.256775-1-tvrtko.ursulin(a)linux.intel.com
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d73ba0f5c4c5..1ceff19a0ac0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -695,9 +695,10 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
insert:
mmo = insert_mmo(obj, mmo);
GEM_BUG_ON(lookup_mmo(obj, mmap_type) != mmo);
-out:
+
if (file)
drm_vma_node_allow(&mmo->vma_node, file);
+out:
return mmo;
err:
--
2.34.1
--
Hello,
I tried e-mailing you more than twice but my email bounced back
failure, Note this, soonest you receive this email revert to me before
I deliver the message it's importunate, pressing, crucial. Await your
response.
Best regards
Dr. Michelle Daniel
Good morning, my name is Aisha Al-Gaddafi.
Please, I have an investment Project transaction of US$27.500.000.00.
that involves transfer and I would like to have your advice on which
Investment / Industry that you think that can bring us profit.
If you're interested, kindly reply for more specific information on
this project.
Thanks,
Mr. Aisha Al-Gaddafi.
This is the start of the stable review cycle for the 6.1.1 release.
There are 25 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Dec 2022 18:29:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.1-rc1.…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.1.1-rc1
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Nikolaus Voss <nikolaus.voss(a)haag-streit.com>
KEYS: encrypted: fix key instantiation with user-provided data
Paulo Alcantara <pc(a)cjr.nz>
cifs: fix oops during encryption
Shruthi Sanil <shruthi.sanil(a)intel.com>
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
usb: typec: ucsi: Resume in separate work
Tony Nguyen <anthony.l.nguyen(a)intel.com>
igb: Initialize mailbox message for VF reset
Martin Kaiser <martin(a)kaiser.cx>
staging: r8188eu: fix led register settings
Reka Norman <rekanorman(a)chromium.org>
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Andy Chi <andy.chi(a)canonical.com>
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
Johan Hovold <johan(a)kernel.org>
USB: serial: f81534: fix division by zero on line-speed change
Johan Hovold <johan(a)kernel.org>
USB: serial: f81232: fix division by zero on line-speed change
Bruno Thomsen <bruno.thomsen(a)gmail.com>
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin <duke_xinanwen(a)163.com>
USB: serial: option: add Quectel EM05-G modem
Szymon Heidrich <szymon.heidrich(a)gmail.com>
usb: gadget: uvc: Prevent buffer overflow in setup handler
Jan Kara <jack(a)suse.cz>
udf: Fix extending file within last block
Jan Kara <jack(a)suse.cz>
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
Jan Kara <jack(a)suse.cz>
udf: Fix preallocation discarding at indirect extent boundary
Jan Kara <jack(a)suse.cz>
udf: Discard preallocation before extending file with a hole
Sean Anderson <sean.anderson(a)seco.com>
irqchip/ls-extirq: Fix endianness detection
John Thomson <git(a)johnthomson.fastmail.com.au>
mips: ralink: mt7621: do not use kzalloc too early
John Thomson <git(a)johnthomson.fastmail.com.au>
mips: ralink: mt7621: soc queries and tests as functions
John Thomson <git(a)johnthomson.fastmail.com.au>
mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem
John Thomson <git(a)johnthomson.fastmail.com.au>
PCI: mt7621: Add sentinel to quirks table
David Michael <fedora.dm0(a)gmail.com>
libbpf: Fix uninitialized warning in btf_dump_dump_type_data
Nathan Chancellor <nathan(a)kernel.org>
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
-------------
Diffstat:
Documentation/security/keys/trusted-encrypted.rst | 3 +-
Makefile | 4 +-
arch/mips/include/asm/mach-ralink/mt7621.h | 4 +-
arch/mips/ralink/mt7621.c | 97 ++++++++++-----
arch/x86/entry/vdso/vdso.lds.S | 2 +
drivers/irqchip/irq-ls-extirq.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/pci/controller/pcie-mt7621.c | 3 +-
drivers/staging/r8188eu/core/rtw_led.c | 25 +---
drivers/usb/common/ulpi.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/gadget/function/f_uvc.c | 5 +-
drivers/usb/host/xhci-pci.c | 4 +-
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/f81232.c | 12 +-
drivers/usb/serial/f81534.c | 12 +-
drivers/usb/serial/option.c | 3 +
drivers/usb/typec/ucsi/ucsi.c | 17 ++-
drivers/usb/typec/ucsi/ucsi.h | 1 +
fs/cifs/cifsglob.h | 68 ++++++++++
fs/cifs/cifsproto.h | 4 +-
fs/cifs/misc.c | 4 +-
fs/cifs/smb2ops.c | 143 ++++++++++------------
fs/udf/inode.c | 76 +++++-------
fs/udf/truncate.c | 48 +++-----
security/keys/encrypted-keys/encrypted.c | 6 +-
sound/pci/hda/patch_realtek.c | 2 +
tools/lib/bpf/btf_dump.c | 2 +-
28 files changed, 319 insertions(+), 236 deletions(-)
The quilt patch titled
Subject: gcov: add support for checksum field
has been removed from the -mm tree. Its filename was
gcov-add-support-for-checksum-field.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: Rickard x Andersson <rickaran(a)axis.com>
Subject: gcov: add support for checksum field
Date: Tue, 20 Dec 2022 11:23:18 +0100
In GCC version 12.1 a checksum field was added.
This patch fixes a kernel crash occurring during boot when using
gcov-kernel with GCC version 12.2. The crash occurred on a system running
on i.MX6SX.
Link: https://lkml.kernel.org/r/20221220102318.3418501-1-rickaran@axis.com
Fixes: 977ef30a7d88 ("gcov: support GCC 12.1 and newer compilers")
Signed-off-by: Rickard x Andersson <rickaran(a)axis.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Tested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Reviewed-by: Martin Liska <mliska(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/gcov/gcc_4_7.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/gcov/gcc_4_7.c~gcov-add-support-for-checksum-field
+++ a/kernel/gcov/gcc_4_7.c
@@ -82,6 +82,7 @@ struct gcov_fn_info {
* @version: gcov version magic indicating the gcc version used for compilation
* @next: list head for a singly-linked list
* @stamp: uniquifying time stamp
+ * @checksum: unique object checksum
* @filename: name of the associated gcov data file
* @merge: merge functions (null for unused counter type)
* @n_functions: number of instrumented functions
@@ -94,6 +95,10 @@ struct gcov_info {
unsigned int version;
struct gcov_info *next;
unsigned int stamp;
+ /* Since GCC 12.1 a checksum field is added. */
+#if (__GNUC__ >= 12)
+ unsigned int checksum;
+#endif
const char *filename;
void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
unsigned int n_functions;
_
Patches currently in -mm which might be from rickaran(a)axis.com are
The quilt patch titled
Subject: test_maple_tree: add test for mas_spanning_rebalance() on insufficient data
has been removed from the -mm tree. Its filename was
test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data.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: Liam Howlett <liam.howlett(a)oracle.com>
Subject: test_maple_tree: add test for mas_spanning_rebalance() on insufficient data
Date: Mon, 19 Dec 2022 16:20:15 +0000
Add a test to the maple tree test suite for the spanning rebalance
insufficient node issue does not go undetected again.
Link: https://lkml.kernel.org/r/20221219161922.2708732-3-Liam.Howlett@oracle.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Andrei Vagin <avagin(a)gmail.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/test_maple_tree.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--- a/lib/test_maple_tree.c~test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data
+++ a/lib/test_maple_tree.c
@@ -2498,6 +2498,25 @@ static noinline void check_dup(struct ma
}
}
+static noinline void check_bnode_min_spanning(struct maple_tree *mt)
+{
+ int i = 50;
+ MA_STATE(mas, mt, 0, 0);
+
+ mt_set_non_kernel(9999);
+ mas_lock(&mas);
+ do {
+ mas_set_range(&mas, i*10, i*10+9);
+ mas_store(&mas, check_bnode_min_spanning);
+ } while (i--);
+
+ mas_set_range(&mas, 240, 509);
+ mas_store(&mas, NULL);
+ mas_unlock(&mas);
+ mas_destroy(&mas);
+ mt_set_non_kernel(0);
+}
+
static DEFINE_MTREE(tree);
static int maple_tree_seed(void)
{
@@ -2742,6 +2761,10 @@ static int maple_tree_seed(void)
check_dup(&tree);
mtree_destroy(&tree);
+ mt_init_flags(&tree, MT_FLAGS_ALLOC_RANGE);
+ check_bnode_min_spanning(&tree);
+ mtree_destroy(&tree);
+
#if defined(BENCH)
skip:
#endif
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
The quilt patch titled
Subject: maple_tree: fix mas_spanning_rebalance() on insufficient data
has been removed from the -mm tree. Its filename was
maple_tree-fix-mas_spanning_rebalance-on-insufficient-data.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: Liam Howlett <liam.howlett(a)oracle.com>
Subject: maple_tree: fix mas_spanning_rebalance() on insufficient data
Date: Mon, 19 Dec 2022 16:20:15 +0000
Mike Rapoport contacted me off-list with a regression in running criu.
Periodic tests fail with an RCU stall during execution. Although rare, it
is possible to hit this with other uses so this patch should be backported
to fix the regression.
This patchset adds the fix and a test case to the maple tree test
suite.
This patch (of 2):
An insufficient node was causing an out-of-bounds access on the node in
mas_leaf_max_gap(). The cause was the faulty detection of the new node
being a root node when overwriting many entries at the end of the tree.
Fix the detection of a new root and ensure there is sufficient data prior
to entering the spanning rebalance loop.
Link: https://lkml.kernel.org/r/20221219161922.2708732-1-Liam.Howlett@oracle.com
Link: https://lkml.kernel.org/r/20221219161922.2708732-2-Liam.Howlett@oracle.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Reported-by: Mike Rapoport <rppt(a)kernel.org>
Tested-by: Mike Rapoport <rppt(a)kernel.org>
Cc: Andrei Vagin <avagin(a)gmail.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/maple_tree.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/lib/maple_tree.c~maple_tree-fix-mas_spanning_rebalance-on-insufficient-data
+++ a/lib/maple_tree.c
@@ -2994,7 +2994,9 @@ static int mas_spanning_rebalance(struct
mast->free = &free;
mast->destroy = &destroy;
l_mas.node = r_mas.node = m_mas.node = MAS_NONE;
- if (!(mast->orig_l->min && mast->orig_r->max == ULONG_MAX) &&
+
+ /* Check if this is not root and has sufficient data. */
+ if (((mast->orig_l->min != 0) || (mast->orig_r->max != ULONG_MAX)) &&
unlikely(mast->bn->b_end <= mt_min_slots[mast->bn->type]))
mast_spanning_rebalance(mast);
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
The quilt patch titled
Subject: kmsan: export kmsan_handle_urb
has been removed from the -mm tree. Its filename was
kmsan-export-kmsan_handle_urb.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: Arnd Bergmann <arnd(a)arndb.de>
Subject: kmsan: export kmsan_handle_urb
Date: Thu, 15 Dec 2022 17:26:57 +0100
USB support can be in a loadable module, and this causes a link failure
with KMSAN:
ERROR: modpost: "kmsan_handle_urb" [drivers/usb/core/usbcore.ko] undefined!
Export the symbol so it can be used by this module.
Link: https://lkml.kernel.org/r/20221215162710.3802378-1-arnd@kernel.org
Fixes: 553a80188a5d ("kmsan: handle memory sent to/from USB")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Marco Elver <elver(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/kmsan/hooks.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/kmsan/hooks.c~kmsan-export-kmsan_handle_urb
+++ a/mm/kmsan/hooks.c
@@ -260,6 +260,7 @@ void kmsan_handle_urb(const struct urb *
urb->transfer_buffer_length,
/*checked*/ false);
}
+EXPORT_SYMBOL_GPL(kmsan_handle_urb);
static void kmsan_handle_dma_page(const void *addr, size_t size,
enum dma_data_direction dir)
_
Patches currently in -mm which might be from arnd(a)arndb.de are
The quilt patch titled
Subject: kmsan: include linux/vmalloc.h
has been removed from the -mm tree. Its filename was
kmsan-include-linux-vmalloch.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: Arnd Bergmann <arnd(a)arndb.de>
Subject: kmsan: include linux/vmalloc.h
Date: Thu, 15 Dec 2022 17:30:17 +0100
This is needed for the vmap/vunmap declarations:
mm/kmsan/kmsan_test.c:316:9: error: implicit declaration of function 'vmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
^
mm/kmsan/kmsan_test.c:316:29: error: use of undeclared identifier 'VM_MAP'
vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
^
mm/kmsan/kmsan_test.c:322:3: error: implicit declaration of function 'vunmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
vunmap(vbuf);
^
Link: https://lkml.kernel.org/r/20221215163046.4079767-1-arnd@kernel.org
Fixes: 8ed691b02ade ("kmsan: add tests for KMSAN")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Marco Elver <elver(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/kmsan/kmsan_test.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/kmsan/kmsan_test.c~kmsan-include-linux-vmalloch
+++ a/mm/kmsan/kmsan_test.c
@@ -22,6 +22,7 @@
#include <linux/spinlock.h>
#include <linux/string.h>
#include <linux/tracepoint.h>
+#include <linux/vmalloc.h>
#include <trace/events/printk.h>
static DEFINE_PER_CPU(int, per_cpu_var);
_
Patches currently in -mm which might be from arnd(a)arndb.de are
The quilt patch titled
Subject: mm/mempolicy: fix memory leak in set_mempolicy_home_node system call
has been removed from the -mm tree. Its filename was
mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.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: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Subject: mm/mempolicy: fix memory leak in set_mempolicy_home_node system call
Date: Thu, 15 Dec 2022 14:46:21 -0500
When encountering any vma in the range with policy other than MPOL_BIND or
MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on
the policy just allocated with mpol_dup().
This allows arbitrary users to leak kernel memory.
Link: https://lkml.kernel.org/r/20221215194621.202816-1-mathieu.desnoyers@efficio…
Fixes: c6018b4b2549 ("mm/mempolicy: add set_mempolicy_home_node syscall")
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reviewed-by: Randy Dunlap <rdunlap(a)infradead.org>
Reviewed-by: "Huang, Ying" <ying.huang(a)intel.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Feng Tang <feng.tang(a)intel.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org> [5.17+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/mempolicy.c~mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call
+++ a/mm/mempolicy.c
@@ -1540,6 +1540,7 @@ SYSCALL_DEFINE4(set_mempolicy_home_node,
* the home node for vmas we already updated before.
*/
if (new->mode != MPOL_BIND && new->mode != MPOL_PREFERRED_MANY) {
+ mpol_put(new);
err = -EOPNOTSUPP;
break;
}
_
Patches currently in -mm which might be from mathieu.desnoyers(a)efficios.com are
The quilt patch titled
Subject: mm, mremap: fix mremap() expanding vma with addr inside vma
has been removed from the -mm tree. Its filename was
mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.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: Vlastimil Babka <vbabka(a)suse.cz>
Subject: mm, mremap: fix mremap() expanding vma with addr inside vma
Date: Fri, 16 Dec 2022 17:32:27 +0100
Since 6.1 we have noticed random rpm install failures that were tracked to
mremap() returning -ENOMEM and to commit ca3d76b0aa80 ("mm: add merging
after mremap resize").
The problem occurs when mremap() expands a VMA in place, but using an
starting address that's not vma->vm_start, but somewhere in the middle.
The extension_pgoff calculation introduced by the commit is wrong in that
case, so vma_merge() fails due to pgoffs not being compatible. Fix the
calculation.
By the way it seems that the situations, where rpm now expands a vma from
the middle, were made possible also due to that commit, thanks to the
improved vma merging. Yet it should work just fine, except for the buggy
calculation.
Link: https://lkml.kernel.org/r/20221216163227.24648-1-vbabka@suse.cz
Reported-by: Jiri Slaby <jirislaby(a)kernel.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359
Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Jakub Mat��na <matenajakub(a)gmail.com>
Cc: "Kirill A . Shutemov" <kirill(a)shutemov.name>
Cc: Liam Howlett <liam.howlett(a)oracle.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/mremap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/mremap.c~mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma
+++ a/mm/mremap.c
@@ -1016,7 +1016,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
long pages = (new_len - old_len) >> PAGE_SHIFT;
unsigned long extension_start = addr + old_len;
unsigned long extension_end = addr + new_len;
- pgoff_t extension_pgoff = vma->vm_pgoff + (old_len >> PAGE_SHIFT);
+ pgoff_t extension_pgoff = vma->vm_pgoff +
+ ((extension_start - vma->vm_start) >> PAGE_SHIFT);
if (vma->vm_flags & VM_ACCOUNT) {
if (security_vm_enough_memory_mm(mm, pages)) {
_
Patches currently in -mm which might be from vbabka(a)suse.cz are
I'm announcing the release of the 6.1.1 kernel.
All users of the 6.1 kernel series must upgrade.
The updated 6.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.1.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/security/keys/trusted-encrypted.rst | 3
Makefile | 2
arch/mips/include/asm/mach-ralink/mt7621.h | 4
arch/mips/ralink/mt7621.c | 97 ++++++++++----
arch/x86/entry/vdso/vdso.lds.S | 2
drivers/irqchip/irq-ls-extirq.c | 2
drivers/net/ethernet/intel/igb/igb_main.c | 2
drivers/pci/controller/pcie-mt7621.c | 3
drivers/staging/r8188eu/core/rtw_led.c | 25 ---
drivers/usb/dwc3/dwc3-pci.c | 2
drivers/usb/gadget/function/f_uvc.c | 5
drivers/usb/host/xhci-pci.c | 4
drivers/usb/serial/cp210x.c | 2
drivers/usb/serial/f81232.c | 12 +
drivers/usb/serial/f81534.c | 12 +
drivers/usb/serial/option.c | 3
drivers/usb/typec/ucsi/ucsi.c | 17 ++
drivers/usb/typec/ucsi/ucsi.h | 1
fs/cifs/cifsglob.h | 68 ++++++++++
fs/cifs/cifsproto.h | 4
fs/cifs/misc.c | 4
fs/cifs/smb2ops.c | 143 ++++++++++------------
fs/udf/inode.c | 76 +++++------
fs/udf/truncate.c | 48 ++-----
security/keys/encrypted-keys/encrypted.c | 6
sound/pci/hda/patch_realtek.c | 2
tools/lib/bpf/btf_dump.c | 2
27 files changed, 317 insertions(+), 234 deletions(-)
Andy Chi (1):
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
Bruno Thomsen (1):
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
David Michael (1):
libbpf: Fix uninitialized warning in btf_dump_dump_type_data
Duke Xin (1):
USB: serial: option: add Quectel EM05-G modem
Greg Kroah-Hartman (1):
Linux 6.1.1
Heikki Krogerus (1):
usb: typec: ucsi: Resume in separate work
Jan Kara (4):
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
Johan Hovold (2):
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
John Thomson (4):
PCI: mt7621: Add sentinel to quirks table
mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem
mips: ralink: mt7621: soc queries and tests as functions
mips: ralink: mt7621: do not use kzalloc too early
Martin Kaiser (1):
staging: r8188eu: fix led register settings
Nathan Chancellor (1):
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
Nikolaus Voss (1):
KEYS: encrypted: fix key instantiation with user-provided data
Paulo Alcantara (1):
cifs: fix oops during encryption
Reka Norman (1):
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Sean Anderson (1):
irqchip/ls-extirq: Fix endianness detection
Shruthi Sanil (1):
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Szymon Heidrich (1):
usb: gadget: uvc: Prevent buffer overflow in setup handler
Tony Nguyen (1):
igb: Initialize mailbox message for VF reset
I'm announcing the release of the 6.0.15 kernel.
All users of the 6.0 kernel series must upgrade.
The updated 6.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.0.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/security/keys/trusted-encrypted.rst | 3
Makefile | 2
drivers/net/ethernet/intel/igb/igb_main.c | 2
drivers/net/loopback.c | 2
drivers/pci/controller/pcie-mt7621.c | 3
drivers/usb/dwc3/dwc3-pci.c | 2
drivers/usb/gadget/function/f_uvc.c | 5
drivers/usb/host/xhci-pci.c | 4
drivers/usb/serial/cp210x.c | 2
drivers/usb/serial/f81232.c | 12 -
drivers/usb/serial/f81534.c | 12 -
drivers/usb/serial/option.c | 3
drivers/usb/typec/ucsi/ucsi.c | 17 +
drivers/usb/typec/ucsi/ucsi.h | 1
fs/udf/inode.c | 76 +++----
fs/udf/truncate.c | 48 +---
include/linux/module.h | 9
kernel/module/kallsyms.c | 2
kernel/trace/bpf_trace.c | 98 +++++++++-
kernel/trace/ftrace.c | 16 +
net/bluetooth/l2cap_core.c | 3
security/keys/encrypted-keys/encrypted.c | 6
sound/pci/hda/patch_realtek.c | 2
tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 24 ++
tools/testing/selftests/bpf/prog_tests/kprobe_multi_testmod_test.c | 89 +++++++++
tools/testing/selftests/bpf/prog_tests/module_attach.c | 7
tools/testing/selftests/bpf/progs/kprobe_multi.c | 50 +++++
tools/testing/selftests/bpf/progs/test_module_attach.c | 6
tools/testing/selftests/bpf/trace_helpers.c | 20 +-
tools/testing/selftests/bpf/trace_helpers.h | 2
tools/testing/selftests/net/toeplitz.sh | 2
31 files changed, 410 insertions(+), 120 deletions(-)
Andy Chi (1):
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
Bruno Thomsen (1):
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin (1):
USB: serial: option: add Quectel EM05-G modem
Greg Kroah-Hartman (1):
Linux 6.0.15
Heikki Krogerus (1):
usb: typec: ucsi: Resume in separate work
Jan Kara (4):
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
Jiri Olsa (8):
kallsyms: Make module_kallsyms_on_each_symbol generally available
ftrace: Add support to resolve module symbols in ftrace_lookup_symbols
bpf: Rename __bpf_kprobe_multi_cookie_cmp to bpf_kprobe_multi_addrs_cmp
bpf: Take module reference on kprobe_multi link
selftests/bpf: Add load_kallsyms_refresh function
selftests/bpf: Add bpf_testmod_fentry_* functions
selftests/bpf: Add kprobe_multi check to module attach test
selftests/bpf: Add kprobe_multi kmod attach api tests
Johan Hovold (2):
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
John Thomson (1):
PCI: mt7621: Add sentinel to quirks table
Nikolaus Voss (1):
KEYS: encrypted: fix key instantiation with user-provided data
Rasmus Villemoes (1):
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Reka Norman (1):
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Shruthi Sanil (1):
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Sungwoo Kim (1):
Bluetooth: L2CAP: Fix u8 overflow
Szymon Heidrich (1):
usb: gadget: uvc: Prevent buffer overflow in setup handler
Tiezhu Yang (1):
selftests: net: Use "grep -E" instead of "egrep"
Tony Nguyen (1):
igb: Initialize mailbox message for VF reset
I'm announcing the release of the 5.15.85 kernel.
All users of the 5.15 kernel series must upgrade.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
drivers/hid/hid-uclogic-core.c | 1
drivers/net/ethernet/intel/igb/igb_main.c | 2
drivers/net/loopback.c | 2
drivers/usb/dwc3/dwc3-pci.c | 2
drivers/usb/gadget/function/f_uvc.c | 5 +
drivers/usb/host/xhci-pci.c | 4 +
drivers/usb/serial/cp210x.c | 2
drivers/usb/serial/f81232.c | 12 ++--
drivers/usb/serial/f81534.c | 12 ++--
drivers/usb/serial/option.c | 3 +
fs/udf/inode.c | 76 +++++++++++++-----------------
fs/udf/truncate.c | 48 +++++-------------
net/bluetooth/l2cap_core.c | 3 -
tools/testing/selftests/net/toeplitz.sh | 2
15 files changed, 82 insertions(+), 94 deletions(-)
Bruno Thomsen (1):
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin (1):
USB: serial: option: add Quectel EM05-G modem
Greg Kroah-Hartman (1):
Linux 5.15.85
Jan Kara (4):
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
Johan Hovold (2):
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
José Expósito (1):
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
Rasmus Villemoes (1):
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Reka Norman (1):
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Shruthi Sanil (1):
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Sungwoo Kim (1):
Bluetooth: L2CAP: Fix u8 overflow
Szymon Heidrich (1):
usb: gadget: uvc: Prevent buffer overflow in setup handler
Tiezhu Yang (1):
selftests: net: Use "grep -E" instead of "egrep"
Tony Nguyen (1):
igb: Initialize mailbox message for VF reset
I'm announcing the release of the 5.10.161 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
drivers/hid/hid-ids.h | 2
drivers/hid/hid-ite.c | 26 +++++++++-
drivers/hid/hid-uclogic-core.c | 1
drivers/net/ethernet/intel/igb/igb_main.c | 2
drivers/net/loopback.c | 2
drivers/usb/gadget/function/f_uvc.c | 5 +
drivers/usb/host/xhci-pci.c | 4 +
drivers/usb/serial/cp210x.c | 2
drivers/usb/serial/f81232.c | 12 ++--
drivers/usb/serial/f81534.c | 12 ++--
drivers/usb/serial/option.c | 3 +
fs/udf/inode.c | 76 +++++++++++++-----------------
fs/udf/truncate.c | 48 +++++-------------
net/bluetooth/l2cap_core.c | 3 -
15 files changed, 106 insertions(+), 94 deletions(-)
Bruno Thomsen (1):
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin (1):
USB: serial: option: add Quectel EM05-G modem
Greg Kroah-Hartman (1):
Linux 5.10.161
Hans de Goede (3):
HID: ite: Add support for Acer S1002 keyboard-dock
HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch 10E
HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10
Jan Kara (4):
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
Johan Hovold (2):
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
José Expósito (1):
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
Rasmus Villemoes (1):
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Reka Norman (1):
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Sungwoo Kim (1):
Bluetooth: L2CAP: Fix u8 overflow
Szymon Heidrich (1):
usb: gadget: uvc: Prevent buffer overflow in setup handler
Tony Nguyen (1):
igb: Initialize mailbox message for VF reset
This is the start of the stable review cycle for the 6.0.15 release.
There are 28 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Dec 2022 18:29:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.15-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.0.15-rc1
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Tiezhu Yang <yangtiezhu(a)loongson.cn>
selftests: net: Use "grep -E" instead of "egrep"
Sungwoo Kim <iam(a)sung-woo.kim>
Bluetooth: L2CAP: Fix u8 overflow
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Nikolaus Voss <nikolaus.voss(a)haag-streit.com>
KEYS: encrypted: fix key instantiation with user-provided data
Shruthi Sanil <shruthi.sanil(a)intel.com>
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
usb: typec: ucsi: Resume in separate work
Tony Nguyen <anthony.l.nguyen(a)intel.com>
igb: Initialize mailbox message for VF reset
Reka Norman <rekanorman(a)chromium.org>
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Andy Chi <andy.chi(a)canonical.com>
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
Johan Hovold <johan(a)kernel.org>
USB: serial: f81534: fix division by zero on line-speed change
Johan Hovold <johan(a)kernel.org>
USB: serial: f81232: fix division by zero on line-speed change
Bruno Thomsen <bruno.thomsen(a)gmail.com>
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin <duke_xinanwen(a)163.com>
USB: serial: option: add Quectel EM05-G modem
Szymon Heidrich <szymon.heidrich(a)gmail.com>
usb: gadget: uvc: Prevent buffer overflow in setup handler
Jan Kara <jack(a)suse.cz>
udf: Fix extending file within last block
Jan Kara <jack(a)suse.cz>
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
Jan Kara <jack(a)suse.cz>
udf: Fix preallocation discarding at indirect extent boundary
Jan Kara <jack(a)suse.cz>
udf: Discard preallocation before extending file with a hole
Jiri Olsa <jolsa(a)kernel.org>
selftests/bpf: Add kprobe_multi kmod attach api tests
Jiri Olsa <jolsa(a)kernel.org>
selftests/bpf: Add kprobe_multi check to module attach test
Jiri Olsa <jolsa(a)kernel.org>
selftests/bpf: Add bpf_testmod_fentry_* functions
Jiri Olsa <jolsa(a)kernel.org>
selftests/bpf: Add load_kallsyms_refresh function
Jiri Olsa <jolsa(a)kernel.org>
bpf: Take module reference on kprobe_multi link
Jiri Olsa <jolsa(a)kernel.org>
bpf: Rename __bpf_kprobe_multi_cookie_cmp to bpf_kprobe_multi_addrs_cmp
Jiri Olsa <jolsa(a)kernel.org>
ftrace: Add support to resolve module symbols in ftrace_lookup_symbols
Jiri Olsa <jolsa(a)kernel.org>
kallsyms: Make module_kallsyms_on_each_symbol generally available
John Thomson <git(a)johnthomson.fastmail.com.au>
PCI: mt7621: Add sentinel to quirks table
-------------
Diffstat:
Documentation/security/keys/trusted-encrypted.rst | 3 +-
Makefile | 4 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/loopback.c | 2 +-
drivers/pci/controller/pcie-mt7621.c | 3 +-
drivers/usb/common/ulpi.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/gadget/function/f_uvc.c | 5 +-
drivers/usb/host/xhci-pci.c | 4 +-
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/f81232.c | 12 +--
drivers/usb/serial/f81534.c | 12 +--
drivers/usb/serial/option.c | 3 +
drivers/usb/typec/ucsi/ucsi.c | 17 +++-
drivers/usb/typec/ucsi/ucsi.h | 1 +
fs/udf/inode.c | 76 ++++++++---------
fs/udf/truncate.c | 48 ++++-------
include/linux/module.h | 9 ++
kernel/module/kallsyms.c | 2 -
kernel/trace/bpf_trace.c | 98 +++++++++++++++++++++-
kernel/trace/ftrace.c | 16 ++--
net/bluetooth/l2cap_core.c | 3 +-
security/keys/encrypted-keys/encrypted.c | 6 +-
sound/pci/hda/patch_realtek.c | 2 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 24 ++++++
.../bpf/prog_tests/kprobe_multi_testmod_test.c | 89 ++++++++++++++++++++
.../selftests/bpf/prog_tests/module_attach.c | 7 ++
tools/testing/selftests/bpf/progs/kprobe_multi.c | 50 +++++++++++
.../selftests/bpf/progs/test_module_attach.c | 6 ++
tools/testing/selftests/bpf/trace_helpers.c | 20 +++--
tools/testing/selftests/bpf/trace_helpers.h | 2 +
tools/testing/selftests/net/toeplitz.sh | 2 +-
32 files changed, 412 insertions(+), 122 deletions(-)
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Commit 98de59bfe4b2f ("take calculation of final prot in
security_mmap_file() into a helper") moved the code to update prot with the
actual protection flags to be granted to the requestor by the kernel to a
helper called mmap_prot(). However, the patch didn't update the argument
passed to ima_file_mmap(), making it receive the requested prot instead of
the final computed prot.
A possible consequence is that files mmapped as executable might not be
measured/appraised if PROT_EXEC is not requested but subsequently added in
the final prot.
Replace prot with mmap_prot(prot) as the second argument of ima_file_mmap()
to restore the original behavior.
Cc: stable(a)vger.kernel.org
Fixes: 98de59bfe4b2 ("take calculation of final prot in security_mmap_file() into a helper")
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
---
security/security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/security.c b/security/security.c
index d1571900a8c7..0d2359d588a1 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1666,7 +1666,7 @@ int security_mmap_file(struct file *file, unsigned long prot,
mmap_prot(file, prot), flags);
if (ret)
return ret;
- return ima_file_mmap(file, prot);
+ return ima_file_mmap(file, mmap_prot(file, prot));
}
int security_mmap_addr(unsigned long addr)
--
2.25.1
This bug is marked as fixed by commit:
ext4: block range must be validated before use in ext4_mb_clear_bb()
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and
new crashes with the same signature are ignored.
This is the start of the stable review cycle for the 5.15.85 release.
There are 17 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Dec 2022 18:29:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.85-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.85-rc1
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Tiezhu Yang <yangtiezhu(a)loongson.cn>
selftests: net: Use "grep -E" instead of "egrep"
Sungwoo Kim <iam(a)sung-woo.kim>
Bluetooth: L2CAP: Fix u8 overflow
José Expósito <jose.exposito89(a)gmail.com>
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Shruthi Sanil <shruthi.sanil(a)intel.com>
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
Tony Nguyen <anthony.l.nguyen(a)intel.com>
igb: Initialize mailbox message for VF reset
Reka Norman <rekanorman(a)chromium.org>
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Johan Hovold <johan(a)kernel.org>
USB: serial: f81534: fix division by zero on line-speed change
Johan Hovold <johan(a)kernel.org>
USB: serial: f81232: fix division by zero on line-speed change
Bruno Thomsen <bruno.thomsen(a)gmail.com>
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin <duke_xinanwen(a)163.com>
USB: serial: option: add Quectel EM05-G modem
Szymon Heidrich <szymon.heidrich(a)gmail.com>
usb: gadget: uvc: Prevent buffer overflow in setup handler
Jan Kara <jack(a)suse.cz>
udf: Fix extending file within last block
Jan Kara <jack(a)suse.cz>
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
Jan Kara <jack(a)suse.cz>
udf: Fix preallocation discarding at indirect extent boundary
Jan Kara <jack(a)suse.cz>
udf: Discard preallocation before extending file with a hole
-------------
Diffstat:
Makefile | 4 +-
drivers/hid/hid-uclogic-core.c | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/loopback.c | 2 +-
drivers/usb/common/ulpi.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/gadget/function/f_uvc.c | 5 +-
drivers/usb/host/xhci-pci.c | 4 +-
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/f81232.c | 12 +++--
drivers/usb/serial/f81534.c | 12 +++--
drivers/usb/serial/option.c | 3 ++
fs/udf/inode.c | 76 ++++++++++++++-----------------
fs/udf/truncate.c | 48 ++++++-------------
net/bluetooth/l2cap_core.c | 3 +-
tools/testing/selftests/net/toeplitz.sh | 2 +-
16 files changed, 84 insertions(+), 96 deletions(-)
This is the start of the stable review cycle for the 5.10.161 release.
There are 18 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Dec 2022 18:29:31 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.161-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.161-rc1
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Sungwoo Kim <iam(a)sung-woo.kim>
Bluetooth: L2CAP: Fix u8 overflow
José Expósito <jose.exposito89(a)gmail.com>
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
Hans de Goede <hdegoede(a)redhat.com>
HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10
Hans de Goede <hdegoede(a)redhat.com>
HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch 10E
Hans de Goede <hdegoede(a)redhat.com>
HID: ite: Add support for Acer S1002 keyboard-dock
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Tony Nguyen <anthony.l.nguyen(a)intel.com>
igb: Initialize mailbox message for VF reset
Reka Norman <rekanorman(a)chromium.org>
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
Johan Hovold <johan(a)kernel.org>
USB: serial: f81534: fix division by zero on line-speed change
Johan Hovold <johan(a)kernel.org>
USB: serial: f81232: fix division by zero on line-speed change
Bruno Thomsen <bruno.thomsen(a)gmail.com>
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
Duke Xin <duke_xinanwen(a)163.com>
USB: serial: option: add Quectel EM05-G modem
Szymon Heidrich <szymon.heidrich(a)gmail.com>
usb: gadget: uvc: Prevent buffer overflow in setup handler
Jan Kara <jack(a)suse.cz>
udf: Fix extending file within last block
Jan Kara <jack(a)suse.cz>
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
Jan Kara <jack(a)suse.cz>
udf: Fix preallocation discarding at indirect extent boundary
Jan Kara <jack(a)suse.cz>
udf: Discard preallocation before extending file with a hole
-------------
Diffstat:
Makefile | 4 +-
drivers/hid/hid-ids.h | 2 +
drivers/hid/hid-ite.c | 26 ++++++++++-
drivers/hid/hid-uclogic-core.c | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/loopback.c | 2 +-
drivers/usb/common/ulpi.c | 2 +-
drivers/usb/gadget/function/f_uvc.c | 5 +-
drivers/usb/host/xhci-pci.c | 4 +-
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/f81232.c | 12 +++--
drivers/usb/serial/f81534.c | 12 +++--
drivers/usb/serial/option.c | 3 ++
fs/udf/inode.c | 76 ++++++++++++++-----------------
fs/udf/truncate.c | 48 ++++++-------------
net/bluetooth/l2cap_core.c | 3 +-
16 files changed, 108 insertions(+), 96 deletions(-)
The patch below does not apply to the 6.0-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>.
Possible dependencies:
12c6223fc180 ("staging: r8188eu: fix led register settings")
647085006beb ("staging: r8188eu: don't check bSurpriseRemoved in SwLedOff")
8f60cb9534e4 ("staging: r8188eu: remove duplicate bSurpriseRemoved check")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 12c6223fc1804fd9295dc50d358294539b4a4184 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Sat, 15 Oct 2022 17:11:06 +0200
Subject: [PATCH] staging: r8188eu: fix led register settings
Using an InterTech DMG-02 dongle, the led remains on when the system goes
into standby mode. After wakeup, it's no longer possible to control the
led.
It turned out that the register settings to enable or disable the led were
not correct. They worked for some dongles like the Edimax V2 but not for
others like the InterTech DMG-02.
This patch fixes the register settings. Bit 3 in the led_cfg2 register
controls the led status, bit 5 must always be set to be able to control
the led, bit 6 has no influence on the led. Setting the mac_pinmux_cfg
register is not necessary.
These settings were tested with Edimax V2 and InterTech DMG-02.
Cc: stable(a)vger.kernel.org
Fixes: 8cd574e6af54 ("staging: r8188eu: introduce new hal dir for RTL8188eu driver")
Suggested-by: Michael Straube <straube.linux(a)gmail.com>
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Tested-by: Michael Straube <straube.linux(a)gmail.com> # InterTech DMG-02,
Tested-by: Philipp Hortmann <philipp.g.hortmann(a)gmail.com> # Edimax N150
Link: https://lore.kernel.org/r/20221015151115.232095-2-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/staging/r8188eu/core/rtw_led.c b/drivers/staging/r8188eu/core/rtw_led.c
index 2527c252c3e9..5b214488571b 100644
--- a/drivers/staging/r8188eu/core/rtw_led.c
+++ b/drivers/staging/r8188eu/core/rtw_led.c
@@ -31,40 +31,19 @@ static void ResetLedStatus(struct led_priv *pLed)
static void SwLedOn(struct adapter *padapter, struct led_priv *pLed)
{
- u8 LedCfg;
- int res;
-
if (padapter->bDriverStopped)
return;
- res = rtw_read8(padapter, REG_LEDCFG2, &LedCfg);
- if (res)
- return;
-
- rtw_write8(padapter, REG_LEDCFG2, (LedCfg & 0xf0) | BIT(5) | BIT(6)); /* SW control led0 on. */
+ rtw_write8(padapter, REG_LEDCFG2, BIT(5)); /* SW control led0 on. */
pLed->bLedOn = true;
}
static void SwLedOff(struct adapter *padapter, struct led_priv *pLed)
{
- u8 LedCfg;
- int res;
-
if (padapter->bDriverStopped)
goto exit;
- res = rtw_read8(padapter, REG_LEDCFG2, &LedCfg);/* 0x4E */
- if (res)
- goto exit;
-
- LedCfg &= 0x90; /* Set to software control. */
- rtw_write8(padapter, REG_LEDCFG2, (LedCfg | BIT(3)));
- res = rtw_read8(padapter, REG_MAC_PINMUX_CFG, &LedCfg);
- if (res)
- goto exit;
-
- LedCfg &= 0xFE;
- rtw_write8(padapter, REG_MAC_PINMUX_CFG, LedCfg);
+ rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3));
exit:
pLed->bLedOn = false;
}
The patch titled
Subject: gcov: add support for checksum field
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
gcov-add-support-for-checksum-field.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: Rickard x Andersson <rickaran(a)axis.com>
Subject: gcov: add support for checksum field
Date: Tue, 20 Dec 2022 11:23:18 +0100
In GCC version 12.1 a checksum field was added.
This patch fixes a kernel crash occurring during boot when using
gcov-kernel with GCC version 12.2. The crash occurred on a system running
on i.MX6SX.
Link: https://lkml.kernel.org/r/20221220102318.3418501-1-rickaran@axis.com
Fixes: 977ef30a7d88 ("gcov: support GCC 12.1 and newer compilers")
Signed-off-by: Rickard x Andersson <rickaran(a)axis.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Tested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Reviewed-By: Martin Liska <mliska(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/gcov/gcc_4_7.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/gcov/gcc_4_7.c~gcov-add-support-for-checksum-field
+++ a/kernel/gcov/gcc_4_7.c
@@ -82,6 +82,7 @@ struct gcov_fn_info {
* @version: gcov version magic indicating the gcc version used for compilation
* @next: list head for a singly-linked list
* @stamp: uniquifying time stamp
+ * @checksum: unique object checksum
* @filename: name of the associated gcov data file
* @merge: merge functions (null for unused counter type)
* @n_functions: number of instrumented functions
@@ -94,6 +95,10 @@ struct gcov_info {
unsigned int version;
struct gcov_info *next;
unsigned int stamp;
+ /* Since GCC 12.1 a checksum field is added. */
+#if (__GNUC__ >= 12)
+ unsigned int checksum;
+#endif
const char *filename;
void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
unsigned int n_functions;
_
Patches currently in -mm which might be from rickaran(a)axis.com are
gcov-add-support-for-checksum-field.patch
From: Rickard x Andersson <rickaran(a)axis.com>
In GCC version 12.1 a checksum field was added.
This patch fixes a kernel crash occurring during boot when
using gcov-kernel with GCC version 12.2. The crash occurred on
a system running on i.MX6SX.
Fixes: 977ef30a7d88 ("gcov: support GCC 12.1 and newer compilers")
Signed-off-by: Rickard x Andersson <rickaran(a)axis.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Tested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Cc: <stable(a)vger.kernel.org>
---
kernel/gcov/gcc_4_7.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index c699feda21ac..04880d8fba25 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -85,6 +85,7 @@ struct gcov_fn_info {
* @version: gcov version magic indicating the gcc version used for compilation
* @next: list head for a singly-linked list
* @stamp: uniquifying time stamp
+ * @checksum: unique object checksum
* @filename: name of the associated gcov data file
* @merge: merge functions (null for unused counter type)
* @n_functions: number of instrumented functions
@@ -97,6 +98,10 @@ struct gcov_info {
unsigned int version;
struct gcov_info *next;
unsigned int stamp;
+ /* Since GCC 12.1 a checksum field is added. */
+#if (__GNUC__ >= 12)
+ unsigned int checksum;
+#endif
const char *filename;
void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
unsigned int n_functions;
--
2.30.2
Am Thu, Dec 15, 2022 at 01:16:16PM -0600 schrieb Mario Limonciello:
> After we introduced a module parameter and quirk infrastructure for > picking the Microsoft GUID over the SOC vendor GUID we discovered >
that lots and lots of systems are getting this wrong. > > The table
continues to grow, and is becoming unwieldy. > > We don't really have
any benefit to forcing vendors to populate the > AMD GUID. This is just
extra work, and more and more vendors seem > to mess it up. As the
Microsoft GUID is used by Windows as well, > it's very likely that it
won't be messed up like this. > > So drop all the quirks forcing it and
the Rembrandt behavior. This > means that Cezanne or later effectively
only run the Microsoft GUID > codepath with the exception of HP
Elitebook 8*5 G9. > > Fixes: fd894f05cf30 ("ACPI: x86: s2idle: If a new
AMD _HID is missing assume Rembrandt") > Cc: stable(a)vger.kernel.org #
6.1 > Reported-by: Benjamin Cheng <ben(a)bcheng.me> > Reported-by:
bilkow(a)tutanota.com > Reported-by: Paul <paul(a)zogpog.com> > Link:
https://gitlab.freedesktop.org/drm/amd/-/issues/2292 > Link:
https://bugzilla.kernel.org/show_bug.cgi?id=216768 > Signed-off-by:
Mario Limonciello <mario.limonciello(a)amd.com> Tested-by: François ARMAND <francois(a)fanf.eu>
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2307
Regards - and thanks for the help Mario!
François
When the user moves a running task to a new rdtgroup using the tasks
file interface or by deleting its rdtgroup, the resulting change in
CLOSID/RMID must be immediately propagated to the PQR_ASSOC MSR on the
task(s) CPUs.
x86 allows reordering loads with prior stores, so if the task starts
running between a task_curr() check that the CPU hoisted before the
stores in the CLOSID/RMID update then it can start running with the old
CLOSID/RMID until it is switched again because __rdtgroup_move_task()
failed to determine that it needs to be interrupted to obtain the new
CLOSID/RMID.
Refer to the diagram below:
CPU 0 CPU 1
----- -----
__rdtgroup_move_task():
curr <- t1->cpu->rq->curr
__schedule():
rq->curr <- t1
resctrl_sched_in():
t1->{closid,rmid} -> {1,1}
t1->{closid,rmid} <- {2,2}
if (curr == t1) // false
IPI(t1->cpu)
A similar race impacts rdt_move_group_tasks(), which updates tasks in a
deleted rdtgroup.
In a memory bandwidth-metered compute host, malicious jobs could exploit
this race to remain in a previous CLOSID or RMID in order to dodge a
class-of-service downgrade imposed by an admin or to steal bandwidth.
In both cases, use smp_mb() to order the task_struct::{closid,rmid}
stores before the loads in task_curr(). In particular, in the
rdt_move_group_tasks() case, simply execute an smp_mb() on every
iteration with a matching task.
It is possible to use a single smp_mb() in rdt_move_group_tasks(), but
this would require two passes and a means of remembering which
task_structs were updated in the first loop. However, benchmarking
results below showed too little performance impact in the simple
approach to justify implementing the two-pass approach.
Times below were collected using `perf stat` to measure the time to
remove a group containing a 1600-task, parallel workload.
CPU: Intel(R) Xeon(R) Platinum P-8136 CPU @ 2.00GHz (112 threads)
# mkdir /sys/fs/resctrl/test
# echo $$ > /sys/fs/resctrl/test/tasks
# perf bench sched messaging -g 40 -l 100000
task-clock time ranges collected using:
# perf stat rmdir /sys/fs/resctrl/test
Baseline: 1.54 - 1.60 ms
smp_mb() every matching task: 1.57 - 1.67 ms
Fixes: ae28d1aae48a ("x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR")
Fixes: 0efc89be9471 ("x86/intel_rdt: Update task closid immediately on CPU in rmdir and unmount")
Signed-off-by: Peter Newman <peternewman(a)google.com>
Reviewed-by: Reinette Chatre <reinette.chatre(a)intel.com>
Cc: stable(a)vger.kernel.org
---
Patch history:
v6:
- Explain exploit case in changelog for stable
- Add Fixes: lines
v5:
- Just put an smp_mb() between CLOSID/RMID stores and task_curr() calls
- Add a diagram detailing the race to the changelog
v4:
- Reorder the patches so that justification for sending more IPIs can
reference the patch fixing __rdtgroup_move_task().
- Correct tense of wording used in changelog and comments
v3:
- Split the handling of multi-task and single-task operations into
separate patches, now that they're handled differently.
- Clarify justification in the commit message, including moving some of
it out of inline code comment.
v2:
- Following Reinette's suggestion: use task_call_func() for single
task, IPI broadcast for group movements.
- Rebased to v6.1-rc4
v1: https://lore.kernel.org/lkml/20221103141641.3055981-1-peternewman@google.co…
v2: https://lore.kernel.org/lkml/20221110135346.2209839-1-peternewman@google.co…
v3: https://lore.kernel.org/lkml/20221115141953.816851-1-peternewman@google.com/
v4: https://lore.kernel.org/lkml/20221129111055.953833-1-peternewman@google.com/
v5: https://lore.kernel.org/lkml/20221214114447.1935755-1-peternewman@google.co…
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index e5a48f05e787..5993da21d822 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -580,8 +580,10 @@ static int __rdtgroup_move_task(struct task_struct *tsk,
/*
* Ensure the task's closid and rmid are written before determining if
* the task is current that will decide if it will be interrupted.
+ * This pairs with the full barrier between the rq->curr update and
+ * resctrl_sched_in() during context switch.
*/
- barrier();
+ smp_mb();
/*
* By now, the task's closid and rmid are set. If the task is current
@@ -2401,6 +2403,14 @@ static void rdt_move_group_tasks(struct rdtgroup *from, struct rdtgroup *to,
WRITE_ONCE(t->closid, to->closid);
WRITE_ONCE(t->rmid, to->mon.rmid);
+ /*
+ * Order the closid/rmid stores above before the loads
+ * in task_curr(). This pairs with the full barrier
+ * between the rq->curr update and resctrl_sched_in()
+ * during context switch.
+ */
+ smp_mb();
+
/*
* If the task is on a CPU, set the CPU in the mask.
* The detection is inaccurate as tasks might move or
base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
--
2.39.0.314.g84b9a713c41-goog
From: Jason Gerecke <killertofu(a)gmail.com>
Some Wacom devices have a special "bootloader" mode that is used for
firmware flashing. When operating in this mode, the device cannot be
used for input, and the HID descriptor is not able to be processed by
the driver. The driver generates an "Unknown device_type" warning and
then returns an error code from wacom_probe(). This is a problem because
userspace still needs to be able to interact with the device via hidraw
to perform the firmware flash.
This commit adds a non-generic device definition for 056a:0094 which
is used when devices are in "bootloader" mode. It marks the devices
with a special BOOTLOADER type that is recognized by wacom_probe() and
wacom_raw_event(). When we see this type we ensure a hidraw device is
created and otherwise keep our hands off so that userspace is in full
control.
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Tested-by: Tatsunosuke Tobita <tatsunosuke.tobita(a)wacom.com>
Cc: <stable(a)vger.kernel.org>
---
drivers/hid/wacom_sys.c | 8 ++++++++
drivers/hid/wacom_wac.c | 4 ++++
drivers/hid/wacom_wac.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 634263e4556b..fb538a6c4add 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -155,6 +155,9 @@ static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
{
struct wacom *wacom = hid_get_drvdata(hdev);
+ if (wacom->wacom_wac.features.type == BOOTLOADER)
+ return 0;
+
if (size > WACOM_PKGLEN_MAX)
return 1;
@@ -2785,6 +2788,11 @@ static int wacom_probe(struct hid_device *hdev,
return error;
}
+ if (features->type == BOOTLOADER) {
+ hid_warn(hdev, "Using device in hidraw-only mode");
+ return hid_hw_start(hdev, HID_CONNECT_HIDRAW);
+ }
+
error = wacom_parse_and_register(wacom, false);
if (error)
return error;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 0f3d57b42684..9312d611db8e 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -4882,6 +4882,9 @@ static const struct wacom_features wacom_features_0x3dd =
static const struct wacom_features wacom_features_HID_ANY_ID =
{ "Wacom HID", .type = HID_GENERIC, .oVid = HID_ANY_ID, .oPid = HID_ANY_ID };
+static const struct wacom_features wacom_features_0x94 =
+ { "Wacom Bootloader", .type = BOOTLOADER };
+
#define USB_DEVICE_WACOM(prod) \
HID_DEVICE(BUS_USB, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\
.driver_data = (kernel_ulong_t)&wacom_features_##prod
@@ -4955,6 +4958,7 @@ const struct hid_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0x84) },
{ USB_DEVICE_WACOM(0x90) },
{ USB_DEVICE_WACOM(0x93) },
+ { USB_DEVICE_WACOM(0x94) },
{ USB_DEVICE_WACOM(0x97) },
{ USB_DEVICE_WACOM(0x9A) },
{ USB_DEVICE_WACOM(0x9F) },
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 5ca6c06d143b..16f221388563 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -243,6 +243,7 @@ enum {
MTTPC,
MTTPC_B,
HID_GENERIC,
+ BOOTLOADER,
MAX_TYPE
};
--
2.38.1
Hi,
I think something went slightly wrong when 7c7f9bc98 (serial: Deassert
Transmit Enable on probe in driver-specific way) got backported to
5.15.y. In fsl_lpuart.c, the original had this
failed_irq_request:
-failed_get_rs485:
uart_remove_one_port(&lpuart_reg, &sport->port);
failed_attach_port:
+failed_get_rs485:
failed_reset:
lpuart_disable_clks(sport);
return ret;
in the error path, but that is missing in the backport. So if we now hit
the 'goto failed_get_rs485;', we'll do uart_remove_one_port() while
uart_add_one_port() hasn't been done.
Rasmus
From: Nathan Chancellor <nathan(a)kernel.org>
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen(a)google.com>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Link: https://lore.kernel.org/r/20221102154215.78059-1-nathan@kernel.org
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index e1dd75b18118..5993d6ac85e6 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -90,8 +90,9 @@ static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
return num_modes;
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
From: Nathan Chancellor <nathan(a)kernel.org>
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen(a)google.com>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Link: https://lore.kernel.org/r/20221102154215.78059-1-nathan@kernel.org
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index c54806d08dd7..aec9fe01dfe9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -83,8 +83,9 @@ static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
return num_modes;
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
From: Nathan Chancellor <nathan(a)kernel.org>
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen(a)google.com>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Link: https://lore.kernel.org/r/20221102154215.78059-1-nathan@kernel.org
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 2298ed2a9e1c..3c8c4a820e95 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -83,8 +83,9 @@ static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
return num_modes;
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
From: Hawkins Jiawei <yin31149(a)gmail.com>
[ Upstream commit 26215b7ee923b9251f7bb12c4e5f09dc465d35f2 ]
Syzkaller reports a null-ptr-deref bug as follows:
======================================================
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
[...]
Call Trace:
<TASK>
vfs_parse_fs_param fs/fs_context.c:148 [inline]
vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129
vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191
generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231
do_new_mount fs/namespace.c:3036 [inline]
path_mount+0x12de/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
</TASK>
======================================================
According to commit "vfs: parse: deal with zero length string value",
kernel will set the param->string to null pointer in vfs_parse_fs_string()
if fs string has zero length.
Yet the problem is that, hugetlbfs_parse_param() will dereference the
param->string, without checking whether it is a null pointer. To be more
specific, if hugetlbfs_parse_param() parses an illegal mount parameter,
such as "size=,", kernel will constructs struct fs_parameter with null
pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to
hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.
This patch solves it by adding sanity check on param->string
in hugetlbfs_parse_param().
Link: https://lkml.kernel.org/r/20221020231609.4810-1-yin31149@gmail.com
Reported-by: syzbot+a3e6acd85ded5c16a709(a)syzkaller.appspotmail.com
Tested-by: syzbot+a3e6acd85ded5c16a709(a)syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000005ad00405eb7148c6@google.com/
Signed-off-by: Hawkins Jiawei <yin31149(a)gmail.com>
Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Hawkins Jiawei <yin31149(a)gmail.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/hugetlbfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 7d039ba5ae28..b1d31c78fc9d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1232,7 +1232,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_size:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->max_size_opt = memparse(param->string, &rest);
ctx->max_val_type = SIZE_STD;
@@ -1242,7 +1242,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_nr_inodes:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->nr_inodes = memparse(param->string, &rest);
return 0;
@@ -1258,7 +1258,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_min_size:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->min_size_opt = memparse(param->string, &rest);
ctx->min_val_type = SIZE_STD;
--
2.35.1
From: Hawkins Jiawei <yin31149(a)gmail.com>
[ Upstream commit 26215b7ee923b9251f7bb12c4e5f09dc465d35f2 ]
Syzkaller reports a null-ptr-deref bug as follows:
======================================================
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
[...]
Call Trace:
<TASK>
vfs_parse_fs_param fs/fs_context.c:148 [inline]
vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129
vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191
generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231
do_new_mount fs/namespace.c:3036 [inline]
path_mount+0x12de/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
</TASK>
======================================================
According to commit "vfs: parse: deal with zero length string value",
kernel will set the param->string to null pointer in vfs_parse_fs_string()
if fs string has zero length.
Yet the problem is that, hugetlbfs_parse_param() will dereference the
param->string, without checking whether it is a null pointer. To be more
specific, if hugetlbfs_parse_param() parses an illegal mount parameter,
such as "size=,", kernel will constructs struct fs_parameter with null
pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to
hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.
This patch solves it by adding sanity check on param->string
in hugetlbfs_parse_param().
Link: https://lkml.kernel.org/r/20221020231609.4810-1-yin31149@gmail.com
Reported-by: syzbot+a3e6acd85ded5c16a709(a)syzkaller.appspotmail.com
Tested-by: syzbot+a3e6acd85ded5c16a709(a)syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/0000000000005ad00405eb7148c6@google.com/
Signed-off-by: Hawkins Jiawei <yin31149(a)gmail.com>
Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Hawkins Jiawei <yin31149(a)gmail.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/hugetlbfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index a2f43f1a85f8..5181e6d4e18c 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1261,7 +1261,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_size:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->max_size_opt = memparse(param->string, &rest);
ctx->max_val_type = SIZE_STD;
@@ -1271,7 +1271,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_nr_inodes:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->nr_inodes = memparse(param->string, &rest);
return 0;
@@ -1287,7 +1287,7 @@ static int hugetlbfs_parse_param(struct fs_context *fc, struct fs_parameter *par
case Opt_min_size:
/* memparse() will accept a K/M/G without a digit */
- if (!isdigit(param->string[0]))
+ if (!param->string || !isdigit(param->string[0]))
goto bad_val;
ctx->min_size_opt = memparse(param->string, &rest);
ctx->min_val_type = SIZE_STD;
--
2.35.1
The patch titled
Subject: mm: memcontrol: deprecate charge moving
has been added to the -mm mm-unstable branch. Its filename is
mm-memcontrol-deprecate-charge-moving.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-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: Johannes Weiner <hannes(a)cmpxchg.org>
Subject: mm: memcontrol: deprecate charge moving
Date: Wed, 7 Dec 2022 14:00:39 +0100
Charge moving mode in cgroup1 allows memory to follow tasks as they
migrate between cgroups. This is, and always has been, a questionable
thing to do - for several reasons.
First, it's expensive. Pages need to be identified, locked and isolated
from various MM operations, and reassigned, one by one.
Second, it's unreliable. Once pages are charged to a cgroup, there isn't
always a clear owner task anymore. Cache isn't moved at all, for example.
Mapped memory is moved - but if trylocking or isolating a page fails,
it's arbitrarily left behind. Frequent moving between domains may leave a
task's memory scattered all over the place.
Third, it isn't really needed. Launcher tasks can kick off workload tasks
directly in their target cgroup. Using dedicated per-workload groups
allows fine-grained policy adjustments - no need to move tasks and their
physical pages between control domains. The feature was never
forward-ported to cgroup2, and it hasn't been missed.
Despite it being a niche usecase, the maintenance overhead of supporting
it is enormous. Because pages are moved while they are live and subject
to various MM operations, the synchronization rules are complicated.
There are lock_page_memcg() in MM and FS code, which non-cgroup people
don't understand. In some cases we've been able to shift code and cgroup
API calls around such that we can rely on native locking as much as
possible. But that's fragile, and sometimes we need to hold MM locks for
longer than we otherwise would (pte lock e.g.).
Mark the feature deprecated. Hopefully we can remove it soon.
And backport into -stable kernels so that people who develop against
earlier kernels are warned about this deprecation as early as possible.
Link: https://lkml.kernel.org/r/Y5COd+qXwk/S+n8N@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Hugh Dickins <hughd(a)google.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Roman Gushchin <roman.gushchin(a)linux.dev>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Documentation/admin-guide/cgroup-v1/memory.rst | 11 ++++++++++-
mm/memcontrol.c | 4 ++++
2 files changed, 14 insertions(+), 1 deletion(-)
--- a/Documentation/admin-guide/cgroup-v1/memory.rst~mm-memcontrol-deprecate-charge-moving
+++ a/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -86,6 +86,8 @@ Brief summary of control files.
memory.swappiness set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate set/show controls of moving charges
+ This knob is deprecated and shouldn't be
+ used.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
@@ -717,9 +719,16 @@ NOTE2:
It is recommended to set the soft limit always below the hard limit,
otherwise the hard limit will take precedence.
-8. Move charges at task migration
+8. Move charges at task migration (DEPRECATED!)
=================================
+THIS IS DEPRECATED!
+
+It's expensive and unreliable! It's better practice to launch workload
+tasks directly from inside their target cgroup. Use dedicated workload
+cgroups to allow fine-grained policy adjustments without having to
+move physical pages between control domains.
+
Users can move charges associated with a task along with task migration, that
is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
This feature is not supported in !CONFIG_MMU environments because of lack of
--- a/mm/memcontrol.c~mm-memcontrol-deprecate-charge-moving
+++ a/mm/memcontrol.c
@@ -3919,6 +3919,10 @@ static int mem_cgroup_move_charge_write(
{
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+ pr_warn_once("Cgroup memory moving (move_charge_at_immigrate) is deprecated. "
+ "Please report your usecase to linux-mm(a)kvack.org if you "
+ "depend on this functionality.\n");
+
if (val & ~MOVE_MASK)
return -EINVAL;
_
Patches currently in -mm which might be from hannes(a)cmpxchg.org are
mm-memcontrol-skip-moving-non-present-pages-that-are-mapped-elsewhere.patch
mm-rmap-remove-lock_page_memcg.patch
mm-memcontrol-deprecate-charge-moving.patch
The patch titled
Subject: test_maple_tree: add test for mas_spanning_rebalance() on insufficient data
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data.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: Liam Howlett <liam.howlett(a)oracle.com>
Subject: test_maple_tree: add test for mas_spanning_rebalance() on insufficient data
Date: Mon, 19 Dec 2022 16:20:15 +0000
Add a test to the maple tree test suite for the spanning rebalance
insufficient node issue does not go undetected again.
Link: https://lkml.kernel.org/r/20221219161922.2708732-3-Liam.Howlett@oracle.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Andrei Vagin <avagin(a)gmail.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/test_maple_tree.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--- a/lib/test_maple_tree.c~test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data
+++ a/lib/test_maple_tree.c
@@ -2498,6 +2498,25 @@ static noinline void check_dup(struct ma
}
}
+static noinline void check_bnode_min_spanning(struct maple_tree *mt)
+{
+ int i = 50;
+ MA_STATE(mas, mt, 0, 0);
+
+ mt_set_non_kernel(9999);
+ mas_lock(&mas);
+ do {
+ mas_set_range(&mas, i*10, i*10+9);
+ mas_store(&mas, check_bnode_min_spanning);
+ } while (i--);
+
+ mas_set_range(&mas, 240, 509);
+ mas_store(&mas, NULL);
+ mas_unlock(&mas);
+ mas_destroy(&mas);
+ mt_set_non_kernel(0);
+}
+
static DEFINE_MTREE(tree);
static int maple_tree_seed(void)
{
@@ -2742,6 +2761,10 @@ static int maple_tree_seed(void)
check_dup(&tree);
mtree_destroy(&tree);
+ mt_init_flags(&tree, MT_FLAGS_ALLOC_RANGE);
+ check_bnode_min_spanning(&tree);
+ mtree_destroy(&tree);
+
#if defined(BENCH)
skip:
#endif
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
maple_tree-fix-mas_spanning_rebalance-on-insufficient-data.patch
test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data.patch
The patch titled
Subject: maple_tree: fix mas_spanning_rebalance() on insufficient data
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
maple_tree-fix-mas_spanning_rebalance-on-insufficient-data.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: Liam Howlett <liam.howlett(a)oracle.com>
Subject: maple_tree: fix mas_spanning_rebalance() on insufficient data
Date: Mon, 19 Dec 2022 16:20:15 +0000
Mike Rapoport contacted me off-list with a regression in running criu.
Periodic tests fail with an RCU stall during execution. Although rare, it
is possible to hit this with other uses so this patch should be backported
to fix the regression.
This patchset adds the fix and a test case to the maple tree test
suite.
This patch (of 2):
An insufficient node was causing an out-of-bounds access on the node in
mas_leaf_max_gap(). The cause was the faulty detection of the new node
being a root node when overwriting many entries at the end of the tree.
Fix the detection of a new root and ensure there is sufficient data prior
to entering the spanning rebalance loop.
Link: https://lkml.kernel.org/r/20221219161922.2708732-1-Liam.Howlett@oracle.com
Link: https://lkml.kernel.org/r/20221219161922.2708732-2-Liam.Howlett@oracle.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Reported-by: Mike Rapoport <rppt(a)kernel.org>
Tested-by: Mike Rapoport <rppt(a)kernel.org>
Cc: Andrei Vagin <avagin(a)gmail.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/maple_tree.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/lib/maple_tree.c~maple_tree-fix-mas_spanning_rebalance-on-insufficient-data
+++ a/lib/maple_tree.c
@@ -2994,7 +2994,9 @@ static int mas_spanning_rebalance(struct
mast->free = &free;
mast->destroy = &destroy;
l_mas.node = r_mas.node = m_mas.node = MAS_NONE;
- if (!(mast->orig_l->min && mast->orig_r->max == ULONG_MAX) &&
+
+ /* Check if this is not root and has sufficient data. */
+ if (((mast->orig_l->min != 0) || (mast->orig_r->max != ULONG_MAX)) &&
unlikely(mast->bn->b_end <= mt_min_slots[mast->bn->type]))
mast_spanning_rebalance(mast);
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
maple_tree-fix-mas_spanning_rebalance-on-insufficient-data.patch
test_maple_tree-add-test-for-mas_spanning_rebalance-on-insufficient-data.patch
The propagate_mnt() functions handles mount propagation when creating mounts
and propagates the source mount tree headed by @source_mnt to the destination
propagation mount tree @dest_mnt. Unfortunately it contains a bug where it
fails to terminate correctly and causes a NULL dereference.
While fixing this bug we've gotten confused multiple times due to conflicting
or even missing terminology and concepts. So I want to start this with the
following clarifications:
* The terms "master" or "peer" denote a shared mount. A shared mount belongs to
a peer group identified by a peer group id recorded in
@shared_mnt->mnt_group_id. Shared mounts within the same peer group have the
same peer group id. The peers in a peer group can be reached via
@shared_mnt->mnt_share.
* Shared mounts may have dependent or "slave" mounts. These are listed on
@shared_mnt->mnt_slave_list. Multiple peers in a peer group can have
non-empty ->mnt_slave_lists and non-empty mnt_slave_lists of peers don't
intersect. Consequently, to ensure all slave mounts of a peer group are
visited the ->mnt_slave_lists of all peers in that peer group need to be
walked.
* A slave mount is a dependent mount that receives propagation from the peers
in a peer group it is a slave to. The closest peer group a slave mount
receives propagation from can be identified by looking at the peer group id
of the ->mnt_master of that slave mount, i.e., by looking at
@slave_mnt->mnt_master->mnt_group_id. A slave mount to a peer group pg1 can
itself be a peer in another peer group pg2. Such slaves will be called
"shared-slave mounts" because they are both slave mounts to pg1 and a shared
mount in a peer group pg2. Each shared-slave mount which is a peer in a peer
group pg2 can be a slave mount to a different peer group. For example,
@shared_slave_1->mnt_group_id = 1 and @shared_slave_2->mnt_group_id = 1 are
peers in the peer group with peer group id 2. But
@shared_slave_1->mnt_master->mnt_group_id = 2 and
@shared_slave_1->mnt_master->mnt_group_id = 3 are slaves to different peer
groups; @shared_slave_1 is a slave to peer group 2 and @shared_slave_2 is a
slave to peer group 3. A slave that isn't a peer in another peer group, i.e.,
is not a shared-slave mount will be called a "pure slave mount".
* A propagation group denotes the set of mounts consisting of a single peer
group pg1 and all slave mounts and shared-slave mounts that receive
propagation from this peer group, i.e., whose master is from pg1.
Specifically, the boundary of a propagation group ends with its immediate
slaves: It only encompasses the peers in that peer group and all slave mounts
whose master is a mount in that peer group such that
@slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id.
IOW, it excludes the slave mounts of peer groups that shared-slave mounts of the
peer group form. It makes it easier to talk about a single propagation
"level" whereas a propagation tree usually refers to the set of mounts that
receive propagation starting from a specific shared mount.
For example, for propagate_mnt() a @dest_mnt is the start of a propagation
tree. The peers in @dest_mnt's peer group and all slaves whose ->mnt_master
points to a peer in @dest_mnt's peer group form a propagation group. The peer
group of a shared-slave and the slave mounts whose ->mnt_master points to a
peer in the shared-slave mount's peer group form another propagation group.
With that out of the way let's get to the actual algorithm. First,
propagate_mnt() propagates the @source_mnt tree to all peers in the peer group
of @dest_mnt. We know that @dest_mnt is guaranteed to be a shared mount as
attach_recursive_mnt() will have verified this for us:
for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) {
ret = propagate_one(n);
if (ret)
goto out;
}
Notice, that it doesn't propagate @dest_mnt itself. That is because @dest_mnt
is mounted directly in attach_recursive_mnt(). This means that by the time
propagate_mnt() is called @source_mnt will not yet have been mounted on
@dest_mnt. Consequently, @source_mnt->mnt_parent will still be pointing to
it's old parent - when the mount is moved - or to itself when it's a new or
bind-mount.
So for each peer @m in the peer group of @dest_mnt we create a new copy @child
of @source_mnt and mount it @m such that @child->mnt_parent is @m. This is
straightforward and no further steps are required.
After having finished propagating @source_mnt to the peers in @dest_mnt's peer
group propagate_mnt() will propagate @source_mnt to the slaves of the peers in
@dest_mnt's peer group:
for (m = next_group(dest_mnt, dest_mnt); m;
m = next_group(m, dest_mnt)) {
/* everything in that slave group */
n = m;
do {
ret = propagate_one(n);
if (ret)
goto out;
n = next_peer(n);
} while (n != m);
}
The next_group() helper will take care to walk the destination propagation tree
by peer groups recursively. For each peer group that receives propagation it
ensures that we always find a peer in a peer group before we find any slaves of
that peer group. IOW, finding masters before slaves.
It is important to remember that propagating the @source_mnt tree to each mount
@m in the destination propagation tree simply means that we create and mount a
new copy @child of the @source_mnt tree on @m such that @child->mnt_parent is @m.
The tricky part is to figure out what the masters of the new copies of
@source_mnt will be when mounted on their new parent @m in the destination
propagation tree. This is tricky because we must keep track of the last
propagation node @m in the destination propagation tree headed by @dest_mnt and
the corresponding copy of @source_mnt we created and mounted at @. We track the
former in @last_dest and we track the later in @last_source. So with each call
to propagate_one() we advance @last_dest and @last_source to @m and @child were
@child is the copy of @last_source we created.
The easy case is what @m and @last_dest are peers as we know that we can simply
copy @last_source without having to figure out what the master for the new copy
@child of @last_source needs to be.
The hard case is when we're dealing with a slave mount or a new shared-slave
mount @m in a destination propagation group.
First, we lookup the master of @m. If we haven't descended into a separate
propagation group that @dest_mnt propagates to yes then we don't have any
marked masters and the relevant master for @m will be @dest_mnt->mnt_master.
IOW, we walk the destination master chain all the way back up to
@dest_mnt->mnt_master and break:
for (n = m; ; n = p) {
p = n->mnt_master;
if (p == dest_master || IS_MNT_MARKED(p))
break;
}
For each propagation node @m in the destination propagation tree headed
@dest_mnt we can walk up the peer group hierarchy by following the masters
@m->mnt_master of @m. Inevitably we will end up either @dest_mnt.
One the first slave mount @m of @dest_mnt in @dest_mnt's propagation group no
mount is marked yet. So the first iteration sets:
n = m;
p = n->mnt_master;
@p now points to @dest_mnt since that is it's master. We walk up one more level
since we don't have any marked mounts. So we end up with
n = dest_mnt;
p = dest_mnt->mnt_master;
Either dest_mnt is a pure shared mount then dest_mnt->mnt_master is NULL or
dest_mnt is a shared-slave and dest_mnt->mnt_master points to a master outside
the propagation tree we're dealing with.
Now we need to figure out the master for the copy of @last_source we're about
to create:
do {
struct mount *parent = last_source->mnt_parent;
if (last_source == first_source)
break;
done = parent->mnt_master == p;
if (done && peers(n, parent))
break;
last_source = last_source->mnt_master;
} while (!done);
For the first slave mount of @dest_mnt's peer group we know that
@last_source->mnt_parent points to @last_dest. And we know that @last_dest
points to the last peer we handled in propagate_mnt()'s peer loop.
Consequently, @last_source->mnt_parent->mnt_master points to
@last_dest->mnt_master.
We also know that @last_dest->mnt_master is either NULL or points to a master
outside of the propagation tree:
done = parent->mnt_master == p;
is trivially true.
We also know that for the first slave mount of @dest_mnt that @last_dest either
points @dest_mnt itself because it was initialized to:
last_dest = dest_mnt;
at the beginning of propagate_mnt() or it will point to a peer of @dest_mnt in
its peer group. In both cases it is guaranteed that on the first iteration @n
and @parent are peers:
if (done && peers(n, parent))
break;
This means that the master of the copy @child of @last_source we're going to
mount at @m needs to be @last_source. And we know that @last_source is set to
the last copy we created and mounted at the last destination node @m which was
a peer in @dest_mnt's peer group.
And since the master of the first destination propagation node @m we handled
after handling the peer of @dest_mnt's peer group is @dest_mnt - as it's a
slave mount of @dest_mnt - we mark this mount as a master.
Although less obvious, the lookup of the correct master for @last_source is
premised on the assumption that each copy of @source_mnt that is mounted on top
of @m we will allows us to similarly traverse the peer group hierarchy of the
destination propagation tree.
If we take @last_source which is the copy of @source_mnt we have mounted on @m
in previous iteration of propagate_one() then @last_source->mnt_master will
point to an earlier copy of @last_source that we mounted at the previous
destination propagation node @m. Hence, the first
@last_source->mnt_master->mnt_parent will point to @last_dest and
@last_dest->mnt_master will be our hook into the master hierarchy of the
destination propagation tree headed @dest_mnt.
Hence, by walking up @last_source->mnt_master we will walk up the new source
destination peer group hierarchy each anchored at a destination propagation
node @m in the destination propagation tree headed at @dest_mnt.
IOW, the destination propagation tree will be overlayed with copies of
@source_mnt. And when we're all done with this the sequence of copies of
@source_mnt we mounted on top the destination propagation nodes @m will mirror
the propagation of the destination nodes @m.
So, for each new destination propagation node @m we use the previous copy of
@last_source and previous destination propagation node @last_dest to determine
what the master of the new copy of @last_source has to be.
And with each destination propagation node @m we mount a copy of @source_mnt on
we will mark the peer which is the closest peer that @m receives propagation
from in the destination propagation tree.
For the next @m we search for a marked master which will be the closest peer
group that @m receives propagation from. We store that master in @p and record
the previous destination propagation node @n.
We then search for this master via @last_source by walking up the master
hierarchy based on the last copy of @last_source we mounted on the previous
destination propagation node.
Ultimately we will hit a master in the source propagation master hierarchy that
is mounted on a previous destination propagation node @m. We can access that @m
via @last_source->mnt_master->mnt_parent.
We will then find a master @last_source->mnt_master->mnt_parent->mnt_master
that will correspond to the closest marked peer group master @p we receive
propagation from and that we detected earlier.
Now, if @last_source->mnt_master->mnt_parent and @n are peers then we know that
the new master is the one we just looked up: @last_source. If they aren't peers
we know that the new master needs to be @last_source->mnt_master.
However, terminating the walk has corner cases...
If the closest marked master for a given destination node @m cannot be found by
walking up the master hierarchy based on @last_source then we need to terminate
the walk when we encounter @source_mnt as this means @source_mnt will be the
master of the new copy of @last_source we're about to create.
As @last_source might not have a master this would lead to a NULL dereference.
So we have to stop the walk when we encounter @source_mnt again.
In a way, this happens when we handled the last slave mount that is a slave to
a peer group that receives propagation from @dest_mnt's peer group, i.e., when
we "reascend" from handling slaves of peer groups deeper down the propagation
tree back to a slave mount that receives propagation in @dest_mnt's peer group
so a slave mount in @dest_mnt's propagation group.
So terminate on @source_mnt, easy peasy. Except, that it misses something what
the rest of the algorithm already handles.
If @dest_mnt has peers in it's peer group the first loop in propagate_mnt():
for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) {
ret = propagate_one(n);
if (ret)
goto out;
}
will consecutively update @last_source such that after that loop terminates
@last_source will point to whatever copy was created for the last peer in that
peer group.
It is however guaranteed that if there is a single additional peer in
@dest_mnt's peer group that @last_source will __not__ point to @source_mnt
anymore. Because, as we mentioned above, @dest_mnt isn't even handled in this
loop but directly in attach_recursive_mnt().
So the first time we handle a slave mount @m of @dest_mnt's peer group the copy
of @last_source we create will make the __last copy for the last peer in
@dest_mnt's peer group__ we created the master of the copy that we now create
for the first slave mount of @dest_mnt's peer group.
But this means that the termination condition @source_mnt is wrong. The
@source_mnt cannot be found anymore by propagate_one(). Instead it will find
the copy we created for the last peer of @dest_mnt's peer group we processed in
the earlier peer loop. And that is a peer of @source_mnt not @source_mnt
itself.
IOW, we fail to terminate the lookup loop for the source master and ultimately
deref @last_source->mnt_master->mnt_parent when @last_source->mnt_master is
NULL because @source_mnt and it's peers are pure shared mounts, i.e., they
aren't slaves to another peer group.
For example, assume @dest_mnt is a pure shared mount and has three peers:
===================================================================================
mount-id mount-parent-id peer-group-id
===================================================================================
(@dest_mnt) mnt_master[216] 309 297 shared:216
\
(@source_mnt) mnt_master[218]: 609 609 shared:218
(1) mnt_master[216]: 607 605 shared:216
\
(P1) mnt_master[218]: 624 607 shared:218
(2) mnt_master[216]: 576 574 shared:216
\
(P2) mnt_master[218]: 625 576 shared:218
(3) mnt_master[216]: 545 543 shared:216
\
(P3) mnt_master[218]: 626 545 shared:218
After this sequence has been processed @last_source will point to (P3), the
copy generated for the third peer propagation we handled. So the first slave
of @dest_mnt's peer group we handle:
===================================================================================
mount-id mount-parent-id peer-group-id
===================================================================================
mnt_master[216] 309 297 shared:216
/
/
(S0) mnt_slave 483 481 master:216
\
\ (P3) mnt_master[218] 626 545 shared:218
\ /
\/
(P4) mnt_slave 627 483 master:218
we can see that (P3) will become the master of the copy of the new slave we
created in propagation (P4) and mounted on top of the first slave (S0) of
@dest_mnt.
On any give walk through the @last_source master hierarchy we generate we may
encounter (P3) but not @source_mnt itself. Ultimately leading to a NULL
dereference.
We can fix this in multiple ways. First, by setting:
@last_source = @source_mnt
after we processed the peers in @dest_mnt's peer group. Second, by changing the
termination condition that relies on finding exactly @source_mnt to find a peer
of @source_mnt. Third, by only moving @last_source when we actually venture
into a new peer group. The latter is more intrusive but something I'd like to
explore in the near future.
Now, we just do the minimally correct thing. Passes LTP and specifically the
mount propagation testsuite part of it and holds up against all reproducers.
Final words...
First, this is a clever but __worringly__ underdocumented algorithm. There
isn't a single detailed comment to be found in next_group(), propagate_one() or
anywhere else in that file for that matter. This has been a giant pain to
understand and work through and a bug like this is insanely difficult to fix
without detailed understanding of what's happening. Let's not talk about the
amount of time that was sunk into fixing this.
Second, all the cool kids with access to
unshare --mount --user --map-root --propagation=unchanged
are going to have a lot of fun.
[ 115.848393] BUG: kernel NULL pointer dereference, address: 0000000000000010
[ 115.848967] #PF: supervisor read access in kernel mode
[ 115.849386] #PF: error_code(0x0000) - not-present page
[ 115.849803] PGD 0 P4D 0
[ 115.850012] Oops: 0000 [#1] PREEMPT SMP PTI
[ 115.850354] CPU: 0 PID: 15591 Comm: mount Not tainted 6.1.0-rc7 #3
[ 115.850851] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 115.851510] RIP: 0010:propagate_one.part.0+0x7f/0x1a0
[ 115.851924] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10
49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01
00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37
02 4d
[ 115.853441] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282
[ 115.853865] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00
[ 115.854458] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780
[ 115.855044] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0
[ 115.855693] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8
[ 115.856304] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000
[ 115.856859] FS: 00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000)
knlGS:0000000000000000
[ 115.857531] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 115.858006] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0
[ 115.858598] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 115.859393] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 115.860099] Call Trace:
[ 115.860358] <TASK>
[ 115.860535] propagate_mnt+0x14d/0x190
[ 115.860848] attach_recursive_mnt+0x274/0x3e0
[ 115.861212] path_mount+0x8c8/0xa60
[ 115.861503] __x64_sys_mount+0xf6/0x140
[ 115.861819] do_syscall_64+0x5b/0x80
[ 115.862117] ? do_faccessat+0x123/0x250
[ 115.862435] ? syscall_exit_to_user_mode+0x17/0x40
[ 115.862826] ? do_syscall_64+0x67/0x80
[ 115.863133] ? syscall_exit_to_user_mode+0x17/0x40
[ 115.863527] ? do_syscall_64+0x67/0x80
[ 115.863835] ? do_syscall_64+0x67/0x80
[ 115.864144] ? do_syscall_64+0x67/0x80
[ 115.864452] ? exc_page_fault+0x70/0x170
[ 115.864775] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 115.865187] RIP: 0033:0x7f92c92b0ebe
[ 115.865480] Code: 48 8b 0d 75 4f 0c 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 42 4f 0c 00 f7 d8 64 89
01 48
[ 115.866984] RSP: 002b:00007fff000aa728 EFLAGS: 00000246 ORIG_RAX:
00000000000000a5
[ 115.867607] RAX: ffffffffffffffda RBX: 000055a77888d6b0 RCX: 00007f92c92b0ebe
[ 115.868240] RDX: 000055a77888d8e0 RSI: 000055a77888e6e0 RDI: 000055a77888e620
[ 115.868823] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
[ 115.869403] R10: 0000000000001000 R11: 0000000000000246 R12: 000055a77888e620
[ 115.869994] R13: 000055a77888d8e0 R14: 00000000ffffffff R15: 00007f92c93e4076
[ 115.870581] </TASK>
[ 115.870763] Modules linked in: 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 rfkill nf_tables nfnetlink qrtr snd_intel8x0
sunrpc snd_ac97_codec ac97_bus snd_pcm snd_timer intel_rapl_msr
intel_rapl_common snd vboxguest intel_powerclamp video rapl joydev
soundcore i2c_piix4 wmi fuse zram xfs vmwgfx crct10dif_pclmul
crc32_pclmul crc32c_intel polyval_clmulni polyval_generic
drm_ttm_helper ttm e1000 ghash_clmulni_intel serio_raw ata_generic
pata_acpi scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_multipath
[ 115.875288] CR2: 0000000000000010
[ 115.875641] ---[ end trace 0000000000000000 ]---
[ 115.876135] RIP: 0010:propagate_one.part.0+0x7f/0x1a0
[ 115.876551] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10
49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01
00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37
02 4d
[ 115.878086] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282
[ 115.878511] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00
[ 115.879128] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780
[ 115.879715] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0
[ 115.880359] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8
[ 115.880962] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000
[ 115.881548] FS: 00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000)
knlGS:0000000000000000
[ 115.882234] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 115.882713] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0
[ 115.883314] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 115.883966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Fixes: f2ebb3a921c1 ("smarter propagate_mnt()")
Cc: <stable(a)vger.kernel.org>
Reported-by: Ditang Chen <ditang.c(a)gmail.com>
Signed-off-by: Seth Forshee (Digital Ocean) <sforshee(a)kernel.org>
Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
---
If there are no big objections I'll get this to Linus rather sooner than later.
Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
---
fs/pnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pnode.c b/fs/pnode.c
index 1106137c747a..468e4e65a615 100644
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -244,7 +244,7 @@ static int propagate_one(struct mount *m)
}
do {
struct mount *parent = last_source->mnt_parent;
- if (last_source == first_source)
+ if (peers(last_source, first_source))
break;
done = parent->mnt_master == p;
if (done && peers(n, parent))
base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
--
2.34.1
Mike Rapoport contacted me off-list with a regression in running criu.
Periodic tests fail with an RCU stall during execution. Although rare,
it is possible to hit this with other uses so this patch should be
backported to fix the regression.
This patch set adds the fix and a test case to the maple tree test
suite.
Link: https://lore.kernel.org/linux-mm/20221216185233.2036415-1-Liam.Howlett@orac…
V1 changes:
- Add stable to CC list
- Add tested-by to Mike's Reported-by.
- Moved test case to its own commit since the test code was added after
the fixed-by commit and isn't part of the fix.
Liam R. Howlett (2):
maple_tree: Fix mas_spanning_rebalance() on insufficient data
test_maple_tree: Add test for mas_spanning_rebalance() on insufficient
data
lib/maple_tree.c | 4 +++-
lib/test_maple_tree.c | 23 +++++++++++++++++++++++
2 files changed, 26 insertions(+), 1 deletion(-)
--
2.35.1
The removal of "hotplug-status" has moved around a bit. First it was
moved from netback_remove() to hotplug_status_changed() in upstream
commit 1f2565780e9b ("xen-netback: remove 'hotplug-status' once it has
served its purpose"). Then the change was reverted in upstream commit
0f4558ae9187 ("Revert "xen-netback: remove 'hotplug-status' once it has
served its purpose""), but it moved the removal to backend_disconnect().
Then the upstream commit c55f34b6aec2 ("xen-netback: only remove
'hotplug-status' when the vif is actually destroyed") moved it finally
back to netback_remove(). The thing to note being it is removed
unconditionally this time around.
The story on v5.4.y adds to this confusion. Commit 60e4e3198ce8 ("Revert
"xen-netback: remove 'hotplug-status' once it has served its purpose"")
is backported to v5.4.y but the original commit that it tries to revert
was never present on 5.4. So the backport incorrectly ends up just
adding another xenbus_rm() of "hotplug-status" in backend_disconnect().
Now in v5.4.y it is removed in both backend_disconnect() and
netback_remove(). But it should only be removed in netback_remove(), as
the upstream version does.
Removing "hotplug-status" in backend_disconnect() causes problems when
the frontend unilaterally disconnects, as explained in
c55f34b6aec2 ("xen-netback: only remove 'hotplug-status' when the vif is
actually destroyed").
Remove "hotplug-status" in the same place as it is done on the upstream
version to ensure unilateral re-connection of frontend continues to
work.
Fixes: 60e4e3198ce8 ("Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"")
Signed-off-by: Pratyush Yadav <ptyadav(a)amazon.de>
---
drivers/net/xen-netback/xenbus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 44e353dd2ba1..43bd881ab3dd 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -202,10 +202,10 @@ static int netback_remove(struct xenbus_device *dev)
set_backend_state(be, XenbusStateClosed);
unregister_hotplug_status_watch(be);
+ xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
if (be->vif) {
kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
xen_unregister_watchers(be->vif);
- xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
xenvif_free(be->vif);
be->vif = NULL;
}
@@ -435,7 +435,6 @@ static void backend_disconnect(struct backend_info *be)
unsigned int queue_index;
xen_unregister_watchers(vif);
- xenbus_rm(XBT_NIL, be->dev->nodename, "hotplug-status");
#ifdef CONFIG_DEBUG_FS
xenvif_debugfs_delif(vif);
#endif /* CONFIG_DEBUG_FS */
--
2.38.1
The patch below does not apply to the 4.14-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
37711e5e2325 ("Merge tag 'nfs-for-5.9-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 4.19-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
37711e5e2325 ("Merge tag 'nfs-for-5.9-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 5.4-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
37711e5e2325 ("Merge tag 'nfs-for-5.9-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 5.15-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 6.0-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 6.1-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>.
Possible dependencies:
ecec4b20d29c ("usb: musb: remove extra check in musb_gadget_vbus_draw")
a6d45ea063f0 ("usb: musb: Allow running without CONFIG_USB_PHY")
21acc656a06e ("usb: musb: Add and use inline functions musb_{get,set}_state")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ecec4b20d29c3d6922dafe7d2555254a454272d2 Mon Sep 17 00:00:00 2001
From: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Date: Fri, 25 Nov 2022 20:21:15 +0200
Subject: [PATCH] usb: musb: remove extra check in musb_gadget_vbus_draw
The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
usb_phy_set_power(), so there is no need of them. Moreover, not calling
usb_phy_set_power() results in usb_phy_set_charger_current() not being
called, so current USB config max current is not propagated through USB
charger framework and charger drivers may try to draw more current than
allowed or possible.
Fix that by removing those extra checks and calling usb_phy_set_power()
directly.
Tested on Motorola Droid4 and Nokia N900
Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com>
Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6cb9514ef340..31c44325e828 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1630,8 +1630,6 @@ static int musb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
struct musb *musb = gadget_to_musb(gadget);
- if (!musb->xceiv || !musb->xceiv->set_power)
- return -EOPNOTSUPP;
return usb_phy_set_power(musb->xceiv, mA);
}
The patch below does not apply to the 5.15-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>.
Possible dependencies:
12c6223fc180 ("staging: r8188eu: fix led register settings")
647085006beb ("staging: r8188eu: don't check bSurpriseRemoved in SwLedOff")
8f60cb9534e4 ("staging: r8188eu: remove duplicate bSurpriseRemoved check")
857fe9e5efc0 ("staging: r8188eu: add error handling of rtw_read8")
5e080cd771e8 ("staging: r8188eu: improve timeout handling in efuse_read_phymap_from_txpktbuf")
efe20b73c5ca ("staging: r8188eu: improve timeout handling in iol_execute")
1060ec636d8b ("staging: r8188eu: improve timeout handling in rtl8188e_firmware_download")
26209855c3ed ("staging: r8188eu: remove HW_VAR_MLME_JOIN")
6b58692032c1 ("staging: r8188eu: remove SetHalDefVar8188EUsb()")
09ff203cb0c5 ("staging: r8188eu: remove GetHalDefVar8188EUsb()")
72b304d013e9 ("staging: r8188eu: remove HAL_DEF_CURRENT_ANTENNA")
0b465150b322 ("staging: r8188eu: remove HAL_DEF_IS_SUPPORT_ANT_DIV")
e665487795a6 ("staging: r8188eu: remove HW_VAR_AMPDU_MIN_SPACE from SetHwReg8188EU()")
7c1972941ad3 ("staging: r8188eu: remove HW_VAR_BSSID from SetHwReg8188EU()")
d8a130d13497 ("staging: r8188eu: remove GetHwReg8188EU()")
61f514799bea ("staging: r8188eu: remove HW_VAR_FWLPS_RF_ON from GetHwReg8188EU()")
9494dba5d734 ("staging: r8188eu: remove HW_VAR_CHK_HI_QUEUE_EMPTY from GetHwReg8188EU()")
ae3d0470ab57 ("staging: r8188eu: remove HW_VAR_BCN_VALID from GetHwReg8188EU()")
db975705cbbe ("staging: r8188eu: rename clear_bacon_valid_bit()")
f6ca689d12df ("staging: r8188eu: remove the "dump tx packet" fragments")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 12c6223fc1804fd9295dc50d358294539b4a4184 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Sat, 15 Oct 2022 17:11:06 +0200
Subject: [PATCH] staging: r8188eu: fix led register settings
Using an InterTech DMG-02 dongle, the led remains on when the system goes
into standby mode. After wakeup, it's no longer possible to control the
led.
It turned out that the register settings to enable or disable the led were
not correct. They worked for some dongles like the Edimax V2 but not for
others like the InterTech DMG-02.
This patch fixes the register settings. Bit 3 in the led_cfg2 register
controls the led status, bit 5 must always be set to be able to control
the led, bit 6 has no influence on the led. Setting the mac_pinmux_cfg
register is not necessary.
These settings were tested with Edimax V2 and InterTech DMG-02.
Cc: stable(a)vger.kernel.org
Fixes: 8cd574e6af54 ("staging: r8188eu: introduce new hal dir for RTL8188eu driver")
Suggested-by: Michael Straube <straube.linux(a)gmail.com>
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Tested-by: Michael Straube <straube.linux(a)gmail.com> # InterTech DMG-02,
Tested-by: Philipp Hortmann <philipp.g.hortmann(a)gmail.com> # Edimax N150
Link: https://lore.kernel.org/r/20221015151115.232095-2-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/staging/r8188eu/core/rtw_led.c b/drivers/staging/r8188eu/core/rtw_led.c
index 2527c252c3e9..5b214488571b 100644
--- a/drivers/staging/r8188eu/core/rtw_led.c
+++ b/drivers/staging/r8188eu/core/rtw_led.c
@@ -31,40 +31,19 @@ static void ResetLedStatus(struct led_priv *pLed)
static void SwLedOn(struct adapter *padapter, struct led_priv *pLed)
{
- u8 LedCfg;
- int res;
-
if (padapter->bDriverStopped)
return;
- res = rtw_read8(padapter, REG_LEDCFG2, &LedCfg);
- if (res)
- return;
-
- rtw_write8(padapter, REG_LEDCFG2, (LedCfg & 0xf0) | BIT(5) | BIT(6)); /* SW control led0 on. */
+ rtw_write8(padapter, REG_LEDCFG2, BIT(5)); /* SW control led0 on. */
pLed->bLedOn = true;
}
static void SwLedOff(struct adapter *padapter, struct led_priv *pLed)
{
- u8 LedCfg;
- int res;
-
if (padapter->bDriverStopped)
goto exit;
- res = rtw_read8(padapter, REG_LEDCFG2, &LedCfg);/* 0x4E */
- if (res)
- goto exit;
-
- LedCfg &= 0x90; /* Set to software control. */
- rtw_write8(padapter, REG_LEDCFG2, (LedCfg | BIT(3)));
- res = rtw_read8(padapter, REG_MAC_PINMUX_CFG, &LedCfg);
- if (res)
- goto exit;
-
- LedCfg &= 0xFE;
- rtw_write8(padapter, REG_MAC_PINMUX_CFG, LedCfg);
+ rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3));
exit:
pLed->bLedOn = false;
}
From: Tony Jones <tonyj(a)suse.de>
[Upstream commit d72eadbc1d2866fc047edd4535ffb0298fe240be]
tests/attr.c invokes attr.py via an explicit invocation of Python
($PYTHON) so there is therefore no need for an explicit shebang.
Also most distros follow pep-0394 which recommends that /usr/bin/python
refer only to v2 and so may not exist on the system (if PYTHON=python3).
Signed-off-by: Tony Jones <tonyj(a)suse.de>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Ravi Bangoria <ravi.bangoria(a)linux.ibm.com>
Cc: Seeteena Thoufeek <s1seetee(a)linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20190124005229.16146-5-tonyj@suse.de
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu>
---
tools/perf/tests/attr.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/tests/attr.py b/tools/perf/tests/attr.py
index 6c68435585c7..3e07eee33b10 100644
--- a/tools/perf/tests/attr.py
+++ b/tools/perf/tests/attr.py
@@ -1,4 +1,3 @@
-#! /usr/bin/env python
# SPDX-License-Identifier: GPL-2.0
import os
--
2.38.1
full_hit() directly uses cpu as an array index. Since
RING_BUFFER_ALL_CPUS == -1, calling full_hit() with cpu ==
RING_BUFFER_ALL_CPUS will cause an invalid memory access.
The upstream commit 42fb0a1e84ff ("tracing/ring-buffer: Have polling
block on watermark") already does this. This was missed when backporting
to v5.4.y.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Fixes: e65ac2bdda54 ("tracing/ring-buffer: Have polling block on watermark")
Signed-off-by: Pratyush Yadav <ptyadav(a)amazon.de>
---
I am not familiar with this code. This was just pointed out by our
static analysis tool and I wrote a quick patch fixing this. Only
compile-tested.
kernel/trace/ring_buffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 176d858903bd..11e8189dd8ae 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -727,6 +727,7 @@ __poll_t ring_buffer_poll_wait(struct ring_buffer *buffer, int cpu,
if (cpu == RING_BUFFER_ALL_CPUS) {
work = &buffer->irq_work;
+ full = 0;
} else {
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return -EINVAL;
--
2.38.1
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Hi Stable maintainers,
On 12/5/22 06:21, irqchip-bot for Sean Anderson wrote:
> The following commit has been merged into the irq/irqchip-next branch of irqchip:
>
> Commit-ID: 3ae977d0e4e3a2a2ccc912ca2d20c9430508ecdd
> Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/3ae977d0e…
> Author: Sean Anderson <sean.anderson(a)seco.com>
> AuthorDate: Thu, 01 Dec 2022 16:28:07 -05:00
> Committer: Marc Zyngier <maz(a)kernel.org>
> CommitterDate: Mon, 05 Dec 2022 10:39:52
>
> irqchip/ls-extirq: Fix endianness detection
>
> parent is the interrupt parent, not the parent of node. Use
> node->parent. This fixes endianness detection on big-endian platforms.
>
> Fixes: 1b00adce8afd ("irqchip/ls-extirq: Fix invalid wait context by avoiding to use regmap")
> Signed-off-by: Sean Anderson <sean.anderson(a)seco.com>
> Signed-off-by: Marc Zyngier <maz(a)kernel.org>
> Link: https://lore.kernel.org/r/20221201212807.616191-1-sean.anderson@seco.com
> ---
> drivers/irqchip/irq-ls-extirq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-ls-extirq.c b/drivers/irqchip/irq-ls-extirq.c
> index d8d48b1..139f26b 100644
> --- a/drivers/irqchip/irq-ls-extirq.c
> +++ b/drivers/irqchip/irq-ls-extirq.c
> @@ -203,7 +203,7 @@ ls_extirq_of_init(struct device_node *node, struct device_node *parent)
> if (ret)
> goto err_parse_map;
>
> - priv->big_endian = of_device_is_big_endian(parent);
> + priv->big_endian = of_device_is_big_endian(node->parent);
> priv->is_ls1021a_or_ls1043a = of_device_is_compatible(node, "fsl,ls1021a-extirq") ||
> of_device_is_compatible(node, "fsl,ls1043a-extirq");
> raw_spin_lock_init(&priv->lock);
This patch has made it into linux/master, but it should also get
backported to 6.1. Just want to make sure this doesn't fall through the
cracks, since this was a really annoying bug to deal with (causes an IRQ
storm).
--Sean
Hi stable team,
I would like to request for cherry picking to the linux-6.1.y branch:
19098934f910 ("PCI: mt7621: Add sentinel to quirks table")
a2cab953b4c0 ("mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem")
b4767d4c0725 ("mips: ralink: mt7621: soc queries and tests as functions")
7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")
On the mips mt7621 SoC, a kzalloc is used too early and returns before reaching a soc_device_register.
soc_device_attribute->revision is used to identify MT7621 ver:1 eco:1 devices for a pci & phy-pci quirk.
A SLUB change in kernel 6.1 caused the device to fail to boot, rather than silently continue.
In fixing this, it was then seen that the pci & phy-pci drivers would oops,
as they were missing a sentinel in their soc_device_match quirks table.
The phy-pci fix has already been applied to stable.
The pci & early kzalloc fixes missed the 6.1rc window and are being taken for 6.2
In a quick web search I cannot find any reference to bootlogs for "ver:1 eco:1"
(which would use the quirk for PCI), so cannot see a current need to backport this
further than fixing the 6.1 boot error.
Link: https://lore.kernel.org/linux-mm/becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.f…
Link: https://lore.kernel.org/lkml/20221205204645.301301-1-git@johnthomson.fastma…
Link: https://lore.kernel.org/lkml/20221114015658.2873120-1-git@johnthomson.fastm…
cc'ed the maintainer, Sergio.
Thank you,
Cheers,
--
John Thomson
I'm announcing the release of the 6.0.14 kernel.
All users of the 6.0 kernel series must upgrade.
The updated 6.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.0.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
arch/x86/entry/vdso/vdso.lds.S | 2 +
drivers/net/can/usb/mcba_usb.c | 10 ++++++--
drivers/net/ethernet/freescale/fec_main.c | 23 ++++++-------------
drivers/nvme/host/pci.c | 2 +
drivers/pinctrl/mediatek/mtk-eint.c | 9 +++++--
drivers/rtc/rtc-cmos.c | 35 ++++++++++++++++++++++--------
include/linux/can/platform/sja1000.h | 2 -
kernel/events/core.c | 17 +++++++++++---
sound/soc/codecs/cs42l51.c | 2 -
sound/soc/fsl/fsl_micfil.c | 19 ++++++++++++++++
sound/soc/soc-ops.c | 9 ++++++-
tools/lib/bpf/btf_dump.c | 2 -
tools/lib/bpf/libbpf_probes.c | 2 -
14 files changed, 94 insertions(+), 42 deletions(-)
Alexandre Belloni (1):
rtc: cmos: fix build on non-ACPI platforms
Charles Keepax (2):
ASoC: cs42l51: Correct PGA Volume minimum value
ASoC: ops: Correct bounds check for second channel on SX controls
David Michael (1):
libbpf: Fix uninitialized warning in btf_dump_dump_type_data
Greg Kroah-Hartman (1):
Linux 6.0.14
Heiko Schocher (1):
can: sja1000: fix size of OCR_MODE_MASK define
Hou Tao (1):
libbpf: Use page size as max_entries when probing ring buffer map
Lei Rao (1):
nvme-pci: clear the prp2 field when not used
Mark Brown (1):
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Nathan Chancellor (1):
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
Peter Zijlstra (1):
perf: Fix perf_pending_task() UaF
Rafael J. Wysocki (2):
rtc: cmos: Fix event handler registration ordering issue
rtc: cmos: Fix wake alarm breakage
Rasmus Villemoes (2):
net: fec: don't reset irq coalesce settings to defaults on "ip link up"
net: fec: properly guard irq coalesce setup
Ricardo Ribalda (1):
pinctrl: meditatek: Startup with the IRQs disabled
Shengjiu Wang (2):
ASoC: fsl_micfil: explicitly clear software reset bit
ASoC: fsl_micfil: explicitly clear CHnF flags
Yasushi SHOJI (1):
can: mcba_usb: Fix termination command argument
I'm announcing the release of the 5.10.160 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/x86/kernel/cpu/mtrr/mtrr.c | 2
arch/x86/kernel/smpboot.c | 1
drivers/net/can/usb/mcba_usb.c | 10 +
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3
drivers/nvme/host/pci.c | 2
drivers/pinctrl/mediatek/mtk-eint.c | 9 +
fs/fuse/dir.c | 2
fs/io_uring.c | 2
fs/nfsd/vfs.c | 8 +
fs/read_write.c | 90 +++++++++------
include/linux/can/platform/sja1000.h | 2
include/linux/fs.h | 8 +
sound/soc/codecs/cs42l51.c | 2
sound/soc/fsl/fsl_micfil.c | 19 +++
sound/soc/soc-ops.c | 9 +
tools/lib/bpf/libbpf_probes.c | 2
17 files changed, 121 insertions(+), 52 deletions(-)
Amir Goldstein (2):
vfs: fix copy_file_range() regression in cross-fs copies
vfs: fix copy_file_range() averts filesystem freeze protection
Bing-Jhong Billy Jheng (1):
io_uring: add missing item types for splice request
Charles Keepax (2):
ASoC: cs42l51: Correct PGA Volume minimum value
ASoC: ops: Correct bounds check for second channel on SX controls
Greg Kroah-Hartman (1):
Linux 5.10.160
Heiko Schocher (1):
can: sja1000: fix size of OCR_MODE_MASK define
Hou Tao (1):
libbpf: Use page size as max_entries when probing ring buffer map
Jialiang Wang (1):
nfp: fix use-after-free in area_cache_get()
Lei Rao (1):
nvme-pci: clear the prp2 field when not used
Mark Brown (1):
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Miklos Szeredi (1):
fuse: always revalidate if exclusive create
Paul E. McKenney (1):
x86/smpboot: Move rcu_cpu_starting() earlier
Ricardo Ribalda (1):
pinctrl: meditatek: Startup with the IRQs disabled
Shengjiu Wang (2):
ASoC: fsl_micfil: explicitly clear software reset bit
ASoC: fsl_micfil: explicitly clear CHnF flags
Yasushi SHOJI (1):
can: mcba_usb: Fix termination command argument
I'm announcing the release of the 5.4.228 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
arch/x86/kernel/cpu/mtrr/mtrr.c | 2 -
arch/x86/kernel/smpboot.c | 1
block/partition-generic.c | 7 +++
drivers/net/can/usb/mcba_usb.c | 10 +++--
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 +
drivers/pinctrl/mediatek/mtk-eint.c | 9 +++-
include/linux/can/platform/sja1000.h | 2 -
include/linux/hugetlb.h | 6 +--
mm/gup.c | 13 ++++++
mm/hugetlb.c | 30 +++++++--------
net/core/filter.c | 2 +
sound/soc/soc-ops.c | 9 ++++
13 files changed, 65 insertions(+), 31 deletions(-)
Baolin Wang (1):
mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page
Charles Keepax (1):
ASoC: ops: Correct bounds check for second channel on SX controls
Greg Kroah-Hartman (1):
Linux 5.4.228
Heiko Schocher (1):
can: sja1000: fix size of OCR_MODE_MASK define
Jialiang Wang (1):
nfp: fix use-after-free in area_cache_get()
Lorenzo Colitti (1):
net: bpf: Allow TC programs to call BPF_FUNC_skb_change_head
Mark Brown (1):
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Ming Lei (1):
block: unhash blkdev part inode when the part is deleted
Paul E. McKenney (1):
x86/smpboot: Move rcu_cpu_starting() earlier
Ricardo Ribalda (1):
pinctrl: meditatek: Startup with the IRQs disabled
Yasushi SHOJI (1):
can: mcba_usb: Fix termination command argument
The catch-all evict can fail due to object lock contention, since it
only goes as far as trylocking the object, due to us already holding the
vm->mutex. Doing a full object lock here can deadlock, since the
vm->mutex is always our inner lock. Add another execbuf pass which drops
the vm->mutex and then tries to grab the object will the full lock,
before then retrying the eviction. This should be good enough for now to
fix the immediate regression with userspace seeing -ENOSPC from execbuf
due to contended object locks during GTT eviction.
v2 (Mani)
- Also revamp the docs for the different passes.
Testcase: igt@gem_ppgtt@shrink-vs-evict-*
Fixes: 7e00897be8bf ("drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something, v2.")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7627
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7570
References: https://bugzilla.mozilla.org/show_bug.cgi?id=1779558
Signed-off-by: Matthew Auld <matthew.auld(a)intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda(a)intel.com>
Cc: Mani Milani <mani(a)chromium.org>
Cc: <stable(a)vger.kernel.org> # v5.18+
Reviewed-by: Mani Milani <mani(a)chromium.org>
Tested-by: Mani Milani <mani(a)chromium.org>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 59 +++++++++++++++----
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/i915_gem_evict.c | 37 ++++++++----
drivers/gpu/drm/i915/i915_gem_evict.h | 4 +-
drivers/gpu/drm/i915/i915_vma.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
6 files changed, 82 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 192bb3f10733..f98600ca7557 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -733,32 +733,69 @@ static int eb_reserve(struct i915_execbuffer *eb)
bool unpinned;
/*
- * Attempt to pin all of the buffers into the GTT.
- * This is done in 2 phases:
+ * We have one more buffers that we couldn't bind, which could be due to
+ * various reasons. To resolve this we have 4 passes, with every next
+ * level turning the screws tighter:
*
- * 1. Unbind all objects that do not match the GTT constraints for
- * the execbuffer (fenceable, mappable, alignment etc).
- * 2. Bind new objects.
+ * 0. Unbind all objects that do not match the GTT constraints for the
+ * execbuffer (fenceable, mappable, alignment etc). Bind all new
+ * objects. This avoids unnecessary unbinding of later objects in order
+ * to make room for the earlier objects *unless* we need to defragment.
*
- * This avoid unnecessary unbinding of later objects in order to make
- * room for the earlier objects *unless* we need to defragment.
+ * 1. Reorder the buffers, where objects with the most restrictive
+ * placement requirements go first (ignoring fixed location buffers for
+ * now). For example, objects needing the mappable aperture (the first
+ * 256M of GTT), should go first vs objects that can be placed just
+ * about anywhere. Repeat the previous pass.
*
- * Defragmenting is skipped if all objects are pinned at a fixed location.
+ * 2. Consider buffers that are pinned at a fixed location. Also try to
+ * evict the entire VM this time, leaving only objects that we were
+ * unable to lock. Try again to bind the buffers. (still using the new
+ * buffer order).
+ *
+ * 3. We likely have object lock contention for one or more stubborn
+ * objects in the VM, for which we need to evict to make forward
+ * progress (perhaps we are fighting the shrinker?). When evicting the
+ * VM this time around, anything that we can't lock we now track using
+ * the busy_bo, using the full lock (after dropping the vm->mutex to
+ * prevent deadlocks), instead of trylock. We then continue to evict the
+ * VM, this time with the stubborn object locked, which we can now
+ * hopefully unbind (if still bound in the VM). Repeat until the VM is
+ * evicted. Finally we should be able bind everything.
*/
- for (pass = 0; pass <= 2; pass++) {
+ for (pass = 0; pass <= 3; pass++) {
int pin_flags = PIN_USER | PIN_VALIDATE;
if (pass == 0)
pin_flags |= PIN_NONBLOCK;
if (pass >= 1)
- unpinned = eb_unbind(eb, pass == 2);
+ unpinned = eb_unbind(eb, pass >= 2);
if (pass == 2) {
err = mutex_lock_interruptible(&eb->context->vm->mutex);
if (!err) {
- err = i915_gem_evict_vm(eb->context->vm, &eb->ww);
+ err = i915_gem_evict_vm(eb->context->vm, &eb->ww, NULL);
+ mutex_unlock(&eb->context->vm->mutex);
+ }
+ if (err)
+ return err;
+ }
+
+ if (pass == 3) {
+retry:
+ err = mutex_lock_interruptible(&eb->context->vm->mutex);
+ if (!err) {
+ struct drm_i915_gem_object *busy_bo = NULL;
+
+ err = i915_gem_evict_vm(eb->context->vm, &eb->ww, &busy_bo);
mutex_unlock(&eb->context->vm->mutex);
+ if (err && busy_bo) {
+ err = i915_gem_object_lock(busy_bo, &eb->ww);
+ i915_gem_object_put(busy_bo);
+ if (!err)
+ goto retry;
+ }
}
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d73ba0f5c4c5..4f69bff63068 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -369,7 +369,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
if (vma == ERR_PTR(-ENOSPC)) {
ret = mutex_lock_interruptible(&ggtt->vm.mutex);
if (!ret) {
- ret = i915_gem_evict_vm(&ggtt->vm, &ww);
+ ret = i915_gem_evict_vm(&ggtt->vm, &ww, NULL);
mutex_unlock(&ggtt->vm.mutex);
}
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
index 4cfe36b0366b..c02ebd6900ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -441,6 +441,11 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
* @vm: Address space to cleanse
* @ww: An optional struct i915_gem_ww_ctx. If not NULL, i915_gem_evict_vm
* will be able to evict vma's locked by the ww as well.
+ * @busy_bo: Optional pointer to struct drm_i915_gem_object. If not NULL, then
+ * in the event i915_gem_evict_vm() is unable to trylock an object for eviction,
+ * then @busy_bo will point to it. -EBUSY is also returned. The caller must drop
+ * the vm->mutex, before trying again to acquire the contended lock. The caller
+ * also owns a reference to the object.
*
* This function evicts all vmas from a vm.
*
@@ -450,7 +455,8 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
* To clarify: This is for freeing up virtual address space, not for freeing
* memory in e.g. the shrinker.
*/
-int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx *ww)
+int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx *ww,
+ struct drm_i915_gem_object **busy_bo)
{
int ret = 0;
@@ -482,15 +488,22 @@ int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx *ww)
* the resv is shared among multiple objects, we still
* need the object ref.
*/
- if (dying_vma(vma) ||
+ if (!i915_gem_object_get_rcu(vma->obj) ||
(ww && (dma_resv_locking_ctx(vma->obj->base.resv) == &ww->ctx))) {
__i915_vma_pin(vma);
list_add(&vma->evict_link, &locked_eviction_list);
continue;
}
- if (!i915_gem_object_trylock(vma->obj, ww))
+ if (!i915_gem_object_trylock(vma->obj, ww)) {
+ if (busy_bo) {
+ *busy_bo = vma->obj; /* holds ref */
+ ret = -EBUSY;
+ break;
+ }
+ i915_gem_object_put(vma->obj);
continue;
+ }
__i915_vma_pin(vma);
list_add(&vma->evict_link, &eviction_list);
@@ -498,25 +511,29 @@ int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx *ww)
if (list_empty(&eviction_list) && list_empty(&locked_eviction_list))
break;
- ret = 0;
/* Unbind locked objects first, before unlocking the eviction_list */
list_for_each_entry_safe(vma, vn, &locked_eviction_list, evict_link) {
__i915_vma_unpin(vma);
- if (ret == 0)
+ if (ret == 0) {
ret = __i915_vma_unbind(vma);
- if (ret != -EINTR) /* "Get me out of here!" */
- ret = 0;
+ if (ret != -EINTR) /* "Get me out of here!" */
+ ret = 0;
+ }
+ if (!dying_vma(vma))
+ i915_gem_object_put(vma->obj);
}
list_for_each_entry_safe(vma, vn, &eviction_list, evict_link) {
__i915_vma_unpin(vma);
- if (ret == 0)
+ if (ret == 0) {
ret = __i915_vma_unbind(vma);
- if (ret != -EINTR) /* "Get me out of here!" */
- ret = 0;
+ if (ret != -EINTR) /* "Get me out of here!" */
+ ret = 0;
+ }
i915_gem_object_unlock(vma->obj);
+ i915_gem_object_put(vma->obj);
}
} while (ret == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.h b/drivers/gpu/drm/i915/i915_gem_evict.h
index e593c530f9bd..bf0ee0e4fe60 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.h
+++ b/drivers/gpu/drm/i915/i915_gem_evict.h
@@ -11,6 +11,7 @@
struct drm_mm_node;
struct i915_address_space;
struct i915_gem_ww_ctx;
+struct drm_i915_gem_object;
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
struct i915_gem_ww_ctx *ww,
@@ -23,6 +24,7 @@ int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
struct drm_mm_node *node,
unsigned int flags);
int i915_gem_evict_vm(struct i915_address_space *vm,
- struct i915_gem_ww_ctx *ww);
+ struct i915_gem_ww_ctx *ww,
+ struct drm_i915_gem_object **busy_bo);
#endif /* __I915_GEM_EVICT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 34f0e6c923c2..7d044888ac33 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1599,7 +1599,7 @@ static int __i915_ggtt_pin(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
* locked objects when called from execbuf when pinning
* is removed. This would probably regress badly.
*/
- i915_gem_evict_vm(vm, NULL);
+ i915_gem_evict_vm(vm, NULL, NULL);
mutex_unlock(&vm->mutex);
}
} while (1);
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 8c6517d29b8e..37068542aafe 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -344,7 +344,7 @@ static int igt_evict_vm(void *arg)
/* Everything is pinned, nothing should happen */
mutex_lock(&ggtt->vm.mutex);
- err = i915_gem_evict_vm(&ggtt->vm, NULL);
+ err = i915_gem_evict_vm(&ggtt->vm, NULL, NULL);
mutex_unlock(&ggtt->vm.mutex);
if (err) {
pr_err("i915_gem_evict_vm on a full GGTT returned err=%d]\n",
@@ -356,7 +356,7 @@ static int igt_evict_vm(void *arg)
for_i915_gem_ww(&ww, err, false) {
mutex_lock(&ggtt->vm.mutex);
- err = i915_gem_evict_vm(&ggtt->vm, &ww);
+ err = i915_gem_evict_vm(&ggtt->vm, &ww, NULL);
mutex_unlock(&ggtt->vm.mutex);
}
--
2.38.1
This is the start of the stable review cycle for the 5.15.84 release.
There are 14 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.84-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.84-rc1
Lei Rao <lei.rao(a)intel.com>
nvme-pci: clear the prp2 field when not used
Peter Zijlstra <peterz(a)infradead.org>
perf: Fix perf_pending_task() UaF
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: cs42l51: Correct PGA Volume minimum value
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
net: fec: don't reset irq coalesce settings to defaults on "ip link up"
Yasushi SHOJI <yasushi.shoji(a)gmail.com>
can: mcba_usb: Fix termination command argument
Heiko Schocher <hs(a)denx.de>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <ribalda(a)chromium.org>
pinctrl: meditatek: Startup with the IRQs disabled
Hou Tao <houtao1(a)huawei.com>
libbpf: Use page size as max_entries when probing ring buffer map
Mark Brown <broonie(a)kernel.org>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear CHnF flags
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear software reset bit
Jialiang Wang <wangjialiang0806(a)163.com>
nfp: fix use-after-free in area_cache_get()
Amir Goldstein <amir73il(a)gmail.com>
vfs: fix copy_file_range() averts filesystem freeze protection
Nathan Chancellor <nathan(a)kernel.org>
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
-------------
Diffstat:
Makefile | 4 ++--
arch/x86/entry/vdso/vdso.lds.S | 2 ++
drivers/net/can/usb/mcba_usb.c | 10 +++++++---
drivers/net/ethernet/freescale/fec_main.c | 22 ++++++----------------
.../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++-
drivers/nvme/host/pci.c | 2 ++
drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++++---
fs/ksmbd/vfs.c | 6 +++---
fs/nfsd/vfs.c | 4 ++--
fs/read_write.c | 17 +++++++++++++----
include/linux/can/platform/sja1000.h | 2 +-
include/linux/fs.h | 8 ++++++++
kernel/events/core.c | 17 +++++++++++++----
sound/soc/codecs/cs42l51.c | 2 +-
sound/soc/fsl/fsl_micfil.c | 19 +++++++++++++++++++
sound/soc/soc-ops.c | 6 ++++++
tools/lib/bpf/libbpf_probes.c | 2 +-
17 files changed, 94 insertions(+), 41 deletions(-)
This bug is marked as fixed by commit:
net: core: netlink: add helper refcount dec and lock function
net: sched: add helper function to take reference to Qdisc
net: sched: extend Qdisc with rcu
net: sched: rename qdisc_destroy() to qdisc_put()
net: sched: use Qdisc rcu API instead of relying on rtnl lock
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and new crashes with the same signature are ignored.
Dashboard link: https://syzkaller.appspot.com/bug?extid=5f229e48cccc804062c0
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Commit ac4e97abce9b8 ("scatterlist: sg_set_buf() argument must be in linear
mapping") checks that both the signature and the digest reside in the
linear mapping area.
However, more recently commit ba14a194a434c ("fork: Add generic vmalloced
stack support"), made it possible to move the stack in the vmalloc area,
which is not contiguous, and thus not suitable for sg_set_buf() which needs
adjacent pages.
Always make a copy of the signature and digest in the same buffer used to
store the key and its parameters, and pass them to sg_set_buf(). Prefer it
to conditionally doing the copy if necessary, to keep the code simple. The
buffer allocated with kmalloc() is in the linear mapping area.
Cc: stable(a)vger.kernel.org # 4.9.x
Fixes: ba14a194a434 ("fork: Add generic vmalloced stack support")
Link: https://lore.kernel.org/linux-integrity/Y4pIpxbjBdajymBJ@sol.localdomain/
Suggested-by: Eric Biggers <ebiggers(a)kernel.org>
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
---
crypto/asymmetric_keys/public_key.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index 2f8352e88860..ccc091119972 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -363,6 +363,7 @@ int public_key_verify_signature(const struct public_key *pkey,
struct scatterlist src_sg[2];
char alg_name[CRYPTO_MAX_ALG_NAME];
char *key, *ptr;
+ u32 key_max_len;
int ret;
pr_devel("==>%s()\n", __func__);
@@ -400,8 +401,12 @@ int public_key_verify_signature(const struct public_key *pkey,
if (!req)
goto error_free_tfm;
- key = kmalloc(pkey->keylen + sizeof(u32) * 2 + pkey->paramlen,
- GFP_KERNEL);
+ key_max_len = max_t(u32,
+ pkey->keylen + sizeof(u32) * 2 + pkey->paramlen,
+ sig->s_size + sig->digest_size);
+
+ /* key is used to store the sig and digest too. */
+ key = kmalloc(key_max_len, GFP_KERNEL);
if (!key)
goto error_free_req;
@@ -424,9 +429,13 @@ int public_key_verify_signature(const struct public_key *pkey,
goto error_free_key;
}
+ memcpy(key, sig->s, sig->s_size);
+ memcpy(key + sig->s_size, sig->digest, sig->digest_size);
+
sg_init_table(src_sg, 2);
- sg_set_buf(&src_sg[0], sig->s, sig->s_size);
- sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);
+ /* Cannot use one scatterlist. The first needs to be s->s_size long. */
+ sg_set_buf(&src_sg[0], key, sig->s_size);
+ sg_set_buf(&src_sg[1], key + sig->s_size, sig->digest_size);
akcipher_request_set_crypt(req, src_sg, NULL, sig->s_size,
sig->digest_size);
crypto_init_wait(&cwait);
--
2.25.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 6b838d3ae7c2..e1cbfbb60303 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -155,7 +155,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -170,8 +170,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -181,9 +181,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -194,6 +193,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -214,6 +218,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 6b838d3ae7c2..e1cbfbb60303 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -155,7 +155,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -170,8 +170,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -181,9 +181,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -194,6 +193,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -214,6 +218,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
This is the start of the stable review cycle for the 5.4.228 release.
There are 9 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.228-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.228-rc1
Yasushi SHOJI <yasushi.shoji(a)gmail.com>
can: mcba_usb: Fix termination command argument
Heiko Schocher <hs(a)denx.de>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <ribalda(a)chromium.org>
pinctrl: meditatek: Startup with the IRQs disabled
Mark Brown <broonie(a)kernel.org>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Jialiang Wang <wangjialiang0806(a)163.com>
nfp: fix use-after-free in area_cache_get()
Ming Lei <ming.lei(a)redhat.com>
block: unhash blkdev part inode when the part is deleted
Baolin Wang <baolin.wang(a)linux.alibaba.com>
mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page
Paul E. McKenney <paulmck(a)kernel.org>
x86/smpboot: Move rcu_cpu_starting() earlier
Lorenzo Colitti <lorenzo(a)google.com>
net: bpf: Allow TC programs to call BPF_FUNC_skb_change_head
-------------
Diffstat:
Makefile | 4 +--
arch/x86/kernel/cpu/mtrr/mtrr.c | 2 --
arch/x86/kernel/smpboot.c | 1 +
block/partition-generic.c | 7 +++++
drivers/net/can/usb/mcba_usb.c | 10 +++++---
.../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++-
drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++---
include/linux/can/platform/sja1000.h | 2 +-
include/linux/hugetlb.h | 6 ++---
mm/gup.c | 13 +++++++++-
mm/hugetlb.c | 30 +++++++++++-----------
net/core/filter.c | 2 ++
sound/soc/soc-ops.c | 6 +++++
13 files changed, 64 insertions(+), 31 deletions(-)
This is the start of the stable review cycle for the 5.10.160 release.
There are 15 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.160-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.160-rc1
Lei Rao <lei.rao(a)intel.com>
nvme-pci: clear the prp2 field when not used
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: cs42l51: Correct PGA Volume minimum value
Yasushi SHOJI <yasushi.shoji(a)gmail.com>
can: mcba_usb: Fix termination command argument
Heiko Schocher <hs(a)denx.de>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <ribalda(a)chromium.org>
pinctrl: meditatek: Startup with the IRQs disabled
Hou Tao <houtao1(a)huawei.com>
libbpf: Use page size as max_entries when probing ring buffer map
Mark Brown <broonie(a)kernel.org>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear CHnF flags
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear software reset bit
Bing-Jhong Billy Jheng <billy(a)starlabs.sg>
io_uring: add missing item types for splice request
Miklos Szeredi <mszeredi(a)redhat.com>
fuse: always revalidate if exclusive create
Jialiang Wang <wangjialiang0806(a)163.com>
nfp: fix use-after-free in area_cache_get()
Amir Goldstein <amir73il(a)gmail.com>
vfs: fix copy_file_range() averts filesystem freeze protection
Amir Goldstein <amir73il(a)gmail.com>
vfs: fix copy_file_range() regression in cross-fs copies
Paul E. McKenney <paulmck(a)kernel.org>
x86/smpboot: Move rcu_cpu_starting() earlier
-------------
Diffstat:
Makefile | 4 +-
arch/x86/kernel/cpu/mtrr/mtrr.c | 2 -
arch/x86/kernel/smpboot.c | 1 +
drivers/net/can/usb/mcba_usb.c | 10 ++-
.../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 +-
drivers/nvme/host/pci.c | 2 +
drivers/pinctrl/mediatek/mtk-eint.c | 9 ++-
fs/fuse/dir.c | 2 +-
fs/io_uring.c | 2 +-
fs/nfsd/vfs.c | 8 +-
fs/read_write.c | 90 +++++++++++++---------
include/linux/can/platform/sja1000.h | 2 +-
include/linux/fs.h | 8 ++
sound/soc/codecs/cs42l51.c | 2 +-
sound/soc/fsl/fsl_micfil.c | 19 +++++
sound/soc/soc-ops.c | 6 ++
tools/lib/bpf/libbpf_probes.c | 2 +-
17 files changed, 120 insertions(+), 52 deletions(-)
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index d3cb27487c70..3bcf98d01733 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -155,7 +155,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -170,8 +170,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -181,9 +181,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -194,6 +193,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -214,6 +218,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index a07fbb60ac3c..a46fa0f3db57 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -168,7 +168,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -183,8 +183,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -194,9 +194,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -207,6 +206,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -227,6 +231,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index a07fbb60ac3c..a46fa0f3db57 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -168,7 +168,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -183,8 +183,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -194,9 +194,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -207,6 +206,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -227,6 +231,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 1014f2a24697..4f72f7dee78b 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -168,7 +168,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -183,8 +183,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -194,9 +194,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -207,6 +206,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -227,6 +231,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 0ce17ea8fa8a..b0a65aaed43e 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -155,7 +155,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -170,8 +170,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -181,9 +181,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -194,6 +193,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -214,6 +218,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
From: Dongliang Mu <mudongliangabcd(a)gmail.com>
[ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.
Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
Reported-by: syzbot+15342c1aa6a00fb7a438(a)syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/jfs/jfs_dmap.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index e75f31b81d63..44600cd7614a 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -155,7 +155,7 @@ int dbMount(struct inode *ipbmap)
struct bmap *bmp;
struct dbmap_disk *dbmp_le;
struct metapage *mp;
- int i;
+ int i, err;
/*
* allocate/initialize the in-memory bmap descriptor
@@ -170,8 +170,8 @@ int dbMount(struct inode *ipbmap)
BMAPBLKNO << JFS_SBI(ipbmap->i_sb)->l2nbperpage,
PSIZE, 0);
if (mp == NULL) {
- kfree(bmp);
- return -EIO;
+ err = -EIO;
+ goto err_kfree_bmp;
}
/* copy the on-disk bmap descriptor to its in-memory version. */
@@ -181,9 +181,8 @@ int dbMount(struct inode *ipbmap)
bmp->db_l2nbperpage = le32_to_cpu(dbmp_le->dn_l2nbperpage);
bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
if (!bmp->db_numag) {
- release_metapage(mp);
- kfree(bmp);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_release_metapage;
}
bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
@@ -194,6 +193,11 @@ int dbMount(struct inode *ipbmap)
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
+ if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
+
for (i = 0; i < MAXAG; i++)
bmp->db_agfree[i] = le64_to_cpu(dbmp_le->dn_agfree[i]);
bmp->db_agsize = le64_to_cpu(dbmp_le->dn_agsize);
@@ -214,6 +218,12 @@ int dbMount(struct inode *ipbmap)
BMAP_LOCK_INIT(bmp);
return (0);
+
+err_release_metapage:
+ release_metapage(mp);
+err_kfree_bmp:
+ kfree(bmp);
+ return err;
}
--
2.35.1
This is the start of the stable review cycle for the 6.0.14 release.
There are 16 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 17 Dec 2022 17:28:57 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.14-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.0.14-rc1
Lei Rao <lei.rao(a)intel.com>
nvme-pci: clear the prp2 field when not used
Peter Zijlstra <peterz(a)infradead.org>
perf: Fix perf_pending_task() UaF
Charles Keepax <ckeepax(a)opensource.cirrus.com>
ASoC: cs42l51: Correct PGA Volume minimum value
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
net: fec: don't reset irq coalesce settings to defaults on "ip link up"
Yasushi SHOJI <yasushi.shoji(a)gmail.com>
can: mcba_usb: Fix termination command argument
Heiko Schocher <hs(a)denx.de>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <ribalda(a)chromium.org>
pinctrl: meditatek: Startup with the IRQs disabled
Hou Tao <houtao1(a)huawei.com>
libbpf: Use page size as max_entries when probing ring buffer map
Mark Brown <broonie(a)kernel.org>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear CHnF flags
Shengjiu Wang <shengjiu.wang(a)nxp.com>
ASoC: fsl_micfil: explicitly clear software reset bit
Alexandre Belloni <alexandre.belloni(a)bootlin.com>
rtc: cmos: fix build on non-ACPI platforms
David Michael <fedora.dm0(a)gmail.com>
libbpf: Fix uninitialized warning in btf_dump_dump_type_data
Nathan Chancellor <nathan(a)kernel.org>
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
rtc: cmos: Fix wake alarm breakage
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
rtc: cmos: Fix event handler registration ordering issue
-------------
Diffstat:
Makefile | 4 ++--
arch/x86/entry/vdso/vdso.lds.S | 2 ++
drivers/net/can/usb/mcba_usb.c | 10 ++++++---
drivers/net/ethernet/freescale/fec_main.c | 22 ++++++-------------
drivers/nvme/host/pci.c | 2 ++
drivers/pinctrl/mediatek/mtk-eint.c | 9 +++++---
drivers/rtc/rtc-cmos.c | 35 +++++++++++++++++++++++--------
include/linux/can/platform/sja1000.h | 2 +-
kernel/events/core.c | 17 +++++++++++----
sound/soc/codecs/cs42l51.c | 2 +-
sound/soc/fsl/fsl_micfil.c | 19 +++++++++++++++++
sound/soc/soc-ops.c | 6 ++++++
tools/lib/bpf/btf_dump.c | 2 +-
tools/lib/bpf/libbpf_probes.c | 2 +-
14 files changed, 93 insertions(+), 41 deletions(-)
From: Eric Biggers <ebiggers(a)google.com>
An issue that arises when migrating from builtin signatures to userspace
signatures is that existing files that have builtin signatures cannot be
opened unless either CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled or
the signing certificate is left in the .fs-verity keyring.
Since builtin signatures provide no security benefit when
fs.verity.require_signatures=0 anyway, let's just skip the signature
verification in this case.
Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures")
Cc: <stable(a)vger.kernel.org> # v5.4+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
fs/verity/signature.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/fs/verity/signature.c b/fs/verity/signature.c
index 143a530a80088..dc6935701abda 100644
--- a/fs/verity/signature.c
+++ b/fs/verity/signature.c
@@ -13,8 +13,8 @@
#include <linux/verification.h>
/*
- * /proc/sys/fs/verity/require_signatures
- * If 1, all verity files must have a valid builtin signature.
+ * /proc/sys/fs/verity/require_signatures. If 1, then builtin signatures are
+ * verified and all verity files must have a valid builtin signature.
*/
static int fsverity_require_signatures;
@@ -54,6 +54,20 @@ int fsverity_verify_signature(const struct fsverity_info *vi,
return 0;
}
+ /*
+ * If require_signatures=0, don't verify builtin signatures.
+ * Originally, builtin signatures were verified opportunistically in
+ * this case. However, no security property is possible when
+ * require_signatures=0 anyway. Skipping the builtin signature
+ * verification makes it easier to migrate existing files from builtin
+ * signature verification to userspace signature verification.
+ */
+ if (!fsverity_require_signatures) {
+ fsverity_warn(inode,
+ "Not checking builtin signature due to require_signatures=0");
+ return 0;
+ }
+
d = kzalloc(sizeof(*d) + hash_alg->digest_size, GFP_KERNEL);
if (!d)
return -ENOMEM;
base-commit: 479174d402bcf60789106eedc4def3957c060bad
--
2.38.1
When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may
have it and has pte marker installed. The warning is improper along with
the comment. The right thing is to inherit the pte marker when needed, or
keep the dst pte empty.
A vague guess is this happened by an accident when there's the prior patch
to introduce src/dst vma into this helper during the uffd-wp feature got
developed and I probably messed up in the rebase, since if we replace
dst_vma with src_vma the warning & comment it all makes sense too.
Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the
general path.
Reproducer:
https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_pag…
Cc: <stable(a)vger.kernel.org> # 5.19+
Fixes: c56d1b62cce8 ("mm/shmem: handle uffd-wp during fork()")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216808
Reported-by: Pengfei Xu <pengfei.xu(a)intel.com>
Signed-off-by: Peter Xu <peterx(a)redhat.com>
---
mm/memory.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index aad226daf41b..032ef700c3e8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -828,12 +828,8 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
return -EBUSY;
return -ENOENT;
} else if (is_pte_marker_entry(entry)) {
- /*
- * We're copying the pgtable should only because dst_vma has
- * uffd-wp enabled, do sanity check.
- */
- WARN_ON_ONCE(!userfaultfd_wp(dst_vma));
- set_pte_at(dst_mm, addr, dst_pte, pte);
+ if (userfaultfd_wp(dst_vma))
+ set_pte_at(dst_mm, addr, dst_pte, pte);
return 0;
}
if (!userfaultfd_wp(dst_vma))
--
2.37.3
When encountering any vma in the range with policy other than MPOL_BIND
or MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put
on the policy just allocated with mpol_dup().
This allows arbitrary users to leak kernel memory.
[ Mathieu: compile-tested only. Tested-by would be welcome. ]
Fixes: c6018b4b2549 ("mm/mempolicy: add set_mempolicy_home_node syscall")
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reviewed-by: Randy Dunlap <rdunlap(a)infradead.org>
Reviewed-by: "Huang, Ying" <ying.huang(a)intel.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Feng Tang <feng.tang(a)intel.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: linux-api(a)vger.kernel.org
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: linux-mm(a)kvack.org
Cc: stable(a)vger.kernel.org # 5.17+
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 61aa9aedb728..02c8a712282f 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1540,6 +1540,7 @@ SYSCALL_DEFINE4(set_mempolicy_home_node, unsigned long, start, unsigned long, le
* the home node for vmas we already updated before.
*/
if (new->mode != MPOL_BIND && new->mode != MPOL_PREFERRED_MANY) {
+ mpol_put(new);
err = -EOPNOTSUPP;
break;
}
--
2.25.1
The patch titled
Subject: mm, mremap: fix mremap() expanding vma with addr inside vma
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.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: Vlastimil Babka <vbabka(a)suse.cz>
Subject: mm, mremap: fix mremap() expanding vma with addr inside vma
Date: Fri, 16 Dec 2022 17:32:27 +0100
Since 6.1 we have noticed random rpm install failures that were tracked to
mremap() returning -ENOMEM and to commit ca3d76b0aa80 ("mm: add merging
after mremap resize").
The problem occurs when mremap() expands a VMA in place, but using an
starting address that's not vma->vm_start, but somewhere in the middle.
The extension_pgoff calculation introduced by the commit is wrong in that
case, so vma_merge() fails due to pgoffs not being compatible. Fix the
calculation.
By the way it seems that the situations, where rpm now expands a vma from
the middle, were made possible also due to that commit, thanks to the
improved vma merging. Yet it should work just fine, except for the buggy
calculation.
Link: https://lkml.kernel.org/r/20221216163227.24648-1-vbabka@suse.cz
Reported-by: Jiri Slaby <jirislaby(a)kernel.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359
Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Jakub Mat��na <matenajakub(a)gmail.com>
Cc: "Kirill A . Shutemov" <kirill(a)shutemov.name>
Cc: Liam Howlett <liam.howlett(a)oracle.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/mremap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/mremap.c~mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma
+++ a/mm/mremap.c
@@ -1016,7 +1016,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
long pages = (new_len - old_len) >> PAGE_SHIFT;
unsigned long extension_start = addr + old_len;
unsigned long extension_end = addr + new_len;
- pgoff_t extension_pgoff = vma->vm_pgoff + (old_len >> PAGE_SHIFT);
+ pgoff_t extension_pgoff = vma->vm_pgoff +
+ ((extension_start - vma->vm_start) >> PAGE_SHIFT);
if (vma->vm_flags & VM_ACCOUNT) {
if (security_vm_enough_memory_mm(mm, pages)) {
_
Patches currently in -mm which might be from vbabka(a)suse.cz are
mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch
If the sink gets disconnected during receiving a multi-packet DP MST AUX
down-reply/up-request sideband message, the state keeping track of which
packets have been received already is not reset. This results in a failed
sanity check for the subsequent message packet received after a sink is
reconnected (due to the pending message not yet completed with an
end-of-message-transfer packet), indicated by the
"sideband msg set header failed"
error.
Fix the above by resetting the up/down message reception state after a
disconnect event.
Cc: Lyude Paul <lyude(a)redhat.com>
Cc: <stable(a)vger.kernel.org> # v3.17+
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 51a46689cda70..90819fff2c9ba 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3641,6 +3641,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
mgr->payload_id_table_cleared = false;
+
+ memset(&mgr->down_rep_recv, 0, sizeof(mgr->down_rep_recv));
+ memset(&mgr->up_req_recv, 0, sizeof(mgr->up_req_recv));
}
out_unlock:
--
2.37.1
Since 6.1 we have noticed random rpm install failures that were tracked
to mremap() returning -ENOMEM and to commit ca3d76b0aa80 ("mm: add
merging after mremap resize").
The problem occurs when mremap() expands a VMA in place, but using an
starting address that's not vma->vm_start, but somewhere in the middle.
The extension_pgoff calculation introduced by the commit is wrong in
that case, so vma_merge() fails due to pgoffs not being compatible.
Fix the calculation.
By the way it seems that the situations, where rpm now expands a vma
from the middle, were made possible also due to that commit, thanks to
the improved vma merging. Yet it should work just fine, except for the
buggy calculation.
Reported-by: Jiri Slaby <jirislaby(a)kernel.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359
Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Jakub Matěna <matenajakub(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Cc: "Kirill A . Shutemov" <kirill(a)shutemov.name>
Cc: Liam Howlett <liam.howlett(a)oracle.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)kernel.org>
---
Hi, this fixes a regression in 6.1 so please process ASAP so that stable
6.1.y can get the fix.
mm/mremap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index e465ffe279bb..fe587c5d6591 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -1016,7 +1016,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
long pages = (new_len - old_len) >> PAGE_SHIFT;
unsigned long extension_start = addr + old_len;
unsigned long extension_end = addr + new_len;
- pgoff_t extension_pgoff = vma->vm_pgoff + (old_len >> PAGE_SHIFT);
+ pgoff_t extension_pgoff = vma->vm_pgoff +
+ ((extension_start - vma->vm_start) >> PAGE_SHIFT);
if (vma->vm_flags & VM_ACCOUNT) {
if (security_vm_enough_memory_mm(mm, pages)) {
--
2.38.1
The assumption that Documentation was right about how this value work was
wrong. It was discovered that the length value of the mgmt header is in
step of word size.
As an example to process 4 byte of data the correct length to set is 2.
To process 8 byte 4, 12 byte 6, 16 byte 8...
Odd values will always return the next size on the ack packet.
(length of 3 (6 byte) will always return 8 bytes of data)
This means that a value of 15 (0xf) actually means reading/writing 32 bytes
of data instead of 16 bytes. This behaviour is totally absent and not
documented in the switch Documentation.
In fact from Documentation the max value that mgmt eth can process is
16 byte of data while in reality it can process 32 bytes at once.
To handle this we always round up the length after deviding it for word
size. We check if the result is odd and we round another time to align
to what the switch will provide in the ack packet.
The workaround for the length limit of 15 is still needed as the length
reg max value is 0xf(15)
Reported-by: Ronald Wahl <ronald.wahl(a)raritan.com>
Tested-by: Ronald Wahl <ronald.wahl(a)raritan.com>
Fixes: 90386223f44e ("net: dsa: qca8k: add support for larger read/write size with mgmt Ethernet")
Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com>
Cc: stable(a)vger.kernel.org # v5.18+
---
drivers/net/dsa/qca/qca8k-8xxx.c | 45 +++++++++++++++++++++++++-------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/qca/qca8k-8xxx.c b/drivers/net/dsa/qca/qca8k-8xxx.c
index c5c3b4e92f28..46151320b2a8 100644
--- a/drivers/net/dsa/qca/qca8k-8xxx.c
+++ b/drivers/net/dsa/qca/qca8k-8xxx.c
@@ -146,7 +146,16 @@ static void qca8k_rw_reg_ack_handler(struct dsa_switch *ds, struct sk_buff *skb)
command = get_unaligned_le32(&mgmt_ethhdr->command);
cmd = FIELD_GET(QCA_HDR_MGMT_CMD, command);
+
len = FIELD_GET(QCA_HDR_MGMT_LENGTH, command);
+ /* Special case for len of 15 as this is the max value for len and needs to
+ * be increased before converting it from word to dword.
+ */
+ if (len == 15)
+ len++;
+
+ /* We can ignore odd value, we always round up them in the alloc function. */
+ len *= sizeof(u16);
/* Make sure the seq match the requested packet */
if (get_unaligned_le32(&mgmt_ethhdr->seq) == mgmt_eth_data->seq)
@@ -193,17 +202,33 @@ static struct sk_buff *qca8k_alloc_mdio_header(enum mdio_cmd cmd, u32 reg, u32 *
if (!skb)
return NULL;
- /* Max value for len reg is 15 (0xf) but the switch actually return 16 byte
- * Actually for some reason the steps are:
- * 0: nothing
- * 1-4: first 4 byte
- * 5-6: first 12 byte
- * 7-15: all 16 byte
+ /* Hdr mgmt length value is in step of word size.
+ * As an example to process 4 byte of data the correct length to set is 2.
+ * To process 8 byte 4, 12 byte 6, 16 byte 8...
+ *
+ * Odd values will always return the next size on the ack packet.
+ * (length of 3 (6 byte) will always return 8 bytes of data)
+ *
+ * This means that a value of 15 (0xf) actually means reading/writing 32 bytes
+ * of data.
+ *
+ * To correctly calculate the length we devide the requested len by word and
+ * round up.
+ * On the ack function we can skip the odd check as we already handle the
+ * case here.
+ */
+ real_len = DIV_ROUND_UP(len, sizeof(u16));
+
+ /* We check if the result len is odd and we round up another time to
+ * the next size. (length of 3 will be increased to 4 as switch will always
+ * return 8 bytes)
*/
- if (len == 16)
- real_len = 15;
- else
- real_len = len;
+ if (real_len % sizeof(u16) != 0)
+ real_len++;
+
+ /* Max reg value is 0xf(15) but switch will always return the next size (32 byte) */
+ if (real_len == 16)
+ real_len--;
skb_reset_mac_header(skb);
skb_set_network_header(skb, skb->len);
--
2.37.2
Hi Handa-san,
On Thu, Nov 17, 2022 at 4:32 PM Tetsuo Handa
<penguin-kernel(a)i-love.sakura.ne.jp> wrote:
> A kernel built with syzbot's config file reported that
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
>
> causes uninitialized "save" to be copied.
> Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Thanks for your patch, which is now commit a6a00d7e8ffd78d1
("fbcon: Use kzalloc() in fbcon_prepare_logo()") in v6.1-rc7,
and which is being backported to stable.
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -577,7 +577,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct fb_info *info,
> if (scr_readw(r) != vc->vc_video_erase_char)
> break;
> if (r != q && new_rows >= rows + logo_lines) {
> - save = kmalloc(array3_size(logo_lines, new_cols, 2),
> + save = kzalloc(array3_size(logo_lines, new_cols, 2),
> GFP_KERNEL);
> if (save) {
> int i = min(cols, new_cols);
The next line is:
scr_memsetw(save, erase,
array3_size(logo_lines, new_cols, 2));
So how can this turn out to be uninitialized later below?
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
What am I missing?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro(a)redhat.com>
---
Version history:
v3: Updated commit message to explain the problem in more details.
v2: Fixed ENOMEN error :( Forgot to do a stg refresh.
net/openvswitch/datapath.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 861dfb8daf4a..55b697c4d576 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -948,6 +948,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
struct sw_flow_mask mask;
struct sk_buff *reply;
struct datapath *dp;
+ struct sw_flow_key *key;
struct sw_flow_actions *acts;
struct sw_flow_match match;
u32 ufid_flags = ovs_nla_get_ufid_flags(a[OVS_FLOW_ATTR_UFID_FLAGS]);
@@ -975,24 +976,26 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
}
/* Extract key. */
- ovs_match_init(&match, &new_flow->key, false, &mask);
+ key = kzalloc(sizeof(*key), GFP_KERNEL);
+ if (!key) {
+ error = -ENOMEM;
+ goto err_kfree_key;
+ }
+
+ ovs_match_init(&match, key, false, &mask);
error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
a[OVS_FLOW_ATTR_MASK], log);
if (error)
goto err_kfree_flow;
+ ovs_flow_mask_key(&new_flow->key, key, true, &mask);
+
/* Extract flow identifier. */
error = ovs_nla_get_identifier(&new_flow->id, a[OVS_FLOW_ATTR_UFID],
- &new_flow->key, log);
+ key, log);
if (error)
goto err_kfree_flow;
- /* unmasked key is needed to match when ufid is not used. */
- if (ovs_identifier_is_key(&new_flow->id))
- match.key = new_flow->id.unmasked_key;
-
- ovs_flow_mask_key(&new_flow->key, &new_flow->key, true, &mask);
-
/* Validate actions. */
error = ovs_nla_copy_actions(net, a[OVS_FLOW_ATTR_ACTIONS],
&new_flow->key, &acts, log);
@@ -1019,7 +1022,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
if (ovs_identifier_is_ufid(&new_flow->id))
flow = ovs_flow_tbl_lookup_ufid(&dp->table, &new_flow->id);
if (!flow)
- flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->key);
+ flow = ovs_flow_tbl_lookup(&dp->table, key);
if (likely(!flow)) {
rcu_assign_pointer(new_flow->sf_acts, acts);
@@ -1089,6 +1092,8 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
if (reply)
ovs_notify(&dp_flow_genl_family, reply, info);
+
+ kfree(key);
return 0;
err_unlock_ovs:
@@ -1098,6 +1103,8 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
ovs_nla_free_flow_actions(acts);
err_kfree_flow:
ovs_flow_free(new_flow, false);
+err_kfree_key:
+ kfree(key);
error:
return error;
}