Prepared RDMA Tree for 4.7

Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi Doug,

I prepared the base tree [1] with patches sent to RDMA mailing and passed review.

This base tree is part of linux-next and kbuild system, and it passed
sanity checks.

I believe that it will save you a lot of work and time if you use it
as a base for next merge window submission (4.7).

The topics which were added:
 * topic/fix-core
 * topic/hfi1
 * topic/i40iw
 * topic/ipoib
 * topic/iw_cxgb4
 * topic/iwcm
 * topic/nes
 * topic/rdma-rw-api
 * topic/srp

[1]
Git repository:
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next

Gitweb:
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next

Thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Thu, May 12, 2016 at 08:44:06PM +0300, Leon Romanovsky wrote:
> Hi Doug,
> 
> I prepared the base tree [1] with patches sent to RDMA mailing and passed review.
> 
> This base tree is part of linux-next and kbuild system, and it passed
> sanity checks.

Forgot to mention that it based on v4.6-rc7.

> 
> I believe that it will save you a lot of work and time if you use it
> as a base for next merge window submission (4.7).
> 
> The topics which were added:
>  * topic/fix-core
>  * topic/hfi1
>  * topic/i40iw
>  * topic/ipoib
>  * topic/iw_cxgb4
>  * topic/iwcm
>  * topic/nes
>  * topic/rdma-rw-api
>  * topic/srp
> 
> [1]
> Git repository:
> git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next
> 
> Gitweb:
> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next
> 
> Thanks.



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On 05/12/2016 01:44 PM, Leon Romanovsky wrote:
> Hi Doug,
> 
> I prepared the base tree [1] with patches sent to RDMA mailing and passed review.

You can't know that.  The reason I say that is because they have to pass
my review as well, and that's usually an implicit thing.  If I review
them and they have already passed list review and they pass my review,
then I include them.  If they don't pass my review (which isn't often if
the other people on the list have already spoke up, but does happen),
then I ask for revisions.  If you take them without an explicit review
from me, then you don't know if I'll ask for a revision or not.  It's
premature.

> This base tree is part of linux-next and kbuild system, and it passed
> sanity checks.

Most, there was a linux-next build failure that I'm sure is related to a
change I hadn't had a chance to look into yet but looked fishy to me
(the move to put ib_addr into ib_core looks like it's broken, but I
hadn't delved into the code to verify it...the linux-next build failure
from tonight makes me thing that it is).

> I believe that it will save you a lot of work and time if you use it
> as a base for next merge window submission (4.7).

Not really.  I still have to review the patches, and I still have to
update patchworks, and when I'm sorting through patchworks is when I get
the patches to include.  The incremental time to grab the patches out of
patchworks and run git am -s on the bundle is negligible.  The real time
is in reading the patches, and this doesn't save me any of that time.
The help is appreciated though ;-)

> The topics which were added:
>  * topic/fix-core
>  * topic/hfi1
>  * topic/i40iw
>  * topic/ipoib
>  * topic/iw_cxgb4
>  * topic/iwcm
>  * topic/nes
>  * topic/rdma-rw-api
>  * topic/srp
> 
> [1]
> Git repository:
> git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next
> 
> Gitweb:
> https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next
> 
> Thanks.
> 


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 4183 bytes --]

On Thu, May 12, 2016 at 10:01:17PM -0400, Doug Ledford wrote:
> On 05/12/2016 01:44 PM, Leon Romanovsky wrote:
> > Hi Doug,
> > 
> > I prepared the base tree [1] with patches sent to RDMA mailing and passed review.
> 
> You can't know that.  The reason I say that is because they have to pass
> my review as well, and that's usually an implicit thing.  If I review
> them and they have already passed list review and they pass my review,
> then I include them.  If they don't pass my review (which isn't often if
> the other people on the list have already spoke up, but does happen),
> then I ask for revisions.  If you take them without an explicit review
> from me, then you don't know if I'll ask for a revision or not.  It's
> premature.

Yes, I don't know for sure, but you can see that patches which I chose
have no dispute over them and have no reasons do not to be accepted.

> 
> > This base tree is part of linux-next and kbuild system, and it passed
> > sanity checks.
> 
> Most, there was a linux-next build failure that I'm sure is related to a
> change I hadn't had a chance to look into yet but looked fishy to me
> (the move to put ib_addr into ib_core looks like it's broken, but I
> hadn't delved into the code to verify it...the linux-next build failure
> from tonight makes me thing that it is).

It is caused by **not merged and delayed** topic branches. Both topic/fix_core and
topic/rdwa-rw-api touched drivers/infiniband/core/Makefile and created merge
conflict.

The merge commit is here [1] and the simple fix is
diff --cc drivers/infiniband/core/Makefile
index 2c6dc6b,26987d9..f0a5276
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@@ -8,9 -8,9 +8,9 @@@ obj-$(CONFIG_INFINIBAND_USER_MAD) +=     ib
  obj-$(CONFIG_INFINIBAND_USER_ACCESS) +=       ib_uverbs.o ib_ucm.o \
                                          $(user_access-y)

- ib_core-y :=			packer.o ud_header.o verbs.o cq.o sysfs.o \
+ ib_core-y :=			packer.o ud_header.overbs.o cq.o rw.o sysfs.o \
				device.o fmr_pool.o cache.o netlink.o \
-                               roce_gid_mgmt.o addr.o
-                               roce_gid_mgmt.o mr_pool.o
++				roce_gid_mgmt.o addr.o mr_pool.o
ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
ib_core-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o umem_rbtree.o

Based on your methodology such merge failures are unavoidable and I'm
not feeling well with your conclusion that topic/fix_core broke the
build.

> 
> > I believe that it will save you a lot of work and time if you use it
> > as a base for next merge window submission (4.7).
> 
> Not really.  I still have to review the patches, and I still have to
> update patchworks, and when I'm sorting through patchworks is when I get
> the patches to include.  The incremental time to grab the patches out of
> patchworks and run git am -s on the bundle is negligible.  The real time
> is in reading the patches, and this doesn't save me any of that time.

I'm not working with patchworks, so I can't save here, but IMHO it still
valuable and save time:
1. Separated by topics
2. ROB tags
3. cleanpatch + checkpatch before merging
4. We (Intel and Mellanox) already run their test regressions on the upstream code
and we will run it on **almost** (pending your acceptance) latest ->next branch.
So the bugs will be caught before sending pull request to Linus.

> The help is appreciated though ;-)

Thanks,
Will you support my effort to continue publish ->next tree?

> 
> > The topics which were added:
> >  * topic/fix-core
> >  * topic/hfi1
> >  * topic/i40iw
> >  * topic/ipoib
> >  * topic/iw_cxgb4
> >  * topic/iwcm
> >  * topic/nes
> >  * topic/rdma-rw-api
> >  * topic/srp
> > 
> > [1]
> > Git repository:
> > git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git rdma-next
> > 
> > Gitweb:
> > https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next
> > 
> > Thanks.
> > 


[1]
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/commit/?h=rdma-next&id=d77eb1c067de68982a63063dc391a28c450ebd64

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 8688 bytes --]

On 05/13/2016 12:22 AM, Leon Romanovsky wrote:
> On Thu, May 12, 2016 at 10:01:17PM -0400, Doug Ledford wrote:
>> On 05/12/2016 01:44 PM, Leon Romanovsky wrote:
>>> Hi Doug,
>>>
>>> I prepared the base tree [1] with patches sent to RDMA mailing and passed review.
>>
>> You can't know that.  The reason I say that is because they have to pass
>> my review as well, and that's usually an implicit thing.  If I review
>> them and they have already passed list review and they pass my review,
>> then I include them.  If they don't pass my review (which isn't often if
>> the other people on the list have already spoke up, but does happen),
>> then I ask for revisions.  If you take them without an explicit review
>> from me, then you don't know if I'll ask for a revision or not.  It's
>> premature.
> 
> Yes, I don't know for sure, but you can see that patches which I chose
> have no dispute over them and have no reasons do not to be accepted.

That's not true.  You chose some of your own patches that I'm not sure
I'm going to accept.  The ib_addr module build patch among them.

>> Most, there was a linux-next build failure that I'm sure is related to a
>> change I hadn't had a chance to look into yet but looked fishy to me
>> (the move to put ib_addr into ib_core looks like it's broken, but I
>> hadn't delved into the code to verify it...the linux-next build failure
>> from tonight makes me thing that it is).
> 
> It is caused by **not merged and delayed** topic branches.

The reported failure from Stephen was with *your* tree.  If there are
any **not merged and delayed** topic branches then they are in your own
tree.  When you put together your own tree, if you can't do so in a
fashion that passes testing, don't act like that's someone else's fault,
that's *your* tree and *your* responsibility.

> Both topic/fix_core and
> topic/rdwa-rw-api touched drivers/infiniband/core/Makefile and created merge
> conflict.
> 
> The merge commit is here [1] and the simple fix is
> diff --cc drivers/infiniband/core/Makefile
> index 2c6dc6b,26987d9..f0a5276
> --- a/drivers/infiniband/core/Makefile
> +++ b/drivers/infiniband/core/Makefile
> @@@ -8,9 -8,9 +8,9 @@@ obj-$(CONFIG_INFINIBAND_USER_MAD) +=     ib
>   obj-$(CONFIG_INFINIBAND_USER_ACCESS) +=       ib_uverbs.o ib_ucm.o \
>                                           $(user_access-y)
> 
> - ib_core-y :=			packer.o ud_header.o verbs.o cq.o sysfs.o \
> + ib_core-y :=			packer.o ud_header.overbs.o cq.o rw.o sysfs.o \
> 				device.o fmr_pool.o cache.o netlink.o \
> -                               roce_gid_mgmt.o addr.o
> -                               roce_gid_mgmt.o mr_pool.o
> ++				roce_gid_mgmt.o addr.o mr_pool.o
> ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
> ib_core-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o umem_rbtree.o
> 
> Based on your methodology such merge failures are unavoidable and I'm
> not feeling well with your conclusion that topic/fix_core broke the
> build.

The tree Stephen tested was *your* rdma-next, and it was the result of a
merge of *your* topic/rdma-rw-api and *your* topic/fix_core.  This has
*nothing* to do with my tree and is all about your own merge failure.
When I merge topics and they don't build properly, I fix up my own tree,
I don't blame someone else.

>>> I believe that it will save you a lot of work and time if you use it
>>> as a base for next merge window submission (4.7).
>>
>> Not really.  I still have to review the patches, and I still have to
>> update patchworks, and when I'm sorting through patchworks is when I get
>> the patches to include.  The incremental time to grab the patches out of
>> patchworks and run git am -s on the bundle is negligible.  The real time
>> is in reading the patches, and this doesn't save me any of that time.
> 
> I'm not working with patchworks, so I can't save here, but IMHO it still
> valuable and save time:
> 1. Separated by topics

Which I do myself anyway.

> 2. ROB tags

Which patchwork collects anyway.

> 3. cleanpatch + checkpatch before merging

Which I don't always do, but I expect patch submitters to do.

> 4. We (Intel and Mellanox) already run their test regressions on the upstream code
> and we will run it on **almost** (pending your acceptance) latest ->next branch.
> So the bugs will be caught before sending pull request to Linus.

You're making a big leap of faith that what you have pulled together
will represent even close to the next ->next pull request.  That isn't
justified.  See below...

>>> The topics which were added:
>>>  * topic/fix-core

Which includes one patch I haven't determined I will take yet.

>>>  * topic/hfi1

Which has less than half of the hfi1 commits my current for-next tag
has, I'm sure Intel will be appreciative of all those lost commits.

>>>  * topic/i40iw

Your branch has 25 commits and mine has 27.  Again, I'm sure Intel will
appreciate the lost commits.

>>>  * topic/ipoib

This topic branch doesn't exist, but ipoib-device-address does, however,
I haven't decided to take that patch just yet, so it's probably a good
thing that you didn't include it in rdma-next even though you say you
did.  But if I can't trust the list of topic branches to be correct,
that's another issue.

>>>  * topic/iw_cxgb4

Both of our branches have 26 commits, but I know mine has one that yours
doesn't, so now I need to search through yours to see which it has that
mine doesn't.

>>>  * topic/iwcm

This shouldn't have been a topic, it's only one commit, but I have it.
It was in one of my misc topics.

>>>  * topic/nes

This is only one commit, and I haven't pulled it yet.  But mine has
three other commits you are missing.

>>>  * topic/rdma-rw-api

This is similar to mine.

>>>  * topic/srp

And this is similar.

>> The help is appreciated though ;-)
> 
> Thanks,
> Will you support my effort to continue publish ->next tree?

I'll give you the same advice Linus gave me in 1994 when I started to
publish my own 1.2.13+ linux kernel tree: I don't care what you publish.
 You are free to publish anything you want.  That's the beauty of open
source.

As for what I'll use, I'll simply point out these facts:

When I helped you get your kernel.org account, I told the kernel.org
people that it was so that both Dave Miller and I could pull the exact
same *commits* from your tree for patches that might have merge
conflicts between our trees if submitted separately.  This if for things
like changes to the mlx5 offsets file.  Even if Dave and I both take the
exact same patches, that still throws a merge issue when Linus merges
the two trees.  The only way for Linus to avoid seeing that at all is if
Dave and I pull the exact same commits from your tree.  This merge cycle
was pretty easy, there were only two commits that we would likely need
to share.  But, instead of putting the tree up with those two commits in
a topic branch that each of us could merge, you sent the patches to the
list, and we both had to commit our own commits for these patches.  I'm
going to have to mention that when I send my pull request to Linus
(although, the mlx5 IB changes this cycle are simply non-existent, so I
could just drop them instead).  So this branch that I expected from you,
I didn't get.

I didn't help you set up your account because I had any intention of
pulling other branches from you.  You are free to publish whatever you
want, but I still must do my own work.  I'm accountable for things like
missed patches and crappy merges.  I prefer to be accountable for things
I actually did, not things other people did.

I would suggest you keep doing what you are doing.  Pulling the branches
that you guys care about together and running them through your internal
test/regression stuff is valuable, no doubt.  It might even save me time
when I get around to taking a patch series as you might have caught some
build/test issue and a new version of the series can be sent to the
mailing list before I include the final series in my tree.  That all has
value.

But ultimately, I will pick up the patches myself and I will do as I
said when I first started doing this job and track them in patchworks.
And what you think rdma-next will be, is not necessarily what it will in
actuality be.  And I will expect that you will actually publish the
topic branches in the future that were the reason we set up your k.o git
repo in the first place.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:

<snip>

I had an intent to help you, since there was kernel oops fix
which wasn't applied for more than month [1] and Christoph/Bart/Steve
asked your plans about important ULP API change [2], which you
decided do not announce.

We all agree that applying patches is not the time
consuming process and you can handle it by yourself.

So can you please share with us your plans on how-to address the
general lack of "communication, transparency and coordination",
which is definitely happen here?

[1] http://permalink.gmane.org/gmane.linux.drivers.rdma/35409
[2] http://marc.info/?l=linux-rdma&m=146229128832706&w=2

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
> On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
> 
> <snip>
> 
> I had an intent to help you,

That's fine.  As I pointed out in my email, I need to know what I'm
sending to Linus.

> So can you please share with us your plans on how-to address the
> general lack of "communication, transparency and coordination",
> which is definitely happen here?

I could always just artificially limit each release to no more than 100
patches or something like that.  Then I would have more time per patch
to be communicative.  But that wouldn't make people happy, it would take
months and years to get things done.

But you guys are only partially mad at me.  I'm not the sole
person/group holding you up from getting your way.  For example the LSO
patches aren't in, and that because they are an API extension that not
everyone understands what LSO in that context means.  The patch set
needs more explanation so that others can actually say if it's generic
enough to meet their needs.  You guys have a ton of features you want to
get into the kernel, each one being a different sort of hardware
offload, and while you may have worked with customers to do the initial
creation, you didn't work with the community on describing them or
anything else, and you bring them here fully done to your satisfaction,
and it takes other people time to wrap their head around what they are,
whether or not they might be usable in their own hardware, and then to
decide if the design as presented would work for them if they did decide
to implement it.  Without their input, I'm left in a rather untenable
position.  And frankly, I'm rather sick of being in that position.

I'm quickly coming to agree with the results of the collaboration summit
in that if a patch set implements a new feature in the form of a user
visible API change (aka, a new flag to create_qp or a change to user
visible work completions, that sort of thing), then patches will need
buy in from other vendors before I'll accept them (where buy in means
they've read it, they've understood it, and they've publicly given their
Acked-by: line....silence does not equal buy in!).

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]

On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
> > On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
> > 
> > <snip>
> > 
> > I had an intent to help you,
> 
> That's fine.  As I pointed out in my email, I need to know what I'm
> sending to Linus.
> 
> > So can you please share with us your plans on how-to address the
> > general lack of "communication, transparency and coordination",
> > which is definitely happen here?
> 
> I could always just artificially limit each release to no more than 100
> patches or something like that.  Then I would have more time per patch
> to be communicative.  But that wouldn't make people happy, it would take
> months and years to get things done.

Most of the patches are fixes and a lot of them one line only. They can
be acknowledged and applied in more timely manner. This will definitely
remove the tension.

For example, I have a build warning fix for hfi1 driver, but I prefer
don't send it till I see their fixes are applied.

> 
> But you guys are only partially mad at me.  I'm not the sole
> person/group holding you up from getting your way.

You are the one who makes decision, and not other persons/groups.

> For example the LSO
> patches aren't in, and that because they are an API extension that not
> everyone understands what LSO in that context means.  The patch set
> needs more explanation so that others can actually say if it's generic
> enough to meet their needs.

I agree with you and this is why we are posting it on the ML and adjust
the patches to answer on the feedback.

I don't see it is a blocker, but as a part of open discussion to adjust
patches to meet upstream criteria.

> You guys have a ton of features you want to
> get into the kernel, each one being a different sort of hardware
> offload, and while you may have worked with customers to do the initial
> creation, you didn't work with the community on describing them or
> anything else, and you bring them here fully done to your satisfaction,
> and it takes other people time to wrap their head around what they are,
> whether or not they might be usable in their own hardware, and then to
> decide if the design as presented would work for them if they did decide
> to implement it.  Without their input, I'm left in a rather untenable
> position.  And frankly, I'm rather sick of being in that position.

What is wrong with SELinux patches?

> 
> I'm quickly coming to agree with the results of the collaboration summit
> in that if a patch set implements a new feature in the form of a user
> visible API change (aka, a new flag to create_qp or a change to user
> visible work completions, that sort of thing), then patches will need
> buy in from other vendors before I'll accept them (where buy in means
> they've read it, they've understood it, and they've publicly given their
> Acked-by: line....silence does not equal buy in!).

There are three issues with this request:
1. It is not silence, but readiness to merge, since all feedback is
answered and everything is understandable. LSO patches are great
example for it, if the people don't understand they will ask and will
request to adjust patches accordingly.
2. It will limit ability to move IB stack further and will eliminate
fair competitive market.
3. According to IBTA [1], there are almost no HW vendors in this field.

[1] http://www.infinibandta.org/content/pages.php?pg=products_overview

> 
> -- 
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
> 
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]

On 05/15/2016 02:00 AM, Leon Romanovsky wrote:
> On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
>> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
>>> On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
>>>
>>> <snip>
>>>
>>> I had an intent to help you,
>>
>> That's fine.  As I pointed out in my email, I need to know what I'm
>> sending to Linus.
>>
>>> So can you please share with us your plans on how-to address the
>>> general lack of "communication, transparency and coordination",
>>> which is definitely happen here?
>>
>> I could always just artificially limit each release to no more than 100
>> patches or something like that.  Then I would have more time per patch
>> to be communicative.  But that wouldn't make people happy, it would take
>> months and years to get things done.
> 
> Most of the patches are fixes and a lot of them one line only. They can
> be acknowledged and applied in more timely manner. This will definitely
> remove the tension.
> 
> For example, I have a build warning fix for hfi1 driver, but I prefer
> don't send it till I see their fixes are applied.

I don't know what you are talking about.  All of their approved fixes
*have* been applied, and commented as such on list.

>> You guys have a ton of features you want to
>> get into the kernel, each one being a different sort of hardware
>> offload, and while you may have worked with customers to do the initial
>> creation, you didn't work with the community on describing them or
>> anything else, and you bring them here fully done to your satisfaction,
>> and it takes other people time to wrap their head around what they are,
>> whether or not they might be usable in their own hardware, and then to
>> decide if the design as presented would work for them if they did decide
>> to implement it.  Without their input, I'm left in a rather untenable
>> position.  And frankly, I'm rather sick of being in that position.
> 
> What is wrong with SELinux patches?

They need time for people to think about them.  You call them the
SELinux patches, but that is somewhat misleading.  When I think of
SELinux, I think of things like limited context server applications
("Can httpd read home directories?", "Can dovecot write to home
direcories?  Can dovecot listen on port 993? 995?", etc.)  It's very
general purpose and has a lot of policy that goes with it.  From what I
read, these patches are different.  They are mainly used to enforce the
subnet manager's P_Key policy.  There isn't anything else they do.  From
that standpoint, they look like the user space half of the namespace
equation.  But they're devoid of any of the other policy decisions that
SELinux often makes.  I haven't read them closes enough to see if they
could be easily extended to implement any of these other types of policy
or not, but that's certainly an issue.  If you are going to go monkeying
around in the SELinux subsystem (and 7 of the 12 patches do), then
making sure we do things in a manner that is not going to paint us into
a corner seems appropriate.  I haven't had the time to do that level of
looking at these patches.

> There are three issues with this request:
> 1. It is not silence, but readiness to merge, since all feedback is
> answered and everything is understandable. LSO patches are great
> example for it, if the people don't understand they will ask and will
> request to adjust patches accordingly.

No, you don't merge things before they are understood and then adjust
them.  You merge things you already understand.

> 2. It will limit ability to move IB stack further and will eliminate
> fair competitive market.

Competition is not a valid reason to merge poorly understood or poorly
designed code.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Mon, May 16, 2016 at 04:15:45PM -0400, Doug Ledford wrote:
> On 05/15/2016 02:00 AM, Leon Romanovsky wrote:
> > On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
> >> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
> >>> On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
> > There are three issues with this request:
> > 1. It is not silence, but readiness to merge, since all feedback is
> > answered and everything is understandable. LSO patches are great
> > example for it, if the people don't understand they will ask and will
> > request to adjust patches accordingly.
> 
> No, you don't merge things before they are understood and then adjust
> them.  You merge things you already understand.
> 
> > 2. It will limit ability to move IB stack further and will eliminate
> > fair competitive market.
> 
> Competition is not a valid reason to merge poorly understood or poorly
> designed code.

No one expects to see this code merged, this is why I gave LSO as an
example: people don't understand -> they ask questions, exactly as was
in LSO, and it is OK that this code wasn't merged due to limited
explanation which will be improved in next version.

The not OK is to expect from hardware vendors better review than
community can perform.

Hardware vendors signature in the limited IB world won't help to anyone
to get good commit messages or better design.

These patches are written by engineers for other engineers for real use
and not for marketing purposes.

> 
> -- 
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
> 
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Prepared RDMA Tree for 4.7

[Daniel Jurgens]

On 5/16/2016 3:15 PM, Doug Ledford wrote:
> On 05/15/2016 02:00 AM, Leon Romanovsky wrote:
>> On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
>>> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
>>>> On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:


>>
>> What is wrong with SELinux patches?
> 
> They need time for people to think about them.  You call them the
> SELinux patches, but that is somewhat misleading.  When I think of
> SELinux, I think of things like limited context server applications
> ("Can httpd read home directories?", "Can dovecot write to home
> direcories?  Can dovecot listen on port 993? 995?", etc.)  It's very

The patches are intended to allow exactly that.  Extend the SELinux
policy language to support controlling access to Infiniband partitions.

> general purpose and has a lot of policy that goes with it.  From what I
> read, these patches are different.  They are mainly used to enforce the
> subnet manager's P_Key policy.  There isn't anything else they do.  From

They don't have anything to do with the subnet managers PKey policy.
They enforce SELinux policy to restrict access to partitions.

> that standpoint, they look like the user space half of the namespace
> equation.  But they're devoid of any of the other policy decisions that
> SELinux often makes.  I haven't read them closes enough to see if they
> could be easily extended to implement any of these other types of policy
> or not, but that's certainly an issue.  If you are going to go monkeying
> around in the SELinux subsystem (and 7 of the 12 patches do), then
> making sure we do things in a manner that is not going to paint us into
> a corner seems appropriate.  I haven't had the time to do that level of
> looking at these patches.

Changes to the SELinux subsystem are required to support the changes to
the policy language to label Infiniband pkeys and devices and to provide
an access control query interface.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html