This patch introduces an accessor which can be used
by the users of debugfs (drivers, fs, ...) to get the
original file_operations struct. It also removes the
REAL_FOPS_DEREF macro in file.c and converts the code
to use the public version.
Previously, REAL_FOPS_DEREF was only available within
the file.c of debugfs. But having a public getter
available for debugfs users is important as some
drivers (carl9170 and b43) use the pointer of the
original file_operations in conjunction with container_of()
within their debugfs implementations.
Reviewed-by: Nicolai Stange <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
fs/debugfs/file.c | 13 +++++--------
include/linux/debugfs.h | 17 +++++++++++++++++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 592059f..309f4e9 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -97,9 +97,6 @@ EXPORT_SYMBOL_GPL(debugfs_use_file_finish);
#define F_DENTRY(filp) ((filp)->f_path.dentry)
-#define REAL_FOPS_DEREF(dentry) \
- ((const struct file_operations *)(dentry)->d_fsdata)
-
static int open_proxy_open(struct inode *inode, struct file *filp)
{
const struct dentry *dentry = F_DENTRY(filp);
@@ -112,7 +109,7 @@ static int open_proxy_open(struct inode *inode, struct file *filp)
goto out;
}
- real_fops = REAL_FOPS_DEREF(dentry);
+ real_fops = debugfs_real_fops(filp);
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -143,7 +140,7 @@ static ret_type full_proxy_ ## name(proto) \
{ \
const struct dentry *dentry = F_DENTRY(filp); \
const struct file_operations *real_fops = \
- REAL_FOPS_DEREF(dentry); \
+ debugfs_real_fops(filp); \
int srcu_idx; \
ret_type r; \
\
@@ -176,7 +173,7 @@ static unsigned int full_proxy_poll(struct file *filp,
struct poll_table_struct *wait)
{
const struct dentry *dentry = F_DENTRY(filp);
- const struct file_operations *real_fops = REAL_FOPS_DEREF(dentry);
+ const struct file_operations *real_fops = debugfs_real_fops(filp);
int srcu_idx;
unsigned int r = 0;
@@ -193,7 +190,7 @@ static unsigned int full_proxy_poll(struct file *filp,
static int full_proxy_release(struct inode *inode, struct file *filp)
{
const struct dentry *dentry = F_DENTRY(filp);
- const struct file_operations *real_fops = REAL_FOPS_DEREF(dentry);
+ const struct file_operations *real_fops = debugfs_real_fops(filp);
const struct file_operations *proxy_fops = filp->f_op;
int r = 0;
@@ -241,7 +238,7 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
goto out;
}
- real_fops = REAL_FOPS_DEREF(dentry);
+ real_fops = debugfs_real_fops(filp);
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 1438e23..4d3f0d1 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -45,6 +45,23 @@ extern struct dentry *arch_debugfs_dir;
extern struct srcu_struct debugfs_srcu;
+/**
+ * debugfs_real_fops - getter for the real file operation
+ * @filp: a pointer to a struct file
+ *
+ * Must only be called under the protection established by
+ * debugfs_use_file_start().
+ */
+static inline const struct file_operations *debugfs_real_fops(struct file *filp)
+ __must_hold(&debugfs_srcu)
+{
+ /*
+ * Neither the pointer to the struct file_operations, nor its
+ * contents ever change -- srcu_dereference() is not needed here.
+ */
+ return filp->f_path.dentry->d_fsdata;
+}
+
#if defined(CONFIG_DEBUG_FS)
struct dentry *debugfs_create_file(const char *name, umode_t mode,
--
2.9.3
On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > Greg KH <[email protected]> writes:
> >
> > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > >> Ben Greear reported:
> > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > >> > My application is going to be poking at it's debugfs files...
> > >> >
> > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > >> > [carl9170] at addr ffff8801bc1208b0
> > >> > Read of size 8 by task btserver/5888
> > >> > =======================================================================
> > >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > >> > -----------------------------------------------------------------------
> > >> >
> > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > >> >...
> > >>
> > >> This breakage was caused by the introduction of intermediate
> > >> fops in debugfs by commit 9fd4dcece43a
> > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > >
> > > Because of this, these should all be backported to 4.7-stable, and
> > > 4.8-stable, right?
Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170
debugfs support is usually disabled.
Greg, would you take these four patches "as is" for -stable
or do you want a "minimal version" which just replaces the
dfops = container_of(file->f_op, ...
with
dfops = container_of(file->f_path.dentry->d_fsdata, ...
in the three drivers for -stable?
> > Via which tree should these go, Greg's or mine?
>
> I'll take it if you ack it, as it's a debugfs issue.
For carl9170: Ben Greear has reported:
"I have verified this fixes my problem in the 4.7 kernel."
But this was with a preliminary/minimal version so I didn't
add the tested-by tag.
As for b43, I'll see if I have a working b43 in my collection
somewhere to confirm the issue and the fix. Question is, do
you want to wait or not?
Regards,
Christian
This patch fixes a crash that happens because b43legacy's
debugfs code expects file->f_op to be a pointer to its own
b43legacy_debugfs_fops struct. This is no longer the case
since commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")
Reviewed-by: Nicolai Stange <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
drivers/net/wireless/broadcom/b43legacy/debugfs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/debugfs.c b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
index 090910e..82ef56e 100644
--- a/drivers/net/wireless/broadcom/b43legacy/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
@@ -221,7 +221,8 @@ static ssize_t b43legacy_debugfs_read(struct file *file, char __user *userbuf,
goto out_unlock;
}
- dfops = container_of(file->f_op, struct b43legacy_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct b43legacy_debugfs_fops, fops);
if (!dfops->read) {
err = -ENOSYS;
goto out_unlock;
@@ -287,7 +288,8 @@ static ssize_t b43legacy_debugfs_write(struct file *file,
goto out_unlock;
}
- dfops = container_of(file->f_op, struct b43legacy_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct b43legacy_debugfs_fops, fops);
if (!dfops->write) {
err = -ENOSYS;
goto out_unlock;
--
2.9.3
Greg KH <[email protected]> writes:
> On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
>> Greg KH <[email protected]> writes:
>>
>> > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
>> >> Ben Greear reported:
>> >> > I see lots of instability as soon as I load up the carl9710 NIC.
>> >> > My application is going to be poking at it's debugfs files...
>> >> >
>> >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
>> >> > [carl9170] at addr ffff8801bc1208b0
>> >> > Read of size 8 by task btserver/5888
>> >> > =======================================================================
>> >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
>> >> > -----------------------------------------------------------------------
>> >> >
>> >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>> >> >...
>> >>
>> >> This breakage was caused by the introduction of intermediate
>> >> fops in debugfs by commit 9fd4dcece43a
>> >> ("debugfs: prevent access to possibly dead file_operations at file open")
>> >
>> > Because of this, these should all be backported to 4.7-stable, and
>> > 4.8-stable, right?
>>
>> Via which tree should these go, Greg's or mine?
>
> I'll take it if you ack it, as it's a debugfs issue.
Good, thanks. The wireless patches look good to me so:
Acked-by: Kalle Valo <[email protected]>
--
Kalle Valo
On Sun, Sep 18, 2016 at 02:49:33PM +0200, Christian Lamparter wrote:
> On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> > On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > > Greg KH <[email protected]> writes:
> > >
> > > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > > >> Ben Greear reported:
> > > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > > >> > My application is going to be poking at it's debugfs files...
> > > >> >
> > > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > >> > [carl9170] at addr ffff8801bc1208b0
> > > >> > Read of size 8 by task btserver/5888
> > > >> > =======================================================================
> > > >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > > >> > -----------------------------------------------------------------------
> > > >> >
> > > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > > >> >...
> > > >>
> > > >> This breakage was caused by the introduction of intermediate
> > > >> fops in debugfs by commit 9fd4dcece43a
> > > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > > >
> > > > Because of this, these should all be backported to 4.7-stable, and
> > > > 4.8-stable, right?
> Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170
> debugfs support is usually disabled.
>
> Greg, would you take these four patches "as is" for -stable
> or do you want a "minimal version" which just replaces the
>
> dfops = container_of(file->f_op, ...
>
> with
>
> dfops = container_of(file->f_path.dentry->d_fsdata, ...
>
> in the three drivers for -stable?
No, I'll take this as is, we want things to remain as close as possible
to Linus's tree. When we are not, is when things break.
> > > Via which tree should these go, Greg's or mine?
> >
> > I'll take it if you ack it, as it's a debugfs issue.
> For carl9170: Ben Greear has reported:
> "I have verified this fixes my problem in the 4.7 kernel."
>
> But this was with a preliminary/minimal version so I didn't
> add the tested-by tag.
>
> As for b43, I'll see if I have a working b43 in my collection
> somewhere to confirm the issue and the fix. Question is, do
> you want to wait or not?
I'll queue these up this week, no rush.
thanks,
greg k-h
On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> Ben Greear reported:
> > I see lots of instability as soon as I load up the carl9710 NIC.
> > My application is going to be poking at it's debugfs files...
> >
> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > [carl9170] at addr ffff8801bc1208b0
> > Read of size 8 by task btserver/5888
> > =======================================================================
> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > -----------------------------------------------------------------------
> >
> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >...
>
> This breakage was caused by the introduction of intermediate
> fops in debugfs by commit 9fd4dcece43a
> ("debugfs: prevent access to possibly dead file_operations at file open")
>
> Thankfully, the original/real fops are still available in d_fsdata.
>
> Reported-by: Ben Greear <[email protected]>
> Reviewed-by: Nicolai Stange <[email protected]>
> Signed-off-by: Christian Lamparter <[email protected]>
> Acked-by: Kalle Valo <[email protected]>
> Cc: stable <[email protected]> # 4.7+
> ---
> drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/debug.c b/drivers/net/wireless/ath/carl9170/debug.c
> index 01a0919..ad7ffd5 100644
> --- a/drivers/net/wireless/ath/carl9170/debug.c
> +++ b/drivers/net/wireless/ath/carl9170/debug.c
> @@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file, char __user *userbuf,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
> struct carl9170_debugfs_fops, fops);
>
> if (!dfops->read)
> @@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
> struct carl9170_debugfs_fops, fops);
> if (!dfops->write)
> return -ENOSYS;
What tree is this against? I can't apply it to 4.8-rc5, or 4.8-rc7, are
you sure it is still needed?
thanks,
greg k-h
Greg KH <[email protected]> writes:
> On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
>> Ben Greear reported:
>> > I see lots of instability as soon as I load up the carl9710 NIC.
>> > My application is going to be poking at it's debugfs files...
>> >
>> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
>> > [carl9170] at addr ffff8801bc1208b0
>> > Read of size 8 by task btserver/5888
>> > =======================================================================
>> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
>> > -----------------------------------------------------------------------
>> >
>> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>> >...
>>
>> This breakage was caused by the introduction of intermediate
>> fops in debugfs by commit 9fd4dcece43a
>> ("debugfs: prevent access to possibly dead file_operations at file open")
>
> Because of this, these should all be backported to 4.7-stable, and
> 4.8-stable, right?
Via which tree should these go, Greg's or mine?
--
Kalle Valo
Ben Greear reported:
> I see lots of instability as soon as I load up the carl9710 NIC.
> My application is going to be poking at it's debugfs files...
>
> BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> [carl9170] at addr ffff8801bc1208b0
> Read of size 8 by task btserver/5888
> =======================================================================
> BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> -----------------------------------------------------------------------
>
> INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>...
This breakage was caused by the introduction of intermediate
fops in debugfs by commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")
Thankfully, the original/real fops are still available in d_fsdata.
Reported-by: Ben Greear <[email protected]>
Reviewed-by: Nicolai Stange <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/debug.c b/drivers/net/wireless/ath/carl9170/debug.c
index 01a0919..ad7ffd5 100644
--- a/drivers/net/wireless/ath/carl9170/debug.c
+++ b/drivers/net/wireless/ath/carl9170/debug.c
@@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file, char __user *userbuf,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_path.dentry->d_fsdata,
+ dfops = container_of(debugfs_real_fops(file),
struct carl9170_debugfs_fops, fops);
if (!dfops->read)
@@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_path.dentry->d_fsdata,
+ dfops = container_of(debugfs_real_fops(file),
struct carl9170_debugfs_fops, fops);
if (!dfops->write)
return -ENOSYS;
--
2.9.3
This patch fixes a crash that happens because b43's
debugfs code expects file->f_op to be a pointer to
its own b43_debugfs_fops struct. This is no longer
the case since commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")
Reviewed-by: Nicolai Stange <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
---
drivers/net/wireless/broadcom/b43/debugfs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/debugfs.c b/drivers/net/wireless/broadcom/b43/debugfs.c
index b4bcd94..7704638 100644
--- a/drivers/net/wireless/broadcom/b43/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43/debugfs.c
@@ -524,7 +524,8 @@ static ssize_t b43_debugfs_read(struct file *file, char __user *userbuf,
goto out_unlock;
}
- dfops = container_of(file->f_op, struct b43_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct b43_debugfs_fops, fops);
if (!dfops->read) {
err = -ENOSYS;
goto out_unlock;
@@ -585,7 +586,8 @@ static ssize_t b43_debugfs_write(struct file *file,
goto out_unlock;
}
- dfops = container_of(file->f_op, struct b43_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct b43_debugfs_fops, fops);
if (!dfops->write) {
err = -ENOSYS;
goto out_unlock;
--
2.9.3
Ben Greear reported:
> I see lots of instability as soon as I load up the carl9710 NIC.
> My application is going to be poking at it's debugfs files...
>
> BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> [carl9170] at addr 0xffff8801bc1208b0
> Read of size 8 by task btserver/5888
> =======================================================================
> BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> -----------------------------------------------------------------------
>
> INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>...
This breakage was caused by the introduction of intermediate
fops in debugfs by commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")
Thankfully, the original/real fops are still available in d_fsdata.
Reported-by: Ben Greear <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
Cc: stable <[email protected]> # 4.7+
---
drivers/net/wireless/ath/carl9170/debug.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/debug.c b/drivers/net/wireless/ath/carl9170/debug.c
index 6808db4..ec3a64e 100644
--- a/drivers/net/wireless/ath/carl9170/debug.c
+++ b/drivers/net/wireless/ath/carl9170/debug.c
@@ -75,7 +75,8 @@ static ssize_t carl9170_debugfs_read(struct file *file, char __user *userbuf,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_op, struct carl9170_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct carl9170_debugfs_fops, fops);
if (!dfops->read)
return -ENOSYS;
@@ -127,7 +128,8 @@ static ssize_t carl9170_debugfs_write(struct file *file,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_op, struct carl9170_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+ struct carl9170_debugfs_fops, fops);
if (!dfops->write)
return -ENOSYS;
--
2.9.3
On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> Greg KH <[email protected]> writes:
>
> > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> >> Ben Greear reported:
> >> > I see lots of instability as soon as I load up the carl9710 NIC.
> >> > My application is going to be poking at it's debugfs files...
> >> >
> >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> >> > [carl9170] at addr ffff8801bc1208b0
> >> > Read of size 8 by task btserver/5888
> >> > =======================================================================
> >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> >> > -----------------------------------------------------------------------
> >> >
> >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >> >...
> >>
> >> This breakage was caused by the introduction of intermediate
> >> fops in debugfs by commit 9fd4dcece43a
> >> ("debugfs: prevent access to possibly dead file_operations at file open")
> >
> > Because of this, these should all be backported to 4.7-stable, and
> > 4.8-stable, right?
>
> Via which tree should these go, Greg's or mine?
I'll take it if you ack it, as it's a debugfs issue.
thanks,
greg k-h
On Sunday, September 18, 2016 6:44:08 PM CEST Greg KH wrote:
> On Sun, Sep 18, 2016 at 02:49:33PM +0200, Christian Lamparter wrote:
> > On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> > > On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > > > Greg KH <[email protected]> writes:
> > > >
> > > > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > > > >> Ben Greear reported:
> > > > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > > > >> > My application is going to be poking at it's debugfs files...
> > > > >> >
> > > > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > > >> > [carl9170] at addr ffff8801bc1208b0
> > > > >> > Read of size 8 by task btserver/5888
> > > > >> > =======================================================================
> > > > >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > > > >> > -----------------------------------------------------------------------
> > > > >> >
> > > > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > > > >> >...
> > > > >>
> > > > >> This breakage was caused by the introduction of intermediate
> > > > >> fops in debugfs by commit 9fd4dcece43a
> > > > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > > > >
> > > > > Because of this, these should all be backported to 4.7-stable, and
> > > > > 4.8-stable, right?
> > Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170
> > debugfs support is usually disabled.
> >
> > Greg, would you take these four patches "as is" for -stable
> > or do you want a "minimal version" which just replaces the
> >
> > dfops = container_of(file->f_op, ...
> >
> > with
> >
> > dfops = container_of(file->f_path.dentry->d_fsdata, ...
> >
> > in the three drivers for -stable?
>
> No, I'll take this as is, we want things to remain as close as possible
> to Linus's tree. When we are not, is when things break.
>
> > > > Via which tree should these go, Greg's or mine?
> > >
> > > I'll take it if you ack it, as it's a debugfs issue.
> > For carl9170: Ben Greear has reported:
> > "I have verified this fixes my problem in the 4.7 kernel."
> >
> > But this was with a preliminary/minimal version so I didn't
> > add the tested-by tag.
> >
> > As for b43, I'll see if I have a working b43 in my collection
> > somewhere to confirm the issue and the fix. Question is, do
> > you want to wait or not?
>
> I'll queue these up this week, no rush.
I was able to sucessfully test the b43 patch on my iBook G4's BCM4306.
Thanks,
Christian
On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> Ben Greear reported:
> > I see lots of instability as soon as I load up the carl9710 NIC.
> > My application is going to be poking at it's debugfs files...
> >
> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > [carl9170] at addr ffff8801bc1208b0
> > Read of size 8 by task btserver/5888
> > =======================================================================
> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > -----------------------------------------------------------------------
> >
> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >...
>
> This breakage was caused by the introduction of intermediate
> fops in debugfs by commit 9fd4dcece43a
> ("debugfs: prevent access to possibly dead file_operations at file open")
Because of this, these should all be backported to 4.7-stable, and
4.8-stable, right?
thanks,
greg k-h
On Wednesday, September 21, 2016 12:13:25 PM CEST Greg KH wrote:
> On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > Ben Greear reported:
> > > I see lots of instability as soon as I load up the carl9710 NIC.
> > > My application is going to be poking at it's debugfs files...
> > >
> > > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > [carl9170] at addr ffff8801bc1208b0
> > > Read of size 8 by task btserver/5888
> > > =======================================================================
> > > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > > -----------------------------------------------------------------------
> > >
> > > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > >...
> >
> > This breakage was caused by the introduction of intermediate
> > fops in debugfs by commit 9fd4dcece43a
> > ("debugfs: prevent access to possibly dead file_operations at file open")
> >
> > Thankfully, the original/real fops are still available in d_fsdata.
> >
> > Reported-by: Ben Greear <[email protected]>
> > Reviewed-by: Nicolai Stange <[email protected]>
> > Signed-off-by: Christian Lamparter <[email protected]>
> > Acked-by: Kalle Valo <[email protected]>
> > Cc: stable <[email protected]> # 4.7+
> > ---
> > drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/debug.c b/drivers/net/wireless/ath/carl9170/debug.c
> > index 01a0919..ad7ffd5 100644
> > --- a/drivers/net/wireless/ath/carl9170/debug.c
> > +++ b/drivers/net/wireless/ath/carl9170/debug.c
> > @@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file, char __user *userbuf,
> >
> > if (!ar)
> > return -ENODEV;
> > - dfops = container_of(file->f_path.dentry->d_fsdata,
> > + dfops = container_of(debugfs_real_fops(file),
> > struct carl9170_debugfs_fops, fops);
> >
> > if (!dfops->read)
> > @@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
> >
> > if (!ar)
> > return -ENODEV;
> > - dfops = container_of(file->f_path.dentry->d_fsdata,
> > + dfops = container_of(debugfs_real_fops(file),
> > struct carl9170_debugfs_fops, fops);
> > if (!dfops->write)
> > return -ENOSYS;
>
> What tree is this against? I can't apply it to 4.8-rc5, or 4.8-rc7, are
> you sure it is still needed?
---
Yes, the patch is needed. That said I screwed this patch up and as a result
it is faulty. I'll send out v2 shortly
Thanks,
Christian
On Mon, Sep 19, 2016 at 10:12:08PM +0200, Christian Lamparter wrote:
> On Sunday, September 18, 2016 6:44:08 PM CEST Greg KH wrote:
> > On Sun, Sep 18, 2016 at 02:49:33PM +0200, Christian Lamparter wrote:
> > > On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> > > > On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > > > > Greg KH <[email protected]> writes:
> > > > >
> > > > > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > > > > >> Ben Greear reported:
> > > > > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > > > > >> > My application is going to be poking at it's debugfs files...
> > > > > >> >
> > > > > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > > > >> > [carl9170] at addr ffff8801bc1208b0
> > > > > >> > Read of size 8 by task btserver/5888
> > > > > >> > =======================================================================
> > > > > >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > > > > >> > -----------------------------------------------------------------------
> > > > > >> >
> > > > > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > > > > >> >...
> > > > > >>
> > > > > >> This breakage was caused by the introduction of intermediate
> > > > > >> fops in debugfs by commit 9fd4dcece43a
> > > > > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > > > > >
> > > > > > Because of this, these should all be backported to 4.7-stable, and
> > > > > > 4.8-stable, right?
> > > Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170
> > > debugfs support is usually disabled.
> > >
> > > Greg, would you take these four patches "as is" for -stable
> > > or do you want a "minimal version" which just replaces the
> > >
> > > dfops = container_of(file->f_op, ...
> > >
> > > with
> > >
> > > dfops = container_of(file->f_path.dentry->d_fsdata, ...
> > >
> > > in the three drivers for -stable?
> >
> > No, I'll take this as is, we want things to remain as close as possible
> > to Linus's tree. When we are not, is when things break.
> >
> > > > > Via which tree should these go, Greg's or mine?
> > > >
> > > > I'll take it if you ack it, as it's a debugfs issue.
> > > For carl9170: Ben Greear has reported:
> > > "I have verified this fixes my problem in the 4.7 kernel."
> > >
> > > But this was with a preliminary/minimal version so I didn't
> > > add the tested-by tag.
> > >
> > > As for b43, I'll see if I have a working b43 in my collection
> > > somewhere to confirm the issue and the fix. Question is, do
> > > you want to wait or not?
> >
> > I'll queue these up this week, no rush.
>
> I was able to sucessfully test the b43 patch on my iBook G4's BCM4306.
So is that a "Tested-by:"? :)