On Wed, 25 Jun 2025 14:18:28 + "Kasireddy, Vivek"
wrote:
> > Cool, thanks, I'll paste that into the changelog ;)
> >
> > So if this code path is rare but expected and normal, should we be
> > emitting this warning at all?
> I think it would be OK to drop the warning. Otherwise, Syzbot would
On Thu, 19 Jun 2025 05:30:52 + "Kasireddy, Vivek"
wrote:
> Hi Andrew, Anshuman,
>
> > Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if
> > there
> > are no resv
> >
> > On Wed, 18 Jun 2025 12:14:49 +0530 Anshuman Khandual
> > wrote:
> >
> > > > Therefore, prevent
hat can be reclaimed,
> by the shrinker.
>
Acked-by: Andrew Morton
can be reclaimed,
> by the shrinker.
>
Reviewed-by: Andrew Morton
On Wed, 18 Jun 2025 12:14:49 +0530 Anshuman Khandual
wrote:
> > Therefore, prevent the above crash by replacing the VM_BUG_ON()
> > with WARN_ON_ONCE() as there is no need to crash the system in
> > this situation and instead we could just warn and fail the
> > allocation.
>
> Why there are no
On Fri, 6 Jun 2025 06:14:06 + "Kasireddy, Vivek"
wrote:
> > Also, patch [2/3] addresses a BUG which was introduced into 6.12.
> > Presumably we want to backport the fix into -stable? If so, it's
> > better to present this as a standalone patch, including the cc:stable
> > tag. This is beca
On Tue, 20 May 2025 22:19:35 -0700 Vivek Kasireddy
wrote:
> Currently, hugetlb_reserve_pages() returns a bool to indicate whether
> the reservation map update for the range [from, to] was successful or
> not. This is not sufficient for the case where the caller needs to
> determine how many entr
On Tue, 3 Jun 2025 19:29:49 -0700 Jakub Kicinski wrote:
> > I think the i915 driver is doing something it shouldn't with these
> > objects. They seem to be initialized more than once, which could lead
> > to leaked ref_tracker objects. It would be good for one of the i915
> > maintainers to comme
On Thu, 13 Mar 2025 11:43:15 + Alessandro Carminati
wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
I've had
On Fri, 28 Mar 2025 16:14:55 -0600 Shuah Khan wrote:
> On 3/13/25 16:05, Andrew Morton wrote:
> > On Thu, 13 Mar 2025 11:31:12 -0700 Guenter Roeck wrote:
> >
> >> On Thu, Mar 13, 2025 at 06:24:25PM +0100, Maxime Ripard wrote:
> >>>>
> >>>>
On Thu, 13 Mar 2025 11:31:12 -0700 Guenter Roeck wrote:
> On Thu, Mar 13, 2025 at 06:24:25PM +0100, Maxime Ripard wrote:
> > >
> > > Yeah, as with my prior review, I'm a fan of this. It makes a bunch of my
> > > very noisy tests much easier to deal with.
> >
> > And for the record, we're also a
convert timeouts to secs_to_jiffies()
> https://git.kernel.org/mkp/scsi/c/a131f20804d6
Really, an acked-by would have been much easier all around, but whatever.
Did you get my fix?
From: Andrew Morton
Subject: scsi-lpfc-convert-timeouts-to-secs_to_jiffies-fix
Date: Tue Feb 25 07:32:03 PM PST 202
On Wed, 26 Feb 2025 11:29:53 + Mark Brown wrote:
> On Tue, Feb 25, 2025 at 08:17:14PM +, Easwar Hariharan wrote:
> > This is the second series (part 1*) that converts users of
> > msecs_to_jiffies() that
> > either use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1000) or
On Mon, 10 Feb 2025 20:37:45 +0100 David Hildenbrand wrote:
> The single "real" user in the tree of make_device_exclusive_range() always
> requests making only a single address exclusive. The current implementation
> is hard to fix for properly supporting anonymous THP / large folios and
> for av
On Mon, 10 Feb 2025 20:37:42 +0100 David Hildenbrand wrote:
> Against mm-hotfixes-stable for now.
>
> Discussing the PageTail() call in make_device_exclusive_range() with
> Willy, I recently discovered [1] that device-exclusive handling does
> not properly work with THP, making the hmm-tests sel
On Mon, 3 Feb 2025 10:39:58 +0200 "Kirill A. Shutemov"
wrote:
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 4fe551037bf7..98493443d120 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -1605,8 +1605,9 @@ static void folio_end_reclaim_write(struct folio
> > *folio)
> >
On Tue, 28 Jan 2025 18:21:45 + Easwar Hariharan
wrote:
> This is the second series (part 1*) that converts users of msecs_to_jiffies()
> that
> either use the multiply pattern of either of:
> - msecs_to_jiffies(N*1000) or
> - msecs_to_jiffies(N*MSEC_PER_SEC)
>
> where N is a constant or an
On Tue, 14 Jan 2025 00:08:00 -0800 Vivek Kasireddy
wrote:
> There are cases when we try to pin a folio but discover that it has
> not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
> but there is a chance that we might encounter a crash/failure
> (VM_BUG_ON(!h->resv_huge_pages
On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan
wrote:
> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace
On Tue, 10 Dec 2024 18:41:29 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > > I'll just grab everything and see if anyone complains ;)
> > >
> > > I may, if this leads to a conflict :(
> >
> > Ve
On Tue, 10 Dec 2024 17:35:48 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > > I have the same question as before: How do you expect these to land?
> > > Do you now have a maintainer who will take all of them?
> > > Or do y
On Tue, 10 Dec 2024 22:02:31 + Easwar Hariharan
wrote:
> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.
Thanks, I added this to mm.git. I suppressed the usual added-to-mm
emails because s many cc's!
I'd ask rele
On Tue, 10 Dec 2024 15:14:22 -0800 Jeff Johnson
wrote:
> On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> > This is a series that follows up on my previous series to introduce
> > secs_to_jiffies() and convert a few initial users.[1] In the review for
> > that series, Anna-Maria requested conver
On Fri, 1 Nov 2024 13:54:04 -0300 Maíra Canal wrote:
> This series introduces four patches related to the kernel parameters
> controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
> in the file `mm/huge_memory.c`.
Thanks. I extracted [1/1] from the series, as the first patch
On Wed, 23 Oct 2024 16:39:43 -0700 Matthew Brost
wrote:
> Part of series [1]. Sending as individual patch ahead of that series as
> this is a prerequisite for merging.
That's news to me - singleton patches are perfectly OK?
On Wed, 23 Oct 2024 16:39:44 -0700 Matthew Brost
wrote:
> Implement
On Thu, 24 Oct 2024 01:50:34 + Matthew Brost
wrote:
> > On Wed, 23 Oct 2024 16:39:44 -0700 Matthew Brost
> > wrote:
> >
> > > Implement migrate_device_pfns to prepare an array of PFNs for migration.
> > > Handles non-contiguous ranges of device pages that require migration.
> >
> > OK, t
On Mon, 26 Aug 2024 10:30:54 +0800 Yafang Shao wrote:
> Hello Andrew,
>
> Could you please apply this series to the mm tree ?
Your comment in
https://lkml.kernel.org/r/CALOAHbA5VDjRYcoMOMKcLMVR0=zwtz5fbtvqzexi6w8we9j...@mail.gmail.com
led me to believe that a v8 is to be sent?
On Wed, 14 Aug 2024 09:57:31 +0300 Jani Nikula wrote:
> > Removing a nested include exposes all those sites which were
> > erroneously depending upon that nested include. Here's what I have
> > found so far, there will be more.
>
> Right. I didn't hit them with the configs I tried... though I w
On Tue, 13 Aug 2024 15:12:35 +0300 Jani Nikula wrote:
> The fault-inject.h users across the kernel need to add a lot of #ifdef
> CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make
> fault-inject.h self-contained for CONFIG_FAULT_INJECTION=n, and add
> stubs for DECLARE_FAULT_ATT
On Mon, 29 Jul 2024 10:37:08 +0800 Yafang Shao wrote:
> Is it appropriate for you to apply this to the mm tree?
There are a couple of minor conflicts against current 6.11-rc1 which
you'd best check. So please redo this against current mainline?
On Fri, 5 Jul 2024 15:55:23 -0700 Andrew Morton
wrote:
> On Fri, 5 Jul 2024 22:11:14 + "Kasireddy, Vivek"
> wrote:
>
> > Hi Andrew and SJ,
> >
> > >
> > > >
> > > > I didn't look deep into the patch, so unsure if
On Fri, 5 Jul 2024 22:11:14 + "Kasireddy, Vivek"
wrote:
> Hi Andrew and SJ,
>
> >
> > >
> > > I didn't look deep into the patch, so unsure if that's a valid fix,
> > > though.
> > > May I ask your thoughts?
> >
> > Perhaps we should propagate the errno which was returned by
> > try_grab
On Fri, 5 Jul 2024 13:48:25 -0700 SeongJae Park wrote:
> > + * memfd_pin_folios() - pin folios associated with a memfd
> [...]
> > + for (i = 0; i < nr_found; i++) {
> > + /*
> > +* As there can be multiple entries for a
> >
On Tue, 2 Jul 2024 09:13:35 +0200 Christian König
wrote:
> yes that is
> intentionally a define and not an inline function.
>
> See this patch here which changed that:
>
> commit 2c321f3f70bc284510598f712b702ce8d60c4d14
> Author: Suren Baghdasaryan
> Date: Sun Apr 14 19:07:31 2024 -0700
>
On Thu, 13 Jun 2024 10:30:39 +0800 Yafang Shao wrote:
> In kstrdup(), it is critical to ensure that the dest string is always
> NUL-terminated. However, potential race condidtion can occur between a
> writer and a reader.
>
> Consider the following scenario involving task->comm:
>
> reader
On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" wrote:
> On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote:
> > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"
On Tue, 6 Feb 2024 09:45:18 +0530 Anshuman Khandual
wrote:
> cma_get_name() just returns cma->name without any additional transformation
> unlike other helpers such as cma_get_base() and cma_get_size(). This helper
> is not worth the additional indirection, and can be dropped after replacing
>
On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" wrote:
> > > Fixing this will require a bit of an API change, and prefeably sorting out
> > > the hwpoison story for pages vs folio and where it is placed in the shmem
> > > API. For now use this one liner to disable large folios.
> > >
> > >
On Wed, 10 Jan 2024 10:21:07 +0100 Christoph Hellwig wrote:
> Hi all,
>
> Darrick reported that the fairly new XFS xfile code blows up when force
> enabling large folio for shmem. This series fixes this quickly by disabling
> large folios for this particular shmem file for now until it can be f
On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
>
> ...
>
> --- a/include/linux/math.h
> +++ b/include/linux/math.h
> @@ -155,6 +155,13 @@ __STRUCT_FRACT(u32)
> __builtin_types_compatible_p(typeof
On Wed, 7 Jun 2023 13:53:10 -0700 Mike Kravetz wrote:
> >
> > BUGs aren't good. Can we please find a way to push this along?
> >
> > Have we heard anything from any udmabuf people?
> >
>
> I have not heard anything. When this issue popped up, it took me by surprise.
>
> udmabuf maintainer
On Tue, 16 May 2023 15:34:40 -0700 Mike Kravetz wrote:
> On 05/15/23 10:04, Mike Kravetz wrote:
> > On 05/12/23 16:29, Mike Kravetz wrote:
> > > On 05/12/23 14:26, James Houghton wrote:
> > > > On Fri, May 12, 2023 at 12:20 AM Junxiao Chang
> > > > wrote:
> > > >
> > > > This alone doesn't fix
On Thu, 30 Mar 2023 21:53:03 + David Laight wrote:
> > But wouldn't all these issues be addressed by simply doing
> >
> > #define is_power_of_2(n) (n != 0 && ((n & (n - 1)) == 0))
> >
> > ?
> >
> > (With suitable tweaks to avoid evaluating `n' more than once)
>
> I think you need to use t
On Thu, 30 Mar 2023 13:42:39 +0300 Jani Nikula wrote:
> is_power_of_2() only works for types <= sizeof(unsigned long) and it's
> also not a constant expression. There are a number of places in kernel
> where is_power_of_2() is called on u64, which fails on 32-bit
> builds. Try to remedy that. Whi
On Wed, 15 Mar 2023 18:44:56 +0100 Matthieu Baerts
wrote:
> +Closes: https://example.com/issues/1234
I (and a few others) have been using "Addresses:" on occasion. I think
"Addresses:" is a bit more general. And more humble - "I tried to fix
it", not "there, I fixed it".
But whatever
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
> Hi all,
>
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
So to clarify, the intent here is a simple readability cleanup for
exi
On Wed, 30 Nov 2022 16:22:50 -0800 Dan Williams
wrote:
> I think since there is no urgent need for this series to move forward in
> v6.2 I can take the time to kill the need for pfn_to_pgmap_offset() and
> circle back for this in v6.3.
I'll drop v3 of "Fix the DAX-gup mistake" and "mm/memremap:
On Mon, 28 Nov 2022 09:18:47 +0100 David Hildenbrand wrote:
> > Less chances of things going wrong that way.
> >
> > Just mention in the v2 cover letter that the first patch was added to
> > make it easy to backport that fix without being hampered by merge
> > conflicts if it was added after you
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this s
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this s
On Wed, 28 Sep 2022 22:01:22 +1000 Alistair Popple wrote:
> @@ -1401,22 +1494,7 @@ static int dmirror_device_init(struct dmirror_device
> *mdevice, int id)
>
> static void dmirror_device_remove(struct dmirror_device *mdevice)
> {
> - unsigned int i;
> -
> - if (mdevice->devmem_chunks
On Mon, 25 Jul 2022 21:22:06 -0500 "Sierra Guiza, Alejandro (Alex)"
wrote:
> >> a) add the || to the end of the previous line
> >> b) indent such the we have a nice-to-read alignment
> >>
> >> if (!list_empty(&movable_page_list) || isolation_error_count ||
> >> coherent_pages)
> >>
> > I mi
On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
> > /*
> > * Try to move out any movable page before pinning the range.
> > */
> > @@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned
> > long nr_pages,
> >
On Thu, 14 Jul 2022 09:56:19 +0800 kernel test robot wrote:
> lib/maple_tree.c:1522:52: warning: Parameter 'gaps' can be declared with
> const [constParameter]
> lib/maple_tree.c:1871:21: warning: Array index 'split' is used before limits
> check. [arrayIndexThenCheck]
> lib/maple_tree.c:2033:5
On Thu, 30 Jun 2022 00:15:06 +0200 David Hildenbrand wrote:
> On 30.06.22 00:08, Felix Kuehling wrote:
> > On 2022-06-29 03:33, David Hildenbrand wrote:
> >> On 29.06.22 05:54, Alex Sierra wrote:
> >>> is_pinnable_page() and folio_is_pinnable() were renamed to
> >>> is_longterm_pinnable_page() an
On Wed, 29 Jun 2022 11:59:26 +0200 David Hildenbrand wrote:
> On 29.06.22 05:54, Alex Sierra wrote:
> > With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> > device-managed anonymous pages that are not LRU pages. Although they
> > behave like normal pages for purposes of mapping in C
On Wed, 29 Jun 2022 18:08:40 -0400 Felix Kuehling
wrote:
> >
> > I'd have called it "is_longterm_pinnable_page", but I am not a native
> > speaker, so no strong opinion :)
>
> I think only the patch title has the name backwards. The code uses
> is_longterm_pinnable_page.
Patch title was quite
On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra wrote:
> This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
> for current 5.18.0
I plan to move this series into the non-rebasing mm-stable branch in a
few days. Unless sternly told not to do so!
On Tue, 31 May 2022 10:56:23 -0500 Alex Sierra wrote:
> new ioctl cmd added to query zone device type. This will be
> used once the test_hmm adds zone device coherent type.
>
> @@ -1026,6 +1027,15 @@ static int dmirror_snapshot(struct dmirror *dmirror,
> return ret;
> }
>
> +static int
On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke wrote:
> This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t
> i.e. a u64, which makes the shift without a cast of the LHS fishy.
Ah, of course, thanks. I remember 32 bits ;)
--- a/mm/shmem.c~mm-shmemc-suppress-shift-warning
On Thu, 26 May 2022 05:35:20 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next
> specific files for 20220525
>
> Error/Warning reports:
>
> ...
>
>
On Wed, 18 May 2022 20:41:27 -0700 Guenter Roeck wrote:
> On 5/18/22 17:55, kernel test robot wrote:
> > tree/branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next
> > specific files for 2
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
hm, that's my third `bad page' report in three emails. But I'm not
seeing a pattern - this one might be a DRM thing.
On Tue, 12 Apr 2022 20:52:18 + bugzilla-dae...@kernel.org wrote:
> https://
On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote:
> Sometimes you might want to use MAP_POPULATE to ask a device driver to
> initialize the device memory in some specific manner. SGX driver can use
> this to request more memory by issuing ENCLS[EAUG] x86 opcode for each
> page in the addr
On Thu, 27 Jan 2022 17:20:40 -0600 "Sierra Guiza, Alejandro (Alex)"
wrote:
> Andrew,
> We're somehow new on this procedure. Are you referring to rebase this
> patch series to
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> <5.17-rc1 tag>?
No, against current Linus mainli
On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like
> MEMORY_DEVICE_PRIVATE.
Some more reviewer input a
On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka wrote:
> >> Then we have to figure out how to order a fix between DRM and mmotm...
> >
> > That is the question! The problem exists only in the merge of the
> > two. On current DRM side stack_depot_init() exists but it's __init and
> > does not
On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote:
> > To what other uses will this infrastructure be put?
> >
> > Because I must ask: if this feature is for one single computer which
> > presumably has a custom kernel, why add it to mainline Linux?
>
> Well, it certainly isn't just "one
On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
> With MEMORY_DEVICE_COHERENT
very alloc/free operation.
>
> v2: rework the commit message to make clear why we need this
Acked-by: Andrew Morton
On Wed, 16 Jun 2021 20:59:27 +1000 Alistair Popple wrote:
> This is my series to add support for SVM atomics in Nouveau
Can we please have a nice [0/n] overview for this patchset?
On Mon, 24 May 2021 23:27:22 +1000 Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that memory. This
> requires CPU page tables to be updated to deny access whilst atomic
> operations are occurring.
>
>
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
Looks like a recent regression?
Begin forwarded message:
Date: Thu, 11 Feb 2021 14:27:43 +
From: bugzilla-dae...@bugzilla.kernel.org
To: a...@linux-foundation.org
Subject: [Bug 211707] New: BUG: unable to handle page fault for address:
a147bdf6b91d
https://bugzilla.kernel.org/show_bug.
I'm not sure who this belongs to...
Begin forwarded message:
Date: Sat, 06 Feb 2021 01:49:51 +
From: bugzilla-dae...@bugzilla.kernel.org
To: a...@linux-foundation.org
Subject: [Bug 211587] New: X: page allocation failure: order:8,
mode:0x190dc2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_ZERO|__GFP_NOM
On Wed, 18 Nov 2020 11:57:44 +0100 Christian König
wrote:
> Am 06.11.20 um 23:48 schrieb Andrew Morton:
> > On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König"
> > wrote:
> >
> >> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args...&quo
On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König"
wrote:
> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
> adds a workaround for a bug in mmap_region.
>
> As the comment states ->mmap() callback can change
> vma->vm_file and so we might call fput() on the wrong file.
>
> Revert th
On Fri, 9 Oct 2020 17:03:37 +0200 "Christian König"
wrote:
> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
> adds a workaround for a bug in mmap_region.
>
> As the comment states ->mmap() callback can change
> vma->vm_file and so we might call fput() on the wrong file.
>
> Revert th
On Mon, 5 Oct 2020 14:47:47 -0300 Jason Gunthorpe wrote:
> Andrew please let me know if you need a resend
Andrew is rather confused.
Can we please identify the minimal patch(es) which are needed for 5.9
and -stable?
___
dri-devel mailing list
dri-dev
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It was
On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams
wrote:
> > I think I am missing some important pieces. Bear with me.
>
> No worries, also bear with me, I'm going to be offline intermittently
> until at least mid-September. Hopefully Joao and/or Vishal can jump in
> on this discussion.
Ordinari
On Sun, 02 Aug 2020 22:03:46 -0700 Dan Williams
wrote:
> Make the device-dax 'size' attribute writable to allow capacity to be
> split between multiple instances in a region. The intended consumers of
> this capability are users that want to split a scarce memory resource
> between device-dax an
On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
wrote:
> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> >resource_size_t base,
> >
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
wrote:
> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
>
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is une
On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> > >
> > > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > > sparc 32 bit...
> > >
> > > Its a long shot but could you try reverting this patch?
> > >
> > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers provide
ase report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Ira Weiny
Signed-off-by: Andrew Morton
---
arch/sparc/include/asm/highmem.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
a/arch/sparc/include/asm/highm
On Thu, 7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote:
> parisc reimplements the kmap calls except to flush it's dcache. This is
> arguably an abuse of kmap but regardless it is messy and confusing.
>
> Remove the duplicate code and have parisc define
> ARCH_HAS_FLUSH_ON_KUNMAP for a kunm
On Thu, 30 Apr 2020 22:38:10 -0400 John Dorminy wrote:
> the change
> description refers to PROT_KERNEL, which is a symbol which does not
> appear to exist; perhaps PAGE_KERNEL was meant?
Yes, thanks, fixed.
___
dri-devel mailing list
dri-devel@lists.f
On Sun, 26 Apr 2020 23:33:02 -0700 Joe Perches wrote:
> On Mon, 2020-04-27 at 07:57 +0200, Sam Ravnborg wrote:
> > Hi Joe.
>
> Hi Sam.
>
> > On Sun, Apr 26, 2020 at 10:40:52PM -0700, Joe Perches wrote:
> > > .yaml files can contain maintainer/author addresses and it seems
> > > unlikely or unne
On Mon, 2 Mar 2020 15:03:29 -0800 Andrew Morton
wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 02 Mar 2020 21:55:10 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
> > https://bugzilla.ke
On Thu, 19 Mar 2020 11:20:44 +0100 Thomas Hellström (VMware)
wrote:
> On 3/19/20 12:27 AM, Andrew Morton wrote:
> > On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware)
> > wrote:
> >
> >>> ___
> >&g
On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware)
wrote:
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> Andrew, would it be possible to have an ack for
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 02 Mar 2020 21:55:10 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206697
>
> --- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
> C
On Tue, 3 Dec 2019 14:22:32 +0100 Thomas Hellström (VMware)
wrote:
> From: Thomas Hellstrom
>
> For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
> and -page table entries, introduce vma_is_special_huge() that takes the
> same codepaths as vma_is_dax().
>
> The use of "
On Tue, 3 Dec 2019 14:22:31 +0100 Thomas Hellström (VMware)
wrote:
> In order to save TLB space and CPU usage this patchset enables huge- and giant
> page-table entries for TTM and TTM-enabled graphics drivers.
Have these savings been measured? They shouild be, please. And
documented in this
On Tue, 3 Dec 2019 14:22:33 +0100 Thomas Hellström (VMware)
wrote:
> We currently only do COW and write-notify on the PTE level, so if the
> huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
> split the huge pages and page-table entries. Also do this for huge PUDs
> if there is no hu
On Fri, 28 Feb 2020 14:08:04 +0100 Thomas Hellström (VMware)
wrote:
> I'm wondering what's the best way here to get the patches touching mm
> reviewed and accepted?
> While drm people and VMware internal people have looked at them, I think
> the huge_fault() fallback splitting and the introduc
On Thu, 27 Feb 2020 13:38:03 -0800 Cong Wang wrote:
> On Tue, Feb 25, 2020 at 5:54 PM Andrew Morton
> wrote:
> >
> > On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang
> > wrote:
> >
> > > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set
>
On Wed, 26 Feb 2020 10:36:26 +0100 Daniel Vetter wrote:
> On Wed, Feb 26, 2020 at 5:29 AM Sumit Semwal wrote:
> >
> > Hello Andrew,
> >
> >
> > On Wed, 26 Feb 2020 at 07:25, Andrew Morton
> > wrote:
> > >
> > >
> > >
1 - 100 of 248 matches
Mail list logo
