Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Tue, Jun 23, 2020 at 01:04:02PM -0500, Eric W. Biederman wrote: >> >> Sigh. I was busy last week so I left reading this until now in the >> hopes I would see something reasonable. >> >> What I see is rejecting of everything that is said to you. >> >> What I do not see are patches fixing issues. I will await patches. > > huh? > I can say exactly the same. You keep ignoring numerous points I brought up. > You still haven't showed what kind of refactoring you have in mind and > why fork_blob is in its way. That is correct. What I wind up doing with exec is irrelevant. What is relevant is getting correct working code on the fork_blob path. Something that is clean enough that whatever weird things it winds up doing are readable. The way things are intermingled today it took 2 years for someone to realize there was a basic reference counting bug. This isn't work anyone else can do because there are not yet any real in tree users of fork_blob. The fact that no one else can make substantials changes to the code because it has no users is what gets in the way of maintenance. One of the 2 year old bugs that needs to be fixed is that some LSMs work in terms of paths. Tetsuo has been very gracious in pointing that out. Either a path needs to be provided or the LSMs that work in terms of paths need to be fixed. Now I really don't care how the bugs are fixed. My recomendation for long term maintenance is to split fork_blob into 2 functions: fs_from_blob, and the ordinary call_usermodehelper_exec. That removes the need for any special support for anything in the exec path because your blob will also have a path for your file, and the file in the filesystem can be reused for restart. That feels like the least long term work on everyone. But with no in-tree users none of us can do anything bug guess what the actual requirements of fork_usermode_blob are. So patches to fix the bugs please. Eric
