On Tue, Sep 06, 2016 at 05:53:59PM -0400, CAI Qian wrote:
>
>
> ----- Original Message -----
> > Fundamentally a splice infrastructure problem. If we let splice race
> > with hole punch and other fallocate() based extent manipulations to
> > avoid this lockdep warning, we allow potential for read or write to
> > regions of the file that have been freed. We can live with having
> > lockdep complain about this potential deadlock as it is unlikely to
> > ever occur in practice. The other option is simply not an acceptible
> > solution....
> The problem with living with having this lockdep complain that
> it seems once this lockdep happens, it will prevent other complains from
> showing up. For example, I have to apply the commit dc3a04d to fix an early
> rcu lockdep first during the bisecting.
Not my problem.
My primary responsibility is to maintain the filesystem integrity
and data safety for the hundreds of thousands (millions?) of XFS
users: it's their data, and I will always err on the side of safety
and integrity. As such I really don't care if there's collateral
damage to developer debug tools - user data integrity requirements
always come first...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|