* [PATCH] net/mlx4_en: fix a memory leak bug
From: Wenwen Wang @ 2019-08-12 6:36 UTC (permalink / raw)
To: Wenwen Wang
Cc: Tariq Toukan, David S. Miller,
open list:MELLANOX ETHERNET DRIVER (mlx4_en),
open list:MELLANOX MLX4 core VPI driver, open list
In mlx4_en_config_rss_steer(), 'rss_map->indir_qp' is allocated through
kzalloc(). After that, mlx4_qp_alloc() is invoked to configure RSS
indirection. However, if mlx4_qp_alloc() fails, the allocated
'rss_map->indir_qp' is not deallocated, leading to a memory leak bug.
To fix the above issue, add the 'mlx4_err' label to free
'rss_map->indir_qp'.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314..9476dbd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1187,7 +1187,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
err = mlx4_qp_alloc(mdev->dev, priv->base_qpn, rss_map->indir_qp);
if (err) {
en_err(priv, "Failed to allocate RSS indirection QP\n");
- goto rss_err;
+ goto mlx4_err;
}
rss_map->indir_qp->event = mlx4_en_sqp_event;
@@ -1241,6 +1241,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
MLX4_QP_STATE_RST, NULL, 0, 0, rss_map->indir_qp);
mlx4_qp_remove(mdev->dev, rss_map->indir_qp);
mlx4_qp_free(mdev->dev, rss_map->indir_qp);
+mlx4_err:
kfree(rss_map->indir_qp);
rss_map->indir_qp = NULL;
rss_err:
--
2.7.4
^ permalink raw reply related
* [PATCH] e1000: fix memory leaks
From: Wenwen Wang @ 2019-08-12 5:59 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list
In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if
e1000_up() fails, leading to memory leaks. Refactor the code to fix this
issue.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index a410085..2e07ffa 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -607,6 +607,7 @@ static int e1000_set_ringparam(struct net_device *netdev,
for (i = 0; i < adapter->num_rx_queues; i++)
rxdr[i].count = rxdr->count;
+ err = 0;
if (netif_running(adapter->netdev)) {
/* Try to get new resources before deleting old */
err = e1000_setup_all_rx_resources(adapter);
@@ -627,14 +628,13 @@ static int e1000_set_ringparam(struct net_device *netdev,
adapter->rx_ring = rxdr;
adapter->tx_ring = txdr;
err = e1000_up(adapter);
- if (err)
- goto err_setup;
}
kfree(tx_old);
kfree(rx_old);
clear_bit(__E1000_RESETTING, &adapter->flags);
- return 0;
+ return err;
+
err_setup_tx:
e1000_free_all_rx_resources(adapter);
err_setup_rx:
@@ -646,7 +646,6 @@ static int e1000_set_ringparam(struct net_device *netdev,
err_alloc_tx:
if (netif_running(adapter->netdev))
e1000_up(adapter);
-err_setup:
clear_bit(__E1000_RESETTING, &adapter->flags);
return err;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] net: can: Fix compiling warning
From: maowenan @ 2019-08-12 5:48 UTC (permalink / raw)
To: Oliver Hartkopp, Dan Carpenter
Cc: davem, netdev, linux-kernel, kernel-janitors
In-Reply-To: <6e1c5aa0-8ed3-eec3-a34d-867ea8f54e9d@hartkopp.net>
On 2019/8/7 0:41, Oliver Hartkopp wrote:
> Hello Dan,
>
> On 06/08/2019 15.52, Dan Carpenter wrote:
>> On Fri, Aug 02, 2019 at 10:10:20AM +0200, Oliver Hartkopp wrote:
>
>>> Btw. what kind of compiler/make switches are you using so that I can see
>>> these warnings myself the next time?
>>
>> These are Sparse warnings, not from GCC.
>
> I compiled the code (the original version), but I do not get that "Should it be static?" warning:
Hello Oliver,
here are my steps for net/can/bcm.c,
make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
make C=2 net/can/bcm.o ARCH=mips CROSS_COMPILE=mips-linux-gnu-
CHECK scripts/mod/empty.c
CALL scripts/checksyscalls.sh
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
CALL scripts/atomic/check-atomics.sh
CHECK net/can/bcm.c
./include/linux/slab.h:672:13: error: undefined identifier '__builtin_mul_overflow'
./include/linux/slab.h:672:13: error: not a function <noident>
./include/linux/slab.h:672:13: error: not a function <noident>
net/can/bcm.c:1683:5: warning: symbol 'bcm_sock_no_ioctlcmd' was not declared. Should it be static?
./include/linux/slab.h:672:13: warning: call with no type!
CC [M] net/can/bcm.o
for net/can/raw.c,
make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
make C=2 net/can/raw.o ARCH=mips CROSS_COMPILE=mips-linux-gnu-
CHECK scripts/mod/empty.c
CALL scripts/checksyscalls.sh
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
CALL scripts/atomic/check-atomics.sh
CHECK net/can/raw.c
net/can/raw.c:840:5: warning: symbol 'raw_sock_no_ioctlcmd' was not declared. Should it be static?
CC [M] net/can/raw.o
^ permalink raw reply
* Re: [PATCH net] net: phy: rtl8211f: do a double read to get real time link status
From: Yonglong Liu @ 2019-08-12 4:49 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: davem, netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
In-Reply-To: <7f18113e-268b-6a4a-af83-236cfa337fcd@gmail.com>
On 2019/8/10 4:05, Heiner Kallweit wrote:
> On 09.08.2019 06:57, Yonglong Liu wrote:
>>
>>
>> On 2019/8/9 4:34, Andrew Lunn wrote:
>>> On Thu, Aug 08, 2019 at 10:01:39PM +0200, Heiner Kallweit wrote:
>>>> On 08.08.2019 21:40, Andrew Lunn wrote:
>>>>>> @@ -568,6 +568,11 @@ int phy_start_aneg(struct phy_device *phydev)
>>>>>> if (err < 0)
>>>>>> goto out_unlock;
>>>>>>
>>>>>> + /* The PHY may not yet have cleared aneg-completed and link-up bit
>>>>>> + * w/o this delay when the following read is done.
>>>>>> + */
>>>>>> + usleep_range(1000, 2000);
>>>>>> +
>>>>>
>>>>> Hi Heiner
>>>>>
>>>>> Does 802.3 C22 say anything about this?
>>>>>
>>>> C22 says:
>>>> "The Auto-Negotiation process shall be restarted by setting bit 0.9 to a logic one. This bit is self-
>>>> clearing, and a PHY shall return a value of one in bit 0.9 until the Auto-Negotiation process has been
>>>> initiated."
>>>>
>>>> Maybe we should read bit 0.9 in genphy_update_link() after having read BMSR and report
>>>> aneg-complete and link-up as false (no matter of their current value) if 0.9 is set.
>>>
>>> Yes. That sounds sensible.
>>>
>>> Andrew
>>>
>>> .
>>>
>>
>> Hi Heiner:
>> I have test more than 50 times, it works. Previously less
>> than 20 times must be recurrence. so I think this patch solved the
>> problem.
>> And I checked about 40 times of the time gap between read
>> and autoneg started, all of them is more than 2ms, as below:
>>
>> kworker/u257:1-670 [015] .... 27.182632: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1240
>> kworker/u257:1-670 [015] .... 27.184670: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
>>
>>
>
> Instead of using this fixed delay, the following experimental patch
> considers that fact that between triggering aneg start and actual
> start of aneg (incl. clearing aneg-complete bit) Clause 22 requires
> a PHY to keep bit 0.9 (aneg restart) set.
> Could you please test this instead of the fixed-delay patch?
>
> Thanks, Heiner
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index b039632de..163295dbc 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1741,7 +1741,17 @@ EXPORT_SYMBOL(genphy_aneg_done);
> */
> int genphy_update_link(struct phy_device *phydev)
> {
> - int status;
> + int status = 0, bmcr;
> +
> + bmcr = phy_read(phydev, MII_BMCR);
> + if (bmcr < 0)
> + return bmcr;
> +
> + /* Autoneg is being started, therefore disregard BMSR value and
> + * report link as down.
> + */
> + if (bmcr & BMCR_ANRESTART)
> + goto done;
>
> /* The link state is latched low so that momentary link
> * drops can be detected. Do not double-read the status
>
Hi Heiner:
Have test 50+ times, this patch can solved the problem too!
Share the mdio trace after executing ifconfig ethx up:
# tracer: nop
#
# entries-in-buffer/entries-written: 60/60 #P:128
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
ifconfig-1174 [005] .... 27.026691: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 27.026734: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x04 val:0x01e1
kworker/u257:1-670 [020] .... 27.026744: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x04 val:0x05e1
kworker/u257:1-670 [020] .... 27.026799: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:1-670 [020] .... 27.026834: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:1-670 [020] .... 27.026869: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 27.026879: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1240
kworker/u257:1-670 [020] .... 27.026932: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1240
kworker/u257:1-670 [020] .... 28.031770: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 28.031837: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:1-670 [020] .... 29.055837: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 29.055873: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:0-8 [004] .... 30.079840: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 30.079875: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:0-8 [004] .... 31.103771: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 31.103839: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79a9
kworker/u257:0-8 [004] .... 31.103906: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x0a val:0x7803
kworker/u257:0-8 [004] .... 31.103973: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:0-8 [004] .... 31.104041: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x05 val:0xc1e1
kworker/u257:0-8 [004] .... 32.127814: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 32.127881: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:0-8 [004] .... 32.127948: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x0a val:0x4800
kworker/u257:0-8 [004] .... 32.128015: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:0-8 [004] .... 32.128082: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x05 val:0xc1e1
kworker/u257:0-8 [004] .... 33.151775: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 33.151815: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:1-670 [021] .... 34.175771: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [021] .... 34.175838: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
ifconfig-1177 [005] .... 35.052340: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
ifconfig-1177 [005] .... 35.052350: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1840
^ permalink raw reply
* Re: [PATCH] net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
From: David Miller @ 2019-08-12 4:42 UTC (permalink / raw)
To: natechancellor; +Cc: netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190812031345.41157-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Sun, 11 Aug 2019 20:13:45 -0700
> clang warns:
>
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
> '&&' with constant operand [-Wconstant-logical-operand]
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ^ ~~~~~~~~~~~~
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
> bitwise operation
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ^~
> &
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
> silence this warning
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ~^~~~~~~~~~~~~~~
> 1 warning generated.
>
> Explicitly check that NET_IP_ALIGN is not zero, which matches how this
> is checked in other parts of the tree. Because NET_IP_ALIGN is a build
> time constant, this check will be constant folded away during
> optimization.
>
> Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
> Link: https://github.com/ClangBuiltLinux/linux/issues/608
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied but I think clang is being rediculous.
^ permalink raw reply
* Re: [PATCH v3] tipc: initialise addr_trail_end when setting node addresses
From: David Miller @ 2019-08-12 4:40 UTC (permalink / raw)
To: chris.packham; +Cc: jon.maloy, ying.xue, netdev, tipc-discussion, linux-kernel
In-Reply-To: <20190811201825.13876-1-chris.packham@alliedtelesis.co.nz>
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Mon, 12 Aug 2019 08:18:25 +1200
> We set the field 'addr_trial_end' to 'jiffies', instead of the current
> value 0, at the moment the node address is initialized. This guarantees
> we don't inadvertently enter an address trial period when the node
> address is explicitly set by the user.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v3] net: dsa: Check existence of .port_mdb_add callback before calling it
From: David Miller @ 2019-08-12 4:37 UTC (permalink / raw)
To: wens; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190811141825.11566-1-wens@kernel.org>
From: Chen-Yu Tsai <wens@kernel.org>
Date: Sun, 11 Aug 2019 22:18:25 +0800
> From: Chen-Yu Tsai <wens@csie.org>
>
> The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
> for drivers to handle multicast database entries. When adding an entry, the
> framework goes through a prepare phase, then a commit phase. Drivers not
> providing these callbacks should be detected in the prepare phase.
>
> DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
> function directly with no prepare phase or no switchdev trans object,
> and the framework ends up calling an undefined .port_mdb_add callback.
> This results in a NULL pointer dereference, as shown in the log below.
>
> The other functions seem to be properly guarded. Do the same for
> .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
...
> Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum_ptp: Keep unmatched entries in a linked list
From: David Miller @ 2019-08-12 4:36 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, richardcochran, mlxsw, idosch
In-Reply-To: <20190811074837.28216-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 11 Aug 2019 10:48:37 +0300
> From: Petr Machata <petrm@mellanox.com>
>
> To identify timestamps for matching with their packets, Spectrum-1 uses a
> five-tuple of (port, direction, domain number, message type, sequence ID).
> If there are several clients from the same domain behind a single port
> sending Delay_Req's, the only thing differentiating these packets, as far
> as Spectrum-1 is concerned, is the sequence ID. Should sequence IDs between
> individual clients be similar, conflicts may arise. That is not a problem
> to hardware, which will simply deliver timestamps on a first comes, first
> served basis.
>
> However the driver uses a simple hash table to store the unmatched pieces.
> When a new conflicting piece arrives, it pushes out the previously stored
> one, which if it is a packet, is delivered without timestamp. Later on as
> the corresponding timestamps arrive, the first one is mismatched to the
> second packet, and the second one is never matched and eventually is GCd.
>
> To correct this issue, instead of using a simple rhashtable, use rhltable
> to keep the unmatched entries.
>
> Previously, a found unmatched entry would always be removed from the hash
> table. That is not the case anymore--an incompatible entry is left in the
> hash table. Therefore removal from the hash table cannot be used to confirm
> the validity of the looked-up pointer, instead the lookup would simply need
> to be redone. Therefore move it inside the critical section. This
> simplifies a lot of the code.
>
> Fixes: 8748642751ed ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
> Reported-by: Alex Veber <alexve@mellanox.com>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: nps_enet: Fix function names in doc comments
From: David Miller @ 2019-08-12 4:32 UTC (permalink / raw)
To: j.neuschaefer; +Cc: netdev, gregkh, alexios.zavras, tglx, allison, linux-kernel
In-Reply-To: <20190810111159.3389-1-j.neuschaefer@gmx.net>
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Date: Sat, 10 Aug 2019 13:11:56 +0200
> Adjust the function names in two doc comments to match the corresponding
> functions.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Applied.
^ permalink raw reply
* Re: [PATCH] caif: no need to check return value of debugfs_create functions
From: David Miller @ 2019-08-12 4:31 UTC (permalink / raw)
To: gregkh; +Cc: netdev, rfontana, swinslow
In-Reply-To: <20190810104243.GA24741@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat, 10 Aug 2019 12:42:43 +0200
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Steve Winslow <swinslow@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH] xen-netback: no need to check return value of debugfs_create functions
From: David Miller @ 2019-08-12 4:30 UTC (permalink / raw)
To: gregkh; +Cc: wei.liu, paul.durrant, xen-devel, netdev
In-Reply-To: <20190810103108.GA29487@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat, 10 Aug 2019 12:31:08 +0200
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix local refcounting
From: David Miller @ 2019-08-12 4:29 UTC (permalink / raw)
To: dhowells; +Cc: netdev, jaltman, linux-afs, linux-kernel
In-Reply-To: <156538726702.16201.13552536596121161945.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Fri, 09 Aug 2019 22:47:47 +0100
> Fix rxrpc_unuse_local() to handle a NULL local pointer as it can be called
> on an unbound socket on which rx->local is not yet set.
>
> The following reproduced (includes omitted):
>
> int main(void)
> {
> socket(AF_RXRPC, SOCK_DGRAM, AF_INET);
> return 0;
> }
>
> causes the following oops to occur:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000010
> ...
> RIP: 0010:rxrpc_unuse_local+0x8/0x1b
> ...
> Call Trace:
> rxrpc_release+0x2b5/0x338
> __sock_release+0x37/0xa1
> sock_close+0x14/0x17
> __fput+0x115/0x1e9
> task_work_run+0x72/0x98
> do_exit+0x51b/0xa7a
> ? __context_tracking_exit+0x4e/0x10e
> do_group_exit+0xab/0xab
> __x64_sys_exit_group+0x14/0x17
> do_syscall_64+0x89/0x1d4
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Reported-by: syzbot+20dee719a2e090427b5f@syzkaller.appspotmail.com
> Fixes: 730c5fd42c1e ("rxrpc: Fix local endpoint refcounting")
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/7] net: dsa: mv88e6xxx: prepare Wait Bit operation
From: David Miller @ 2019-08-12 4:27 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, f.fainelli, andrew
In-Reply-To: <20190809224759.5743-1-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Fri, 9 Aug 2019 18:47:52 -0400
> The Remote Management Interface has its own implementation of a Wait
> Bit operation, which requires a bit number and a value to wait for.
>
> In order to prepare the introduction of this implementation, rework the
> code waiting for bits and masks in mv88e6xxx to match this signature.
>
> This has the benefit to unify the implementation of wait routines while
> removing obsolete wait and update functions and also reducing the code.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] r8169: inline rtl8169_free_rx_databuff
From: David Miller @ 2019-08-12 4:26 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <e0902cae-4557-dcda-9c96-ad19b3c05993@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 9 Aug 2019 22:59:07 +0200
> rtl8169_free_rx_databuff is used in only one place, so let's inline it.
> We can improve the loop because rtl8169_init_ring zero's RX_databuff
> before calling rtl8169_rx_fill, and rtl8169_rx_fill fills
> Rx_databuff starting from index 0.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: phy: realtek: add support for integrated 2.5Gbps PHY in RTL8125
From: David Miller @ 2019-08-12 4:24 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <755b2bc9-22cb-f529-4188-0f4b6e48efbd@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 9 Aug 2019 20:41:58 +0200
> This series adds support for the integrated 2.5Gbps PHY in RTL8125.
> First three patches add necessary functionality to phylib.
>
> Changes in v2:
> - added patch 1
> - changed patch 4 to use a fake PHY ID that is injected by the
> network driver. This allows to use a dedicated PHY driver.
Series applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH][net-next] rxrpc: fix uninitialized return value in variable err
From: David Miller @ 2019-08-12 4:22 UTC (permalink / raw)
To: colin.king; +Cc: dhowells, linux-afs, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190809170259.29859-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 9 Aug 2019 18:02:59 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> An earlier commit removed the setting of err to -ENOMEM so currently
> the skb_shinfo(skb)->nr_frags > 16 check returns with an uninitialized
> bogus return code. Fix this by setting err to -ENOMEM to restore
> the original behaviour.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: b214b2d8f277 ("rxrpc: Don't use skb_cow_data() in rxkad")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
David, I assume you will pick this up.
^ permalink raw reply
* Re: [patch net-next] netdevsim: register couple of devlink params
From: David Miller @ 2019-08-12 4:20 UTC (permalink / raw)
To: jiri; +Cc: netdev, jakub.kicinski, mlxsw
In-Reply-To: <20190809110512.31779-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 9 Aug 2019 13:05:12 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Register couple of devlink params, one generic, one driver-specific.
> Make the values available over debugfs.
>
> Example:
> $ echo "111" > /sys/bus/netdevsim/new_device
> $ devlink dev param
> netdevsim/netdevsim111:
> name max_macs type generic
> values:
> cmode driverinit value 32
> name test1 type driver-specific
> values:
> cmode driverinit value true
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/max_macs
> 32
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/test1
> Y
> $ devlink dev param set netdevsim/netdevsim111 name max_macs cmode driverinit value 16
> $ devlink dev param set netdevsim/netdevsim111 name test1 cmode driverinit value false
> $ devlink dev reload netdevsim/netdevsim111
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/max_macs
> 16
> $ cat /sys/kernel/debug/netdevsim/netdevsim111/test1
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the config attributes.
From: Sudarsana Reddy Kalluru @ 2019-08-12 4:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <DM5PR18MB2215C258FCC2276F0319D81EC4DA0@DM5PR18MB2215.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Ariel Elior <aelior@marvell.com>
> Sent: Monday, August 5, 2019 8:00 PM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>; David Miller
> <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>
> Subject: RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the
> config attributes.
>
> > From: Sudarsana Reddy Kalluru
> > Sent: Tuesday, July 30, 2019 6:36 AM
> > To: David Miller <davem@davemloft.net>
> >
> > > -----Original Message-----
> > > From: David Miller <davem@davemloft.net>
> > > Sent: Monday, July 29, 2019 11:34 PM
> > > To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > > Cc: netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>;
> > > Ariel Elior <aelior@marvell.com>
> > > Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for
> > > flashing the config attributes.
> > >
> > > From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > > Date: Sat, 27 Jul 2019 18:55:49 -0700
> > >
> > > > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev
> > > > *cdev,
> > > const char *name)
> > > > rc = qed_nvm_flash_image_access(cdev, &data,
> > > > &check_resp);
> > > > break;
> > > > + case QED_NVM_FLASH_CMD_NVM_CFG_ID:
> > > > + rc = qed_nvm_flash_cfg_write(cdev, &data);
> > > > + break;
> >
> > > > default:
> > > > DP_ERR(cdev, "Unknown command %08x\n",
> > > cmd_type);
> > >
> > > I don't see how any existing portable interface can cause this new
> > > code to actually be used.
> > >
> > > You have to explain this to me.
> > The API qed_nvm_flash() is used to flash the user provided data (e.g.,
> > Management FW) to the required partitions of the adapter.
> > - Format of the input file would be - file signature info, followed
> > by one or more data sets.
> > - Each data set is represented with the header followed by its contents.
> > Header captures info such as command name (e.g., FILE_START), data
> > size etc., which specifies how to handle the data.
> > The API qed_nvm_flash() validates the user provided input file, parses
> > the data sets and handles each accordingly. Here one of the data sets
> > (preferably the last one) could be nvm-attributes page (with cmd-id =
> > QED_NVM_FLASH_CMD_NVM_CHANGE).
>
> This is basically an expansion of our existing ethtool -f implementation.
> The management FW has exposed an additional method of configuring some
> of the nvram options, and this makes use of that. The new code will come
> into use when newer FW files which contain configuration directives
> employing this API will be provided to ethtool -f.
>
> thanks,
> Ariel
Dave,
The series appears as "changes requested" in patchwork. Please let us know if any modifications need to be incorporated on this series?
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: David Miller @ 2019-08-12 4:13 UTC (permalink / raw)
To: jasowang; +Cc: mst, kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <360a3b91-1ac5-84c0-d34b-a4243fa748c4@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 12 Aug 2019 10:44:51 +0800
> On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
>> At this point how about we revert
>> 7f466032dc9e5a61217f22ea34b2df932786bbfc
>> for this release, and then re-apply a corrected version
>> for the next one?
>
> If possible, consider we've actually disabled the feature. How about
> just queued those patches for next release?
I'm tossing this series while you and Michael decide how to move forward.
^ permalink raw reply
* Re: [PATCHv2 net 0/2] Add netdev_level_ratelimited to avoid netdev msg flush
From: David Miller @ 2019-08-12 4:08 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, joe, tlfalcon
In-Reply-To: <20190809002941.15341-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 9 Aug 2019 08:29:39 +0800
> ibmveth 30000003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter table
You need to root cause and fix the reason this message appears so much.
Once I let you rate limit the message you will have zero incentive to
fix the real problem and fix it.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Restore per-network namespace accounting for fib entries
From: David Miller @ 2019-08-12 4:02 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, dsahern
In-Reply-To: <20190806191517.8713-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Tue, 6 Aug 2019 12:15:17 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Prior to the commit in the fixes tag, the resource controller in netdevsim
> tracked fib entries and rules per network namespace. Restore that behavior.
>
> Fixes: 5fc494225c1e ("netdevsim: create devlink instance per netdevsim instance")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks for bringing this to our attention and fixing it David.
Jiri, I disagree you on every single possible level.
If you didn't like how netdevsim worked in this area the opportunity to do
something about it was way back when it went in.
No matter how completely busted or disagreeable an interface is, once we have
committed it to a release (and in particular people are knowingly using and
depending upon it) you cannot break it.
It doesn't matter how much you disagree with something, you cannot break it
when it's out there and actively in use.
Do you have any idea how much stuff I'd like to break because I think the
design turned out to be completely wrong? But I can't.
^ permalink raw reply
* Re: [PATCH] nfc: st-nci: Fix an incorrect skb_buff size in 'st_nci_i2c_read()'
From: David Miller @ 2019-08-12 3:57 UTC (permalink / raw)
To: christophe.jaillet
Cc: tglx, gregkh, colin.king, allison, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20190806141640.13197-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Tue, 6 Aug 2019 16:16:40 +0200
> In 'st_nci_i2c_read()', we allocate a sk_buff with a size of
> ST_NCI_I2C_MIN_SIZE + len.
>
> However, later on, we first 'skb_reserve()' ST_NCI_I2C_MIN_SIZE bytes, then
> we 'skb_put()' ST_NCI_I2C_MIN_SIZE bytes.
> Finally, if 'len' is not 0, we 'skb_put()' 'len' bytes.
>
> So we use ST_NCI_I2C_MIN_SIZE*2 + len bytes.
>
> This is incorrect and should already panic. I guess that it does not occur
> because of extra memory allocated because of some rounding.
>
> Fix it and allocate enough room for the 'skb_reserve()' and the 'skb_put()'
> calls.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This patch is LIKELY INCORRECT. So think twice to what is the correct
> solution before applying it.
> Maybe the skb_reserve should be axed or some other sizes are incorrect.
> There seems to be an issue, that's all I can say.
The skb_reserve() should be removed, and the second memcpy() should remove
the " + ST_NCI_I2C_MIN_SIZE".
This SKB just get sent down to ndlc_recv() so the content returned from I2C
should places at skb->data to be processed.
Pretty clear this code was never tested.
^ permalink raw reply
* Re: [PATCH net] ipv4/route: do not check saddr dev if iif is LOOPBACK_IFINDEX
From: David Miller @ 2019-08-12 3:49 UTC (permalink / raw)
To: dsahern; +Cc: liuhangbin, netdev, sbrivio, mleitner
In-Reply-To: <209d2ebf-aeb1-de08-2343-f478d51b92fa@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 1 Aug 2019 22:16:00 -0600
> On 8/1/19 10:13 PM, Hangbin Liu wrote:
>> On Thu, Aug 01, 2019 at 01:51:25PM -0600, David Ahern wrote:
>>> On 8/1/19 2:29 AM, Hangbin Liu wrote:
>>>> Jianlin reported a bug that for IPv4, ip route get from src_addr would fail
>>>> if src_addr is not an address on local system.
>>>>
>>>> \# ip route get 1.1.1.1 from 2.2.2.2
>>>> RTNETLINK answers: Invalid argument
>>>
>>> so this is a forwarding lookup in which case iif should be set. Based on
>>
>> with out setting iif in userspace, the kernel set iif to lo by default.
>
> right, it presumes locally generated traffic.
>>
>>> the above 'route get' inet_rtm_getroute is doing a lookup as if it is
>>> locally generated traffic.
>>
>> yeah... but what about the IPv6 part. That cause a different behavior in
>> userspace.
>
> just one of many, many annoying differences between v4 and v6. We could
> try to catalog it.
I think we just have to accept this difference because this change would
change behavior for all route lookups, not just those done by ip route get.
^ permalink raw reply
* [PATCH] net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
From: Nathan Chancellor @ 2019-08-12 3:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, clang-built-linux, Nathan Chancellor
clang warns:
drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
^ ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
bitwise operation
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
^~
&
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
~^~~~~~~~~~~~~~~
1 warning generated.
Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.
Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: https://github.com/ClangBuiltLinux/linux/issues/608
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 8479a440527b..12466a72cefc 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -1504,7 +1504,7 @@ tc35815_rx(struct net_device *dev, int limit)
pci_unmap_single(lp->pci_dev,
lp->rx_skbs[cur_bd].skb_dma,
RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
- if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
+ if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN != 0)
memmove(skb->data, skb->data - NET_IP_ALIGN,
pkt_len);
data = skb_put(skb, pkt_len);
--
2.23.0.rc2
^ permalink raw reply related
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: Jason Wang @ 2019-08-12 2:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <20190810134948-mutt-send-email-mst@kernel.org>
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
>> Hi all:
>>
>> This series try to fix several issues introduced by meta data
>> accelreation series. Please review.
>>
>> Changes from V4:
>> - switch to use spinlock synchronize MMU notifier with accessors
>>
>> Changes from V3:
>> - remove the unnecessary patch
>>
>> Changes from V2:
>> - use seqlck helper to synchronize MMU notifier with vhost worker
>>
>> Changes from V1:
>> - try not use RCU to syncrhonize MMU notifier with vhost worker
>> - set dirty pages after no readers
>> - return -EAGAIN only when we find the range is overlapped with
>> metadata
>>
>> Jason Wang (9):
>> vhost: don't set uaddr for invalid address
>> vhost: validate MMU notifier registration
>> vhost: fix vhost map leak
>> vhost: reset invalidate_count in vhost_set_vring_num_addr()
>> vhost: mark dirty pages during map uninit
>> vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
>> vhost: do not use RCU to synchronize MMU notifier with worker
>> vhost: correctly set dirty pages in MMU notifiers callback
>> vhost: do not return -EAGAIN for non blocking invalidation too early
>>
>> drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
>> drivers/vhost/vhost.h | 6 +-
>> 2 files changed, 122 insertions(+), 86 deletions(-)
> This generally looks more solid.
>
> But this amounts to a significant overhaul of the code.
>
> At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
> for this release, and then re-apply a corrected version
> for the next one?
If possible, consider we've actually disabled the feature. How about
just queued those patches for next release?
Thanks
>
>> --
>> 2.18.1
^ permalink raw reply
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