On Fri, Dec 13, 2019 at 11:19:16AM +0100, Daniel Vetter wrote:
> On Wed, Dec 11, 2019 at 10:57:13PM +, Jason Gunthorpe wrote:
> > On Thu, Dec 05, 2019 at 11:03:24AM -0500, Jerome Glisse wrote:
> >
> > > > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm)
> > > >-> mmn_mm
> > > > struct m
On Wed, Dec 18, 2019 at 08:53:05AM -0800, Linus Torvalds wrote:
> On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
> Yes, global function names need to be unique, and if they aren't
> really core, they want some prefix that explains the context, because
> global functions are called from _o
On Wed, Dec 18, 2019 at 10:37 AM Jason Gunthorpe wrote:
>
> I think this is what you are looking for?
I think that with these names, I would have had an easier time reading
the original patch that made me go "Eww", yes.
Of course, now that it's just a rename patch, it's not like the patch
is all
On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
>
> Do you think calling it 'mmn_subscriptions' is clear?
Why do you want that "mmn"?
Guys, the "mmn" part is clear from the _context_. The function name is
When the function name is something like "mmu_interval_read_begin()",
and the filen
On Wed, Dec 11, 2019 at 10:57:13PM +, Jason Gunthorpe wrote:
> On Thu, Dec 05, 2019 at 11:03:24AM -0500, Jerome Glisse wrote:
>
> > > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm)
> > >-> mmn_mm
> > > struct mm_struct
> > >-> mm
> > > struct mmu_notifier (ie the user subscriptio
On Thu, Dec 05, 2019 at 03:03:56PM -0800, John Hubbard wrote:
> No advice, just a naming idea similar in spirit to Jerome's suggestion
> (use a longer descriptive word, and don't try to capture the entire phrase):
> use "notif" in place of the unloved "mmn". So partially, approximately like
> thi
On Thu, Dec 05, 2019 at 11:03:24AM -0500, Jerome Glisse wrote:
> > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm)
> >-> mmn_mm
> > struct mm_struct
> >-> mm
> > struct mmu_notifier (ie the user subscription to the mm_struct)
> >-> mn
> > struct mmu_interval_notifier (the other ki
On 12/2/19 6:42 PM, Jason Gunthorpe wrote:
...
> Regarding the ugly names.. Naming has been really hard here because
> currently everything is a 'mmu notifier' and the natural abberviations
> from there are crummy. Here is the basic summary:
>
> struct mmu_notifier_mm (ie the mm->mmu_notifier_mm)
On Tue, Dec 03, 2019 at 02:42:12AM +, Jason Gunthorpe wrote:
> On Sat, Nov 30, 2019 at 10:23:31AM -0800, Linus Torvalds wrote:
> > On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
> > wrote:
> > >
> > > I'll try to figure the code out, but my initial reaction was "yeah,
> > > not in my VM".
> >
On Sat, Nov 30, 2019 at 10:23:31AM -0800, Linus Torvalds wrote:
> On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
> wrote:
> >
> > I'll try to figure the code out, but my initial reaction was "yeah,
> > not in my VM".
>
> Why is it ok to sometimes do
>
> WRITE_ONCE(mni->invalidate_seq, cur_s
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> Here is this batch of hmm updates, I think we are nearing the end of this
> project for now, although I suspect there will be some more patches related to
> hmm_range_fault() in the next cycle.
I've ended up pulling this, but I'm not ent
On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
wrote:
>
> I'll try to figure the code out, but my initial reaction was "yeah,
> not in my VM".
Why is it ok to sometimes do
WRITE_ONCE(mni->invalidate_seq, cur_seq);
(to pair with the unlocked READ_ONCE), and sometimes then do
mni->inval
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> You will probably be most interested in the patch "mm/mmu_notifier: add an
> interval tree notifier".
I'm trying to read that patch, and I'm completely unable to by the
absolutely *horrid* variable names.
There are zero excuses for name
Hi Linus,
Here is this batch of hmm updates, I think we are nearing the end of this
project for now, although I suspect there will be some more patches related to
hmm_range_fault() in the next cycle.
You will probably be most interested in the patch "mm/mmu_notifier: add an
interval tree notifier
Hi Linus,
Locking fix for nouveau's use of HMM
This small series was posted by Christoph before the merge window, but didn't
make it in time for the PR. It fixes various locking errors in the nouveau
driver's use of the hmm_range_* functions.
The diffstat is a bit big as Christoph did a comprehe
The pull request you sent on Tue, 30 Jul 2019 11:58:37 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus-hmm
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/515f12b9eeed35250d793b7c874707c33f7f6e05
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Tue, 9 Jul 2019 19:24:21 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus-hmm
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fec88ab0af9706b2201e5daf377c5031c62d11f7
Thank you!
--
Deet-doot-dot, I am a
On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote:
>
> I'm sending it early as it is now a dependency for several patches in
> mm's quilt.
.. but I waited to merge it until I had time to review it more
closely, because I expected the review to be painful.
I'm happy to say that I was overly p
Hi Linus,
As was discussed some time ago here are the mostly -mm patches related
to hmm functions. In agreement with Andrew we split this out from
quilt into a git topic branch so it can be shared between the DRM and
RDMA git trees. However, this cycle did not see dependencies with work
in DRM or
19 matches
Mail list logo
