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
very alloc/free operation.
>
> v2: rework the commit message to make clear why we need this
Acked-by: Andrew Morton
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
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.
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 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 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 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
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 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 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, 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, 27 Apr 2016 16:48:13 +0900 Minchan Kim wrote:
> Recently, I got many reports about perfermance degradation in embedded
> system(Android mobile phone, webOS TV and so on) and easy fork fail.
>
> The problem was fragmentation caused by zram and GPU driver mainly.
> With memory pressure, th
On Fri, 10 May 2019 19:53:23 + "Kuehling, Felix"
wrote:
> From: Philip Yang
>
> While the page is migrating by NUMA balancing, HMM failed to detect this
> condition and still return the old page. Application will use the new
> page migrated, but driver pass the old page physical address to
On Fri, 24 May 2019 09:44:55 -0300 Jason Gunthorpe wrote:
> Now that -mm merged the basic hmm API skeleton I think running like
> this would get us quickly to the place we all want: comprehensive in tree
> users of hmm.
>
> Andrew, would this be acceptable to you?
Sure. Please take care not to
On Tue, 26 Mar 2019 12:47:39 -0400 jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> (Andrew this apply on top of my HMM patchset as otherwise you will have
> conflict with changes to mm/hmm.c)
>
> Changes since v5:
> - drop KVM bits waiting for KVM people to express interest if they
>
On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple line
On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini
wrote:
> Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
> and FIELD_SIZEOF which are used to calculate the size of a member of
> structure, so to bring uniformity in entire kernel source tree lets use
> FIELD_SIZEOF and r
On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote:
> >> to FIELD_SIZEOF
> >
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members. So this is an opportunity to switch everything to
> > a new member_sizeof().
> >
> > What do people think of that and
On Thu, 13 Jun 2019 14:24:20 -0600 Logan Gunthorpe wrote:
>
>
> On 2019-06-13 2:21 p.m., Dan Williams wrote:
> > On Thu, Jun 13, 2019 at 1:18 PM Logan Gunthorpe wrote:
> >>
> >>
> >>
> >> On 2019-06-13 12:27 p.m., Dan Williams wrote:
> >>> On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wro
On Fri, 28 Jun 2019 12:14:44 -0700 Dan Williams
wrote:
> I believe -mm auto drops patches when they appear in the -next
> baseline. So it should "just work" to pull it into the series and send
> it along for -next inclusion.
Yup. Although it isn't very "auto" - I manually check that the patch
On Fri, 5 Jul 2019 13:14:35 +1000 Stephen Rothwell
wrote:
> > I checked next-20190704 tag.
> >
> > I see the empty file
> > drivers/gpu/drm/i915/oa/Makefile
> >
> > Did someone delete it?
>
> Commit
>
> 5ed7a0cf3394 ("drm/i915: Move OA files to separate folder")
>
> from the drm-intel tre
On Thu, 04 Jul 2019 22:22:41 -0700 Joe Perches wrote:
> > So when comparing a zero-length file with a non-existent file, diff
> > produces no output.
>
> Why use the -N option ?
>
> $ diff --help
> [...]
> -N, --new-file treat absent files as empty
>
> otherwise
>
> $ cd $(
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 01 Aug 2019 22:34:16 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204407
>
> Bug ID: 204407
>Summary: Bad page stat
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 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
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, 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 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, 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 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 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
(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 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 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 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 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 Wed, 6 Nov 2019 09:24:18 -0800 Kees Cook wrote:
> > Since this is -mm can I have a stable sha1 or something for
> > referencing? Or do you want to include this in the -mm patch bomb for
> > the merge window?
>
> Traditionally these things live in akpm's tree when they are fixes for
> patches
On Mon, 9 Dec 2019 21:53:00 -0800 John Hubbard wrote:
> > Correction: this is somehow missing the fixes that resulted from Jan Kara's
> > review (he
> > noted that we can't take a page lock in this context). I must have picked
> > up the
> > wrong version of it, when I rebased for -rc1.
> >
>
different from struct vm_area_struct::vm_page_prot. (Michal Hocko)
> > Changes since v3:
> > *) More documentation regarding under which conditions it's safe to use a
> > page protection different from struct vm_area_struct::vm_page_prot. This
> > time also in
On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote:
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
>
> ...
>
> Ack for merging through drm trees very much appreciated.
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
> it never gets freed.
>
> Free it in dma_buf_release().
>
> ...
>
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -108,6 +108,7 @@ static int dma_buf
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:
> > >
> > >
> > >
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 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 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
(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 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
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 Tue, 14 Jan 2020 12:15:08 -0800 John Hubbard wrote:
> >
> > Hi Andrew and all,
> >
> > To clarify: I'm hoping that this series can go into 5.6.
> >
> > Meanwhile, I'm working on tracking down and solving the problem that Leon
> > reported, in the "track FOLL_PIN pages" patch, and that patch
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 01 Oct 2019 17:06:35 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=205065
>
> Bug ID: 205065
>Summary: workqueue: P
On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call, without an
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
> Hi Peter,
>
> Iirc you've been involved at least somewhat in discussing this. -mm folks
> are a bit undecided whether these new non_block semantics are a good idea.
> Michal Hocko still is in support, but And
On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook wrote:
> > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> >
> > Andrew, could you take a look and give your Acked-by or pick them up
> > directly?
>
> Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> via Andrew? I
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This wi
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 m
On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko wrote:
> > I continue to struggle with this. It introduces a new kernel state
> > "running preemptibly but must not call schedule()". How does this make
> > any sense?
> >
> > Perhaps a much, much more detailed description of the oom_reaper
> > s
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 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 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 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 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 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 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 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 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, 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 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 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
) does
> not. So, teach track_pfn_insert() and untrack_pfn() how to handle
> tracking without a vma, and arrange for devm_memremap_pages() to
> establish the write-back-cache reservation in the memtype tree.
Acked-by: Andrew Morton
I'll grab [2/2].
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 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 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 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 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
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 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
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, 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, 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 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 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 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 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
I'm not sure what's happened to the drm code in linux-next - it's
exploding all over the place. Did someone turn on -Werror without
doing anywhere near enough testing?
Anyway, I don't know how to fix this i386 build error:
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init':
driv
On Sat, 23 May 2015 14:30:09 +0100 Damien Lespiau
wrote:
> On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote:
> > I'm not sure what's happened to the drm code in linux-next - it's
> > exploding all over the place. Did someone turn on -Werror without
On Wed, 13 May 2015 15:08:08 +0200 Jan Kara wrote:
> Provide new function get_vaddr_frames(). This function maps virtual
> addresses from given start and fills given array with page frame numbers of
> the corresponding pages. If given start belongs to a normal vma, the function
> grabs reference
On Wed, 1 Jun 2016 08:21:09 +0900 Minchan Kim wrote:
> Recently, I got many reports about perfermance degradation in embedded
> system(Android mobile phone, webOS TV and so on) and easy fork fail.
>
> The problem was fragmentation caused by zram and GPU driver mainly.
> With memory pressure, th
On Mon, 6 Jun 2016 21:20:56 +0900 Masahiro Yamada wrote:
> The use of config_enabled() against config options is ambiguous.
> In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
> but the author might have used it for the meaning of IS_ENABLED().
> Using IS_ENABLED(), IS_BUILTIN(
On Fri, 6 Jun 2014 10:22:51 -0700 "Paul E. McKenney" wrote:
> On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote:
> > From: Behalf Of Ken Helias
> > > All other add functions for lists have the new item as first argument and
> > > the
> > > position where it is added as second argument
ing to do here?
And it's quite infuriating to go BUG when the code could easily warn
and fix it up.
And it's quite infuriating to go BUG because one of the bits was set,
but not tell us which bit it was!
Could the slab guys please review this?
From: Andrew Morton
Subject: slab: improve
On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter
wrote:
> On Tue, 11 Nov 2014, Andrew Morton wrote:
>
> > There's no point in doing
> >
> > #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> >
> > because __GF
On Wed, 12 Nov 2014 09:44:19 +0900 Joonsoo Kim
wrote:
> >
> > And it's quite infuriating to go BUG when the code could easily warn
> > and fix it up.
>
> If user wants memory on HIGHMEM, it can be easily fixed by following
> change because all memory is compatible for HIGHMEM. But, if user wan
On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote:
> On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > But anyway - Luke, please attach your .config to
> > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
>
> Done: https://bugzilla.kernel.org/att
On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim
wrote:
> On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> > On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote:
> >
> > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > &
On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov" wrote:
> On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph L
On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa wrote:
> Andrew Morton wrote:
> > Poor ttm guys - this is a bit of a trap we set for them.
>
> Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid
> deadlock.\")
> changed to use sc-&
1 - 100 of 238 matches
Mail list logo
