On Mon, Mar 13, 2017 at 05:16:07PM -0500, Eric Sandeen wrote: > On 3/13/17 8:23 AM, Brian Foster wrote: > > I think some ASSERT(!ro) calls would be prudent in the newly reachable > > codepaths that would make modifications (in both xfs_release() and > > xfs_inactive()), just to catch any future bugs that would otherwise go > > undetected. Otherwise, both patches seem reasonable to me. > > Ok, well - we can't assert (!ro) because we /do/ get here in the early > stages of an ro mount. > Ok, I suppose we'd have to filter out from "mounting" context. That is only for the case where we run log recovery though, right? > I want to rework all this like Dave had suggested, but it's not getting > done this release cycle, and I thought a couple targeted changes like this > which fix the bug without making the code beautiful might still make it :) > > Maybe the best shortcut for now is to stash, remove, and replace the RO > mount flag like we do for log recovery itself, and clean it all up in > the next round. > Hmm, that does sound like a cleaner approach. Brian > -Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
