On Mon, 29 Jan 2024, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel
> 6.8.0-rc1-gecb1b8288dc7. Attached to the email were a POC file of the issue.
>
> Stack dump:
> [
# 1.064 G/sec
> 803,233,322iTLB-load-misses # 0.229182% miss rate
>
> Total test time: 329.826087 seconds
>
> A check of /proc/$(pidof dex2oat64)/smaps shows THPs in use:
>
> /apex/com.android.art/lib64/libart.so
> FilePmdMapped: 4096 kB
>
> /apex/c
On Mon, 12 Apr 2021, Axel Rasmussen wrote:
> In a previous commit, we added the mcopy_atomic_install_ptes() helper.
> This helper does the job of setting up PTEs for an existing page, to map
> it into a given VMA. It deals with both the anon and shmem cases, as
> well as the shared and private
On Mon, 12 Apr 2021, Axel Rasmussen wrote:
> With this change, userspace can resolve a minor fault within a
> shmem-backed area with a UFFDIO_CONTINUE ioctl. The semantics for this
> match those for hugetlbfs - we look up the existing page in the page
> cache, and install PTEs for it.
s/PTEs/a
On Thu, 15 Apr 2021, Axel Rasmussen wrote:
> Base
>
>
> This series is based on (and therefore should apply cleanly to) the tag
> "v5.12-rc7-mmots-2021-04-11-20-49", additionally with Peter's selftest cleanup
> series applied first:
>
> https://lore.kernel.org/patchwork/cover/1412450/
>
>
On Mon, 12 Apr 2021, Axel Rasmussen wrote:
> This patch allows shmem-backed VMAs to be registered for minor faults.
> Minor faults are appropriately relayed to userspace in the fault path,
> for VMAs with the relevant flag.
>
> This commit doesn't hook up the UFFDIO_CONTINUE ioctl for
quivalent to pgoff, so we can get rid of offset entirely.
> - Split two VM_BUG_ON cases into two statements. This means the line
> number reported when the BUG is hit specifies exactly which condition
> was true.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Axel Rasmussen
On Mon, 12 Apr 2021, Axel Rasmussen wrote:
> Minimizing header file inclusion is desirable. In this case, we can do
> so just by forward declaring the enumeration our signature relies upon.
>
> Reviewed-by: Peter Xu
> Signed-off-by: Axel Rasmussen
> ---
> include/linux/hugetlb.h | 4 +++-
>
ake comments describing trim_snb_memory()
> operation more elaborate.
>
> Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Randy Dunlap
> Signed-off-by: Mike Rapoport
Tested-by: Hugh Dickins
Thanks Mike and Randy. ThinkPad T420s here.
On Mon, 12 Apr 2021, Peter Xu wrote:
> On Tue, Apr 06, 2021 at 11:14:30PM -0700, Hugh Dickins wrote:
> > > +static int mcopy_atomic_install_ptes(struct mm_struct *dst_mm, pmd_t
> > > *dst_pmd,
> > > +
On Thu, 8 Apr 2021, Axel Rasmussen wrote:
> On Tue, Apr 6, 2021 at 4:49 PM Peter Xu wrote:
> > On Mon, Apr 05, 2021 at 10:19:17AM -0700, Axel Rasmussen wrote:
...
> > > --- a/mm/userfaultfd.c
> > > +++ b/mm/userfaultfd.c
...
> > > +
> > > + if (is_file_backed) {
> > > + /* The
On Wed, 7 Apr 2021, Axel Rasmussen wrote:
> Agreed about taking one direction or the other further.
>
> I get the sense that Peter prefers the mcopy_atomic_install_ptes()
> version, and would thus prefer to just expose that and let
> shmem_mcopy_atomic_pte() use it.
>
> But, I get the sense that
[PATCH v4] userfaultfd/shmem: fix MCOPY_ATOMIC_CONTINUE behavior
was a significant rework, so here I'm reviewing a synthetic patch
merged from 5.12-rc5's 2021-03-31 mmotm patches:
userfaultfd-support-minor-fault-handling-for-shmem.patch
On Fri, 2 Apr 2021, Hugh Dickins wrote:
>
> There is a "Put holes back where they were" xas_store(, NULL) on
> the failure path, which I think we would expect to delete empty nodes.
> But it only goes as far as nr_none. Is it ok to xas_store(, NULL)
> where there was no
On Fri, 2 Apr 2021, Matthew Wilcox wrote:
> OK, more competent testing, and that previous bug now detected and fixed.
> I have a reasonable amount of confidence this will solve your problem.
> If you do apply this patch, don't enable CONFIG_TEST_XARRAY as the new
> tests assume that attempting to
On Wed, 31 Mar 2021, Matthew Wilcox wrote:
> On Tue, Mar 30, 2021 at 06:30:22PM -0700, Hugh Dickins wrote:
> > Running my usual tmpfs kernel builds swapping load, on Sunday's rc4-mm1
> > mmotm (I never got to try rc3-mm1 but presume it behaved the same way),
> > I hit c
On Wed, 31 Mar 2021, Yang Shi wrote:
> On Wed, Mar 31, 2021 at 6:54 AM Shakeel Butt wrote:
> > On Tue, Mar 30, 2021 at 4:44 PM Hugh Dickins wrote:
> > >
> > > Lockdep warns mm/vmscan.c: suspicious rcu_dereference_protected() usage!
> > > when
Running my usual tmpfs kernel builds swapping load, on Sunday's rc4-mm1
mmotm (I never got to try rc3-mm1 but presume it behaved the same way),
I hit clear_inode()'s BUG_ON(!mapping_empty(>i_data)); on two
machines, within an hour or few, repeatably though not to order.
The stack backtrace has
free_shrinker_info() can manage the shrinker_rwsem for itself.
Link: https://lkml.kernel.org/r/20210317140615.GB28839@xsang-OptiPlex-9020
Reported-by: kernel test robot
Signed-off-by: Hugh Dickins
Cc: Yang Shi
---
Sorry, I've made no attempt to work out precisely where in the series
the locking went
On Fri, 26 Mar 2021, Matthew Wilcox wrote:
> On Thu, Mar 25, 2021 at 06:55:42PM -0700, Hugh Dickins wrote:
> > The first reason occurred to me this morning. I thought I had been
> > clever to spot the PageHead race which you fix here. But now I just feel
> > very stupi
On Tue, 23 Mar 2021, Hugh Dickins wrote:
> On Tue, 23 Mar 2021, Johannes Weiner wrote:
> > From f6f062a3ec46f4fb083dcf6792fde9723f18cfc5 Mon Sep 17 00:00:00 2001
> > From: Johannes Weiner
> > Date: Fri, 19 Mar 2021 02:17:00 -0400
> > Subject: [PATCH] mm: page_alloc: fix
in the KAISER disabled case.
>
> Co-debugged by Babu Moger .
>
> Reported-by: Jim Mattson
> Signed-off-by: Borislav Petkov
> Link:
> https://lkml.kernel.org/r/CALMp9eRDSW66%2BXvbHVF4ohL7XhThoPoT0BrB0TcS0cgk=dk...@mail.gmail.com
Acked-by: Hugh Dickins
Great write-up too: many thanks.
On Wed, 24 Mar 2021, Hugh Dickins wrote:
> On Wed, 24 Mar 2021, Borislav Petkov wrote:
>
> > Ok,
> >
> > some more experimenting Babu and I did lead us to:
> >
> > ---
> > diff --git a/arch/x86/include/asm/tlbflush.h
> > b/arch/x86/include/asm
On Wed, 24 Mar 2021, Borislav Petkov wrote:
> Ok,
>
> some more experimenting Babu and I did lead us to:
>
> ---
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index f5ca15622dc9..259aa4889cad 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++
> happening to the page during that race.
>
> Fixes: e320d3012d25 mm/page_alloc.c: fix freeing non-compound pages
> Reported-by: Hugh Dickins
> Reported-by: Matthew Wilcox
> Signed-off-by: Johannes Weiner
> Cc: # 5.10+
This is great, thanks Hannes.
Acked-by: Hugh Di
s still describe an earlier version, they should say:
"mappings, and these special mappings are now protected by a check of
!VM_DONTEXPAND and !VM_PFNMAP which will result in a -EINVAL."
>
> 1. https://lkml.org/lkml/2020/12/28/2340
>
> Signed-off-by: Brian Geffon
> Acked-by
xactly is happening to the page during that race.
>
> This bug is old and has its roots in the speculative page cache patch
> and adding cgroup accounting of kernel pages. There are no known user
> reports. A backport to stable is therefor not warranted.
>
> Reported-by: Matthew
On Fri, 19 Mar 2021, Johannes Weiner wrote:
> The swapaccounting= commandline option already does very little
> today. To close a trivial containment failure case, the swap ownership
> tracking part of the swap controller has recently become mandatory
> (see commit 2d1c498072de ("mm: memcontrol:
ntrol: make swap tracking an integral part of
> memory control")
> Reported-by: Hugh Dickins
> Signed-off-by: Johannes Weiner
Acked-by: Hugh Dickins
Thanks for the memory!
> ---
> mm/memcontrol.c | 3 +++
> mm/swap_cgroup.c | 6 ++
> 2 files changed,
w
vm_insert_page() case.
Also make some things a bit more anal wrt VM_PFNMAP.
Pointed out by Hugh Dickins
Signed-off-by: Linus Torvalds
So apparently I do bear some anal responsibility. My concern seems
to have been that in those days an unexpected page fault in a special
driver area would en
up needed: -EFAULT was what the incorrect v2 gave, but
v3 issues -EINVAL like before, and I'm content with that difference.
>
> 1. https://lkml.org/lkml/2020/12/28/2340
>
> Signed-off-by: Brian Geffon
Acked-by: Hugh Dickins
Thanks Brian, I'm happy with this result.
> ---
> arch/x86/
vate anonymous mappings, this
> patch will enable using UFFDIO_CONTINUE for the new userfaultfd-based heap
> compaction."
>
> [1]
> https://lore.kernel.org/linux-mm/20201215030730.nc3cu98e4%25a...@linux-foundation.org/
> [2]
> https://lore.kernel.org/linux-mm/202103020001
On Wed, 3 Mar 2021, Brian Geffon wrote:
> Currently MREMAP_DONTUNMAP only accepts private anonymous mappings. This
> change
> will widen the support to include shmem mappings. The primary use case
> is to support MREMAP_DONTUNMAP on mappings which may have been created from
> a memfd.
>
>
On Sat, 13 Mar 2021, Andrew Morton wrote:
> On Fri, 5 Mar 2021 04:18:36 + "Matthew Wilcox (Oracle)"
> wrote:
>
> > Our type system does not currently distinguish between tail pages and
> > head or single pages. This is a problem because we call compound_head()
> > multiple times (and the
On Thu, 11 Mar 2021, Jue Wang wrote:
> On Thu, Mar 11, 2021 at 7:14 AM HORIGUCHI NAOYA(堀口 直也)
> wrote:
> > On Wed, Mar 10, 2021 at 11:22:18PM -0800, Hugh Dickins wrote:
> > >
> > > I'm not much into memory-failure myself, but Jue discovered that the
>
On Thu, 11 Mar 2021, Michal Hocko wrote:
> On Thu 11-03-21 10:21:39, Johannes Weiner wrote:
> > On Thu, Mar 11, 2021 at 09:37:02AM +0100, Michal Hocko wrote:
> > > Johannes, Hugh,
> > >
> > > what do you think about this approach? If we want to stick with
> > > split_page approach then we need to
}
> + pr_info("%s: %#lx: thp split failed\n", msg, page_to_pfn(page));
> unlock_page(page);
> -
> - return 0;
> + put_page(page);
> + return -EBUSY;
> }
>
> static int memory_failure_hugetlb(unsigned long pfn, int flags)
> --
> 2.25.1
On Thu, 11 Mar 2021, Singh, Balbir wrote:
> On 9/3/21 7:28 pm, Michal Hocko wrote:
> > On Tue 09-03-21 09:37:29, Balbir Singh wrote:
> >> On 4/3/21 6:40 pm, Zhou Guanghui wrote:
> > [...]
> >>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>> /*
> >>> - * Because page_memcg(head) is not set on compound
On Sat, 6 Mar 2021, Sedat Dilek wrote:
> On Sat, Mar 6, 2021 at 8:48 PM Hugh Dickins wrote:
> >
> > There is no iwl_so_trans_cfg if CONFIG_IWLDVM but not CONFIG_IWLMVM:
> > move the CONFIG_IWLMVM guard up before the problematic SnJ workaround
> > to fix the bu
No time_point op has been provided for DVM: check for NULL before
calling, to fix the oops (blank screen booting non-modular kernel).
Fixes: d01293154c0a ("iwlwifi: dbg: add op_mode callback for collecting debug
data.")
Signed-off-by: Hugh Dickins
---
drivers/net/wireless/intel/iwlw
There is no iwl_so_trans_cfg if CONFIG_IWLDVM but not CONFIG_IWLMVM:
move the CONFIG_IWLMVM guard up before the problematic SnJ workaround
to fix the build breakage.
Fixes: 930be4e76f26 ("iwlwifi: add support for SnJ with Jf devices")
Signed-off-by: Hugh Dickins
---
drivers/net/wire
On Fri, 5 Mar 2021, Shakeel Butt wrote:
> On Fri, Mar 5, 2021 at 1:26 PM Shakeel Butt wrote:
> >
> > Currently the kernel adds the page, allocated for swapin, to the
> > swapcache before charging the page. This is fine but now we want a
> > per-memcg swapcache stat which is essential for folks
annes talked you out of __GFP_NOFAIL: much better like this).
I'll say
Acked-by: Hugh Dickins
but I am quite unhappy with the name mem_cgroup_finish_swapin_page():
it doesn't finish the swapin, it doesn't finish the page, and I'm
not persuaded by your paragraph above that there's any "tr
On Tue, 2 Mar 2021, Johannes Weiner wrote:
> On Tue, Mar 02, 2021 at 12:24:41PM -0800, Hugh Dickins wrote:
> > On Tue, 2 Mar 2021, Michal Hocko wrote:
> > > [Cc Johannes for awareness and fixup Nick's email]
> > >
> > > On Tue 02-03-21 01:34:51, Zhou Gua
On Tue, 2 Mar 2021, Michal Hocko wrote:
> [Cc Johannes for awareness and fixup Nick's email]
>
> On Tue 02-03-21 01:34:51, Zhou Guanghui wrote:
> > When split page, the memory cgroup info recorded in first page is
> > not copied to tail pages. In this case, when the tail pages are
> > freed, the
Gushchin
Signed-off-by: Hugh Dickins
---
mm/vmstat.c | 15 +++
1 file changed, 15 insertions(+)
--- vmstat2/mm/vmstat.c 2021-02-25 11:56:18.0 -0800
+++ vmstat3/mm/vmstat.c 2021-02-25 12:42:15.0 -0800
@@ -1840,6 +1840,14 @@ int vmstat_refresh(struct ctl_table *tab
On Sun, 28 Feb 2021, Roman Gushchin wrote:
> On Thu, Feb 25, 2021 at 03:14:03PM -0800, Hugh Dickins wrote:
> > vmstat_refresh() can occasionally catch nr_zone_write_pending and
> > nr_writeback when they are transiently negative. The reason is partly
> > that the interrupt
On Mon, 1 Mar 2021, Yu Zhao wrote:
> On Mon, Mar 01, 2021 at 02:50:07PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Feb 26, 2021 at 12:13:14PM +, Matthew Wilcox wrote:
> > > On Fri, Feb 26, 2021 at 02:17:18AM -0700, Yu Zhao wrote:
> > > > All places but one test, set or clear PG_active and
On Fri, 26 Feb 2021, Palmer Dabbelt wrote:
> On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:
> > On Fri, 26 Feb 2021, Andrew Morton wrote:
> > > On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt
> > > wrote:
> > > > From: Palmer Dabbelt
> > > >
> > > > This is only useful under
On Fri, 26 Feb 2021, Andrew Morton wrote:
> On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt wrote:
> > From: Palmer Dabbelt
> >
> > This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> > right thing to do here, as without CONFIG_NUMA there will never be any
> > large node
All of the VM NUMA stats are event counts, incremented never decremented:
it is not very useful for vmstat_refresh() to check them throughout their
first aeon, then warn on them throughout their next.
Signed-off-by: Hugh Dickins
---
mm/vmstat.c |9 -
1 file changed, 9 deletions
, but the migratetype
of a pageblock is not guaranteed to be constant.
Use switch statements so we can most easily add or remove cases later.
Link: https://lore.kernel.org/linux-mm/20200714173747.3315771-1-g...@fb.com/
Reported-by: Roman Gushchin
Signed-off-by: Hugh Dickins
---
mm/vmstat.c | 15
uch failed with that error. Stop doing that.
Signed-off-by: Hugh Dickins
---
mm/vmstat.c |5 -
1 file changed, 5 deletions(-)
--- vmstat1/mm/vmstat.c 2021-02-25 11:50:36.0 -0800
+++ vmstat2/mm/vmstat.c 2021-02-25 11:56:18.0 -0800
@@ -1844,7 +1844,6 @@ int vmstat_refr
EMS without updating
vmstat_refresh(): so it has been missing out much of the vmstat underflow
checking ever since. Reinstate it. Thanks to Roman Gushchin
for tangentially pointing this out.
Signed-off-by: Hugh Dickins
---
mm/vmstat.c |8
1 file changed, 8 insertions(+)
--- 5.12-rc/mm
On Wed, 24 Feb 2021, Roman Gushchin wrote:
> On Tue, Feb 23, 2021 at 11:24:23PM -0800, Hugh Dickins wrote:
> > On Thu, 6 Aug 2020, Andrew Morton wrote:
> > > On Thu, 6 Aug 2020 16:38:04 -0700 Roman Gushchin wrote:
> >
> > August, yikes, I t
On Wed, 24 Feb 2021, Rik van Riel wrote:
> On Wed, 2021-02-24 at 00:41 -0800, Hugh Dickins wrote:
> > On Mon, 14 Dec 2020, Vlastimil Babka wrote:
> >
> > > > (There's also a specific issue with the gfp_mask limiting: I have
> > > > not yet reviewed the allow
On Mon, 14 Dec 2020, Vlastimil Babka wrote:
> On 12/14/20 10:16 PM, Hugh Dickins wrote:
> > On Tue, 24 Nov 2020, Rik van Riel wrote:
> >
> >> The allocation flags of anonymous transparent huge pages can be controlled
> >> through the files in /sys/kernel/mm/trans
On Thu, 6 Aug 2020, Andrew Morton wrote:
> On Thu, 6 Aug 2020 16:38:04 -0700 Roman Gushchin wrote:
August, yikes, I thought it was much more recent.
>
> > it seems that Hugh and me haven't reached a consensus here.
> > Can, you, please, not merge this patch into 5.9, so we would have
> > more
On Mon, 22 Feb 2021, Jens Axboe wrote:
> On 2/22/21 2:31 PM, Hugh Dickins wrote:
> > On Thu, 18 Feb 2021, Jens Axboe wrote:
> >> On 2/18/21 4:16 PM, Andrew Morton wrote:
> >>> On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe wrote:
> >>>
> >&
On Thu, 18 Feb 2021, Jens Axboe wrote:
> On 2/18/21 4:16 PM, Andrew Morton wrote:
> > On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe wrote:
> >
> >> Currently we cap the batch count at max(32, 2*nr_online_cpus), which these
> >> days is kind of silly as systems have gotten much bigger than in
On Wed, 10 Feb 2021, Michal Hocko wrote:
> On Wed 10-02-21 17:57:29, Michal Hocko wrote:
> > On Wed 10-02-21 16:18:50, Vlastimil Babka wrote:
> [...]
> > > And the munlock (munlock_vma_pages_range()) is slow, because it uses
> > > follow_page_mask() in a loop incrementing addresses by PAGE_SIZE,
On Wed, 10 Feb 2021, Johannes Weiner wrote:
> On Wed, Feb 10, 2021 at 08:22:00AM -0800, Hugh Dickins wrote:
> > On Tue, 9 Feb 2021, Hugh Dickins wrote:
> > > On Tue, 9 Feb 2021, Johannes Weiner wrote:
> > >
> > > > Page writeback doesn't hold
On Tue, 9 Feb 2021, Hugh Dickins wrote:
> On Tue, 9 Feb 2021, Johannes Weiner wrote:
>
> > Page writeback doesn't hold a page reference, which allows truncate to
> > free a page the second PageWriteback is cleared. This used to require
> > special attention in test_clear
l.c,
and its declarations deleted from include/linux/memcontrol.h?
And further: delete __dec_lruvec_state() and dec_lruvec_state()
from include/linux/vmstat.h - unless you feel that every "inc"
ought to be matched by a "dec", even when unused.
>
> Signed-off-by: Joh
alpha.
>
> Fixes: ea3271f7196c ("tmpfs: support 64-bit inums per-sb")
> Cc: sta...@vger.kernel.org # v5.9+
> Signed-off-by: Seth Forshee
Thanks,
Acked-by: Hugh Dickins
> ---
> fs/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
he mount options and thus passes it in the
> options for the remount.
>
>
> So prevent CONFIG_TMPFS_INODE64 from being selected on s390.
>
> Link:
> https://lkml.kernel.org/r/20210205230620.518245-1-seth.fors...@canonical.com
> Fixes: ea3271f7196c ("tmpfs: support 64
On Fri, 29 Jan 2021, Peter Xu wrote:
>
> Huge & Mike,
>
> Would any of you have comment/concerns on the high-level design of this
> series?
>
> It would be great to know it, especially major objection, before move on to an
> non-rfc version.
Seeing Mike's update prompts me to speak up: I have
020 at 08:33:44PM +, Matthew Wilcox wrote:
> > On Mon, Dec 21, 2020 at 11:56:36AM -0800, Hugh Dickins wrote:
> > > On Mon, 23 Nov 2020, Andrew Morton wrote:
> > > > On Fri, 20 Nov 2020 17:55:22 -0800 syzbot
> > > > wrote:
> > > >
> &g
On Thu, 4 Feb 2021, Michal Hocko wrote:
> On Thu 04-02-21 17:32:20, Christian Koenig wrote:
> > Hi Michal,
> >
> > as requested in the other mail thread the following sample code gets my test
> > system down within seconds.
> >
> > The issue is that the memory allocated for the file descriptor
On Tue, 2 Feb 2021, Axel Rasmussen wrote:
> On Tue, Feb 2, 2021 at 1:03 PM Hugh Dickins wrote:
> > On Tue, 2 Feb 2021, Axel Rasmussen wrote:
> >
> > > For background, mm/userfaultfd.c provides a general mcopy_atomic
> > > implementation. But some types of memo
On Tue, 2 Feb 2021, Axel Rasmussen wrote:
> For background, mm/userfaultfd.c provides a general mcopy_atomic
> implementation. But some types of memory (e.g., hugetlb and shmem) need
> a slightly different implementation, so they provide their own helpers
> for this. In other words, userfaultfd
On Tue, 26 Jan 2021, Will Deacon wrote:
> On Wed, Jan 20, 2021 at 05:36:04PM +, Will Deacon wrote:
> > Hi all,
> >
> > This is version four of the patches I previously posted here:
> >
> > v1: https://lore.kernel.org/r/20201209163950.8494-1-w...@kernel.org
> > v2:
On Sun, 24 Jan 2021, Greg Kroah-Hartman wrote:
> On Sat, Jan 23, 2021 at 03:37:30PM -0800, Hugh Dickins wrote:
> > On Tue, 12 Jan 2021, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 12, 2021 at 03:32:04PM +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Jan 11, 2
On Tue, 12 Jan 2021, Greg Kroah-Hartman wrote:
> On Tue, Jan 12, 2021 at 03:32:04PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Jan 11, 2021 at 7:46 PM Stephan Gerhold wrote:
> > >
> > > Hi,
> > >
> > > since 5.11-rc1 I get kernel crashes with infinite recursion in
> > > device_reorder_to_tail()
nt atomic against
__split_huge_pmd_locked()")
Signed-off-by: Hugh Dickins
Reviewed-by: Andrea Arcangeli
Cc: sta...@vger.kernel.org
---
The status of reuse_swap_page(), and its use on THPs, is currently under
discussion, and may need to be changed: but this patch is a simple fix
to the reported deadloc
On Thu, 14 Jan 2021, Sergey Senozhatsky wrote:
> Hi,
>
> We are running into lockups during the memory pressure tests on our
> boards, which essentially NMI panic them. In short the test case is
>
> - THP shmem
> echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
>
> - And a
On Mon, 11 Jan 2021, Saravana Kannan wrote:
> On Mon, Jan 11, 2021 at 4:44 PM Hugh Dickins wrote:
> > On Mon, 11 Jan 2021, Saravana Kannan wrote:
> > >
> > > Did you see this patch change the organization of devices under
> > > /sys/devices/?
> &g
On Mon, 11 Jan 2021, Saravana Kannan wrote:
> On Mon, Jan 11, 2021 at 3:42 PM Hugh Dickins wrote:
> > On Mon, 11 Jan 2021, Saravana Kannan wrote:
> > >
> > > I happen to have an X1 Carbon (different gen though) lying around and
> > > I poked at i
On Mon, 11 Jan 2021, Saravana Kannan wrote:
>
> I happen to have an X1 Carbon (different gen though) lying around and
> I poked at its /sys folders. None of the devices in the rmi4_smbus are
> considered the grandchildren of the i2c device. I think the real
> problem is
On Mon, 11 Jan 2021, Will Deacon wrote:
> On Fri, Jan 08, 2021 at 11:34:08AM -0800, Linus Torvalds wrote:
> > On Fri, Jan 8, 2021 at 9:15 AM Will Deacon wrote:
> > >
> > > The big difference in this version is that I have reworked it based on
> > > Kirill's patch which he posted as a follow-up to
as we have for page locking, we'd have to change our roughly
> ~50 different writeback functions. Painful.
>
> Instead, just make "wait_on_page_writeback()" loop on the very unlikely
> situation that the PG_writeback bit is still set, basically re-instating
> the old behavior. T
On Mon, 11 Jan 2021, Thierry Reding wrote:
> On Sun, Jan 10, 2021 at 08:44:13PM -0800, Hugh Dickins wrote:
> >
> > Synaptics RMI4 SMBus touchpad on ThinkPad X1 Carbon (5th generation)
> > fails to suspend when running 5.11-rc kernels: bisected to
> > 5b6164d3465f (&q
On Mon, 11 Jan 2021, Rafael J. Wysocki wrote:
> On Mon, Jan 11, 2021 at 5:44 AM Hugh Dickins wrote:
> >
> > Hi Rafael,
> >
> > Synaptics RMI4 SMBus touchpad on ThinkPad X1 Carbon (5th generation)
> > fails to suspend when running 5.11-rc kernels: bisected
Hi Rafael,
Synaptics RMI4 SMBus touchpad on ThinkPad X1 Carbon (5th generation)
fails to suspend when running 5.11-rc kernels: bisected to
5b6164d3465f ("driver core: Reorder devices on successful probe"),
and reverting that fixes it. dmesg.xz attached, but go ahead and ask
me to switch on a
On Thu, 7 Jan 2021, Vlastimil Babka wrote:
> On 1/4/21 6:03 AM, Hugh Dickins wrote:
> > Boot a CONFIG_MEMCG=y kernel with "cgroup_disabled=memory" and you are
> > met by a series of warnings from the VM_WARN_ON_ONCE_PAGE(!memcg, page)
> > recently added to th
On Wed, 6 Jan 2021, Andrea Arcangeli wrote:
>
> I'd be surprised if the kernel can boot with BUG_ON() defined as "do
> {}while(0)" so I guess it doesn't make any difference.
I had been afraid of that too, when CONFIG_BUG is not set:
but I think it's actually "if (cond) do {} while (0)".
On Wed, 6 Jan 2021, Andrew Morton wrote:
> On Tue, 5 Jan 2021 20:28:27 -0800 (PST) Hugh Dickins wrote:
>
> > Alex, please consider why the authors of these lines (whom you
> > did not Cc) chose to write them without BUG_ON(): it has always
> > been preferre
On Sat, 12 Dec 2020, Alex Shi wrote:
>
> I'm very sorry, a typo here. the patch should be updated:
>
> From ed4fa1c6d5bed5766c5f0c35af0c597855d7be06 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Fri, 11 Dec 2020 21:26:46 +0800
> Subject: [PATCH] mm/mmap: replace if (cond) BUG() with
On Tue, 5 Jan 2021, Qian Cai wrote:
> On Tue, 2021-01-05 at 13:35 -0800, Hugh Dickins wrote:
> > This patchset went into mmotm 2020-11-16-16-23, so probably linux-next
> > on 2020-11-17: you'll have had three trouble-free weeks testing with it
> > in, so it's not a likel
t; > > > This patchset followed 2 memcg VM_WARN_ON_ONCE_PAGE patches which were
> > > > added to -mm tree yesterday.
> > > >
> > > > Many thanks for line by line review by Hugh Dickins, Alexander Duyck and
> > > > Johannes Weiner.
&g
On Tue, 5 Jan 2021, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
> wrote:
> > On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> > >
> > > > So the one-liner of changing the "if" to "while" in
> > > >
On Mon, 4 Jan 2021, Linus Torvalds wrote:
> On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton
> wrote:
>
> > Linus, how confident are you in those wait_on_page_bit_common()
> > changes?
>
> Pretty confident. The atomicity of the bitops themselves is fairly simple.
>
> But in the writeback bit?
: but skip if mem_cgroup_disabled().
Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()")
Signed-off-by: Hugh Dickins
---
include/linux/memcontrol.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 5.11-rc2/include/linux/memcontrol.h 2020-12-27 20:39:36.751923135 -0800
+++
Got it at last, sorry it's taken so long.
On Tue, 29 Dec 2020, Kirill A. Shutemov wrote:
> On Tue, Dec 29, 2020 at 01:05:48AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Dec 28, 2020 at 10:47:36AM -0800, Linus Torvalds wrote:
> > > On Mon, Dec 28, 2020 at 4:53 AM Kirill A. Shutemov
> > >
On Sun, 27 Dec 2020, Linus Torvalds wrote:
> On Sun, Dec 27, 2020 at 3:48 PM Kirill A. Shutemov
> wrote:
> >
> > I did what Hugh proposed and it got clear to my eyes. It gets somewhat
> > large, but take a look.
>
> Ok, it's not that much bigger, and the end result is certainly much
> clearer
On Sun, 27 Dec 2020, Damian Tometzki wrote:
> On Sun, 27. Dec 11:38, Linus Torvalds wrote:
> > On Sat, Dec 26, 2020 at 6:38 PM Hugh Dickins wrote:
> > >
> > > This patch (like its antecedents) moves the pte_unmap_unlock() from
> > > after do_fault_around()'
On Sat, 26 Dec 2020, Hugh Dickins wrote:
> On Sun, 27 Dec 2020, Kirill A. Shutemov wrote:
> >
> > Here's the fixup I have so far. It doesn't blow up immediately, but please
> > take a closer look. Who knows what stupid mistake I did this time. :/
>
> It's been running
On Sun, 27 Dec 2020, Kirill A. Shutemov wrote:
>
> Here's the fixup I have so far. It doesn't blow up immediately, but please
> take a closer look. Who knows what stupid mistake I did this time. :/
It's been running fine on x86_64 for a couple of hours (but of course
my testing is deficient, in
On Sat, 26 Dec 2020, Kirill A. Shutemov wrote:
> On Sat, Dec 26, 2020 at 09:57:13AM -0800, Linus Torvalds wrote:
> > Because not only does that get rid of the "if (page)" test, I think it
> > would make things a bit clearer. When I read the patch first, the
> > initial "next_page()" call confused
On Tue, 22 Dec 2020, Kirill A. Shutemov wrote:
>
> Updated patch is below.
>
> From 0ec1bc1fe95587350ac4f4c866d6482383740b36 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Sat, 19 Dec 2020 15:19:23 +0300
> Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
>
>
1 - 100 of 4042 matches
Mail list logo
