Re: [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive
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 > that > the approved verbiage exists in the specification. > > Compile tested, no functionality changes intended > > [1]: > https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > > Signed-off-by: Easwar Hariharan > --- > drivers/infiniband/hw/hfi1/chip.c | 6 ++-- > drivers/infiniband/hw/hfi1/chip.h | 2 +- > drivers/infiniband/hw/hfi1/chip_registers.h | 2 +- > drivers/infiniband/hw/hfi1/file_ops.c | 2 +- > drivers/infiniband/hw/hfi1/firmware.c | 22 ++--- > drivers/infiniband/hw/hfi1/pcie.c | 2 +- > drivers/infiniband/hw/hfi1/qsfp.c | 36 ++--- > drivers/infiniband/hw/hfi1/user_exp_rcv.c | 2 +- > drivers/infiniband/hw/qib/qib_twsi.c| 6 ++-- > 9 files changed, 40 insertions(+), 40 deletions(-) hfi1 and qib work perfectly fine with the current terminology. There is no need to change old code just for the sake of change. Let's drop this patch. Thanks
Re: [PATCH 3/3] RDMA/hfi1: Use RMW accessors for changing LNKCTL2
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 easier to > > > understand what the code tries to do. > > > > > > LNKCTL2 is not really owned by any driver because it is a collection of > > > control bits that PCI core might need to touch. RMW accessors already > > > have support for proper locking for a selected set of registers > > > (LNKCTL2 is not yet among them but likely will be in the future) to > > > avoid losing concurrent updates. > > > > > > Suggested-by: Lukas Wunner > > > Signed-off-by: Ilpo Järvinen > > > Reviewed-by: Dean Luick > > > > I found out from Linux RDMA and InfiniBand patchwork that this patch had > > been silently closed as "Not Applicable". Is there some reason for > > that? > > It is part of a series that crosses subsystems, series like that > usually go through some other trees. Exactly, this is why I marked it as "Not Applicable". > > If you want single patches applied then please send single > patches.. It is hard to understand intent from mixed series. > > Jason
Re: [PATCH] PCI: Add vf reset notification for pf
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 separately from the PF. In addition to that Keith said, this patch needs better justification. Thanks > > Solution: > Add the callback function in pci_driver sriov_vf_reset_notification. When > vf reset happens, then call this callback function. > > Signed-off-by: Emily Deng > --- > drivers/pci/pci.c | 8 > include/linux/pci.h | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 60230da957e0..aca937b05531 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4780,6 +4780,14 @@ EXPORT_SYMBOL_GPL(pcie_flr); > */ > int pcie_reset_flr(struct pci_dev *dev, bool probe) > { > + struct pci_dev *pf_dev; > + > + if (dev->is_virtfn) { > + pf_dev = dev->physfn; > + if (pf_dev->driver->sriov_vf_reset_notification) > + pf_dev->driver->sriov_vf_reset_notification(pf_dev, > dev); > + } > + > if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET) > return -ENOTTY; > > diff --git a/include/linux/pci.h b/include/linux/pci.h > index c69a2cc1f412..4fa31d9b0aa7 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -926,6 +926,7 @@ struct pci_driver { > int (*sriov_configure)(struct pci_dev *dev, int num_vfs); /* On PF */ > int (*sriov_set_msix_vec_count)(struct pci_dev *vf, int > msix_vec_count); /* On PF */ > u32 (*sriov_get_vf_total_msix)(struct pci_dev *pf); > + void (*sriov_vf_reset_notification)(struct pci_dev *pf, struct pci_dev > *vf); > const struct pci_error_handlers *err_handler; > const struct attribute_group **groups; > const struct attribute_group **dev_groups; > -- > 2.36.1 > >
Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr
On Wed, Mar 20, 2019 at 03:51:30PM +0100, 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 0x00) as syscall arguments. > > mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can > only by done with untagged pointers. > > Untag user pointers in this function. > > Signed-off-by: Andrey Konovalov > --- > drivers/infiniband/hw/mlx4/mr.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c > index 395379a480cb..9a35ed2c6a6f 100644 > --- a/drivers/infiniband/hw/mlx4/mr.c > +++ b/drivers/infiniband/hw/mlx4/mr.c > @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata > *udata, u64 start, >* again >*/ > if (!ib_access_writable(access_flags)) { > + unsigned long untagged_start = untagged_addr(start); > struct vm_area_struct *vma; > > down_read(¤t->mm->mmap_sem); > @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata > *udata, u64 start, >* cover the memory, but for now it requires a single vma to >* entirely cover the MR to support RO mappings. >*/ > - vma = find_vma(current->mm, start); > - if (vma && vma->vm_end >= start + length && > - vma->vm_start <= start) { > + vma = find_vma(current->mm, untagged_start); > + if (vma && 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 Interesting, the followup question is why mlx4 is only one driver in IB which needs such code in umem_mr. I'll take a look on it. Thanks ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v15 13/17] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr()
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 0x00) as syscall arguments. > > > > ib_uverbs_(re)reg_mr() use provided user pointers for vma lookups (through > > e.g. mlx4_get_umem_mr()), which can only by done with untagged pointers. > > > > Untag user pointers in these functions. > > > > Signed-off-by: Andrey Konovalov > > --- > > drivers/infiniband/core/uverbs_cmd.c | 4 > > 1 file changed, 4 insertions(+) > > I think this is OK.. We should really get it tested though.. Leon? It can be done after v5.2-rc1. Thanks > > Jason ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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. > > > > Any further feedback is highly appreciated of course. > > Any other feedback before I post this as non-RFC? From mlx5 perspective, who is primary user of umem_odp.c your change looks ok. Thanks signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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 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. > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > Any other feedback before I post this as non-RFC? > > > > From mlx5 perspective, who is primary user of umem_odp.c your change looks > > ok. > > Can I assume your Acked-by? I didn't have a chance to test it because it applies on our rdma-next, but fails to compile. Thanks > > Thanks for your review! > -- > Michal Hocko > SUSE Labs > signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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 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. > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > > > > > Any other feedback before I post this as non-RFC? > > > > > > > > From mlx5 perspective, who is primary user of umem_odp.c your change > > > > looks ok. > > > > > > Can I assume your Acked-by? > > > > I didn't have a chance to test it because it applies on our rdma-next, but > > fails to compile. > > What is the compilation problem? Is it caused by the patch or some other > unrelated changed? Thanks for pushing me to take a look on it. Your patch needs the following hunk to properly compile at least on my system. I'll take it to our regression. diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index 369867501bed..1f364a157097 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -155,9 +155,9 @@ struct mmu_notifier_ops { * cannot block, mmu_notifier_ops.flags should have * MMU_INVALIDATE_DOES_NOT_BLOCK set. */ - void (*invalidate_range_start)(struct mmu_notifier *mn, + int (*invalidate_range_start)(struct mmu_notifier *mn, struct mm_struct *mm, - unsigned long start, unsigned long end); + unsigned long start, unsigned long end, bool blockable); void (*invalidate_range_end)(struct mmu_notifier *mn, struct mm_struct *mm, unsigned long start, unsigned long end); @@ -229,7 +229,7 @@ extern int __mmu_notifier_test_young(struct mm_struct *mm, unsigned long address); extern void __mmu_notifier_change_pte(struct mm_struct *mm, unsigned long address, pte_t pte); -extern void __mmu_notifier_invalidate_range_start(struct mm_struct *mm, +extern int __mmu_notifier_invalidate_range_start(struct mm_struct *mm, unsigned long start, unsigned long end, bool blockable); extern void __mmu_notifier_invalidate_range_end(struct mm_struct *mm, diff --git a/include/linux/oom.h b/include/linux/oom.h index 6adac113e96d..92f70e4c6252 100644 --- a/include/linux/oom.h +++ b/include/linux/oom.h @@ -95,7 +95,7 @@ static inline int check_stable_address_space(struct mm_struct *mm) return 0; } -void __oom_reap_task_mm(struct mm_struct *mm); +bool __oom_reap_task_mm(struct mm_struct *mm); extern unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg, const nodemask_t *nodemask, diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 7e0c6e78ae5c..7c7bd6f3298e 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -1,6 +1,6 @@ /* * linux/mm/oom_kill.c - * + * * Copyright (C) 1998,2000 Rik van Riel * Thanks go out to Claus Fischer for some serious inspiration and * for goading me into coding this file... @@ -569,7 +569,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm) if (!__oom_reap_task_mm(mm)) { up_read(&mm->mmap_sem); ret = false; - goto out_unlock; + goto unlock_oom; } pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n", Thanks > -- > Michal Hocko > SUSE Labs signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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 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 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. > > > > > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > > > > > > > > > Any other feedback before I post this as non-RFC? > > > > > > > > > > > > From mlx5 perspective, who is primary user of umem_odp.c your > > > > > > change looks ok. > > > > > > > > > > Can I assume your Acked-by? > > > > > > > > I didn't have a chance to test it because it applies on our rdma-next, > > > > but > > > > fails to compile. > > > > > > What is the compilation problem? Is it caused by the patch or some other > > > unrelated changed? > > > > Thanks for pushing me to take a look on it. > > Your patch needs the following hunk to properly compile at least on my > > system. > > I suspect you were trying the original version. I've posted an updated > patch here http://lkml.kernel.org/r/20180627074421.gf32...@dhcp22.suse.cz > and all these issues should be fixed there. Including many other fixes. > Ohh, you used --reply-to, IMHO it is best way to make sure that the patch will be lost :) > Could you have a look at that one please? I grabbed it, the results will be overnight only. Thanks > -- > Michal Hocko > SUSE Labs signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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 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. > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > Any other feedback before I post this as non-RFC? > > > > From mlx5 perspective, who is primary user of umem_odp.c your change looks > > ok. > > Can I assume your Acked-by? > > Thanks for your review! For mlx and umem_odp pieces, Acked-by: Leon Romanovsky Thanks signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
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_reaper because it needs to guarantee a forward progress so it cannot > > depend on any sleepable locks. > > > > Currently we simply back off and mark an oom victim with blockable mmu > > notifiers as done after a short sleep. That can result in selecting a > > new oom victim prematurely because the previous one still hasn't torn > > its memory down yet. > > > > We can do much better though. Even if mmu notifiers use sleepable locks > > there is no reason to automatically assume those locks are held. > > Moreover majority of notifiers only care about a portion of the address > > space and there is absolutely zero reason to fail when we are unmapping an > > unrelated range. Many notifiers do really block and wait for HW which is > > harder to handle and we have to bail out though. > > > > This patch handles the low hanging fruid. > > __mmu_notifier_invalidate_range_start > > gets a blockable flag and callbacks are not allowed to sleep if the > > flag is set to false. This is achieved by using trylock instead of the > > sleepable lock for most callbacks and continue as long as we do not > > block down the call chain. > > I assume device driver developers are wondering "what does this mean > for me". As I understand it, the only time they will see > blockable==false is when their driver is being called in response to an > out-of-memory condition, yes? So it is a very rare thing. I can't say for everyone, but at least for me (mlx5), it is not rare event. I'm seeing OOM very often while I'm running my tests in low memory VMs. Thanks > > Any suggestions regarding how the driver developers can test this code > path? I don't think we presently have a way to fake an oom-killing > event? Perhaps we should add such a thing, given the problems we're > having with that feature. signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx