On Fri, 2016-04-08 at 01:01 +0200, Christoph Hellwig wrote: > On Thu, Apr 07, 2016 at 03:29:41PM -0700, Nicholas A. Bellinger wrote: > > I asked to not revert the percpu_ida conversion and again you simply > > ignored subsystem maintainer feedback, and included a different > > percpu_ida conversion without using alloc_session callback that still > > does pre-allocation of buffers before session login even completes. > > He doesn't revert it after the patch series, but reverts it first > to then do it properly. If you don't like that it's fine to ask > Bart to resend with a different patch ordering, but it would be really > helpful to do it politely. I've already taken the time to send out a patch to address the regression for v4.6-rc. If there is a problem with that patch he should comment with the specifics of the issue he found, and not revert for v4.6 and do his own thing for v4.7. > > > The whole point of the alloc_session callback is so that extra > > pre-allocation doesn't happen until after se_node_acl lookup has > > finished, and is what ib_srpt needs to be using given SRP's completely > > existent spec level security model. > > Your original patch didn't use the alloc_session callback either, > so I don't really see the fuzz here. I don't see how it makes things > clearer, but if you ask politely, and provide a detailed and valid > explanation I'm pretty sure Bart will adopt the series to your taste. > > > > > In any event, I'm fixing the regression ahead of the next v4.6-rc PULL > > in: > > > > http://www.spinics.net/lists/target-devel/msg12535.html > > > > Any issues you find with this patch should be sent out as an incremental > > patch, and not rolling your own concoction. > > That patch doesn't work. While it's great to have a maintainer that > sets overall architectural direction it also really helps to work nicely > with contributors that have detailed experience with the transport (or in > this case even wrote the original driver). > Yep, will address for -v2 after verifying with IB ports. > I think a lot of these disagreements could be sorted out much better if > you work with Bart at a technical level rather than having a personal > vandetta. It's nice that Bart has decided to wake up after 5 years of inactivity while I've been maintaining ib_srpt during that time. I'll let the failed attempt at high-jacking the upstream target drivers be water under the bridge, but if he continues to ignore feedback and constantly mix-up unrelated issues at every opportunity like with the TMR stuff, plus ib_srpt patches never make it on target-devel, don't expect me to be in a particularly friendly mood. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
