From: "Mike Rapoport (IBM)"
There are several architectures that duplicate definitions of
map_page_into_agp(), unmap_page_from_agp() and flush_agp_cache().
Define those in asm-generic/agp.h and use it instead of duplicated
per-architecture headers.
Signed-off-by: Mike Rapoport (IBM)
From: "Mike Rapoport (IBM)"
There is a copy of alloc_gatt_pages() and free_gatt_pages in several
architectures in arch/$ARCH/include/asm/agp.h. All the copies do exactly
the same: alias alloc_gatt_pages() to __get_free_pages(GFP_KERNEL) and
alias free_gatt_pages() to free_pages(
From: "Mike Rapoport (IBM)"
Hi,
asm/agp.h is duplicated in several architectures, with x86 being the
only instance that differs from the rest.
Introduce asm-generic/agp.h and use it instead of per-architecture
headers for the most cases.
I believe that asm-generic is the best tree
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
&
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > vm_flags are among VMA attributes which affect decisions like VMA merging
> > and splitting. Therefore all vm_flags modifications are performed a
ump_mm() function.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> mm/debug.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9d3d893dc7f4..96d594e16292 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
t
> vm_flags modification attempts.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 5 -
> arch/s390/mm/gmap.c| 5 -
> mm/khugepaged.c| 2 ++
> mm/ksm.c
On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in suc
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by:
vm_area_struct *vma,
> + unsigned long flags)
I'd suggest to make it vm_flags_init() etc.
Except that
Acked-by: Mike Rapoport (IBM)
> +{
> + vma->vm_flags = flags;
> +}
> +
> +/* Use when VMA is part of the VMA tree
On Mon, Jan 23, 2023 at 04:36:25AM +, Matthew Wilcox wrote:
> On Sat, Jan 21, 2023 at 11:03:05AM -0400, Jason Gunthorpe wrote:
> > I would like to have a session at LSF to talk about Matthew's
> > physr discussion starter:
> >
> > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infra
On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley
wrote:
>On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
>> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
>> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
>> > wrote:
>> > > I don't think that using the extra variable mak
On Fri, Oct 15, 2021 at 10:27:17AM +0200, Vlastimil Babka wrote:
> On 10/14/21 12:16, Mike Rapoport wrote:
> > On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
> >> On 10/14/21 10:54, kernel test robot wrote:
> >>
> >> In my local testi
[ 319.147926][ T259] BUG: unable to handle page fault for address:
> > 0ec74110
> > [ 319.149309][ T259] #PF: supervisor read access in kernel mode
> > [ 319.150362][ T259] #PF: error_code(0x) - not-present page
> > [ 319.151372][ T259] *pde =
> > [ 3
On Thu, Apr 22, 2021 at 02:08:51PM +, peter.enderb...@sony.com wrote:
> On 4/22/21 10:06 AM, Mike Rapoport wrote:
> > So the flow is like this:
> >
> > * a user has a problem and reports it to an application developer; at best
> > the user runs simple and limit
On Wed, Apr 21, 2021 at 05:35:57PM +, peter.enderb...@sony.com wrote:
> On 4/21/21 5:31 PM, Mike Rapoport wrote:
> > On Wed, Apr 21, 2021 at 10:37:11AM +, peter.enderb...@sony.com wrote:
> >> On 4/21/21 11:15 AM, Daniel Vetter wrote:
> >>> We need to understa
On Wed, Apr 21, 2021 at 10:37:11AM +, peter.enderb...@sony.com wrote:
> On 4/21/21 11:15 AM, Daniel Vetter wrote:
> >
> > We need to understand what the "correct" value is. Not in terms of kernel
> > code, but in terms of semantics. Like if userspace allocates a GL texture,
> > is this supposed
On Tue, Apr 20, 2021 at 10:45:21AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 11:41 AM, Mike Rapoport wrote:
> > Hello Peter,
> >
> > On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> >> On 4/20/21 10:58 AM, Daniel Vetter wrote:
&g
Hello Peter,
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is no
On Tue, Apr 20, 2021 at 09:04:51AM +0200, Michal Hocko wrote:
> On Mon 19-04-21 18:37:13, Christian König wrote:
> > Am 19.04.21 um 18:11 schrieb Michal Hocko:
> [...]
> > > The question is not whether it is NUMA aware but whether it is useful to
> > > know per-numa data for the purpose the counter
MA"
> instead, such that user configuration and dependencies are respected.
>
> v1 -> v2:
> - Fix DRM_CMA -> DMA_CMA
>
> Cc: Joel Stanley
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Jeffery
> Cc: Lucas Stach
> Cc: Russell King
> Cc:
On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
On Thu, Apr 08, 2021 at 11:20:10AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
On Tue, Oct 27, 2020 at 01:17:18PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> When allocating an array of elements, users should check for
> multiplication overflow or preferably use one of the provided helpers
> like: kmalloc_array().
>
> There's no krealloc_array() count
From: Mike Rapoport
The only in-tree user for mbx driver for Intel 2700G graphics chip was
cm-x270 platform. Since this platform was removed by the commit
9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards") there is no
point to keep the obsolete framebuffer driver.
Signed-of
On Tue, Jul 21, 2020 at 03:00:41PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: Andy Shevchenko
> >Sent: Tuesday, July 21, 2020 10:47 AM
> >To: Ruhl, Michael J
> >Cc: dri-devel@lists.freedesktop.org; Andrew Morton >foundation.org>; M
On Tue, Jul 07, 2020 at 11:04:13AM -0700, Randy Dunlap wrote:
> Drop the doubled word "the".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Andrew Morton
> Cc: linux...@kvack.org
Reviewed-by: Mike Rapoport
&
On Tue, Jun 23, 2020 at 11:52:58AM +0200, Mauro Carvalho Chehab wrote:
> The nommu-mmap.txt file provides description of user visible
> behaviuour. So, move it to the admin-guide.
>
> As it is already at the ReST, also rename it.
>
> Suggested-by: Mike Rapoport
> Suggeste
entry code, the comment /* must be last! */ is stale...
@Peter, @Thomas, can you comment please?
>From e51d50ee6f4d1f446decf91c2c67230da14ff82c Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 4 Jun 2020 12:37:03 +0300
Subject: [PATCH] softirq: don't call lockdep_hardirq_exit() t
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> With linux-next on sparc I too see the spinlock issue; something like:
>
> ...
> Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139
> lock: 0xf53ef350,
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> >>
> >
> > Actually it occurs to me that the patch consolidatin
Hello Mauro,
On Fri, May 01, 2020 at 05:37:55PM +0200, Mauro Carvalho Chehab wrote:
> There are a number of random documents that seem to be
> describing some aspects of the core-api. Move them to such
> directory, adding them at the core-api/index.rst file.
>
> Signed-off-by: Mauro Carvalho Cheh
FOLL_PIN
>
> * For pages that are received via FOLL_PIN, those pages must be returned
> via put_user_page().
>
> Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
> in this documentation. (I've reworded it and expanded upon it.)
>
> Reviewe
On Tue, Nov 05, 2019 at 11:00:06AM -0800, John Hubbard wrote:
> On 11/5/19 5:10 AM, Mike Rapoport wrote:
> ...
> >> ---
> >> Documentation/vm/index.rst | 1 +
> >> Documentation/vm/pin_user_pages.rst | 212 ++
> >
> >
On Sun, Nov 03, 2019 at 01:18:00PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() varia
Hi Souptick,
On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> Just thought to take opinion for documentation before placing it in v3.
> Does it looks fine ?
Overall looks good to me. Several minor points below.
> +/**
> + * __vm_insert_range - insert range of ke
On Thu, Feb 07, 2019 at 09:37:08PM +0530, Souptick Joarder wrote:
> On Thu, Feb 7, 2019 at 9:27 PM Mike Rapoport wrote:
> >
> > Hi Souptick,
> >
> > On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote:
> > > Hi Mike,
> > >
> > >
On Thu, Jan 31, 2019 at 03:43:39PM +0530, Souptick Joarder wrote:
> On Thu, Jan 31, 2019 at 2:09 PM Mike Rapoport wrote:
> >
> > On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > >
On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be gener
On Mon, Dec 03, 2018 at 03:18:17PM -0500, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, r
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping rang
On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be gener
On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote:
> On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
> >
> > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > > Hi Mike,
> > >
> > > On Sat, Nov 17, 20
On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
> >
> > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > > On Fri, Nov 16, 2018 at
On Thu, Nov 15, 2018 at 09:15:30PM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be gener
ed, but I rather not
> if we just want to delete them anyway.
>
> As a starting point, remove all index-files and references to 00-INDEX and
> see where the discussion is going.
For the Documentation/vm
Acked-by: Mike Rapoport
> Again, sorry for the insanely wide distributi
bugfs.c: In function
âvirtio_gpu_debugfs_irq_infoâ:
drivers/gpu/drm/virtio/virtgpu_debugfs.c:39:6: warning: format â%ldâ
expects argument of type âlong intâ, but argument 3 has type âlong long
intâ [-Wformat=]
vgdev->fence_drv.sync_seq);
^
Signed-off-by: Mike Rapopor
47 matches
Mail list logo
