Hi Folks,
On Tue, Apr 20, 2021 at 12:18 PM Roman Gushchin wrote:
>
> On Mon, Apr 19, 2021 at 06:44:02PM -0700, Shakeel Butt wrote:
> > Proposal: Provide memory guarantees to userspace oom-killer.
> >
> > Background:
> >
> > Issues with kernel oom-killer:
> > 1. Very conservative and prefer to
On Wed, Apr 7, 2021 at 12:23 PM Linus Torvalds
wrote:
>
> On Wed, Apr 7, 2021 at 11:47 AM Mikulas Patocka wrote:
> >
> > So, we fixed it, but we don't know why.
> >
> > Peter Xu's patchset that fixed it is here:
> > https://lore.kernel.org/lkml/20200821234958.7896-1-pet...@redhat.com/
>
> Yeah,
On Wed, Apr 7, 2021 at 9:07 AM Linus Torvalds
wrote:
>
> On Wed, Apr 7, 2021 at 6:22 AM Vlastimil Babka wrote:
> >
> > 1) Ignore the issue (outside of Android at least). The security model of
> > zygote
> > is unusual. Where else a parent of fork() doesn't trust the child, which is
> > the
> >
On Thu, Apr 1, 2021 at 4:47 PM Peter Xu wrote:
>
> Hi, Suren,
>
> On Thu, Apr 01, 2021 at 12:43:51PM -0700, Suren Baghdasaryan wrote:
> > On Thu, Apr 1, 2021 at 11:59 AM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Apr 1, 2021 at 11:17 AM Suren Bagh
On Thu, Apr 1, 2021 at 12:38 PM Greg KH wrote:
>
> On Thu, Apr 01, 2021 at 11:17:37AM -0700, Suren Baghdasaryan wrote:
> > From: Kirill Tkhai
> >
> > Add an optimization for KSM pages almost in the same way that we have
> > for ordinary anonymous pages. If th
On Thu, Apr 1, 2021 at 11:59 AM Linus Torvalds
wrote:
>
> On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan wrote:
> >
> > We received a report that the copy-on-write issue repored by Jann Horn in
> > https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 i
From: Nadav Amit
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read in mwriteprotect_range() and defers flushes, and
since there is insufficient consideration of concurrent
From: Shaohua Li
Patch series "userfaultfd: write protection support", v6.
Overview
The uffd-wp work was initialized by Shaohua Li [1], and later continued by
Andrea [2]. This series is based upon Andrea's latest userfaultfd tree,
and it is a continuous works from both Shaohua and
From: Linus Torvalds
Commit 09854ba94c6a ("mm: do_wp_page() simplification") reorganized all
the code around the page re-use vs copy, but in the process also moved
the final unlock_page() around to after the wp_page_reuse() call.
That normally doesn't matter - but it means that the
From: Kirill Tkhai
Add an optimization for KSM pages almost in the same way that we have
for ordinary anonymous pages. If there is a write fault in a page,
which is mapped to an only pte, and it is not related to swap cache; the
page may be reused without copying its content.
[ Note that we do
From: Linus Torvalds
How about we just make sure we're the only possible valid user fo the
page before we bother to reuse it?
Simplify, simplify, simplify.
And get rid of the nasty serialization on the page lock at the same time.
[peterx: add subject prefix]
Signed-off-by: Linus Torvalds
We received a report that the copy-on-write issue repored by Jann Horn in
https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer
coded in vmsplice.c). I confirmed this and also that the issue was not
From: Shaohua Li
Patch series "userfaultfd: write protection support", v6.
Overview
The uffd-wp work was initialized by Shaohua Li [1], and later continued by
Andrea [2]. This series is based upon Andrea's latest userfaultfd tree,
and it is a continuous works from both Shaohua and
From: Nadav Amit
Userfaultfd self-test fails occasionally, indicating a memory corruption.
Analyzing this problem indicates that there is a real bug since mmap_lock
is only taken for read in mwriteprotect_range() and defers flushes, and
since there is insufficient consideration of concurrent
From: Linus Torvalds
Commit 09854ba94c6a ("mm: do_wp_page() simplification") reorganized all
the code around the page re-use vs copy, but in the process also moved
the final unlock_page() around to after the wp_page_reuse() call.
That normally doesn't matter - but it means that the
From: Linus Torvalds
How about we just make sure we're the only possible valid user fo the
page before we bother to reuse it?
Simplify, simplify, simplify.
And get rid of the nasty serialization on the page lock at the same time.
[peterx: add subject prefix]
Signed-off-by: Linus Torvalds
From: Kirill Tkhai
Add an optimization for KSM pages almost in the same way that we have
for ordinary anonymous pages. If there is a write fault in a page,
which is mapped to an only pte, and it is not related to swap cache; the
page may be reused without copying its content.
[ Note that we do
We received a report that the copy-on-write issue repored by Jann Horn in
https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer
coded in vmsplice.c). I confirmed this and also that the issue was not
On Fri, Mar 5, 2021 at 10:23 AM David Hildenbrand wrote:
>
> On 05.03.21 19:08, Suren Baghdasaryan wrote:
> > On Fri, Mar 5, 2021 at 9:52 AM David Hildenbrand wrote:
> >>
> >> On 05.03.21 18:45, Shakeel Butt wrote:
> >>> On Fri, Mar 5
On Fri, Mar 5, 2021 at 9:52 AM David Hildenbrand wrote:
>
> On 05.03.21 18:45, Shakeel Butt wrote:
> > On Fri, Mar 5, 2021 at 9:37 AM David Hildenbrand wrote:
> >>
> >> On 04.03.21 01:03, Shakeel Butt wrote:
> >>> On Wed, Mar 3, 2021 a
On Wed, Mar 3, 2021 at 4:04 PM Shakeel Butt wrote:
>
> On Wed, Mar 3, 2021 at 3:34 PM Suren Baghdasaryan wrote:
> >
> > On Wed, Mar 3, 2021 at 3:17 PM Shakeel Butt wrote:
> > >
> > > On Wed, Mar 3, 2021 at 10:58 AM Suren Baghdasaryan
> > > wro
On Wed, Mar 3, 2021 at 3:17 PM Shakeel Butt wrote:
>
> On Wed, Mar 3, 2021 at 10:58 AM Suren Baghdasaryan wrote:
> >
> > process_madvise currently requires ptrace attach capability.
> > PTRACE_MODE_ATTACH gives one process complete control over another
> > p
On Tue, Mar 2, 2021 at 4:19 PM Suren Baghdasaryan wrote:
>
> On Tue, Mar 2, 2021 at 4:17 PM Andrew Morton
> wrote:
> >
> > On Tue, 2 Mar 2021 15:53:39 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > Hi Andrew,
> > > A friendly reminder to pleas
ASLR metadata
and CAP_SYS_NICE for influencing process performance.
Cc: sta...@vger.kernel.org # 5.10+
Signed-off-by: Suren Baghdasaryan
Reviewed-by: Kees Cook
Acked-by: Minchan Kim
Acked-by: David Rientjes
---
changes in v3
- Added Reviewed-by: Kees Cook
- Created man page
On Tue, Mar 2, 2021 at 4:17 PM Andrew Morton wrote:
>
> On Tue, 2 Mar 2021 15:53:39 -0800 Suren Baghdasaryan
> wrote:
>
> > Hi Andrew,
> > A friendly reminder to please include this patch into mm tree.
> > There seem to be no more questions or objections.
On Mon, Feb 1, 2021 at 9:34 PM Suren Baghdasaryan wrote:
>
> On Thu, Jan 28, 2021 at 11:08 PM Suren Baghdasaryan wrote:
> >
> > On Thu, Jan 28, 2021 at 11:51 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Tue, Jan 26, 2021 at 5:52 AM '
On Wed, Feb 17, 2021 at 11:55 PM Michael Kerrisk (man-pages)
wrote:
>
> Hello Suren,
>
> >> Thanks. I added a few words to clarify this.>
> > Any link where I can see the final version?
>
> Sure:
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man2/process_madvise.2
>
> Also
Hi Michael,
On Sat, Feb 13, 2021 at 2:04 PM Michael Kerrisk (man-pages)
wrote:
>
> Hello Suren,
>
> On 2/2/21 11:12 PM, Suren Baghdasaryan wrote:
> > Hi Michael,
> >
> > On Tue, Feb 2, 2021 at 2:45 AM Michael Kerrisk (man-pages)
> > wrote:
> >
On Wed, Feb 10, 2021 at 10:32 AM Christian König
wrote:
>
>
>
> Am 10.02.21 um 17:39 schrieb Suren Baghdasaryan:
> > On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
> >> On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> >>> On Tue
On Wed, Feb 10, 2021 at 9:21 AM Daniel Vetter wrote:
>
> On Wed, Feb 10, 2021 at 5:39 PM Suren Baghdasaryan wrote:
> >
> > On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
> > >
> > > On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
>
The code looks fine to me. Description needs a bit polishing :)
On Wed, Feb 10, 2021 at 8:26 AM Minchan Kim wrote:
>
> Linux VM is not hard to support PAGE_ALLOC_COSTLY_ODER allocation
> so normally expects driver passes __GFP_NOWARN in that case
> if they has fallback options.
>
> system_heap
On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
>
> On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> > >
> > > On Tue, Feb 9, 2021 at 6:46 PM Christian König
> > > wr
On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
>
> On Tue, Feb 9, 2021 at 6:46 PM Christian König
> wrote:
> >
> >
> >
> > Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan:
> > > On Tue, Feb 9, 2021 at 4:57 AM Christian König
> > > w
On Tue, Feb 9, 2021 at 9:46 AM Christian König wrote:
>
>
>
> Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan:
> > On Tue, Feb 9, 2021 at 4:57 AM Christian König
> > wrote:
> >> Am 09.02.21 um 13:11 schrieb Christian König:
> >>> [SNIP]
> >
On Tue, Feb 9, 2021 at 4:57 AM Christian König wrote:
>
> Am 09.02.21 um 13:11 schrieb Christian König:
> > [SNIP]
> +void drm_page_pool_add(struct drm_page_pool *pool, struct page *page)
> +{
> + spin_lock(>lock);
> + list_add_tail(>lru, >items);
> +
On Fri, Feb 5, 2021 at 12:47 PM John Stultz wrote:
>
> On Fri, Feb 5, 2021 at 12:47 AM Christian König
> wrote:
> > Am 05.02.21 um 09:06 schrieb John Stultz:
> > > diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
> > > new file mode 100644
> > > index
On Fri, Feb 5, 2021 at 1:28 PM Minchan Kim wrote:
>
> On Fri, Feb 05, 2021 at 12:25:52PM -0800, John Hubbard wrote:
> > On 2/5/21 8:15 AM, Minchan Kim wrote:
> > ...
> > > > Yes, approximately. I was wondering if this would suffice at least as a
> > > > baseline:
> > > >
> > > >
On Thu, Feb 4, 2021 at 7:55 AM Alex Deucher wrote:
>
> On Thu, Feb 4, 2021 at 3:16 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 22:41 schrieb Suren Baghdasaryan:
> > > [SNIP]
> > >>> How many semi-unrelated buffer accounting schemes does google
On Thu, Feb 4, 2021 at 5:44 PM Minchan Kim wrote:
>
> On Thu, Feb 04, 2021 at 04:24:20PM -0800, John Hubbard wrote:
> > On 2/4/21 4:12 PM, Minchan Kim wrote:
> > ...
> > > > > Then, how to know how often CMA API failed?
> > > >
> > > > Why would you even need to know that, *in addition* to
On Thu, Feb 4, 2021 at 4:34 PM John Hubbard wrote:
>
> On 2/4/21 4:25 PM, John Hubbard wrote:
> > On 2/4/21 3:45 PM, Suren Baghdasaryan wrote:
> > ...
> >>>>>> 2) The overall CMA allocation attempts/failures (first two items
> >>>>>>
On Thu, Feb 4, 2021 at 3:43 PM Suren Baghdasaryan wrote:
>
> On Thu, Feb 4, 2021 at 3:14 PM John Hubbard wrote:
> >
> > On 2/4/21 12:07 PM, Minchan Kim wrote:
> > > On Thu, Feb 04, 2021 at 12:50:58AM -0800, John Hubbard wrote:
> > >> On 2/3/21 7:50 A
On Thu, Feb 4, 2021 at 3:14 PM John Hubbard wrote:
>
> On 2/4/21 12:07 PM, Minchan Kim wrote:
> > On Thu, Feb 04, 2021 at 12:50:58AM -0800, John Hubbard wrote:
> >> On 2/3/21 7:50 AM, Minchan Kim wrote:
> >>> Since CMA is getting used more widely, it's more important to
> >>> keep monitoring CMA
On Wed, Feb 3, 2021 at 1:25 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 9:29 PM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
> > >
> > > On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter
> > > wrote:
&
On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> >
> > On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> > > Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page wit
On Wed, Feb 3, 2021 at 12:06 AM Christian König
wrote:
>
> Am 03.02.21 um 03:02 schrieb Suren Baghdasaryan:
> > On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim wrote:
> >> On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote:
> >>> Currently system hea
On Tue, Feb 2, 2021 at 5:55 PM Matthew Wilcox wrote:
>
> On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> > Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with
> > WARN_ON_ONCE and returning an error. This is to ensure users of the
&g
On Tue, Feb 2, 2021 at 6:07 PM John Stultz wrote:
>
> On Tue, Feb 2, 2021 at 4:31 PM Suren Baghdasaryan wrote:
> > Currently system heap maps its buffers with VM_PFNMAP flag using
> > remap_pfn_range. This results in such buffers not being accounted
> > for in PSS calcul
On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim wrote:
>
> On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote:
> > Currently system heap maps its buffers with VM_PFNMAP flag using
> > remap_pfn_range. This results in such buffers not being accounted
> > for in
On Tue, Feb 2, 2021 at 5:31 PM Minchan Kim wrote:
>
> On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> > Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with
> > WARN_ON_ONCE and returning an error. This is to ensure users of the
&g
-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io
[2]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html
(sorry, could not find lore links for these discussions)
Suggested-by: Laura Abbott
Signed-off-by: Suren Baghdasaryan
---
v1 posted
tifying drivers that need to clear VM_PFNMAP before
using dmabuf system heap which is moving to use vm_insert_page.
Suggested-by: Christoph Hellwig
Signed-off-by: Suren Baghdasaryan
---
mm/memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.
ted pieces in *madvise(2)*,
> as well as one other question. See below.
>
> On 2/2/21 6:30 AM, Suren Baghdasaryan wrote:
> > Initial version of process_madvise(2) manual page. Initial text was
> > extracted from [1], amended after fix [2] and more details added using
> > man pag
On Tue, Feb 2, 2021 at 12:51 AM Christoph Hellwig wrote:
>
> On Tue, Feb 02, 2021 at 12:44:44AM -0800, Suren Baghdasaryan wrote:
> > On Mon, Feb 1, 2021 at 11:03 PM Christoph Hellwig
> > wrote:
> > >
> > > IMHO the
> > >
&
On Mon, Feb 1, 2021 at 11:03 PM Christoph Hellwig wrote:
>
> IMHO the
>
> BUG_ON(vma->vm_flags & VM_PFNMAP);
>
> in vm_insert_page should just become a WARN_ON_ONCE with an error
> return, and then we just need to gradually fix up the callers that
> trigger it instead of coming up with
On Thu, Jan 28, 2021 at 11:08 PM Suren Baghdasaryan wrote:
>
> On Thu, Jan 28, 2021 at 11:51 AM Suren Baghdasaryan wrote:
> >
> > On Tue, Jan 26, 2021 at 5:52 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Wed 20-01-21 14:17:39, Jann Horn w
/patchwork/patch/1297933/
[2] https://lkml.org/lkml/2020/12/8/1282
[3]
https://patchwork.kernel.org/project/selinux/patch/2021070622.2613577-1-sur...@google.com/#23888311
Signed-off-by: Suren Baghdasaryan
Reviewed-by: Michal Hocko
---
changes in v2:
- Changed description of MADV_COLD per
>
> Again, thanks for the rendered version. As before, I've added my
> comments to the page source.
Hi Michael,
Thanks for reviewing!
>
> On 1/29/21 8:03 AM, Suren Baghdasaryan wrote:
> > Initial version of process_madvise(2) manual page. Initial text was
> > extracted fro
On Thu, Jan 28, 2021 at 11:00 AM Suren Baghdasaryan wrote:
>
> On Thu, Jan 28, 2021 at 10:19 AM Minchan Kim wrote:
> >
> > On Thu, Jan 28, 2021 at 09:52:59AM -0800, Suren Baghdasaryan wrote:
> > > On Thu, Jan 28, 2021 at 1:13 AM Christoph Hellwig
> > > w
On Fri, Jan 29, 2021 at 1:13 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Thu 28-01-21 23:03:40, Suren Baghdasaryan wrote:
> > Initial version of process_madvise(2) manual page. Initial text was
> > extracted from [1], amended after fix [2] and more details added using
> &
On Thu, Jan 28, 2021 at 12:31 PM Michael Kerrisk (man-pages)
wrote:
>
> Hello Suren,
>
> On 1/28/21 7:40 PM, Suren Baghdasaryan wrote:
> > On Thu, Jan 28, 2021 at 4:24 AM Michael Kerrisk (man-pages)
> > wrote:
> >>
> >> Hello Suren,
> >>
> &
On Thu, Jan 28, 2021 at 11:51 AM Suren Baghdasaryan wrote:
>
> On Tue, Jan 26, 2021 at 5:52 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 20-01-21 14:17:39, Jann Horn wrote:
> > > On Wed, Jan 13, 2021 at 3:22 PM Michal Hocko wrote:
> >
/patchwork/patch/1297933/
[2] https://lkml.org/lkml/2020/12/8/1282
[3]
https://patchwork.kernel.org/project/selinux/patch/2021070622.2613577-1-sur...@google.com/#23888311
Signed-off-by: Suren Baghdasaryan
---
changes in v2:
- Changed description of MADV_COLD per Michal Hocko's suggestion
On Thu, Jan 28, 2021 at 12:31 PM Michael Kerrisk (man-pages)
wrote:
>
> Hello Suren,
>
> On 1/28/21 7:40 PM, Suren Baghdasaryan wrote:
> > On Thu, Jan 28, 2021 at 4:24 AM Michael Kerrisk (man-pages)
> > wrote:
> >>
> >> Hello Suren,
> >>
> &
On Tue, Jan 26, 2021 at 5:52 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 20-01-21 14:17:39, Jann Horn wrote:
> > On Wed, Jan 13, 2021 at 3:22 PM Michal Hocko wrote:
> > > On Tue 12-01-21 09:51:24, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 12, 202
On Thu, Jan 28, 2021 at 1:13 AM Christoph Hellwig wrote:
>
> On Thu, Jan 28, 2021 at 12:38:17AM -0800, Suren Baghdasaryan wrote:
> > Currently system heap maps its buffers with VM_PFNMAP flag using
> > remap_pfn_range. This results in such buffers not being accounted
> >
On Thu, Jan 28, 2021 at 12:38 AM Suren Baghdasaryan wrote:
>
> Currently system heap maps its buffers with VM_PFNMAP flag using
> remap_pfn_range. This results in such buffers not being accounted
> for in PSS calculations because vm treats this memory as having no
> page struct
for these discussions)
Suggested-by: Laura Abbott
Signed-off-by: Suren Baghdasaryan
---
drivers/dma-buf/heaps/system_heap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..0e92e42b2251 100644
On Mon, Jan 25, 2021 at 5:19 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 20-01-21 12:23:37, Suren Baghdasaryan wrote:
> [...]
> > MADV_COLD (since Linux 5.4.1)
> > Deactivate a given range of pages by moving them from active to
> > inac
nsistent with other places we do refcounted
vmap/vunmap then feel free to ignore my suggestion.
Thanks!
>
> Best,
> Sumit.
> >
> > Cc: Sumit Semwal
> > Cc: Liam Mark
> > Cc: Laura Abbott
> > Cc: Brian Starkey
> > Cc: Hridya Valsaraju
> > Cc: Suren
behaviors, it follows the rule below.
>
> no_warn gfp_flags
>
> false GFP_KERNEL
> true GFP_KERNEL|__GFP_NOWARN
> gfp & __GFP_NOWARNGFP_KERNEL | (gfp & __GFP_NOWARN)
>
> Signed-
rved_memory
> > > > node by following Rob Herring's suggestion in [1].
> > > >
> > > > [1]
> > > > https://lore.kernel.org/lkml/20191025225009.50305-2-john.stu...@linaro.org/T/#m3dc63acd33fea269a584f43bb799a876f0b2b45d
> > > >
> > >
On Wed, Jan 20, 2021 at 8:57 AM Suren Baghdasaryan wrote:
>
> On Wed, Jan 20, 2021 at 5:18 AM Jann Horn wrote:
> >
> > On Wed, Jan 13, 2021 at 3:22 PM Michal Hocko wrote:
> > > On Tue 12-01-21 09:51:24, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 1
/patchwork/patch/1297933/
[2] https://lkml.org/lkml/2020/12/8/1282
[3]
https://patchwork.kernel.org/project/selinux/patch/2021070622.2613577-1-sur...@google.com/#23888311
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Minchan Kim
---
Adding the plane text version for ease of review:
NAME
On Wed, Jan 20, 2021 at 5:18 AM Jann Horn wrote:
>
> On Wed, Jan 13, 2021 at 3:22 PM Michal Hocko wrote:
> > On Tue 12-01-21 09:51:24, Suren Baghdasaryan wrote:
> > > On Tue, Jan 12, 2021 at 9:45 AM Oleg Nesterov wrote:
> > > >
> > > > On 01/12, Mich
On Tue, Jan 19, 2021 at 9:02 PM James Morris wrote:
>
> On Mon, 11 Jan 2021, Suren Baghdasaryan wrote:
>
> > Replace PTRACE_MODE_ATTACH with a combination of PTRACE_MODE_READ
> > and CAP_SYS_NICE. PTRACE_MODE_READ to prevent leaking ASLR metadata
> > and CAP_SYS_N
On Wed, Jan 13, 2021 at 6:22 AM Michal Hocko wrote:
>
> On Tue 12-01-21 09:51:24, Suren Baghdasaryan wrote:
> > On Tue, Jan 12, 2021 at 9:45 AM Oleg Nesterov wrote:
> > >
> > > On 01/12, Michal Hocko wrote:
> > > >
> > > &
On Mon, Jan 11, 2021 at 11:46 PM Michal Hocko wrote:
>
> On Mon 11-01-21 09:06:22, Suren Baghdasaryan wrote:
> > process_madvise currently requires ptrace attach capability.
> > PTRACE_MODE_ATTACH gives one process complete control over another
> > process. It effectiv
On Tue, Jan 12, 2021 at 9:45 AM Oleg Nesterov wrote:
>
> On 01/12, Michal Hocko wrote:
> >
> > On Mon 11-01-21 09:06:22, Suren Baghdasaryan wrote:
> >
> > > What we want is the ability for one process to influence another process
> > > in order to opt
On Mon, Jan 11, 2021 at 5:22 PM Andrew Morton wrote:
>
> On Mon, 11 Jan 2021 09:06:22 -0800 Suren Baghdasaryan
> wrote:
>
> > process_madvise currently requires ptrace attach capability.
> > PTRACE_MODE_ATTACH gives one process complete control over another
> > p
On Mon, Jan 11, 2021 at 9:05 AM Suren Baghdasaryan wrote:
>
> On Mon, Jan 11, 2021 at 2:20 AM Florian Weimer wrote:
> >
> > * Suren Baghdasaryan:
> >
> > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > index 6a660858784b..c2d600386902 100644
> &g
ASLR metadata
and CAP_SYS_NICE for influencing process performance.
Signed-off-by: Suren Baghdasaryan
Acked-by: Minchan Kim
Acked-by: David Rientjes
---
mm/madvise.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6a660858784b
On Mon, Jan 11, 2021 at 2:20 AM Florian Weimer wrote:
>
> * Suren Baghdasaryan:
>
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 6a660858784b..c2d600386902 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -1197,12 +1197,22 @@ SYSCALL_DEF
On Fri, Jan 8, 2021 at 5:02 PM David Rientjes wrote:
>
> On Fri, 8 Jan 2021, Suren Baghdasaryan wrote:
>
> > > > @@ -1197,12 +1197,22 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd,
> > > > const struct iovec __user *, vec,
> &
On Fri, Jan 8, 2021 at 2:15 PM Minchan Kim wrote:
>
> On Fri, Jan 08, 2021 at 12:58:57PM -0800, Suren Baghdasaryan wrote:
> > process_madvise currently requires ptrace attach capability.
> > PTRACE_MODE_ATTACH gives one process complete control over another
> > process
ASLR metadata
and CAP_SYS_NICE for influencing process performance.
Signed-off-by: Suren Baghdasaryan
---
mm/madvise.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6a660858784b..c2d600386902 100644
--- a/mm/madvise.c
+++ b/mm
Just a couple minor nits.
On Tue, Dec 8, 2020 at 5:29 AM Will Deacon wrote:
>
> Asymmetric systems may not offer the same level of userspace ISA support
> across all CPUs, meaning that some applications cannot be executed by
> some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs
On Tue, Dec 8, 2020 at 5:29 AM Will Deacon wrote:
>
> Asymmetric systems may not offer the same level of userspace ISA support
> across all CPUs, meaning that some applications cannot be executed by
> some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
> not feature support for
On Tue, Dec 22, 2020 at 11:57 PM Christoph Hellwig wrote:
>
> On Tue, Dec 22, 2020 at 09:48:43AM -0800, Suren Baghdasaryan wrote:
> > Thanks for the feedback! The use case is userspace memory reaping
> > similar to oom-reaper. Detailed justification is here:
> > https://
On Tue, Dec 22, 2020 at 9:48 AM Suren Baghdasaryan wrote:
>
> On Tue, Dec 22, 2020 at 5:44 AM Christoph Hellwig wrote:
> >
> > On Fri, Dec 11, 2020 at 09:27:46PM +0100, Jann Horn wrote:
> > > > Can we just use one element in iovec to indicate entire addres
On Tue, Dec 22, 2020 at 5:44 AM Christoph Hellwig wrote:
>
> On Fri, Dec 11, 2020 at 09:27:46PM +0100, Jann Horn wrote:
> > > Can we just use one element in iovec to indicate entire address rather
> > > than using up the reserved flags?
> > >
> > > struct iovec {
> > >
it Semwal
> Cc: Liam Mark
> Cc: Chris Goldsworthy
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: S
On Wed, Dec 16, 2020 at 8:48 AM Qais Yousef wrote:
>
> On 12/16/20 14:14, Will Deacon wrote:
> > Hi Qais,
> >
> > On Wed, Dec 16, 2020 at 11:16:46AM +, Qais Yousef wrote:
> > > On 12/08/20 13:28, Will Deacon wrote:
> > > > Changes in v5 include:
> > > >
> > > > * Teach cpuset_cpus_allowed()
; + psi = cgroup_ino(cgrp) == 1 ? _system : >psi;
> + new = psi_trigger_create(psi, buf, nbytes, res);
> if (IS_ERR(new)) {
> cgroup_put(cgrp);
> return PTR_ERR(new);
> --
> 2.29.2
>
Reviewed-by: Suren Baghdasaryan
On Tue, Dec 8, 2020 at 3:40 PM Jann Horn wrote:
>
> On Tue, Nov 24, 2020 at 6:50 AM Suren Baghdasaryan wrote:
> > In modern systems it's not unusual to have a system component monitoring
> > memory conditions of the system and tasked with keeping system memory
> > pressur
On Mon, Nov 30, 2020 at 11:01 AM Suren Baghdasaryan wrote:
>
> On Wed, Nov 25, 2020 at 3:43 PM Minchan Kim wrote:
> >
> > On Wed, Nov 25, 2020 at 03:23:40PM -0800, Suren Baghdasaryan wrote:
> > > On Wed, Nov 25, 2020 at 3:13 PM Minchan Kim wrote:
> > > >
On Wed, Nov 25, 2020 at 3:43 PM Minchan Kim wrote:
>
> On Wed, Nov 25, 2020 at 03:23:40PM -0800, Suren Baghdasaryan wrote:
> > On Wed, Nov 25, 2020 at 3:13 PM Minchan Kim wrote:
> > >
> > > On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
&g
On Wed, Nov 25, 2020 at 3:13 PM Minchan Kim wrote:
>
> On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> > process_madvise requires a vector of address ranges to be provided for
> > its operations. When an advice should be applied to the entire process,
>
On Tue, Nov 24, 2020 at 5:42 AM Oleg Nesterov wrote:
>
> On 11/23, Suren Baghdasaryan wrote:
> >
> > + if (madvise_destructive(behavior)) {
> > + /* Allow destructive madvise only on a dying processes */
> > + if (!
On Wed, Nov 18, 2020 at 4:13 PM Suren Baghdasaryan wrote:
>
> On Wed, Nov 18, 2020 at 11:55 AM Suren Baghdasaryan wrote:
> >
> > On Wed, Nov 18, 2020 at 11:51 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Wed, Nov 18, 2020 at 11:32 AM Michal Hocko
to reclaim its memory. This would allow userspace system
components like oomd and lmkd to free memory of the target process in
a more predictable way.
Signed-off-by: Suren Baghdasaryan
---
mm/madvise.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/mm
1 - 100 of 349 matches
Mail list logo
