The patch titled
Subject: mm: use swp_offset as key in shmem_replace_page()
has been added to the -mm tree. Its filename is
mm-use-swp_offset-as-key-in-shmem_replace_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-use-swp_offset-as-key-in-shmem_…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-use-swp_offset-as-key-in-shmem_…
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: Yu Zhao <yuzhao(a)google.com>
Subject: mm: use swp_offset as key in shmem_replace_page()
We changed the key of swap cache tree from swp_entry_t.val to swp_offset.
We need to do so in shmem_replace_page() as well.
Link: http://lkml.kernel.org/r/20181121215442.138545-1-yuzhao@google.com
Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap cache")
Signed-off-by: Yu Zhao <yuzhao(a)google.com>
Reviewed-by: Matthew Wilcox <willy(a)infradead.org>
Acked-by: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.9+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/shmem.c~mm-use-swp_offset-as-key-in-shmem_replace_page
+++ a/mm/shmem.c
@@ -1509,11 +1509,13 @@ static int shmem_replace_page(struct pag
{
struct page *oldpage, *newpage;
struct address_space *swap_mapping;
+ swp_entry_t entry;
pgoff_t swap_index;
int error;
oldpage = *pagep;
- swap_index = page_private(oldpage);
+ entry.val = page_private(oldpage);
+ swap_index = swp_offset(entry);
swap_mapping = page_mapping(oldpage);
/*
@@ -1532,7 +1534,7 @@ static int shmem_replace_page(struct pag
__SetPageLocked(newpage);
__SetPageSwapBacked(newpage);
SetPageUptodate(newpage);
- set_page_private(newpage, swap_index);
+ set_page_private(newpage, entry.val);
SetPageSwapCache(newpage);
/*
_
Patches currently in -mm which might be from yuzhao(a)google.com are
mm-use-swp_offset-as-key-in-shmem_replace_page.patch
mm-dont-expose-page-to-fast-gup-before-its-ready.patch
From: Ben Hutchings <ben(a)decadent.org.uk>
Depending on which functions are inlined in util/pmu.c, the snprintf()
calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
warning:
util/pmu.c: In function 'pmu_aliases':
util/pmu.c:178:31: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
^~
I found this when trying to build perf from Linux 3.16 with gcc 8.
However I can reproduce the problem in mainline if I force
__perf_pmu__new_alias() to be inlined.
Suppress this by using scnprintf() as has been done elsewhere in perf.
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20181111184524.fux4taownc6ndbx6@decadent.org.uk
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
---
tools/perf/util/pmu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7e49baad304d..7348eea0248f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -145,7 +145,7 @@ static int perf_pmu__parse_scale(struct perf_pmu_alias *alias, char *dir, char *
int fd, ret = -1;
char path[PATH_MAX];
- snprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -175,7 +175,7 @@ static int perf_pmu__parse_unit(struct perf_pmu_alias *alias, char *dir, char *n
ssize_t sret;
int fd;
- snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -205,7 +205,7 @@ perf_pmu__parse_per_pkg(struct perf_pmu_alias *alias, char *dir, char *name)
char path[PATH_MAX];
int fd;
- snprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -223,7 +223,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias *alias,
char path[PATH_MAX];
int fd;
- snprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
--
2.14.5
On Thu, 22 Nov 2018 at 11:42, 陳雅正 <yacheng600221(a)gmail.com> wrote:
>
> Hi Dave,
> Thanks for your feedback. No issue found actually if I remove "volatile" on my platform. In my experience, if the value is volatile, adding "volatile" will be safer and no harm, that is why I add it by default. If you think it is not necessary, it's ok for me to remove it.
>
Don't add it unless you've got proof you need it, we don't want it
confusing people later.
Dave.
Dear stable kernel team,
In stable kernel 4.19.2, the following upstream commit was included:
commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
Author: Erik Schmauss
Date: Wed Oct 17 14:09:35 2018 -0700
ACPICA: AML interpreter: add region addresses in global list during initialization
This commit was tagged with:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
Tested-by: Jean-Marc Lenoir
Cc: All applicable <stable(a)vger.kernel.org>
making it sound like it was fixing an actual bug. This is not the case.
The commit fixes a side issue discovered while investigating bug
#200011. It does NOT fix bug #200011 itself (as explicitly reported by
Jean-Marc at https://bugzilla.kernel.org/show_bug.cgi?id=200011#c65 ).
It does however cause regressions, despite what the commit message says. See:
https://bugzilla.kernel.org/show_bug.cgi?id=201721
and I expect more similar regressions, as ACPI resource conflicts are
very frequent.
This commit was not stable material to start with. It is intrusive,
presents a risk of side effects, and does not solve an actual bug that
is bothering users.
Please revert this commit from future stable kernels on all affected
branches (I think only 4.18.19 and 4.19.2 are affected at the moment,
but maybe other affected releases are in the works already).
Thanks,
--
Jean Delvare
SUSE L3 Support