Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH iproute2-next v2 2/4] devlink: Add devlink trap set and show commands
From: Jiri Pirko @ 2019-08-13  8:44 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-3-idosch@idosch.org>

Tue, Aug 13, 2019 at 10:31:41AM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>The trap set command allows the user to set the action of an individual
>trap. Example:
>
># devlink trap set netdevsim/netdevsim10 trap blackhole_route action trap
>
>The trap show command allows the user to get the current status of an
>individual trap or a dump of all traps in case one is not specified.
>When '-s' is specified the trap's statistics are shown. When '-v' is
>specified the metadata types the trap can provide are shown. Example:
>
># devlink -jvps trap show netdevsim/netdevsim10 trap blackhole_route
>{
>    "trap": {
>        "netdevsim/netdevsim10": [ {
>                "name": "blackhole_route",
>                "type": "drop",
>                "generic": true,
>                "action": "trap",
>                "group": "l3_drops",
>                "metadata": [ "input_port" ],
>                "stats": {
>                    "rx": {
>                        "bytes": 0,
>                        "packets": 0
>                    }
>                }
>            } ]
>    }
>}
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>

Acked-by: Jiri Pirko <jiri@mellanox.com>

^ permalink raw reply

* Re: [PATCH v4 8/9] MIPS: SGI-IP27: fix readb/writeb addressing
From: Philippe Mathieu-Daudé @ 2019-08-13  8:47 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Andy Shevchenko
  Cc: Thomas Bogendoerfer, Ralf Baechle, Paul Burton, James Hogan,
	Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
	Alessandro Zummo, Alexandre Belloni, Jiri Slaby, Evgeniy Polyakov,
	linux-mips, Linux Kernel Mailing List, linux-input, netdev,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
	open list:SERIAL DRIVERS
In-Reply-To: <20190811072907.GA1416@kroah.com>

Hi Thomas,

On 8/11/19 9:29 AM, Greg Kroah-Hartman wrote:
> On Sat, Aug 10, 2019 at 04:22:23PM +0300, Andy Shevchenko wrote:
>> On Fri, Aug 9, 2019 at 1:34 PM Thomas Bogendoerfer
>> <tbogendoerfer@suse.de> wrote:
>>>
>>> Our chosen byte swapping, which is what firmware already uses, is to
>>> do readl/writel by normal lw/sw intructions (data invariance). This
>>> also means we need to mangle addresses for u8 and u16 accesses. The
>>> mangling for 16bit has been done aready, but 8bit one was missing.
>>> Correcting this causes different addresses for accesses to the
>>> SuperIO and local bus of the IOC3 chip. This is fixed by changing
>>> byte order in ioc3 and m48rtc_rtc structs.
>>
>>>  /* serial port register map */
>>>  struct ioc3_serialregs {
>>> -       uint32_t        sscr;
>>> -       uint32_t        stpir;
>>> -       uint32_t        stcir;
>>> -       uint32_t        srpir;
>>> -       uint32_t        srcir;
>>> -       uint32_t        srtr;
>>> -       uint32_t        shadow;
>>> +       u32     sscr;
>>> +       u32     stpir;
>>> +       u32     stcir;
>>> +       u32     srpir;
>>> +       u32     srcir;
>>> +       u32     srtr;
>>> +       u32     shadow;
>>>  };
>>
>> Isn't it a churn? AFAIU kernel documentation the uint32_t is okay to
>> use, just be consistent inside one module / driver.
>> Am I mistaken?
> 
> No, but really it uint* shouldn't be used anywhere in the kernel source
> as it does not make sense.

If you respin your series, please send this cleanup as a separate patch.

Thanks,

Phil.

^ permalink raw reply

* Re: [PATCH 05/16] sh: prefer __section from compiler_attributes.h
From: Yoshinori Sato @ 2019-08-13  8:51 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: akpm, sedat.dilek, jpoimboe, yhs, miguel.ojeda.sandonis,
	clang-built-linux, Rich Felker, Alexei Starovoitov,
	Daniel Borkmann, Martin KaFai Lau, Song Liu, linux-sh,
	linux-kernel, netdev, bpf
In-Reply-To: <20190812215052.71840-5-ndesaulniers@google.com>

On Tue, 13 Aug 2019 06:50:38 +0900,
Nick Desaulniers wrote:
> 
> Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
>  arch/sh/include/asm/cache.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sh/include/asm/cache.h b/arch/sh/include/asm/cache.h
> index 2408ac4873aa..07ddf31124a3 100644
> --- a/arch/sh/include/asm/cache.h
> +++ b/arch/sh/include/asm/cache.h
> @@ -15,7 +15,7 @@
>  
>  #define L1_CACHE_BYTES		(1 << L1_CACHE_SHIFT)
>  
> -#define __read_mostly __attribute__((__section__(".data..read_mostly")))
> +#define __read_mostly __section(.data..read_mostly)
>  
>  #ifndef __ASSEMBLY__
>  struct cache_info {
> -- 
> 2.23.0.rc1.153.gdeed80330f-goog
> 

Applied sh-next.
Thanks.

-- 
Yosinori Sato

^ permalink raw reply

* Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
From: Antoine Tenart @ 2019-08-13  8:58 UTC (permalink / raw)
  To: Igor Russkikh
  Cc: Antoine Tenart, davem@davemloft.net, sd@queasysnail.net,
	andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com,
	allan.nielsen@microchip.com, camelia.groza@nxp.com,
	Simon Edelhaus, Pavel Belous
In-Reply-To: <e96fa4ae-1f2c-c1be-b2d8-060217d8e151@aquantia.com>

Hi Igor,

On Sat, Aug 10, 2019 at 01:20:32PM +0000, Igor Russkikh wrote:
> On 08.08.2019 17:05, Antoine Tenart wrote:
> 
> > The Rx and TX handlers are modified to take in account the special case
> > were the MACsec transformation happens in the hardware, whether in a PHY
> > or in a MAC, as the packets seen by the networking stack on both the
> 
> Don't you think we may eventually may need xmit / handle_frame ops to be
> a part of macsec_ops?
> 
> That way software macsec could be extract to just another type of offload.
> The drawback of current code is it doesn't show explicitly the path of
> offloaded packets. It is hidden in `handle_not_macsec` and in
> `macsec_start_xmit` branch. This makes incorrect counters to tick (see my below
> comment)
> 
> Another thing is that both xmit / macsec_handle_frame can't now be customized
> by device driver. But this may be required.
> We for example have usecases and HW features to allow specific flows to bypass
> macsec encryption. This is normally used for macsec key control protocols,
> identified by ethertype. Your phy is also capable on that as I see.

I think this question is linked to the use of a MACsec virtual interface
when using h/w offloading. The starting point for me was that I wanted
to reuse the data structures and the API exposed to the userspace by the
s/w implementation of MACsec. I then had two choices: keeping the exact
same interface for the user (having a virtual MACsec interface), or
registering the MACsec genl ops onto the real net devices (and making
the s/w implementation a virtual net dev and a provider of the MACsec
"offloading" ops).

The advantages of the first option were that nearly all the logic of the
s/w implementation could be kept and especially that it would be
transparent for the user to use both implementations of MACsec. But this
raised an issue as I had to modify the xmit / handle_frame ops to let
all the traffic pass. This is because we have no way of knowing if a
frame was handled by the MACsec h/w or not in ingress. So the virtual
interface here only serve as the entrypoint for the API...

The second option would have the advantage to better represent the actual
flow, but the way of configuring MACsec would be a bit different for the
user, whether he wants to use s/w or h/w MACsec. If we were to do this I
think we could extract the genl functions from the MACsec s/w
implementation, and let it implement the MACsec ops (exactly as the
offloading drivers).

I'm open to discussing this :)

As for the need for xmit / handle_frame ops (for a MAC w/ MACsec
offloading), I'd say the xmit / handle_frame ops of the real net device
driver could be used as the one of the MACsec virtual interface do not
do much (regardless of the implementation choice discussed above).

> > @@ -2546,11 +2814,15 @@ static netdev_tx_t macsec_start_xmit(struct sk_buff *skb,
> >  {
> >  	struct macsec_dev *macsec = netdev_priv(dev);
> >  	struct macsec_secy *secy = &macsec->secy;
> > +	struct macsec_tx_sc *tx_sc = &secy->tx_sc;
> >  	struct pcpu_secy_stats *secy_stats;
> > +	struct macsec_tx_sa *tx_sa;
> >  	int ret, len;
> >  
> > +	tx_sa = macsec_txsa_get(tx_sc->sa[tx_sc->encoding_sa]);
> 
> Declared, but not used?

I'll remove it then.

> >  	/* 10.5 */
> > -	if (!secy->protect_frames) {
> > +	if (!secy->protect_frames || macsec_get_ops(netdev_priv(dev), NULL)) {
> >  		secy_stats = this_cpu_ptr(macsec->stats);
> >  		u64_stats_update_begin(&secy_stats->syncp);
> >  		secy_stats->stats.OutPktsUntagged++;
> 
> Here you use same `if` for sw and hw flows, this making `OutPktsUntagged`
> counter invalid.

Right, I'll try to fix that.

> >  	struct macsec_dev *macsec = macsec_priv(dev);
> > -	struct net_device *real_dev;
> > +	struct net_device *real_dev, *loop_dev;
> > +	struct macsec_context ctx;
> > +	const struct macsec_ops *ops;
> > +	struct net *loop_net;
> 
> Reverse Christmas tree is normally a formatting requirement where possible.

Sure.

> > +	for_each_net(loop_net) {
> > +		for_each_netdev(loop_net, loop_dev) {
> > +			struct macsec_dev *priv;
> > +
> > +			if (!netif_is_macsec(loop_dev))
> > +				continue;
> > +
> > +			priv = macsec_priv(loop_dev);
> > +
> > +			/* A limitation of the MACsec h/w offloading is only a
> > +			 * single MACsec interface can be created for a given
> > +			 * real interface.
> > +			 */
> > +			if (macsec_get_ops(netdev_priv(dev), NULL) &&
> > +			    priv->real_dev == real_dev)
> > +				return -EBUSY;
> > +		}
> > +	}
> > +
> 
> There is no need to do this search loop if `macsec_get_ops(..) == NULL` ?
> So you can extract this check before `for_each_net` for SW macsec...

Right, I'll fix it!

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v2 bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits
From: Ivan Khoronzhuk @ 2019-08-13  9:12 UTC (permalink / raw)
  To: Magnus Karlsson
  Cc: Björn Töpel, linux-mm, Xdp, Network Development, bpf,
	linux-kernel, akpm, Alexei Starovoitov, Karlsson, Magnus
In-Reply-To: <CAJ8uoz0bBhdQSocQz8Y9tvrGCsCE9TDf3m1u6=sL4Eo5tZ17YQ@mail.gmail.com>

On Tue, Aug 13, 2019 at 10:02:54AM +0200, Magnus Karlsson wrote:
>On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
>> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
>> established already and are part of configuration interface.
>>
>> But for 32-bit systems, while AF_XDP socket configuration, the values
>> are to large to pass maximum allowed file size verification.
>> The offsets can be tuned ofc, but instead of changing existent
>> interface - extend max allowed file size for sockets.
>
>Can you use mmap2() instead that takes a larger offset (2^44) even on
>32-bit systems?

That's for mmap2.

>
>/Magnus
>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>>
>> Based on bpf-next/master
>>
>> v2..v1:
>>         removed not necessarily #ifdev as ULL and UL for 64 has same size
>>
>>  mm/mmap.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 7e8c3e8ae75f..578f52812361 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -1358,6 +1358,9 @@ static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
>>         if (S_ISBLK(inode->i_mode))
>>                 return MAX_LFS_FILESIZE;
>>
>> +       if (S_ISSOCK(inode->i_mode))
>> +               return MAX_LFS_FILESIZE;
>> +
>>         /* Special "we do even unsigned file positions" case */
>>         if (file->f_mode & FMODE_UNSIGNED_OFFSET)
>>                 return 0;
>> --
>> 2.17.1
>>

-- 
Regards,
Ivan Khoronzhuk

^ permalink raw reply

* [PATCH] cxgb4: fix a memory leak bug
From: Wenwen Wang @ 2019-08-13  9:18 UTC (permalink / raw)
  To: Wenwen Wang
  Cc: Vishal Kulkarni, David S. Miller,
	open list:CXGB4 ETHERNET DRIVER (CXGB4), open list

In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
leading to a memory leak bug. To fix this issue, free t before returning
the error.

Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 0295903..d692251 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -3236,8 +3236,10 @@ static ssize_t blocked_fl_write(struct file *filp, const char __user *ubuf,
 		return -ENOMEM;
 
 	err = bitmap_parse_user(ubuf, count, t, adap->sge.egr_sz);
-	if (err)
+	if (err) {
+		kvfree(t);
 		return err;
+	}
 
 	bitmap_copy(adap->sge.blocked_fl, t, adap->sge.egr_sz);
 	kvfree(t);
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH v3 11/17] qca: no need to check return value of debugfs_create functions
From: Stefan Wahren @ 2019-08-13  9:21 UTC (permalink / raw)
  To: Greg Kroah-Hartman, netdev; +Cc: David S. Miller, Michael Heimpold, Yangtao Li
In-Reply-To: <20190810101732.26612-12-gregkh@linuxfoundation.org>

On 10.08.19 12:17, Greg Kroah-Hartman wrote:
> 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: "David S. Miller" <davem@davemloft.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Michael Heimpold <michael.heimpold@i2se.com>
> Cc: Yangtao Li <tiny.windzz@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Acked-by: Stefan Wahren <stefan.wahren@i2se.com>


^ permalink raw reply

* Re: KASAN: slab-out-of-bounds Read in usbnet_generic_cdc_bind
From: Oliver Neukum @ 2019-08-13  9:27 UTC (permalink / raw)
  To: Andrey Konovalov, syzbot
  Cc: David S. Miller, syzkaller-bugs, Alan Stern, LKML, USB list,
	netdev
In-Reply-To: <CAAeHK+wELVfuQPJaOeG7KggR2BDTOuzCYLC+dzqbhrRRPNf9cA@mail.gmail.com>

Am Montag, den 12.08.2019, 14:27 +0200 schrieb Andrey Konovalov:
> On
> This one is funny, we do sizeof(struct usb_cdc_mdlm_desc *) instead of
> sizeof(struct usb_cdc_mdlm_desc) and the same for
> usb_cdc_mdlm_detail_desc in cdc_parse_cdc_header().

You are right. Old copy & paste error presumably.
Patch is on the way.

	Regards
		Oliver


^ permalink raw reply

* Re: [PATCH v4 3/9] nvmem: core: add nvmem_device_find
From: Srinivas Kandagatla @ 2019-08-13  9:40 UTC (permalink / raw)
  To: Thomas Bogendoerfer, Ralf Baechle, Paul Burton, James Hogan,
	Dmitry Torokhov, Lee Jones, David S. Miller, Alessandro Zummo,
	Alexandre Belloni, Greg Kroah-Hartman, Jiri Slaby,
	Evgeniy Polyakov, linux-mips, linux-kernel, linux-input, netdev,
	linux-rtc, linux-serial
In-Reply-To: <20190809103235.16338-4-tbogendoerfer@suse.de>



On 09/08/2019 11:32, Thomas Bogendoerfer wrote:
> nvmem_device_find provides a way to search for nvmem devices with
> the help of a match function simlair to bus_find_device.
> 
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
>   drivers/nvmem/core.c           | 62 ++++++++++++++++++++++--------------------
>   include/linux/nvmem-consumer.h |  9 ++++++
>   2 files changed, 41 insertions(+), 30 deletions(-)

Have you considered using nvmem_register_notifier() ?


--srini

^ permalink raw reply

* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Pablo Neira Ayuso @ 2019-08-13  9:55 UTC (permalink / raw)
  To: Jeremy Sowden; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190807141705.4864-1-jeremy@azazel.net>

On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> A number of netfilter header files are on the header-test blacklist
> becuse they cannot be compiled stand-alone.   There are two main reasons
> for this: missing inclusions of other headers, and missing conditionals
> checking for CONFIG_* symbols.
> 
> The first six of these patches rectify these omissions, the seventh
> removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> removes all the NF headers from the blacklist.
> 
> I've cc'ed Masahiro Yamada because the last patch removes 74 lines from
> include/Kbuild and may conflict with his kbuild tree.

Series applied, one comment below.

> Jeremy Sowden (8):
>   netfilter: inlined four headers files into another one.
>   netfilter: added missing includes to a number of header-files.
>   netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
>     header-file.
>   netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
>     header-file.
>   netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
>     some header-files.
>   netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
>     header-files.
>   netfilter: removed "#ifdef __KERNEL__" guards from some headers.
>   kbuild: removed all netfilter headers from header-test blacklist.

Would you mind if - before pushing this out - I do this string
replacement for the patch subject?

s/added/add
s/removed/remove
s/inlined/inline

I was told present tense is preferred for description. Otherwise, I'll
leave them as is.

Thanks.

^ permalink raw reply

* Re: [PATCH] net/netfilter - add missing prototypes.
From: Pablo Neira Ayuso @ 2019-08-13  9:56 UTC (permalink / raw)
  To: Valdis Klētnieks
  Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
	netdev, linux-kernel
In-Reply-To: <54079.1565242088@turing-police>

On Thu, Aug 08, 2019 at 01:28:08AM -0400, Valdis Klētnieks wrote:
> Sparse rightly complains about undeclared symbols.
> 
>   CHECK   net/netfilter/nft_set_hash.c
> net/netfilter/nft_set_hash.c:647:21: warning: symbol 'nft_set_rhash_type' was not declared. Should it be static?
> net/netfilter/nft_set_hash.c:670:21: warning: symbol 'nft_set_hash_type' was not declared. Should it be static?
> net/netfilter/nft_set_hash.c:690:21: warning: symbol 'nft_set_hash_fast_type' was not declared. Should it be static?
>   CHECK   net/netfilter/nft_set_bitmap.c
> net/netfilter/nft_set_bitmap.c:296:21: warning: symbol 'nft_set_bitmap_type' was not declared. Should it be static?
>   CHECK   net/netfilter/nft_set_rbtree.c
> net/netfilter/nft_set_rbtree.c:470:21: warning: symbol 'nft_set_rbtree_type' was not declared. Should it be static?
> 
> Include nf_tables_core.h rather than nf_tables.h to pick up the additional definitions.

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] net/netfilter/nf_nat_proto.c - make tables static
From: Pablo Neira Ayuso @ 2019-08-13  9:58 UTC (permalink / raw)
  To: Valdis Klētnieks
  Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
	netdev, linux-kernel
In-Reply-To: <55481.1565243002@turing-police>

On Thu, Aug 08, 2019 at 01:43:22AM -0400, Valdis Klētnieks wrote:
> Sparse warns about two tables not being declared.
> 
>   CHECK   net/netfilter/nf_nat_proto.c
> net/netfilter/nf_nat_proto.c:725:26: warning: symbol 'nf_nat_ipv4_ops' was not declared. Should it be static?
> net/netfilter/nf_nat_proto.c:964:26: warning: symbol 'nf_nat_ipv6_ops' was not declared. Should it be static?
> 
> And in fact they can indeed be static.

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Jeremy Sowden @ 2019-08-13 10:04 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190813095529.aisgjjwl6rzt5xeh@salvia>

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

On 2019-08-13, at 11:55:29 +0200, Pablo Neira Ayuso wrote:
> On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> > A number of netfilter header files are on the header-test blacklist
> > becuse they cannot be compiled stand-alone.   There are two main
> > reasons for this: missing inclusions of other headers, and missing
> > conditionals checking for CONFIG_* symbols.
> >
> > The first six of these patches rectify these omissions, the seventh
> > removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> > removes all the NF headers from the blacklist.
> >
> > I've cc'ed Masahiro Yamada because the last patch removes 74 lines
> > from include/Kbuild and may conflict with his kbuild tree.
>
> Series applied, one comment below.
>
> > Jeremy Sowden (8):
> >   netfilter: inlined four headers files into another one.
> >   netfilter: added missing includes to a number of header-files.
> >   netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
> >     header-file.
> >   netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
> >     header-file.
> >   netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
> >     some header-files.
> >   netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
> >     header-files.
> >   netfilter: removed "#ifdef __KERNEL__" guards from some headers.
> >   kbuild: removed all netfilter headers from header-test blacklist.
>
> Would you mind if - before pushing this out - I do this string
> replacement for the patch subject?
>
> s/added/add
> s/removed/remove
> s/inlined/inline
>
> I was told present tense is preferred for description. Otherwise, I'll
> leave them as is.

I adopted past tenses because at the point at which one is reading the
description of a commit, one is usually reading about old behaviour and
what has been done to change it.  However, I wasn't aware that there was
a preference and I am happy to switch to the present tense instead, so
by all means feel free to change them.

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* [PATCH] qed: Add cleanup in qed_slowpath_start()
From: Wenwen Wang @ 2019-08-13 10:05 UTC (permalink / raw)
  To: Wenwen Wang
  Cc: Ariel Elior, supporter:QLOGIC QL4xxx ETHERNET DRIVER,
	David S. Miller, open list:QLOGIC QL4xxx ETHERNET DRIVER,
	open list

If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
memory leaks. To fix this issue, redirect the execution to the label 'err3'
before returning the error.

Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
 drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..d16a251 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1325,7 +1325,7 @@ static int qed_slowpath_start(struct qed_dev *cdev,
 					      &drv_version);
 		if (rc) {
 			DP_NOTICE(cdev, "Failed sending drv version command\n");
-			return rc;
+			goto err3;
 		}
 	}
 
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH rdma-next 0/4] Add XRQ and SRQ support to DEVX interface
From: Leon Romanovsky @ 2019-08-13 10:06 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Jason Gunthorpe, RDMA mailing list, Edward Srouji, Saeed Mahameed,
	Yishai Hadas, linux-netdev
In-Reply-To: <dc88624d6632f23a1b0ca77f45ed21a20158d3e6.camel@redhat.com>

On Mon, Aug 12, 2019 at 11:43:58AM -0400, Doug Ledford wrote:
> On Thu, 2019-08-08 at 10:11 +0000, Leon Romanovsky wrote:
> > On Thu, Aug 08, 2019 at 11:43:54AM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@mellanox.com>
> > >
> > > Hi,
> > >
> > > This small series extends DEVX interface with SRQ and XRQ legacy
> > > commands.
> >
> > Sorry for typo in cover letter, there is no SRQ here.
>
> Series looks fine to me.  Are you planning on the first two via mlx5-
> next and the remainder via RDMA tree?
>

Thanks, applied to mlx5-next

b1635ee6120c net/mlx5: Add XRQ legacy commands opcodes
647d58a989b3 net/mlx5: Use debug message instead of warn

^ permalink raw reply

* Re: [PATCH v2] net/netfilter: remove unnecessary spaces
From: Pablo Neira Ayuso @ 2019-08-13 10:10 UTC (permalink / raw)
  To: yangxingwu
  Cc: wensong, horms, ja, kadlec, fw, davem, netdev, lvs-devel,
	netfilter-devel, coreteam, linux-kernel, joe
In-Reply-To: <20190716021301.27753-1-xingwu.yang@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next v1 0/8] netfilter: header compilation fixes
From: Pablo Neira Ayuso @ 2019-08-13 10:14 UTC (permalink / raw)
  To: Jeremy Sowden; +Cc: Netfilter Devel, Net Dev, Masahiro Yamada
In-Reply-To: <20190813100424.GA4840@azazel.net>

On Tue, Aug 13, 2019 at 11:04:24AM +0100, Jeremy Sowden wrote:
> On 2019-08-13, at 11:55:29 +0200, Pablo Neira Ayuso wrote:
> > On Wed, Aug 07, 2019 at 03:16:57PM +0100, Jeremy Sowden wrote:
> > > A number of netfilter header files are on the header-test blacklist
> > > becuse they cannot be compiled stand-alone.   There are two main
> > > reasons for this: missing inclusions of other headers, and missing
> > > conditionals checking for CONFIG_* symbols.
> > >
> > > The first six of these patches rectify these omissions, the seventh
> > > removes some unnecessary "#ifdef __KERNEL__" checks, and the last
> > > removes all the NF headers from the blacklist.
> > >
> > > I've cc'ed Masahiro Yamada because the last patch removes 74 lines
> > > from include/Kbuild and may conflict with his kbuild tree.
> >
> > Series applied, one comment below.
> >
> > > Jeremy Sowden (8):
> > >   netfilter: inlined four headers files into another one.
> > >   netfilter: added missing includes to a number of header-files.
> > >   netfilter: added missing IS_ENABLED(CONFIG_BRIDGE_NETFILTER) checks to
> > >     header-file.
> > >   netfilter: added missing IS_ENABLED(CONFIG_NF_TABLES) check to
> > >     header-file.
> > >   netfilter: added missing IS_ENABLED(CONFIG_NF_CONNTRACK) checks to
> > >     some header-files.
> > >   netfilter: added missing IS_ENABLED(CONFIG_NETFILTER) checks to some
> > >     header-files.
> > >   netfilter: removed "#ifdef __KERNEL__" guards from some headers.
> > >   kbuild: removed all netfilter headers from header-test blacklist.
> >
> > Would you mind if - before pushing this out - I do this string
> > replacement for the patch subject?
> >
> > s/added/add
> > s/removed/remove
> > s/inlined/inline
> >
> > I was told present tense is preferred for description. Otherwise, I'll
> > leave them as is.
> 
> I adopted past tenses because at the point at which one is reading the
> description of a commit, one is usually reading about old behaviour and
> what has been done to change it.  However, I wasn't aware that there was
> a preference and I am happy to switch to the present tense instead, so
> by all means feel free to change them.

This is not in the Documentation tree, or I could not find this in a
quick git grep:

https://kernelnewbies.org/PatchPhilosophy

"In patch descriptions and in the subject, it is common and preferable
to use present-tense, imperative language. Write as if you are telling
git what to do with your patch."

I remember though that maintainers have been asking for this in the
past.

Thanks!

^ permalink raw reply

* Re: [PATCH iproute2-next v2 3/4] devlink: Add devlink trap group set and show commands
From: Jiri Pirko @ 2019-08-13 10:15 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-4-idosch@idosch.org>

Tue, Aug 13, 2019 at 10:31:42AM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>These commands are similar to the trap set and show commands, but
>operate on a trap group and not individual traps. Example:
>
># devlink trap group set netdevsim/netdevsim10 group l3_drops action trap
># devlink -jps trap group show netdevsim/netdevsim10 group l3_drops
>{
>    "trap_group": {
>        "netdevsim/netdevsim10": [ {
>                "name": "l3_drops",
>                "generic": true,
>                "stats": {
>                    "rx": {
>                        "bytes": 0,
>                        "packets": 0
>                    }
>                }
>            } ]
>    }
>}
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>

Acked-by: Jiri Pirko <jiri@mellanox.com>

^ permalink raw reply

* Re: [PATCH iproute2-next v2 4/4] devlink: Add man page for devlink-trap
From: Jiri Pirko @ 2019-08-13 10:20 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813083143.13509-5-idosch@idosch.org>

Tue, Aug 13, 2019 at 10:31:43AM CEST, idosch@idosch.org wrote:
>From: Ido Schimmel <idosch@mellanox.com>
>
>Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>---
> man/man8/devlink-monitor.8 |   3 +-
> man/man8/devlink-trap.8    | 138 +++++++++++++++++++++++++++++++++++++
> man/man8/devlink.8         |  11 ++-
> 3 files changed, 150 insertions(+), 2 deletions(-)
> create mode 100644 man/man8/devlink-trap.8
>
>diff --git a/man/man8/devlink-monitor.8 b/man/man8/devlink-monitor.8
>index 13fe641dc8f5..fffab3a4ce88 100644
>--- a/man/man8/devlink-monitor.8
>+++ b/man/man8/devlink-monitor.8
>@@ -21,7 +21,7 @@ command is the first in the command line and then the object list.
> .I OBJECT-LIST
> is the list of object types that we want to monitor.
> It may contain
>-.BR dev ", " port ".
>+.BR dev ", " port ", " trap ", " trap-group .

Looks like "trap-group" is a leftover here, isn't it?


> 
> .B devlink
> opens Devlink Netlink socket, listens on it and dumps state changes.
>@@ -31,6 +31,7 @@ opens Devlink Netlink socket, listens on it and dumps state changes.
> .BR devlink-dev (8),
> .BR devlink-sb (8),
> .BR devlink-port (8),
>+.BR devlink-trap (8),
> .br
> 
> .SH AUTHOR
>diff --git a/man/man8/devlink-trap.8 b/man/man8/devlink-trap.8
>new file mode 100644
>index 000000000000..4f079eb86d7b
>--- /dev/null
>+++ b/man/man8/devlink-trap.8
>@@ -0,0 +1,138 @@
>+.TH DEVLINK\-TRAP 8 "2 August 2019" "iproute2" "Linux"
>+.SH NAME
>+devlink-trap \- devlink trap configuration
>+.SH SYNOPSIS
>+.sp
>+.ad l
>+.in +8
>+.ti -8
>+.B devlink
>+.RI "[ " OPTIONS " ]"
>+.B trap
>+.RI "{ " COMMAND " |"
>+.BR help " }"
>+.sp
>+
>+.ti -8
>+.IR OPTIONS " := { "
>+\fB\-v\fR[\fIerbose\fR] |
>+\fB\-s\fR[\fItatistics\fR] }

Not sure you need to put generic option here. But I don't mind much.

Otherwise this looks fine.
Acked-by: Jiri Pirko <jiri@mellanox.com>

[...]

^ permalink raw reply

* [PATCH bpf-next 1/3] libbpf: add asm/unistd.h to xsk to get __NR_mmap2
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
  To: magnus.karlsson, bjorn.topel
  Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
	xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>

That's needed to get __NR_mmap2 when mmap2 syscall is used.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
 tools/lib/bpf/xsk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 5007b5d4fd2c..f2fc40f9804c 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -12,6 +12,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <asm/unistd.h>
 #include <arpa/inet.h>
 #include <asm/barrier.h>
 #include <linux/compiler.h>
-- 
2.17.1


^ permalink raw reply related

* [PATCH bpf-next 3/3] samples: bpf: syscal_nrs: use mmap2 if defined
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
  To: magnus.karlsson, bjorn.topel
  Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
	xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>

For arm32 xdp sockets mmap2 is preferred, so use it if it's defined.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
 samples/bpf/syscall_nrs.c  |  5 +++++
 samples/bpf/tracex5_kern.c | 11 +++++++++++
 2 files changed, 16 insertions(+)

diff --git a/samples/bpf/syscall_nrs.c b/samples/bpf/syscall_nrs.c
index 516e255cbe8f..2dec94238350 100644
--- a/samples/bpf/syscall_nrs.c
+++ b/samples/bpf/syscall_nrs.c
@@ -9,5 +9,10 @@ void syscall_defines(void)
 	COMMENT("Linux system call numbers.");
 	SYSNR(__NR_write);
 	SYSNR(__NR_read);
+#ifdef __NR_mmap2
+	SYSNR(__NR_mmap2);
+#else
 	SYSNR(__NR_mmap);
+#endif
+
 }
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
index f57f4e1ea1ec..300350ad299a 100644
--- a/samples/bpf/tracex5_kern.c
+++ b/samples/bpf/tracex5_kern.c
@@ -68,12 +68,23 @@ PROG(SYS__NR_read)(struct pt_regs *ctx)
 	return 0;
 }
 
+#ifdef __NR_mmap2
+PROG(SYS__NR_mmap2)(struct pt_regs *ctx)
+{
+	char fmt[] = "mmap2\n";
+
+	bpf_trace_printk(fmt, sizeof(fmt));
+	return 0;
+}
+#else
 PROG(SYS__NR_mmap)(struct pt_regs *ctx)
 {
 	char fmt[] = "mmap\n";
+
 	bpf_trace_printk(fmt, sizeof(fmt));
 	return 0;
 }
+#endif
 
 char _license[] SEC("license") = "GPL";
 u32 _version SEC("version") = LINUX_VERSION_CODE;
-- 
2.17.1


^ permalink raw reply related

* [PATCH bpf-next 2/3] xdp: xdp_umem: replace kmap on vmap for umem map
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
  To: magnus.karlsson, bjorn.topel
  Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
	xdp-newbies, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20190813102318.5521-1-ivan.khoronzhuk@linaro.org>

For 64-bit there is no reason to use vmap/vunmap, so use page_address
as it was initially. For 32 bits, in some apps, like in samples
xdpsock_user.c when number of pgs in use is quite big, the kmap
memory can be not enough, despite on this, kmap looks like is
deprecated in such cases as it can block and should be used rather
for dynamic mm.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
 net/xdp/xdp_umem.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index a0607969f8c0..907c9019fe21 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -14,7 +14,7 @@
 #include <linux/netdevice.h>
 #include <linux/rtnetlink.h>
 #include <linux/idr.h>
-#include <linux/highmem.h>
+#include <linux/vmalloc.h>
 
 #include "xdp_umem.h"
 #include "xsk_queue.h"
@@ -167,10 +167,12 @@ void xdp_umem_clear_dev(struct xdp_umem *umem)
 
 static void xdp_umem_unmap_pages(struct xdp_umem *umem)
 {
+#if BITS_PER_LONG == 32
 	unsigned int i;
 
 	for (i = 0; i < umem->npgs; i++)
-		kunmap(umem->pgs[i]);
+		vunmap(umem->pages[i].addr);
+#endif
 }
 
 static void xdp_umem_unpin_pages(struct xdp_umem *umem)
@@ -378,8 +380,14 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
 		goto out_account;
 	}
 
-	for (i = 0; i < umem->npgs; i++)
-		umem->pages[i].addr = kmap(umem->pgs[i]);
+	for (i = 0; i < umem->npgs; i++) {
+#if BITS_PER_LONG == 32
+		umem->pages[i].addr = vmap(&umem->pgs[i], 1, VM_MAP,
+					   PAGE_KERNEL);
+#else
+		umem->pages[i].addr = page_address(umem->pgs[i]);
+#endif
+	}
 
 	return 0;
 
-- 
2.17.1


^ permalink raw reply related

* [PATCH bpf-next 0/3] xdpsock: allow mmap2 usage for 32bits
From: Ivan Khoronzhuk @ 2019-08-13 10:23 UTC (permalink / raw)
  To: magnus.karlsson, bjorn.topel
  Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
	xdp-newbies, linux-kernel, Ivan Khoronzhuk

This patchset contains several improvements for af_xdp socket umem
mappings for 32bit systems. Also, there is one more patch outside of
othis series that can be applied to another tree and related to mmap2
af_xdp umem offsets:
"mm: mmap: increase sockets maximum memory size pgoff for 32bits"
https://lkml.org/lkml/2019/8/12/549

Based on bpf-next/master

Ivan Khoronzhuk (3):
  libbpf: add asm/unistd.h to xsk to get __NR_mmap2
  xdp: xdp_umem: replace kmap on vmap for umem map
  samples: bpf: syscal_nrs: use mmap2 if defined

 net/xdp/xdp_umem.c         | 16 ++++++++++++----
 samples/bpf/syscall_nrs.c  |  5 +++++
 samples/bpf/tracex5_kern.c | 11 +++++++++++
 tools/lib/bpf/xsk.c        |  1 +
 4 files changed, 29 insertions(+), 4 deletions(-)

-- 
2.17.1


^ permalink raw reply

* Re: [PATCH iproute2-next v2 4/4] devlink: Add man page for devlink-trap
From: Ido Schimmel @ 2019-08-13 10:39 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, dsahern, stephen, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20190813102037.GP2428@nanopsycho>

On Tue, Aug 13, 2019 at 12:20:37PM +0200, Jiri Pirko wrote:
> Tue, Aug 13, 2019 at 10:31:43AM CEST, idosch@idosch.org wrote:
> >From: Ido Schimmel <idosch@mellanox.com>
> >
> >Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> >---
> > man/man8/devlink-monitor.8 |   3 +-
> > man/man8/devlink-trap.8    | 138 +++++++++++++++++++++++++++++++++++++
> > man/man8/devlink.8         |  11 ++-
> > 3 files changed, 150 insertions(+), 2 deletions(-)
> > create mode 100644 man/man8/devlink-trap.8
> >
> >diff --git a/man/man8/devlink-monitor.8 b/man/man8/devlink-monitor.8
> >index 13fe641dc8f5..fffab3a4ce88 100644
> >--- a/man/man8/devlink-monitor.8
> >+++ b/man/man8/devlink-monitor.8
> >@@ -21,7 +21,7 @@ command is the first in the command line and then the object list.
> > .I OBJECT-LIST
> > is the list of object types that we want to monitor.
> > It may contain
> >-.BR dev ", " port ".
> >+.BR dev ", " port ", " trap ", " trap-group .
> 
> Looks like "trap-group" is a leftover here, isn't it?

You get events when traps and groups are created / destroyed. See below output
when creating a new netdevsim device:

$ devlink mon trap-group
[trap-group,new] netdevsim/netdevsim20: name l2_drops generic true
[trap-group,new] netdevsim/netdevsim20: name l3_drops generic true
[trap-group,new] netdevsim/netdevsim20: name buffer_drops generic true

$ devlink mon trap
[trap,new] netdevsim/netdevsim10: name source_mac_is_multicast type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name vlan_tag_mismatch type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name ingress_vlan_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name ingress_spanning_tree_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name port_list_is_empty type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name port_loopback_filter type drop generic true action drop group l2_drops
[trap,new] netdevsim/netdevsim10: name fid_miss type exception generic false action trap group l2_drops
[trap,new] netdevsim/netdevsim10: name blackhole_route type drop generic true action drop group l3_drops
[trap,new] netdevsim/netdevsim10: name ttl_value_is_too_small type exception generic true action trap group l3_drops
[trap,new] netdevsim/netdevsim10: name tail_drop type drop generic true action drop group buffer_drops

^ permalink raw reply

* RE: [EXT] [PATCH] qed: Add cleanup in qed_slowpath_start()
From: Sudarsana Reddy Kalluru @ 2019-08-13 10:46 UTC (permalink / raw)
  To: Wenwen Wang
  Cc: Ariel Elior, GR-everest-linux-l2, David S. Miller,
	open list:QLOGIC QL4xxx ETHERNET DRIVER, open list
In-Reply-To: <1565690709-3186-1-git-send-email-wenwen@cs.uga.edu>

> -----Original Message-----
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Sent: Tuesday, August 13, 2019 3:35 PM
> To: Wenwen Wang <wenwen@cs.uga.edu>
> Cc: Ariel Elior <aelior@marvell.com>; GR-everest-linux-l2 <GR-everest-linux-
> l2@marvell.com>; David S. Miller <davem@davemloft.net>; open
> list:QLOGIC QL4xxx ETHERNET DRIVER <netdev@vger.kernel.org>; open list
> <linux-kernel@vger.kernel.org>
> Subject: [EXT] [PATCH] qed: Add cleanup in qed_slowpath_start()
> 
> External Email
> 
> ----------------------------------------------------------------------
> If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
> memory leaks. To fix this issue, redirect the execution to the label 'err3'
> before returning the error.
> 
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> ---
>  drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c
> b/drivers/net/ethernet/qlogic/qed/qed_main.c
> index 829dd60..d16a251 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_main.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
> @@ -1325,7 +1325,7 @@ static int qed_slowpath_start(struct qed_dev
> *cdev,
>  					      &drv_version);
>  		if (rc) {
>  			DP_NOTICE(cdev, "Failed sending drv version
> command\n");
> -			return rc;
> +			goto err3;

In this case, we might need to free the ll2-buf allocated at the below path (?),
1312         /* Allocate LL2 interface if needed */
1313         if (QED_LEADING_HWFN(cdev)->using_ll2) {
1314                 rc = qed_ll2_alloc_if(cdev);
May be by adding a new goto label 'err4'.

>  		}
>  	}
> 
> --
> 2.7.4


^ permalink raw reply


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