On Sat, 25 May 2019, Sebastian Andrzej Siewior wrote:
> On 2019-05-24 15:22:51 [-0700], Hugh Dickins wrote:
> > I've now run a couple of hours of load successfully with Mike's patch
> > to GUP, no problem; but whatever the merits of that patch in general,
> >
On Sat, 25 May 2019, Pavel Machek wrote:
> Hi!
>
> > I'm having to revert 0db37915d912 ("leds: avoid races with workqueue")
> > from my 5.2-rc testing tree, because lockdep and other debug options
> > don't like it: net/mac80211/led.c arranges for led_blink_setup() to be
> > called at softirq
Hi Pavel,
I'm having to revert 0db37915d912 ("leds: avoid races with workqueue")
from my 5.2-rc testing tree, because lockdep and other debug options
don't like it: net/mac80211/led.c arranges for led_blink_setup() to be
called at softirq time, and flush_work() is not good for calling then.
Hugh
On Wed, 22 May 2019, Sebastian Andrzej Siewior wrote:
> On 2019-05-22 12:21:13 [-0700], Andrew Morton wrote:
> > On Tue, 14 May 2019 17:29:55 +0300 Mike Rapoport wrote:
> >
> > > When get_user_pages*() is called with pages = NULL, the processing of
> > > VM_FAULT_RETRY terminates early without
On Tue, 9 Apr 2019, Konstantin Khlebnikov wrote:
> On 08.04.2019 23:01, Hugh Dickins wrote:
> > - if (!list_empty(>swaplist)) {
> > + while (!list_empty(>swaplist)) {
> > + /* Wait while shmem_unu
preempted after its get_swap_page(), before making the
swap entry visible to swapoff.
Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity")
Signed-off-by: Hugh Dickins
---
include/linux/shmem_fs.h |1 +
mm/shmem.c | 39 ++-
was before, and needs a different interface: so leave it as is for now.
Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity")
Signed-off-by: Hugh Dickins
---
mm/swapfile.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
--- 5.1-rc4/mm/swapfile.c
ff of quadratic complexity")
Signed-off-by: Hugh Dickins
---
mm/swapfile.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- 5.1-rc4/mm/swapfile.c 2019-03-17 16:18:15.713823942 -0700
+++ linux/mm/swapfile.c 2019-04-07 19:15:01.269054187 -0700
@@ -2023,7 +2023,6 @@
e,
causing swapoff to be unnecessarily OOM-killed when it should succeed.
Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity")
Signed-off-by: Hugh Dickins
---
mm/shmem.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- 5.1-rc4/mm/shmem.c 2019-03-1
Here are four fixes to the new "rid quadratic" swapoff in 5.1-rc:
1/4 mm: swapoff: shmem_find_swap_entries() filter out other types
2/4 mm: swapoff: remove too limiting SWAP_UNUSE_MAX_TRIES
3/4 mm: swapoff: take notice of completion sooner
4/4 mm: swapoff: shmem_unuse() stop eviction without
On Mon, 8 Apr 2019, Konstantin Khlebnikov wrote:
>
> I suppose your solution will wait for wakeup from shmem_evict_inode()?
No, it's the other way round: shmem_unuse() gets on with its work without
delay, shmem_evict_inode() waits until the stop_eviction count has gone
down to zero, saying
On Fri, 5 Apr 2019, Konstantin Khlebnikov wrote:
> On 05.04.2019 5:12, Hugh Dickins wrote:
> > Hi Alex, could you please give the patch below a try? It fixes a
> > problem, but I'm not sure that it's your problem - please let us know.
> >
> > I've not yet writte
On Tue, 2 Apr 2019, Hugh Dickins wrote:
> On Sun, 31 Mar 2019, Hugh Dickins wrote:
> > On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote:
> > > Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm:
> > > > On Sun, Mar 24, 2019 at 11:30 AM Ale
On Sun, 31 Mar 2019, Hugh Dickins wrote:
> On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote:
> > Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm:
> > > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71)
> > > wrote:
> > >>
> > >> I
On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote:
> Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm:
> > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71)
> > wrote:
> >>
> >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I
> >> suspect my setup erroneously
/r/alpine.LSU.2.11.1902182134370.7035@eggly.anvils
> Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to")
> Signed-off-by: Darrick J. Wong
> Signed-off-by: Hugh Dickins
> Reported-by: Matej Kupljen
> Acked-by: Al Viro
> Signed-off-by: Andr
On Mon, 18 Mar 2019, Oscar Salvador wrote:
> Swap mapping->host is NULL, so let us protect __dump_page() for such cases.
Thanks :)
>
> Fixes: 1c6fb1d89e73c ("mm: print more information about mapping in
> __dump_page")
> Signed-off-by: Oscar Salvador
> Acked-by
On Fri, 15 Mar 2019, Oscar Salvador wrote:
> On Fri, Mar 15, 2019 at 01:47:33PM +0100, Michal Hocko wrote:
> > diff --git a/mm/debug.c b/mm/debug.c
> > index 1611cf00a137..499c26d5ebe5 100644
> > --- a/mm/debug.c
> > +++ b/mm/debug.c
> > @@ -78,6 +78,9 @@ void __dump_page(struct page *page, const
ated.
>
> Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1902182134370.7035@eggly.anvils
> Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to")
> Signed-off-by: Darrick J. Wong
> Signed-off-by: Hugh Dickins
> Reported-by: Matej Kupljen
&g
On Mon, 25 Feb 2019, Linus Torvalds wrote:
> On Fri, Feb 22, 2019 at 10:35 PM Hugh Dickins wrote:
> >
> > When we made the shmem_reserve_inode call in shmem_link conditional, we
> > forgot to update the declaration for ret so that it always has a known
> > value.
accounting when a tmpfile is linked in")
Reported-by: Dan Carpenter
Signed-off-by: Darrick J. Wong
Signed-off-by: Hugh Dickins
---
mm/shmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 0905215fb016..2c012eee133d 100644
--- a/mm/shme
ut this deficiency in the original patch.
>
> Fixes: "tmpfs: fix link accounting when a tmpfile is linked in"
> Reported-by: dan.carpen...@oracle.com
> Signed-off-by: Darrick J. Wong
Gosh, yes indeed: thanks Dan and Darrick, I'm very sorry for not noticing that.
Acked-by: Hugh Dickins
On Tue, 19 Feb 2019, Al Viro wrote:
> On Mon, Feb 18, 2019 at 09:37:52PM -0800, Hugh Dickins wrote:
> > From: "Darrick J. Wong"
> >
> > tmpfs has a peculiarity of accounting hard links as if they were separate
> > inodes: so that when the number of i
ood limiting, so no need to do anything more complicated.
Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to")
Reported-by: Matej Kupljen
Signed-off-by: Darrick J. Wong
Signed-off-by: Hugh Dickins
---
mm/shmem.c | 10 +++---
1 file changed, 7 insertions(+)
ust a free-floating leftover from the
previous tree.
"age" 0 or 1 says which: but if it's more than 1, then something has
gone wrong: cmp_and_merge_page() was forgetting to remove the item
in the new EBUSY case.
Signed-off-by: Hugh Dickins
---
Fix to fold into
mm-ksm-do-not-block-on-p
On Fri, 15 Feb 2019, Hugh Dickins wrote:
> On Thu, 14 Feb 2019, Darrick J. Wong wrote:
> > > On Mon, 11 Feb 2019 15:18:11 +0100 Matej Kupljen
> > > wrote:
> > > >
> > > > it seems that when opening file on file system that is mounted on
> >
On Thu, 14 Feb 2019, Darrick J. Wong wrote:
> [cc the shmem maintainer and the mm list]
Yup, thanks - Matej also did so the day after sending to linux-kernel.
>
> On Thu, Feb 14, 2019 at 03:44:02PM -0800, Andrew Morton wrote:
> > (cc linux-fsdevel)
Okay, thanks, but a tmpfs peculiarity we
On Tue, 5 Feb 2019, Linus Torvalds wrote:
> On Mon, Feb 4, 2019 at 8:43 PM Hugh Dickins wrote:
> >
> > Something I shall not be doing, is verifying the correctness of the
> > low-level get_page_unless_zero() versus page_ref_freeze() protocol
> > on arm64 and power -
On Tue, 5 Feb 2019, Qian Cai wrote:
>
> >> Cai, can you please check if you can reproduce this issue in your
> >> environment with 5.0-rc5?
> >
> > Yes, please do - practical confirmation more convincing than my certainty.
>
> Indeed, I am no longer be able to reproduce this anymore.
Great,
On Tue, 5 Feb 2019, Artem Savkov wrote:
> On Mon, Feb 04, 2019 at 12:42:50PM -0800, Hugh Dickins wrote:
> > On Mon, 4 Feb 2019, Artem Savkov wrote:
> >
> > > Hi Hugh,
> > >
> > > Your recent patch 9a1ea439b16b "mm: put_and_wait_on_page_locke
On Mon, 4 Feb 2019, Artem Savkov wrote:
> Hi Hugh,
>
> Your recent patch 9a1ea439b16b "mm: put_and_wait_on_page_locked() while
> page is migrated" seems to have introduced a race into page migration
> process. I have a host that eagerly reproduces the following BUG under
> stress:
>
> [
On Thu, 10 Jan 2019, Vlastimil Babka wrote:
>
> For the record, anyone backporting this to older kernels should make
> sure to also include 605ca5ede764 ("mm/huge_memory.c: reorder operations
> in __split_huge_page_tail()") or they are in for a lot of fun, like me.
Thanks a lot for alerting us
On Wed, 2 Jan 2019, Vineeth Pillai wrote:
>
> After reading the code again, I feel like we can make the retry logic
> simpler and avoid the use of oldi. If my understanding is correct,
> except for frontswap case, we reach try_to_unuse() only after we
> disable the swap device. So I think, we
On Tue, 1 Jan 2019, Vineeth Pillai wrote:
> Thanks a lot for the fixes and detailed explanation Hugh! I shall fold all
> the changes from you and Huang in the next iteration.
>
> Thanks for all the suggestions and comments as well. I am looking into all
> those and will include all the changes
On Mon, 3 Dec 2018, Vineeth Remanan Pillai wrote:
> This patch was initially posted by Kelley(kelley...@gmail.com).
> Reposting the patch with all review comments addressed and with minor
> modifications and optimizations. Tests were rerun and commit message
> updated with new results.
>
> The
s not worth doing the long ksm page rmap
> walk to reclaim just one page.
>
> Skip KSM pages in direct reclaim if the reclaim priority is low, but still
> try to reclaim KSM pages with high priority.
>
> Link:
> http://lkml.kernel.org/r/1541618201-120667-1-git-send-email-yan
On Wed, 19 Dec 2018, Paul Burton wrote:
> On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote:
> > The really simple but possibly suboptimal fix is to get rid of
> > VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it.
>
> I actually wound up trying this route because
> Cc:
> Fixes: 29ec90660d68 ("userfaultfd: shmem/hugetlbfs: only allow to register
> VM_MAYWRITE vmas")
> Reported-by: syzbot+06c7092e7d71218a2...@syzkaller.appspotmail.com
> Signed-off-by: Andrea Arcangeli
Acked-by: Hugh Dickins
> ---
> fs/userfaultfd.c | 3 ++-
> Cc:
> Fixes: 29ec90660d68 ("userfaultfd: shmem/hugetlbfs: only allow to register
> VM_MAYWRITE vmas")
> Reported-by: syzbot+06c7092e7d71218a2...@syzkaller.appspotmail.com
> Signed-off-by: Andrea Arcangeli
Acked-by: Hugh Dickins
> ---
> fs/userfaultfd.c | 3 ++-
On Tue, 27 Nov 2018, Mike Rapoport wrote:
> On Mon, Nov 26, 2018 at 11:27:07AM -0800, Hugh Dickins wrote:
> >
> > +/*
> > + * A choice of three behaviors for wait_on_page_bit_common():
> > + */
> > +enum behavior {
> > + EXCLUSIVE, /* Hold ref to
On Tue, 27 Nov 2018, Mike Rapoport wrote:
> On Mon, Nov 26, 2018 at 11:27:07AM -0800, Hugh Dickins wrote:
> >
> > +/*
> > + * A choice of three behaviors for wait_on_page_bit_common():
> > + */
> > +enum behavior {
> > + EXCLUSIVE, /* Hold ref to
ut I don't think it matters much, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-an
ut I don't think it matters much, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-an
On Sun, 25 Nov 2018, Linus Torvalds wrote:
> On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote:
> >
> > Linus, I'm addressing this patch to you because I see from Tim Chen's
> > thread that it would interest you, and you were disappointed not to
> > root caus
On Sun, 25 Nov 2018, Linus Torvalds wrote:
> On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote:
> >
> > Linus, I'm addressing this patch to you because I see from Tim Chen's
> > thread that it would interest you, and you were disappointed not to
> > root caus
h, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-and-tested-by: Baoquan He
S
h, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-and-tested-by: Baoquan He
S
On Thu, 22 Nov 2018, Michal Hocko wrote:
>
> If you want some update to the comment in this function or to the
> changelog, I am open of course. Right now I have
> +* Check for a locked page first, as a speculative
> +* reference may adversely influence page
On Thu, 22 Nov 2018, Michal Hocko wrote:
>
> If you want some update to the comment in this function or to the
> changelog, I am open of course. Right now I have
> +* Check for a locked page first, as a speculative
> +* reference may adversely influence page
On Wed, 21 Nov 2018, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:54:42 -0700 Yu Zhao wrote:
>
> > We changed key of swap cache tree from swp_entry_t.val to
> > swp_offset. Need to do so in shmem_replace_page() as well.
>
> What are the user-visible effects of this change?
Sorry, I don't
On Wed, 21 Nov 2018, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:54:42 -0700 Yu Zhao wrote:
>
> > We changed key of swap cache tree from swp_entry_t.val to
> > swp_offset. Need to do so in shmem_replace_page() as well.
>
> What are the user-visible effects of this change?
Sorry, I don't
On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Tue 20-11-18 17:47:21, Hugh Dickins wrote:
> > On Tue, 20 Nov 2018, Michal Hocko wrote:
> >
> > > From: Michal Hocko
> > >
> > > filemap_map_pages takes a speculative reference to each page in the
> >
On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Tue 20-11-18 17:47:21, Hugh Dickins wrote:
> > On Tue, 20 Nov 2018, Michal Hocko wrote:
> >
> > > From: Michal Hocko
> > >
> > > filemap_map_pages takes a speculative reference to each page in the
> >
On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 21:44:41, Hugh Dickins wrote:
> [...]
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a
On Wed, 21 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 21:44:41, Hugh Dickins wrote:
> [...]
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a
nel.org # v4.9+
> Signed-off-by: Yu Zhao
Acked-by: Hugh Dickins
Thanks!
> ---
> mm/shmem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d44991ea5ed4..42b70978e814 100644
> --- a/mm/shmem.c
>
nel.org # v4.9+
> Signed-off-by: Yu Zhao
Acked-by: Hugh Dickins
Thanks!
> ---
> mm/shmem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d44991ea5ed4..42b70978e814 100644
> --- a/mm/shmem.c
>
On Tue, 20 Nov 2018, Hugh Dickins wrote:
> On Tue, 20 Nov 2018, Vlastimil Babka wrote:
> > >
> > > finish_wait(q, wait);
> >
> > ... the code continues by:
> >
> > if (thrashing) {
> > if (!PageSwapBacked(page))
&
On Tue, 20 Nov 2018, Hugh Dickins wrote:
> On Tue, 20 Nov 2018, Vlastimil Babka wrote:
> > >
> > > finish_wait(q, wait);
> >
> > ... the code continues by:
> >
> > if (thrashing) {
> > if (!PageSwapBacked(page))
&
an Kara
> Signed-off-by: Michal Hocko
Acked-by: Hugh Dickins
though I think this patch is more useful to the avoid atomic ops,
and unnecessary dirtying of the cacheline, than to avoid the very
transient elevation of refcount, which will not affect page migration
very much.
> ---
>
an Kara
> Signed-off-by: Michal Hocko
Acked-by: Hugh Dickins
though I think this patch is more useful to the avoid atomic ops,
and unnecessary dirtying of the cacheline, than to avoid the very
transient elevation of refcount, which will not affect page migration
very much.
> ---
>
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/20/18 at 02:38pm, Vlastimil Babka wrote:
> > On 11/20/18 6:44 AM, Hugh Dickins wrote:
> > > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> > >
> > > We have all assumed that it is esse
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/20/18 at 02:38pm, Vlastimil Babka wrote:
> > On 11/20/18 6:44 AM, Hugh Dickins wrote:
> > > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> > >
> > > We have all assumed that it is esse
On Tue, 20 Nov 2018, Vlastimil Babka wrote:
> On 11/20/18 6:44 AM, Hugh Dickins wrote:
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a pag
On Tue, 20 Nov 2018, Vlastimil Babka wrote:
> On 11/20/18 6:44 AM, Hugh Dickins wrote:
> > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
> >
> > We have all assumed that it is essential to hold a page reference while
> > waiting on a pag
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/19/18 at 09:59pm, Michal Hocko wrote:
> > On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> > > I'm glad that I delayed, what I had then (migration_waitqueue instead
> > > of using page_waitqueue) was not wrong, but what I'v
On Tue, 20 Nov 2018, Baoquan He wrote:
> On 11/19/18 at 09:59pm, Michal Hocko wrote:
> > On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> > > I'm glad that I delayed, what I had then (migration_waitqueue instead
> > > of using page_waitqueue) was not wrong, but what I'v
On Mon, 19 Nov 2018, Yu Zhao wrote:
> On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote:
> > On Sun, 18 Nov 2018, Yu Zhao wrote:
> >
> > > We used to have a single swap address space with swp_entry_t.val
> > > as its radix tree index. This
On Mon, 19 Nov 2018, Yu Zhao wrote:
> On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote:
> > On Sun, 18 Nov 2018, Yu Zhao wrote:
> >
> > > We used to have a single swap address space with swp_entry_t.val
> > > as its radix tree index. This
On Sun, 18 Nov 2018, Yu Zhao wrote:
> We used to have a single swap address space with swp_entry_t.val
> as its radix tree index. This is not the case anymore. Now Each
> swp_type() has its own address space and should use swp_offset()
> as radix tree index.
>
> Signed-off-by: Yu Zhao
This fix
On Sun, 18 Nov 2018, Yu Zhao wrote:
> We used to have a single swap address space with swp_entry_t.val
> as its radix tree index. This is not the case anymore. Now Each
> swp_type() has its own address space and should use swp_offset()
> as radix tree index.
>
> Signed-off-by: Yu Zhao
This fix
On Mon, 19 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> [...]
> > In other words. Why cannot we do the following?
>
> Baoquan, this is certainly not the right fix but I would be really
> curious whether it makes the problem go away.
>
> > diff --git
On Mon, 19 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 15:10:16, Michal Hocko wrote:
> [...]
> > In other words. Why cannot we do the following?
>
> Baoquan, this is certainly not the right fix but I would be really
> curious whether it makes the problem go away.
>
> > diff --git
Hi Jann,
On Mon, 17 Sep 2018, Jann Horn wrote:
> [I'm not sure who the best people to ask about this are, I hope the
> recipient list resembles something reasonable...]
>
> I have noticed that the dup_mmap() logic on fork() doesn't handle
> pages with active direct I/O properly: dup_mmap()
Hi Jann,
On Mon, 17 Sep 2018, Jann Horn wrote:
> [I'm not sure who the best people to ask about this are, I hope the
> recipient list resembles something reasonable...]
>
> I have noticed that the dup_mmap() logic on fork() doesn't handle
> pages with active direct I/O properly: dup_mmap()
ng larger base page sizes than 4k. No such workarounds needed on
> >> platforms that support large sizes. Things just zoom along without
> >> contortions necessary to deal with huge pages etc.
> >>
> >> Can we come up with a 2M base page VM or someth
ng larger base page sizes than 4k. No such workarounds needed on
> >> platforms that support large sizes. Things just zoom along without
> >> contortions necessary to deal with huge pages etc.
> >>
> >> Can we come up with a 2M base page VM or someth
On Tue, 7 Aug 2018, zhaowu...@wingtech.com wrote:
>
> Thanks for affirming the modification of disabling preemption and
> pointing out the incompleteness, delete_from_swap_cache() needs the same
> protection.
> I'm curious about that why don't put swapcache_free(swap) under protection of
>
On Tue, 7 Aug 2018, zhaowu...@wingtech.com wrote:
>
> Thanks for affirming the modification of disabling preemption and
> pointing out the incompleteness, delete_from_swap_cache() needs the same
> protection.
> I'm curious about that why don't put swapcache_free(swap) under protection of
>
On Fri, 27 Jul 2018, zhaowu...@wingtech.com wrote:
> >On Thu, 26 Jul 2018 15:03:23 +0800 "zhaowu...@wingtech.com"
> > wrote:
> >
> >> >On Thu 26-07-18 10:21:40, zhaowu...@wingtech.com wrote:
> >> >[...]
> >> >> Our project really needs a fix to this issue
> >> >
> >> >Could you be more specific
On Fri, 27 Jul 2018, zhaowu...@wingtech.com wrote:
> >On Thu, 26 Jul 2018 15:03:23 +0800 "zhaowu...@wingtech.com"
> > wrote:
> >
> >> >On Thu 26-07-18 10:21:40, zhaowu...@wingtech.com wrote:
> >> >[...]
> >> >> Our project really needs a fix to this issue
> >> >
> >> >Could you be more specific
On Sat, 4 Aug 2018, Linus Torvalds wrote:
> On Fri, Aug 3, 2018 at 5:19 PM Hugh Dickins wrote:
> >
> > I thought that virt_to_page() only works on virtual addresses
> > in the direct map
>
> You're right that virt_to_page() does not work on any _actual_ virtual
&
On Sat, 4 Aug 2018, Linus Torvalds wrote:
> On Fri, Aug 3, 2018 at 5:19 PM Hugh Dickins wrote:
> >
> > I thought that virt_to_page() only works on virtual addresses
> > in the direct map
>
> You're right that virt_to_page() does not work on any _actual_ virtual
&
xffff826000001504K
> pte
> current_user-0x8260-0xa000 474M
> pmd
>
> Signed-off-by: Dave Hansen
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: And
xffff826000001504K
> pte
> current_user-0x8260-0xa000 474M
> pmd
>
> Signed-off-by: Dave Hansen
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: And
d wonder if you meant " now ".
> Signed-off-by: Dave Hansen
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Andrea Arcangeli
> Cc: Juergen Gross
> Cc: Josh Poimboeuf
> Cc: Greg Kroah-Hartman
> Cc: Peter Zijlstra
> Cc: Hugh Dickins
>
d wonder if you meant " now ".
> Signed-off-by: Dave Hansen
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Andrea Arcangeli
> Cc: Juergen Gross
> Cc: Josh Poimboeuf
> Cc: Greg Kroah-Hartman
> Cc: Peter Zijlstra
> Cc: Hugh Dickins
>
8200-0x8240 4M ro
>PSE GLB NX pmd
> current_user-0x8240-0x82488000 544K ro
>NX pte
> current_user-0x82488000-0x8260 1504K
>
8200-0x8240 4M ro
>PSE GLB NX pmd
> current_user-0x8240-0x82488000 544K ro
>NX pte
> current_user-0x82488000-0x8260 1504K
>
On Wed, 1 Aug 2018, Kirill A. Shutemov wrote:
> On Wed, Aug 01, 2018 at 11:31:52AM -0700, Hugh Dickins wrote:
> > On Wed, 1 Aug 2018, Linus Torvalds wrote:
> > >
> > > Anyway, the upshot of all this is that I think I know what the ia64
> > > problem was, an
On Wed, 1 Aug 2018, Kirill A. Shutemov wrote:
> On Wed, Aug 01, 2018 at 11:31:52AM -0700, Hugh Dickins wrote:
> > On Wed, 1 Aug 2018, Linus Torvalds wrote:
> > >
> > > Anyway, the upshot of all this is that I think I know what the ia64
> > > problem was, an
ely clear,
but the danger of sometimes crashing on the BUG is now fairly clear.
Signed-off-by: Hugh Dickins
---
mm/memory.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- 4.18-rc7/mm/memory.c2018-06-16 18:48:22.041173422 -0700
+++ linux/mm/memory.c 2018-08-01
ely clear,
but the danger of sometimes crashing on the BUG is now fairly clear.
Signed-off-by: Hugh Dickins
---
mm/memory.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- 4.18-rc7/mm/memory.c2018-06-16 18:48:22.041173422 -0700
+++ linux/mm/memory.c 2018-08-01
On Tue, 31 Jul 2018, Kirill A. Shutemov wrote:
> On Tue, Jul 31, 2018 at 09:29:27AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Jul 30, 2018 at 06:01:26PM -0700, Linus Torvalds wrote:
> > >
> > > So to me it looks like a historical check that simply doesn't
> > > "normally" trigger, but there's
On Tue, 31 Jul 2018, Kirill A. Shutemov wrote:
> On Tue, Jul 31, 2018 at 09:29:27AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Jul 30, 2018 at 06:01:26PM -0700, Linus Torvalds wrote:
> > >
> > > So to me it looks like a historical check that simply doesn't
> > > "normally" trigger, but there's
On Mon, 30 Jul 2018, Linus Torvalds wrote:
> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote:
> >
> > I have no problem with reverting -rc7's vma_is_anonymous() series.
>
> I don't think we need to revert the whole series: I think the rest are
> all fairly obvious
On Mon, 30 Jul 2018, Linus Torvalds wrote:
> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote:
> >
> > I have no problem with reverting -rc7's vma_is_anonymous() series.
>
> I don't think we need to revert the whole series: I think the rest are
> all fairly obvious
On Mon, 30 Jul 2018, Linus Torvalds wrote:
> On Mon, Jul 30, 2018 at 6:01 AM Kirill A. Shutemov
> wrote:
> >
> > I think I missed vma_set_anonymous() somewhere, but I fail to see where.
>
> Honestly, by now we just need to revert that commit.
>
> It's not even clear that it was a good idea to
On Mon, 30 Jul 2018, Linus Torvalds wrote:
> On Mon, Jul 30, 2018 at 6:01 AM Kirill A. Shutemov
> wrote:
> >
> > I think I missed vma_set_anonymous() somewhere, but I fail to see where.
>
> Honestly, by now we just need to revert that commit.
>
> It's not even clear that it was a good idea to
On Thu, 26 Jul 2018, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:53:15PM -0700, Hugh Dickins wrote:
>
> and fixing the bug differently ;-) But many thanks for spotting it!
I thought you might :)
>
> I'll look into the next bug you reported ...
No need: that idea now wor
301 - 400 of 4042 matches
Mail list logo
