All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Michal Hocko" <mhocko@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org DRI Development"
	<dri-devel@lists.freedesktop.org>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David Rientjes" <rientjes@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Wei Wang" <wvw@google.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Jann Horn" <jannh@google.com>, "Feng Tang" <feng.tang@intel.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Daniel Vetter" <daniel.vetter@intel.c>
Subject: Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
Date: Fri, 16 Aug 2019 11:05:01 -0400	[thread overview]
Message-ID: <20190816150501.GA3149@redhat.com> (raw)
In-Reply-To: <20190816143145.GD5398@ziepe.ca>

On Fri, Aug 16, 2019 at 11:31:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote:
> > On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote:
> > > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote:
> > > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote:
> > > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote:

[...]

> > > I would like to inject it into the notifier path as this is very
> > > difficult for driver authors to discover and know about, but I'm
> > > worried about your false positive remark.
> > > 
> > > I think I understand we can use only GFP_ATOMIC in the notifiers, but
> > > we need a strategy to handle OOM to guarentee forward progress.
> > 
> > Your example is from the notifier registration IIUC. 
> 
> Yes, that is where this commit hit it.. Triggering this under an
> actual notifier to get a lockdep report is hard.
> 
> > Can you pre-allocate before taking locks? Could you point me to some
> > examples when the allocation is necessary in the range notifier
> > callback?
> 
> Hmm. I took a careful look, I only found mlx5 as obviously allocating
> memory:
> 
>  mlx5_ib_invalidate_range()
>   mlx5_ib_update_xlt()
>    __get_free_pages(gfp, get_order(size));
> 
> However, I think this could be changed to fall back to some small
> buffer if allocation fails. The existing scheme looks sketchy
> 
> nouveau does:
> 
>  nouveau_svmm_invalidate
>   nvif_object_mthd
>    kmalloc(GFP_KERNEL)
> 
> But I think it reliably uses a stack buffer here
> 
> i915 I think Daniel said he audited.
> 
> amd_mn.. The actual invalidate_range_start does not allocate memory,
> but it is entangled with so many locks it would need careful analysis
> to be sure.
> 
> The others look generally OK, which is good, better than I hoped :)

It is on my TODO list to get rid of allocation in notifier callback
(iirc nouveau already use the stack unless it was lost in all the
revision it wants through). Anyway i do not think we need allocation
in notifier.

Cheers,
Jérôme

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Michal Hocko" <mhocko@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org DRI Development"
	<dri-devel@lists.freedesktop.org>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David Rientjes" <rientjes@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Wei Wang" <wvw@google.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Jann Horn" <jannh@google.com>, "Feng Tang" <feng.tang@intel.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH 2/5] kernel.h: Add non_block_start/end()
Date: Fri, 16 Aug 2019 11:05:01 -0400	[thread overview]
Message-ID: <20190816150501.GA3149@redhat.com> (raw)
In-Reply-To: <20190816143145.GD5398@ziepe.ca>

On Fri, Aug 16, 2019 at 11:31:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote:
> > On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote:
> > > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote:
> > > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote:
> > > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote:

[...]

> > > I would like to inject it into the notifier path as this is very
> > > difficult for driver authors to discover and know about, but I'm
> > > worried about your false positive remark.
> > > 
> > > I think I understand we can use only GFP_ATOMIC in the notifiers, but
> > > we need a strategy to handle OOM to guarentee forward progress.
> > 
> > Your example is from the notifier registration IIUC. 
> 
> Yes, that is where this commit hit it.. Triggering this under an
> actual notifier to get a lockdep report is hard.
> 
> > Can you pre-allocate before taking locks? Could you point me to some
> > examples when the allocation is necessary in the range notifier
> > callback?
> 
> Hmm. I took a careful look, I only found mlx5 as obviously allocating
> memory:
> 
>  mlx5_ib_invalidate_range()
>   mlx5_ib_update_xlt()
>    __get_free_pages(gfp, get_order(size));
> 
> However, I think this could be changed to fall back to some small
> buffer if allocation fails. The existing scheme looks sketchy
> 
> nouveau does:
> 
>  nouveau_svmm_invalidate
>   nvif_object_mthd
>    kmalloc(GFP_KERNEL)
> 
> But I think it reliably uses a stack buffer here
> 
> i915 I think Daniel said he audited.
> 
> amd_mn.. The actual invalidate_range_start does not allocate memory,
> but it is entangled with so many locks it would need careful analysis
> to be sure.
> 
> The others look generally OK, which is good, better than I hoped :)

It is on my TODO list to get rid of allocation in notifier callback
(iirc nouveau already use the stack unless it was lost in all the
revision it wants through). Anyway i do not think we need allocation
in notifier.

Cheers,
Jérôme

  reply	other threads:[~2019-08-16 15:05 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 20:20 [PATCH 0/5] hmm & mmu_notifier debug/lockdep annotations Daniel Vetter
2019-08-14 20:20 ` [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail Daniel Vetter
2019-08-14 22:14   ` Andrew Morton
2019-08-14 23:22     ` Jason Gunthorpe
2019-08-14 23:34     ` Ralph Campbell
2019-08-16 17:19   ` Jason Gunthorpe
2019-08-14 20:20 ` [PATCH 2/5] kernel.h: Add non_block_start/end() Daniel Vetter
2019-08-14 20:20   ` Daniel Vetter
2019-08-14 20:45   ` Andrew Morton
2019-08-14 20:45     ` Andrew Morton
2019-08-15  6:52     ` Daniel Vetter
2019-08-15  6:52       ` Daniel Vetter
2019-08-15  8:44     ` Michal Hocko
2019-08-15  8:44       ` Michal Hocko
2019-08-15 13:04       ` Jason Gunthorpe
2019-08-15 13:04         ` Jason Gunthorpe
2019-08-15 13:12         ` Daniel Vetter
2019-08-15 13:12           ` Daniel Vetter
2019-08-15 14:37           ` Jason Gunthorpe
2019-08-15 14:37             ` Jason Gunthorpe
2019-08-15 14:43             ` Daniel Vetter
2019-08-15 14:43               ` Daniel Vetter
2019-08-15 15:10               ` Jason Gunthorpe
2019-08-15 15:10                 ` Jason Gunthorpe
2019-08-15 16:25                 ` Daniel Vetter
2019-08-15 16:25                   ` Daniel Vetter
2019-08-15 17:35                   ` Jason Gunthorpe
2019-08-15 17:35                     ` Jason Gunthorpe
2019-08-15 17:39                     ` Jerome Glisse
2019-08-15 17:39                       ` Jerome Glisse
2019-08-15 18:01                       ` Jason Gunthorpe
2019-08-15 18:01                         ` Jason Gunthorpe
2019-08-15 18:27                         ` Jerome Glisse
2019-08-15 18:27                           ` Jerome Glisse
2019-08-15 18:57                           ` Jason Gunthorpe
2019-08-15 18:57                             ` Jason Gunthorpe
2019-08-15 16:32                 ` Jerome Glisse
2019-08-15 16:32                   ` Jerome Glisse
2019-08-15 17:16                   ` Jason Gunthorpe
2019-08-15 17:16                     ` Jason Gunthorpe
2019-08-15 17:21                     ` Daniel Vetter
2019-08-15 17:21                       ` Daniel Vetter
2019-08-15 17:35                       ` Jerome Glisse
2019-08-15 17:35                         ` Jerome Glisse
2019-08-15 13:24         ` Michal Hocko
2019-08-15 13:24           ` Michal Hocko
2019-08-15 22:15       ` Andrew Morton
2019-08-15 22:15         ` Andrew Morton
2019-08-16  8:24         ` Michal Hocko
2019-08-16  8:24           ` Michal Hocko
2019-08-14 23:58   ` Jason Gunthorpe
2019-08-14 23:58     ` Jason Gunthorpe
2019-08-15  6:58     ` Daniel Vetter
2019-08-15  6:58       ` Daniel Vetter
2019-08-15 12:23       ` Jason Gunthorpe
2019-08-15 12:23         ` Jason Gunthorpe
2019-08-15 13:21         ` Michal Hocko
2019-08-15 13:21           ` Michal Hocko
2019-08-15 14:12           ` Jason Gunthorpe
2019-08-15 14:12             ` Jason Gunthorpe
2019-08-15 16:00             ` Michal Hocko
2019-08-15 16:00               ` Michal Hocko
2019-08-15 16:56               ` Jason Gunthorpe
2019-08-15 16:56                 ` Jason Gunthorpe
2019-08-15 17:11                 ` Jerome Glisse
2019-08-15 17:17                   ` Jason Gunthorpe
2019-08-15 17:42                 ` Michal Hocko
2019-08-15 17:42                   ` Michal Hocko
2019-08-15 17:57                   ` Jerome Glisse
2019-08-15 18:24                   ` Jason Gunthorpe
2019-08-15 18:24                     ` Jason Gunthorpe
2019-08-15 19:05                     ` Michal Hocko
2019-08-15 19:05                       ` Michal Hocko
2019-08-15 19:18                       ` Jason Gunthorpe
2019-08-15 19:18                         ` Jason Gunthorpe
2019-08-15 19:35                         ` Michal Hocko
2019-08-15 19:35                           ` Michal Hocko
2019-08-15 20:13                           ` Jason Gunthorpe
2019-08-15 20:13                             ` Jason Gunthorpe
2019-08-16  8:10                             ` Michal Hocko
2019-08-16  8:10                               ` Michal Hocko
2019-08-16 12:19                               ` Jason Gunthorpe
2019-08-16 12:19                                 ` Jason Gunthorpe
2019-08-16 12:26                                 ` Michal Hocko
2019-08-16 12:26                                   ` Michal Hocko
2019-08-16 14:31                                   ` Jason Gunthorpe
2019-08-16 14:31                                     ` Jason Gunthorpe
2019-08-16 15:05                                     ` Jerome Glisse [this message]
2019-08-16 15:05                                       ` Jerome Glisse
2019-08-20  8:18                                     ` Michal Hocko
2019-08-20  8:18                                       ` Michal Hocko
2019-08-15 20:16                           ` [Intel-gfx] " Daniel Vetter
2019-08-15 20:16                             ` Daniel Vetter
2019-08-15 20:27                             ` Jason Gunthorpe
2019-08-15 20:27                               ` Jason Gunthorpe
2019-08-15 20:49                               ` Daniel Vetter
2019-08-15 20:49                                 ` Daniel Vetter
2019-08-16  1:00                                 ` Jason Gunthorpe
2019-08-16  1:00                                   ` Jason Gunthorpe
2019-08-16  6:20                                   ` Daniel Vetter
2019-08-16  6:20                                     ` Daniel Vetter
2019-08-16 12:12                                     ` Jason Gunthorpe
2019-08-16 12:12                                       ` Jason Gunthorpe
2019-08-16 14:11                                       ` Daniel Vetter
2019-08-16 14:11                                         ` Daniel Vetter
2019-08-16 14:38                                         ` Jason Gunthorpe
2019-08-16 14:38                                           ` Jason Gunthorpe
2019-08-16 16:36                                           ` Daniel Vetter
2019-08-16 16:36                                             ` Daniel Vetter
2019-08-16 16:54                                             ` Jason Gunthorpe
2019-08-16 16:54                                               ` Jason Gunthorpe
2019-08-16  8:27                             ` Michal Hocko
2019-08-16  8:27                               ` Michal Hocko
2019-08-14 20:20 ` [PATCH 3/5] mm, notifier: Catch sleeping/blocking for !blockable Daniel Vetter
2019-08-15  0:00   ` Jason Gunthorpe
2019-08-15  7:02     ` Daniel Vetter
2019-08-15 12:35       ` Jason Gunthorpe
2019-08-17 16:09         ` Daniel Vetter
2019-08-17 16:09           ` Daniel Vetter
2019-08-14 20:20 ` [PATCH 4/5] mm, notifier: Add a lockdep map for invalidate_range_start Daniel Vetter
2019-08-15  0:09   ` Jason Gunthorpe
2019-08-15  7:10     ` Daniel Vetter
2019-08-15  7:10       ` Daniel Vetter
2019-08-15 12:53       ` Jason Gunthorpe
2019-08-14 20:20 ` [PATCH 5/5] mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors Daniel Vetter
2019-08-15  0:11   ` Jason Gunthorpe
2019-08-15  7:14     ` Daniel Vetter
2019-08-15  7:14       ` Daniel Vetter
2019-08-14 21:29 ` ✗ Fi.CI.CHECKPATCH: warning for hmm & mmu_notifier debug/lockdep annotations Patchwork
2019-08-14 21:56 ` ✓ Fi.CI.BAT: success " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190816150501.GA3149@redhat.com \
    --to=jglisse@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@intel.c \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=feng.tang@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jannh@google.com \
    --cc=jgg@ziepe.ca \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=wvw@google.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.