(CC'ing Jeff) Ilya Dryomov <idryomov@xxxxxxxxx> writes: > On Fri, Mar 30, 2018 at 9:26 AM, Yan, Zheng <zyan@xxxxxxxxxx> wrote: >> >> >>> On 30 Mar 2018, at 15:20, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: >>> >>> On Fri, Mar 30, 2018 at 5:21 AM, Yan, Zheng <zyan@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On 30 Mar 2018, at 00:49, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: >>>>> >>>>> On Fri, Mar 16, 2018 at 4:32 AM, Yan, Zheng <zyan@xxxxxxxxxx> wrote: >>>>> >>>>> Hi Zheng, >>>>> >>>>> Can you explain how this fixes the invalid memory access reported in >>>>> "KASAN: use-after-free Read in set_page_dirty_lock"? Did you come up >>>>> with a different reproducer? >>>>> >>>> >>>> I don\u2019t know why KASAN reports use-after-free (like false alarm) in >>>> this case. I compared the code with other filesystem, found recent commits >>>> make other filesystems only dirty ITER_IOVEC pages. The change should also >>>> make KASAN silent. >>> >>> Did you manage to reproduce that KASAN report? >>> >> no >> >>> If it is a false positive, the patch shouldn't have been marked for >>> stable. >>> >> >> I CCed stable because fuse did the same >> >> commit 8fba54aebbdf1f999738121922e74bf796ad60ee >> Author: Miklos Szeredi <mszeredi@xxxxxxxxxx> >> Date: Wed Aug 24 18:17:04 2016 +0200 >> >> fuse: direct-io: don't dirty ITER_BVEC pages >> >> When reading from a loop device backed by a fuse file it deadlocks on >> lock_page(). >> >> This is because the page is already locked by the read() operation done on >> the loop device. In this case we don't want to either lock the page or >> dirty it. >> >> So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors. > > OK, so it is a potential deadlock which has nothing to do with that > KASAN report. I have rewritten the changelog to reflect that, please > take a look: > > https://github.com/ceph/ceph-client/commit/85784f9395987a422fa04263e7c0fb13da11eb5c Just as a side note, it's still trivial to get a cephfs-related KASAN report by running a fuzzer (trinity in my case) against a mainline kernel 4.16.0-rc7 with this fix backported. As Jeff mentioned in a different thread, splice syscall is broken on cephfs and the fix for it is still tagged as "DO NOT MERGE" in the ceph-client testing branch. I still think there's some bug in Jeff's fix as I still see a crash occasionally, but I haven't yet finished debugging it. Unfortunately, Jeff's fix is probably not appropriate for stable kernels (but may I'm wrong). Cheers, -- Luis -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
