From: Al Viro <viro@ZenIV.linux.org.uk>
To: Martin Kepplinger <martink@posteo.de>
Cc: Chris Mason <clm@fb.com>,
linux-btrfs@vger.kernel.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: Don't check for file->private_data on open(). It is set by the core.
Date: Thu, 13 Nov 2014 22:14:41 +0000 [thread overview]
Message-ID: <20141113221441.GL7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5463A84A.8010606@posteo.de>
On Wed, Nov 12, 2014 at 07:34:50PM +0100, Martin Kepplinger wrote:
> > Btrfs uses this in the transaction start ioctl to record the transaction
> > handle being started. Ceph is the main user of the ioctl, and we could
> > setup a hash table if needed. But which call path in miscdevice is
> > doing this?
> >
> > With your patch in place, btrfs would end up overwriting the miscdevice
> > private_data field, which would probably cause problems.
> >
> > -chris
> >
>
> I think i was mistaken, sorry. misc_open() used to set
> file->private_data _only_ if you use set .open in struct file_operations.
>
> In current -next this changed and file->private_data is set to struct
> miscdevice on a (userspace's) open call (misc_open()) just in any case.
>
> You do set .open so this wouldn't affect you and this patch can be ignored.
More to the point, this function is not reachable from anything in
file_operations of any miscdevice. btrfs_ioctl != btrfs_control_ioctl...
prev parent reply other threads:[~2014-11-13 22:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 16:38 [PATCH] btrfs: Don't check for file->private_data on open(). It is set by the core Martin Kepplinger
2014-11-12 17:59 ` Chris Mason
2014-11-12 18:34 ` Martin Kepplinger
2014-11-13 22:14 ` Al Viro [this message]
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=20141113221441.GL7996@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=clm@fb.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martink@posteo.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.