All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taehee Yoo <ap420073@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: David Miller <davem@davemloft.net>,
	Netdev <netdev@vger.kernel.org>,
	David Laight <David.Laight@aculab.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Nicolai Stange <nstange@suse.de>,
	derosier@gmail.com, Kalle Valo <kvalo@codeaurora.org>,
	linux-wireless@vger.kernel.org, wil6210@qti.qualcomm.com,
	b43-dev@lists.infradead.org, linux-bluetooth@vger.kernel.org,
	michael.hennerich@analog.com, linux-wpan@vger.kernel.org,
	stefan@datenfreihafen.org, inaky.perez-gonzalez@intel.com,
	linux-wimax@intel.com, emmanuel.grumbach@intel.com,
	Luciano Coelho <luciano.coelho@intel.com>,
	stf_xl@wp.pl, pkshih@realtek.com, ath11k@lists.infradead.org,
	ath10k@lists.infradead.org, wcn36xx@lists.infradead.org,
	merez@codeaurora.org, pizza@shaftnet.org,
	Larry Finger <Larry.Finger@lwfinger.net>,
	amitkarwar@gmail.com, ganapathi.bhat@nxp.com,
	huxinming820@gmail.com, marcel@holtmann.org,
	johan.hedberg@gmail.com, alex.aring@gmail.com,
	jukka.rissanen@linux.intel.com,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	franky.lin@broadcom.com, hante.meuleman@broadcom.com,
	chung-hsien.hsu@infineon.com, wright.feng@infineon.com,
	chi-hsien.lin@infineon.com
Subject: Re: [PATCH net v2 00/21] net: avoid to remove module when its debugfs is being used
Date: Sun, 8 Nov 2020 04:52:55 +0900	[thread overview]
Message-ID: <CAMArcTXNMpjEnVA8sz82CTTnCofqEK+hUSSq27mvjqV6QCiAOQ@mail.gmail.com> (raw)
In-Reply-To: <20201107110522.2a796f1d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Sun, 8 Nov 2020 at 04:05, Jakub Kicinski <kuba@kernel.org> wrote:
>

Hi Jakub,
Thank you for the review!

> On Sat,  7 Nov 2020 17:21:31 +0000 Taehee Yoo wrote:
> > 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.
> >
> > 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.
>
> Hm, looks like some of the patches need to be revised because
> .owner is already set in the ops, and a warning gets generated.

Thanks, I found my mistake via patchwork.
I will fix this problem.

>
> Also it'd be good to mention why Johannes's approach was abandoned.

I'm sorry about skipping the explanation of the situation,
Johannes sent RFC[1], which fixes this problem in the debugfs core logic.
I tested it and it actually avoids this problem well.
And I think there would be more discussion.
So, I thought this series' approach is reasonable right now.
I think setting .owner to THIS_MODULE is a common behavior and it
doesn't hurt our logic even if Johannes's approach is merged.
I'm expecting that both approaches of this series and Johannes are
doing separately.

[1] https://www.spinics.net/lists/linux-wireless/msg204171.html

>
> When you repost please separate out all the patches for
> drivers/net/wireless/ and send that to Kalle's wireless drivers tree.
> Patch 1 needs to be split in two. Patches 2 and 3 would go via Johannes.
> The wimax patch needs to go to staging (wimax code has been moved).
> The remaining patches can be posted individually, not as a series.

Okay, I will do this.

Thanks a lot!
Taehee Yoo

WARNING: multiple messages have this Message-ID (diff)
From: Taehee Yoo <ap420073@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: alex.aring@gmail.com, emmanuel.grumbach@intel.com,
	chi-hsien.lin@infineon.com, amitkarwar@gmail.com,
	ganapathi.bhat@nxp.com, Luciano Coelho <luciano.coelho@intel.com>,
	ath10k@lists.infradead.org, wcn36xx@lists.infradead.org,
	stefan@datenfreihafen.org, merez@codeaurora.org, stf_xl@wp.pl,
	pkshih@realtek.com, Nicolai Stange <nstange@suse.de>,
	chung-hsien.hsu@infineon.com, wright.feng@infineon.com,
	inaky.perez-gonzalez@intel.com, derosier@gmail.com,
	David Laight <David.Laight@aculab.com>,
	b43-dev@lists.infradead.org, ath11k@lists.infradead.org,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	johan.hedberg@gmail.com, michael.hennerich@analog.com,
	marcel@holtmann.org, hante.meuleman@broadcom.com,
	linux-wimax@intel.com, jukka.rissanen@linux.intel.com,
	Kalle Valo <kvalo@codeaurora.org>,
	franky.lin@broadcom.com, huxinming820@gmail.com,
	Netdev <netdev@vger.kernel.org>,
	linux-wireless@vger.kernel.org, linux-bluetooth@vger.kernel.org,
	wil6210@qti.qualcomm.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	linux-wpan@vger.kernel.org, David Miller <davem@davemloft.net>,
	pizza@shaftnet.org
Subject: Re: [PATCH net v2 00/21] net: avoid to remove module when its debugfs is being used
Date: Sun, 8 Nov 2020 04:52:55 +0900	[thread overview]
Message-ID: <CAMArcTXNMpjEnVA8sz82CTTnCofqEK+hUSSq27mvjqV6QCiAOQ@mail.gmail.com> (raw)
In-Reply-To: <20201107110522.2a796f1d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Sun, 8 Nov 2020 at 04:05, Jakub Kicinski <kuba@kernel.org> wrote:
>

Hi Jakub,
Thank you for the review!

> On Sat,  7 Nov 2020 17:21:31 +0000 Taehee Yoo wrote:
> > 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.
> >
> > 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.
>
> Hm, looks like some of the patches need to be revised because
> .owner is already set in the ops, and a warning gets generated.

Thanks, I found my mistake via patchwork.
I will fix this problem.

>
> Also it'd be good to mention why Johannes's approach was abandoned.

I'm sorry about skipping the explanation of the situation,
Johannes sent RFC[1], which fixes this problem in the debugfs core logic.
I tested it and it actually avoids this problem well.
And I think there would be more discussion.
So, I thought this series' approach is reasonable right now.
I think setting .owner to THIS_MODULE is a common behavior and it
doesn't hurt our logic even if Johannes's approach is merged.
I'm expecting that both approaches of this series and Johannes are
doing separately.

[1] https://www.spinics.net/lists/linux-wireless/msg204171.html

>
> When you repost please separate out all the patches for
> drivers/net/wireless/ and send that to Kalle's wireless drivers tree.
> Patch 1 needs to be split in two. Patches 2 and 3 would go via Johannes.
> The wimax patch needs to go to staging (wimax code has been moved).
> The remaining patches can be posted individually, not as a series.

Okay, I will do this.

Thanks a lot!
Taehee Yoo

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Taehee Yoo <ap420073@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: alex.aring@gmail.com, emmanuel.grumbach@intel.com,
	chi-hsien.lin@infineon.com, amitkarwar@gmail.com,
	ganapathi.bhat@nxp.com, Luciano Coelho <luciano.coelho@intel.com>,
	ath10k@lists.infradead.org, wcn36xx@lists.infradead.org,
	stefan@datenfreihafen.org, merez@codeaurora.org, stf_xl@wp.pl,
	pkshih@realtek.com, Nicolai Stange <nstange@suse.de>,
	chung-hsien.hsu@infineon.com, wright.feng@infineon.com,
	inaky.perez-gonzalez@intel.com, derosier@gmail.com,
	David Laight <David.Laight@aculab.com>,
	b43-dev@lists.infradead.org, ath11k@lists.infradead.org,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	johan.hedberg@gmail.com, michael.hennerich@analog.com,
	marcel@holtmann.org, hante.meuleman@broadcom.com,
	linux-wimax@intel.com, jukka.rissanen@linux.intel.com,
	Kalle Valo <kvalo@codeaurora.org>,
	franky.lin@broadcom.com, huxinming820@gmail.com,
	Netdev <netdev@vger.kernel.org>,
	linux-wireless@vger.kernel.org, linux-bluetooth@vger.kernel.org,
	wil6210@qti.qualcomm.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	linux-wpan@vger.kernel.org, David Miller <davem@davemloft.net>,
	pizza@shaftnet.org
Subject: Re: [PATCH net v2 00/21] net: avoid to remove module when its debugfs is being used
Date: Sun, 8 Nov 2020 04:52:55 +0900	[thread overview]
Message-ID: <CAMArcTXNMpjEnVA8sz82CTTnCofqEK+hUSSq27mvjqV6QCiAOQ@mail.gmail.com> (raw)
In-Reply-To: <20201107110522.2a796f1d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Sun, 8 Nov 2020 at 04:05, Jakub Kicinski <kuba@kernel.org> wrote:
>

Hi Jakub,
Thank you for the review!

> On Sat,  7 Nov 2020 17:21:31 +0000 Taehee Yoo wrote:
> > 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.
> >
> > 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.
>
> Hm, looks like some of the patches need to be revised because
> .owner is already set in the ops, and a warning gets generated.

Thanks, I found my mistake via patchwork.
I will fix this problem.

>
> Also it'd be good to mention why Johannes's approach was abandoned.

I'm sorry about skipping the explanation of the situation,
Johannes sent RFC[1], which fixes this problem in the debugfs core logic.
I tested it and it actually avoids this problem well.
And I think there would be more discussion.
So, I thought this series' approach is reasonable right now.
I think setting .owner to THIS_MODULE is a common behavior and it
doesn't hurt our logic even if Johannes's approach is merged.
I'm expecting that both approaches of this series and Johannes are
doing separately.

[1] https://www.spinics.net/lists/linux-wireless/msg204171.html

>
> When you repost please separate out all the patches for
> drivers/net/wireless/ and send that to Kalle's wireless drivers tree.
> Patch 1 needs to be split in two. Patches 2 and 3 would go via Johannes.
> The wimax patch needs to go to staging (wimax code has been moved).
> The remaining patches can be posted individually, not as a series.

Okay, I will do this.

Thanks a lot!
Taehee Yoo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2020-11-07 19:53 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 17:21 [PATCH net v2 00/21] net: avoid to remove module when its debugfs is being used Taehee Yoo
2020-11-07 17:21 ` Taehee Yoo
2020-11-07 17:21 ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 01/21] net: set .owner to THIS_MODULE Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:48   ` net: avoid to remove module when its debugfs is being used bluez.test.bot
2020-11-07 17:21 ` [PATCH net v2 02/21] mac80211: set .owner to THIS_MODULE Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 03/21] cfg80211: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 04/21] netdevsim: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 05/21] ieee802154: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 06/21] i2400m: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 07/21] wlcore: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 08/21] wl1251: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 09/21] iwlwifi: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 10/21] iwlegacy: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 11/21] rtlwifi: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 12/21] ath11k: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 13/21] ath10k: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 14/21] wcn36xx: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 15/21] wil6210: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 16/21] cw1200: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 17/21] brcmfmac: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:41   ` Arend Van Spriel
2020-11-07 17:41     ` Arend Van Spriel
2020-11-07 17:41     ` Arend Van Spriel
2020-11-07 18:16     ` Taehee Yoo
2020-11-07 18:16       ` Taehee Yoo
2020-11-07 18:16       ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 18/21] b43legacy: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 19/21] b43: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 20/21] mwifiex: mwifiex: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21 ` [PATCH net v2 21/21] Bluetooth: " Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 17:21   ` Taehee Yoo
2020-11-07 19:05 ` [PATCH net v2 00/21] net: avoid to remove module when its debugfs is being used Jakub Kicinski
2020-11-07 19:05   ` Jakub Kicinski
2020-11-07 19:05   ` Jakub Kicinski
2020-11-07 19:52   ` Taehee Yoo [this message]
2020-11-07 19:52     ` Taehee Yoo
2020-11-07 19:52     ` Taehee Yoo
2020-11-10  8:32   ` Johannes Berg
2020-11-10  8:32     ` Johannes Berg
2020-11-10  8:32     ` Johannes Berg

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=CAMArcTXNMpjEnVA8sz82CTTnCofqEK+hUSSq27mvjqV6QCiAOQ@mail.gmail.com \
    --to=ap420073@gmail.com \
    --cc=David.Laight@aculab.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=alex.aring@gmail.com \
    --cc=amitkarwar@gmail.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=ath10k@lists.infradead.org \
    --cc=ath11k@lists.infradead.org \
    --cc=b43-dev@lists.infradead.org \
    --cc=chi-hsien.lin@infineon.com \
    --cc=chung-hsien.hsu@infineon.com \
    --cc=davem@davemloft.net \
    --cc=derosier@gmail.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=franky.lin@broadcom.com \
    --cc=ganapathi.bhat@nxp.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=huxinming820@gmail.com \
    --cc=inaky.perez-gonzalez@intel.com \
    --cc=johan.hedberg@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=jukka.rissanen@linux.intel.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wimax@intel.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=marcel@holtmann.org \
    --cc=merez@codeaurora.org \
    --cc=michael.hennerich@analog.com \
    --cc=netdev@vger.kernel.org \
    --cc=nstange@suse.de \
    --cc=pizza@shaftnet.org \
    --cc=pkshih@realtek.com \
    --cc=stefan@datenfreihafen.org \
    --cc=stf_xl@wp.pl \
    --cc=wcn36xx@lists.infradead.org \
    --cc=wil6210@qti.qualcomm.com \
    --cc=wright.feng@infineon.com \
    /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.