The patch titled
Subject: mm: hugetlb: soft-offline: fix wrong return value of soft offline
has been added to the -mm tree. Its filename is
mm-hugetlb-soft-offline-fix-wrong-return-value-of-soft-offline.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-soft-offline-fix-wrong-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-soft-offline-fix-wrong-…
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 and is updated
there every 3-4 working days
------------------------------------------------------
From: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Subject: mm: hugetlb: soft-offline: fix wrong return value of soft offline
Soft offline events for hugetlb pages return -EBUSY when page migration
succeeded and dissolve_free_huge_page() failed, which can happen when
there're surplus hugepages. We should judge pass/fail of soft offline by
checking whether the raw error page was finally contained or not (i.e.
the result of set_hwpoison_free_buddy_page()), so this behavior is wrong.
This problem was introduced by the following change of commit 6bc9b56433b76
("mm: fix race on soft-offlining"):
if (ret > 0)
ret = -EIO;
} else {
- if (PageHuge(page))
- dissolve_free_huge_page(page);
+ /*
+ * We set PG_hwpoison only when the migration source hugepage
+ * was successfully dissolved, because otherwise hwpoisoned
+ * hugepage remains on free hugepage list, then userspace will
+ * find it as SIGBUS by allocation failure. That's not expected
+ * in soft-offlining.
+ */
+ ret = dissolve_free_huge_page(page);
+ if (!ret) {
+ if (set_hwpoison_free_buddy_page(page))
+ num_poisoned_pages_inc();
+ }
}
return ret;
}
so a simple fix is to restore the PageHuge precheck, but my code reading
shows that we already have PageHuge check in dissolve_free_huge_page()
with hugetlb_lock, which is better place to check it. And currently
dissolve_free_huge_page() returns -EBUSY for !PageHuge but that's simply
wrong because that that case should be considered as success (meaning that
"the given hugetlb was already dissolved.")
This change affects other callers of dissolve_free_huge_page(), which are
also cleaned up by this patch.
Link: http://lkml.kernel.org/r/1558937200-18544-1-git-send-email-n-horiguchi@ah.j…
Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
Signed-off-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Reported-by: Chen, Jerry T <jerry.t.chen(a)intel.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: "Zhuo, Qiuxu" <qiuxu.zhuo(a)intel.com>
Cc: <stable(a)vger.kernel.org> [4.19+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 15 +++++++++------
mm/memory-failure.c | 7 +++----
2 files changed, 12 insertions(+), 10 deletions(-)
--- a/mm/hugetlb.c~mm-hugetlb-soft-offline-fix-wrong-return-value-of-soft-offline
+++ a/mm/hugetlb.c
@@ -1519,7 +1519,12 @@ int dissolve_free_huge_page(struct page
int rc = -EBUSY;
spin_lock(&hugetlb_lock);
- if (PageHuge(page) && !page_count(page)) {
+ if (!PageHuge(page)) {
+ rc = 0;
+ goto out;
+ }
+
+ if (!page_count(page)) {
struct page *head = compound_head(page);
struct hstate *h = page_hstate(head);
int nid = page_to_nid(head);
@@ -1564,11 +1569,9 @@ int dissolve_free_huge_pages(unsigned lo
for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
page = pfn_to_page(pfn);
- if (PageHuge(page) && !page_count(page)) {
- rc = dissolve_free_huge_page(page);
- if (rc)
- break;
- }
+ rc = dissolve_free_huge_page(page);
+ if (rc)
+ break;
}
return rc;
--- a/mm/memory-failure.c~mm-hugetlb-soft-offline-fix-wrong-return-value-of-soft-offline
+++ a/mm/memory-failure.c
@@ -1733,6 +1733,8 @@ static int soft_offline_huge_page(struct
if (!ret) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
+ else
+ ret = -EBUSY;
}
}
return ret;
@@ -1857,11 +1859,8 @@ static int soft_offline_in_use_page(stru
static int soft_offline_free_page(struct page *page)
{
- int rc = 0;
- struct page *head = compound_head(page);
+ int rc = dissolve_free_huge_page(page);
- if (PageHuge(head))
- rc = dissolve_free_huge_page(page);
if (!rc) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
_
Patches currently in -mm which might be from n-horiguchi(a)ah.jp.nec.com are
mm-hugetlb-soft-offline-fix-wrong-return-value-of-soft-offline.patch
We met another Acer Aspire laptop which has the problem on the
headset-mic, the Pin 0x19 is not set the corret configuration for a
mic and the pin presence can't be detected too after plugging a
headset. Kailang suggested that we should set the coeff to enable the
mic and apply the ALC269_FIXUP_LIFEBOOK_EXTMIC. After doing that,
both headset-mic presence and headset-mic work well.
The existing ALC255_FIXUP_ACER_MIC_NO_PRESENCE set the headset-mic
jack to be a phantom jack. Now since the jack can support presence
unsol event, let us imporve it to set the jack to be a normal jack.
https://bugs.launchpad.net/bugs/1821269
Fixes: 5824ce8de7b1c ("ALSA: hda/realtek - Add support for Acer Aspire E5-475 headset mic")
Cc: Chris Chiu <chiu(a)endlessm.com>
CC: Daniel Drake <drake(a)endlessm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Signed-off-by: Hui Wang <hui.wang(a)canonical.com>
---
sound/pci/hda/patch_realtek.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f1bac03e954b..f42a097f2e16 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6223,13 +6223,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chain_id = ALC269_FIXUP_THINKPAD_ACPI,
},
[ALC255_FIXUP_ACER_MIC_NO_PRESENCE] = {
- .type = HDA_FIXUP_PINS,
- .v.pins = (const struct hda_pintbl[]) {
- { 0x19, 0x01a1913c }, /* use as headset mic, without its own jack detect */
- { }
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Enable the Mic */
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
+ {}
},
.chained = true,
- .chain_id = ALC255_FIXUP_HEADSET_MODE
+ .chain_id = ALC269_FIXUP_LIFEBOOK_EXTMIC
},
[ALC255_FIXUP_ASUS_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
@@ -7273,6 +7275,10 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = {
{0x18, 0x02a11030},
{0x19, 0x0181303F},
{0x21, 0x0221102f}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1025, "Acer", ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
+ {0x12, 0x90a60140},
+ {0x14, 0x90170120},
+ {0x21, 0x02211030}),
SND_HDA_PIN_QUIRK(0x10ec0255, 0x1025, "Acer", ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
{0x12, 0x90a601c0},
{0x14, 0x90171120},
--
2.17.1
The patch titled
Subject: mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
has been added to the -mm tree. Its filename is
list_lru-fix-memory-leak-in-__memcg_init_list_lru_node.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/list_lru-fix-memory-leak-in-__memc…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/list_lru-fix-memory-leak-in-__memc…
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 and is updated
there every 3-4 working days
------------------------------------------------------
From: Shakeel Butt <shakeelb(a)google.com>
Subject: mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
Syzbot reported following memory leak:
ffffffffda RBX: 0000000000000003 RCX: 0000000000441f79
BUG: memory leak
unreferenced object 0xffff888114f26040 (size 32):
comm "syz-executor626", pid 7056, jiffies 4294948701 (age 39.410s)
hex dump (first 32 bytes):
40 60 f2 14 81 88 ff ff 40 60 f2 14 81 88 ff ff @`......@`......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000018f36b56>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<0000000018f36b56>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000018f36b56>] slab_alloc mm/slab.c:3326 [inline]
[<0000000018f36b56>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<0000000055b9a1a5>] kmalloc include/linux/slab.h:547 [inline]
[<0000000055b9a1a5>] __memcg_init_list_lru_node+0x58/0xf0 mm/list_lru.c:352
[<000000001356631d>] memcg_init_list_lru_node mm/list_lru.c:375 [inline]
[<000000001356631d>] memcg_init_list_lru mm/list_lru.c:459 [inline]
[<000000001356631d>] __list_lru_init+0x193/0x2a0 mm/list_lru.c:626
[<00000000ce062da3>] alloc_super+0x2e0/0x310 fs/super.c:269
[<000000009023adcf>] sget_userns+0x94/0x2a0 fs/super.c:609
[<0000000052182cd8>] sget+0x8d/0xb0 fs/super.c:660
[<0000000006c24238>] mount_nodev+0x31/0xb0 fs/super.c:1387
[<0000000006016a76>] fuse_mount+0x2d/0x40 fs/fuse/inode.c:1236
[<000000009a61ec1d>] legacy_get_tree+0x27/0x80 fs/fs_context.c:661
[<0000000096cd9ef8>] vfs_get_tree+0x2e/0x120 fs/super.c:1476
[<000000005b8f472d>] do_new_mount fs/namespace.c:2790 [inline]
[<000000005b8f472d>] do_mount+0x932/0xc50 fs/namespace.c:3110
[<00000000afb009b4>] ksys_mount+0xab/0x120 fs/namespace.c:3319
[<0000000018f8c8ee>] __do_sys_mount fs/namespace.c:3333 [inline]
[<0000000018f8c8ee>] __se_sys_mount fs/namespace.c:3330 [inline]
[<0000000018f8c8ee>] __x64_sys_mount+0x26/0x30 fs/namespace.c:3330
[<00000000f42066da>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<0000000043d74ca0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This is a simple off by one bug on the error path.
Link: http://lkml.kernel.org/r/20190528043202.99980-1-shakeelb@google.com
Fixes: 60d3fd32a7a9 ("list_lru: introduce per-memcg lists")
Reported-by: syzbot+f90a420dfe2b1b03cb2c(a)syzkaller.appspotmail.com
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Kirill Tkhai <ktkhai(a)virtuozzo.com>
Cc: <stable(a)vger.kernel.org> [4.0+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/list_lru.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/list_lru.c~list_lru-fix-memory-leak-in-__memcg_init_list_lru_node
+++ a/mm/list_lru.c
@@ -354,7 +354,7 @@ static int __memcg_init_list_lru_node(st
}
return 0;
fail:
- __memcg_destroy_list_lru_node(memcg_lrus, begin, i - 1);
+ __memcg_destroy_list_lru_node(memcg_lrus, begin, i);
return -ENOMEM;
}
_
Patches currently in -mm which might be from shakeelb(a)google.com are
list_lru-fix-memory-leak-in-__memcg_init_list_lru_node.patch
memcg-oom-no-oom-kill-for-__gfp_retry_mayfail.patch
memcg-fsnotify-no-oom-kill-for-remote-memcg-charging.patch
Le 24/05/2019 à 11:22, Pablo Neira Ayuso a écrit :
> On Mon, May 20, 2019 at 10:35:07AM +0200, Nicolas Dichtel wrote:
>> Le 06/05/2019 à 15:16, Pablo Neira Ayuso a écrit :
>>> On Mon, May 06, 2019 at 10:49:52AM +0200, Nicolas Dichtel wrote:
>> [snip]
>>>> Is it possible to queue this for stable?
>>>
>>> Sure, as soon as this hits Linus' tree.
>>>
>> FYI, it's now in Linus tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
>
> Please, send an email requesting this to stable(a)vger.kernel.org and
> keep me on CC.
This is a request to backport the upstream commit f8e608982022 ("netfilter:
ctnetlink: Resolve conntrack L3-protocol flush regression") in stable trees.
Thank you,
Nicolas
>
> I'll ACK it.
>
> Thanks.
>