[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4BCCB9U10mkiehu@ZenIV>
Date: Fri, 25 Nov 2022 04:18:16 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Cc: Nitesh Shetty <nj.shetty@...sung.com>, axboe@...nel.dk,
agk@...hat.com, snitzer@...nel.org, dm-devel@...hat.com,
kbusch@...nel.org, hch@....de, sagi@...mberg.me,
james.smart@...adcom.com, kch@...dia.com, naohiro.aota@....com,
jth@...nel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-fsdevel@...r.kernel.org, anuj20.g@...sung.com,
joshi.k@...sung.com, p.raghav@...sung.com, nitheshshetty@...il.com,
gost.dev@...sung.com
Subject: Re: [PATCH v5 10/10] fs: add support for copy file range in zonefs
On Thu, Nov 24, 2022 at 10:47:55AM +0900, Damien Le Moal wrote:
> >> + inode_lock(src_inode);
> >> + inode_lock(dst_inode);
> >
> > So you did zonefs_copy_file_checks() outside of these locks, which mean
> > that everything about the source and destination files may have changed.
> > This does not work.
>
> I forgot to mention that locking 2 inodes blindly like this can leads to
> deadlocks if another process tries a copy range from dst to src at the
> same time (lock order is reversed and so can deadlock).
Not to mention the deadlocks with existing places where fs/namei.c locks
two inodes...
Powered by blists - more mailing lists