[PATCH net 000/117] net: avoid to remove module when its debugfs is being used

Taehee Yoo <[email protected]>
Newsgroups org.infradead.lists.b43-dev,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-wireless,org.kernel.vger.netdev
Message-ID <CAMArcTWBdqRG11XcFPvPTR2YpwfdDMuQ-_7WGow574QftUEGYA@mail.gmail.com>
On Fri, 9 Oct 2020 at 14:39, Nicolai Stange <[email protected]> wrote:
>

Hi Nicolai,
Thank you for the review!

> Taehee Yoo <[email protected]> writes:
>
> > On Fri, 9 Oct 2020 at 01:14, Johannes Berg <[email protected]> wrote:
> > On Thu, 2020-10-08 at 15:59 +0000, David Laight wrote:
> >
> >> From: Taehee Yoo
> >> > Sent: 08 October 2020 16:49
> >> >
> >> > When debugfs file is opened, its module should not be removed until
> >> > it's closed.
> >> > Because debugfs internally uses the module's data.
> >> > So, it could access freed memory.
>
> Yes, the file_operations' ->release() to be more specific -- that's not
> covered by debugfs' proxy fops.
>
>
> >> > In order to avoid panic, it just sets .owner to THIS_MODULE.
> >> > So that all modules will be held when its debugfs file is opened.
> >>
> >> Can't you fix it in common code?
> >
> >> Yeah I was just wondering that too - weren't the proxy_fops even already
> >> intended to fix this?
> >
> > I didn't try to fix this issue in the common code(debugfs).
> > Because I thought It's a typical pattern of panic and THIS_MODULE
> > can fix it clearly.
> > So I couldn't think there is a root reason in the common code.
>
> That's correct, ->owner should get set properly, c.f. my other mail in
> this thread.
>

Thanks a lot for verifying it!
Taehee
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.