Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp503519pxb; Wed, 22 Sep 2021 07:02:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5nWpjwiGWHqpVuvauIQJHj4XechBLsVMuI+cdei4wxnmFBcOy1tv/RKXHFPtlwhWiYlbe X-Received: by 2002:a6b:5114:: with SMTP id f20mr4497072iob.97.1632319354278; Wed, 22 Sep 2021 07:02:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632319354; cv=none; d=google.com; s=arc-20160816; b=rT60/HUB4oag0eRvNQaMzerWtcnaHDPbletUOJDGYamb48b4wSbbBwWOjeIDRlVDGj sgg1OzaSOfiPgUgTdrTMy7zetyfRqgHKtFsKVs7KalXcIGajIzOS2ZFsr7MbLL+06HVj DCV84T3ChXoWsGaF3CjvCsEl2JPqgfm8jWzAqxleY+rwaCtyUDC3UwEBQPjGLikJNFhU ZLE8oe2rlcMLb5+R9b/8EaxX8Gw9s3ObJAhvBMLH90rULmjvZtOOkxSOieUQKvtdi1p4 clA5yBygF18JoZe6Pkf11I121MZTmS/5ALNvX4g9HF20BWvLnVpcjdE+AlZuaGvqOlO/ pwEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=/PFaCHE2WPQbR8drQXuuWr5Eu0qa3Smkwzq6UOruVoI=; b=eH0qoA2FL+5rjRCLVy3JJVkZM/ORYlTW88Cf9my9W/2SXO+IiqDfrl0vcIqgvz0i02 0rDdkNIgywmKLYgC7YSD+UMT/rGp1oMVOgraUb+g69lkrljftB1GKTZOS/0Q9iaOSSmG BnqRbvsMd7+39Q3AjVN6JAeNB4xy5A0q189NJ2P+lPaeuZpnKBUI/GBz8Lj4DZKwY8/U ZypzG1oug8ZhAcllS1V+LqCkZm/imIotKPup9YBs1ZLU2c+iCV4lFpvTometgrM9YWYg Mr8N2QA8efmiEa7lSTjIUPF3D4lFxOl4kXQTXI0wNPsZOKoH5+coZKfqqtrmGJTicOLw OFDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=XmOBm56H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m47si2239956jaf.133.2021.09.22.07.01.56; Wed, 22 Sep 2021 07:02:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=XmOBm56H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232199AbhIVOCa (ORCPT + 99 others); Wed, 22 Sep 2021 10:02:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234346AbhIVOC3 (ORCPT ); Wed, 22 Sep 2021 10:02:29 -0400 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89801C061757 for ; Wed, 22 Sep 2021 07:00:59 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id n17so3023284vsr.10 for ; Wed, 22 Sep 2021 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/PFaCHE2WPQbR8drQXuuWr5Eu0qa3Smkwzq6UOruVoI=; b=XmOBm56HjqwB5qD9VVdHzC/i8Edr+mLRECUuTTW3RVWZW26D1FuP0VcRWWRx7bB25l DRDY76/ZERZ8y1/wnstMEheh5w6tN7bqeMdkj3ssQxSWpnqX5VDNT1Lz40Tc4DqOY4PR mCH5FG+dkzmz+C4mIegeKS1PI6bZRNlhhWfEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/PFaCHE2WPQbR8drQXuuWr5Eu0qa3Smkwzq6UOruVoI=; b=GdZ0J+6xebjYYBor5p9dlLLUU6OfxhCASPbaKA23HFx/jfZ+Y938HIlJJLn1w6fSSe +kA0zrvnmkE3LwTNETbzfMhL2Duviq+oNeYeodlkAi2SvGNdsWv6FI/dbdfIzYPsh4IC rplbYiHAgw6KO8RwtpQS8CI6MxvRH9Qfd4GgMFbGs/y4Ig2ytC33BD+Dt9FkS2szZidg /T4UJ58HQf//ir40e+desFLJdFJIG8Dc228CBSPFTI5H+OQAgM40O5Dnvm1qYPavHUJ9 jz/371AhpNSFvVFgXdyXZ1omNQEGit0FEgQCPd9LgVI3d9E2DvseVhQ5Dull6xsr5zJJ 784g== X-Gm-Message-State: AOAM5320vPWFS80XJQTr91HuOF7vDQDecA864symwDrU9UeXf5YR+rwW z5o+ha6Qp3pE0eBg7cqUSctZra7ySC1pMes+TfD+5A== X-Received: by 2002:a05:6102:40f:: with SMTP id d15mr18784743vsq.51.1632319258613; Wed, 22 Sep 2021 07:00:58 -0700 (PDT) MIME-Version: 1.0 References: <9ef909de-1854-b4be-d272-2b4cda52329f@oppo.com> <20210922072326.3538-1-huangjianan@oppo.com> <919e929d-6af7-b729-9fd2-954cd1e52999@oppo.com> <314324e7-02d7-dc43-b270-fb8117953549@139.com> In-Reply-To: <314324e7-02d7-dc43-b270-fb8117953549@139.com> From: Miklos Szeredi Date: Wed, 22 Sep 2021 16:00:47 +0200 Message-ID: Subject: Re: [PATCH v3] ovl: fix null pointer when filesystemdoesn'tsupportdirect IO To: Chengguang Xu Cc: Huang Jianan , overlayfs , linux-erofs@lists.ozlabs.org, xiang@kernel.org, chao@kernel.org, guoweichao@oppo.com, yh@oppo.com, zhangshiming@oppo.com, guanyuwei@oppo.com, jnhuang95@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Chengguang Xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 Sept 2021 at 15:21, Chengguang Xu wrote: > > =E5=9C=A8 2021/9/22 16:24, Huang Jianan =E5=86=99=E9=81=93: > > > > > > =E5=9C=A8 2021/9/22 16:06, Chengguang Xu =E5=86=99=E9=81=93: > >> =E5=9C=A8 2021/9/22 15:23, Huang Jianan =E5=86=99=E9=81=93: > >>> From: Huang Jianan > >>> > >>> At present, overlayfs provides overlayfs inode to users. Overlayfs > >>> inode provides ovl_aops with noop_direct_IO to avoid open failure > >>> with O_DIRECT. But some compressed filesystems, such as erofs and > >>> squashfs, don't support direct_IO. > >>> > >>> Users who use f_mapping->a_ops->direct_IO to check O_DIRECT support, > >>> will read file through this way. This will cause overlayfs to access > >>> a non-existent direct_IO function and cause panic due to null pointer= : > >> > >> I just looked around the code more closely, in open_with_fake_path(), > >> > >> do_dentry_open() has already checked O_DIRECT open flag and > >> a_ops->direct_IO of underlying real address_space. > >> > >> Am I missing something? > >> > >> > > > > It seems that loop_update_dio will set lo->use_dio after open file > > without set O_DIRECT. > > loop_update_dio will check f_mapping->a_ops->direct_IO but it deal > > with ovl_aops with > > noop _direct_IO. > > > > So I think we still need a new aops? > > > It means we should only set ->direct_IO for overlayfs inodes whose > underlying fs has DIRECT IO ability. First let's fix the oops: ovl_read_iter()/ovl_write_iter() must check real file's ->direct_IO if IOCB_DIRECT is set in iocb->ki_flags and return -EINVAL if not. To fix the loop -> overlay -> squashfs case your suggestion of having separate aops depending on the real inode's ->direct_IO sounds good. Thanks, Miklos