Re: [V9fs-developer] [PATCH 2/6] Don't assume UID 0 attach

[evanhensbergen]

Can you send me your xfstest invocation formulas and I’ll add them to my regression tests.

Yeah, I was torn on this merge window or next - the more complicated patches here are really fixes for things that are kinda broken in the code — so they might even be -rc candidate patches.  Most of them only effect cache mode, which isn’t default — so its probably low-risk, but I know the preference is for things to have had longer in the review cycle to marinate.

The simple ones probably could go into this merge window, but I leave it up to you since you’ve been carrying the maintainer mantle — and my PGP key and kernel.org repos need to be re-established in the web of trust, but mainly because you’re active maintainer here.

I’ll keep crunching and send out the new patch set by the end of the day regardless.

     -eric



> On Dec 18, 2022, at 1:49 PM, asmadeus@xxxxxxxxxxxxx wrote:
> 
> evanhensbergen@xxxxxxxxxx wrote on Sun, Dec 18, 2022 at 10:32:57AM -0600:
>> Okay, reproduced the error you suspected on the patch.  It’s kind of a
>> pain because the code as is won’t work unless I’m running the file
>> server as root and changing all the servers to ignore requests seems
>> off.  It also occurred to me that having a root R/W write back could
>> be a security vulnerability.  I tried patching it with
>> dfltuid/dfltgid, but only root can override the modes so that doesn’t
>> work.
>> 
>> Since I have the better write back fix testing okay, we could drop
>> this patch from the series and I could just focus on getting that
>> patch ready (which I should be able to do today).  It does seem to
>> work with the python test case you gave, so it doesn’t have the same
>> issues.
>> 
>> Thoughts?
> 
> That sounds good to me, thanks!
> 
> I haven't had time to look at the other patches in detail but they look
> good to me in principle.
> I'll try to find time to run some xfstests this week to check for
> regressions with the other patches (I don't have any list, so run some
> before/after with qemu in cache=mmap/loose modes perhaps?) and we can
> submit them next merge window unless you're in a hurry.
> Some are obvious fixes (not calling in fscache code in loose mode) and
> could get in faster but I don't think we should rush e.g. option
> parsing... Well that probably won't get much tests in -next, I'll leave
> that up to you.
> 
> Do you (still?) have a branch that gets merged in linux-next, or shall I
> take the patches in for that, or do you want to ask Stefen?
> (I should probably just check myself, but it's 5am and I'll be lazy)
> 
> -- 
> Dominique