From: Al Viro <viro@zeniv.linux.org.uk>
To: Qinghua Jin <qhjin.dev@gmail.com>
Cc: Colin Ian King <colin.king@canonical.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] vfs: fix bug when opening a file with O_DIRECT on a file system that does not support it will leave an empty file
Date: Tue, 4 Jan 2022 21:40:20 +0000 [thread overview]
Message-ID: <YdS+xJMYbBMJBTcH@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <CACL7WENRAkZKo5sx5HvRJ_e9KXmM-SyOutb8BAthJzfH1b2vDA@mail.gmail.com>
On Wed, Jan 05, 2022 at 05:23:30AM +0800, Qinghua Jin wrote:
> OK, thanks.
> So, how to resolve this bug? I think we should check the param before
> creating the inode and dentry. Maybe the best place is in the lookup_open
> where the last component get created, and the parent inode and child inode
> is in the same filesystem, so I think we can use
> dir_inode->i_mapping->a_ops->direct_IO to check the O_DIRECT param. The
> code looks like this:
> if((open_flag & O_CREAT) && (open_flag & O_DIRECT)) {
> if (!dir_inode->i_mapping || !dir_inode->i_mapping->a_ops ||
> !dir_inode->i_mapping->a_ops->direct_IO)
> return ERR_PTR(-EINVAL);
> }
> should do the work.
Why would it? Seriously, why would directories' use of page cache resemble that
by the regular files on the same fs? Sure, for minixfs we have that - directory
contents there happens to be stored in exact same way as for regular files.
For many other filesystem types it's not true.
Incidentally, how would an inode possibly get NULL ->i_mapping? Or NULL
->a_ops, for that matter (IOW, the existing check is also partially
cargo-culted)...
next prev parent reply other threads:[~2022-01-04 21:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 9:42 Qinghua Jin
[not found] ` <YdRdBcUAp7Mgp4pV@zeniv-ca.linux.org.uk>
[not found] ` <CACL7WENRAkZKo5sx5HvRJ_e9KXmM-SyOutb8BAthJzfH1b2vDA@mail.gmail.com>
2022-01-04 21:40 ` Al Viro [this message]
2022-01-06 13:52 ` [vfs] bf75e8b684: WARNING:possible_recursive_locking_detected kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YdS+xJMYbBMJBTcH@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=colin.king@canonical.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qhjin.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®