* Re: [PATCH v7 net-next 00/19] ionic: Add ionic driver
From: David Miller @ 2019-09-05 7:25 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190903222821.46161-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Tue, 3 Sep 2019 15:28:02 -0700
> This is a patch series that adds the ionic driver, supporting the Pensando
> ethernet device.
>
> In this initial patchset we implement basic transmit and receive. Later
> patchsets will add more advanced features.
>
> Our thanks to Saeed Mahameed, David Miller, Andrew Lunn, Michal Kubecek,
> Jacub Kicinski, Jiri Pirko, Yunsheng Lin, and the ever present kbuild
> test robots for their comments and suggestions.
...
Series applied, thank you.
^ permalink raw reply
* RE: [EXT] [PATCH] net: qed: Move static keyword to the front of declaration
From: Michal Kalderon @ 2019-09-05 7:10 UTC (permalink / raw)
To: Krzysztof Wilczynski, Ariel Elior
Cc: David S. Miller, GR-everest-linux-l2, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190904141730.31497-1-kw@linux.com>
> From: Krzysztof Wilczynski <kswilczynski@gmail.com> On Behalf Of Krzysztof
> Wilczynski
>
> External Email
>
> ----------------------------------------------------------------------
> Move the static keyword to the front of declaration of iwarp_state_names,
> and resolve the following compiler warning that can be seen when building
> with warnings enabled (W=1):
>
> drivers/net/ethernet/qlogic/qed/qed_iwarp.c:385:1: warning:
> ‘static’ is not at beginning of declaration [-Wold-style-declaration]
>
> Also, resolve checkpatch.pl script warning:
>
> WARNING: static const char * array should probably be
> static const char * const
>
> Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
> ---
> Related: https://lore.kernel.org/r/20190827233017.GK9987@google.com
>
> drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> index f380fae8799d..65ec16a31658 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> @@ -382,7 +382,7 @@ qed_iwarp2roce_state(enum qed_iwarp_qp_state
> state)
> }
> }
>
> -const static char *iwarp_state_names[] = {
> +static const char * const iwarp_state_names[] = {
> "IDLE",
> "RTS",
> "TERMINATE",
Thanks,
Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
> --
> 2.22.1
^ permalink raw reply
* RE: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Joakim Zhang @ 2019-09-05 7:10 UTC (permalink / raw)
To: Sean Nyekjaer, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <588ab34d-613d-ac01-7949-921140ca4543@geanix.com>
> -----Original Message-----
> From: Sean Nyekjaer <sean@geanix.com>
> Sent: 2019年9月5日 13:58
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; mkl@pengutronix.de;
> linux-can@vger.kernel.org
> Cc: wg@grandegger.com; netdev@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; Martin Hundebøll <martin@geanix.com>
> Subject: Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self
> wakeup
>
>
>
> On 29/08/2019 09.30, Joakim Zhang wrote:
> > Hi Sean,
> >
> > I'm sorry that I can't get the debug log as the site can't be reached. And I
> connect two boards to do test at my side, this issue can't be reproduced.
> >
> > Best Regards,
> > Joakim Zhang
>
> Hi Joakim,
>
> What commit and branch are you doing your tests with?
Hi Sean,
Could you update lastest flexcan driver using linux-can-next/flexcan and then merge below two patches from linux-can/testing?
d0b53616716e (HEAD -> testing, origin/testing) can: flexcan: add LPSR mode support for i.MX7D
803eb6bad65b can: flexcan: fix deadlock when using self wakeup
Best Regards,
Joakim Zhang
> /Sean
^ permalink raw reply
* Re: [PATCH v2 net-next] net: stmmac: Add support for MDIO interrupts
From: Andrew Lunn @ 2019-09-05 6:40 UTC (permalink / raw)
To: Voon, Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jose Abreu, Giuseppe Cavallaro,
Alexandre Torgue, Ong, Boon Leong
In-Reply-To: <D6759987A7968C4889FDA6FA91D5CBC81475C23E@PGSMSX103.gar.corp.intel.com>
>
> The change log is near the end of the patch:
> /**
> --
> Changelog v2
> *mdio interrupt mode or polling mode will depends on mdio interrupt enable bit
> *Disable the mdio interrupt enable bit in stmmac_release
> *Remove the condition for initialize wait queues
> *Applied reverse Christmas tree
> 1.9.1
At the end, nobody sees it, because everybody else does it at the beginning.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=submitting#the-canonical-patch-format
This talks about the ---. David prefers to see the change log before
the ---. Other maintainers want it after the ---.
>
> >
> > The formatting of this patch also looks a bit odd. Did you use git
> > format-patch ; git send-email?
>
> Yes, I do git format-patch, then ./scripts/checkpatch.pl.
> Lastly git send-email
What looked odd is the missing --- marker. git format-patch should of
create that as part of the patch.
Andrew
^ permalink raw reply
* [PATCH] iavf: fix MAC address setting for VFs when filter is rejected
From: Stefan Assmann @ 2019-09-05 6:34 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, lihong.yang, sassmann
Currently iavf unconditionally applies MAC address change requests. This
brings the VF in a state where it is no longer able to pass traffic if
the PF rejects a MAC filter change for the VF.
A typical scenario for a rejected MAC filter is for an untrusted VF to
request to change the MAC address when an administratively set MAC is
present.
To keep iavf working in this scenario the MAC filter handling in iavf
needs to act on the PF reply regarding the MAC filter change. In the
case of an ack the new MAC address gets set, whereas in the case of a
nack the previous MAC address needs to stay in place.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 1 -
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 7 +++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 39cc67cde89e..9e571a657fe7 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -826,7 +826,6 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
if (f) {
ether_addr_copy(hw->mac.addr, addr->sa_data);
- ether_addr_copy(netdev->dev_addr, adapter->hw.mac.addr);
}
return (f == NULL) ? -ENOMEM : 0;
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index d49d58a6de80..c46770eba320 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -1252,6 +1252,8 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
case VIRTCHNL_OP_ADD_ETH_ADDR:
dev_err(&adapter->pdev->dev, "Failed to add MAC filter, error %s\n",
iavf_stat_str(&adapter->hw, v_retval));
+ /* restore administratively set MAC address */
+ ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
break;
case VIRTCHNL_OP_DEL_VLAN:
dev_err(&adapter->pdev->dev, "Failed to delete VLAN filter, error %s\n",
@@ -1319,6 +1321,11 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
}
}
switch (v_opcode) {
+ case VIRTCHNL_OP_ADD_ETH_ADDR: {
+ if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr))
+ ether_addr_copy(netdev->dev_addr, adapter->hw.mac.addr);
+ }
+ break;
case VIRTCHNL_OP_GET_STATS: {
struct iavf_eth_stats *stats =
(struct iavf_eth_stats *)msg;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] net: phy: adin: implement Energy Detect Powerdown mode via phy-tunable
From: Ardelean, Alexandru @ 2019-09-05 6:32 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com
In-Reply-To: <20190904200350.GB21264@lunn.ch>
On Wed, 2019-09-04 at 22:03 +0200, Andrew Lunn wrote:
> [External]
>
> On Wed, Sep 04, 2019 at 07:23:22PM +0300, Alexandru Ardelean wrote:
> > This driver becomes the first user of the kernel's `ETHTOOL_PHY_EDPD`
> > phy-tunable feature.
> > EDPD is also enabled by default on PHY config_init, but can be disabled via
> > the phy-tunable control.
> >
> > When enabling EDPD, it's also a good idea (for the ADIN PHYs) to enable TX
> > periodic pulses, so that in case the other PHY is also on EDPD mode, there
> > is no lock-up situation where both sides are waiting for the other to
> > transmit.
> >
> > Via the phy-tunable control, TX pulses can be disabled if specifying 0
> > `tx-interval` via ethtool.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 50 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index 4dec83df048d..742728ab2a5d 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -26,6 +26,11 @@
> >
> > #define ADIN1300_RX_ERR_CNT 0x0014
> >
> > +#define ADIN1300_PHY_CTRL_STATUS2 0x0015
> > +#define ADIN1300_NRG_PD_EN BIT(3)
> > +#define ADIN1300_NRG_PD_TX_EN BIT(2)
> > +#define ADIN1300_NRG_PD_STATUS BIT(1)
> > +
> > #define ADIN1300_PHY_CTRL2 0x0016
> > #define ADIN1300_DOWNSPEED_AN_100_EN BIT(11)
> > #define ADIN1300_DOWNSPEED_AN_10_EN BIT(10)
> > @@ -328,12 +333,51 @@ static int adin_set_downshift(struct phy_device *phydev, u8 cnt)
> > ADIN1300_DOWNSPEEDS_EN);
> > }
> >
> > +static int adin_get_edpd(struct phy_device *phydev, u16 *tx_interval)
> > +{
> > + int val;
> > +
> > + val = phy_read(phydev, ADIN1300_PHY_CTRL_STATUS2);
> > + if (val < 0)
> > + return val;
> > +
> > + if (ADIN1300_NRG_PD_EN & val) {
> > + if (val & ADIN1300_NRG_PD_TX_EN)
> > + *tx_interval = 1;
>
> What does 1 mean? 1 pico second, one hour? Anything but zero seconds?
> Does the datasheet specify what it actually does? Maybe you should be
> using ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL here, to indicate you actually
> have no idea, but it is the default for this PHY?
This PHY currently has a 1 second TX interval.
As specified by the datasheet (page 22 Energy-Detect Powerdown Mode section):
https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf
"The PHY monitors the line for signal energy and sends a link pulse once every second"
Currently there is no control exposed to configure this interval; but there could be some registers (that are not
exposed yet) that could control this.
Micrel's datasheet mentions (page 27 3.16.1ENERGY-DETECT POWER-DOWN MODE section):
http://ww1.microchip.com/downloads/en/devicedoc/00002117f.pdf
"In EDPD Mode, the KSZ9031RNX shuts down all transceiver blocks, except for the transmitter and energy detect cir-cuits.
Power can be reduced further by extending the time interval between the transmissions of link pulses to check forthe
presence of a link partner."
I did not check for Micrel to see how that interval is controlled.
The reason for doing this TX interval control was mostly based on this mention from Micrel's datasheet, with
consideration that it could work ADIN & other future PHYs.
>
> > + else
> > + *tx_interval = ETHTOOL_PHY_EDPD_NO_TX;
> > + } else {
> > + *tx_interval = ETHTOOL_PHY_EDPD_DISABLE;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int adin_set_edpd(struct phy_device *phydev, u16 tx_interval)
> > +{
> > + u16 val;
> > +
> > + if (tx_interval == ETHTOOL_PHY_EDPD_DISABLE)
> > + return phy_clear_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
> > + (ADIN1300_NRG_PD_EN | ADIN1300_NRG_PD_TX_EN));
> > +
> > + val = ADIN1300_NRG_PD_EN;
> > + if (tx_interval != ETHTOOL_PHY_EDPD_NO_TX)
> > + val |= ADIN1300_NRG_PD_TX_EN;
>
> So you silently accept any interval? That sounds wrong. You really
> should be returning -EINVAL for any value other than, either 1, or
> maybe ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL, if you change the get
> function.
ack;
will use ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL, ETHTOOL_PHY_EDPD_NO_TX && 1 as acceptable values here
>
> Andrew
^ permalink raw reply
* Re: pull request: bluetooth 2019-09-05
From: David Miller @ 2019-09-05 6:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-bluetooth
In-Reply-To: <20190905061444.GA47480@blobacz-mobl.ger.corp.intel.com>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Thu, 5 Sep 2019 09:14:44 +0300
> Here are a few more Bluetooth fixes for 5.3. I hope they can still make
> it. There's one USB ID addition for btusb, two reverts due to discovered
> regressions, and two other important fixes.
>
> Please let me know if there any issues pulling. Thanks.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] ethtool: implement Energy Detect Powerdown support via phy-tunable
From: Ardelean, Alexandru @ 2019-09-05 6:25 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com
In-Reply-To: <20190904195357.GA21264@lunn.ch>
On Wed, 2019-09-04 at 21:53 +0200, Andrew Lunn wrote:
> [External]
>
> On Wed, Sep 04, 2019 at 07:23:21PM +0300, Alexandru Ardelean wrote:
>
> Hi Alexandru
>
> Somewhere we need a comment stating what EDPD means. Here would be a
> good place.
ack
>
> > +#define ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL 0x7fff
> > +#define ETHTOOL_PHY_EDPD_NO_TX 0x8000
> > +#define ETHTOOL_PHY_EDPD_DISABLE 0
>
> I think you are passing a u16. So why not 0xfffe and 0xffff? We also
> need to make it clear what the units are for interval. This file
I initially thought about keeping this u8 and going with 0xff & 0xfe.
But 254 or 253 could be too small to specify the value of an interval.
Also (maybe due ti all the coding-patterns that I saw over the course of some time), make me feel that I should add a
flag somewhere.
Bottom line is: 0xfffe and 0xffff also work from my side, if it is acceptable (by the community).
Another approach I considered, was to maybe have this EDPD just do enable & disable (which is sufficient for the `adin`
PHY & `micrel` as well).
That would mean that if we would ever want to configure the TX interval (in the future), we would need an extra PHY-
tunable parameter just for that; because changing the enable/disable behavior would be dangerous.
And also, deferring the TX-interval configuration, does not sound like good design/pattern, since it can allow for tons
of PHY-tunable parameters for every little knob.
> specifies the contract between the kernel and user space. So we need
> to clearly define what we mean here. Lots of comments are better than
> no comments.
Will come back with more comments.
>
> Andrew
^ permalink raw reply
* pull request: bluetooth 2019-09-05
From: Johan Hedberg @ 2019-09-05 6:14 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Hi Dave,
Here are a few more Bluetooth fixes for 5.3. I hope they can still make
it. There's one USB ID addition for btusb, two reverts due to discovered
regressions, and two other important fixes.
Please let me know if there any issues pulling. Thanks.
Johan
---
The following changes since commit 8693265329560af4d1190aaa195ad767a05ceeab:
Merge tag 'mac80211-for-davem-2019-08-29' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2019-08-29 16:44:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to 68d19d7d995759b96169da5aac313363f92a9075:
Revert "Bluetooth: validate BLE connection interval updates" (2019-09-05 09:02:59 +0300)
----------------------------------------------------------------
Harish Bandi (1):
Bluetooth: hci_qca: disable irqs when spinlock is acquired
Jian-Hong Pan (1):
Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices
Marcel Holtmann (1):
Revert "Bluetooth: validate BLE connection interval updates"
Mario Limonciello (1):
Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"
Navid Emamdoost (1):
Bluetooth: bpa10x: change return value
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/btusb.c | 8 +++-----
drivers/bluetooth/hci_qca.c | 10 ++++++----
net/bluetooth/hci_event.c | 5 -----
net/bluetooth/l2cap_core.c | 9 +--------
5 files changed, 11 insertions(+), 23 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv2 1/1] forcedeth: use per cpu to collect xmit/recv statistics
From: David Miller @ 2019-09-05 6:13 UTC (permalink / raw)
To: yanjun.zhu; +Cc: eric.dumazet, netdev
In-Reply-To: <70ae3f79-0c57-97d4-ebec-1378782605c8@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Thu, 5 Sep 2019 10:48:01 +0800
>
> On 2019/9/5 6:22, David Miller wrote:
>> From: Zhu Yanjun <yanjun.zhu@oracle.com>
>> Date: Sun, 1 Sep 2019 03:26:13 -0400
>>
>>> +static inline void nv_get_stats(int cpu, struct fe_priv *np,
>>> + struct rtnl_link_stats64 *storage)
>> ...
>>> +static inline void rx_missing_handler(u32 flags, struct fe_priv *np)
>>> +{
>> Never use the inline keyword in foo.c files, let the compiler decide.
>
> Thanks a lot for your advice. I will pay attention to the usage of
> inline in the
>
> source code.
>
> If you agree, I will send V3 about this soon.
Of course "I agree" with my own feedback. Please just make V3 with
the inline keywords removed.
^ permalink raw reply
* Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Sean Nyekjaer @ 2019-09-05 5:57 UTC (permalink / raw)
To: Joakim Zhang, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <DB7PR04MB4618E527339B69AEAD46FB06E6A20@DB7PR04MB4618.eurprd04.prod.outlook.com>
On 29/08/2019 09.30, Joakim Zhang wrote:
> Hi Sean,
>
> I'm sorry that I can't get the debug log as the site can't be reached. And I connect two boards to do test at my side, this issue can't be reproduced.
>
> Best Regards,
> Joakim Zhang
Hi Joakim,
What commit and branch are you doing your tests with?
/Sean
^ permalink raw reply
* Zdravstvujte! Vas interesujut klientskie bazy dannyh?
From: netdev @ 2019-09-04 21:56 UTC (permalink / raw)
To: netdev
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
^ permalink raw reply
* [PATCH] cfg80211: Do not compare with boolean in nl80211_common_reg_change_event
From: zhong jiang @ 2019-09-05 4:25 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, zhongjiang, netdev, linux-kernel
With the help of boolinit.cocci, we use !nl80211_reg_change_event_fill
instead of (nl80211_reg_change_event_fill == false). Meanwhile, Clean
up the code.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/wireless/nl80211.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3e30e18..0c7fa60 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14997,12 +14997,10 @@ void nl80211_common_reg_change_event(enum nl80211_commands cmd_id,
return;
hdr = nl80211hdr_put(msg, 0, 0, 0, cmd_id);
- if (!hdr) {
- nlmsg_free(msg);
- return;
- }
+ if (!hdr)
+ goto nla_put_failure;
- if (nl80211_reg_change_event_fill(msg, request) == false)
+ if (!nl80211_reg_change_event_fill(msg, request))
goto nla_put_failure;
genlmsg_end(msg, hdr);
--
1.7.12.4
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the arm-soc tree
From: Stephen Rothwell @ 2019-09-05 3:42 UTC (permalink / raw)
To: David Miller, Networking, Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Stephen Boyd
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/nuvoton/w90p910_ether.c
between commit:
00d2fbf73d55 ("net: remove w90p910-ether driver")
from the arm-soc tree and commit:
d1a55841ab24 ("net: Remove dev_err() usage after platform_get_irq()")
from the net-next tree.
I fixed it up (I removed the file) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCHv2 net-next] ipmr: remove cache_resolve_queue_len
From: Hangbin Liu @ 2019-09-05 3:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Phil Karn, Sukumar Gopalakrishnan, David S . Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <aa759647-953e-23b5-32e2-b0b7373e07e4@gmail.com>
On Wed, Sep 04, 2019 at 09:50:15AM +0200, Eric Dumazet wrote:
> > +static int queue_count(struct mr_table *mrt)
> > +{
> > + struct list_head *pos;
> > + int count = 0;
> > +
> > + spin_lock_bh(&mfc_unres_lock);
> > + list_for_each(pos, &mrt->mfc_unres_queue)
> > + count++;
> > + spin_unlock_bh(&mfc_unres_lock);
> > +
> > + return count;
> > +}
>
> I guess that even if we remove a limit on the number of items, we probably should
> keep the atomic counter (no code churn, patch much easier to review...)
>
> Your patch could be a one liner really [1]
>
> Eventually replacing this linear list with an RB-tree, so that we can be on the safe side.
>
> [1]
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index c07bc82cbbe96d53d05c1665b2f03faa055f1084..313470f6bb148326b4afbc00d265b6a1e40d93bd 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -1134,8 +1134,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
>
> if (!found) {
> /* Create a new entry if allowable */
> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> - (c = ipmr_cache_alloc_unres()) == NULL) {
> + c = ipmr_cache_alloc_unres();
> + if (!c) {
> spin_unlock_bh(&mfc_unres_lock);
>
> kfree_skb(skb);
hmm, that looks more clear and easy to review..
Hi David, Alexey,
What do you think? If you also agree, I could post a new version patch.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/3] bpf: implement CAP_BPF
From: Alexei Starovoitov @ 2019-09-05 3:15 UTC (permalink / raw)
To: Song Liu
Cc: Alexei Starovoitov, David S . Miller, Daniel Borkmann,
Peter Zijlstra, Andy Lutomirski, Networking, bpf, Kernel Team,
linux-api@vger.kernel.org
In-Reply-To: <E342EC2A-24F6-4581-BFDC-119B5E02B560@fb.com>
On Thu, Sep 05, 2019 at 02:51:51AM +0000, Song Liu wrote:
>
>
> > On Sep 4, 2019, at 6:32 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Sep 05, 2019 at 12:34:36AM +0000, Song Liu wrote:
> >>
> >>
> >>> On Sep 4, 2019, at 11:43 AM, Alexei Starovoitov <ast@kernel.org> wrote:
> >>>
> >>> Implement permissions as stated in uapi/linux/capability.h
> >>>
> >>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> >>>
> >>
> >> [...]
> >>
> >>> @@ -1648,11 +1648,11 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
> >>> is_gpl = license_is_gpl_compatible(license);
> >>>
> >>> if (attr->insn_cnt == 0 ||
> >>> - attr->insn_cnt > (capable(CAP_SYS_ADMIN) ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
> >>> + attr->insn_cnt > (capable_bpf() ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
> >>> return -E2BIG;
> >>> if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
> >>> type != BPF_PROG_TYPE_CGROUP_SKB &&
> >>> - !capable(CAP_SYS_ADMIN))
> >>> + !capable_bpf())
> >>> return -EPERM;
> >>
> >> Do we allow load BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB
> >> without CAP_BPF? If so, maybe highlight in the header?
> >
> > of course. there is no change in behavior.
> > 'highlight in the header'?
> > you mean in commit log?
> > I think it's a bit weird to describe things in commit that patch
> > is _not_ changing vs things that patch does actually change.
> > This type of comment would be great in a doc though.
> > The doc will be coming separately in the follow up assuming
> > the whole thing lands. I'll remember to note that bit.
>
> I meant capability.h:
>
> + * CAP_BPF allows the following BPF operations:
> + * - Loading all types of BPF programs
>
> But CAP_BPF is not required to load all types of programs.
yes, but above statement is still correct, right?
And right below it says:
* CAP_BPF allows the following BPF operations:
* - Loading all types of BPF programs
* - Creating all types of BPF maps except:
* - stackmap that needs CAP_TRACING
* - devmap that needs CAP_NET_ADMIN
* - cpumap that needs CAP_SYS_ADMIN
which is also correct, but CAP_BPF is not required
for array, hash, prog_array, percpu, map-in-map ...
except their lru variants...
and except if they contain bpf_spin_lock...
and if they need BTF it currently can be loaded with cap_sys_admin only...
If we say something about socket_filter, cg_skb progs in capability.h
we should clarify maps as well, but then it will become too big for .h
The comments in capability.h already look too long to me.
All that info and a lot more belongs in the doc.
> On a second thought, I am not sure whether we will keep capability.h
> up to date with all features. So this is probably OK.
It's clearly not for cap_sys_admin.
cap_net_admin is not up to date either.
These two are kitchen sink of anything root-like and networking-root like.
Developers didn't bother updating that .h
With CAP_BPF we can enforce through patch acceptance policy that
major new things (like big verifier features) should have a line
in capability.h
Though .h is not a replacement for proper doc which will come as follow up.
Unlike bpf.h that serves as a template for auto-generating man pages
capability.h is not such thing. I won't change often either.
So normal doc is a better way to document all details.
^ permalink raw reply
* [BACKPORT 4.14.y v2 5/6] ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
From: Baolin Wang @ 2019-09-05 3:10 UTC (permalink / raw)
To: stable, paulus
Cc: ebiggers, linux-ppp, netdev, arnd, baolin.wang, orsonzhai,
vincent.guittot, linux-kernel
In-Reply-To: <cover.1567649728.git.baolin.wang@linaro.org>
From: Eric Biggers <ebiggers@google.com>
[Upstream commit 25a09ce79639a8775244808c17282c491cff89cf]
Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
use the new arc4_crypt() library function rather than access RC4 through
the dynamic crypto_skcipher API.
Meanwhile commit aad1dcc4f011 ("ppp: mppe: Add softdep to arc4") was
merged through the net tree and added a module soft-dependency on "arc4".
The latter commit no longer makes sense because the code now uses the
"libarc4" module rather than "arc4", and also due to the direct use of
arc4_crypt(), no module soft-dependency is required.
So revert the latter commit.
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/net/ppp/ppp_mppe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index d9eda7c..6c7fd98 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -63,7 +63,6 @@
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-MODULE_SOFTDEP("pre: arc4");
MODULE_VERSION("1.0.2");
static unsigned int
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3] tun: fix use-after-free when register netdev failed
From: Jason Wang @ 2019-09-05 3:10 UTC (permalink / raw)
To: Yang Yingliang
Cc: David Miller, netdev, eric dumazet, xiyou wangcong, weiyongjun1
In-Reply-To: <5D706CE4.3000103@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 17619 bytes --]
On 2019/9/5 上午10:03, Yang Yingliang wrote:
>
>
> On 2019/9/3 18:50, Jason Wang wrote:
>>
>> ----- Original Message -----
>>>
>>> On 2019/9/3 14:06, Jason Wang wrote:
>>>> On 2019/9/3 下午1:42, Yang Yingliang wrote:
>>>>>
>>>>> On 2019/9/3 11:03, Jason Wang wrote:
>>>>>> On 2019/9/3 上午9:45, Yang Yingliang wrote:
>>>>>>>
>>>>>>> On 2019/9/2 13:32, Jason Wang wrote:
>>>>>>>> On 2019/8/23 下午5:36, Yang Yingliang wrote:
>>>>>>>>>
>>>>>>>>> On 2019/8/23 11:05, Jason Wang wrote:
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> On 2019/8/22 14:07, Yang Yingliang wrote:
>>>>>>>>>>>> On 2019/8/22 10:13, Jason Wang wrote:
>>>>>>>>>>>>> On 2019/8/20 上午10:28, Jason Wang wrote:
>>>>>>>>>>>>>> On 2019/8/20 上午9:25, David Miller wrote:
>>>>>>>>>>>>>>> From: Yang Yingliang <yangyingliang@huawei.com>
>>>>>>>>>>>>>>> Date: Mon, 19 Aug 2019 21:31:19 +0800
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Call tun_attach() after register_netdevice() to make sure
>>>>>>>>>>>>>>>> tfile->tun
>>>>>>>>>>>>>>>> is not published until the netdevice is registered. So the
>>>>>>>>>>>>>>>> read/write
>>>>>>>>>>>>>>>> thread can not use the tun pointer that may freed by
>>>>>>>>>>>>>>>> free_netdev().
>>>>>>>>>>>>>>>> (The tun and dev pointer are allocated by
>>>>>>>>>>>>>>>> alloc_netdev_mqs(), they
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> be freed by netdev_freemem().)
>>>>>>>>>>>>>>> register_netdevice() must always be the last operation in
>>>>>>>>>>>>>>> the order of
>>>>>>>>>>>>>>> network device setup.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At the point register_netdevice() is called, the device is
>>>>>>>>>>>>>>> visible
>>>>>>>>>>>>>>> globally
>>>>>>>>>>>>>>> and therefore all of it's software state must be fully
>>>>>>>>>>>>>>> initialized and
>>>>>>>>>>>>>>> ready for us.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You're going to have to find another solution to these
>>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>>> The device is loosely coupled with sockets/queues. Each
>>>>>>>>>>>>>> side is
>>>>>>>>>>>>>> allowed to be go away without caring the other side. So
>>>>>>>>>>>>>> in this
>>>>>>>>>>>>>> case, there's a small window that network stack think the
>>>>>>>>>>>>>> device has
>>>>>>>>>>>>>> one queue but actually not, the code can then safely drop
>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>> Maybe it's ok here with some comments?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or if not, we can try to hold the device before tun_attach
>>>>>>>>>>>>>> and drop
>>>>>>>>>>>>>> it after register_netdevice().
>>>>>>>>>>>>> Hi Yang:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think maybe we can try to hold refcnt instead of playing
>>>>>>>>>>>>> real num
>>>>>>>>>>>>> queues here. Do you want to post a V4?
>>>>>>>>>>>> I think the refcnt can prevent freeing the memory in this
>>>>>>>>>>>> case.
>>>>>>>>>>>> When register_netdevice() failed, free_netdev() will be called
>>>>>>>>>>>> directly,
>>>>>>>>>>>> dev->pcpu_refcnt and dev are freed without checking refcnt of
>>>>>>>>>>>> dev.
>>>>>>>>>>> How about using patch-v1 that using a flag to check whether the
>>>>>>>>>>> device
>>>>>>>>>>> registered successfully.
>>>>>>>>>>>
>>>>>>>>>> As I said, it lacks sufficient locks or barriers. To be clear, I
>>>>>>>>>> meant
>>>>>>>>>> something like (compile-test only):
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>>>>>>>> index db16d7a13e00..e52678f9f049 100644
>>>>>>>>>> --- a/drivers/net/tun.c
>>>>>>>>>> +++ b/drivers/net/tun.c
>>>>>>>>>> @@ -2828,6 +2828,7 @@ static int tun_set_iff(struct net *net,
>>>>>>>>>> struct file *file, struct ifreq *ifr)
>>>>>>>>>> (ifr->ifr_flags & TUN_FEATURES);
>>>>>>>>>> INIT_LIST_HEAD(&tun->disabled);
>>>>>>>>>> + dev_hold(dev);
>>>>>>>>>> err = tun_attach(tun, file, false,
>>>>>>>>>> ifr->ifr_flags & IFF_NAPI,
>>>>>>>>>> ifr->ifr_flags &
>>>>>>>>>> IFF_NAPI_FRAGS);
>>>>>>>>>> if (err < 0)
>>>>>>>>>> @@ -2836,6 +2837,7 @@ static int tun_set_iff(struct net *net,
>>>>>>>>>> struct file *file, struct ifreq *ifr)
>>>>>>>>>> err = register_netdevice(tun->dev);
>>>>>>>>>> if (err < 0)
>>>>>>>>>> goto err_detach;
>>>>>>>>>> + dev_put(dev);
>>>>>>>>>> }
>>>>>>>>>> netif_carrier_on(tun->dev);
>>>>>>>>>> @@ -2852,11 +2854,13 @@ static int tun_set_iff(struct net *net,
>>>>>>>>>> struct file *file, struct ifreq *ifr)
>>>>>>>>>> return 0;
>>>>>>>>>> err_detach:
>>>>>>>>>> + dev_put(dev);
>>>>>>>>>> tun_detach_all(dev);
>>>>>>>>>> /* register_netdevice() already called
>>>>>>>>>> tun_free_netdev() */
>>>>>>>>>> goto err_free_dev;
>>>>>>>>>> err_free_flow:
>>>>>>>>>> + dev_put(dev);
>>>>>>>>>> tun_flow_uninit(tun);
>>>>>>>>>> security_tun_dev_free_security(tun->security);
>>>>>>>>>> err_free_stat:
>>>>>>>>>>
>>>>>>>>>> What's your thought?
>>>>>>>>> The dev pointer are freed without checking the refcount in
>>>>>>>>> free_netdev() called by err_free_dev
>>>>>>>>>
>>>>>>>>> path, so I don't understand how the refcount protects this
>>>>>>>>> pointer.
>>>>>>>>>
>>>>>>>> The refcount are guaranteed to be zero there, isn't it?
>>>>>>> No, it's not.
>>>>>>>
>>>>>>> err_free_dev:
>>>>>>> free_netdev(dev);
>>>>>>>
>>>>>>> void free_netdev(struct net_device *dev)
>>>>>>> {
>>>>>>> ...
>>>>>>> /* pcpu_refcnt can be freed without checking refcount */
>>>>>>> free_percpu(dev->pcpu_refcnt);
>>>>>>> dev->pcpu_refcnt = NULL;
>>>>>>>
>>>>>>> /* Compatibility with error handling in drivers */
>>>>>>> if (dev->reg_state == NETREG_UNINITIALIZED) {
>>>>>>> /* dev can be freed without checking refcount */
>>>>>>> netdev_freemem(dev);
>>>>>>> return;
>>>>>>> }
>>>>>>> ...
>>>>>>> }
>>>>>>
>>>>>> Right, but what I meant is in my patch, when code reaches
>>>>>> free_netdev() the refcnt is zero. What did I miss?
>>>>> Yes, but it can't fix the UAF problem.
>>>>
>>>> Well, it looks to me that the dev_put() in tun_put() won't release the
>>>> device in this case.
>>> The device is not released in tun_put().
>>> This is how the UAF occurs:
>>>
>>> CPUA CPUB
>>> tun_set_iff()
>>> alloc_netdev_mqs()
>>> tun_attach()
>>>
>>> tun_chr_read_iter()
>>> tun_get()
>>> tun_do_read()
>>>
>>> tun_ring_recv()
>>> register_netdevice() <-- inject error
>>> goto err_detach
>>> tun_detach_all() <-- set RCV_SHUTDOWN
>>> free_netdev() <-- called from
>>> err_free_dev path
>>> netdev_freemem() <-- free the memory
>>> without check refcount
>>> (In this path, the refcount cannot prevent
>>> freeing the memory of dev, and the memory
>>> will be used by dev_put() called by
>>> tun_chr_read_iter() on CPUB.)
>>> (Break from
>>>
>>> tun_ring_recv(),
>>> because
>>> RCV_SHUTDOWN
>>> is set)
>>> tun_put()
>>> dev_put() <--
>>> use the
>>> memory freed by
>>> netdev_freemem()
>>>
>>>
>> My bad, thanks for the patience. Since all evil come from the
>> tfile->tun, how about delay the publishing of tfile->tun until the
>> success of registration to make sure dev_put() and dev_hold() work.
>> (Compile test only)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index db16d7a13e00..aab0be40d443 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -787,7 +787,8 @@ static void tun_detach_all(struct net_device *dev)
>> }
>> static int tun_attach(struct tun_struct *tun, struct file *file,
>> - bool skip_filter, bool napi, bool napi_frags)
>> + bool skip_filter, bool napi, bool napi_frags,
>> + bool publish_tun)
>> {
>> struct tun_file *tfile = file->private_data;
>> struct net_device *dev = tun->dev;
>> @@ -870,7 +871,8 @@ static int tun_attach(struct tun_struct *tun,
>> struct file *file,
>> * initialized tfile; otherwise we risk using half-initialized
>> * object.
>> */
>> - rcu_assign_pointer(tfile->tun, tun);
>> + if (publish_tun)
>> + rcu_assign_pointer(tfile->tun, tun);
>> rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
>> tun->numqueues++;
>> tun_set_real_num_queues(tun);
>> @@ -2730,7 +2732,7 @@ static int tun_set_iff(struct net *net, struct
>> file *file, struct ifreq *ifr)
>> err = tun_attach(tun, file, ifr->ifr_flags & IFF_NOFILTER,
>> ifr->ifr_flags & IFF_NAPI,
>> - ifr->ifr_flags & IFF_NAPI_FRAGS);
>> + ifr->ifr_flags & IFF_NAPI_FRAGS, true);
>> if (err < 0)
>> return err;
>> @@ -2829,13 +2831,17 @@ static int tun_set_iff(struct net *net,
>> struct file *file, struct ifreq *ifr)
>> INIT_LIST_HEAD(&tun->disabled);
>> err = tun_attach(tun, file, false, ifr->ifr_flags & IFF_NAPI,
>> - ifr->ifr_flags & IFF_NAPI_FRAGS);
>> + ifr->ifr_flags & IFF_NAPI_FRAGS, false);
>> if (err < 0)
>> goto err_free_flow;
>> err = register_netdevice(tun->dev);
>> if (err < 0)
>> goto err_detach;
>> + /* free_netdev() won't check refcnt, to aovid race
>> + * with dev_put() we need publish tun after registration.
>> + */
>> + rcu_assign_pointer(tfile->tun, tun);
>> }
>> netif_carrier_on(tun->dev);
>> @@ -2978,7 +2984,7 @@ static int tun_set_queue(struct file *file,
>> struct ifreq *ifr)
>> if (ret < 0)
>> goto unlock;
>> ret = tun_attach(tun, file, false, tun->flags & IFF_NAPI,
>> - tun->flags & IFF_NAPI_FRAGS);
>> + tun->flags & IFF_NAPI_FRAGS, true);
>> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
>> tun = rtnl_dereference(tfile->tun);
>> if (!tun || !(tun->flags & IFF_MULTI_QUEUE) ||
>> tfile->detached)
> I tested this patch, it can fix this UAF.
>
> But as Eric replied in my patch v1, tun_get() will return NULL as long
> as tun_set_iff() (TUNSETIFF ioctl())
> has not yet been called.
Isn't this the expected behavior. Without TUNSETIFF, it means the
netdevice is not attached, tun_get() should return NULL here.
> This could break some applications, since tun_get() is used from poll()
> and other syscalls.
>
> I think it should return '-EAGIAN' instead of '-EBADFD' in this way. I
> did some change in patch v1,
> if it's OK, I will send a v4.
>
> drivers/net/tun.c | 34 ++++++++++++++++++++++++++++++----
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index db16d7a13e00..0abc654010e3 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -115,6 +115,7 @@ do { \
> /* High bits in flags field are unused. */
> #define TUN_VNET_LE 0x80000000
> #define TUN_VNET_BE 0x40000000
> +#define TUN_DEV_REGISTERED 0x20000000
>
> #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
> @@ -719,8 +720,10 @@ static void __tun_detach(struct tun_file *tfile,
> bool clean)
> netif_carrier_off(tun->dev);
>
> if (!(tun->flags & IFF_PERSIST) &&
> - tun->dev->reg_state == NETREG_REGISTERED)
> + tun->dev->reg_state == NETREG_REGISTERED) {
> + tun->flags &= ~TUN_DEV_REGISTERED;
As I said for previous versions. It's not good that try to invent new
internal state like this, and you need carefully to deal with the
synchronization, it could be lock or barriers. Consider the
synchronization of tun is already complex, let's better try to avoid
adding more but using exist mechanism, e.g pointer publishing through RCU.
Thanks
> unregister_netdevice(tun->dev);
> + }
> }
> if (tun)
> xdp_rxq_info_unreg(&tfile->xdp_rxq);
> @@ -884,8 +887,12 @@ static struct tun_struct *tun_get(struct tun_file
> *tfile)
>
> rcu_read_lock();
> tun = rcu_dereference(tfile->tun);
> - if (tun)
> - dev_hold(tun->dev);
> + if (tun) {
> + if (tun->flags & TUN_DEV_REGISTERED)
> + dev_hold(tun->dev);
> + else
> + tun = ERR_PTR(-EAGAIN);
> + }
> rcu_read_unlock();
>
> return tun;
> @@ -1428,7 +1435,7 @@ static __poll_t tun_chr_poll(struct file *file,
> poll_table *wait)
> struct sock *sk;
> __poll_t mask = 0;
>
> - if (!tun)
> + if (IS_ERR_OR_NULL(tun))
> return EPOLLERR;
>
> sk = tfile->socket.sk;
> @@ -2017,6 +2024,9 @@ static ssize_t tun_chr_write_iter(struct kiocb
> *iocb, struct iov_iter *from)
> if (!tun)
> return -EBADFD;
>
> + if (IS_ERR(tun))
> + return PTR_ERR(tun);
> +
> result = tun_get_user(tun, tfile, NULL, from,
> file->f_flags & O_NONBLOCK, false);
>
> @@ -2242,6 +2252,10 @@ static ssize_t tun_chr_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>
> if (!tun)
> return -EBADFD;
> +
> + if (IS_ERR(tun))
> + return PTR_ERR(tun);
> +
> ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
> ret = min_t(ssize_t, ret, len);
> if (ret > 0)
> @@ -2525,6 +2539,9 @@ static int tun_sendmsg(struct socket *sock,
> struct msghdr *m, size_t total_len)
> if (!tun)
> return -EBADFD;
>
> + if (IS_ERR(tun))
> + return PTR_ERR(tun);
> +
> if (ctl && (ctl->type == TUN_MSG_PTR)) {
> struct tun_page tpage;
> int n = ctl->num;
> @@ -2573,6 +2590,11 @@ static int tun_recvmsg(struct socket *sock,
> struct msghdr *m, size_t total_len,
> goto out_free;
> }
>
> + if (IS_ERR(tun)) {
> + ret = PTR_ERR(tun);
> + goto out_free;
> + }
> +
> if (flags & ~(MSG_DONTWAIT|MSG_TRUNC|MSG_ERRQUEUE)) {
> ret = -EINVAL;
> goto out_put_tun;
> @@ -2622,6 +2644,9 @@ static int tun_peek_len(struct socket *sock)
> if (!tun)
> return 0;
>
> + if (IS_ERR(tun))
> + return PTR_ERR(tun);
> +
> ret = PTR_RING_PEEK_CALL(&tfile->tx_ring, tun_ptr_peek_len);
> tun_put(tun);
>
> @@ -2836,6 +2861,7 @@ static int tun_set_iff(struct net *net, struct
> file *file, struct ifreq *ifr)
> err = register_netdevice(tun->dev);
> if (err < 0)
> goto err_detach;
> + tun->flags |= TUN_DEV_REGISTERED;
> }
>
> netif_carrier_on(tun->dev);
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2493 bytes --]
^ permalink raw reply
* [BACKPORT 4.14.y v2 1/6] ip6: fix skb leak in ip6frag_expire_frag_queue()
From: Baolin Wang @ 2019-09-05 3:06 UTC (permalink / raw)
To: stable, davem, kuznet, yoshfuji
Cc: edumazet, netdev, arnd, baolin.wang, orsonzhai, vincent.guittot,
linux-kernel
In-Reply-To: <cover.1567649728.git.baolin.wang@linaro.org>
From: Eric Dumazet <edumazet@google.com>
[Upstream commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4]
Since ip6frag_expire_frag_queue() now pulls the head skb
from frag queue, we should no longer use skb_get(), since
this leads to an skb leak.
Stefan Bader initially reported a problem in 4.4.stable [1] caused
by the skb_get(), so this patch should also fix this issue.
296583.091021] kernel BUG at /build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207!
[296583.091734] Call Trace:
[296583.091749] [<ffffffff81740e50>] __pskb_pull_tail+0x50/0x350
[296583.091764] [<ffffffff8183939a>] _decode_session6+0x26a/0x400
[296583.091779] [<ffffffff817ec719>] __xfrm_decode_session+0x39/0x50
[296583.091795] [<ffffffff818239d0>] icmpv6_route_lookup+0xf0/0x1c0
[296583.091809] [<ffffffff81824421>] icmp6_send+0x5e1/0x940
[296583.091823] [<ffffffff81753238>] ? __netif_receive_skb+0x18/0x60
[296583.091838] [<ffffffff817532b2>] ? netif_receive_skb_internal+0x32/0xa0
[296583.091858] [<ffffffffc0199f74>] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe]
[296583.091876] [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
[296583.091893] [<ffffffff8183d431>] icmpv6_send+0x21/0x30
[296583.091906] [<ffffffff8182b500>] ip6_expire_frag_queue+0xe0/0x120
[296583.091921] [<ffffffffc04eb27f>] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6]
[296583.091938] [<ffffffff810f3b57>] call_timer_fn+0x37/0x140
[296583.091951] [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
[296583.091968] [<ffffffff810f5464>] run_timer_softirq+0x234/0x330
[296583.091982] [<ffffffff8108a339>] __do_softirq+0x109/0x2b0
Fixes: d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6 defrag")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Cc: Peter Oskolkov <posk@google.com>
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/net/ipv6_frag.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/ipv6_frag.h b/include/net/ipv6_frag.h
index 28aa9b3..1f77fb4 100644
--- a/include/net/ipv6_frag.h
+++ b/include/net/ipv6_frag.h
@@ -94,7 +94,6 @@ static inline u32 ip6frag_obj_hashfn(const void *data, u32 len, u32 seed)
goto out;
head->dev = dev;
- skb_get(head);
spin_unlock(&fq->q.lock);
icmpv6_send(head, ICMPV6_TIME_EXCEED, ICMPV6_EXC_FRAGTIME, 0);
--
1.7.9.5
^ permalink raw reply related
* [BACKPORT 4.14.y v2 0/6] Candidates from Spreadtrum 4.14 product kernel
From: Baolin Wang @ 2019-09-05 3:05 UTC (permalink / raw)
To: stable, davem, kuznet, yoshfuji, peterz, mingo, linus.walleij,
natechancellor, sre, paulus, gregkh
Cc: edumazet, netdev, longman, linux-gpio, david, linux-pm, ebiggers,
linux-ppp, lanqing.liu, linux-serial, arnd, baolin.wang,
orsonzhai, vincent.guittot, linux-kernel
With Arnd's script [1] help, I found some bugfixes in Spreadtrum 4.14 product
kernel, but missing in v4.14.141:
25a09ce79639 ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
47d3d7fdb10a ip6: fix skb leak in ip6frag_expire_frag_queue()
5b9cea15a3de serial: sprd: Modify the baud rate calculation formula
513e1073d52e locking/lockdep: Add debug_locks check in __lock_downgrade()
957063c92473 pinctrl: sprd: Use define directive for sprd_pinconf_params values
87a2b65fc855 power: supply: sysfs: ratelimit property read error message
[1] https://lore.kernel.org/lkml/20190322154425.3852517-19-arnd@arndb.de/T/
Changes from v1:
- Drop 2 unnecessary patches (patch 1 and patch 4) from v1 patch set.
- Add upstream commit id in change log for each stable patch.
David Lechner (1):
power: supply: sysfs: ratelimit property read error message
Eric Biggers (1):
ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
Eric Dumazet (1):
ip6: fix skb leak in ip6frag_expire_frag_queue()
Lanqing Liu (1):
serial: sprd: Modify the baud rate calculation formula
Nathan Chancellor (1):
pinctrl: sprd: Use define directive for sprd_pinconf_params values
Waiman Long (1):
locking/lockdep: Add debug_locks check in __lock_downgrade()
drivers/net/ppp/ppp_mppe.c | 1 -
drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++----
drivers/power/supply/power_supply_sysfs.c | 3 ++-
drivers/tty/serial/sprd_serial.c | 2 +-
include/net/ipv6_frag.h | 1 -
kernel/locking/lockdep.c | 3 +++
6 files changed, 8 insertions(+), 8 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/3] bpf: implement CAP_BPF
From: Song Liu @ 2019-09-05 2:51 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, David S . Miller, Daniel Borkmann,
Peter Zijlstra, Andy Lutomirski, Networking, bpf, Kernel Team,
linux-api@vger.kernel.org
In-Reply-To: <20190905013245.wguhhcxvxt5rnc6h@ast-mbp.dhcp.thefacebook.com>
> On Sep 4, 2019, at 6:32 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Sep 05, 2019 at 12:34:36AM +0000, Song Liu wrote:
>>
>>
>>> On Sep 4, 2019, at 11:43 AM, Alexei Starovoitov <ast@kernel.org> wrote:
>>>
>>> Implement permissions as stated in uapi/linux/capability.h
>>>
>>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>>>
>>
>> [...]
>>
>>> @@ -1648,11 +1648,11 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
>>> is_gpl = license_is_gpl_compatible(license);
>>>
>>> if (attr->insn_cnt == 0 ||
>>> - attr->insn_cnt > (capable(CAP_SYS_ADMIN) ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
>>> + attr->insn_cnt > (capable_bpf() ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
>>> return -E2BIG;
>>> if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
>>> type != BPF_PROG_TYPE_CGROUP_SKB &&
>>> - !capable(CAP_SYS_ADMIN))
>>> + !capable_bpf())
>>> return -EPERM;
>>
>> Do we allow load BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB
>> without CAP_BPF? If so, maybe highlight in the header?
>
> of course. there is no change in behavior.
> 'highlight in the header'?
> you mean in commit log?
> I think it's a bit weird to describe things in commit that patch
> is _not_ changing vs things that patch does actually change.
> This type of comment would be great in a doc though.
> The doc will be coming separately in the follow up assuming
> the whole thing lands. I'll remember to note that bit.
I meant capability.h:
+ * CAP_BPF allows the following BPF operations:
+ * - Loading all types of BPF programs
But CAP_BPF is not required to load all types of programs.
On a second thought, I am not sure whether we will keep capability.h
up to date with all features. So this is probably OK.
Thanks,
Song
^ permalink raw reply
* [PATCH net-next v2] r8152: adjust the settings of ups flags
From: Hayes Wang @ 2019-09-05 2:46 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Hayes Wang
In-Reply-To: <1394712342-15778-327-Taiwan-albertk@realtek.com>
The UPS feature only works for runtime suspend, so UPS flags only
need to be set before enabling runtime suspend. Therefore, I create
a struct to record relative information, and use it before runtime
suspend.
All chips could record such information, even though not all of
them support the feature of UPS. Then, some functions could be
combined.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
v2:
Fix the conflicts after commit 771efeda3936 ("r8152: modify
rtl8152_set_speed function") is applied.
---
drivers/net/usb/r8152.c | 208 +++++++++++++++++++++++-----------------
1 file changed, 120 insertions(+), 88 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ec23c166e67b..08726090570e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -445,18 +445,18 @@
#define UPS_FLAGS_250M_CKDIV BIT(2)
#define UPS_FLAGS_EN_ALDPS BIT(3)
#define UPS_FLAGS_CTAP_SHORT_DIS BIT(4)
-#define UPS_FLAGS_SPEED_MASK (0xf << 16)
#define ups_flags_speed(x) ((x) << 16)
#define UPS_FLAGS_EN_EEE BIT(20)
#define UPS_FLAGS_EN_500M_EEE BIT(21)
#define UPS_FLAGS_EN_EEE_CKDIV BIT(22)
+#define UPS_FLAGS_EEE_PLLOFF_100 BIT(23)
#define UPS_FLAGS_EEE_PLLOFF_GIGA BIT(24)
#define UPS_FLAGS_EEE_CMOD_LV_EN BIT(25)
#define UPS_FLAGS_EN_GREEN BIT(26)
#define UPS_FLAGS_EN_FLOW_CTR BIT(27)
enum spd_duplex {
- NWAY_10M_HALF = 1,
+ NWAY_10M_HALF,
NWAY_10M_FULL,
NWAY_100M_HALF,
NWAY_100M_FULL,
@@ -749,6 +749,23 @@ struct r8152 {
void (*autosuspend_en)(struct r8152 *tp, bool enable);
} rtl_ops;
+ struct ups_info {
+ u32 _10m_ckdiv:1;
+ u32 _250m_ckdiv:1;
+ u32 aldps:1;
+ u32 lite_mode:2;
+ u32 speed_duplex:4;
+ u32 eee:1;
+ u32 eee_lite:1;
+ u32 eee_ckdiv:1;
+ u32 eee_plloff_100:1;
+ u32 eee_plloff_giga:1;
+ u32 eee_cmod_lv:1;
+ u32 green:1;
+ u32 flow_control:1;
+ u32 ctap_short_off:1;
+ } ups_info;
+
atomic_t rx_count;
bool eee_en;
@@ -2865,14 +2882,76 @@ static void r8153_u2p3en(struct r8152 *tp, bool enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
}
-static void r8153b_ups_flags_w1w0(struct r8152 *tp, u32 set, u32 clear)
+static void r8153b_ups_flags(struct r8152 *tp)
{
- u32 ocp_data;
+ u32 ups_flags = 0;
+
+ if (tp->ups_info.green)
+ ups_flags |= UPS_FLAGS_EN_GREEN;
+
+ if (tp->ups_info.aldps)
+ ups_flags |= UPS_FLAGS_EN_ALDPS;
+
+ if (tp->ups_info.eee)
+ ups_flags |= UPS_FLAGS_EN_EEE;
+
+ if (tp->ups_info.flow_control)
+ ups_flags |= UPS_FLAGS_EN_FLOW_CTR;
+
+ if (tp->ups_info.eee_ckdiv)
+ ups_flags |= UPS_FLAGS_EN_EEE_CKDIV;
+
+ if (tp->ups_info.eee_cmod_lv)
+ ups_flags |= UPS_FLAGS_EEE_CMOD_LV_EN;
+
+ if (tp->ups_info._10m_ckdiv)
+ ups_flags |= UPS_FLAGS_EN_10M_CKDIV;
+
+ if (tp->ups_info.eee_plloff_100)
+ ups_flags |= UPS_FLAGS_EEE_PLLOFF_100;
- ocp_data = ocp_read_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS);
- ocp_data &= ~clear;
- ocp_data |= set;
- ocp_write_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS, ocp_data);
+ if (tp->ups_info.eee_plloff_giga)
+ ups_flags |= UPS_FLAGS_EEE_PLLOFF_GIGA;
+
+ if (tp->ups_info._250m_ckdiv)
+ ups_flags |= UPS_FLAGS_250M_CKDIV;
+
+ if (tp->ups_info.ctap_short_off)
+ ups_flags |= UPS_FLAGS_CTAP_SHORT_DIS;
+
+ switch (tp->ups_info.speed_duplex) {
+ case NWAY_10M_HALF:
+ ups_flags |= ups_flags_speed(1);
+ break;
+ case NWAY_10M_FULL:
+ ups_flags |= ups_flags_speed(2);
+ break;
+ case NWAY_100M_HALF:
+ ups_flags |= ups_flags_speed(3);
+ break;
+ case NWAY_100M_FULL:
+ ups_flags |= ups_flags_speed(4);
+ break;
+ case NWAY_1000M_FULL:
+ ups_flags |= ups_flags_speed(5);
+ break;
+ case FORCE_10M_HALF:
+ ups_flags |= ups_flags_speed(6);
+ break;
+ case FORCE_10M_FULL:
+ ups_flags |= ups_flags_speed(7);
+ break;
+ case FORCE_100M_HALF:
+ ups_flags |= ups_flags_speed(8);
+ break;
+ case FORCE_100M_FULL:
+ ups_flags |= ups_flags_speed(9);
+ break;
+ default:
+ break;
+ }
+
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS, ups_flags);
}
static void r8153b_green_en(struct r8152 *tp, bool enable)
@@ -2893,7 +2972,7 @@ static void r8153b_green_en(struct r8152 *tp, bool enable)
data |= GREEN_ETH_EN;
sram_write(tp, SRAM_GREEN_CFG, data);
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_GREEN, 0);
+ tp->ups_info.green = enable;
}
static u16 r8153_phy_status(struct r8152 *tp, u16 desired)
@@ -2923,6 +3002,8 @@ static void r8153b_ups_en(struct r8152 *tp, bool enable)
u32 ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_POWER_CUT);
if (enable) {
+ r8153b_ups_flags(tp);
+
ocp_data |= UPS_EN | USP_PREWAKE | PHASE2_EN;
ocp_write_byte(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
@@ -3231,16 +3312,8 @@ static void r8153_eee_en(struct r8152 *tp, bool enable)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+ tp->ups_info.eee = enable;
}
static void rtl_eee_enable(struct r8152 *tp, bool enable)
@@ -3262,21 +3335,13 @@ static void rtl_eee_enable(struct r8152 *tp, bool enable)
case RTL_VER_04:
case RTL_VER_05:
case RTL_VER_06:
- if (enable) {
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
- } else {
- r8153_eee_en(tp, false);
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
- }
- break;
case RTL_VER_08:
case RTL_VER_09:
if (enable) {
- r8153b_eee_en(tp, true);
+ r8153_eee_en(tp, true);
ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
} else {
- r8153b_eee_en(tp, false);
+ r8153_eee_en(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
}
break;
@@ -3292,6 +3357,8 @@ static void r8152b_enable_fc(struct r8152 *tp)
anar = r8152_mdio_read(tp, MII_ADVERTISE);
anar |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
r8152_mdio_write(tp, MII_ADVERTISE, anar);
+
+ tp->ups_info.flow_control = true;
}
static void rtl8152_disable(struct r8152 *tp)
@@ -3485,22 +3552,8 @@ static void r8153_aldps_en(struct r8152 *tp, bool enable)
break;
}
}
-}
-static void r8153b_aldps_en(struct r8152 *tp, bool enable)
-{
- r8153_aldps_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_ALDPS, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
-}
-
-static void r8153b_enable_fc(struct r8152 *tp)
-{
- r8152b_enable_fc(tp);
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_FLOW_CTR, 0);
+ tp->ups_info.aldps = enable;
}
static void r8153_hw_phy_cfg(struct r8152 *tp)
@@ -3577,11 +3630,11 @@ static u32 r8152_efuse_read(struct r8152 *tp, u8 addr)
static void r8153b_hw_phy_cfg(struct r8152 *tp)
{
- u32 ocp_data, ups_flags = 0;
+ u32 ocp_data;
u16 data;
/* disable ALDPS before updating the PHY parameters */
- r8153b_aldps_en(tp, false);
+ r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
rtl_eee_enable(tp, false);
@@ -3629,28 +3682,27 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
data = ocp_reg_read(tp, OCP_POWER_CFG);
data |= EEE_CLKDIV_EN;
ocp_reg_write(tp, OCP_POWER_CFG, data);
+ tp->ups_info.eee_ckdiv = true;
data = ocp_reg_read(tp, OCP_DOWN_SPEED);
data |= EN_EEE_CMODE | EN_EEE_1000 | EN_10M_CLKDIV;
ocp_reg_write(tp, OCP_DOWN_SPEED, data);
+ tp->ups_info.eee_cmod_lv = true;
+ tp->ups_info._10m_ckdiv = true;
+ tp->ups_info.eee_plloff_giga = true;
ocp_reg_write(tp, OCP_SYSCLK_CFG, 0);
ocp_reg_write(tp, OCP_SYSCLK_CFG, clk_div_expo(5));
-
- ups_flags |= UPS_FLAGS_EN_10M_CKDIV | UPS_FLAGS_250M_CKDIV |
- UPS_FLAGS_EN_EEE_CKDIV | UPS_FLAGS_EEE_CMOD_LV_EN |
- UPS_FLAGS_EEE_PLLOFF_GIGA;
+ tp->ups_info._250m_ckdiv = true;
r8153_patch_request(tp, false);
}
- r8153b_ups_flags_w1w0(tp, ups_flags, 0);
-
if (tp->eee_en)
rtl_eee_enable(tp, true);
- r8153b_aldps_en(tp, true);
- r8153b_enable_fc(tp);
+ r8153_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
r8153_u2p3en(tp, true);
set_bit(PHY_RESET, &tp->flags);
@@ -3801,18 +3853,9 @@ static void rtl8153_disable(struct r8152 *tp)
r8153_aldps_en(tp, true);
}
-static void rtl8153b_disable(struct r8152 *tp)
-{
- r8153b_aldps_en(tp, false);
- rtl_disable(tp);
- rtl_reset_bmu(tp);
- r8153b_aldps_en(tp, true);
-}
-
static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
u32 advertising)
{
- enum spd_duplex speed_duplex;
u16 bmcr;
int ret = 0;
@@ -3825,24 +3868,24 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
bmcr = BMCR_SPEED10;
if (duplex == DUPLEX_FULL) {
bmcr |= BMCR_FULLDPLX;
- speed_duplex = FORCE_10M_FULL;
+ tp->ups_info.speed_duplex = FORCE_10M_FULL;
} else {
- speed_duplex = FORCE_10M_HALF;
+ tp->ups_info.speed_duplex = FORCE_10M_HALF;
}
break;
case SPEED_100:
bmcr = BMCR_SPEED100;
if (duplex == DUPLEX_FULL) {
bmcr |= BMCR_FULLDPLX;
- speed_duplex = FORCE_100M_FULL;
+ tp->ups_info.speed_duplex = FORCE_100M_FULL;
} else {
- speed_duplex = FORCE_100M_HALF;
+ tp->ups_info.speed_duplex = FORCE_100M_HALF;
}
break;
case SPEED_1000:
if (tp->mii.supports_gmii) {
bmcr = BMCR_SPEED1000 | BMCR_FULLDPLX;
- speed_duplex = NWAY_1000M_FULL;
+ tp->ups_info.speed_duplex = NWAY_1000M_FULL;
break;
}
/* fall through */
@@ -3875,20 +3918,20 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
ADVERTISE_100HALF | ADVERTISE_100FULL);
if (advertising & RTL_ADVERTISED_10_HALF) {
tmp1 |= ADVERTISE_10HALF;
- speed_duplex = NWAY_10M_HALF;
+ tp->ups_info.speed_duplex = NWAY_10M_HALF;
}
if (advertising & RTL_ADVERTISED_10_FULL) {
tmp1 |= ADVERTISE_10FULL;
- speed_duplex = NWAY_10M_FULL;
+ tp->ups_info.speed_duplex = NWAY_10M_FULL;
}
if (advertising & RTL_ADVERTISED_100_HALF) {
tmp1 |= ADVERTISE_100HALF;
- speed_duplex = NWAY_100M_HALF;
+ tp->ups_info.speed_duplex = NWAY_100M_HALF;
}
if (advertising & RTL_ADVERTISED_100_FULL) {
tmp1 |= ADVERTISE_100FULL;
- speed_duplex = NWAY_100M_FULL;
+ tp->ups_info.speed_duplex = NWAY_100M_FULL;
}
if (anar != tmp1) {
@@ -3905,7 +3948,7 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
if (advertising & RTL_ADVERTISED_1000_FULL) {
tmp1 |= ADVERTISE_1000FULL;
- speed_duplex = NWAY_1000M_FULL;
+ tp->ups_info.speed_duplex = NWAY_1000M_FULL;
}
if (gbcr != tmp1)
@@ -3922,17 +3965,6 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
r8152_mdio_write(tp, MII_BMCR, bmcr);
- switch (tp->version) {
- case RTL_VER_08:
- case RTL_VER_09:
- r8153b_ups_flags_w1w0(tp, ups_flags_speed(speed_duplex),
- UPS_FLAGS_SPEED_MASK);
- break;
-
- default:
- break;
- }
-
if (bmcr & BMCR_RESET) {
int i;
@@ -4017,12 +4049,12 @@ static void rtl8153b_up(struct r8152 *tp)
r8153b_u1u2en(tp, false);
r8153_u2p3en(tp, false);
- r8153b_aldps_en(tp, false);
+ r8153_aldps_en(tp, false);
r8153_first_init(tp);
ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH, RX_THR_B);
- r8153b_aldps_en(tp, true);
+ r8153_aldps_en(tp, true);
r8153_u2p3en(tp, true);
r8153b_u1u2en(tp, true);
}
@@ -4037,9 +4069,9 @@ static void rtl8153b_down(struct r8152 *tp)
r8153b_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153b_power_cut_en(tp, false);
- r8153b_aldps_en(tp, false);
+ r8153_aldps_en(tp, false);
r8153_enter_oob(tp);
- r8153b_aldps_en(tp, true);
+ r8153_aldps_en(tp, true);
}
static bool rtl8152_in_nway(struct r8152 *tp)
@@ -5445,7 +5477,7 @@ static int rtl_ops_init(struct r8152 *tp)
case RTL_VER_09:
ops->init = r8153b_init;
ops->enable = rtl8153_enable;
- ops->disable = rtl8153b_disable;
+ ops->disable = rtl8153_disable;
ops->up = rtl8153b_up;
ops->down = rtl8153b_down;
ops->unload = rtl8153b_unload;
--
2.21.0
^ permalink raw reply related
* Re: [PATCHv2 1/1] forcedeth: use per cpu to collect xmit/recv statistics
From: Zhu Yanjun @ 2019-09-05 2:48 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20190904.152218.250246841354408872.davem@davemloft.net>
On 2019/9/5 6:22, David Miller wrote:
> From: Zhu Yanjun <yanjun.zhu@oracle.com>
> Date: Sun, 1 Sep 2019 03:26:13 -0400
>
>> +static inline void nv_get_stats(int cpu, struct fe_priv *np,
>> + struct rtnl_link_stats64 *storage)
> ...
>> +static inline void rx_missing_handler(u32 flags, struct fe_priv *np)
>> +{
> Never use the inline keyword in foo.c files, let the compiler decide.
Thanks a lot for your advice. I will pay attention to the usage of
inline in the
source code.
If you agree, I will send V3 about this soon.
Zhu Yanjun
>
^ permalink raw reply
* Re: WARNING in hso_free_net_device
From: Hui Peng @ 2019-09-05 2:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: syzbot+44d53c7255bb1aea22d2, alexios.zavras, andreyknvl, davem,
gregkh, linux-kernel, linux-usb, mathias.payer, netdev, rfontana,
syzkaller-bugs, tglx
In-Reply-To: <20190904154140.45dfb398@hermes.lan>
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Can you guys have a look at the attached patch?
On 9/4/19 6:41 PM, Stephen Hemminger wrote:
> On Wed, 4 Sep 2019 16:27:50 -0400
> Hui Peng <benquike@gmail.com> wrote:
>
>> Hi, all:
>>
>> I looked at the bug a little.
>>
>> The issue is that in the error handling code, hso_free_net_device
>> unregisters
>>
>> the net_device (hso_net->net) by calling unregister_netdev. In the
>> error handling code path,
>>
>> hso_net->net has not been registered yet.
>>
>> I think there are two ways to solve the issue:
>>
>> 1. fix it in drivers/net/usb/hso.c to avoiding unregistering the
>> net_device when it is still not registered
>>
>> 2. fix it in unregister_netdev. We can add a field in net_device to
>> record whether it is registered, and make unregister_netdev return if
>> the net_device is not registered yet.
>>
>> What do you guys think ?
> #1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-a-wrong-unregistering-bug-in-hso_free_net_device.patch --]
[-- Type: text/x-patch; name="0001-Fix-a-wrong-unregistering-bug-in-hso_free_net_device.patch", Size: 2399 bytes --]
From f3fdee8fc03aa2bc982f22da1d29bbf6bca72935 Mon Sep 17 00:00:00 2001
From: Hui Peng <benquike@gmail.com>
Date: Wed, 4 Sep 2019 21:38:35 -0400
Subject: [PATCH] Fix a wrong unregistering bug in hso_free_net_device
As shown below, hso_create_net_device may call hso_free_net_device
before the net_device is registered. hso_free_net_device will
unregister the network device no matter it is registered or not,
unregister_netdev is not able to handle unregistered net_device,
resulting in the bug reported by the syzbot.
```
static struct hso_device *hso_create_net_device(struct usb_interface *interface,
int port_spec)
{
......
net = alloc_netdev(sizeof(struct hso_net), "hso%d", NET_NAME_UNKNOWN,
hso_net_init);
......
if (!hso_net->out_endp) {
dev_err(&interface->dev, "Can't find BULK OUT endpoint\n");
goto exit;
}
......
result = register_netdev(net);
......
exit:
hso_free_net_device(hso_dev);
return NULL;
}
static void hso_free_net_device(struct hso_device *hso_dev)
{
......
if (hso_net->net)
unregister_netdev(hso_net->net);
......
}
```
This patch adds a net_registered field in struct hso_net to record whether
the containing net_device is registered or not, and avoid unregistering it
if it is not registered yet.
Reported-by: syzbot+44d53c7255bb1aea22d2@syzkaller.appspotmail.com
Signed-off-by: Hui Peng <benquike@gmail.com>
---
drivers/net/usb/hso.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index ce78714..5b3df33 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -128,6 +128,7 @@ struct hso_shared_int {
struct hso_net {
struct hso_device *parent;
struct net_device *net;
+ bool net_registered;
struct rfkill *rfkill;
char name[24];
@@ -2362,7 +2363,7 @@ static void hso_free_net_device(struct hso_device *hso_dev)
remove_net_device(hso_net->parent);
- if (hso_net->net)
+ if (hso_net->net && hso_net->net_registered)
unregister_netdev(hso_net->net);
/* start freeing */
@@ -2544,6 +2545,7 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
dev_err(&interface->dev, "Failed to register device\n");
goto exit;
}
+ hso_net->net_registered = true;
hso_log_port(hso_dev);
--
2.7.4
[-- Attachment #3: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2489 bytes --]
^ permalink raw reply related
* [PATCH] net/mlx5: Fix addr's type in mlx5dr_icm_dm
From: Nathan Chancellor @ 2019-09-05 2:14 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev, linux-rdma, linux-kernel, clang-built-linux,
Nathan Chancellor
clang errors when CONFIG_PHYS_ADDR_T_64BIT is not set:
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8:
error: incompatible pointer types passing 'u64 *' (aka 'unsigned long
long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *')
[-Werror,-Wincompatible-pointer-types]
&icm_mr->dm.addr, &icm_mr->dm.obj_id);
^~~~~~~~~~~~~~~~
include/linux/mlx5/driver.h:1092:39: note: passing argument to parameter
'addr' here
u64 length, u16 uid, phys_addr_t *addr, u32 *obj_id);
^
1 error generated.
Use phys_addr_t for addr's type in mlx5dr_icm_dm, which won't change
anything with 64-bit builds because phys_addr_t is u64 when
CONFIG_PHYS_ADDR_T_64BIT is set, which is always when CONFIG_64BIT is
set.
Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator")
Link: https://github.com/ClangBuiltLinux/linux/issues/653
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
index e76f61e7555e..913f1e5aaaf2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
@@ -53,7 +53,7 @@ struct mlx5dr_icm_pool {
struct mlx5dr_icm_dm {
u32 obj_id;
enum mlx5_sw_icm_type type;
- u64 addr;
+ phys_addr_t addr;
size_t length;
};
--
2.23.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox