On Sun, 2016-02-07 at 22:24 +0000, Rainer Weikusat wrote: > Rainer Weikusat <rw@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes: > > [...] > > > The start uses that to record an error which might need to be > > reported, the return statement uses it to indicate that an error has > > occurred. Hence, some kind of in-between translation must occur. The > > mutex_lock_interruptible happened to do that but that was never it's > > intended purpose. > > Additional information: The 'trick' of using recvmsg w/o a receive > buffer in order to retrieve control messages in fact wouldn't have > worked with the unix_stream_recvmsg prior to introduction of the > interruptible lock as that (judging from the git source) would have > triggered all the same issues, > > - -EOPNOTSUP if a msg was available > > - -EAGAIN if the code had to wait > > - not receiving the creds if the -EAGAIN hadn't happened because > of the continue (that's the other patch) > > IOW, that's a feature inadvertendly added by an otherwise useless code > change (mea culpa). This is exactly the needed information for stable teams. Goal is here is not to blame someone (you, me ... it does not matter) , but give to stable teams the point the problem showed up. See the 'Fixes' tag as a time saver for people like me. It is incredibly useful when hutting bugs, because each commit can easily point to the 'bug origin'. Having spent time lately in af_unix code insanity, I really can tell. At the time someone fixes a bug, he/she has a clear view of what is happening, but months later, he/she often has to start again the commits analysis. Thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html