On Mon 12-06-23 13:08:11, Jan Kara wrote:
> On Sun 11-06-23 20:15:22, Darrick J. Wong wrote:
> > +
> > if (sb->s_writers.frozen != SB_UNFROZEN) {
>
> I still find it strange that:
>
> Task1 Task2
>
> while (1) { while (1) {
> ioctl(f, FIFREEZE); freeze_super(sb, FREEZE_HOLDER_KERNEL);
> ioctl(f, FITHAW); thaw_super(sb, FREEZE_HOLDER_KERNEL);
> } }
>
> will randomly end up returning EBUSY to Task1 or Task2 although there is no
> real conflict. I think it will be much more useful behavior if in case of
> this conflict the second holder just waited for freezing procedure to finish
> and then report success. Because I don't think either caller can do
> anything sensible with this race other than retry but it cannot really
> distinguish EBUSY as in "someone other holder of the same type has the sb
> already frozen" from "freezing raced with holder of a different type".
I take this back, you solve the problem in patch 2 :). I'm sorry for the
noise.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
