On Tue, Aug 29, 2017 at 09:10:59AM -0700, Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 7:09 AM, Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > > Hello, > > > > On Tue, Aug 29, 2017 at 02:59:23PM +0200, Adam Borowski wrote: > >> On Tue, Aug 29, 2017 at 02:45:41PM +0200, Takashi Iwai wrote: > >> > [Put more people to Cc, sorry for growing too much...] > >> > >> We're all interested in 4.13.0 not crashing on us, so that's ok. > >> > >> > On Tue, 29 Aug 2017 11:19:13 +0200, > >> > Bernhard Held wrote: > >> > > > >> > > On 08/28/2017 at 06:56 PM, Nadav Amit wrote: > >> > > > Don’t blame me for the TLB stuff... My money is on aac2fea94f7a . > >> > > > >> > > Amit, thanks for your courage to expose your patch! > >> > > > >> > > I'm more and more confident that aac2fea94f7a is the culprit. Maybe it > >> > > just accelerates the triggering of the splash. To be more sure the > >> > > kernel needs to be tested for a couple of days. It would be great if > >> > > others could assist in testing aac2fea94f7a. > >> > > >> > I'm testing with the revert for a while and it seems working. > >> > >> With nothing but aac2fea94f7a reverted, no explosions for me either. > > > > The aforementioned commit has 3 bugs. > > Yes. I'm reverting it from my tree. > > We should really *really* just tell the stupid MMU notifier users that > they can't sleep. There is no way around sleeping if we ever want to support thing like GPU. To invalidate page table on GPU you need to schedule commands to do so on GPU command queue and wait for the GPU to signal that it has invalidated its page table/tlb and caches. We had this discussion before. Either we want to support all the new fancy GPGPU, AI and all the API they rely on or we should tell them sorry guys not on linux. > > The MMU notifiers are not going to destroy our VM layer. I hate the > damn crap, and this kind of garbage is an example of why. Issue here is that nobody calls mmu_notifier_invalidate_range_start/end() hence why people relied on invalidate_range() to not sleep like start/end Now we can make the decission that start/end can sleep while the range can't but then we also need to make sure that range_start/end is always called. Cheers, Jérôme
