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 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] 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 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: [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(>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] 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
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: [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 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(>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 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 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
