On Fri, Dec 8, 2017 at 2:13 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Dec 08, 2017 at 10:59:22AM +1100, Dave Chinner wrote:
>
>> > 3. if multi nested looped fs is important (not really) then loop/nbd will
>> > need to know if its file is on a looped fs and propagate nesting level
>> > to ext4
>>
>> This functionality is definitely used and needs to be supported by
>> the annotations.
>
> FWIW, in addition to loop, there's md.
Do you mean md can sit on a file directly without loop/nbd?
I am referring to loop/nbd, because those are the only ones I know
of that can be used to nest (non stackable) fs over fs.
> So should loop need to know if its
> backing file lives on a filesystem that does, for example, have an extrnal
> journal sitting on RAID1 with one of the components hosted in a file on
> some other fs, brought into the array via another loop device?
>
The nested depth accounting scheme I proposed is unneeded.
I think it should be enough to use a macro to annotate locks that
can go from fs into io for underlying blockdev,
e.g. (for Ted's lockdep splat):
init_rwsem(&meta_group_info[i]->alloc_sem);
lockdep_fsio(&meta_group_info[i]->alloc_sem, sb);
That can help isolate the annotation to a lockdep map attached
to the underlying blockdev/gendisk.
As you pointed out, this does not cover all the cases of fs that uses
multi blockdev for external journal or whatever, but even if we isolate
lockdep by the main (or any) blockdev of a filesystem, assuming this
blockdev is used exclusively by that fs instance, this would be enough
to mitigate the false positives from loop nested setups.
> Oh, and to make life even more fun, backing file can be flipped under
> configured /dev/loop. IOW, those nesting depths are not static at all.
In that case, lockdep would have been very right to warn us, because
we can actually create a deadlock by looping loop into a file that sits
inside fs on the loop device.
Amir.
