On Wed, 2017-02-08 at 23:04 +0000, Bart Van Assche wrote: > On Wed, 2017-02-08 at 14:49 -0800, Nicholas A. Bellinger wrote: > > On Wed, 2017-02-08 at 20:14 +0000, Bart Van Assche wrote: > > > On Wed, 2017-02-08 at 11:06 -0800, Nicholas A. Bellinger wrote: > > > > Adding a second atomic_t emulating a kref on top of the existing > > > > se_cmd->cmd_kref, and then doing a complete_all() for the special TMR > > > > path in the normal fast-path is not going to be acceptable. > > > > > > I don't see why that approach would not be acceptable. My patches remove > > > more atomic operations than the number of new atomic operations that are > > > introduced in the hot path so these patches will improve performance. > > > > You've got less than 24 hours of soak time [ ... ] > > You are irritating me, and it's not very smart to do that. Anyway, a good > kernel developer develops tests to reproduce race conditions in much less time > than 24 hours. Listen, my primary concern is the integrity of the code-paths that has taken us years to get stable. Based upon your actions, it looks like your primary concern is getting large untested and unreviewed changes that effect complex code-paths into linux-next, and into mainline. This, for a codebase that you don't have dedicated QA resources or automation assigned from your employer, nor production customers to answer to. So if you want to be a LIO maintainer, you'll need to starting answering to the LIO community for your actions. -- 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