* Re: [PATCH net] af_key: free SKBs under RCU protection
From: stranche @ 2018-09-20 19:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, steffen.klassert
In-Reply-To: <6d194ac2-15e8-76d7-31d0-b4c4eed68d5a@gmail.com>
>
> I do not believe the changelog or the patch makes sense.
>
> Having skb still referencing a socket prevents this socket being
> released.
>
> If you think about it, what would prevent the freeing happening
> _before_ the rcu_read_lock() in pfkey_broadcast() ?
>
> Maybe the correct fix is that pfkey_broadcast_one() should ensure the
> socket is still valid.
>
> I would suggest something like :
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index
> 9d61266526e767770d9a1ce184ac8cdd59de309a..5ce309d020dda5e46e4426c4a639bfb551e2260d
> 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -201,7 +201,9 @@ static int pfkey_broadcast_one(struct sk_buff
> *skb, struct sk_buff **skb2,
> {
> int err = -ENOBUFS;
>
> - sock_hold(sk);
> + if (!refcount_inc_not_zero(&sk->sk_refcnt))
> + return -ENOENT;
> +
> if (*skb2 == NULL) {
> if (refcount_read(&skb->users) != 1) {
> *skb2 = skb_clone(skb, allocation);
Hi Eric,
I'm not sure that the socket getting freed before the rcu_read_lock()
would
be an issue, since then it would no longer be in the net_pkey->table
that
we loop through (since we call pfkey_remove() from pfkey_relase()).
Because of
that, all the sockets processed in pfkey_broadcast_one() have valid
refcounts,
so checking for zero there doesn't prevent the crash that I'm seeing.
However, after going over the call flow again, I see that the actual
problem
occurs because of pfkey_broadcast_one(). Specifically, because of this
check:
if (*skb2 == NULL) {
if (refcount_read(&skb->users) != 1) {
*skb2 = skb_clone(skb, allocation);
} else {
*skb2 = skb;
refcount_inc(&skb->users);
}
}
Since we always pass a freshly cloned SKB to this function, skb->users
is
always 1, and skb2 just becomes skb. We then set skb2 (and thus skb) to
belong to the socket.
If the socket we queue skb2 to frees this SKB (thereby decrementing its
refcount to 1) and the socket is freed before pfkey_broadcast() can
execute the kfree_skb(skb) on line 284, we will then attempt to run
sock_rfree() on an SKB with a dangling reference to this socket.
Perhaps a cleaner solution here is to always clone the SKB in
pfkey_broadcast_one(). That will ensure that the two kfree_skb() calls
in pfkey_broadcast() will never be passed an SKB with sock_rfree() as
its destructor, and we can avoid this race condition.
^ permalink raw reply
* IT Decision Makers Across the Globe
From: beverly.bruce @ 2018-09-20 19:36 UTC (permalink / raw)
To: netdev
Hello,
Hope all is well!
We are a database organization. We provide business executives' contact
information.
Below, I've included a few examples:
Industry-Specific Lists: Agriculture, Business Services, Chambers of
Commerce, Cities, Towns & Municipalities, Construction, Consumer Services,
Cultural, Education, Energy, Utilities & Waste Treatment, Finance,
Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services,
Manufacturing, Media & Internet, Metals & Mining, Organizations, Real
Estate, Retail, Software, Telecommunications, Transportation, and more!
Technology-Specific Lists: SAP users, PeopleSoft users, SIEBEL customers,
Oracle Application customers, Microsoft Dynamic users, Sales force users,
Microsoft Exchange users, QuickBooks, Lawson users, Act users, JD Edward
users, ASP users, Microsoft GP Applications users, Net Suite users, IBM
DBMS Application users, McAfee users, MS Dynamics GP (Great Plains), and
many more.
Title-Specific Lists: C-level executives: CEO, CFO, CIO, CTO, CMO, CISO,
CSO, COO Key decision-makers: All C-level, VP-level, and Director-level
executives HR Executives: VP of HR, HR Director & HR Manager, etc.
Marketing Executives: CMO, VP of Marketing, Director of Marketing,
Marketing Managers IT Executives: CIO, CTO, CISO, IT-VP, IT-Director, IT
Manager, MIS Manager, etc.
Please keep me informed for any additional details. I look forward to
hearing from you.
Regards,
Beverly
Marketing Executive
If you don't want to include yourself in our mailing list, please reply
back “Leave Out"n a subject line
^ permalink raw reply
* Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 1:33 UTC (permalink / raw)
To: David Miller
Cc: dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten, madalin.bucur,
pantelis.antoniou, claudiu.manoil, leoyang.li, linux, sammy, ralf,
nico, steve.glendinning, f.fainelli, grygorii.strashko, w-kwok2,
m-karicheri2, t.sailer, jreuter, kys, haiyangz, wei.liu2,
paul.durrant, arvid.brodin, pshelar, linux-kernel, netdev,
linux-can, linux-arm-kernel, <linuxppc-
In-Reply-To: <20180920.085055.1188796939437872993.davem@davemloft.net>
On 2018/9/20 23:50, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Thu, 20 Sep 2018 20:32:44 +0800
>
>> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
>> which is a typedef for an enum type, so make sure the implementation in
>> this driver has returns 'netdev_tx_t' value, and change the function
>> return type to netdev_tx_t.
>
> I would advise you not to send so many of these changes as a group.
>
> If one of the patches needs feedback addressed, which is already the
> case, you will have to resubmit the entire series all over again with
> the fixes.
>
Yes, I will send it separately after test and review again.
Thank you for your advice.
> .
>
^ permalink raw reply
* Re: [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 1:35 UTC (permalink / raw)
To: Haiyang Zhang, Stephen Hemminger
Cc: dmitry.tarnyagin@lockless.no, madalin.bucur@nxp.com,
linux-mips@linux-mips.org, linux@armlinux.org.uk,
pantelis.antoniou@gmail.com, t.sailer@alumni.ethz.ch,
dev@openvswitch.org, f.fainelli@gmail.com, arvid.brodin@alten.se,
michal.simek@xilinx.com, pshelar@ovn.org, m-karicheri2@ti.com,
xen-devel@lists.xenproject.org, jreuter@yaina.de, sammy@sammy.net,
grygorii.strashko@ti.com, w-kwok2@ti.com,
"steve.glendinning@shawell.net" <steve.
In-Reply-To: <BN6PR21MB016180C794F26A279345A17FCA130@BN6PR21MB0161.namprd21.prod.outlook.com>
On 2018/9/20 22:50, Haiyang Zhang wrote:
>
>
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Thursday, September 20, 2018 10:44 AM
>> To: YueHaibing <yuehaibing@huawei.com>
>> Cc: davem@davemloft.net; dmitry.tarnyagin@lockless.no;
>> wg@grandegger.com; mkl@pengutronix.de; michal.simek@xilinx.com;
>> hsweeten@visionengravers.com; madalin.bucur@nxp.com;
>> pantelis.antoniou@gmail.com; claudiu.manoil@nxp.com; leoyang.li@nxp.com;
>> linux@armlinux.org.uk; sammy@sammy.net; ralf@linux-mips.org;
>> nico@fluxnic.net; steve.glendinning@shawell.net; f.fainelli@gmail.com;
>> grygorii.strashko@ti.com; w-kwok2@ti.com; m-karicheri2@ti.com;
>> t.sailer@alumni.ethz.ch; jreuter@yaina.de; KY Srinivasan <kys@microsoft.com>;
>> Haiyang Zhang <haiyangz@microsoft.com>; wei.liu2@citrix.com;
>> paul.durrant@citrix.com; arvid.brodin@alten.se; pshelar@ovn.org;
>> dev@openvswitch.org; linux-mips@linux-mips.org; xen-
>> devel@lists.xenproject.org; netdev@vger.kernel.org; linux-usb@vger.kernel.org;
>> linux-kernel@vger.kernel.org; linux-can@vger.kernel.org;
>> devel@linuxdriverproject.org; linux-hams@vger.kernel.org; linux-
>> omap@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
>> kernel@lists.infradead.org
>> Subject: Re: [PATCH net-next 17/22] hv_netvsc: fix return type of
>> ndo_start_xmit function
>>
>> On Thu, 20 Sep 2018 20:33:01 +0800
>> YueHaibing <yuehaibing@huawei.com> wrote:
>>> int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
>>> */
>>> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
>>> if (vf_netdev && netif_running(vf_netdev) &&
>>> - !netpoll_tx_running(net))
>>> - return netvsc_vf_xmit(net, vf_netdev, skb);
>>> + !netpoll_tx_running(net)) {
>>> + ret = netvsc_vf_xmit(net, vf_netdev, skb);
>>> + if (ret)
>>> + return NETDEV_TX_BUSY;
>>> + }
>>
>> Sorry, the new code is wrong. It will fall through if ret == 0 (NETDEV_TX_OK)
>> Please review and test your patches.
>
> Plus consideration of -- For error case, please just return NETDEV_TX_OK. We
> are not sure if the error can go away after retrying, returning NETDEV_TX_BUSY
> may cause infinite retry from the upper layer.
>
> So, let's just always return NETDEV_TX_OK like this:
> netvsc_vf_xmit(net, vf_netdev, skb);
> return NETDEV_TX_OK;
Thank you for review.
Will do that in v2.
>
> Thanks,
> - Haiyang
>
> .
>
^ permalink raw reply
* Re: [PATCH mlx5-next v1 7/7] net/mlx5: Update mlx5_ifc with DEVX UID bits
From: Or Gerlitz @ 2018-09-20 20:08 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180920183526.13995-8-leon@kernel.org>
On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> RQ, XRCD, PD, MKEY and MCG.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> include/linux/mlx5/mlx5_ifc.h | 67 +++++++++++++++++++++++++++----------------
> 1 file changed, 43 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> index efa4a60431d4..0f460fb22c31 100644
> --- a/include/linux/mlx5/mlx5_ifc.h
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@ -1291,7 +1291,9 @@ struct mlx5_ifc_wq_bits {
> u8 reserved_at_118[0x3];
> u8 log_wq_sz[0x5];
>
> - u8 reserved_at_120[0x3];
> + u8 dbr_umem_valid[0x1];
> + u8 wq_umem_valid[0x1];
> + u8 reserved_at_122[0x1];
> u8 log_hairpin_num_packets[0x5];
> u8 reserved_at_128[0x3];
> u8 log_hairpin_data_sz[0x5];
> @@ -2365,7 +2367,10 @@ struct mlx5_ifc_qpc_bits {
>
> u8 dc_access_key[0x40];
>
> - u8 reserved_at_680[0xc0];
> + u8 reserved_at_680[0x3];
> + u8 dbr_umem_valid[0x1];
> +
> + u8 reserved_at_684[0xbc];
> };
>
> struct mlx5_ifc_roce_addr_layout_bits {
> @@ -2465,7 +2470,7 @@ struct mlx5_ifc_xrc_srqc_bits {
>
> u8 wq_signature[0x1];
> u8 cont_srq[0x1];
> - u8 reserved_at_22[0x1];
> + u8 dbr_umem_valid[0x1];
> u8 rlky[0x1];
> u8 basic_cyclic_rcv_wqe[0x1];
> u8 log_rq_stride[0x3];
> @@ -3129,7 +3134,9 @@ enum {
>
> struct mlx5_ifc_cqc_bits {
> u8 status[0x4];
> - u8 reserved_at_4[0x4];
> + u8 reserved_at_4[0x2];
> + u8 dbr_umem_valid[0x1];
> + u8 reserved_at_7[0x1];
> u8 cqe_sz[0x3];
> u8 cc[0x1];
> u8 reserved_at_c[0x1];
> @@ -5315,7 +5322,7 @@ struct mlx5_ifc_modify_tis_bitmask_bits {
>
> struct mlx5_ifc_modify_tis_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -5354,7 +5361,7 @@ struct mlx5_ifc_modify_tir_out_bits {
>
> struct mlx5_ifc_modify_tir_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -5455,7 +5462,7 @@ struct mlx5_ifc_rqt_bitmask_bits {
>
> struct mlx5_ifc_modify_rqt_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -5642,7 +5649,10 @@ struct mlx5_ifc_modify_cq_in_bits {
>
> struct mlx5_ifc_cqc_bits cq_context;
>
> - u8 reserved_at_280[0x600];
> + u8 reserved_at_280[0x40];
> +
> + u8 cq_umem_valid[0x1];
> + u8 reserved_at_2c1[0x5bf];
>
> u8 pas[0][0x40];
> };
> @@ -5963,7 +5973,7 @@ struct mlx5_ifc_detach_from_mcg_out_bits {
>
> struct mlx5_ifc_detach_from_mcg_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6031,7 +6041,7 @@ struct mlx5_ifc_destroy_tis_out_bits {
>
> struct mlx5_ifc_destroy_tis_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6053,7 +6063,7 @@ struct mlx5_ifc_destroy_tir_out_bits {
>
> struct mlx5_ifc_destroy_tir_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6143,7 +6153,7 @@ struct mlx5_ifc_destroy_rqt_out_bits {
>
> struct mlx5_ifc_destroy_rqt_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6508,7 +6518,7 @@ struct mlx5_ifc_dealloc_xrcd_out_bits {
>
> struct mlx5_ifc_dealloc_xrcd_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6596,7 +6606,7 @@ struct mlx5_ifc_dealloc_pd_out_bits {
>
> struct mlx5_ifc_dealloc_pd_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6675,7 +6685,9 @@ struct mlx5_ifc_create_xrc_srq_in_bits {
>
> struct mlx5_ifc_xrc_srqc_bits xrc_srq_context_entry;
>
> - u8 reserved_at_280[0x600];
> + u8 reserved_at_280[0x40];
> + u8 xrc_srq_umem_valid[0x1];
> + u8 reserved_at_2c1[0x5bf];
>
> u8 pas[0][0x40];
> };
> @@ -6694,7 +6706,7 @@ struct mlx5_ifc_create_tis_out_bits {
>
> struct mlx5_ifc_create_tis_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6718,7 +6730,7 @@ struct mlx5_ifc_create_tir_out_bits {
>
> struct mlx5_ifc_create_tir_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6824,7 +6836,7 @@ struct mlx5_ifc_create_rqt_out_bits {
>
> struct mlx5_ifc_create_rqt_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -6909,7 +6921,10 @@ struct mlx5_ifc_create_qp_in_bits {
>
> struct mlx5_ifc_qpc_bits qpc;
>
> - u8 reserved_at_800[0x80];
> + u8 reserved_at_800[0x60];
> +
> + u8 wq_umem_valid[0x1];
> + u8 reserved_at_861[0x1f];
>
> u8 pas[0][0x40];
> };
> @@ -6971,7 +6986,8 @@ struct mlx5_ifc_create_mkey_in_bits {
> u8 reserved_at_40[0x20];
>
> u8 pg_access[0x1];
> - u8 reserved_at_61[0x1f];
> + u8 mkey_umem_valid[0x1];
> + u8 reserved_at_62[0x1e];
>
> struct mlx5_ifc_mkc_bits memory_key_mkey_entry;
>
> @@ -7174,7 +7190,10 @@ struct mlx5_ifc_create_cq_in_bits {
>
> struct mlx5_ifc_cqc_bits cq_context;
>
> - u8 reserved_at_280[0x600];
> + u8 reserved_at_280[0x60];
> +
> + u8 cq_umem_valid[0x1];
> + u8 reserved_at_2e1[0x59f];
>
> u8 pas[0][0x40];
> };
> @@ -7222,7 +7241,7 @@ struct mlx5_ifc_attach_to_mcg_out_bits {
>
> struct mlx5_ifc_attach_to_mcg_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -7349,7 +7368,7 @@ struct mlx5_ifc_alloc_xrcd_out_bits {
>
> struct mlx5_ifc_alloc_xrcd_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> @@ -7437,7 +7456,7 @@ struct mlx5_ifc_alloc_pd_out_bits {
>
> struct mlx5_ifc_alloc_pd_in_bits {
> u8 opcode[0x10];
> - u8 reserved_at_10[0x10];
> + u8 uid[0x10];
>
> u8 reserved_at_20[0x10];
> u8 op_mod[0x10];
> --
> 2.14.4
>
^ permalink raw reply
* Re: [PATCH mlx5-next v1 7/7] net/mlx5: Update mlx5_ifc with DEVX UID bits
From: Or Gerlitz @ 2018-09-20 20:11 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180920183526.13995-8-leon@kernel.org>
On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky wrote:
> Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> RQ, XRCD, PD, MKEY and MCG.
typo - TRI --> TIR
"DEVX information" is a bit cryptic - what does xxx_valid means
for the devx use case (fw command is issued by devx process) - and
what semantics does it have for non-devx callers -- e.g the Eth driver when
they deal with tir/tis/etc
Explain and elaborate further at the change log
Or.
^ permalink raw reply
* Re: [PATCH rdma-next v1 0/7] Preparation to DevX extension series
From: Or Gerlitz @ 2018-09-20 20:16 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180920183526.13995-1-leon@kernel.org>
On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
> Set uid as part of various IB commands so that the firmware can manage
> the IB object in a secured way.
This series deals with FS core and commands used by the Ethernet driver
> net/mlx5: Update mlx5_ifc with DEVX UID bits
> net/mlx5: Set uid as part of CQ commands
> net/mlx5: Set uid as part of RQ commands
> net/mlx5: Set uid as part of SQ commands
such as the life-cycle (create, modify, destroy) of objects like:
RQ/SQ/CQ/etc --
saying IB commands is inaccurate, please be more precise
>
> The firmware should mark this IB object with the given uid so that it
> can be used later on only by objects with the same uid.
these are not IB objects, but rather Ethernet objects
>
> Upon DEVX flows that use this objec, the pointed object must have
> the same uid as of the issuer uid command.
typo - objec --> object
>
> When a command is issued with uid=0 it means that the issuer of the
> command is trusted (i.e. kernel), in that case any pointed object
> can be used regardless of its uid.
>
> Thanks
>
> net/mlx5: Set uid as part of SRQ commands
> net/mlx5: Set uid as part of DCT commands
> net/mlx5: Set uid as part of QP commands
^ permalink raw reply
* [PATCH net] netlabel: check for IPV4MASK in addrinfo_get
From: Sean Tranchetti @ 2018-09-20 20:29 UTC (permalink / raw)
To: netdev, davem; +Cc: Sean Tranchetti
netlbl_unlabel_addrinfo_get() assumes that if it finds the
NLBL_UNLABEL_A_IPV4ADDR attribute, it must also have the
NLBL_UNLABEL_A_IPV4MASK attribute as well. However, this is
not necessarily the case as the current checks in
netlbl_unlabel_staticadd() and friends are not sufficent to
enforce this.
If passed a netlink message with NLBL_UNLABEL_A_IPV4ADDR,
NLBL_UNLABEL_A_IPV6ADDR, and NLBL_UNLABEL_A_IPV6MASK attributes,
these functions will all call netlbl_unlabel_addrinfo_get() which
will then attempt dereference NULL when fetching the non-existent
NLBL_UNLABEL_A_IPV4MASK attribute:
Unable to handle kernel NULL pointer dereference at virtual address 0
Process unlab (pid: 31762, stack limit = 0xffffff80502d8000)
Call trace:
netlbl_unlabel_addrinfo_get+0x44/0xd8
netlbl_unlabel_staticremovedef+0x98/0xe0
genl_rcv_msg+0x354/0x388
netlink_rcv_skb+0xac/0x118
genl_rcv+0x34/0x48
netlink_unicast+0x158/0x1f0
netlink_sendmsg+0x32c/0x338
sock_sendmsg+0x44/0x60
___sys_sendmsg+0x1d0/0x2a8
__sys_sendmsg+0x64/0xb4
SyS_sendmsg+0x34/0x4c
el0_svc_naked+0x34/0x38
Code: 51001149 7100113f 540000a0 f9401508 (79400108)
---[ end trace f6438a488e737143 ]---
Kernel panic - not syncing: Fatal exception
Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
---
net/netlabel/netlabel_unlabeled.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index c070dfc..c92894c 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -781,7 +781,8 @@ static int netlbl_unlabel_addrinfo_get(struct genl_info *info,
{
u32 addr_len;
- if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR]) {
+ if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR] &&
+ info->attrs[NLBL_UNLABEL_A_IPV4MASK]) {
addr_len = nla_len(info->attrs[NLBL_UNLABEL_A_IPV4ADDR]);
if (addr_len != sizeof(struct in_addr) &&
addr_len != nla_len(info->attrs[NLBL_UNLABEL_A_IPV4MASK]))
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2] net: phy: don't reschedule state machine when PHY is halted
From: Heiner Kallweit @ 2018-09-20 20:34 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <d32d4101-03cb-df57-66d2-29e9a17fc2c5@gmail.com>
When being in state PHY_HALTED we don't have to reschedule the
state machine, phy_start() will start it again.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- added comment
---
drivers/net/phy/phy.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a5e0f0721..a1f8e4816 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1123,9 +1123,13 @@ void phy_state_machine(struct work_struct *work)
/* Only re-schedule a PHY state machine change if we are polling the
* PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
- * between states from phy_mac_interrupt()
+ * between states from phy_mac_interrupt().
+ *
+ * In state PHY_HALTED the PHY gets suspended, so rescheduling the
+ * state machine would be pointless and possibly error prone when
+ * called from phy_disconnect() synchronously.
*/
- if (phy_polling_mode(phydev))
+ if (phy_polling_mode(phydev) && old_state != PHY_HALTED)
queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
PHY_STATE_TIME * HZ);
}
--
2.19.0
^ permalink raw reply related
* [PATCH net] r8169: fix autoneg issue on resume with RTL8168E
From: Heiner Kallweit @ 2018-09-20 20:47 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers
Cc: netdev@vger.kernel.org, Neil MacLeod
It was reported that chip version 33 (RTL8168E) ends up with
10MBit/Half on a 1GBit link after resuming from S3 (with different
link partners). For whatever reason the PHY on this chip doesn't
properly start a renegotiation when soft-reset.
Explicitly requesting a renegotiation fixes this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii")
Reported-by: Neil MacLeod <neil@nmacleod.com>
Tested-by: Neil MacLeod <neil@nmacleod.com>
---
drivers/net/ethernet/realtek/r8169.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1d8631303..7f4647c58 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4069,6 +4069,15 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
phy_speed_up(dev->phydev);
genphy_soft_reset(dev->phydev);
+
+ /* It was reported that chip version 33 ends up with 10MBit/Half on a
+ * 1GBit link after resuming from S3. For whatever reason the PHY on
+ * this chip doesn't properly start a renegotiation when soft-reset.
+ * Explicitly requesting a renegotiation fixes this.
+ */
+ if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
+ dev->phydev->autoneg == AUTONEG_ENABLE)
+ phy_restart_aneg(dev->phydev);
}
static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch
From: Stephen Hemminger @ 2018-09-20 20:47 UTC (permalink / raw)
To: Haiyang Zhang
Cc: haiyangz, davem, netdev, olaf, linux-kernel, devel, vkuznets
In-Reply-To: <20180920170701.9574-2-haiyangz@linuxonhyperv.com>
On Thu, 20 Sep 2018 17:06:59 +0000
Haiyang Zhang <haiyangz@linuxonhyperv.com> wrote:
> +static inline void rsc_add_data
> + (struct netvsc_channel *nvchan,
> + const struct ndis_pkt_8021q_info *vlan,
> + const struct ndis_tcp_ip_checksum_info *csum_info,
> + void *data, u32 len)
> +{
Could this be changed to look more like a function and skip the inline.
The compiler will end up inlining it anyway.
static void rsc_add_data(struct netvsc_channel *nvchan,
^ permalink raw reply
* [PATCH net-next 1/3] net/ipv4: Move device validation to helper
From: dsahern @ 2018-09-20 20:50 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: pablo, fw, David Ahern
In-Reply-To: <20180920205049.15143-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Move the device matching check in __fib_validate_source to a helper and
export it for use by netfilter modules. Code move only; no functional
change intended.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/net/ip_fib.h | 1 +
net/ipv4/fib_frontend.c | 44 +++++++++++++++++++++++++++-----------------
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 69c91d1934c1..f7c109e37298 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -373,6 +373,7 @@ static inline bool fib4_rules_early_flow_dissect(struct net *net,
extern const struct nla_policy rtm_ipv4_policy[];
void ip_fib_init(void);
__be32 fib_compute_spec_dst(struct sk_buff *skb);
+bool fib_info_nh_uses_dev(struct fib_info *fi, const struct net_device *dev);
int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
u8 tos, int oif, struct net_device *dev,
struct in_device *idev, u32 *itag);
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 2998b0e47d4b..222b968de94c 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -315,6 +315,32 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
return inet_select_addr(dev, ip_hdr(skb)->saddr, scope);
}
+bool fib_info_nh_uses_dev(struct fib_info *fi, const struct net_device *dev)
+{
+ bool dev_match = false;
+ int ret;
+
+#ifdef CONFIG_IP_ROUTE_MULTIPATH
+ for (ret = 0; ret < fi->fib_nhs; ret++) {
+ struct fib_nh *nh = &fi->fib_nh[ret];
+
+ if (nh->nh_dev == dev) {
+ dev_match = true;
+ break;
+ } else if (l3mdev_master_ifindex_rcu(nh->nh_dev) == dev->ifindex) {
+ dev_match = true;
+ break;
+ }
+ }
+#else
+ if (fi->fib_nh[0].nh_dev == dev)
+ dev_match = true;
+#endif
+
+ return dev_match;
+}
+EXPORT_SYMBOL_GPL(fib_info_nh_uses_dev);
+
/* Given (packet source, input interface) and optional (dst, oif, tos):
* - (main) check, that source is valid i.e. not broadcast or our local
* address.
@@ -361,24 +387,8 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
(res.type != RTN_LOCAL || !IN_DEV_ACCEPT_LOCAL(idev)))
goto e_inval;
fib_combine_itag(itag, &res);
- dev_match = false;
-
-#ifdef CONFIG_IP_ROUTE_MULTIPATH
- for (ret = 0; ret < res.fi->fib_nhs; ret++) {
- struct fib_nh *nh = &res.fi->fib_nh[ret];
- if (nh->nh_dev == dev) {
- dev_match = true;
- break;
- } else if (l3mdev_master_ifindex_rcu(nh->nh_dev) == dev->ifindex) {
- dev_match = true;
- break;
- }
- }
-#else
- if (FIB_RES_DEV(res) == dev)
- dev_match = true;
-#endif
+ dev_match = fib_info_nh_uses_dev(res.fi, dev);
if (dev_match) {
ret = FIB_RES_NH(res).nh_scope >= RT_SCOPE_HOST;
return ret;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 0/3] net: wean netfilter from fib_nh
From: dsahern @ 2018-09-20 20:50 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: pablo, fw, David Ahern
From: David Ahern <dsahern@gmail.com>
Two netfilter modules reference fib_nh. In both cases the code is
only checking if a nexthop in a fib_info uses a specific device.
Both instances essentially duplicate code from __fib_validate_source,
so move that code into a helper and flip the netfilter modules to
use it.
David Ahern (3):
net/ipv4: Move device validation to helper
netfilter: rpfilter: Convert rpfilter_lookup_reverse to new dev helper
netfilter: nft_fib: Convert nft_fib4_eval to new dev helper
include/net/ip_fib.h | 1 +
net/ipv4/fib_frontend.c | 44 ++++++++++++++++++++++++---------------
net/ipv4/netfilter/ipt_rpfilter.c | 17 +--------------
net/ipv4/netfilter/nft_fib_ipv4.c | 27 ++++++------------------
4 files changed, 35 insertions(+), 54 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 2/3] netfilter: rpfilter: Convert rpfilter_lookup_reverse to new dev helper
From: dsahern @ 2018-09-20 20:50 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: pablo, fw, David Ahern
In-Reply-To: <20180920205049.15143-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Convert rpfilter_lookup_reverse to the new device checking helper
and remove the duplicate code.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/netfilter/ipt_rpfilter.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index 12843c9ef142..0b10d8812828 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -36,7 +36,6 @@ static bool rpfilter_lookup_reverse(struct net *net, struct flowi4 *fl4,
const struct net_device *dev, u8 flags)
{
struct fib_result res;
- bool dev_match;
int ret __maybe_unused;
if (fib_lookup(net, fl4, &res, FIB_LOOKUP_IGNORE_LINKSTATE))
@@ -46,21 +45,7 @@ static bool rpfilter_lookup_reverse(struct net *net, struct flowi4 *fl4,
if (res.type != RTN_LOCAL || !(flags & XT_RPFILTER_ACCEPT_LOCAL))
return false;
}
- dev_match = false;
-#ifdef CONFIG_IP_ROUTE_MULTIPATH
- for (ret = 0; ret < res.fi->fib_nhs; ret++) {
- struct fib_nh *nh = &res.fi->fib_nh[ret];
-
- if (nh->nh_dev == dev) {
- dev_match = true;
- break;
- }
- }
-#else
- if (FIB_RES_DEV(res) == dev)
- dev_match = true;
-#endif
- return dev_match || flags & XT_RPFILTER_LOOSE;
+ return fib_info_nh_uses_dev(res.fi, dev) || flags & XT_RPFILTER_LOOSE;
}
static bool
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 3/3] netfilter: nft_fib: Convert nft_fib4_eval to new dev helper
From: dsahern @ 2018-09-20 20:50 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: pablo, fw, David Ahern
In-Reply-To: <20180920205049.15143-1-dsahern@kernel.org>
From: David Ahern <dsahern@gmail.com>
Convert nft_fib4_eval to the new device checking helper and
remove the duplicate code.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/netfilter/nft_fib_ipv4.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/net/ipv4/netfilter/nft_fib_ipv4.c b/net/ipv4/netfilter/nft_fib_ipv4.c
index e50976e3c213..94eb25bc8d7e 100644
--- a/net/ipv4/netfilter/nft_fib_ipv4.c
+++ b/net/ipv4/netfilter/nft_fib_ipv4.c
@@ -76,10 +76,7 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs,
.flowi4_iif = LOOPBACK_IFINDEX,
};
const struct net_device *oif;
- struct net_device *found;
-#ifdef CONFIG_IP_ROUTE_MULTIPATH
- int i;
-#endif
+ const struct net_device *found;
/*
* Do not set flowi4_oif, it restricts results (for example, asking
@@ -146,25 +143,13 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs,
if (!oif) {
found = FIB_RES_DEV(res);
- goto ok;
- }
-
-#ifdef CONFIG_IP_ROUTE_MULTIPATH
- for (i = 0; i < res.fi->fib_nhs; i++) {
- struct fib_nh *nh = &res.fi->fib_nh[i];
+ } else {
+ if (!fib_info_nh_uses_dev(res.fi, oif))
+ return;
- if (nh->nh_dev == oif) {
- found = nh->nh_dev;
- goto ok;
- }
+ found = oif;
}
- return;
-#else
- found = FIB_RES_DEV(res);
- if (found != oif)
- return;
-#endif
-ok:
+
switch (priv->result) {
case NFT_FIB_RESULT_OIF:
*dest = found->ifindex;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: wean netfilter from fib_nh
From: Florian Westphal @ 2018-09-20 20:53 UTC (permalink / raw)
To: dsahern; +Cc: netdev, netfilter-devel, pablo, fw, David Ahern
In-Reply-To: <20180920205049.15143-1-dsahern@kernel.org>
dsahern@kernel.org <dsahern@kernel.org> wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Two netfilter modules reference fib_nh. In both cases the code is
> only checking if a nexthop in a fib_info uses a specific device.
> Both instances essentially duplicate code from __fib_validate_source,
> so move that code into a helper and flip the netfilter modules to
> use it.
Lokks good to me, thanks David.
^ permalink raw reply
* KMSAN: uninit-value in IP6_ECN_decapsulate
From: syzbot @ 2018-09-20 20:54 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 88e0e95b30f1 kmsan: add a newline before "Uninit was creat..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=146dfccf800000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=bf7e6250c7ce248f3ec9
compiler: clang version 7.0.0 (trunk 334104)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177a9ce4400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14f68bd8400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bf7e6250c7ce248f3ec9@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:189
[inline]
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x421/0x970
include/net/inet_ecn.h:234
CPU: 0 PID: 4515 Comm: syz-executor162 Not tainted 4.17.0+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1122
__msan_warning_32+0x70/0xc0 mm/kmsan/kmsan_instr.c:620
INET_ECN_decapsulate include/net/inet_ecn.h:189 [inline]
IP6_ECN_decapsulate+0x421/0x970 include/net/inet_ecn.h:234
ip6ip6_dscp_ecn_decapsulate+0x1e0/0x250 net/ipv6/ip6_tunnel.c:719
__ip6_tnl_rcv+0xff9/0x1a10 net/ipv6/ip6_tunnel.c:829
ip6_tnl_rcv+0xe6/0x110 net/ipv6/ip6_tunnel.c:868
gre_rcv+0x1661/0x1a90 net/ipv6/ip6_gre.c:534
ip6_input_finish+0x1353/0x2260 net/ipv6/ip6_input.c:284
NF_HOOK include/linux/netfilter.h:288 [inline]
ip6_input+0x294/0x320 net/ipv6/ip6_input.c:327
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x498/0x6e0 net/ipv6/ip6_input.c:71
NF_HOOK include/linux/netfilter.h:288 [inline]
ipv6_rcv+0x1d6b/0x2360 net/ipv6/ip6_input.c:208
__netif_receive_skb_core+0x47f3/0x4aa0 net/core/dev.c:4592
__netif_receive_skb net/core/dev.c:4657 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5337
napi_poll net/core/dev.c:5735 [inline]
net_rx_action+0x766/0x1a80 net/core/dev.c:5801
__do_softirq+0x592/0x979 kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
</IRQ>
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
ip6_finish_output2+0x1ce8/0x2100 net/ipv6/ip6_output.c:121
ip6_finish_output+0xaf0/0xbb0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip6_output+0x597/0x6c0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
ip6_local_out+0x164/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1703 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1723
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x4254/0x4fc0 net/ipv6/raw.c:935
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
sock_write_iter+0x3bc/0x470 net/socket.c:908
call_write_iter include/linux/fs.h:1784 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x808/0x9f0 fs/read_write.c:487
vfs_write+0x467/0x8c0 fs/read_write.c:549
ksys_write fs/read_write.c:598 [inline]
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x1bf/0x3e0 fs/read_write.c:607
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441199
RSP: 002b:00007fff83b55688 EFLAGS: 00000217 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441199
RDX: 0000000000000004 RSI: 00000000200001c0 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000217 R12: 00000000004020a0
R13: 0000000000402130 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb35/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
__ip6_append_data+0x364d/0x4fb0 net/ipv6/ip6_output.c:1434
ip6_append_data+0x40e/0x6b0 net/ipv6/ip6_output.c:1597
rawv6_sendmsg+0x2756/0x4fc0 net/ipv6/raw.c:928
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
sock_write_iter+0x3bc/0x470 net/socket.c:908
call_write_iter include/linux/fs.h:1784 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x808/0x9f0 fs/read_write.c:487
vfs_write+0x467/0x8c0 fs/read_write.c:549
ksys_write fs/read_write.c:598 [inline]
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x1bf/0x3e0 fs/read_write.c:607
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
---
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
* [PATCH net-next] net: micrel: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 2:42 UTC (permalink / raw)
To: davem; +Cc: linux-kernel, netdev, krzk, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/micrel/ks8695net.c | 2 +-
drivers/net/ethernet/micrel/ks8851_mll.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8695net.c b/drivers/net/ethernet/micrel/ks8695net.c
index bd51e05..b881f5d 100644
--- a/drivers/net/ethernet/micrel/ks8695net.c
+++ b/drivers/net/ethernet/micrel/ks8695net.c
@@ -1164,7 +1164,7 @@ static int ks8695_poll(struct napi_struct *napi, int budget)
* sk_buff and adds it to the TX ring. It then kicks the TX DMA
* engine to ensure transmission begins.
*/
-static int
+static netdev_tx_t
ks8695_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct ks8695_priv *ksp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
index 0e9719f..35f8c9e 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -1021,9 +1021,9 @@ static void ks_write_qmu(struct ks_net *ks, u8 *pdata, u16 len)
* spin_lock_irqsave is required because tx and rx should be mutual exclusive.
* So while tx is in-progress, prevent IRQ interrupt from happenning.
*/
-static int ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
{
- int retv = NETDEV_TX_OK;
+ netdev_tx_t retv = NETDEV_TX_OK;
struct ks_net *ks = netdev_priv(netdev);
disable_irq(netdev->irq);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Jeff Kirsher @ 2018-09-20 21:01 UTC (permalink / raw)
To: Eric Dumazet, Song Liu, netdev; +Cc: intel-wired-lan, kernel-team, stable
In-Reply-To: <c1251d5d-4b18-a1de-acd2-6de829b7c7ac@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
On Thu, 2018-09-20 at 13:35 -0700, Eric Dumazet wrote:
> On 09/20/2018 12:01 PM, Song Liu wrote:
> > The NIC driver should only enable interrupts when napi_complete_done()
> > returns true. This patch adds the check for ixgbe.
> >
> > Cc: stable@vger.kernel.org # 4.10+
> > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Suggested-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
>
>
> Well, unfortunately we do not know why this is needed,
> this is why I have not yet sent this patch formally.
>
> netpoll has correct synchronization :
>
> poll_napi() places into napi->poll_owner current cpu number before
> calling poll_one_napi()
>
> netpoll_poll_lock() does also use napi->poll_owner
>
> When netpoll calls ixgbe poll() method, it passed a budget of 0,
> meaning napi_complete_done() is not called.
>
> As long as we can not explain the problem properly in the changelog,
> we should investigate, otherwise we will probably see coming dozens of
> patches
> trying to fix a 'potential hazard'.
Agreed, which is why I have our validation and developers looking into it,
while we test the current patch from Song.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* general protection fault in ctnetlink_alloc_filter
From: syzbot @ 2018-09-20 21:04 UTC (permalink / raw)
To: coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 3eb5358079d3 Add linux-next specific files for 20180918
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=171ce6f1400000
kernel config: https://syzkaller.appspot.com/x/.config?x=786006c5dafbadf6
dashboard link: https://syzkaller.appspot.com/bug?extid=e45eda8eda6e93a03959
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=114f76fa400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102ed6c6400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e45eda8eda6e93a03959@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 5551 Comm: syz-executor610 Not tainted
4.19.0-rc4-next-20180918+ #74
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:nla_get_be32 include/net/netlink.h:1082 [inline]
RIP: 0010:ctnetlink_alloc_filter+0xb9/0x200
net/netfilter/nf_conntrack_netlink.c:843
Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 57 01 00 00 48 b8 00 00 00 00 00
fc ff df 4d 8b 6c 24 40 49 8d 7d 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 06
RSP: 0018:ffff8801c48f71a0 EFLAGS: 00010247
RAX: dffffc0000000000 RBX: ffff8801d7acd580 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff864dfefd RDI: 0000000000000004
RBP: ffff8801c48f71b8 R08: ffff8801d957a180 R09: ffffed003b585b57
R10: ffffed003b585b57 R11: ffff8801dac2dabb R12: ffff8801c48f7500
R13: 0000000000000000 R14: ffff8801d90ef2b8 R15: ffff8801d90ef291
FS: 0000000000a90880(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 00000001d9104000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ctnetlink_start+0x10b/0x1b0 net/netfilter/nf_conntrack_netlink.c:857
__netlink_dump_start+0x43e/0x6f0 net/netlink/af_netlink.c:2312
netlink_dump_start include/linux/netlink.h:213 [inline]
ctnetlink_get_conntrack+0x777/0x9f0
net/netfilter/nf_conntrack_netlink.c:1320
nfnetlink_rcv_msg+0xdd3/0x10c0 net/netfilter/nfnetlink.c:228
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2447
nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x5a5/0x760 net/netlink/af_netlink.c:1336
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
___sys_sendmsg+0x7fd/0x930 net/socket.c:2117
__sys_sendmsg+0x11d/0x280 net/socket.c:2155
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400d9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff461c2298 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004400d9
RDX: 0000000000000000 RSI: 0000000020d65000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401960
R13: 00000000004019f0 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 37c3db5bd5270e98 ]---
RIP: 0010:nla_get_be32 include/net/netlink.h:1082 [inline]
RIP: 0010:ctnetlink_alloc_filter+0xb9/0x200
net/netfilter/nf_conntrack_netlink.c:843
Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 57 01 00 00 48 b8 00 00 00 00 00
fc ff df 4d 8b 6c 24 40 49 8d 7d 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 06
RSP: 0018:ffff8801c48f71a0 EFLAGS: 00010247
RAX: dffffc0000000000 RBX: ffff8801d7acd580 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff864dfefd RDI: 0000000000000004
RBP: ffff8801c48f71b8 R08: ffff8801d957a180 R09: ffffed003b585b57
R10: ffffed003b585b57 R11: ffff8801dac2dabb R12: ffff8801c48f7500
R13: 0000000000000000 R14: ffff8801d90ef2b8 R15: ffff8801d90ef291
FS: 0000000000a90880(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 00000001d9104000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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
* [PATCH net-next] net: freescale: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 2:50 UTC (permalink / raw)
To: davem, madalin.bucur, pantelis.antoniou, claudiu.manoil,
leoyang.li
Cc: linux-kernel, netdev, linuxppc-dev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 3 ++-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 3 ++-
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 3 ++-
drivers/net/ethernet/freescale/gianfar.c | 4 ++--
drivers/net/ethernet/freescale/ucc_geth.c | 3 ++-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index a5131a5..84843de 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2044,7 +2044,8 @@ static inline int dpaa_xmit(struct dpaa_priv *priv,
return 0;
}
-static int dpaa_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
+static netdev_tx_t
+dpaa_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
{
const int queue_mapping = skb_get_queue_mapping(skb);
bool nonlinear = skb_is_nonlinear(skb);
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 6d7269d..b90bab7 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -305,7 +305,8 @@ static int mpc52xx_fec_close(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct bcom_fec_bd *bd;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 2c2976a..7c548ed 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -481,7 +481,8 @@ static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
}
#endif
-static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
cbd_t __iomem *bdp;
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index c488d31..0bd21a4 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -110,7 +110,7 @@
const char gfar_driver_version[] = "2.0";
static int gfar_enet_open(struct net_device *dev);
-static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t gfar_start_xmit(struct sk_buff *skb, struct net_device *dev);
static void gfar_reset_task(struct work_struct *work);
static void gfar_timeout(struct net_device *dev);
static int gfar_close(struct net_device *dev);
@@ -2332,7 +2332,7 @@ static inline bool gfar_csum_errata_76(struct gfar_private *priv,
/* This is called by the kernel when a frame is ready for transmission.
* It is pointed to by the dev->hard_start_xmit function pointer
*/
-static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_tx_q *tx_queue = NULL;
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 9600837..32e0270 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3078,7 +3078,8 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* This is called by the kernel when a frame is ready for transmission. */
/* It is pointed to by the dev->hard_start_xmit function pointer */
-static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ucc_geth_private *ugeth = netdev_priv(dev);
#ifdef CONFIG_UGETH_TX_ON_DEMAND
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: seeq: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 2:53 UTC (permalink / raw)
To: davem, linux; +Cc: linux-kernel, netdev, linux-arm-kernel, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/seeq/ether3.c | 5 +++--
drivers/net/ethernet/seeq/sgiseeq.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/seeq/ether3.c b/drivers/net/ethernet/seeq/ether3.c
index c5bc124..d1bb73b 100644
--- a/drivers/net/ethernet/seeq/ether3.c
+++ b/drivers/net/ethernet/seeq/ether3.c
@@ -77,7 +77,8 @@
static int ether3_rx(struct net_device *dev, unsigned int maxcnt);
static void ether3_tx(struct net_device *dev);
static int ether3_open (struct net_device *dev);
-static int ether3_sendpacket (struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ether3_sendpacket(struct sk_buff *skb,
+ struct net_device *dev);
static irqreturn_t ether3_interrupt (int irq, void *dev_id);
static int ether3_close (struct net_device *dev);
static void ether3_setmulticastlist (struct net_device *dev);
@@ -481,7 +482,7 @@ static void ether3_timeout(struct net_device *dev)
/*
* Transmit a packet
*/
-static int
+static netdev_tx_t
ether3_sendpacket(struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
diff --git a/drivers/net/ethernet/seeq/sgiseeq.c b/drivers/net/ethernet/seeq/sgiseeq.c
index 573691b..70cce63 100644
--- a/drivers/net/ethernet/seeq/sgiseeq.c
+++ b/drivers/net/ethernet/seeq/sgiseeq.c
@@ -578,7 +578,8 @@ static inline int sgiseeq_reset(struct net_device *dev)
return 0;
}
-static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct sgiseeq_private *sp = netdev_priv(dev);
struct hpc3_ethregs *hregs = sp->hregs;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: cirrus: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 3:02 UTC (permalink / raw)
To: davem, hsweeten, fthain, geert, b.zolnierkie
Cc: linux-kernel, netdev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/cirrus/mac89x0.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cirrus/ep93xx_eth.c b/drivers/net/ethernet/cirrus/ep93xx_eth.c
index e2a7029..13dfdfc 100644
--- a/drivers/net/ethernet/cirrus/ep93xx_eth.c
+++ b/drivers/net/ethernet/cirrus/ep93xx_eth.c
@@ -332,7 +332,7 @@ static int ep93xx_poll(struct napi_struct *napi, int budget)
return rx;
}
-static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ep93xx_priv *ep = netdev_priv(dev);
struct ep93xx_tdesc *txd;
diff --git a/drivers/net/ethernet/cirrus/mac89x0.c b/drivers/net/ethernet/cirrus/mac89x0.c
index 3f8fe8f..6324e80 100644
--- a/drivers/net/ethernet/cirrus/mac89x0.c
+++ b/drivers/net/ethernet/cirrus/mac89x0.c
@@ -113,7 +113,7 @@ struct net_local {
/* Index to functions, as function prototypes. */
static int net_open(struct net_device *dev);
-static int net_send_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t net_send_packet(struct sk_buff *skb, struct net_device *dev);
static irqreturn_t net_interrupt(int irq, void *dev_id);
static void set_multicast_list(struct net_device *dev);
static void net_rx(struct net_device *dev);
@@ -324,7 +324,7 @@ static int mac89x0_device_probe(struct platform_device *pdev)
return 0;
}
-static int
+static netdev_tx_t
net_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct net_local *lp = netdev_priv(dev);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: sgi: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-21 3:05 UTC (permalink / raw)
To: davem, ralf; +Cc: linux-kernel, netdev, linux-mips, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/sgi/ioc3-eth.c | 4 ++--
drivers/net/ethernet/sgi/meth.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c b/drivers/net/ethernet/sgi/ioc3-eth.c
index 18d533f..3140999 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -99,7 +99,7 @@ struct ioc3_private {
static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static void ioc3_set_multicast_list(struct net_device *dev);
-static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
static void ioc3_timeout(struct net_device *dev);
static inline unsigned int ioc3_hash(const unsigned char *addr);
static inline void ioc3_stop(struct ioc3_private *ip);
@@ -1390,7 +1390,7 @@ static void ioc3_remove_one(struct pci_dev *pdev)
.remove = ioc3_remove_one,
};
-static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
unsigned long data;
struct ioc3_private *ip = netdev_priv(dev);
diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index ea55abd..703fbbe 100644
--- a/drivers/net/ethernet/sgi/meth.c
+++ b/drivers/net/ethernet/sgi/meth.c
@@ -697,7 +697,7 @@ static void meth_add_to_tx_ring(struct meth_private *priv, struct sk_buff *skb)
/*
* Transmit a packet (called by the kernel)
*/
-static int meth_tx(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t meth_tx(struct sk_buff *skb, struct net_device *dev)
{
struct meth_private *priv = netdev_priv(dev);
unsigned long flags;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Andrew Lunn @ 2018-09-21 3:12 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Arnd Bergmann, Ard Biesheuvel, Eric Biggers, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9rJq=q7xj_E_84GN5FuzSW2KdP4Ch=y527Lem0ME4GnLg@mail.gmail.com>
On Fri, Sep 21, 2018 at 02:11:43AM +0200, Jason A. Donenfeld wrote:
> Hey Arnd,
>
> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > Right, if you hit a stack requirement like this, it's usually the compiler
> > doing something bad, not just using too much stack but also generating
> > rather slow object code in the process. It's better to fix the bug by
> > optimizing the code to not spill registers to the stack.
> >
> > In the long run, I'd like to reduce the stack frame size further, so
> > best assume that anything over 1024 bytes (on 32-bit) or 1280 bytes
> > (on 64-bit) is a bug in the code, and stay below that.
> >
> > For prototyping, you can just mark the broken functions individually
> > by setting the warning limit for a specific function that is known to
> > be misoptimized by the compiler (with a comment about which compiler
> > and architectures are affected), but not override the limit for the
> > entire file.
>
> Thanks for the explanation. Fortunately in my case, the issues were
> trivially fixable to get it under 1024/1280. (By the way, why does
> 64-bit have a slightly larger stack frame? To account for 32 pointers
> taking double the space or something?) That will be rectified in v6.
Hi Jason
Do you any stack usage information?
A VPN can be at the bottom of some deep stack calls. Swap on NFS over
the VPN? If you have one frame of 1K, you might be O.K. But if you
have a few of these, i can see there might be issues of overflowing
the stack.
Andrew
^ 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