Re: [PATCH 3/3] RDMA/hfi1: Use RMW accessors for changing LNKCTL2

2024-05-05 Thread Leon Romanovsky
On Fri, May 03, 2024 at 10:04:16AM -0300, Jason Gunthorpe wrote: > On Fri, May 03, 2024 at 01:18:35PM +0300, Ilpo Järvinen wrote: > > On Thu, 15 Feb 2024, Ilpo Järvinen wrote: > > > > > Convert open coded RMW accesses for LNKCTL2 to use > > > pcie_capability_clear_and_set_word() which makes its ea

Re: [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive

2024-04-03 Thread Leon Romanovsky
On Fri, Mar 29, 2024 at 05:00:25PM +, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's series > to fix drivers/i2c[1], fix the terminology where I had a role to play, now >

Re: [PATCH] PCI: Add vf reset notification for pf

2024-02-04 Thread Leon Romanovsky
On Sun, Feb 04, 2024 at 02:12:57PM +0800, Emily Deng wrote: > When a vf has been reset, the pf wants to get notification to remove the vf > out of schedule. It is very questionable if this is right thing to do. The idea of SR-IOV is that VFs represent a physical device and they should be treated s

Re: [PATCH v15 13/17] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr()

2019-05-06 Thread Leon Romanovsky
On Mon, May 06, 2019 at 04:50:20PM -0300, Jason Gunthorpe wrote: > On Mon, May 06, 2019 at 06:30:59PM +0200, Andrey Konovalov wrote: > > This patch is a part of a series that extends arm64 kernel ABI to allow to > > pass tagged user pointers (with the top byte set to something else other > > than 0

Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

2019-04-29 Thread Leon Romanovsky
amp;& vma->vm_end >= untagged_start + length && > + vma->vm_start <= untagged_start) { > if (vma->vm_flags & VM_WRITE) > access_flags |= IB_ACCESS_LOCAL_WRITE; > } else { > -- Thanks, Reviewed-by: Leon Romanovsky

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-17 Thread Leon Romanovsky
On Mon, Jul 16, 2018 at 04:12:49PM -0700, Andrew Morton wrote: > On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote: > > > From: Michal Hocko > > > > There are several blockable mmu notifiers which might sleep in > > mmu_notifier_invalidate_range_start and that is a problem for the > > oom_rea

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-16 Thread Leon Romanovsky
On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > > This is the v2 of RFC based

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-11 Thread Leon Romanovsky
On Wed, Jul 11, 2018 at 01:13:18PM +0200, Michal Hocko wrote: > On Wed 11-07-18 13:14:47, Leon Romanovsky wrote: > > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote: > > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > > > > On Tue, Jul 10, 2018 at

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-11 Thread Leon Romanovsky
On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote: > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > > > On Mon, Jul 09, 2018 at

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-10 Thread Leon Romanovsky
On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > > This is the v2 of RFC based

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-10 Thread Leon Romanovsky
On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no idea how. > > >