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
