From: Alexey Dobriyan <adobriyan@sw.ru>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: /proc/bus/pci IOCTL breakage
Date: Fri, 27 Jul 2007 13:25:35 +0400 [thread overview]
Message-ID: <20070727092534.GB6924@localhost.sw.ru> (raw)
In-Reply-To: <20070726.230435.68159913.davem@davemloft.net>
On Thu, Jul 26, 2007 at 11:04:35PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 26 Jul 2007 19:07:51 -0700 (PDT)
>
> > Two ways to fix:
> >
> > 1) Make the PROC wrapper call ->unlocked_ioctl() or ->ioctl()
> > as a fallback of ->compat_ioctl is NULL.
> >
> > 2) Make proc_bus_pci_operations provide a .compat_ioctl method,
> > but then we'll need to audit the entire tree for cases like
> > this and make the same fix.
> >
> > Because it's easier to validate that all cases are covered,
> > I think #1 is the preferred fix.
>
> Here is my suggested fix.
>
> It is important to only provide the compat_ioctl method
> if the downstream de->proc_fops does too, otherwise this
> utterly confuses the logic in fs/compat_ioctl.c and we
> end up doing the right thing.
Indeed, my patch broke cases where .compat_ioctl was not supplied and
ioctl was done with compat_sys_ioctl().
> To be honest, the other unlocked_ioctl fallback scheme in
> this file should be scrutinized for similar problems.
I checked on test module all (3 + 3 + 1) x 2 combinations of available
methods and ioctl/compat_ioctl accesses. Regression were only in
compat_sys_ioctl(2) part. And your patch fixes all of them.
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -386,6 +386,19 @@ static const struct file_operations proc_reg_file_ops = {
> .release = proc_reg_release,
> };
>
> +#ifdef CONFIG_COMPAT
> +static const struct file_operations proc_reg_file_ops_no_compat = {
> + .llseek = proc_reg_llseek,
> + .read = proc_reg_read,
> + .write = proc_reg_write,
> + .poll = proc_reg_poll,
> + .unlocked_ioctl = proc_reg_unlocked_ioctl,
> + .mmap = proc_reg_mmap,
> + .open = proc_reg_open,
> + .release = proc_reg_release,
> +};
> +#endif
> +
> struct inode *proc_get_inode(struct super_block *sb, unsigned int ino,
> struct proc_dir_entry *de)
> {
> @@ -413,8 +426,15 @@ struct inode *proc_get_inode(struct super_block *sb, unsigned int ino,
> if (de->proc_iops)
> inode->i_op = de->proc_iops;
> if (de->proc_fops) {
> - if (S_ISREG(inode->i_mode))
> - inode->i_fop = &proc_reg_file_ops;
> + if (S_ISREG(inode->i_mode)) {
> +#ifdef CONFIG_COMPAT
> + if (!de->proc_fops->compat_ioctl)
> + inode->i_fop =
> + &proc_reg_file_ops_no_compat;
> + else
> +#endif
> + inode->i_fop = &proc_reg_file_ops;
> + }
> else
> inode->i_fop = de->proc_fops;
> }
Looks good, thanks David.
prev parent reply other threads:[~2007-07-27 9:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 2:07 /proc/bus/pci IOCTL breakage David Miller
2007-07-27 6:04 ` David Miller
2007-07-27 9:25 ` Alexey Dobriyan [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=20070727092534.GB6924@localhost.sw.ru \
--to=adobriyan@sw.ru \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
/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