On Tue, Jul 6, 2021 at 4:40 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > [ back looking at this from doing other merge window stuff ] > > On Sat, Jul 3, 2021 at 8:27 AM Dmitry Kadashev <dkadashev@xxxxxxxxx> wrote: > > > > This is how I originally thought it is going to be, but Al suggested > > that it eats the name on the failure. Now that I spent slightly > > more time with it I *suspect* the reason (or a part of it) is making it > > keep the name on failure would require A LOT of changes, since a lot of > > functions that __filename_create() calls eat the name on failure. > > Ok. > > Let's try to keep the changes minimal and simple. > > Your original approach with __filename_create() looks reasonable, if > we then just clean up the end result by making putname() ok with an > error pointer. > > The odd conditional putname() calls were the main issue that made me > go "this is just very ugly and confusing" > > How do the patches end up looking with just that cleanup (and some > clarifying comment about the very odd "out_putpath" case it had?) OK, I'll send v7 of the series soon and will CC you. Also, I've looked at the code again, and I think making __filename_create() and friends not consume the name (even on error) is not that much of extra work (but some existing code like filename_parentat() has to be adjusted, so it's still not completely trivial). I'll try to do that and will send RFC on top of this series, so if it turns out to look better / be easier to reason about we can just switch to that (in another release probably). Thank you for your help, Linus! -- Dmitry Kadashev
