* [PATCH net-next] net: stmmac: Re-word Kconfig entry
From: Jose Abreu @ 2019-07-02 9:12 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Jose Abreu, Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue
We support many speeds and it doesn't make much sense to list them all
in the Kconfig. Let's just call it Multi-Gigabit.
Suggested-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 2acb999b7f63..943189dcccb1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
config STMMAC_ETH
- tristate "STMicroelectronics 10/100/1000/EQOS/2500/5000/10000 Ethernet driver"
+ tristate "STMicroelectronics Multi-Gigabit Ethernet driver"
depends on HAS_IOMEM && HAS_DMA
select MII
select PHYLINK
--
2.7.4
^ permalink raw reply related
* Re: Use-after-free in br_multicast_rcv
From: Martin Weinelt @ 2019-07-02 8:46 UTC (permalink / raw)
To: Nikolay Aleksandrov, bridge, Roopa Prabhu; +Cc: netdev
In-Reply-To: <6dc6e89b-8b40-7dac-ec69-f4223d5dc147@cumulusnetworks.com>
Hi Nik,
On 7/2/19 12:37 AM, Nikolay Aleksandrov wrote:
> On 7/2/19 1:17 AM, Martin Weinelt wrote:
>> Hi again,
>>
>> On 7/1/19 7:37 PM, Nikolay Aleksandrov wrote:
>>> I see, thanks for clarifying this. So on the KASAN could you please try the attached patch ?
>>> Also could you please run the br_multicast_rcv+xxx addresses through
>>> linux/scripts/faddr2line for your kernel/bridge:
>>> usage: faddr2line [--list] <object file> <func+offset> <func+offset>...
>>>
>>> Thanks,
>>> Nik
>>>
>>
>> back with a new report. This is 5.2.0-rc7 + your patch.
>>
>> Best,
>> Martin
>>
>
> Thanks! Aaargh.. I made a stupid mistake hurrying to send the patch, apologies.
> Here's the fixed version, please give it a go. This report is because
> of my change, not because of the previous bug that should've been fixed.
>
I applied your latest patch against 5.2.0-rc7 and it seems to have fixed the issue as,
after 6 hours of uptime, the KASAN report isn't coming up anymore.
Also there are currently no kmemleak results coming up on 5.2.0-rc7, so I'll be
looking at the v4.19.x series next.
Thank you!
Best
Martin
^ permalink raw reply
* Re: [PATCH bpf-next v3] virtio_net: add XDP meta data support
From: Jason Wang @ 2019-07-02 8:33 UTC (permalink / raw)
To: Yuya Kusakabe
Cc: ast, daniel, davem, hawk, jakub.kicinski, john.fastabend, kafai,
mst, netdev, songliubraving, yhs
In-Reply-To: <20190702081646.23230-1-yuya.kusakabe@gmail.com>
On 2019/7/2 下午4:16, Yuya Kusakabe wrote:
> This adds XDP meta data support to both receive_small() and
> receive_mergeable().
>
> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
> ---
> v3:
> - fix preserve the vnet header in receive_small().
> v2:
> - keep copy untouched in page_to_skb().
> - preserve the vnet header in receive_small().
> - fix indentation.
> ---
> drivers/net/virtio_net.c | 45 +++++++++++++++++++++++++++-------------
> 1 file changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4f3de0ac8b0b..03a1ae6fe267 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct receive_queue *rq,
> struct page *page, unsigned int offset,
> unsigned int len, unsigned int truesize,
> - bool hdr_valid)
> + bool hdr_valid, unsigned int metasize)
> {
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> @@ -393,7 +393,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> else
> hdr_padded_len = sizeof(struct padded_vnet_hdr);
>
> - if (hdr_valid)
> + if (hdr_valid && !metasize)
> memcpy(hdr, p, hdr_len);
>
> len -= hdr_len;
> @@ -405,6 +405,11 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> copy = skb_tailroom(skb);
> skb_put_data(skb, p, copy);
>
> + if (metasize) {
> + __skb_pull(skb, metasize);
> + skb_metadata_set(skb, metasize);
> + }
> +
> len -= copy;
> offset += copy;
>
> @@ -644,6 +649,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> unsigned int delta = 0;
> struct page *xdp_page;
> int err;
> + unsigned int metasize = 0;
>
> len -= vi->hdr_len;
> stats->bytes += len;
> @@ -683,10 +689,13 @@ static struct sk_buff *receive_small(struct net_device *dev,
>
> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
> xdp.data = xdp.data_hard_start + xdp_headroom;
> - xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + len;
> + xdp.data_meta = xdp.data;
> xdp.rxq = &rq->xdp_rxq;
> orig_data = xdp.data;
> + /* Copy the vnet header to the front of data_hard_start to avoid
> + * overwriting by XDP meta data */
> + memcpy(xdp.data_hard_start - vi->hdr_len, xdp.data - vi->hdr_len, vi->hdr_len);
What happens if we have a large metadata that occupies all headroom here?
Thanks
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> stats->xdp_packets++;
>
> @@ -695,9 +704,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
> /* Recalculate length in case bpf program changed it */
> delta = orig_data - xdp.data;
> len = xdp.data_end - xdp.data;
> + metasize = xdp.data - xdp.data_meta;
> break;
> case XDP_TX:
> stats->xdp_tx++;
> + xdp.data_meta = xdp.data;
> xdpf = convert_to_xdp_frame(&xdp);
> if (unlikely(!xdpf))
> goto err_xdp;
> @@ -736,10 +747,12 @@ static struct sk_buff *receive_small(struct net_device *dev,
> skb_reserve(skb, headroom - delta);
> skb_put(skb, len);
> if (!delta) {
> - buf += header_offset;
> - memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
> + memcpy(skb_vnet_hdr(skb), buf + VIRTNET_RX_PAD, vi->hdr_len);
> } /* keep zeroed vnet hdr since packet was changed by bpf */
>
> + if (metasize)
> + skb_metadata_set(skb, metasize);
> +
> err:
> return skb;
>
> @@ -760,8 +773,8 @@ static struct sk_buff *receive_big(struct net_device *dev,
> struct virtnet_rq_stats *stats)
> {
> struct page *page = buf;
> - struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len,
> - PAGE_SIZE, true);
> + struct sk_buff *skb =
> + page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, true, 0);
>
> stats->bytes += len - vi->hdr_len;
> if (unlikely(!skb))
> @@ -793,6 +806,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> unsigned int truesize;
> unsigned int headroom = mergeable_ctx_to_headroom(ctx);
> int err;
> + unsigned int metasize = 0;
>
> head_skb = NULL;
> stats->bytes += len - vi->hdr_len;
> @@ -839,8 +853,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> data = page_address(xdp_page) + offset;
> xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
> xdp.data = data + vi->hdr_len;
> - xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + (len - vi->hdr_len);
> + xdp.data_meta = xdp.data;
> xdp.rxq = &rq->xdp_rxq;
>
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> @@ -852,8 +866,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> * adjustments. Note other cases do not build an
> * skb and avoid using offset
> */
> - offset = xdp.data -
> - page_address(xdp_page) - vi->hdr_len;
> + metasize = xdp.data - xdp.data_meta;
> + offset = xdp.data - page_address(xdp_page) -
> + vi->hdr_len - metasize;
>
> /* recalculate len if xdp.data or xdp.data_end were
> * adjusted
> @@ -863,14 +878,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> if (unlikely(xdp_page != page)) {
> rcu_read_unlock();
> put_page(page);
> - head_skb = page_to_skb(vi, rq, xdp_page,
> - offset, len,
> - PAGE_SIZE, false);
> + head_skb = page_to_skb(vi, rq, xdp_page, offset,
> + len, PAGE_SIZE, false,
> + metasize);
> return head_skb;
> }
> break;
> case XDP_TX:
> stats->xdp_tx++;
> + xdp.data_meta = xdp.data;
> xdpf = convert_to_xdp_frame(&xdp);
> if (unlikely(!xdpf))
> goto err_xdp;
> @@ -921,7 +937,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> goto err_skb;
> }
>
> - head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog);
> + head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
> + metasize);
> curr_skb = head_skb;
>
> if (unlikely(!curr_skb))
^ permalink raw reply
* [PATCH bpf-next v3] virtio_net: add XDP meta data support
From: Yuya Kusakabe @ 2019-07-02 8:16 UTC (permalink / raw)
To: jasowang
Cc: yuya.kusakabe, ast, daniel, davem, hawk, jakub.kicinski,
john.fastabend, kafai, mst, netdev, songliubraving, yhs
In-Reply-To: <32dc2f4e-4f19-4fa5-1d24-17a025a08297@gmail.com>
This adds XDP meta data support to both receive_small() and
receive_mergeable().
Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
---
v3:
- fix preserve the vnet header in receive_small().
v2:
- keep copy untouched in page_to_skb().
- preserve the vnet header in receive_small().
- fix indentation.
---
drivers/net/virtio_net.c | 45 +++++++++++++++++++++++++++-------------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4f3de0ac8b0b..03a1ae6fe267 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
struct receive_queue *rq,
struct page *page, unsigned int offset,
unsigned int len, unsigned int truesize,
- bool hdr_valid)
+ bool hdr_valid, unsigned int metasize)
{
struct sk_buff *skb;
struct virtio_net_hdr_mrg_rxbuf *hdr;
@@ -393,7 +393,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
else
hdr_padded_len = sizeof(struct padded_vnet_hdr);
- if (hdr_valid)
+ if (hdr_valid && !metasize)
memcpy(hdr, p, hdr_len);
len -= hdr_len;
@@ -405,6 +405,11 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
copy = skb_tailroom(skb);
skb_put_data(skb, p, copy);
+ if (metasize) {
+ __skb_pull(skb, metasize);
+ skb_metadata_set(skb, metasize);
+ }
+
len -= copy;
offset += copy;
@@ -644,6 +649,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
unsigned int delta = 0;
struct page *xdp_page;
int err;
+ unsigned int metasize = 0;
len -= vi->hdr_len;
stats->bytes += len;
@@ -683,10 +689,13 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
xdp.data = xdp.data_hard_start + xdp_headroom;
- xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + len;
+ xdp.data_meta = xdp.data;
xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
+ /* Copy the vnet header to the front of data_hard_start to avoid
+ * overwriting by XDP meta data */
+ memcpy(xdp.data_hard_start - vi->hdr_len, xdp.data - vi->hdr_len, vi->hdr_len);
act = bpf_prog_run_xdp(xdp_prog, &xdp);
stats->xdp_packets++;
@@ -695,9 +704,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
/* Recalculate length in case bpf program changed it */
delta = orig_data - xdp.data;
len = xdp.data_end - xdp.data;
+ metasize = xdp.data - xdp.data_meta;
break;
case XDP_TX:
stats->xdp_tx++;
+ xdp.data_meta = xdp.data;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -736,10 +747,12 @@ static struct sk_buff *receive_small(struct net_device *dev,
skb_reserve(skb, headroom - delta);
skb_put(skb, len);
if (!delta) {
- buf += header_offset;
- memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
+ memcpy(skb_vnet_hdr(skb), buf + VIRTNET_RX_PAD, vi->hdr_len);
} /* keep zeroed vnet hdr since packet was changed by bpf */
+ if (metasize)
+ skb_metadata_set(skb, metasize);
+
err:
return skb;
@@ -760,8 +773,8 @@ static struct sk_buff *receive_big(struct net_device *dev,
struct virtnet_rq_stats *stats)
{
struct page *page = buf;
- struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len,
- PAGE_SIZE, true);
+ struct sk_buff *skb =
+ page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, true, 0);
stats->bytes += len - vi->hdr_len;
if (unlikely(!skb))
@@ -793,6 +806,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
unsigned int truesize;
unsigned int headroom = mergeable_ctx_to_headroom(ctx);
int err;
+ unsigned int metasize = 0;
head_skb = NULL;
stats->bytes += len - vi->hdr_len;
@@ -839,8 +853,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
data = page_address(xdp_page) + offset;
xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
xdp.data = data + vi->hdr_len;
- xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + (len - vi->hdr_len);
+ xdp.data_meta = xdp.data;
xdp.rxq = &rq->xdp_rxq;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -852,8 +866,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
* adjustments. Note other cases do not build an
* skb and avoid using offset
*/
- offset = xdp.data -
- page_address(xdp_page) - vi->hdr_len;
+ metasize = xdp.data - xdp.data_meta;
+ offset = xdp.data - page_address(xdp_page) -
+ vi->hdr_len - metasize;
/* recalculate len if xdp.data or xdp.data_end were
* adjusted
@@ -863,14 +878,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
if (unlikely(xdp_page != page)) {
rcu_read_unlock();
put_page(page);
- head_skb = page_to_skb(vi, rq, xdp_page,
- offset, len,
- PAGE_SIZE, false);
+ head_skb = page_to_skb(vi, rq, xdp_page, offset,
+ len, PAGE_SIZE, false,
+ metasize);
return head_skb;
}
break;
case XDP_TX:
stats->xdp_tx++;
+ xdp.data_meta = xdp.data;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -921,7 +937,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto err_skb;
}
- head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog);
+ head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
+ metasize);
curr_skb = head_skb;
if (unlikely(!curr_skb))
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-02 8:01 UTC (permalink / raw)
To: Daniel Drake
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAD8Lp44R0a1=fVi=fGv69w1ppdcaFV01opkdkhaX-eJ=K=tYeA@mail.gmail.com>
On Mon, Jul 1, 2019 at 4:28 PM Daniel Drake <drake@endlessm.com> wrote:
>
> Hi Chris,
>
> On Thu, Jun 27, 2019 at 5:53 PM Chris Chiu <chiu@endlessm.com> wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > This commit hand over the antenna control to PTA, the wifi signal
> > will be back to normal and the bluetooth scan can also work at the
> > same time. However, the btcoexist still needs to be handled under
> > different circumstances. If there's a BT connection established,
> > the wifi still fails to connect until disconneting the BT.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
>
> Really nice work finding this!
>
> I know that after this change, you plan to bring over the btcoexist
> code from the vendor driver (or at least the minimum required code)
> for a more complete fix, but I'm curious how you found these magic
> register values and how they compare to the values used by the vendor
> driver with btcoexist?
>
> What's PTA? A type of firmware-implemented btcoexist that works for
> scanning but doesn't work when a BT connection is actually
> established?
>
When the vendor driver invokes rtw_btcoex_HAL_Initialize, which will then
call halbtc8723b1ant_SetAntPath to configure the registers in this patch.
From the code, the registers will have different register settings per the
antenna position and the phase. If the driver is in the InitHwConfig phase,
the register value is identical to what rtl8xxxu driver does in enable_rf().
However, the vendor driver will do halbtc8723b1ant_PsTdma() twice by
halbtc8723b1ant_ActionWifiNotConnected() with the type argument 8 for
PTA control about 200ms after InitHwConfig. The _ActionWifiNotConnected
is invoked by the BTCOEXIST. I keep seeing the halbtc8723b1ant_PsTdma
with type 8 been called every 2 seconds.
I don't know what PTA is. I presume it's the mechanism in FW for the automatic
antenna selecting instead of manual control. Given the phenomenon that wifi
signal still stays low even without bluetooth driver loaded, I believe
setting the
registers as in halbtc8723b1ant_SetAntPath with BTC_ANT_PATH_PTA also
makes sense.
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > index 3adb1d3d47ac..6c3c70d93ac1 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > /*
> > * WLAN action by PTA
> > */
> > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
>
> The comment above this still says "WLAN action by PTA" and the vendor
> driver has:
> //set wlan_act control by PTA
> pBtCoexist->fBtcWrite1Byte(pBtCoexist, 0x76e, 0x4);
>
> but then also:
> //set wlan_act control by PTA
> pBtCoexist->fBtcWrite1Byte(pBtCoexist, 0x76e, 0xc);
>
> So this change seems to be at least consistent with ambiguity of the
> vendor driver, do you have any understanding of the extra bit that is
> now set here?
>
I think the precise expression for 0x04 is "set wlan act to always low",
it's configured for wifi only.
> It's not easy to follow the code flow of the vendor driver to see what
> actually happens, have you checked that, does it end up using the 0xc
> value?
>
Yes, it ends up with 0x0c not matter what antenna position type is. Unless
it's configured wifi only.
> > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > + * Different settings per different antenna position.
> > + * Antenna switch to BT: 0x280, 0x00 (inverse)
> > + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> > + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> I don't quite follow the comment here. Why are there 2 values listed
> for each possibility, what do you mean by inverse? You say the
> register settings were incorrect, but the previous value was 0x00
> which you now document as "antenna switch to wifi" which sounds like
> it was already correct?
>
> Which value does the vendor driver use?
>
The first column means the value for normal antenna installation, wifi
on the main port. The second column is the value for inverse antenna
installation. So if I want to manually switch the antenna for BT use,
and the antenna installation is inverse, I need to set to 0x280. So 0x80
means I want to switch to PTA and the antenna installation in inverse.
The vendor driver's code about this is also in halbtc8723b1ant_SetAntPath.
> > /*
> > * Software control, antenna at WiFi side
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > index 8136e268b4e6..87b2179a769e 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> >
> > /* Check if MAC is already powered on */
> > val8 = rtl8xxxu_read8(priv, REG_CR);
> > + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
> >
> > /*
> > * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> > * initialized. First MAC returns 0xea, second MAC returns 0x00
> > */
> > - if (val8 == 0xea)
> > + if (val8 == 0xea || !(val16 & BIT(11)))
> > macpower = false;
> > else
> > macpower = true;
>
> At a glance I can't see which code this corresponds to in the vendor
> driver, can you point that out?
>
> Thanks
> Daniel
It's in rtl8723bu_hal_init and the comment says "Check if MAC has already
power on". In vendor driver, it's just for output messages but in rtl8xxxu, it
will determine whether if the llt_init() and tx related registers
being correctly
initialized. I sometimes hit the problem of connection failure after boot and
it's because the macpower is falsely true.
Chris
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: fix GCC8 warning for strncpy
From: Magnus Karlsson @ 2019-07-02 7:32 UTC (permalink / raw)
To: Y Song
Cc: Andrii Nakryiko, Andrii Nakryiko, bpf, netdev, Alexei Starovoitov,
Daniel Borkmann, Magnus Karlsson
In-Reply-To: <CAH3MdRUv9eJuecKq7weG614+6oEtfLeUHnTxoU19qr39p9-mrQ@mail.gmail.com>
On Tue, Jul 2, 2019 at 8:10 AM Y Song <ys114321@gmail.com> wrote:
>
> On Mon, Jul 1, 2019 at 10:47 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > GCC8 started emitting warning about using strncpy with number of bytes
> > exactly equal destination size, which is generally unsafe, as can lead
> > to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
> > of bytes to ensure name is always zero-terminated.
> >
> > Cc: Magnus Karlsson <magnus.karlsson@intel.com>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/xsk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> > index bf15a80a37c2..9588e7f87d0b 100644
> > --- a/tools/lib/bpf/xsk.c
> > +++ b/tools/lib/bpf/xsk.c
> > @@ -327,7 +327,7 @@ static int xsk_get_max_queues(struct xsk_socket *xsk)
> >
> > channels.cmd = ETHTOOL_GCHANNELS;
> > ifr.ifr_data = (void *)&channels;
> > - strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ);
> > + strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1);
>
> To accommodate the xsk->ifname string length FNAMSIZ - 1, we need to have
> ifr.ifr_name[FNAMSIZ - 1] = '\0';
> right?
Yes. Since the ifr struct is allocated from the stack and not zeroed,
we should do this.
Thanks to both of you for catching this.
/Magnus
> > err = ioctl(fd, SIOCETHTOOL, &ifr);
> > if (err && errno != EOPNOTSUPP) {
> > ret = -errno;
> > --
> > 2.17.1
> >
^ permalink raw reply
* [PATCH net-next] hinic: remove standard netdev stats
From: Xue Chaojing @ 2019-07-01 23:40 UTC (permalink / raw)
To: davem
Cc: linux-kernel, netdev, luoshaokai, cloud.wangxiaoyun, xuechaojing,
chiqijun, wulike1
This patch removes standard netdev stats in ethtool -S.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
.../net/ethernet/huawei/hinic/hinic_ethtool.c | 47 +------------------
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index 8d98f37c88a8..73a20f01ad4c 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -440,35 +440,6 @@ static u32 hinic_get_rxfh_indir_size(struct net_device *netdev)
#define ARRAY_LEN(arr) ((int)((int)sizeof(arr) / (int)sizeof(arr[0])))
-#define HINIC_NETDEV_STAT(_stat_item) { \
- .name = #_stat_item, \
- .size = FIELD_SIZEOF(struct rtnl_link_stats64, _stat_item), \
- .offset = offsetof(struct rtnl_link_stats64, _stat_item) \
-}
-
-static struct hinic_stats hinic_netdev_stats[] = {
- HINIC_NETDEV_STAT(rx_packets),
- HINIC_NETDEV_STAT(tx_packets),
- HINIC_NETDEV_STAT(rx_bytes),
- HINIC_NETDEV_STAT(tx_bytes),
- HINIC_NETDEV_STAT(rx_errors),
- HINIC_NETDEV_STAT(tx_errors),
- HINIC_NETDEV_STAT(rx_dropped),
- HINIC_NETDEV_STAT(tx_dropped),
- HINIC_NETDEV_STAT(multicast),
- HINIC_NETDEV_STAT(collisions),
- HINIC_NETDEV_STAT(rx_length_errors),
- HINIC_NETDEV_STAT(rx_over_errors),
- HINIC_NETDEV_STAT(rx_crc_errors),
- HINIC_NETDEV_STAT(rx_frame_errors),
- HINIC_NETDEV_STAT(rx_fifo_errors),
- HINIC_NETDEV_STAT(rx_missed_errors),
- HINIC_NETDEV_STAT(tx_aborted_errors),
- HINIC_NETDEV_STAT(tx_carrier_errors),
- HINIC_NETDEV_STAT(tx_fifo_errors),
- HINIC_NETDEV_STAT(tx_heartbeat_errors),
-};
-
#define HINIC_FUNC_STAT(_stat_item) { \
.name = #_stat_item, \
.size = FIELD_SIZEOF(struct hinic_vport_stats, _stat_item), \
@@ -658,20 +629,11 @@ static void hinic_get_ethtool_stats(struct net_device *netdev,
{
struct hinic_dev *nic_dev = netdev_priv(netdev);
struct hinic_vport_stats vport_stats = {0};
- const struct rtnl_link_stats64 *net_stats;
struct hinic_phy_port_stats *port_stats;
- struct rtnl_link_stats64 temp;
u16 i = 0, j = 0;
char *p;
int err;
- net_stats = dev_get_stats(netdev, &temp);
- for (j = 0; j < ARRAY_LEN(hinic_netdev_stats); j++, i++) {
- p = (char *)net_stats + hinic_netdev_stats[j].offset;
- data[i] = (hinic_netdev_stats[j].size ==
- sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
- }
-
err = hinic_get_vport_stats(nic_dev, &vport_stats);
if (err)
netif_err(nic_dev, drv, netdev,
@@ -716,8 +678,7 @@ static int hinic_get_sset_count(struct net_device *netdev, int sset)
switch (sset) {
case ETH_SS_STATS:
q_num = nic_dev->num_qps;
- count = ARRAY_LEN(hinic_netdev_stats) +
- ARRAY_LEN(hinic_function_stats) +
+ count = ARRAY_LEN(hinic_function_stats) +
(ARRAY_LEN(hinic_tx_queue_stats) +
ARRAY_LEN(hinic_rx_queue_stats)) * q_num;
@@ -738,12 +699,6 @@ static void hinic_get_strings(struct net_device *netdev,
switch (stringset) {
case ETH_SS_STATS:
- for (i = 0; i < ARRAY_LEN(hinic_netdev_stats); i++) {
- memcpy(p, hinic_netdev_stats[i].name,
- ETH_GSTRING_LEN);
- p += ETH_GSTRING_LEN;
- }
-
for (i = 0; i < ARRAY_LEN(hinic_function_stats); i++) {
memcpy(p, hinic_function_stats[i].name,
ETH_GSTRING_LEN);
--
2.17.1
^ permalink raw reply related
* Re: INFO: task hung in vhost_init_device_iotlb
From: Jason Wang @ 2019-07-02 7:23 UTC (permalink / raw)
To: Dmitry Vyukov, Michael S. Tsirkin
Cc: syzbot, KVM list, LKML, netdev, syzkaller-bugs, virtualization
In-Reply-To: <CACT4Y+Yiz2NpDMNLSP+Z-qf9Swo56Yhb0CbmrUyPHojmMZzCAQ@mail.gmail.com>
On 2019/1/30 下午4:12, Dmitry Vyukov wrote:
> On Tue, Jan 29, 2019 at 5:06 PM Michael S. Tsirkin<mst@redhat.com> wrote:
>> On Tue, Jan 29, 2019 at 01:22:02AM -0800, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 983542434e6b Merge tag 'edac_fix_for_5.0' of git://git.ker..
>>> git tree: upstream
>>> console output:https://syzkaller.appspot.com/x/log.txt?x=17476498c00000
>>> kernel config:https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
>>> dashboard link:https://syzkaller.appspot.com/bug?extid=40e28a8bd59d10ed0c42
>>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>> Hmm nothing obvious below. Generic corruption elsewhere?
> Hard to say, a silent memory corruption is definitely possible.
> If there is nothing obvious let's wait, maybe syzbot will come up with
> a repro or we get more such hangs so that it will be possible to rule
> out flakes/corruptions.
>
It hasn't been reproduced for a while. We can invalid this and see if we
can get it again.
So
#syz invalid
Thanks
^ permalink raw reply
* Re: Reminder: 2 open syzbot bugs in vhost subsystem
From: Jason Wang @ 2019-07-02 7:18 UTC (permalink / raw)
To: Eric Biggers
Cc: kvm, virtualization, netdev, Michael S. Tsirkin, Hillf Danton,
linux-kernel, syzkaller-bugs
In-Reply-To: <20190702053223.GA27702@sol.localdomain>
On 2019/7/2 下午1:32, Eric Biggers wrote:
> On Tue, Jul 02, 2019 at 01:24:43PM +0800, Jason Wang wrote:
>>> --------------------------------------------------------------------------------
>>> Title: INFO: task hung in vhost_init_device_iotlb
>>> Last occurred: 125 days ago
>>> Reported: 153 days ago
>>> Branches: Mainline and others
>>> Dashboard link: https://syzkaller.appspot.com/bug?id=cb1ea8daf03a5942c2ab314679148cf6e128ef58
>>> Original thread: https://lkml.kernel.org/lkml/0000000000007e86fd058095533f@google.com/T/#u
>>>
>>> Unfortunately, this bug does not have a reproducer.
>>>
>>> The original thread for this bug received 2 replies; the last was 152 days ago.
>>>
>>> If you fix this bug, please add the following tag to the commit:
>>> Reported-by: syzbot+40e28a8bd59d10ed0c42@syzkaller.appspotmail.com
>>>
>>> If you send any email or patch for this bug, please consider replying to the
>>> original thread. For the git send-email command to use, or tips on how to reply
>>> if the thread isn't in your mailbox, see the "Reply instructions" at
>>> https://lkml.kernel.org/r/0000000000007e86fd058095533f@google.com
>>>
>> Can syzbot still reproduce this issue?
> Apparently not, as it last occurred 125 days ago.
>
> That doesn't necessarily mean the bug isn't still there, though.
>
> But if you (as a person familiar with the code) think it's no longer valid or
> not actionable, you can invalidate it.
>
> - Eric
Thanks for the hint.
Let me try to invalidate it in the original thread.
^ permalink raw reply
* Re: [PATCH 2/3 bpf-next] i40e: Support zero-copy XDP_TX on the RX path for AF_XDP sockets.
From: Maxim Mikityanskiy @ 2019-07-02 7:07 UTC (permalink / raw)
To: Jonathan Lemon
Cc: netdev@vger.kernel.org, bjorn.topel@intel.com,
magnus.karlsson@intel.com, jakub.kicinski@netronome.com,
jeffrey.t.kirsher@intel.com, kernel-team@fb.com
In-Reply-To: <20190628221555.3009654-3-jonathan.lemon@gmail.com>
On 2019-06-29 01:15, Jonathan Lemon wrote:
> + xdpf = convert_to_xdp_frame_keep_zc(xdp);
> + if (unlikely(!xdpf))
> + return I40E_XDP_CONSUMED;
> + xdpf->handle = xdp->handle;
Shouldn't this line belong to convert_to_xdp_frame_keep_zc (and the
previous patch)? It looks like it's code common for all drivers, and
also patch 1 adds the handle field, but doesn't use it, which looks weird.
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: remove get_mtu indirection from xfrm_type
From: Steffen Klassert @ 2019-07-02 7:00 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20190624200448.8753-1-fw@strlen.de>
On Mon, Jun 24, 2019 at 10:04:48PM +0200, Florian Westphal wrote:
> esp4_get_mtu and esp6_get_mtu are exactly the same, the only difference
> is a single sizeof() (ipv4 vs. ipv6 header).
>
> Merge both into xfrm_state_mtu() and remove the indirection.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks a lot!
^ permalink raw reply
* [PATCH] ss: in --numeric mode, print raw numbers for data rates
From: Tomasz Torcz @ 2019-07-02 6:53 UTC (permalink / raw)
To: dsahern; +Cc: netdev, Tomasz Torcz
In-Reply-To: <13d80225-8b36-3990-4718-aafbb9602d7d@gmail.com>
ss by default shows data rates in human-readable form - as Mbps/Gbps etc.
Enhance --numeric mode to show raw values in bps, without conversion.
Signed-of-by: Tomasz Torcz <tomasz.torcz@nordea.com>
---
man/man8/ss.8 | 2 +-
misc/ss.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 9054fab9..f428e60c 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -28,7 +28,7 @@ Suppress header line.
Print each socket's data on a single line.
.TP
.B \-n, \-\-numeric
-Do not try to resolve service names.
+Do not try to resolve service names. Show exact bandwidth values, instead of human-readable.
.TP
.B \-r, \-\-resolve
Try to resolve numeric address/ports.
diff --git a/misc/ss.c b/misc/ss.c
index 99c06d31..3d9d1d8f 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2361,7 +2361,9 @@ static int proc_inet_split_line(char *line, char **loc, char **rem, char **data)
static char *sprint_bw(char *buf, double bw)
{
- if (bw > 1000000.)
+ if (!resolve_services)
+ sprintf(buf, "%.0f", bw);
+ else if (bw > 1000000.)
sprintf(buf, "%.1fM", bw / 1000000.);
else if (bw > 1000.)
sprintf(buf, "%.1fK", bw / 1000.);
--
2.21.0
^ permalink raw reply related
* [iproute2] Can't create ip6 tunnel device
From: Ji Jianwen @ 2019-07-02 6:53 UTC (permalink / raw)
To: netdev; +Cc: stephen
Hello there,
I got error when creating ip6 tunnel device on a rhel-8.0.0 system.
Here are the steps to reproduce the issue.
# # uname -r
4.18.0-80.el8.x86_64
# dnf install -y libcap-devel bison flex git gcc
# git clone git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
# cd iproute2 && git log --pretty=oneline --abbrev-commit
d0272f54 (HEAD -> master, origin/master, origin/HEAD) devlink: fix
libc and kernel headers collision
ee09370a devlink: fix format string warning for 32bit targets
68c46872 ip address: do not set mngtmpaddr option for IPv4 addresses
e4448b6c ip address: do not set home option for IPv4 addresses
....
# ./configure && make && make install
# ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2
local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev eno1 --->
please replace eno1 with the network card name of your system
add tunnel "ip6tnl0" failed: File exists
Please help take a look. Thanks!
Br,
Jianwen
^ permalink raw reply
* Re: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
From: Colin Ian King @ 2019-07-02 6:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: alexandre.torgue, davem, joabreu, kernel-janitors,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, peppe.cavallaro
In-Reply-To: <CAFBinCCpJLSQiUeqpQTKQDgjy7-ROgjYa913Xe1My_oc6miTzw@mail.gmail.com>
On 01/07/2019 23:43, Martin Blumenstingl wrote:
> On Fri, Jun 28, 2019 at 6:05 PM Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>>
>> Hi Colin,
>>
>> On Fri, Jun 28, 2019 at 10:32 AM Colin Ian King
>> <colin.king@canonical.com> wrote:
>>>
>>> On 28/06/2019 05:15, Martin Blumenstingl wrote:
>>>> On Tue, Jun 25, 2019 at 9:58 AM Colin Ian King <colin.king@canonical.com> wrote:
>>>>>
>>>>> On 25/06/2019 05:44, Martin Blumenstingl wrote:
>>>>>> Hi Colin,
>>>>>>
>>>>>> On Thu, Jun 20, 2019 at 3:34 AM Martin Blumenstingl
>>>>>> <martin.blumenstingl@googlemail.com> wrote:
>>>>>>>
>>>>>>> Hi Colin,
>>>>>>>
>>>>>>> On Wed, Jun 19, 2019 at 8:55 AM Colin Ian King <colin.king@canonical.com> wrote:
>>>>>>>>
>>>>>>>> On 19/06/2019 06:13, Martin Blumenstingl wrote:
>>>>>>>>> Hi Colin,
>>>>>>>>>
>>>>>>>>>> Currently the call to device_property_read_u32_array is not error checked
>>>>>>>>>> leading to potential garbage values in the delays array that are then used
>>>>>>>>>> in msleep delays. Add a sanity check to the property fetching.
>>>>>>>>>>
>>>>>>>>>> Addresses-Coverity: ("Uninitialized scalar variable")
>>>>>>>>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>>>>>>>> I have also sent a patch [0] to fix initialize the array.
>>>>>>>>> can you please look at my patch so we can work out which one to use?
>>>>>>>>>
>>>>>>>>> my concern is that the "snps,reset-delays-us" property is optional,
>>>>>>>>> the current dt-bindings documentation states that it's a required
>>>>>>>>> property. in reality it isn't, there are boards (two examples are
>>>>>>>>> mentioned in my patch: [0]) without it.
>>>>>>>>>
>>>>>>>>> so I believe that the resulting behavior has to be:
>>>>>>>>> 1. don't delay if this property is missing (instead of delaying for
>>>>>>>>> <garbage value> ms)
>>>>>>>>> 2. don't error out if this property is missing
>>>>>>>>>
>>>>>>>>> your patch covers #1, can you please check whether #2 is also covered?
>>>>>>>>> I tested case #2 when submitting my patch and it worked fine (even
>>>>>>>>> though I could not reproduce the garbage values which are being read
>>>>>>>>> on some boards)
>>>>>> in the meantime I have tested your patch.
>>>>>> when I don't set the "snps,reset-delays-us" property then I get the
>>>>>> following error:
>>>>>> invalid property snps,reset-delays-us
>>>>>>
>>>>>> my patch has landed in the meantime: [0]
>>>>>> how should we proceed with your patch?
>>>
>>> Your fix is good, so I think we should just drop/forget about my fix.
>> thank you for looking at the situation
>>
>> as far I understand the -net/-net-next tree all commits are immutable
>> so if we want to remove your patch we need to send a revert
>> do you want me to do that (I can do it on Monday) or will you take care of that?
> I just sent the patch: [0]
Thank you, much appreciated.
>
>
> [0] https://patchwork.ozlabs.org/patch/1125686/
>
^ permalink raw reply
* Re: KASAN: use-after-free Write in xfrm_hash_rebuild
From: Dmitry Vyukov @ 2019-07-02 6:43 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, David Miller, Herbert Xu, LKML, netdev, Steffen Klassert,
syzkaller-bugs
In-Reply-To: <000000000000db481c058c462e4c@google.com>
On Tue, Jul 2, 2019 at 8:38 AM Hillf Danton <hdanton@sina.com> wrote:
>
>
> On Wed, 26 Jun 2019 20:59:05 -0700 (PDT)
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10f017c3a00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
> > dashboard link: https://syzkaller.appspot.com/bug?extid=0165480d4ef07360eeda
> > compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf37c3a00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in __write_once_size include/linux/compiler.h:221 [inline]
> > BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:748 [inline]
> > BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455 [inline]
> > BUG: KASAN: use-after-free in xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
> > Write of size 8 at addr ffff888095e79c00 by task kworker/1:3/8066
> >
> > CPU: 1 PID: 8066 Comm: kworker/1:3 Not tainted 5.2.0-rc6+ #7
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events xfrm_hash_rebuild
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
> > print_address_description+0x6d/0x310 mm/kasan/report.c:188
> > __kasan_report+0x14b/0x1c0 mm/kasan/report.c:317
> > kasan_report+0x26/0x50 mm/kasan/common.c:614
> > __asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137
> > __write_once_size include/linux/compiler.h:221 [inline]
> > __hlist_del include/linux/list.h:748 [inline]
> > hlist_del_rcu include/linux/rculist.h:455 [inline]
> > xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
> > process_one_work+0x814/0x1130 kernel/workqueue.c:2269
> > worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
> > kthread+0x325/0x350 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> > Allocated by task 8064:
> > save_stack mm/kasan/common.c:71 [inline]
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:489
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
> > __do_kmalloc mm/slab.c:3660 [inline]
> > __kmalloc+0x23c/0x310 mm/slab.c:3669
> > kmalloc include/linux/slab.h:552 [inline]
> > kzalloc include/linux/slab.h:742 [inline]
> > xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
> > xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
> > xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
> > ops_init+0x336/0x420 net/core/net_namespace.c:130
> > setup_net+0x212/0x690 net/core/net_namespace.c:316
> > copy_net_ns+0x224/0x380 net/core/net_namespace.c:439
> > create_new_namespaces+0x4ec/0x700 kernel/nsproxy.c:103
> > unshare_nsproxy_namespaces+0x12a/0x190 kernel/nsproxy.c:202
> > ksys_unshare+0x540/0xac0 kernel/fork.c:2692
> > __do_sys_unshare kernel/fork.c:2760 [inline]
> > __se_sys_unshare kernel/fork.c:2758 [inline]
> > __x64_sys_unshare+0x38/0x40 kernel/fork.c:2758
> > do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 17:
> > save_stack mm/kasan/common.c:71 [inline]
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:451
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
> > __cache_free mm/slab.c:3432 [inline]
> > kfree+0xae/0x120 mm/slab.c:3755
> > xfrm_hash_free+0x38/0xd0 net/xfrm/xfrm_hash.c:35
> > xfrm_bydst_resize net/xfrm/xfrm_policy.c:602 [inline]
> > xfrm_hash_resize+0x13f1/0x1840 net/xfrm/xfrm_policy.c:680
> > process_one_work+0x814/0x1130 kernel/workqueue.c:2269
> > worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
> > kthread+0x325/0x350 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> > The buggy address belongs to the object at ffff888095e79c00
> > which belongs to the cache kmalloc-64 of size 64
> > The buggy address is located 0 bytes inside of
> > 64-byte region [ffff888095e79c00, ffff888095e79c40)
> > The buggy address belongs to the page:
> > page:ffffea0002579e40 refcount:1 mapcount:0 mapping:ffff8880aa400340
> > index:0x0
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea0002540888 ffffea0002907548 ffff8880aa400340
> > raw: 0000000000000000 ffff888095e79000 0000000100000020 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff888095e79b00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> > ffff888095e79b80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> > > ffff888095e79c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> > ^
> > ffff888095e79c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> > ffff888095e79d00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> > ==================================================================
> >
>
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -1203,6 +1203,11 @@ xfrm_policy_inexact_insert(struct xfrm_policy *policy, u8 dir, int excl)
> return delpol;
> }
>
> +static inline bool xfrm_policy_node_hashed(struct hlist_node *node)
> +{
> + return node->pprev && node->pprev != LIST_POISON2;
Is it right to open code LIST_POISON2 use here? As far as I see all
current uses of LIST_POISON2 are encapsulated in list functions.
> +}
> +
> static void xfrm_hash_rebuild(struct work_struct *work)
> {
> struct net *net = container_of(work, struct net,
> @@ -1315,7 +1320,9 @@ static void xfrm_hash_rebuild(struct work_struct *work)
> chain = policy_hash_bysel(net, &policy->selector,
> policy->family, dir);
>
> - hlist_del_rcu(&policy->bydst);
> + /* check bydst still hashed in case that policy survived bydst resize */
> + if (xfrm_policy_node_hashed(&policy->bydst))
> + hlist_del_rcu(&policy->bydst);
>
> if (!chain) {
> void *p = xfrm_policy_inexact_insert(policy, dir, 0);
> --
^ permalink raw reply
* Re: [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs
From: Leon Romanovsky @ 2019-07-02 6:41 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Idan Burstein, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Yamin Friedman, Max Gurtovoy
In-Reply-To: <9d26c90c-8e0b-656f-341f-a67251549126@grimberg.me>
On Mon, Jul 01, 2019 at 10:36:41PM -0700, Sagi Grimberg wrote:
> Hey Idan,
>
> > " Please don't. This is a bad choice to opt it in by default."
> >
> > I disagree here. I'd prefer Linux to have good out of the box experience (e.g. reach 100G in 4K NVMeOF on Intel servers) with the default parameters. Especially since Yamin have shown it is beneficial / not hurting in terms of performance for variety of use cases. The whole concept of DIM is that it adapts to the workload requirements in terms of bandwidth and latency.
>
> Well, its a Mellanox device driver after all.
>
> But do note that by far, the vast majority of users are not saturating
> 100G of 4K I/O. The absolute vast majority of users are primarily
> sensitive to synchronous QD=1 I/O latency, and when the workload
> is much more dynamic than the synthetic 100%/50%/0% read mix.
>
> As much as I'm a fan (IIRC I was the one giving a first pass at this),
> the dim default opt-in is not only not beneficial, but potentially
> harmful to the majority of users out-of-the-box experience.
>
> Given that this is a fresh code with almost no exposure, and that was
> not tested outside of Yamin running limited performance testing, I think
> it would be a mistake to add it as a default opt-in, that can come as an
> incremental stage.
>
> Obviously, I cannot tell what Mellanox should/shouldn't do in its own
> device driver of course, but I just wanted to emphasize that I think
> this is a mistake.
Hi Sagi,
I'm not sharing your worries about bad out-of-the-box experience for a
number of reasons.
First of all, this code is part of upstream kernel and will take time
till users actually start to use it as is and not as part of some distro
backports or MOFED packages.
Second, Yamin did extensive testing and worked very close with Or G.
and I have very high confident in the results of their team work.
Third (outcome of first), actually the opposite is true, the setting
this option as a default will give us more time to fix/adjust code if
needed, before users will see any potential degradation.
>
> > Moreover, net-dim is enabled by default, I don't see why RDMA is different.
>
> Very different animals.
Yes and no, the logic behind is the same and both solutions have same
constrains of throughput vs. latency.
Thanks
^ permalink raw reply
* Reminder: 5 open syzbot bugs in "net/hsr" subsystem
From: Eric Biggers @ 2019-07-02 6:26 UTC (permalink / raw)
To: netdev, Arvid Brodin, David S. Miller; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 5 of them as possibly being bugs in the "net/hsr" subsystem. I've listed
these reports below, sorted by an algorithm that tries to list first the reports
most likely to be still valid, important, and actionable.
Of these 5 bugs, 4 were seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/hsr" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in hsr_register_frame_in
Last occurred: 1 day ago
Reported: 140 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=2ad30d6cef7180728e401174df99d001bae578fe
Original thread: https://lkml.kernel.org/lkml/0000000000003bb1540581a55575@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b8152ab439b9c5174ffd@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003bb1540581a55575@google.com
--------------------------------------------------------------------------------
Title: WARNING in hsr_addr_subst_dest
Last occurred: 0 days ago
Reported: 180 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=924b5574f42ebeddc94fad06f2fa329b199d58d3
Original thread: https://lkml.kernel.org/lkml/0000000000001b1a1d057e776c92@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 2 replies; the last was 111 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b92e4f1472a54e1c7dec@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001b1a1d057e776c92@google.com
--------------------------------------------------------------------------------
Title: WARNING in hsr_forward_skb
Last occurred: 0 days ago
Reported: 180 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=13de4605e86ebcf39093017dc255aa0fd6c2f12d
Original thread: https://lkml.kernel.org/lkml/0000000000009f94c1057e772431@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 4 replies; the last was 110 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+fdce8f2a8903f3ba0e6b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009f94c1057e772431@google.com
--------------------------------------------------------------------------------
Title: memory leak in hsr_create_self_node
Last occurred: 4 days ago
Reported: 35 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=291f241bec2fdf1bc2418cca91cc1d4e7f36027b
Original thread: https://lkml.kernel.org/lkml/000000000000ea09dd0589e3af1a@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c6167ec3de7def23d1e8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ea09dd0589e3af1a@google.com
--------------------------------------------------------------------------------
Title: BUG: corrupted list in hsr_prune_nodes
Last occurred: 78 days ago
Reported: 78 days ago
Branches: bpf-next
Dashboard link: https://syzkaller.appspot.com/bug?id=583fd57905151af7bc057ec47208d4873e953db7
Original thread: https://lkml.kernel.org/lkml/000000000000ca5ede0586804c42@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+99ad9e40137a83c70ee3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ca5ede0586804c42@google.com
^ permalink raw reply
* Reminder: 6 open syzbot bugs in "net/smc" subsystem
From: Eric Biggers @ 2019-07-02 6:24 UTC (permalink / raw)
To: linux-s390, netdev, Ursula Braun, Karsten Graul, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 6 of them as possibly being bugs in the "net/smc" subsystem. I've listed
these reports below, sorted by an algorithm that tries to list first the reports
most likely to be still valid, important, and actionable.
Of these 6 bugs, 3 were seen in mainline in the last week.
Of these 6 bugs, 1 was bisected to a commit from the following person:
Ursula Braun <ubraun@linux.ibm.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/smc" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING in smc_unhash_sk (2)
Last occurred: 0 days ago
Reported: 79 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=f650845a184aed6947c0dd0f4d99d561335a7c31
Original thread: https://lkml.kernel.org/lkml/000000000000ac48ed05866bbc2c@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 50717a37db032ce783f50685a73bb2ac68471a5a
Author: Ursula Braun <ubraun@linux.ibm.com>
Date: Fri Apr 12 10:57:23 2019 +0000
net/smc: nonblocking connect rework
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+bd8cc73d665590a1fcad@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ac48ed05866bbc2c@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in __sk_destruct
Last occurred: 0 days ago
Reported: 428 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=591666b46bf0d9e2fbb8dbb386982d12ba804648
Original thread: https://lkml.kernel.org/lkml/000000000000451f9d056aff4397@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+92209502e7aab127c75f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000451f9d056aff4397@google.com
--------------------------------------------------------------------------------
Title: WARNING in debug_check_no_obj_freed
Last occurred: 2 days ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=83687867d4a435fce7c6045b34425b1cfb3bf2d6
Original thread: https://lkml.kernel.org/lkml/00000000000090ae7a058bc12946@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b972214bb803a343f4fe@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000090ae7a058bc12946@google.com
--------------------------------------------------------------------------------
Title: BUG: workqueue leaked lock or atomic in smc_tx_work
Last occurred: 5 days ago
Reported: 7 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=dd71ec2acfdd198626ec8e914f70afc70cf35c72
Original thread: https://lkml.kernel.org/lkml/0000000000006a28b5058c0d7e17@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8759e3927fd85a7c520a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006a28b5058c0d7e17@google.com
--------------------------------------------------------------------------------
Title: general protection fault in inet_accept
Last occurred: 193 days ago
Reported: 355 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=282e2b3c76b4d2fc3e28d16518b757336a40b4f7
Original thread: https://lkml.kernel.org/lkml/0000000000006e1bbe0570bea62e@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+2e9616288940d15a6476@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006e1bbe0570bea62e@google.com
--------------------------------------------------------------------------------
Title: general protection fault in __smc_diag_dump
Last occurred: 167 days ago
Reported: 180 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=4d03c161c6cc140b6234f534c6009d8c9da39f6c
Original thread: https://lkml.kernel.org/lkml/00000000000060600e057e7748dc@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 2 replies; the last was 175 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5dd1f9327a9ee760048c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000060600e057e7748dc@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/rxrpc" subsystem
From: Eric Biggers @ 2019-07-02 6:21 UTC (permalink / raw)
To: linux-afs, netdev, David Howells, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/rxrpc" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 3 bugs, 1 was seen in mainline in the last week.
Of these 3 bugs, 2 were bisected to commits from the following person:
David Howells <dhowells@redhat.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/rxrpc" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in rxrpc_connect_call
Last occurred: 14 days ago
Reported: 159 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=41872265f1e3e0489eb0cc8762f8d48b3667afdb
Original thread: https://lkml.kernel.org/lkml/00000000000033d5e205801b05d3@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7966f2a0b2c7da8939b4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000033d5e205801b05d3@google.com
--------------------------------------------------------------------------------
Title: kernel BUG at net/rxrpc/local_object.c:LINE!
Last occurred: 4 days ago
Reported: 4 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=53b6555b27af2cae74e2fbdac6cadc73f9cb18aa
Original thread: https://lkml.kernel.org/lkml/0000000000004c2416058c594b30@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000004c2416058c594b30@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in flush_workqueue_prep_pwqs
Last occurred: 9 days ago
Reported: 136 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=4ae48f9c43f87ccf9f2f270b14d5b9284dadd05c
Original thread: https://lkml.kernel.org/lkml/0000000000005c7e6f0581f1b86a@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0c4264acb66ea0484d11@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005c7e6f0581f1b86a@google.com
^ permalink raw reply
* [PATCH net-next] iavf: remove unused debug function iavf_debug_d
From: YueHaibing @ 2019-07-02 6:20 UTC (permalink / raw)
To: jeffrey.t.kirsher, davem, intel-wired-lan
Cc: linux-kernel, netdev, YueHaibing
There is no caller of function iavf_debug_d() in tree since
commit 75051ce4c5d8 ("iavf: Fix up debug print macro"),
so it can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 881561b..327dda8 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -143,28 +143,6 @@ enum iavf_status iavf_free_virt_mem_d(struct iavf_hw *hw,
}
/**
- * iavf_debug_d - OS dependent version of debug printing
- * @hw: pointer to the HW structure
- * @mask: debug level mask
- * @fmt_str: printf-type format description
- **/
-void iavf_debug_d(void *hw, u32 mask, char *fmt_str, ...)
-{
- char buf[512];
- va_list argptr;
-
- if (!(mask & ((struct iavf_hw *)hw)->debug_mask))
- return;
-
- va_start(argptr, fmt_str);
- vsnprintf(buf, sizeof(buf), fmt_str, argptr);
- va_end(argptr);
-
- /* the debug string is already formatted with a newline */
- pr_info("%s", buf);
-}
-
-/**
* iavf_schedule_reset - Set the flags and schedule a reset event
* @adapter: board private structure
**/
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] r8169: add random MAC address fallback
From: Heiner Kallweit @ 2019-07-02 6:18 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
>From 1c8bacf724f1450e5256c68fbff407305faf9cbd Mon Sep 17 00:00:00 2001
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 40 +++++++++++++++--------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 450c74dc1..d6c137b7f 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -6651,13 +6651,36 @@ static int rtl_get_ether_clk(struct rtl8169_private *tp)
return rc;
}
+static void rtl_init_mac_address(struct rtl8169_private *tp)
+{
+ struct net_device *dev = tp->dev;
+ u8 *mac_addr = dev->dev_addr;
+ int rc, i;
+
+ rc = eth_platform_get_mac_address(tp_to_dev(tp), mac_addr);
+ if (!rc)
+ goto done;
+
+ rtl_read_mac_address(tp, mac_addr);
+ if (is_valid_ether_addr(mac_addr))
+ goto done;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ mac_addr[i] = RTL_R8(tp, MAC0 + i);
+ if (is_valid_ether_addr(mac_addr))
+ goto done;
+
+ eth_hw_addr_random(dev);
+ dev_warn(tp_to_dev(tp), "can't read MAC address, setting random one\n");
+done:
+ rtl_rar_set(tp, mac_addr);
+}
+
static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
- /* align to u16 for is_valid_ether_addr() */
- u8 mac_addr[ETH_ALEN] __aligned(2) = {};
struct rtl8169_private *tp;
struct net_device *dev;
- int chipset, region, i;
+ int chipset, region;
int jumbo_max, rc;
dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
@@ -6749,16 +6772,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
- /* get MAC address */
- rc = eth_platform_get_mac_address(&pdev->dev, mac_addr);
- if (rc)
- rtl_read_mac_address(tp, mac_addr);
-
- if (is_valid_ether_addr(mac_addr))
- rtl_rar_set(tp, mac_addr);
-
- for (i = 0; i < ETH_ALEN; i++)
- dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
+ rtl_init_mac_address(tp);
dev->ethtool_ops = &rtl8169_ethtool_ops;
--
2.22.0
^ permalink raw reply related
* Reminder: 6 open syzbot bugs in "net/dccp" subsystem
From: Eric Biggers @ 2019-07-02 6:18 UTC (permalink / raw)
To: dccp, netdev, Gerrit Renker, David S. Miller; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 6 of them as possibly being bugs in the "net/dccp" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 6 bugs, 1 was seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/dccp" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Last occurred: 3 days ago
Reported: 603 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=0881c535c265ca965edc49c0ac3d0a9850d26eb1
Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c05611406f6a5055d38a272%40google.com
This bug has a C reproducer.
For some reason the original report email for this bug is missing from the LKML
archive at lore.kernel.org, so my script couldn't check whether anyone has
replied to it or not. The Google Groups link above should still work, though.
Also try searching for the bug title.
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in ccid2_hc_tx_packet_recv
Last occurred: 4 days ago
Reported: 455 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=31f032fe94df7aca6ce5d45455f6acefa26515e4
Original thread: https://lkml.kernel.org/lkml/0000000000003872fd0568da185f@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+554ccde221001ab5479a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003872fd0568da185f@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in ccid_hc_tx_delete
Last occurred: 45 days ago
Reported: 308 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3e769c60cb2d1cab692fd541dae957b1fd31bde4
Original thread: https://lkml.kernel.org/lkml/000000000000de3c7705746dcbb7@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3967c1caf256f4d5aefe@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000de3c7705746dcbb7@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in dccp_invalid_packet
Last occurred: 437 days ago
Reported: 438 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=89916fdba284272cdbd0bf00de942f41d052c3f4
Original thread: https://lkml.kernel.org/lkml/0000000000000e2bf3056a36962d@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+00763607efc31f91b276@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000e2bf3056a36962d@google.com
--------------------------------------------------------------------------------
Title: suspicious RCU usage at ./include/net/inet_sock.h:LINE
Last occurred: 513 days ago
Reported: 603 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=78f9fe251de26a75a60690bc2384d62d2db32299
Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/001a1140ad88c4f006055d3836d2%40google.com
This bug has a C reproducer.
For some reason the original report email for this bug is missing from the LKML
archive at lore.kernel.org, so my script couldn't check whether anyone has
replied to it or not. The Google Groups link above should still work, though.
Also try searching for the bug title.
--------------------------------------------------------------------------------
Title: WARNING: suspicious RCU usage in pid_task
Last occurred: 280 days ago
Reported: 380 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5b9f20bfdfb67155f627c5e13c258ca56eff026a
Original thread: https://lkml.kernel.org/lkml/0000000000002b532a056ebcb3eb@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 301 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c2d4c3ae3fd90bbaf059@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002b532a056ebcb3eb@google.com
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: fix GCC8 warning for strncpy
From: Y Song @ 2019-07-02 6:09 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: andrii.nakryiko, bpf, netdev, Alexei Starovoitov, Daniel Borkmann,
Magnus Karlsson
In-Reply-To: <20190702054647.1686489-1-andriin@fb.com>
On Mon, Jul 1, 2019 at 10:47 PM Andrii Nakryiko <andriin@fb.com> wrote:
>
> GCC8 started emitting warning about using strncpy with number of bytes
> exactly equal destination size, which is generally unsafe, as can lead
> to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
> of bytes to ensure name is always zero-terminated.
>
> Cc: Magnus Karlsson <magnus.karlsson@intel.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/lib/bpf/xsk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> index bf15a80a37c2..9588e7f87d0b 100644
> --- a/tools/lib/bpf/xsk.c
> +++ b/tools/lib/bpf/xsk.c
> @@ -327,7 +327,7 @@ static int xsk_get_max_queues(struct xsk_socket *xsk)
>
> channels.cmd = ETHTOOL_GCHANNELS;
> ifr.ifr_data = (void *)&channels;
> - strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ);
> + strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1);
To accommodate the xsk->ifname string length FNAMSIZ - 1, we need to have
ifr.ifr_name[FNAMSIZ - 1] = '\0';
right?
> err = ioctl(fd, SIOCETHTOOL, &ifr);
> if (err && errno != EOPNOTSUPP) {
> ret = -errno;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/3] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Heiner Kallweit @ 2019-07-02 6:07 UTC (permalink / raw)
To: Matthias Kaehlcke, Andrew Lunn
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190702000925.GD250418@google.com>
On 02.07.2019 02:09, Matthias Kaehlcke wrote:
> On Mon, Jul 01, 2019 at 11:09:02PM +0200, Andrew Lunn wrote:
>> On Mon, Jul 01, 2019 at 10:37:16PM +0200, Heiner Kallweit wrote:
>>> On 01.07.2019 22:02, Andrew Lunn wrote:
>>>> On Mon, Jul 01, 2019 at 12:52:24PM -0700, Matthias Kaehlcke wrote:
>>>>> The RTL8211E has extension pages, which can be accessed after
>>>>> selecting a page through a custom method. Add a function to
>>>>> modify bits in a register of an extension page and a few
>>>>> helpers for dealing with ext pages.
>>>>>
>>>>> rtl8211e_modify_ext_paged() and rtl821e_restore_page() are
>>>>> inspired by their counterparts phy_modify_paged() and
>>>>> phy_restore_page().
>>>>
>>>> Hi Matthias
>>>>
>>>> While an extended page is selected, what happens to the normal
>>>> registers in the range 0-0x1c? Are they still accessible?
>>>>
>>> AFAIK: no
>>
>> This it would be better to make use of the core paged access support,
>> so that locking is done correctly.
>
> Do I understand correctly that this would involve assigning
> .read/write_page and use phy_select_page() and phy_restore_page()?
>
> Besides the benefit of locking this would also result in less code and
> we could get rid of the custom _restore_page().
>
Interestingly certain Realtek PHY's (incl. RTL8211E) support two paging
mechanisms.
1. Normal paging (set reg 0x1f to page number) - set by core paging
2. Extended pages (set reg 0x1f to 7, and reg 0x1e to ext. page number)
Newer Realtek PHY's use normal paging only.
^ permalink raw reply
* [PATCH net-next] Revert "r8169: improve handling VLAN tag"
From: Heiner Kallweit @ 2019-07-02 5:59 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Al Viro
This reverts commit 759d095741721888b6ee51afa74e0a66ce65e974.
The patch was based on a misunderstanding. As Al Viro pointed out [0]
it's simply wrong on big endian. So let's revert it.
[0] https://marc.info/?t=156200975600004&r=1&w=2
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index a73f25321..22b2f3dcb 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -1528,7 +1528,7 @@ static int rtl8169_set_features(struct net_device *dev,
static inline u32 rtl8169_tx_vlan_tag(struct sk_buff *skb)
{
return (skb_vlan_tag_present(skb)) ?
- TxVlanTag | htons(skb_vlan_tag_get(skb)) : 0x00;
+ TxVlanTag | swab16(skb_vlan_tag_get(skb)) : 0x00;
}
static void rtl8169_rx_vlan_tag(struct RxDesc *desc, struct sk_buff *skb)
@@ -1536,8 +1536,7 @@ static void rtl8169_rx_vlan_tag(struct RxDesc *desc, struct sk_buff *skb)
u32 opts2 = le32_to_cpu(desc->opts2);
if (opts2 & RxVlanTag)
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
- ntohs(opts2 & 0xffff));
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), swab16(opts2 & 0xffff));
}
static void rtl8169_get_regs(struct net_device *dev, struct ethtool_regs *regs,
--
2.22.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