On Fri, Mar 30, 2018 at 12:24 PM, Luis Henriques <lhenriques@xxxxxxxx> wrote: > (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. Right. This patch fixes a deadlock which is completely unrelated. The report which I was referring to is probably a by product of ceph splice brokenness in mainline and not a false positive. > > 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 Yes, that's why I asked Zheng about a different reproducer. The auto-generated one is based on splice, but it didn't trigger anything for me on testing (i.e. with Jeff's splice patches). > 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). Need to get it in mainline in some form first... Thanks, Ilya -- 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
