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
m() 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
>
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
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: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:
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)
> ---
&
rea_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 and modif
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
On Tue, Mar 16, 2021 at 10:08:10AM +0100, David Hildenbrand wrote:
> On 16.03.21 09:58, Liang, Liang (Leo) wrote:
> > [AMD Public Use]
> >
> > Hi David,
> >
> > root@scbu-Chachani:~# cat /proc/mtrr
> > reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
> > reg01:
iginal Message-
> From: David Hildenbrand
> Sent: Monday, March 15, 2021 9:04 PM
> To: Mike Rapoport
> Cc: Liang, Liang (Leo) ; Deucher, Alexander
> ; linux-ker...@vger.kernel.org; amd-gfx list
> ; Andrew Morton ;
> Huang, Ray ; Koenig, Christian ;
> Rafael J. Wysocki ;
Hi,
On Sat, Mar 13, 2021 at 10:05:23AM +0100, David Hildenbrand wrote:
> > Am 13.03.2021 um 05:04 schrieb Liang, Liang (Leo) :
> >
> > Hi David,
> >
> > Which benchmark tool you prefer? Memtest86+ or else?
>
> Hi Leo,
>
> I think you want something that runs under Linux natively.
>
> I‘m
iro.
The userfault patches usually go via -mm tree, not sure if Al looks at them :)
FWIW, you can add
Reviewed-by: Mike Rapoport
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index ae0b8b5f69e6..c2be36a168ca 100644
> > --- a/fs/userfaultfd.c
> &g
12 matches
Mail list logo
