On Tue, Oct 03, 2017 at 08:02:22PM +0000, Bart Van Assche wrote: > On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote: > > +static bool super_allows_freeze(struct super_block *sb) > > +{ > > + return !!(sb->s_type->fs_flags & FS_FREEZE_ON_SUSPEND); > > +} > > A minor comment: if "!!" would be left out the compiler will perform the > conversion from int to bool implicitly For all compilers? > so I propose to leave out the "!!" and parentheses. OK! > Anyway, I agree with the approach of this patch and I think > that freezing filesystems before processes are frozen would be a big step > forward. Great! But please note, the current implementation calls fs_suspend_freeze() *after* try_to_freeze_tasks(), ie: this implementation freezes userspace and only after then filesystems. Order will be *critical* here to get right, so we should definitely figure out if this is definitely the right place (TM) to call fs_suspend_freeze(). Lastly, a final minor implementation note: I think using a PM notifier would have been much cleaner, in fact it was my the way I originally implemented this orthogonally to Jiri's work, however to get this right the semantics of __pm_notifier_call_chain() would need to be expanded with another state, perhaps PM_USERSPACE_FROZEN, for example. I decided in the end a new state was not worth it give we would just have one user: fs freezing. So to be clear using a notifier to wrap this code into the fs code and not touching kernel/power/process.c is not possible with today's semantics nor do I think its worth it to expand on these semantics. This approach is explicit about order and requirements for those that should care: those that will maintain kernel/power/process.c and friends. Having this in a notifier would shift this implicitly. Luis -- 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