Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 8 Apr 2021 16:51:27 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4fa56ad0d12e24df768c98bffe9039f915d1bc02 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 25 Mar 2021 15:04:21 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2ba9bea2d3682361f0f22f68a400bcee4248c205 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 5 Mar 2021 19:35:41 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f3ed4de6cc8327e4ef79e6c7892b2b5cbbc02405 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Mon, 22 Feb 2021 10:59:21 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3672ac8ac0d8bece188f82c48770bbe40f234f1e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 15 Jan 2021 15:21:40 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8cbe71e7e01a9e45a390b204403880c90a226039 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Wed, 16 Dec 2020 13:57:30 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/009bd55dfcc857d8b00a5bbb17a8db060317af6f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 10 Dec 2020 11:50:05 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9fca90cf28920c6d0723d7efd1eae0b0fb90309c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 27 Nov 2020 10:00:52 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d41e9b22eb871a7a7060964db9ce1ceb1c6e5b57 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 19 Nov 2020 15:29:25 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3be28e93cd88fbcbe97cabcbe92b1ccc9f830450 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 5 Nov 2020 14:16:36 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6f3f374ac05d05cfa63d04f4479ead7e3cb6d087 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 29 Oct 2020 15:41:23 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b9c0f4bd5b8114ee1773734e07cda921b6e8248b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
On Thu, Oct 29, 2020 at 11:41 AM Jason Gunthorpe wrote: > > Three notable merge window regressions that didn't get caught/fixed in > time for rc1: Three .. and then you list five things ;) Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sat, Oct 17, 2020 at 11:21:51AM -0700, Linus Torvalds wrote: > On Fri, Oct 16, 2020 at 11:52 AM Jason Gunthorpe wrote: > > > > You'll need to apply this fixup to the merge commit (it is in the tag > > for-linus-merged for reference): > > Ugh. That's unbelievably and unnecessarily ugly. > > There's no point in that unnecessary "ret" variable and the "goto out" > etc, when all the error cases can be handled much more directly. Yep > So I resolved that merge issue somewhat differently. I can't test the > end result, but it looks TriviallyCorrect(tm). > > Famous last words. Feel free to make fun of me and call me names if that > breaks. Not familiar with DRM land, but it looks trivially fine to me too. Thanks, Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 16 Oct 2020 15:51:55 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a1e16bc7d5f7ca3599d8a7f061841c93a563665e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Oct 16, 2020 at 11:52 AM Jason Gunthorpe wrote: > > You'll need to apply this fixup to the merge commit (it is in the tag > for-linus-merged for reference): Ugh. That's unbelievably and unnecessarily ugly. There's no point in that unnecessary "ret" variable and the "goto out" etc, when all the error cases can be handled much more directly. So I resolved that merge issue somewhat differently. I can't test the end result, but it looks TriviallyCorrect(tm). Famous last words. Feel free to make fun of me and call me names if that breaks. Linus I did it v
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 25 Sep 2020 09:57:29 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/33d04c66f5799befa7c0c618be387541d0c311a3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 10 Sep 2020 20:38:10 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b1df2a0783f3d80d6d37102eb90f06727113c7dc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 21 Aug 2020 11:06:12 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cd02217a5d813e2bbec984a9eeb8280ff290a150 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 6 Aug 2020 15:27:32 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d7806bbd22cabc3e3b0a985cfcffa29cf156bb30 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 31 Jul 2020 12:17:02 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ae2911de2eb5dc9ccb88c6502c776a8fbb7acc67 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 24 Jul 2020 14:47:39 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fcef1046eb1b78c98105e9b68e48df6022c23a06 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 10 Jul 2020 14:58:06 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/aa0c9086b40c17a7ad94425b3b70dd1fdd7497bf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 25 Jun 2020 14:56:10 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/87d93e9a91c76bcb45112d863ef72aab41e01879 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 4 Jun 2020 16:51:31 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/242b23319809e05170b3cc0d44d3b4bd202bb073 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 29 May 2020 11:15:56 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6ff64d2537f5b445177c30a2fc7779a6f2107ed5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 15 May 2020 16:13:54 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d5dfe4f1b44ed532653c2335267ad9599c8a698e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Tue, 28 Apr 2020 16:59:14 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/edb98d162418e90d6d2c1cec42e09be0375cfd88 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Wed, 9 Oct 2019 14:28:15 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8a8c600de5dc1d9a7f4b83269fddc80ebd3dd045 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 19 Sep 2019 16:34:46 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/018c6837f3e63b45163d55a1668d9f8e6fdecf6e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Tue, 30 Jul 2019 12:15:01 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/32a024b9a9f3b40f84bc55a6dd35eaa770ea26a4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Mon, 15 Jul 2019 15:26:22 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2a3c389a0fde49b241430df806a34276568cfb29 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 6 Jun 2019 20:14:24 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6e38335dcc70f03faba26bf1260ee024d930afe1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Wed, 15 May 2019 00:46:58 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5ac94332248ee017964ba368cdda4ce647e3aba7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 9 May 2019 13:37:23 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dce45af5c2e9e85f22578f2f8065f225f5d11764 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sun, Apr 28, 2019 at 05:09:08PM -0700, Linus Torvalds wrote: > On Sun, Apr 28, 2019 at 4:49 PM Jason Gunthorpe wrote: > > > > It is for high availability - we have situations where the hardware > > can fault and needs some kind of destructive recovery. For instance a > > firmware reboot, or a VM migration. > > > > In these designs there may be multiple cards in the system and the > > userspace application could be using both. Just because one card > > crashed we can't send SIGBUS and kill the application, that breaks the > > HA design. > > Why can't this magical application that is *so* special that it is HA > and does magic mmap's of special rdma areas just catch the SIGBUS? > > Honestly, the whole "it's for HA" excuse stinks. It stinks because you > now silently just replace the mapping with *garbage*. That's not HA, > that's just random. This should only used in cases where user space only writes to the BAR page (it is an interrupt to the device essentially), so it doesn't care that the pages are now garbage, we just need to redirect the writes away from the bar. However I think someone later on added a readable counter BAR pages to one of the devices :( So even that ideal wasn't respected. > Wouldn't it be a lot better to just get the SIGBUS, and then that > magical application knows that "oh, it's gone", and it could - in its > SIGBUS handler - just do the dummy anonymous mmap() with /dev/zero it > if it wants to? This does sound more appealing, and probably should have been done instead. All this VMA stuff has been a big pain in the long run Thanks, Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Mon, 2019-04-29 at 11:42 -0400, Doug Ledford wrote:
> On Mon, 2019-04-29 at 08:40 +, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > > Hi Linus,
> > > >
> > > > Third rc pull request
> > > >
> > > > Nothing particularly special here. There is a small merge conflict
> > > > with Adrea's mm_still_valid patches which is resolved as below:
> > > ...
> > > > Jason Gunthorpe (3):
> > > > RDMA/mlx5: Do not allow the user to write to the clock page
> > > > RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> > > > RDMA/ucontext: Fix regression with disassociate
> > >
> > > This doesn't compile. The patch below would fix it, but not sure if
> > > this is what is intended:
> > >
> > > drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
> > > drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault'
> > > has no member named 'vm_start'
> > >vmf->page = ZERO_PAGE(vmf->vm_start);
> > > ^~
> > > diff --git a/drivers/infiniband/core/uverbs_main.c
> > > b/drivers/infiniband/core/uverbs_main.c
> > > index 7843e89235c3..65fe89b3fa2d 100644
> > > +++ b/drivers/infiniband/core/uverbs_main.c
> > > @@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault
> > > *vmf)
> > >
> > > /* Read only pages can just use the system zero page. */
> > > if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> > > - vmf->page = ZERO_PAGE(vmf->vm_start);
> > > + vmf->page = ZERO_PAGE(vmf->vma->vm_start);
> > > get_page(vmf->page);
> > > return 0;
> > > }
> > >
> >
> > Thanks Heiko, this looks right to me.
> >
> > I'm surprised to be seeing this at this point, these patches should
> > have been seen by 0 day for several days now, and they were in
> > linux-next already too..
> >
> > Doug, can you send this to Linus today?
>
> Yep.
>
Done.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
Re: [GIT PULL] Please pull RDMA subsystem changes
On Mon, 2019-04-29 at 08:40 +, Jason Gunthorpe wrote:
> On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > Hi Linus,
> > >
> > > Third rc pull request
> > >
> > > Nothing particularly special here. There is a small merge conflict
> > > with Adrea's mm_still_valid patches which is resolved as below:
> > ...
> > > Jason Gunthorpe (3):
> > > RDMA/mlx5: Do not allow the user to write to the clock page
> > > RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> > > RDMA/ucontext: Fix regression with disassociate
> >
> > This doesn't compile. The patch below would fix it, but not sure if
> > this is what is intended:
> >
> > drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
> > drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault' has
> > no member named 'vm_start'
> >vmf->page = ZERO_PAGE(vmf->vm_start);
> > ^~
> > diff --git a/drivers/infiniband/core/uverbs_main.c
> > b/drivers/infiniband/core/uverbs_main.c
> > index 7843e89235c3..65fe89b3fa2d 100644
> > +++ b/drivers/infiniband/core/uverbs_main.c
> > @@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault *vmf)
> >
> > /* Read only pages can just use the system zero page. */
> > if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> > - vmf->page = ZERO_PAGE(vmf->vm_start);
> > + vmf->page = ZERO_PAGE(vmf->vma->vm_start);
> > get_page(vmf->page);
> > return 0;
> > }
> >
>
> Thanks Heiko, this looks right to me.
>
> I'm surprised to be seeing this at this point, these patches should
> have been seen by 0 day for several days now, and they were in
> linux-next already too..
>
> Doug, can you send this to Linus today?
Yep.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
Re: [GIT PULL] Please pull RDMA subsystem changes
On Mon, Apr 29, 2019 at 11:00:40AM +0200, Michal Kubecek wrote:
> On Mon, Apr 29, 2019 at 08:40:37AM +, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > > Hi Linus,
> > > >
> > > > Third rc pull request
> > > >
> > > > Nothing particularly special here. There is a small merge conflict
> > > > with Adrea's mm_still_valid patches which is resolved as below:
> > > ...
> > > > Jason Gunthorpe (3):
> > > > RDMA/mlx5: Do not allow the user to write to the clock page
> > > > RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> > > > RDMA/ucontext: Fix regression with disassociate
> > >
> > > This doesn't compile. The patch below would fix it, but not sure if
> > > this is what is intended:
> > >
> > > drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
> > > drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault'
> > > has no member named 'vm_start'
> > >vmf->page = ZERO_PAGE(vmf->vm_start);
> > > ^~
> > > diff --git a/drivers/infiniband/core/uverbs_main.c
> > > b/drivers/infiniband/core/uverbs_main.c
> > > index 7843e89235c3..65fe89b3fa2d 100644
> > > +++ b/drivers/infiniband/core/uverbs_main.c
> > > @@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault
> > > *vmf)
> > >
> > > /* Read only pages can just use the system zero page. */
> > > if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> > > - vmf->page = ZERO_PAGE(vmf->vm_start);
> > > + vmf->page = ZERO_PAGE(vmf->vma->vm_start);
> > > get_page(vmf->page);
> > > return 0;
> > > }
> > >
> >
> > Thanks Heiko, this looks right to me.
> >
> > I'm surprised to be seeing this at this point, these patches should
> > have been seen by 0 day for several days now, and they were in
> > linux-next already too..
>
> Most architectures have versions of ZERO_PAGE() which ignore the
> argument so that the code builds anyway. I'm not sure if 0-day also
> tests s390x builds (which is where I ran into this).
According to 0-build results for this patch, the answer is yes, it builds.
s390default_defconfig
And it compiles uverbs_main.c (CONFIG_INFINIBAND_USER_ACCESS)
kernel git:(rdma-next) grep INFIN arch/s390/configs/debug_defconfig
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_MLX4_INFINIBAND=m
CONFIG_MLX5_INFINIBAND=m
Thanks
>
> Michal Kubecek
Re: [GIT PULL] Please pull RDMA subsystem changes
On Mon, Apr 29, 2019 at 08:40:37AM +, Jason Gunthorpe wrote:
> On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > Hi Linus,
> > >
> > > Third rc pull request
> > >
> > > Nothing particularly special here. There is a small merge conflict
> > > with Adrea's mm_still_valid patches which is resolved as below:
> > ...
> > > Jason Gunthorpe (3):
> > > RDMA/mlx5: Do not allow the user to write to the clock page
> > > RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> > > RDMA/ucontext: Fix regression with disassociate
> >
> > This doesn't compile. The patch below would fix it, but not sure if
> > this is what is intended:
> >
> > drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
> > drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault' has
> > no member named 'vm_start'
> >vmf->page = ZERO_PAGE(vmf->vm_start);
> > ^~
> > diff --git a/drivers/infiniband/core/uverbs_main.c
> > b/drivers/infiniband/core/uverbs_main.c
> > index 7843e89235c3..65fe89b3fa2d 100644
> > +++ b/drivers/infiniband/core/uverbs_main.c
> > @@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault *vmf)
> >
> > /* Read only pages can just use the system zero page. */
> > if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> > - vmf->page = ZERO_PAGE(vmf->vm_start);
> > + vmf->page = ZERO_PAGE(vmf->vma->vm_start);
> > get_page(vmf->page);
> > return 0;
> > }
> >
>
> Thanks Heiko, this looks right to me.
>
> I'm surprised to be seeing this at this point, these patches should
> have been seen by 0 day for several days now, and they were in
> linux-next already too..
Most architectures have versions of ZERO_PAGE() which ignore the
argument so that the code builds anyway. I'm not sure if 0-day also
tests s390x builds (which is where I ran into this).
Michal Kubecek
Re: [GIT PULL] Please pull RDMA subsystem changes
On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > Hi Linus,
> >
> > Third rc pull request
> >
> > Nothing particularly special here. There is a small merge conflict
> > with Adrea's mm_still_valid patches which is resolved as below:
> ...
> > Jason Gunthorpe (3):
> > RDMA/mlx5: Do not allow the user to write to the clock page
> > RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> > RDMA/ucontext: Fix regression with disassociate
>
> This doesn't compile. The patch below would fix it, but not sure if
> this is what is intended:
>
> drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
> drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault' has no
> member named 'vm_start'
>vmf->page = ZERO_PAGE(vmf->vm_start);
> ^~
> diff --git a/drivers/infiniband/core/uverbs_main.c
> b/drivers/infiniband/core/uverbs_main.c
> index 7843e89235c3..65fe89b3fa2d 100644
> +++ b/drivers/infiniband/core/uverbs_main.c
> @@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault *vmf)
>
> /* Read only pages can just use the system zero page. */
> if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> - vmf->page = ZERO_PAGE(vmf->vm_start);
> + vmf->page = ZERO_PAGE(vmf->vma->vm_start);
> get_page(vmf->page);
> return 0;
> }
>
Thanks Heiko, this looks right to me.
I'm surprised to be seeing this at this point, these patches should
have been seen by 0 day for several days now, and they were in
linux-next already too..
Doug, can you send this to Linus today?
Thanks,
Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> Hi Linus,
>
> Third rc pull request
>
> Nothing particularly special here. There is a small merge conflict
> with Adrea's mm_still_valid patches which is resolved as below:
...
> Jason Gunthorpe (3):
> RDMA/mlx5: Do not allow the user to write to the clock page
> RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
> RDMA/ucontext: Fix regression with disassociate
This doesn't compile. The patch below would fix it, but not sure if
this is what is intended:
drivers/infiniband/core/uverbs_main.c: In function 'rdma_umap_fault':
drivers/infiniband/core/uverbs_main.c:898:28: error: 'struct vm_fault' has no
member named 'vm_start'
vmf->page = ZERO_PAGE(vmf->vm_start);
^~
diff --git a/drivers/infiniband/core/uverbs_main.c
b/drivers/infiniband/core/uverbs_main.c
index 7843e89235c3..65fe89b3fa2d 100644
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -895,7 +895,7 @@ static vm_fault_t rdma_umap_fault(struct vm_fault *vmf)
/* Read only pages can just use the system zero page. */
if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
- vmf->page = ZERO_PAGE(vmf->vm_start);
+ vmf->page = ZERO_PAGE(vmf->vma->vm_start);
get_page(vmf->page);
return 0;
}
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sun, Apr 28, 2019 at 4:49 PM Jason Gunthorpe wrote: > > It is for high availability - we have situations where the hardware > can fault and needs some kind of destructive recovery. For instance a > firmware reboot, or a VM migration. > > In these designs there may be multiple cards in the system and the > userspace application could be using both. Just because one card > crashed we can't send SIGBUS and kill the application, that breaks the > HA design. Why can't this magical application that is *so* special that it is HA and does magic mmap's of special rdma areas just catch the SIGBUS? Honestly, the whole "it's for HA" excuse stinks. It stinks because you now silently just replace the mapping with *garbage*. That's not HA, that's just random. Wouldn't it be a lot better to just get the SIGBUS, and then that magical application knows that "oh, it's gone", and it could - in its SIGBUS handler - just do the dummy anonymous mmap() with /dev/zero it if it wants to? Whatever. It really sounds like this is yet another horrible back for bad interfaces for all these "super-special high-end enterprise people". I hope that some day enterprise people will wake up and realize that "enterprise" seems to be often a code name for "lots of random hacks". Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sun, Apr 28, 2019 at 09:59:56AM -0700, Linus Torvalds wrote: > On Sun, Apr 28, 2019 at 4:52 AM Jason Gunthorpe wrote: > > > > Nothing particularly special here. There is a small merge conflict > > with Adrea's mm_still_valid patches which is resolved as below: > > I still don't understand *why* you play the crazy VM games to begin with. > > What's wrong with just returning SIGBUS? Why does that > rdma_umap_fault() not just look like this one-liner: > > return VM_FAULT_SIGBUS; > > without the crazy parts? Nobody ever explained why you'd want to have > that silly "let's turn it into a bogus anonymous mapping". There was a big thread where I went over the use case with Andrea, but I guess that was private.. It is for high availability - we have situations where the hardware can fault and needs some kind of destructive recovery. For instance a firmware reboot, or a VM migration. In these designs there may be multiple cards in the system and the userspace application could be using both. Just because one card crashed we can't send SIGBUS and kill the application, that breaks the HA design. So.. the kernel makes the BAR VMA into a 'dummy' and sends an async notification to the application. The use of the BAR memory by userspace is all 'write only' so it doesn't really care. When it sees the async notification it safely cleans up the userspace side of things. An more modern VM example of where this gets used is on VM systems using SRIO-V pass through of a raw RDMA device. When it is time to migrate the VM then the hypervisor causes the SRIO-V instance to fault and be removed from the guest kernel, then migrates and attaches a new RDMA SRIO-V instance. The user space is expected to see the failure, maintain state, then recover onto the new device. The only alternative that has come up would be to delay the kernel side until the application cleans up and deletes the VMA, but people generally don't like this as it degrades the recovery time and has the usual problems with blocking the kernel on userspace. When this was created I'm not sure people explored more creative ideas like trying to handle/ignore the SIGBUS in userspace - unfortunately it has been so long now that we are probably stuck doing this as part of the UAPI. I've been trying to make it less crufty over the last year based on remarks from yourself and Andrea, but I'm still stuck with this basic requirement that the VMA shouldn't fault or touch the BAR after the hardware is released by the kernel. Thanks, Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Sun, 28 Apr 2019 11:52:12 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/14f974d7f0f1f93d8c35f496ae774ba0f1b3389a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
On Sun, Apr 28, 2019 at 4:52 AM Jason Gunthorpe wrote: > > Nothing particularly special here. There is a small merge conflict > with Adrea's mm_still_valid patches which is resolved as below: I still don't understand *why* you play the crazy VM games to begin with. What's wrong with just returning SIGBUS? Why does that rdma_umap_fault() not just look like this one-liner: return VM_FAULT_SIGBUS; without the crazy parts? Nobody ever explained why you'd want to have that silly "let's turn it into a bogus anonymous mapping". I've pulled this, but why do the rdma and SCSI people always do these strange and pointless things? Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Wed, 10 Apr 2019 18:46:23 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/582549e3fbe137eb6ce9be591aca25ca36b4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Mon, 18 Mar 2019 01:04:12 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/01c8d80383d9076ab4fbebc3e60ae9abc70f70d5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 7 Mar 2019 01:34:16 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a50243b1ddcdd766d0d17fbfeeb1a22e62fdc461 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 21 Feb 2019 23:07:20 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/168bd29830e8ebbffcd70d2af50249dca088e1a8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 1 Feb 2019 17:41:11 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5eeb63359b1ec4914d9898e24aa357ff930e6ee1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 18 Jan 2019 03:56:44 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d7393226d15add056285c8fc86723d54d7e0c77d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 4 Jan 2019 05:00:10 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3954e1d0310e30e743431b58918825c4d4fe8812 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Mon, 24 Dec 2018 22:16:14 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5d24ae67a961c51beb255a28c9c417d9710247c2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
On Thu, Oct 25, 2018 at 2:21 PM Jason Gunthorpe wrote: > > This pull request is following your recommendation from 4.19, the > for-linus tag has no merge, a for-linus-merged tag has my merge > resolution for your reference, and the diffstat below has been > replaced with the diffstat from the for-linus-merged tag. Thanks, looks good. Pulled, Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Thu, Sep 27, 2018 at 12:24:32PM -0600, Jason Gunthorpe wrote: > Hi Greg, > > Second rc pull request > > This has a few fixes for smaller regressions introduced this cycle and > the usual various driver oops fixes. > > There is one long standing race bug in the comp_channel that Steve was > able to reproduce, track down and fix. > > I believe the HFI1 driver regression breakage has been fixed in > Bjorn's tree and I'm currently expecting the lingering ipoib issue to > be fixed in the netdev tree, but patches are still delayed due to > various holidays this month. > > Thanks, > Jason > > The following changes since commit 8f28b178f71cc56eccf2a6e2c0ace17c82f900d7: > > RDMA/mlx4: Ensure that maximal send/receive SGE less than supported by HW > (2018-09-06 13:16:12 -0600) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus Now pulled, thanks. greg k-h
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe wrote: > > Would you like a patch to remove that CONFIG option? I've definitely considered it and would almost certainly just apply a patch that removed it. We haven't had this issue for a while (because people stopped using the deprecated thing), so it ended up not having been an issue lately. Yours was the first case of deprecation warnings I've seen in a longish while. Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote: > On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote: > > > > We often have merge conflicts with RDMA, how do you prefer to get the > > PR? I'm actually not very clear on this part of the process. > > I generally prefer the non-merged version, but with comments about > the conflicts. > > In fact, the really preferred model is generally to send me a > non-merged pull request (say "tags/for-linus") but if the conflicts > look even half-way nasty - or simply because you did the merge anyway > just to get the proper diffstat because history is complex - mention > that you have a merged branch for verification (say > "branch/for-linus-merged"). > > When I get that kind of pull request, I'll just do the merge > resolution myself, and after I've done it I'll generally then do > >git checkout -b test-merge >git pull for-linus-merged > > and then just compare the end result with my resolution as an extra > verification step. > > I may end up skipping the verification step if everything looks > entirely trivial (and really, if you have no real reason for the > pre-merged branch, don't bother even mentioning it even if you did it > for the diffstat), but in practice whenever somebody does that, I have > no reason not to just do that simple extra verification. > > Most of the time the merges are exactly the same, possibly with > whitespace or trivial ordering differences (things like Makefiles and > Kconfig files often have add-add conflicts where the ordering really > doesn't matter between two config options). > > And then sometimes it shows that I missed something in my mmerge. > > And sometimes it shows that I do so many merges that I actually ended > up noticing something that the submaintainer didn't. > > So it can be uninteresting, and when it isn't uninteresting it can go > either way, but so far for the people who do this, I've never been in > the situation where I was *sorry* for the double merge and extra > verification step. > > Because when mis-merges happen (they are happily pretty rare) they are > _so_ annoying and can be so hard to figure out later, that I'd rather > spend a bit more time on the merge than have a dodgy one. Thanks for the explanation. Doug and I will do this in future. Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote: > On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds > wrote: > > > > Ok, everything but the max_sge thing was trivial. I just took yours. > > Oh, and doing the full test compile, I notice there are new warnings. > > That is *NOT* ok. I expect to send you a pull request to remove all of this next week. This is fall out from the SMC merge conflict reversion. > The whole "x is deprecated" is not a useful warning. If you can't > remove something, making it a reminder for yourself for later is not > an acceptable excuse for bothering everybody else with the warning, > and possibly having other issues hidden because by the time there are > expected warnings, people will start ignoring the unexpected ones too. > > So "__deprecated" is for stuff that really isn't used any more, to > catch possible new users. People have tried to use it for anything > else, but it's always been a much bigger pain than it is worth. In this case it has become confusing what CONFIG_ENABLE_WARN_DEPRECATED is for. If the kernel is supposed to compile warning free with that config set, then why have the config at all - it does nothing, by definition? Would you like a patch to remove that CONFIG option? Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds wrote: > > Ok, everything but the max_sge thing was trivial. I just took yours. Oh, and doing the full test compile, I notice there are new warnings. That is *NOT* ok. The whole "x is deprecated" is not a useful warning. If you can't remove something, making it a reminder for yourself for later is not an acceptable excuse for bothering everybody else with the warning, and possibly having other issues hidden because by the time there are expected warnings, people will start ignoring the unexpected ones too. So "__deprecated" is for stuff that really isn't used any more, to catch possible new users. People have tried to use it for anything else, but it's always been a much bigger pain than it is worth. I've considered just removing the whole deprecation infrastructure. It has never really worked. Either its used, in which case deprecation warnings only hide real issues, or it's not used, in which case the function should just be removed. Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote: > > We often have merge conflicts with RDMA, how do you prefer to get the > PR? I'm actually not very clear on this part of the process. I generally prefer the non-merged version, but with comments about the conflicts. In fact, the really preferred model is generally to send me a non-merged pull request (say "tags/for-linus") but if the conflicts look even half-way nasty - or simply because you did the merge anyway just to get the proper diffstat because history is complex - mention that you have a merged branch for verification (say "branch/for-linus-merged"). When I get that kind of pull request, I'll just do the merge resolution myself, and after I've done it I'll generally then do git checkout -b test-merge git pull for-linus-merged and then just compare the end result with my resolution as an extra verification step. I may end up skipping the verification step if everything looks entirely trivial (and really, if you have no real reason for the pre-merged branch, don't bother even mentioning it even if you did it for the diffstat), but in practice whenever somebody does that, I have no reason not to just do that simple extra verification. Most of the time the merges are exactly the same, possibly with whitespace or trivial ordering differences (things like Makefiles and Kconfig files often have add-add conflicts where the ordering really doesn't matter between two config options). And then sometimes it shows that I missed something in my mmerge. And sometimes it shows that I do so many merges that I actually ended up noticing something that the submaintainer didn't. So it can be uninteresting, and when it isn't uninteresting it can go either way, but so far for the people who do this, I've never been in the situation where I was *sorry* for the double merge and extra verification step. Because when mis-merges happen (they are happily pretty rare) they are _so_ annoying and can be so hard to figure out later, that I'd rather spend a bit more time on the merge than have a dodgy one. Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 12:31:00PM -0700, Linus Torvalds wrote: > On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote: > > > > This time there are many merge conflicts, all due to various tree-wide or > > RDMA > > subystem wide changes done by various people. The resolution is tricky, as > > git > > does not highlight two areas that need revision. > > I was confused by this, because there were no merge conflicts. > > Then I looked at the history, and the reason is that you actually > pushed the for-next branch into the for-linus branch, and so I got the > pre-merged version. Er, yes, sorry, I made a typo in my email, it should have read "As before I've resolved the conflicts in the for-linus tag and provided the unmerged tree in the for-linus-unmerged tag" > Oh well. I'll look at what the conflicts were, but may end up just > taking your resolution. We often have merge conflicts with RDMA, how do you prefer to get the PR? I'm actually not very clear on this part of the process. Historically, when we have conflicts, I've given you a tag 'for-linus-unmerged', a text description of the conflicts with merge diff hunks, and then a tag 'for-linus' which contains the full resolution I used and checked (based on linux-next). In the past you've taken from both tags, I think, depending on how the resolution looks? I generate the 'git request-pull' against the 'for-linus' tag only because the diffstat of the resolved branch is closer to what you'll actually see during merge. Otherwise there are always misleading netdev changes due to the shared branches with netdev. If you don't care about the diffstat I'll switch to 'for-linus' and 'for-linus-resolved' tags so you won't accidentally get any resolution commit unless you want it. Thanks, Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Aug 17, 2018 at 12:31 PM Linus Torvalds wrote: > > Oh well. I'll look at what the conflicts were, but may end up just > taking your resolution. Ok, everything but the max_sge thing was trivial. I just took yours. Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote: > > This time there are many merge conflicts, all due to various tree-wide or RDMA > subystem wide changes done by various people. The resolution is tricky, as git > does not highlight two areas that need revision. I was confused by this, because there were no merge conflicts. Then I looked at the history, and the reason is that you actually pushed the for-next branch into the for-linus branch, and so I got the pre-merged version. Oh well. I'll look at what the conflicts were, but may end up just taking your resolution. Linus
Re: [GIT PULL] Please pull RDMA subsystem changes
On Wed, May 16, 2018 at 11:49:33AM -0600, Jason Gunthorpe wrote: > On Wed, May 16, 2018 at 07:39:08PM +0200, Eugene Syromiatnikov wrote: > > On Fri, Apr 06, 2018 at 10:05:41AM -0600, Jason Gunthorpe wrote: > > > RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 > > Looks like this change changed the size of struct hfi1_ctxt_info and the > > value of HFI1_IOCTL_CTXT_INFO ioctl number as a result. > > Only on 32 bit.. > > HF1 does not build on 32 bit kernels, so the 32 bit version of the > ioctl is never supported. > > HFI1 also does not define '.compat_ioctl' so even a 32 bit user space > on 64 bit kernel cannot call this ioctl. > > So, yes it changed, but it doesn't matter. > > > > IB/uverbs: Extend uverbs_ioctl header with driver_id > > This patch changed the value of the RDMA_VERBS_IOCTL ioctl number. > > > > (see https://lists.strace.io/pipermail/strace-devel/2018-May/008196.html > > for the reference) > > Yes. > > RDMA_VERBS_IOCTL has been considered experimental and was protected by > a CONFIG option. > > After the above commit the experimental was dropped and the ABI was > fixed, but prior to doing so, the struct was revised based on > feedback. > > There is no userspace user of the old struct, only the new struct. > > Basically from strace's perspective it should use the new ioctl #'s > across all kernel revs and it will be correct as there is no user > space that will issue the old ioctls. Got it, thanks for the clarification!
Re: [GIT PULL] Please pull RDMA subsystem changes
On Wed, May 16, 2018 at 07:39:08PM +0200, Eugene Syromiatnikov wrote: > On Fri, Apr 06, 2018 at 10:05:41AM -0600, Jason Gunthorpe wrote: > > RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 > Looks like this change changed the size of struct hfi1_ctxt_info and the > value of HFI1_IOCTL_CTXT_INFO ioctl number as a result. Only on 32 bit.. HF1 does not build on 32 bit kernels, so the 32 bit version of the ioctl is never supported. HFI1 also does not define '.compat_ioctl' so even a 32 bit user space on 64 bit kernel cannot call this ioctl. So, yes it changed, but it doesn't matter. > > IB/uverbs: Extend uverbs_ioctl header with driver_id > This patch changed the value of the RDMA_VERBS_IOCTL ioctl number. > > (see https://lists.strace.io/pipermail/strace-devel/2018-May/008196.html > for the reference) Yes. RDMA_VERBS_IOCTL has been considered experimental and was protected by a CONFIG option. After the above commit the experimental was dropped and the ABI was fixed, but prior to doing so, the struct was revised based on feedback. There is no userspace user of the old struct, only the new struct. Basically from strace's perspective it should use the new ioctl #'s across all kernel revs and it will be correct as there is no user space that will issue the old ioctls. Jason
Re: [GIT PULL] Please pull RDMA subsystem changes
On Fri, Apr 06, 2018 at 10:05:41AM -0600, Jason Gunthorpe wrote: > RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 Looks like this change changed the size of struct hfi1_ctxt_info and the value of HFI1_IOCTL_CTXT_INFO ioctl number as a result. > IB/uverbs: Extend uverbs_ioctl header with driver_id This patch changed the value of the RDMA_VERBS_IOCTL ioctl number. (see https://lists.strace.io/pipermail/strace-devel/2018-May/008196.html for the reference)
