CC: stable(a)vger.kernel.org
On Fri, 2018-12-21 at 18:17 +0800, Linus Walleij wrote:
> On Thu, Dec 13, 2018 at 3:28 AM Ryder Lee <ryder.lee(a)mediatek.com> wrote:
>
> > Remove prompts to make all pinctrl cores to non-visible symbols and
> > make sure the target SoCs would be coupled with the corresponding
> > cores.
> >
> > Signed-off-by: Ryder Lee <ryder.lee(a)mediatek.com>
>
> Patch applied with ACK and Tested-by.
>
> Yours,
> Linus Walleij
I forgot to add stable-kernel into CC list.
This patch should be applied to stable-rc linux-4.20.y.
Sorry for the inconvenience.
Ryder
The patch titled
Subject: huegtlbfs: fix page leak during migration of file pages
has been added to the -mm tree. Its filename is
huegtlbfs-fix-page-leak-during-migration-of-file-pages.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/huegtlbfs-fix-page-leak-during-mig…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/huegtlbfs-fix-page-leak-during-mig…
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: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: huegtlbfs: fix page leak during migration of file pages
Files can be created and mapped in an explicitly mounted hugetlbfs
filesystem. If pages in such files are migrated, the filesystem usage
will not be decremented for the associated pages. This can result in mmap
or page allocation failures as it appears there are fewer pages in the
filesystem than there should be.
For example, a test program which hole punches, faults and migrates pages
in such a file (1G in size) will eventually fail because it can not
allocate a page. Reported counts and usage at time of failure:
node0
537 free_hugepages
1024 nr_hugepages
0 surplus_hugepages
node1
1000 free_hugepages
1024 nr_hugepages
0 surplus_hugepages
Filesystem Size Used Avail Use% Mounted on
nodev 4.0G 4.0G 0 100% /var/opt/hugepool
Note that the filesystem shows 4G of pages used, while actual usage is 511
pages (just under 1G). Failed trying to allocate page 512.
If a hugetlb page is associated with an explicitly mounted filesystem,
this information in contained in the page_private field. At migration
time, this information is not preserved. To fix, simply transfer
page_private from old to new page at migration time if necessary. Also,
migrate_page_states() unconditionally clears page_private and PagePrivate
of the old page. It is unlikely, but possible that these fields could be
non-NULL and are needed at hugetlb free page time. So, do not touch these
fields for hugetlb pages.
Link: http://lkml.kernel.org/r/20190130211443.16678-1-mike.kravetz@oracle.com
Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/hugetlbfs/inode.c | 10 ++++++++++
mm/migrate.c | 10 ++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
--- a/fs/hugetlbfs/inode.c~huegtlbfs-fix-page-leak-during-migration-of-file-pages
+++ a/fs/hugetlbfs/inode.c
@@ -859,6 +859,16 @@ static int hugetlbfs_migrate_page(struct
rc = migrate_huge_page_move_mapping(mapping, newpage, page);
if (rc != MIGRATEPAGE_SUCCESS)
return rc;
+
+ /*
+ * page_private is subpool pointer in hugetlb pages, transfer
+ * if needed.
+ */
+ if (page_private(page) && !page_private(newpage)) {
+ set_page_private(newpage, page_private(page));
+ set_page_private(page, 0);
+ }
+
if (mode != MIGRATE_SYNC_NO_COPY)
migrate_page_copy(newpage, page);
else
--- a/mm/migrate.c~huegtlbfs-fix-page-leak-during-migration-of-file-pages
+++ a/mm/migrate.c
@@ -641,8 +641,14 @@ void migrate_page_states(struct page *ne
*/
if (PageSwapCache(page))
ClearPageSwapCache(page);
- ClearPagePrivate(page);
- set_page_private(page, 0);
+ /*
+ * Unlikely, but PagePrivate and page_private could potentially
+ * contain information needed at hugetlb free page time.
+ */
+ if (!PageHuge(page)) {
+ ClearPagePrivate(page);
+ set_page_private(page, 0);
+ }
/*
* If any waiters have accumulated on the new page then
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
huegtlbfs-fix-page-leak-during-migration-of-file-pages.patch
The nr_dentry_unused per-cpu counter tracks dentries in both the
LRU lists and the shrink lists where the DCACHE_LRU_LIST bit is set.
The shrink_dcache_sb() function moves dentries from the LRU list to a
shrink list and subtracts the dentry count from nr_dentry_unused. This
is incorrect as the nr_dentry_unused count Will also be decremented in
shrink_dentry_list() via d_shrink_del(). To fix this double decrement,
the decrement in the shrink_dcache_sb() function is taken out.
Fixes: 4e717f5c1083 ("list_lru: remove special case function list_lru_dispose_all."
Cc: stable(a)vger.kernel.org
Signed-off-by: Waiman Long <longman(a)redhat.com>
Reviewed-by: Dave Chinner <dchinner(a)redhat.com>
---
fs/dcache.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 2593153..44e5652 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1188,15 +1188,11 @@ static enum lru_status dentry_lru_isolate_shrink(struct list_head *item,
*/
void shrink_dcache_sb(struct super_block *sb)
{
- long freed;
-
do {
LIST_HEAD(dispose);
- freed = list_lru_walk(&sb->s_dentry_lru,
+ list_lru_walk(&sb->s_dentry_lru,
dentry_lru_isolate_shrink, &dispose, 1024);
-
- this_cpu_sub(nr_dentry_unused, freed);
shrink_dentry_list(&dispose);
} while (list_lru_count(&sb->s_dentry_lru) > 0);
}
--
1.8.3.1
It depends on USB_OTG_FSM, but USB_OTG_FSM can be module, so
FSL_USB2_OTG should be tristate. It fixes below build warning:
drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_ioctl':
phy-fsl-usb.c:(.text+0x5e4): undefined reference to `otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_start_srp':
phy-fsl-usb.c:(.text+0x680): undefined reference to `otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_set_host':
phy-fsl-usb.c:(.text+0x800): undefined reference to `otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_start_hnp':
phy-fsl-usb.c:(.text+0x88c): undefined reference to `otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `show_fsl_usb2_otg_state':
phy-fsl-usb.c:(.text+0xa44): undefined reference to `usb_otg_state_string'
drivers/usb/phy/phy-fsl-usb.o: In function `a_wait_enum':
phy-fsl-usb.c:(.text+0x1718): undefined reference to `otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_set_peripheral':
phy-fsl-usb.c:(.text+0x1f20): undefined reference to `usb_gadget_vbus_disconnect'
phy-fsl-usb.c:(.text+0x1f40): undefined reference to `otg_statemachine'
Cc: <stable(a)vger.kernel.org> #v4.1+
Cc: Li Yang <leoyang.li(a)nxp.com>
Reported-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Peter Chen <peter.chen(a)nxp.com>
---
drivers/usb/phy/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d7312eed6088..5444d2437475 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -20,7 +20,7 @@ config AB8500_USB
in host mode, low speed.
config FSL_USB2_OTG
- bool "Freescale USB OTG Transceiver Driver"
+ tristate "Freescale USB OTG Transceiver Driver"
depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y'
select USB_PHY
--
2.14.1
L1 tables are allocated with __get_dma_pages, and therefore already
ignored by kmemleak.
Without this, the kernel would print this error message on boot,
when the first L1 table is allocated:
[ 2.810533] kmemleak: Trying to color unknown object at 0xffffffd652388000 as Black
[ 2.818190] CPU: 5 PID: 39 Comm: kworker/5:0 Tainted: G S 4.19.16 #8
[ 2.831227] Workqueue: events deferred_probe_work_func
[ 2.836353] Call trace:
...
[ 2.852532] paint_ptr+0xa0/0xa8
[ 2.855750] kmemleak_ignore+0x38/0x6c
[ 2.859490] __arm_v7s_alloc_table+0x168/0x1f4
[ 2.863922] arm_v7s_alloc_pgtable+0x114/0x17c
[ 2.868354] alloc_io_pgtable_ops+0x3c/0x78
...
Fixes: e5fc9753b1a8314 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
Signed-off-by: Nicolas Boichat <drinkcat(a)chromium.org>
---
I only tested this on top of my other series
(https://patchwork.kernel.org/patch/10720495/), but I think the same fix
applies. I'm still a bit confused as to why this only shows up now, as IIUC,
the kmemleak_ignore call was always wrong with L1 tables.
drivers/iommu/io-pgtable-arm-v7s.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index cec29bf45c9bd7..98a4a4a0dfb0c1 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -217,7 +217,8 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
if (dma != phys)
goto out_unmap;
}
- kmemleak_ignore(table);
+ if (lvl == 2)
+ kmemleak_ignore(table);
return table;
out_unmap:
--
2.20.1.495.gaa96b0ce6b-goog
On Wed, Jan 30, 2019 at 02:46:48PM +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 1860033237d4 mm: make PR_SET_THP_DISABLE immediately active.
>
> The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96.
>
> v4.20.5: Build OK!
> v4.19.18: Build OK!
> v4.14.96: Failed to apply! Possible dependencies:
> f66406638fff ("proc: replace seq_printf on seq_putc to speed up /proc/pid/smaps")
>
>
> How should we proceed with this patch?
We shouldn't. It is a false positive due to Fixes flag.
Hi Sasha,
I will send v4.19 patch independently to the stable mailing list
after It gets carefully reviewed by Chao (and Al Viro if it is possible...)
Thanks,
Gao Xiang
On 2019/1/30 22:46, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: d72d1ce60174 staging: erofs: add namei functions.
>
> The bot has tested the following trees: v4.20.5, v4.19.18.
>
> v4.20.5: Build OK!
> v4.19.18: Failed to apply! Possible dependencies:
> 6e78901a9f23 ("staging: erofs: separate erofs_get_meta_page")
> 7dd68b147d60 ("staging: erofs: use explicit unsigned int type")
> 8be31270362b ("staging: erofs: introduce erofs_grab_bio")
> ab47dd2b0819 ("staging: erofs: cleanup z_erofs_vle_work_{lookup, register}")
>
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
>