public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: linux-kernel@vger.kernel.org
Cc: adobriyan@sw.ru
Subject: Re: /proc/bus/pci IOCTL breakage
Date: Thu, 26 Jul 2007 23:04:35 -0700 (PDT)	[thread overview]
Message-ID: <20070726.230435.68159913.davem@davemloft.net> (raw)
In-Reply-To: <20070726.190751.66179795.davem@davemloft.net>

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.

To be honest, the other unlocked_ioctl fallback scheme in
this file should be scrutinized for similar problems.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 94e2c1a..a5b0dfd 100644
--- 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;
 		}

  reply	other threads:[~2007-07-27  6:04 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 [this message]
2007-07-27  9:25   ` Alexey Dobriyan

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=20070726.230435.68159913.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=adobriyan@sw.ru \
    --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