Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 2/5] net: add an info message to eth_platform_get_mac_address()
From: David Miller @ 2018-07-18 23:13 UTC (permalink / raw)
  To: brgl
  Cc: nsekhar, khilman, linux, grygorii.strashko, srinivas.kandagatla,
	lukas, robh, f.fainelli, dan.carpenter, ivan.khoronzhuk, david,
	gregkh, andrew, linux-arm-kernel, linux-kernel, linux-omap,
	netdev, bgolaszewski
In-Reply-To: <20180718161035.7005-3-brgl@bgdev.pl>

From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Wed, 18 Jul 2018 18:10:32 +0200

>  
> +	dev_info(dev, "read MAC address from %s\n", from);
>  	ether_addr_copy(mac_addr, addr);
>  	return 0;

Ugh, please don't do this.

We probe various bits of information from various sources during
driver probe, and none of them are more or less important than
the MAC address.  So singling this out for log info output is
really not such a great idea.

Thank you.

^ permalink raw reply

* Re: [PATCH 1/5] net: visually shrink eth_platform_get_mac_address()
From: David Miller @ 2018-07-18 23:10 UTC (permalink / raw)
  To: brgl
  Cc: nsekhar, khilman, linux, grygorii.strashko, srinivas.kandagatla,
	lukas, robh, f.fainelli, dan.carpenter, ivan.khoronzhuk, david,
	gregkh, andrew, linux-arm-kernel, linux-kernel, linux-omap,
	netdev, bgolaszewski
In-Reply-To: <20180718161035.7005-2-brgl@bgdev.pl>

From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Wed, 18 Jul 2018 18:10:31 +0200

> @@ -527,15 +527,10 @@ unsigned char * __weak arch_get_platform_mac_address(void)
>  
>  int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
>  {
> -	const unsigned char *addr;
> -	struct device_node *dp;
> +	struct device_node *dp = dev_is_pci(dev) ?
> +			pci_device_to_OF_node(to_pci_dev(dev)) : dev->of_node;
> +	const unsigned char *addr = NULL;
>  
> -	if (dev_is_pci(dev))
> -		dp = pci_device_to_OF_node(to_pci_dev(dev));
> -	else
> -		dp = dev->of_node;
> -

Reverse christmas tree is why the assignments are in the body of
the function instead of the declaration area.

Please don't do this, thanks.

^ permalink raw reply

* Re: [PATCH v2] tcp: identify cryptic messages as TCP seq # bugs
From: David Miller @ 2018-07-18 22:26 UTC (permalink / raw)
  To: rdunlap; +Cc: netdev, edumazet, jidanni
In-Reply-To: <a492fbea-5d2f-7b47-8692-e852957d798b@infradead.org>

From: Randy Dunlap <rdunlap@infradead.org>
Date: Tue, 17 Jul 2018 18:27:45 -0700

> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Attempt to make cryptic TCP seq number error messages clearer by
> (1) identifying the source of the message as "TCP", (2) identifying the
> errors as "seq # bug", and (3) grouping the field identifiers and values
> by separating them with commas.
> 
> E.g., the following message is changed from:
> 
> recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
> WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90
> 
> to:
> 
> TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 73BCB9AA, fl 0
> WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 tcp_recvmsg+0x694/0xba0
> 
> Suggested-by: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> v2: drop __func__ because it duplicates part of the error message.

Applied, thanks Randy.

^ permalink raw reply

* Re: [PATCH net-next] pktgen: convert safe uses of strncpy() to strcpy() to avoid string truncation warning
From: David Miller @ 2018-07-18 22:24 UTC (permalink / raw)
  To: jakub.kicinski; +Cc: oss-drivers, netdev
In-Reply-To: <20180717213224.14695-1-jakub.kicinski@netronome.com>

From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 17 Jul 2018 14:32:24 -0700

> GCC 8 complains:
> 
> net/core/pktgen.c: In function ‘pktgen_if_write’:
> net/core/pktgen.c:1419:4: warning: ‘strncpy’ output may be truncated copying between 0 and 31 bytes from a string of length 127 [-Wstringop-truncation]
>     strncpy(pkt_dev->src_max, buf, len);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/core/pktgen.c:1399:4: warning: ‘strncpy’ output may be truncated copying between 0 and 31 bytes from a string of length 127 [-Wstringop-truncation]
>     strncpy(pkt_dev->src_min, buf, len);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/core/pktgen.c:1290:4: warning: ‘strncpy’ output may be truncated copying between 0 and 31 bytes from a string of length 127 [-Wstringop-truncation]
>     strncpy(pkt_dev->dst_max, buf, len);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/core/pktgen.c:1268:4: warning: ‘strncpy’ output may be truncated copying between 0 and 31 bytes from a string of length 127 [-Wstringop-truncation]
>     strncpy(pkt_dev->dst_min, buf, len);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> There is no bug here, but the code is not perfect either.  It copies
> sizeof(pkt_dev->/member/) - 1 from user space into buf, and then does
> a strcmp(pkt_dev->/member/, buf) hence assuming buf will be null-terminated
> and shorter than pkt_dev->/member/ (pkt_dev->/member/ is never
> explicitly null-terminated, and strncpy() doesn't have to null-terminate
> so the assumption must be on buf).  The use of strncpy() without explicit
> null-termination looks suspicious.  Convert to use straight strcpy().
> 
> strncpy() would also null-pad the output, but that's clearly unnecessary
> since the author calls memset(pkt_dev->/member/, 0, sizeof(..)); prior
> to strncpy(), anyway.
> 
> While at it format the code for "dst_min", "dst_max", "src_min" and
> "src_max" in the same way by removing extra new lines in one case.
> 
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Jiong Wang <jiong.wang@netronome.com>

Applied, thanks Jakub.

^ permalink raw reply

* Re: [PATCH] net: cavium: Add fine-granular dependencies on PCI
From: David Miller @ 2018-07-18 22:22 UTC (permalink / raw)
  To: alexander.sverdlin
  Cc: netdev, aleksey.makarov, sgoutham, raghu.vatsavayi, vijaya.guvva,
	andrew, arnd
In-Reply-To: <20180717162358.1508-1-alexander.sverdlin@nokia.com>

From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date: Tue, 17 Jul 2018 18:23:58 +0200

> Add dependencies on PCI where necessary.
> 
> Fixes: 7e2bc7fb65 ("net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI")
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH net-next 1/1] tc-tests: initial version of fw filter unit tests
From: David Miller @ 2018-07-18 22:21 UTC (permalink / raw)
  To: kleib; +Cc: netdev, jhs, xiyou.wangcong, jiri, lucasb
In-Reply-To: <1531843974-25221-1-git-send-email-kleib@mojatatu.com>

From: Keara Leibovitz <kleib@mojatatu.com>
Date: Tue, 17 Jul 2018 12:12:54 -0400

> Create initial unit tests for the tc fw filter.
> 
> Signed-off-by: Keara Leibovitz <kleib@mojatatu.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH v3 net-next 6/8] lan743x: Add power management support
From: David Miller @ 2018-07-18 22:17 UTC (permalink / raw)
  To: Bryan.Whitehead; +Cc: netdev, UNGLinuxDriver
In-Reply-To: <20180719.071552.1853366394480223525.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Thu, 19 Jul 2018 07:15:52 +0900 (KST)

> Please remove these "#endif FOO, #ifdef FOO" sequences, and instead just have
> one large continuous "ifdef FOO, endif FOO" section.

BTW, there were other patches that had this problem too, so please
go through your entire submission correcting this.

Thank you.

^ permalink raw reply

* Re: [PATCH v3 net-next 6/8] lan743x: Add power management support
From: David Miller @ 2018-07-18 22:15 UTC (permalink / raw)
  To: Bryan.Whitehead; +Cc: netdev, UNGLinuxDriver
In-Reply-To: <1531947878-9758-7-git-send-email-Bryan.Whitehead@microchip.com>

From: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Date: Wed, 18 Jul 2018 17:04:36 -0400

> +#ifdef CONFIG_PM
> +static void lan743x_ethtool_get_wol(struct net_device *netdev,
> +				    struct ethtool_wolinfo *wol)
> +{
> +	struct lan743x_adapter *adapter = netdev_priv(netdev);
> +
> +	wol->supported = 0;
> +	wol->wolopts = 0;
> +	phy_ethtool_get_wol(netdev->phydev, wol);
> +
> +	wol->supported &= WAKE_BCAST | WAKE_UCAST | WAKE_MCAST |
> +		WAKE_MAGIC | WAKE_PHY | WAKE_ARP;
> +
> +	wol->wolopts &= adapter->wolopts;
> +}
> +#endif /* CONFIG_PM */
> +
> +#ifdef CONFIG_PM

Please remove these "#endif FOO, #ifdef FOO" sequences, and instead just have
one large continuous "ifdef FOO, endif FOO" section.

Thank you.

^ permalink raw reply

* Re: [PATCH v2 net-next 0/8] PTP support for mv88e6165 family
From: David Miller @ 2018-07-18 22:07 UTC (permalink / raw)
  To: andrew; +Cc: richardcochran, vivien.didelot, netdev
In-Reply-To: <1531946307-22752-1-git-send-email-andrew@lunn.ch>

From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 18 Jul 2018 22:38:19 +0200

> The mv88e6165 family of switches supports PTP. It is however not fully
> compatible with the current PTP support in the mv88e6xxx driver. This
> patchset adds a level of abstraction to the PTP code, and then adds
> the code needed to support the mv88e6165 family.
> 
> v2: Correctly cluster local variables in mv88e6xxx_ptp_setup()
>     Added Acked-by: Richard Cochran <richardcochran@gmail.com>

Series applied, thanks Andrew.

^ permalink raw reply

* Re: [PATCH] ptp: fix missing break in switch
From: Gustavo A. R. Silva @ 2018-07-18 22:39 UTC (permalink / raw)
  To: David Miller; +Cc: stefan.sorensen, richardcochran, netdev, linux-kernel
In-Reply-To: <20180719.072608.944784986385146557.davem@davemloft.net>



On 07/18/2018 05:26 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 17 Jul 2018 20:17:33 -0500
> 
>> It seems that a *break* is missing in order to avoid falling through
>> to the default case. Otherwise, checking *chan* makes no sense.
>>
>> Fixes: 72df7a7244c0 ("ptp: Allow reassigning calibration pin function")
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> 
> Applied and queued up for -stable, thank you.
> 

Great. Glad to help. :)

Thanks
--
Gustavo

^ permalink raw reply

* RE: [PATCH v3 net-next 6/8] lan743x: Add power management support
From: Bryan.Whitehead @ 2018-07-18 21:55 UTC (permalink / raw)
  To: andrew; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <20180718213513.GA23800@lunn.ch>

> > +#ifdef CONFIG_PM
> > +static void lan743x_ethtool_get_wol(struct net_device *netdev,
> > +				    struct ethtool_wolinfo *wol)
> > +{
> > +	struct lan743x_adapter *adapter = netdev_priv(netdev);
> > +
> > +	wol->supported = 0;
> > +	wol->wolopts = 0;
> > +	phy_ethtool_get_wol(netdev->phydev, wol);
> > +
> > +	wol->supported &= WAKE_BCAST | WAKE_UCAST | WAKE_MCAST |
> > +		WAKE_MAGIC | WAKE_PHY | WAKE_ARP;
> 
> Hi Bryan
> 
> Say the PHY set WAKE_MAGICSECURE, because it supports that. This AND
> then wipes it out, making the call to phy_ethtool_get_wol() pointless.
> In fact, should this AND be an OR?

Hi Andrew,
I assumed that "supported" means that it is supported by both the phy and mac driver, which is why I used the AND operator.
Am I mistaken? Is WAKE_MAGICSECURE a special case not requiring mac driver support?


> 
> > +
> > +#ifdef CONFIG_PM
> > +static int lan743x_ethtool_set_wol(struct net_device *netdev,
> > +				   struct ethtool_wolinfo *wol)
> > +{
> > +	struct lan743x_adapter *adapter = netdev_priv(netdev);
> > +
> > +	if (wol->wolopts & WAKE_MAGICSECURE)
> > +		return -EOPNOTSUPP;
> 
> The PHY might support this. Since you call phy_ethtool_set_wol(), you
> should give it the chance.
> 
Again, does WAKE_MAGICSECURE require mac driver support?
If so then it does not matter if the phy driver supports it.
If I misunderstand, can you explain, or direct me to documents.

Thanks,
Bryan

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] docs: Convert alias and bridge to rst
From: David Miller @ 2018-07-18 22:28 UTC (permalink / raw)
  To: me; +Cc: markus.heiser, linux-doc, netdev, linux-kernel
In-Reply-To: <20180718032736.8000-1-me@tobin.cc>

From: "Tobin C. Harding" <me@tobin.cc>
Date: Wed, 18 Jul 2018 13:27:34 +1000

> Here is my first attempt at working on converting docs in
> Documentation/networking to rst format.  I've picked a couple of trivial
> ones to start with.  If there is anything extra I can do to make your
> life easier during documentation conversion please say.  (Also if there
> is some reason that it would be preferable to _not_ embark on this task
> please say :)
> 
> This set does not make any changes to the converted files apart from
> formatting.
 ...
> v2:
>  - remove incorrect patch from set (changing 'Indices' indentation)

Series applied, thanks Tobin.

^ permalink raw reply

* Re: [PATCH v3 net-next 7/8] lan743x: Add EEE support
From: Andrew Lunn @ 2018-07-18 21:46 UTC (permalink / raw)
  To: Bryan Whitehead; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <1531947878-9758-8-git-send-email-Bryan.Whitehead@microchip.com>

> +	if (eee->eee_enabled) {
> +		ret = phy_init_eee(phydev, 0);
> +		if (ret) {
> +			netif_err(adapter, drv, adapter->netdev,
> +				  "EEE initialization failed\n");
> +			return ret;
> +		}
> +
> +		buf = lan743x_csr_read(adapter, MAC_CR);
> +		buf |= MAC_CR_EEE_EN_;
> +		lan743x_csr_write(adapter, MAC_CR, buf);
> +
> +		phy_ethtool_set_eee(phydev, eee);

Hi Bryan

It could return an error, so please check the return value. Maybe move
this call out of the if to keep the code minimal?

     Andrew

^ permalink raw reply

* Re: [PATCH] ptp: fix missing break in switch
From: David Miller @ 2018-07-18 22:26 UTC (permalink / raw)
  To: gustavo; +Cc: stefan.sorensen, richardcochran, netdev, linux-kernel
In-Reply-To: <20180718011733.GA27872@embeddedor.com>

From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 17 Jul 2018 20:17:33 -0500

> It seems that a *break* is missing in order to avoid falling through
> to the default case. Otherwise, checking *chan* makes no sense.
> 
> Fixes: 72df7a7244c0 ("ptp: Allow reassigning calibration pin function")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

Applied and queued up for -stable, thank you.

^ permalink raw reply

* Re: [PATCH net,v2] hv_netvsc: Fix napi reschedule while receive completion is busy
From: David Miller @ 2018-07-18 22:24 UTC (permalink / raw)
  To: haiyangz, haiyangz
  Cc: netdev, kys, sthemmin, olaf, vkuznets, devel, linux-kernel,
	stephen
In-Reply-To: <20180717171113.6390-1-haiyangz@linuxonhyperv.com>

From: Haiyang Zhang <haiyangz@linuxonhyperv.com>
Date: Tue, 17 Jul 2018 17:11:13 +0000

> From: Haiyang Zhang <haiyangz@microsoft.com>
> 
> If out ring is full temporarily and receive completion cannot go out,
> we may still need to reschedule napi if certain conditions are met.
> Otherwise the napi poll might be stopped forever, and cause network
> disconnect.
> 
> Fixes: 7426b1a51803 ("netvsc: optimize receive completions")
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH net 3/3] tcp: do not delay ACK in DCTCP upon CE status change
From: Eric Dumazet @ 2018-07-18 21:44 UTC (permalink / raw)
  To: Yuchung Cheng, davem; +Cc: netdev, edumazet, ncardwell, brakmo, ysseung
In-Reply-To: <20180718205636.210731-4-ycheng@google.com>



On 07/18/2018 01:56 PM, Yuchung Cheng wrote:
> Per DCTCP RFC8257 (Section 3.2) the ACK reflecting the CE status change
> has to be sent immediately so the sender can respond quickly:
> 
> """ When receiving packets, the CE codepoint MUST be processed as follows:
> 
>    1.  If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to
>        true and send an immediate ACK.
> 
>    2.  If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE
>        to false and send an immediate ACK.
> """
> 
> Previously DCTCP implementation may continue to delay the ACK. This
> patch fixes that to implement the RFC by forcing an immediate ACK.


Oh well, more ACK packets ;)

Signed-off-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH] MAINTAINERS: Drop inactive Vitaly Bordug's email
From: David Miller @ 2018-07-18 22:22 UTC (permalink / raw)
  To: krzk; +Cc: pantelis.antoniou, linuxppc-dev, netdev, linux-kernel, vbordug,
	vitb
In-Reply-To: <20180717164154.6577-1-krzk@kernel.org>

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Tue, 17 Jul 2018 18:41:54 +0200

> The Vitaly Bordug's email bounces ("ru.mvista.com: Name or service not
> known") and there was no activity (ack, review, sign) since 2009.
> 
> Cc: Vitaly Bordug <vitb@kernel.crashing.org>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Applied.

^ permalink raw reply

* Re: [PATCH net 2/3] tcp: do not cancel delay-AcK on DCTCP special ACK
From: Eric Dumazet @ 2018-07-18 21:42 UTC (permalink / raw)
  To: Yuchung Cheng, davem; +Cc: netdev, edumazet, ncardwell, brakmo, ysseung
In-Reply-To: <20180718205636.210731-3-ycheng@google.com>



On 07/18/2018 01:56 PM, Yuchung Cheng wrote:
> Currently when a DCTCP receiver delays an ACK and receive a
> data packet with a different CE mark from the previous one's, it
> sends two immediate ACKs acking previous and latest sequences
> respectly (for ECN accounting).
> 
> Previously sending the first ACK may mark off the delayed ACK timer
> (tcp_event_ack_sent). This may subsequently prevent sending the
> second ACK to acknowledge the latest sequence (tcp_ack_snd_check).
> The culprit is that tcp_send_ack() assumes it always acknowleges
> the latest sequence, which is not true for the first special ACK.
> 
> The fix is to not make the assumption in tcp_send_ack and check the
> actual ack sequence before cancelling the delayed ACK. Further it's
> safer to pass the ack sequence number as a local variable into
> tcp_send_ack routine, instead of intercepting tp->rcv_nxt to avoid
> future bugs like this.
> 
> Reported-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>

Signed-off-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH net 1/3] tcp: helpers to send special DCTCP ack
From: Eric Dumazet @ 2018-07-18 21:42 UTC (permalink / raw)
  To: Yuchung Cheng, davem; +Cc: netdev, edumazet, ncardwell, brakmo, ysseung
In-Reply-To: <20180718205636.210731-2-ycheng@google.com>



On 07/18/2018 01:56 PM, Yuchung Cheng wrote:
> Refactor and create helpers to send the special ACK in DCTCP.
> 
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> ---
>  net/ipv4/tcp_output.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)


tcp_send_ack() could be an inline, but that is a very minor point.

Signed-off-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply

* Re: [PATCH mlx5-next 0/8] Mellanox, mlx5 updates 2018-07-16
From: Saeed Mahameed @ 2018-07-18 21:41 UTC (permalink / raw)
  To: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
  Cc: Jason Gunthorpe, davem@davemloft.net, Leon Romanovsky,
	dledford@redhat.com
In-Reply-To: <20180717013537.26411-1-saeedm@mellanox.com>

On Mon, 2018-07-16 at 18:35 -0700, Saeed Mahameed wrote:
> Hi,
> 
> This series includes mlx5 core infrastructure updates and fixes
> aimed for mlx5-next branch.
> 
> In case of no objections, below patches will be applied to mlx5-next
> branch
> and next mlx5 net-next pull request will start with a merge commit
> pointing to the last patch in this series.
> 

Series applied to mlx5-next.

Thanks everyone.

^ permalink raw reply

* Re: [PATCH 0/3] net: qca_spi: Minor bugfixes
From: David Miller @ 2018-07-18 22:19 UTC (permalink / raw)
  To: stefan.wahren; +Cc: netdev, linux-kernel
In-Reply-To: <1531895505-26971-1-git-send-email-stefan.wahren@i2se.com>

From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Wed, 18 Jul 2018 08:31:42 +0200

> This patch series contains some minor bugfixes for
> the qca_spi driver.

Series applied, thanks.

^ permalink raw reply

* KASAN: stack-out-of-bounds Read in bpf_tcp_close
From: syzbot @ 2018-07-18 22:19 UTC (permalink / raw)
  To: ast, daniel, linux-kernel, netdev, syzkaller-bugs

Hello,

syzbot found the following crash on:

HEAD commit:    8ae71e76cf1f Merge branch 'bpf-offload-sharing'
git tree:       bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1379a978400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
dashboard link: https://syzkaller.appspot.com/bug?extid=65a97319fd875ea52b73
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=114f4b2c400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1774932c400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+65a97319fd875ea52b73@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
IPVS: ftp: loaded support on port[0] = 21
==================================================================
swap_info_get: Bad swap file entry 8007fffc400d72b
BUG: KASAN: stack-out-of-bounds in __read_once_size  
include/linux/compiler.h:188 [inline]
BUG: KASAN: stack-out-of-bounds in smap_psock_sk kernel/bpf/sockmap.c:149  
[inline]
BUG: KASAN: stack-out-of-bounds in bpf_tcp_close+0xf10/0x1050  
kernel/bpf/sockmap.c:316
Read of size 8 at addr ffff8801adcc4428 by task syz-executor115/24313
BUG: Bad page map in process syz-executor115  pte:1ffff10035cac810  
pmd:1ae564067

CPU: 0 PID: 24313 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:

addr:(____ptrval____) vm_flags:00000875 anon_vma:          (null)  
mapping:(____ptrval____) index:0
Allocated by task 2294230744:
usercopy: Kernel memory overwrite attempt detected to SLAB  
object 'task_struct(17:syz0)' (offset 6088, size 2)!
file:syz-executor115250413 fault:ext4_filemap_fault mmap:ext4_file_mmap  
readpage:ext4_readpage
------------[ cut here ]------------
Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected  
to SLAB object 'task_struct(17:syz0)' (offset 4936, size 2)!
WARNING: CPU: 0 PID: 24313 at mm/usercopy.c:81 usercopy_warn+0xf5/0x120  
mm/usercopy.c:76
CPU: 1 PID: 4479 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
Kernel panic - not syncing: panic_on_warn set ...

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
  print_bad_pte.cold.116+0x1cd/0x22b mm/memory.c:774
  zap_pte_range mm/memory.c:1380 [inline]
  zap_pmd_range mm/memory.c:1437 [inline]
  zap_pud_range mm/memory.c:1466 [inline]
  zap_p4d_range mm/memory.c:1487 [inline]
  unmap_page_range+0x1cb9/0x2220 mm/memory.c:1508
  unmap_single_vma+0x1a0/0x310 mm/memory.c:1553
  unmap_vmas+0x120/0x1f0 mm/memory.c:1583
  exit_mmap+0x2c2/0x5b0 mm/mmap.c:3105
  __mmput kernel/fork.c:970 [inline]
  mmput+0x265/0x620 kernel/fork.c:991
  exit_mm kernel/exit.c:544 [inline]
  do_exit+0xea9/0x2750 kernel/exit.c:852
  do_group_exit+0x177/0x440 kernel/exit.c:968
  get_signal+0x88e/0x1970 kernel/signal.c:2468
  do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
  exit_to_usermode_loop+0x2e0/0x370 arch/x86/entry/common.c:162
  prepare_exit_to_usermode+0x342/0x3b0 arch/x86/entry/common.c:197
  retint_user+0x8/0x18
RIP: 0033:0x4731e0
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
RSP: 002b:00007ffd426a9928 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000002e7e RCX: 00000000004731e0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffd426a9930
RBP: 0000000000002e7e R08: 0000000000000001 R09: 0000000000e2a880
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000f7e
R13: 000000000003ab5f R14: 0000000000000000 R15: 0000000000000000
CPU: 0 PID: 24313 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
swap_info_get: Bad swap file entry 403fffe200725fc
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
Dumping ftrace buffer:
    (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply

* Re: [PATCH v3 net-next 6/8] lan743x: Add power management support
From: Andrew Lunn @ 2018-07-18 21:35 UTC (permalink / raw)
  To: Bryan Whitehead; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <1531947878-9758-7-git-send-email-Bryan.Whitehead@microchip.com>

> +#ifdef CONFIG_PM
> +static void lan743x_ethtool_get_wol(struct net_device *netdev,
> +				    struct ethtool_wolinfo *wol)
> +{
> +	struct lan743x_adapter *adapter = netdev_priv(netdev);
> +
> +	wol->supported = 0;
> +	wol->wolopts = 0;
> +	phy_ethtool_get_wol(netdev->phydev, wol);
> +
> +	wol->supported &= WAKE_BCAST | WAKE_UCAST | WAKE_MCAST |
> +		WAKE_MAGIC | WAKE_PHY | WAKE_ARP;

Hi Bryan

Say the PHY set WAKE_MAGICSECURE, because it supports that. This AND
then wipes it out, making the call to phy_ethtool_get_wol() pointless.
In fact, should this AND be an OR?

> +
> +#ifdef CONFIG_PM
> +static int lan743x_ethtool_set_wol(struct net_device *netdev,
> +				   struct ethtool_wolinfo *wol)
> +{
> +	struct lan743x_adapter *adapter = netdev_priv(netdev);
> +
> +	if (wol->wolopts & WAKE_MAGICSECURE)
> +		return -EOPNOTSUPP;

The PHY might support this. Since you call phy_ethtool_set_wol(), you
should give it the chance. 

       Andrew

^ permalink raw reply

* Re: [PATCH] ipv6: fix useless rol32 call on hash
From: David Miller @ 2018-07-18 22:11 UTC (permalink / raw)
  To: colin.king; +Cc: kuznet, yoshfuji, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180717161239.30782-1-colin.king@canonical.com>

From: Colin King <colin.king@canonical.com>
Date: Tue, 17 Jul 2018 17:12:39 +0100

> From: Colin Ian King <colin.king@canonical.com>
> 
> The rol32 call is currently rotating hash but the rol'd value is
> being discarded. I believe the current code is incorrect and hash
> should be assigned the rotated value returned from rol32.
> 
> Thanks to David Lebrun for spotting this.
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Also applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] ipv6: sr: fix useless rol32 call on hash
From: David Miller @ 2018-07-18 22:11 UTC (permalink / raw)
  To: colin.king; +Cc: kuznet, yoshfuji, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180717155254.30367-1-colin.king@canonical.com>

From: Colin King <colin.king@canonical.com>
Date: Tue, 17 Jul 2018 16:52:54 +0100

> From: Colin Ian King <colin.king@canonical.com>
> 
> The rol32 call is currently rotating hash but the rol'd value is
> being discarded. I believe the current code is incorrect and hash
> should be assigned the rotated value returned from rol32.
> 
> Detected by CoverityScan, CID#1468411 ("Useless call")
> 
> Fixes: b5facfdba14c ("ipv6: sr: Compute flowlabel for outer IPv6 header of seg6 encap mode")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Applied and queued up for -stable.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox