On Wed, 11 Jun 2025 14:06:51 +0200 David Hildenbrand wrote:
> While working on improving vm_normal_page() and friends, I stumbled
> over this issues: refcounted "normal" pages must not be marked
> using pmd_special() / pud_special().
Why is this?
>
> ...
>
> I spent too much time trying to get
On Mon, 9 Jun 2025 12:06:07 + Shivank Garg wrote:
> The mm selftests are timing out with the current 180-second limit.
> Testing shows that run_vmtests.sh takes approximately 11 minutes
> (664 seconds) to complete.
>
> Increase the timeout to 900 seconds (15 minutes) to provide sufficient
>
On Thu, 05 Jun 2025 22:34:31 +0100 Mark Brown wrote:
> Unlike the other cases gup_longterm's memfd tests previously skipped the
> test when failing to set up the file descriptor to test, restore this
> behaviour.
>
> Signed-off-by: Mark Brown
I added a bunch of stuff to this. Please check?
On Thu, 5 Jun 2025 18:48:49 +0200 David Hildenbrand wrote:
> On 05.06.25 18:15, Mark Brown wrote:
> > On Thu, Jun 05, 2025 at 05:00:49PM +0100, Lorenzo Stoakes wrote:
> >
> >> This seems to be causing tests to fail rather than be skipped if hugetlb
> >> isn't configured. I bisected the problem t
On Tue, 3 Jun 2025 02:22:32 +0300 Khaled Elnaggar
wrote:
> The hugevm tests 'charge_reserved_hugetlb.sh' and
> 'hugetlb_reparenting_test.sh'
> depend on the 'write_to_hugetlbfs' binary to simulate writes to hugetlbfs
> while checking reservations asynchronously in the background.
>
> When thi
On Mon, 19 May 2025 19:20:31 +0530 Ujwal Kundur wrote:
> I'm not sure about the protocol here, should I roll a PATCH v4 or a
> new patch entirely?
Those two are the same thing.
I dropped the v3 patch, my inbox eagerly awaits v4, thanks.
On Sun, 4 May 2025 15:18:25 +0530 Ujwal Kundur wrote:
> This patch refactors macros and non-composite global variable
> definitions into a struct that is defined at the start of a test and is
> passed around instead of relying on global vars.
The uffd tests have changed somewhat in the MM devel
On Sat, 3 May 2025 23:46:26 +0530 Ujwal Kundur wrote:
> Thanks for the review and testing!
>
> I'll push a V2 with the indentation fixes soon.
>
> > this deletes the global vars before it deletes
> > the references to them. That's gonna be a real pain for bisections,
> > please can you restruct
On Sun, 27 Apr 2025 15:56:39 +0530 Siddarth G wrote:
> Change the type of 'dwRegionSize' in wp_init() and wp_free()
> from int to long to match callers that pass long or
> unsigned long long values.
>
> wp_addr_range function is left unchanged because it passes
> 'dwRegionSize' parameter directl
On Thu, 17 Apr 2025 11:01:54 -0700 Dan Williams
wrote:
> Darrick J. Wong wrote:
> > On Thu, Apr 10, 2025 at 12:12:33PM -0700, Alison Schofield wrote:
> > > On Thu, Apr 10, 2025 at 11:10:20AM +0200, David Hildenbrand wrote:
> > > > Alison reports an issue with fsdax when large extends end up usin
On Fri, 11 Apr 2025 17:08:33 -0400 Waiman Long wrote:
> > - * A/B/F memory.current = 0
> > + * A/B/C memory.current ~= 29M, memory.events:low > 0
> > + * A/B/D memory.current ~= 21M, memory.events:low > 0
> > + * A/B/E memory.current ~= 0, memory.events:low not specified (==0
> > w/out me
On Sat, 29 Mar 2025 03:30:37 +0530 Siddarth G wrote:
> Cppcheck reported a style warning:
> int result is assigned to long long variable. If the variable is long long
> to avoid loss of information, then you have loss of information.
>
> Changing the type of page_size from 'unsigned int' to 'uns
On Tue, 04 Mar 2025 11:20:53 -0500 Zi Yan wrote:
> Do you mind folding Hugh’s fixes to this patch? Let me know if you prefer
> a V10. Thanks.
I think a new series, please. I'll remove the current version from mm.git.
Can I suggest that you repeat Hugh's testing, hopefully see the same
failures
On Mon, 17 Feb 2025 10:22:44 -0500 Zi Yan wrote:
> >
> > Thanks. The patch below should fix it.
> >
> > I am going to send V8, since
> > 1. there have been 4 fixes so far for V7, a new series would help people
> > review;
> >
> > 2. based on the discussion with you in THP cabal meeting, to
> > c
/math: add Kunit test suite for gcd()"
(https://lkml.kernel.org/r/20250203075400.3431330-1-eleanor...@gmail.com)
in the obvious fashion then added this fixup:
From: Andrew Morton
Subject: lib-math-hook-up-tests-makefile-fix
Date: Sat Feb 8 03:33:59 PM PST 2025
don't link gcd_kunit.o t
On Tue, 4 Feb 2025 22:14:10 -0500 Zi Yan wrote:
> This patchset adds a new buddy allocator like (or non-uniform) large folio
> split to reduce the total number of after-split folios, the amount of memory
> needed for multi-index xarray split, and keep more large folios after a split.
It would b
On Thu, 30 Jan 2025 23:10:53 + Pedro Falcato
wrote:
> On Thu, Jan 30, 2025 at 10:53 PM Lorenzo Stoakes
> wrote:
> >
> > > The above code sequence doesn't seem at all onerous. I'm not
> > > understanding why it's worth altering the kernel to permit this little
> > > shortcut?
> >
> > In pra
On Thu, 30 Jan 2025 20:40:25 + Lorenzo Stoakes
wrote:
> If you wish to utilise a pidfd interface to refer to the current process or
> thread it is rather cumbersome, requiring something like:
>
> int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
>
> ...
>
> close(pidf
On Thu, 9 Jan 2025 22:38:26 +0500 Muhammad Usama Anjum
wrote:
> Recently, I reviewed a patch on the mm/kselftest mailing list about a
> test which had obvious type mismatch fix in it. It was strange why that
> wasn't caught during development and when patch was accepted. This led
> me to discov
On Wed, 15 Jan 2025 17:30:20 + Lorenzo Stoakes
wrote:
> I sort of favour putting hotfixes in quick, but this one has gone in
> quicker than some reviewed hotfixes which we left in unstable... however
> towards the end of a cycle I think Andrew is stuck between a rock and a
> hard place in de
On Tue, 14 Jan 2025 11:21:15 +0800 liuye wrote:
> If name is NULL, a NULL pointer may be accessed in printf.
>
> ...
>
> --- a/tools/testing/selftests/memfd/memfd_test.c
> +++ b/tools/testing/selftests/memfd/memfd_test.c
> @@ -171,7 +171,7 @@ static void mfd_fail_new(const char *name, unsign
On Mon, 13 Jan 2025 14:51:55 +0800 Chen Ridong
wrote:
>
>
> On 2025/1/6 16:45, Vlastimil Babka wrote:
> > On 12/24/24 03:52, Chen Ridong wrote:
> >> From: Chen Ridong
> >
> > +CC RCU
> >
> >> A soft lockup issue was found in the product with about 56,000 tasks were
> >> in the OOM cgroup, i
On Mon, 13 Jan 2025 14:15:38 +0100 Thomas Weißschuh
wrote:
> The virtual_address_range selftest reads from the start of each mapping
> listed in /proc/self/maps.
> However not all mappings are valid to be arbitrarily accessed.
>
> For example the vvar data used for virtual clocks on x86 [vvar_v
On Thu, 9 Jan 2025 09:50:45 -0800 Kees Cook wrote:
> On Thu, Jan 09, 2025 at 10:48:52PM +0500, Muhammad Usama Anjum wrote:
> > For the all other case, why should we keep argv/argc and mark them unused
> > as well when they aren't being used?
>
> I'm fine either way, but my personal code style in
On Wed, 11 Dec 2024 21:12:58 -0500 Luis Felipe Hernandez
wrote:
> Adds test suite for integer based square root function.
>
> The test suite is designed to verify the correctness of the int_sqrt()
> math library function.
>
my x86_64 allmodconfig build says
AR built-in.a
AR vml
On Sun, 10 Nov 2024 12:22:12 +0530 Donet Tom wrote:
> > Fixes: 0268d4579901 ("selftests: hugetlb_dio: check for initial conditions
> > to skip in the start")
>
> ...
>
> Would you prefer I send this fixup patch as a new series, or is it okay as is?
All looks good, thanks. I added cc:stable, be
On Sat, 9 Nov 2024 22:20:01 -0800 Andrew Morton
wrote:
> On Fri, 8 Nov 2024 19:13:04 +0500 Muhammad Usama Anjum
> wrote:
>
> > On 11/8/24 3:49 PM, Donet Tom wrote:
> >
> > > I think below changes are required.
> > >
> > > iff --git a/tools/t
On Fri, 8 Nov 2024 19:13:04 +0500 Muhammad Usama Anjum
wrote:
> On 11/8/24 3:49 PM, Donet Tom wrote:
>
> > I think below changes are required.
> >
> > iff --git a/tools/testing/selftests/mm/hugetlb_dio.c
> > b/tools/testing/selftests/mm/hugetlb_dio.c
> > index 60001c142ce9..4b52106b8124 10064
On Wed, 6 Nov 2024 09:33:55 +0100 Geert Uytterhoeven
wrote:
> Hi all,
> > This conflicts with "[PATCH] m68k: defconfig: Update defconfigs for
> > v6.12-rc1"[1]. Of course the proper way forward would be to add
> > "default KUNIT_ALL_TESTS" to all tests that still lack it, so I can
> > just neve
On Fri, 1 Nov 2024 19:15:57 +0500 Muhammad Usama Anjum
wrote:
> The test should be skipped if initial conditions aren't fulfilled in
> the start instead of failing and outputting non-compliant TAP logs. This
> kind of failure pollutes the results. The initial conditions are:
> - The test should
On Fri, 18 Oct 2024 17:17:21 + Edward Liaw wrote:
> Subject: [PATCH 0/3] selftests/mm: revert pthread_barrier change and
I simply removed the " and".
> Date: Fri, 18 Oct 2024 17:17:21 +
> X-Mailer: git-send-email 2.47.0.105.g07ac214952-goog
>
> On Android arm, pthread_create followed b
On Thu, 17 Oct 2024 12:31:31 +0530 Anshuman Khandual
wrote:
> On 10/15/24 07:32, Nanyong Sun wrote:
> > The mount option of tmpfs should be huge=advise, not madvise
> > which is not supported and may mislead the users.
>
> Agreed.
>
> >
> > Fixes: 1b03d0d558a2 ("selftests/vm: add thp collapse
On Tue, 8 Oct 2024 00:20:43 +0800 I Hsin Cheng wrote:
> > I would recommend updating the patch description slightly, as it's a
> > little bit confusing as-is (partly due to the early version having
> > already been applied and reverted).
>
> No problem, I'll refine the commit message, hoever, I
On Thu, 3 Oct 2024 21:17:09 + Edward Liaw wrote:
> On Android arm, pthread_create followed by a fork caused a deadlock in
> the case where the fork required work to be completed by the created
> thread.
>
> Updated the synchronization primitive to use pthread_barrier instead of
> atomic_boo
On Fri, 27 Sep 2024 16:21:30 +0530 Donet Tom wrote:
> >> Test Result with this patch
> >> ===
> >> # RUN hmm2.hmm2_device_private.double_map ...
> >> #OK hmm2.hmm2_device_private.double_map
> >> ok 53 hmm2.hmm2_device_private.double_map
> >>
>
On Fri, 21 Jun 2024 13:34:44 +0200 Ilya Leoshkevich wrote:
> v6 -> v7: Drop the ptdump patch.
> All patches are reviewed.
I added v7 to mm.git (and hence linux-next).
On Thu, 13 Jun 2024 16:10:12 -0400 Steven Rostedt wrote:
> > And... I'm a bit surprised that forward declarations are allowed in C.
> > A billion years ago I used a C compiler which would use 16 bits for
> > an enum if the enumted values would fit in 16 bits. And it would use 32
> > bits otherw
On Thu, 13 Jun 2024 15:34:02 -0400 Steven Rostedt wrote:
> On Thu, 13 Jun 2024 22:22:18 +0300
> Alexey Dobriyan wrote:
>
> > g++ doesn't like forward enum declarations:
> >
> > error: use of enum ‘E’ without previous declaration
> >64 | enum E;
>
> But we don't care about g++. Do
On Thu, 11 Apr 2024 17:40:02 +0200 Michal Koutný wrote:
> Hello.
>
> On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
> wrote:
> > That seems like a large change.
>
> In what sense is it large?
A large increase in the maximum number of processes. Or did I misinterpret?
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> Please review! Also feel free to take the KVM patches through the mm
> tree, as I don't expect any conflicts.
It's mainly a KVM thing and the MM changes are small and simple.
I'd say that the KVM tree would be a better home?
On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang"
wrote:
> Hi Jonathan,
>
> On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron
> wrote:
> >
> > On Fri, 5 Apr 2024 00:07:05 +
> > "Ho-Ren (Jack) Chuang" wrote:
> >
> > > Since different memory devices require finding, allocating, and pu
On Mon, 8 Apr 2024 16:58:18 +0200 Michal Koutný wrote:
> The kernel provides mechanisms, while it should not imply policies --
> default pid_max seems to be an example of the policy that does not fit
> all. At the same time pid_max must have some value assigned, so use the
> end of the allowed r
On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma
wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in the
On Tue, 12 Mar 2024 20:20:17 + "Verma, Vishal L"
wrote:
> > All of these WARN_ON_ONCE() usages should be replaced with
> > lockdep_assert_held() and lockdep_assert_held_write() where appropriate.
>
> Makes sense - I can send a patch post -rc1 to change these if that's okay
> Andrew?
Pleas
On Mon, 19 Feb 2024 02:35:20 -0500 "Michael S. Tsirkin" wrote:
> On Sun, Feb 18, 2024 at 09:06:18PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d37e1e4c52bc Add linux-next specific files for 20240216
> > git tree: linux-next
> > con
On Sat, 17 Feb 2024 16:18:10 +0800 Changbin Du wrote:
> The synchronization here is just to ensure the module init's been freed
> before doing W+X checking. But the commit 1a7b7d922081 ("modules: Use
> vmalloc special flag") moves do_free_init() into a global workqueue
> instead of call_rcu(). So
On Wed, 24 Jan 2024 12:03:45 -0800 Vishal Verma
wrote:
> This series adds sysfs ABI to control memmap_on_memory behavior for DAX
> devices.
Thanks. I'll add this to mm-unstable for some additional testing, but
I do think we should have the evidence of additional review on this
series's four pr
On Wed, 17 Jan 2024 06:16:36 + Chen Zhongjin
wrote:
> There is a deadlock scenario in kprobe_optimizer():
>
> pid A pid B pid C
> kprobe_optimizer()do_exit() perf_kprobe_init()
> mutex_lock(&kprobe_mutex) exit_tasks_rcu
On Tue, 19 Dec 2023 22:12:31 +0800 Changbin Du wrote:
> The commit 1a7b7d922081 ("modules: Use vmalloc special flag") moves
> do_free_init() into a global workqueue instead of call_rcu(). So now
> we should wait it via flush_work().
What are the runtime effects of this change?
On Mon, 11 Dec 2023 19:26:40 -0800 Bixuan Cui wrote:
> -TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
> +TRACE_EVENT(mm_vmscan_lru_shrink_inactive_start,
Current kernels have a call to trace_mm_vmscan_lru_shrink_inactive() in
evict_folios(), so this renaming broke the build.
odule
> search path can be extended by a space separated list of paths passed
> to the
> lx-symbols command.
>
> Note how that talks about a "space separated list of paths" for which
> clearly a single path seems like it should be accepted?
>
> > @@
On Fri, 21 Jul 2023 14:15:31 +1000 Alistair Popple wrote:
> Thanks for this Huang, I had been hoping to take a look at it this week
> but have run out of time. I'm keen to do some testing with it as well.
Thanks. I'll queue this in mm-unstable for some testing. Detailed
review and testing woul
Link:
https://lkml.kernel.org/r/1669972991-246-1-git-send-email-ruansy.f...@fujitsu.com
Signed-off-by: Shiyang Ruan
Cc: Alistair Popple
Cc: Dan Williams
Cc: Darrick J. Wong
Cc: Dave Chinner
Cc: Jason Gunthorpe
Cc: John Hubbard
Signed-off-by: Andrew Morton
---
fs/dax.c | 12 ++-
On Thu, 1 Dec 2022 15:58:11 -0800 "Darrick J. Wong" wrote:
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -1092,7 +1092,7 @@ static int dax_iomap_direct_access(const struct iomap
> > *iomap, loff_t pos,
> > }
> >
> > /**
> > - * dax_iomap_cow_copy - Copy the data from source to destination bef
On Tue, 29 Nov 2022 19:59:14 -0800 Dan Williams
wrote:
> [ add Andrew ]
>
> Shiyang Ruan wrote:
> > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > This also effects dax+noreflink mode if we run the test after a
> > dax+reflink test. So, the most urgent thing is so
On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams wrote:
> Jonathan Cameron wrote:
> > On Wed, 7 Sep 2022 18:07:31 -0700
> > Dan Williams wrote:
> >
> > > Andrew Morton wrote:
> > > > I really dislike the term "flush". Sometimes it means writeb
I really dislike the term "flush". Sometimes it means writeback,
sometimes it means invalidate. Perhaps at other times it means
both.
Can we please be very clear in comments and changelogs about exactly
what this "flush" does. With bonus points for being more specific in the
function naming?
On Wed, 6 Jul 2022 10:47:32 +0800 Muchun Song wrote:
> > If this wakeup is not one of these, then are there reports from the
> > softlockup detector?
> >
> > Do we have reports of processes permanently stuck in D state?
> >
>
> No. The task is in an TASK_INTERRUPTIBLE state (see
> __fuse_dax_b
On Wed, 6 Jul 2022 00:38:41 +0100 Matthew Wilcox wrote:
> On Tue, Jul 05, 2022 at 02:18:19PM -0700, Andrew Morton wrote:
> > On Tue, 5 Jul 2022 20:35:32 +0800 Muchun Song
> > wrote:
> >
> > > FSDAX page refcounts are 1-based, rather than 0-based: if refcoun
On Tue, 5 Jul 2022 20:35:32 +0800 Muchun Song wrote:
> FSDAX page refcounts are 1-based, rather than 0-based: if refcount is
> 1, then the page is freed. The FSDAX pages can be pinned through GUP,
> then they will be unpinned via unpin_user_page() using a folio variant
> to put the page, howeve
Unless there be last-minute objections, I plan to move this series into
the non-rebasing mm-stable branch a few days from now.
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote:
> This is a combination of two patchsets:
> 1.fsdax-rmap:
> https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
> 2.fsdax-reflink:
> https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fuj
On Thu, 2 Jun 2022 10:18:09 -0700 "Darrick J. Wong" wrote:
> On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote:
> > Hi,
> >
> > Is there any other work I should do with these two patchsets? I think they
> > are good for now. So... since the 5.19-rc1 is coming, could the
> > notify_f
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote:
> On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> > wrote:
> >
> > > > It'll need to be a stable branch somewhere, b
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
wrote:
> > It'll need to be a stable branch somewhere, but I don't think it
> > really matters where al long as it's merged into the xfs for-next
> > tree so it gets filesystem test coverage...
>
> So how about let the notify_failure() bits go thr
On Thu, 31 Mar 2022 11:55:47 -0400 Qian Cai wrote:
> On Fri, Mar 18, 2022 at 03:45:23PM +0800, Muchun Song wrote:
> > This series is based on next-20220225.
> >
> > Patch 1-2 fix a cache flush bug, because subsequent patches depend on
> > those on those changes, there are placed in this series.
On Mon, 28 Feb 2022 14:35:34 +0800 Muchun Song wrote:
> The devmap pages can not use page_vma_mapped_walk() to check if a huge
> devmap page is mapped into a vma. Add support for walking huge devmap
> pages so that DAX can use it in the next patch.
>
x86_64 allnoconfig:
In file included from
On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
wrote:
> @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
> for (j = 0; j < MAX_ORDER; ++j)
> ttm_pool_type_fini(&pool->caching[i].orders[j]);
> }
> +
> + /* We remove
On Thu, 15 Apr 2021 12:23:55 +0200 Christophe Leroy
wrote:
> > +* is done. STRICT_MODULE_RWX may require extra work to support this
> > +* too.
> > +*/
> >
> > - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> > GFP_KERNEL,
> > -
On Sun, 11 Apr 2021 15:17:56 -0700 Randy Dunlap wrote:
> Fix various kernel-doc warnings in lib/ due to missing or
> erroneous function names.
> Add kernel-doc for some function parameters that was missing.
> Use kernel-doc "Return:" notation in earlycpio.c.
>
> Quietens the following warnings:
On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas
wrote:
> Hi Andrew,
>
> On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
> > wrote:
> > > Looks like my patch "kasan: fix KASAN_STACK
On Fri, 9 Apr 2021 08:44:39 +0200 Greg Kroah-Hartman
wrote:
> On Thu, Apr 08, 2021 at 10:05:02PM -0700, Andrew Morton wrote:
> > On Thu, 8 Apr 2021 15:06:05 +0200 Gioh Kim wrote:
> >
> > > As the name shows, it checks if strings are equal in case insensitive
> >
arvesting mailing lists.
>
> But I will appreciate it if somebody can run this through various build tests.
>
um, did you try x86_64 allmodconfig?
I'm up to
kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix.patch
and counting.
From: Andrew Morton
Subject: kernelh
On Wed, 07 Apr 2021 22:38:37 +0200 Oscar Salvador wrote:
> On 2021-04-06 22:28, Oscar Salvador wrote:
> > Heh, it seems I spaced out today.
> >
> > We need a few things on top:
> >
>
Yes please.
On Thu, 8 Apr 2021 09:11:30 +0200 Oscar Salvador wrote:
> But if It is going to be easier for Andrew, just pull them all out and I
> will resend the whole series once this work goes in.
I think so.
I shall drop these:
mmpage_alloc-bail-out-earlier-on-enomem-in-alloc_contig_migrate_range.patch
On Thu, 8 Apr 2021 15:06:05 +0200 Gioh Kim wrote:
> As the name shows, it checks if strings are equal in case insensitive
> manner.
Peh. Who would die if we simply made sysfs_streq() case-insensitive?
On Thu, 8 Apr 2021 14:26:58 +0800 Tian Tao wrote:
> Remove including that don't need it.
>
Um, how can version.c possibly not include version.h?
Sure, it may obtain access to version.h via some other include, but
that's plain luck and nonsense. And it's unreliable and it requires
whichever-h
On Thu, 8 Apr 2021 16:43:18 -0700 Axel Rasmussen
wrote:
> The idea is that it will apply cleanly to akpm's tree, *replacing* the
> following
> patches (i.e., drop these first, and then apply this series):
>
> userfaultfd-support-minor-fault-handling-for-shmem.patch
> userfaultfd-support-minor
On Fri, 9 Apr 2021 11:17:49 +0800 Miaohe Lin wrote:
> On 2021/4/9 7:25, Mike Kravetz wrote:
> > On 4/2/21 2:32 AM, Miaohe Lin wrote:
> >> A rare out of memory error would prevent removal of the reserve map region
> >> for a page. hugetlb_fix_reserve_counts() handles this rare case to avoid
> >> d
On Wed, 7 Apr 2021 14:28:21 -0700 Nick Desaulniers
wrote:
> On Wed, Apr 7, 2021 at 2:21 PM Andrew Morton
> wrote:
> >
> > On Wed, 7 Apr 2021 11:54:55 -0700 Nick Desaulniers
> > wrote:
> >
> > > LLVM changed the expected function signature for
> >
On Wed, 7 Apr 2021 11:54:55 -0700 Nick Desaulniers
wrote:
> LLVM changed the expected function signature for
> llvm_gcda_emit_function() in the clang-11 release. Users of clang-11 or
> newer may have noticed their kernels producing invalid coverage
> information:
>
> $ llvm-cov gcov -a -c -u
On Mon, 5 Apr 2021 20:22:26 -0700 Davidlohr Bueso wrote:
> On Mon, 05 Apr 2021, Andrew Morton wrote:
>
> >Tricky. 339ddb53d373 was merged in December 2019. So do we backport
> >this fix? Could any userspace code be depending upon the
> >post-339ddb53d373 behavio
On Sat, 3 Apr 2021 14:31:43 +0200 Uladzislau Rezki wrote:
> >
> > We may need to replaced that kcalloc() with kmvalloc() though...
> >
> Yep. If we limit to USHRT_MAX, the maximum amount of memory for
> internal data would be ~12MB. Something like below:
>
> diff --git a/lib/test_vmalloc.c b/li
On Mon, 5 Apr 2021 16:10:25 -0700 Davidlohr Bueso wrote:
> 339ddb53d373 (fs/epoll: remove unnecessary wakeups of nested epoll) changed
> the userspace visible behavior of exclusive waiters blocked on a common
> epoll descriptor upon a single event becoming ready. Previously, all tasks
> doing ep
On Mon, 5 Apr 2021 02:16:25 +0800 kernel test robot wrote:
> Hi Andrey,
>
> First bad commit (maybe != root cause):
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 2023a53bdf41b7646b1d384b6816af06309f73a5
> commit: 5d92bdffd2d53f98de683229c0ad7
On Wed, 31 Mar 2021 20:35:02 -0700 Roman Gushchin wrote:
> On Thu, Apr 01, 2021 at 11:31:16AM +0800, Miaohe Lin wrote:
> > On 2021/4/1 11:01, Muchun Song wrote:
> > > Christian Borntraeger reported a warning about "percpu ref
> > > (obj_cgroup_release) <= 0 (-1) after switching to atomic".
> > >
On Fri, 2 Apr 2021 15:03:37 +0800 Stillinux wrote:
> In the case of high system memory and load pressure, we ran ltp test
> and found that the system was stuck, the direct memory reclaim was
> all stuck in io_schedule, the waiting request was stuck in the blk_plug
> flow of one process, and this
On Fri, 2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)"
wrote:
> By using this parameter we can specify how many workers are
> created to perform vmalloc tests. By default it is one CPU.
> The maximum value is set to 1024.
>
> As a result of this change a 'single_cpu_test' one becomes
> ob
On Thu, 1 Apr 2021 12:50:31 +0300 Andy Shevchenko
wrote:
> > I normally don't have a lot of material for asm-generic either, half
> > the time there are no pull requests at all for a given release. I would
> > expect future changes to the bitmap implementation to only need
> > an occasional bugf
On Thu, 1 Apr 2021 19:09:43 +0800 Wan Jiabing wrote:
> checkdeclares: find struct declared more than once.
> Inspired by checkincludes.pl.
> This script checks for duplicate struct declares.
> Note that this will not take into consideration macros, so
> you should run this only if you know you d
On Thu, 1 Apr 2021 21:22:48 +0800 Qiheng Lin wrote:
> Fix the following W=1 kernel build warning(s):
> mm/vmalloc.c:425: warning: expecting prototype for vunmap_range_noflush().
> Prototype was for vunmap_range() instead
>
> ...
>
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -413,7 +413,7 @@
On Thu, 1 Apr 2021 10:26:36 -0400 Pavel Tatashin
wrote:
> On Wed, Mar 31, 2021 at 12:38 PM Mike Rapoport wrote:
> >
> > From: Mike Rapoport
> >
> > The renaming of PF_MEMALLOC_NOCMA to PF_MEMALLOC_PIN missed one occurrence
> > in mm/hugetlb.c which causes build error:
> >
> > CC mm/huge
On Thu, 1 Apr 2021 23:30:10 +0100 Sergei Trofimovich wrote:
> Before the change page_owner recursion was detected via fetching
> backtrace and inspecting it for current instruction pointer.
> It has a few problems:
> - it is slightly slow as it requires extra backtrace and a linear
> stack sca
On Wed, 31 Mar 2021 09:44:47 +0100 Sergei Trofimovich wrote:
> ia64 has two stacks:
> - memory stack (or stack), pointed at by by r12
> - register backing store (register stack), pointed at
> ar.bsp/ar.bspstore with complications around dirty
> register frame on CPU.
>
> In https://bugs.gent
On Wed, 31 Mar 2021 22:45:12 +0800 Muchun Song wrote:
>
> Hi Andrew,
>
> Now we have two choices to fix this issue.
>
> 1) Send a v6 patchset (Use obj_cgroup APIs to charge kmem pages)
> to fix this issue.
> 2) Send a separate fix patch (Just like above).
>
> Both ways are ok for me. But
On Wed, 31 Mar 2021 16:49:27 +0200 Michal Hocko wrote:
> > Thanks for the clarification! I have suspected this to be the case but
> > I am not really familiar with the interface to have any strong statement
> > here. Maybe we want to document this explicitly.
>
> Btw. Andrew the patch still seem
On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
> From: jun qian
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, found
> that the vm_normal_pa
On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
wrote:
> Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> that was merged into 5.12-rc causes a build time warning:
>
> include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> defined, evaluates to 0 [-Wundef]
On Tue, 30 Mar 2021 10:58:43 +0200 David Hildenbrand wrote:
> >
> > MAINTAINERS| 1 +
> > arch/alpha/include/uapi/asm/mman.h | 3 +
> > arch/mips/include/uapi/asm/mman.h | 3 +
> > arch/parisc/include/uapi/asm/mman.h| 3 +
> >
On Tue, 30 Mar 2021 09:52:26 -0500 "Gustavo A. R. Silva"
wrote:
> Fix the following out-of-bounds warnings by enclosing
> structure members file and finder into new struct info:
>
> fs/hfsplus/xattr.c:300:5: warning: 'memcpy' offset [65, 80] from the object
> at 'entry' is out of the bounds of
1 - 100 of 11143 matches
Mail list logo
