Extended link state structures and enums use kdoc headers
but then do not describe any of the members.
Convert to normal comments.
Signed-off-by: Jakub Kicinski
---
include/linux/ethtool.h | 4 +---
include/uapi/linux/ethtool.h | 26 ++
2 files changed, 7 insertion
Code to defer the reset(which caps the frequency of the reset) schedules the
timer and returns. Hence, following 'else-if' looks un-necessary.
Fixes: 9de0b86f6444 ("net: hns3: Prevent to request reset frequently")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/h
Code to defer the reset(which caps the frequency of the reset) schedules the
timer and returns. Hence, following 'else-if' looks un-necessary.
Fixes: 9de0b86f6444 ("net: hns3: Prevent to request reset frequently")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/h
From: Eric Dumazet
Date: Wed, 31 Mar 2021 08:00:24 +0200
> Can you merge this patch so that I can send my global fix for fallback
> tunnels, with a correct Fixes: tag for this patch ?
Done.
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 29 Mar 2021 23:45:51 -0700 you wrote:
> From: Eric Dumazet
>
> Same reasons than for the previous commits :
> 6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods")
> 40cb8
On Wed, Mar 31, 2021 at 13:58, Eric Dumazet wrote:
>
> On Wed, Mar 31, 2021 at 2:01 AM Wong, Vee Khee
> wrote:
> >
> > Hi all,
> >
> >
> >
> > This patch introduced the following massive warnings printouts on a
> >
> > Intel x86 Alderlake platform with STMMAC MAC and Marvell 88E2110 PHY.
> >
> >
Hi all,
This patch introduced the following massive warnings printouts on a
Intel x86 Alderlake platform with STMMAC MAC and Marvell 88E2110 PHY.
[ 149.674232] unregister_netdevice: waiting for sit0 to become free. Usage
count = 2
[ 159.930310] unregister_netdevice: waiting for sit0 to become
From: Eric Dumazet
Same reasons than for the previous commits :
6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods")
40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods")
7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init
..]
Here is the summary with links:
- [net-next] sit: proper dev_{hold|put} in ndo_[un]init methods
https://git.kernel.org/netdev/net-next/c/6289a98f0817
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
..]
Here is the summary with links:
- [net-next] ip6_gre: proper dev_{hold|put} in ndo_[un]init methods
https://git.kernel.org/netdev/net-next/c/7f700334be9a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
..]
Here is the summary with links:
- [net-next] ip6_vti: proper dev_{hold|put} in ndo_[un]init methods
https://git.kernel.org/netdev/net-next/c/40cb881b5aaa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
From: Eric Dumazet
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
a warning [1]
Issue here is that:
- all dev_put() should be paired with a corresponding prior dev_hold().
- A driver doing a dev_put() in its ndo_uninit() MUST also
do a dev_hold() in its ndo_init()
From: Eric Dumazet
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
a warning [1]
Issue here is that:
- all dev_put() should be paired with a corresponding prior dev_hold().
- A driver doing a dev_put() in its ndo_uninit() MUST also
do a dev_hold() in its ndo_init()
From: Eric Dumazet
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
a warning [1]
Issue here is that:
- all dev_put() should be paired with a corresponding dev_hold(),
and vice versa.
- A driver doing a dev_put() in its ndo_uninit() MUST also
do a dev_hold() in it
refill objcg stock. This is pointless. As we
already know the charing size. So we can directly skip touch the
objcg stock and introduce obj_cgroup_{un}charge_page() to charge or
uncharge a kmem page.
In the later patch, we can reuse those helpers to charge/uncharge
the kmem pages. This is just code
bool firmware_bug = false;
+
if (force) {
/* Request ME un-configure ULP mode in the PHY */
mac_reg = er32(H2ME);
@@ -1248,16 +1251,24 @@ static s32 e1000_disable_ulp_lpt_lp(struct e1000_hw
*hw, bool force)
e
fan Assmann; David Miller;
> darc...@redhat.com; Shen, Yijun; Yuan, Perry;
> anthony.w...@canonical.com; Hans de Goede; Limonciello, Mario; Aaron
> Ma; Mark Pearson
> Subject: [PATCH v5 2/4] e1000e: bump up timeout to wait when ME un-
> configures ULP mode
>
> Per guidance from I
> *hw, bool force)
> return 0;
>
> if (er32(FWSM) & E1000_ICH_FWSM_FW_VALID) {
> + struct e1000_adapter *adapter = hw->adapter;
> + bool firmware_bug = false;
> +
> if (force) {
> /
t e1000_hw *hw,
bool force)
return 0;
if (er32(FWSM) & E1000_ICH_FWSM_FW_VALID) {
+ struct e1000_adapter *adapter = hw->adapter;
+ bool firmware_bug = false;
+
if (force) {
/* Request ME un-configur
Per guidance from Intel ethernet architecture team, it may take
up to 1 second for unconfiguring ULP mode.
Suggested-by: Aaron Ma
Suggested-by: Sasha Netfin
Fixes: f15bb6dde738cc8fa0 ("e1000e: Add support for S0ix")
BugLink: https://bugs.launchpad.net/bugs/1865570
Link:
https://patchwork.ozlabs
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the patches in your latest vers
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required to set the protections on multiple
> >
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending o
From: Ira Weiny
To correctly support the semantics of kmap() with Kernel protection keys
(PKS), kmap() may be required to set the protections on multiple
processors (globally). Enabling PKS globally can be very expensive
depending on the requested operation. Furthermore, enabling a domain
globa
From: Ira Weiny
Most kmap() callers use the map within a single thread and have no need
for the protection domain to be enabled globally.
To differentiate these kmap users, new k[un]map_thread() calls were
introduced which are thread local.
To aid in debugging the new use of kmap_thread(), add
We're trying to make LOCKDEP-related function declarations
visible to the compiler and depend on dead code elimination
to remove them.
Make lockdep_tasklist_lock_is_held() visible.
Signed-off-by: Jakub Kicinski
---
CC: christian.brau...@ubuntu.com
CC: pet...@infradead.org
CC: ebied...@xmission.c
We're trying to make LOCKDEP-related function declarations
visible to the compiler and depend on dead code elimination
to remove them.
Fix up the situation with lockdep_tcf_chain_is_locked() and
lockdep_tcf_proto_is_locked().
Signed-off-by: Jakub Kicinski
--
CC: j...@mojatatu.com
CC: xiyou.wangc
We're trying to make LOCKDEP-related forward declarations
visible to the compiler and depend on dead code elimination
to remove them.
Expose RCU lock maps.
Signed-off-by: Jakub Kicinski
---
CC: paul...@kernel.org
CC: j...@joshtriplett.org
CC: rost...@goodmis.org
CC: mathieu.desnoy...@efficios.co
We're trying to make LOCKDEP-related function declarations
visible to the compiler and depend on dead code elimination
to remove them.
Un-hide lockdep_sock_is_held().
Signed-off-by: Jakub Kicinski
---
include/net/sock.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/net/soc
On Mon, 2020-06-29 at 20:18 +, stran...@codeaurora.org wrote:
>
> Thanks Cong. Yes, removing the genl_bind()/genl_unbind() functions
> eliminates the
> potential for this deadlock. Adding Johannes here to comment on removing
> these,
> as the family->mcast_bind() capability added by commit c38
On 6/29/2020 5:03 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Functions should only be static inline if they're very short. This
> devres helper is already over 10 lines and it will grow soon as we'll
> be improving upon its approach. Pull it into mdio_devres.c.
>
> Signed-
From: Bartosz Golaszewski
Functions should only be static inline if they're very short. This
devres helper is already over 10 lines and it will grow soon as we'll
be improving upon its approach. Pull it into mdio_devres.c.
Signed-off-by: Bartosz Golaszewski
---
drivers/net/phy/Makefile |
demonstrated below.
1) Thread 1 is performing a netlink_bind() operation on a socket. As
part
of this call, it will call netlink_lock_table(), incrementing the
nl_table_users count to 1.
2) Thread 2 is registering (or unregistering) a genl_family via the
genl_(un)register_family() API
From: Sean Tranchetti
Date: Fri, 26 Jun 2020 18:31:03 -0600
> @@ -328,6 +325,10 @@ int genl_register_family(struct genl_family *family)
> if (err)
> return err;
>
> + /* Acquire netlink table lock before any GENL-specific locks to ensure
> + * sync with any netlink
;
> 1) Thread 1 is performing a netlink_bind() operation on a socket. As part
>of this call, it will call netlink_lock_table(), incrementing the
>nl_table_users count to 1.
> 2) Thread 2 is registering (or unregistering) a genl_family via the
>genl_(un)register_family() A
this call, it will call netlink_lock_table(), incrementing the
nl_table_users count to 1.
2) Thread 2 is registering (or unregistering) a genl_family via the
genl_(un)register_family() API. The cb_lock semaphore will be taken for
writing.
3) Thread 1 will call genl_bind() as part of the
On Tue, Jun 23, 2020 at 1:55 AM Florian Fainelli wrote:
>
> On 6/22/20 3:00 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Functions should only be static inline if they're very short. This
> > devres helper is already over 10 lines and it will grow soon as we'll
> > be impr
On 6/22/20 3:00 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Functions should only be static inline if they're very short. This
> devres helper is already over 10 lines and it will grow soon as we'll
> be improving upon its approach. Pull it into mdio_devres.c.
>
> Signed-off-b
From: Bartosz Golaszewski
Functions should only be static inline if they're very short. This
devres helper is already over 10 lines and it will grow soon as we'll
be improving upon its approach. Pull it into mdio_devres.c.
Signed-off-by: Bartosz Golaszewski
---
drivers/net/phy/Makefile |
This patch prepares for incremental flowtable hook updates.
Signed-off-by: Pablo Neira Ayuso
---
net/netfilter/nf_tables_api.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 87945b4a6789..
On Wed, Aug 14, 2019 at 01:17:30PM +0200, Jakub Jankowski wrote:
On 2019-08-14, Reindl Harald wrote:
that's still not in 5.2.8
It will make its way into next 5.2.x release, as it is now in the
pending queue: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5
On 7/30/19 7:21 PM, Jakub Kicinski wrote:
>
If bpftool was taught to do equivalent of 'ip link' that would be
very different story and I would be opposed to that.
>>> Yes, that'd be pretty clear cut, only the XDP stuff is a bit more
>>> of a judgement call.
>> bpftool must be able t
On Tue, 30 Jul 2019 18:52:40 -0700
Alexei Starovoitov wrote:
> On Tue, Jul 30, 2019 at 06:21:44PM -0700, Jakub Kicinski wrote:
> > > > Duplicating the same features in bpftool will only diminish the
> > > > incentive for moving iproute2 to libbpf.
> > >
> > > not at all. why do you think so
On Tue, Jul 30, 2019 at 06:21:44PM -0700, Jakub Kicinski wrote:
> > > Duplicating the same features in bpftool will only diminish the
> > > incentive for moving iproute2 to libbpf.
> >
> > not at all. why do you think so?
>
> Because iproute2's BPF has fallen behind so the simplest thing is to
On Tue, 30 Jul 2019 17:23:39 -0700, Alexei Starovoitov wrote:
> On Tue, Jul 30, 2019 at 05:07:25PM -0700, Jakub Kicinski wrote:
> > Nothing meaning you disagree it's duplicated effort and unnecessary
> > LoC the community has to maintain, review, test..?
>
> I don't see duplicated effort.
Coul
t; Currently, bpftool net only supports dumping progs loaded on the
> > > > interface. To load XDP prog on interface, user must use other tool
> > > > (eg. iproute2). By this patch, with `bpftool net (un)load`, user can
> > > > (un)load XDP prog on interface.
>
erface. To load XDP prog on interface, user must use other tool
> > > (eg. iproute2). By this patch, with `bpftool net (un)load`, user can
> > > (un)load XDP prog on interface.
> >
> > I don't understand why using another tool is a bad thing :(
> >
oute2). By this patch, with `bpftool net (un)load`, user can
> > (un)load XDP prog on interface.
>
> I don't understand why using another tool is a bad thing :(
> What happened to the Unix philosophy?
>
> I remain opposed to duplicating iproute2's functionality under
On Wed, 31 Jul 2019 03:48:19 +0900, Daniel T. Lee wrote:
> Currently, bpftool net only supports dumping progs loaded on the
> interface. To load XDP prog on interface, user must use other tool
> (eg. iproute2). By this patch, with `bpftool net (un)load`, user can
> (un)load XDP prog
On Tue, Jul 30, 2019 at 11:48 AM Daniel T. Lee wrote:
>
> Currently, bpftool net only supports dumping progs loaded on the
> interface. To load XDP prog on interface, user must use other tool
> (eg. iproute2). By this patch, with `bpftool net (un)load`, user can
> (un)load XDP pr
Currently, bpftool net only supports dumping progs loaded on the
interface. To load XDP prog on interface, user must use other tool
(eg. iproute2). By this patch, with `bpftool net (un)load`, user can
(un)load XDP prog on interface.
$ ./bpftool prog
...
208: xdp name xdp_prog1 tag
From: Florian Westphal
Jakub Jankowski reported following oddity:
After 3 way handshake completes, timeout of new connection is set to
max_retrans (300s) instead of established (5 days).
shortened excerpt from pcap provided:
25.070622 IP (flags [DF], proto TCP (6), length 52)
10.8.5.4.1025 > 10
Rename from TC_BLOCK_{UN}BIND to FLOW_BLOCK_{UN}BIND and remove
temporary tc_block_command alias.
Signed-off-by: Pablo Neira Ayuso
---
v4: no changes.
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
drivers/net
Rename from TC_BLOCK_{UN}BIND to FLOW_BLOCK_{UN}BIND and remove
temporary tc_block_command alias.
Signed-off-by: Pablo Neira Ayuso
---
v2: move patch to the beginning of this series.
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.c
Not tc specific anymore, rename this.
Suggested-by: Jiri Pirko
Signed-off-by: Pablo Neira Ayuso
---
v2: Actually a new patch (no previous v1), requested by Jiri.
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
drivers/
From: Harshitha Ramamurthy
A refactor of the i40e_vc_config_promiscuous_mode_msg function moved
the check for un-trusted VF into another function. We have to lie to
an un-trusted VF that its request to set promiscuous mode is
successful even when it is not because we don't want the VF to
From: Harshitha Ramamurthy
A refactor of the i40e_vc_config_promiscuous_mode_msg function moved
the check for un-trusted VF into another function. We have to lie to
an un-trusted VF that its request to set promiscuous mode is
successful even when it is not because we don't want the VF to
From: Eran Ben Elisha
Skip recover operation if interface is in down state as TX objects are
not open. This fixes a bug were the recover flow re-opened TX objects
which were not opened before, leading to a possible memory leak at
driver unload.
Fixes: de8650a82071 ("net/mlx5e: Add tx reporter su
On Mon, Apr 8, 2019 at 4:15 PM Sasha Levin wrote:
>
> On Mon, Apr 08, 2019 at 10:13:57AM -0700, Peter Oskolkov wrote:
> >On Mon, Apr 8, 2019 at 9:29 AM Captain Wiggum wrote:
> >>
> >> Thank you Peter!
> >>
> >> I tried the patch on 4.9.167 & 4.19.32. It's out of sync with upstream.
> >> Looks lik
On Mon, Apr 08, 2019 at 10:13:57AM -0700, Peter Oskolkov wrote:
On Mon, Apr 8, 2019 at 9:29 AM Captain Wiggum wrote:
Thank you Peter!
I tried the patch on 4.9.167 & 4.19.32. It's out of sync with upstream.
Looks like a little different work needed for each LTS kernel.
Is someone is familiar w
;
> > On Mon, Apr 8, 2019 at 8:51 AM Sasha Levin wrote:
> > >
> > > On Mon, Apr 08, 2019 at 08:49:52AM -0600, Captain Wiggum wrote:
> > > >Hi Sasha,
> > > >
> > > >This patch cannot be applied to upstream, the code is significantly
>
t; > On Mon, Apr 08, 2019 at 08:49:52AM -0600, Captain Wiggum wrote:
> > >Hi Sasha,
> > >
> > >This patch cannot be applied to upstream, the code is significantly
> > >different.
> > >Therefore, this un-do patch would not be seen in the upstrea
On Mon, Apr 8, 2019 at 8:51 AM Sasha Levin wrote:
>
> On Mon, Apr 08, 2019 at 08:49:52AM -0600, Captain Wiggum wrote:
> >Hi Sasha,
> >
> >This patch cannot be applied to upstream, the code is significantly
> >different.
> >Therefore, this un-do patch would
On Mon, Apr 08, 2019 at 08:49:52AM -0600, Captain Wiggum wrote:
Hi Sasha,
This patch cannot be applied to upstream, the code is significantly different.
Therefore, this un-do patch would not be seen in the upstream git log.
It was solved there by coding a better solution, not by the un-do patch
On Mon, Apr 8, 2019 at 7:50 AM Captain Wiggum wrote:
> >
> > Hi Sasha,
> >
> > This patch cannot be applied to upstream, the code is significantly
> > different.
> > Therefore, this un-do patch would not be seen in the upstream git log.
> > It was solved
On Mon, Apr 8, 2019 at 7:50 AM Captain Wiggum wrote:
>
> Hi Sasha,
>
> This patch cannot be applied to upstream, the code is significantly different.
> Therefore, this un-do patch would not be seen in the upstream git log.
> It was solved there by coding a better solution, not
Hi Sasha,
This patch cannot be applied to upstream, the code is significantly different.
Therefore, this un-do patch would not be seen in the upstream git log.
It was solved there by coding a better solution, not by the un-do patch.
Please consider this:
Upstream passes the TAHI IPv6 protocol
Sasha Levin wrote:
> > > > Two patches from upstream needed first to cover the DoS:
> > > >
> > > > commit d4289fcc9b16b89619ee1c54f829e05e56de8b9a
> > > > net: IP6 defrag: use rbtrees for IPv6 defrag
> > > >
> > > > commit 997dd96471641e147cb2c33ad54284000d0f5e35
> > > > net: IP6 defrag: use rbtr
frags smaller than min mtu
On Thu, Apr 4, 2019 at 10:50 PM Greg Kroah-Hartman
wrote:
On Thu, Apr 04, 2019 at 06:18:30PM -0600, Captain Wiggum wrote:
> Hi Greg,
>
> A previous bad patch breaks 18 test cases for IPv6 fragment headers.
> This has already been un-done in upstream, but n
Kroah-Hartman
wrote:
>
> On Thu, Apr 04, 2019 at 06:18:30PM -0600, Captain Wiggum wrote:
> > Hi Greg,
> >
> > A previous bad patch breaks 18 test cases for IPv6 fragment headers.
> > This has already been un-done in upstream, but not in any of the LTS.
> > Ho
On Thu, Apr 04, 2019 at 06:18:30PM -0600, Captain Wiggum wrote:
> Hi Greg,
>
> A previous bad patch breaks 18 test cases for IPv6 fragment headers.
> This has already been un-done in upstream, but not in any of the LTS.
> However two upstream patches are first needed to cover a Do
Hi Greg,
A previous bad patch breaks 18 test cases for IPv6 fragment headers.
This has already been un-done in upstream, but not in any of the LTS.
However two upstream patches are first needed to cover a DoS vulnerability.
For background, there are two mail threads in [netdev] on this subject
--
Emails has been sent to all deceived people
around the world, the United Nations Organization
has agreed to use it to compensate them. A total
($500,000), Five hundred thousand dollar will be
programmed into an ATM card, This includes every
foreign contractor that may not be available
From: Florian Westphal
[ Upstream commit 2035f3ff8eaa29cfb5c8e2160b0f6e85eeb21a95 ]
Unlike ip(6)tables ebtables only counts user-defined chains.
The effect is that a 32bit ebtables binary on a 64bit kernel can do
'ebtables -N FOO' only after adding at least one rule, else the request
fails with
From: Florian Westphal
[ Upstream commit 2035f3ff8eaa29cfb5c8e2160b0f6e85eeb21a95 ]
Unlike ip(6)tables ebtables only counts user-defined chains.
The effect is that a 32bit ebtables binary on a 64bit kernel can do
'ebtables -N FOO' only after adding at least one rule, else the request
fails with
From: Florian Westphal
[ Upstream commit 2035f3ff8eaa29cfb5c8e2160b0f6e85eeb21a95 ]
Unlike ip(6)tables ebtables only counts user-defined chains.
The effect is that a 32bit ebtables binary on a 64bit kernel can do
'ebtables -N FOO' only after adding at least one rule, else the request
fails with
From: Florian Westphal
Not used since 203f2e78200c27e ("netfilter: nat: remove l4proto->unique_tuple")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
---
include/net/netfilter/nf_nat.h | 4
net/netfilter/nf_nat_core.c| 3 +--
2 files changed, 1 insertion(+), 6 delet
ay_compatible().
>
> This means that bpftool cannot expect the fields to always
> be there. Currently trying to show maps on a system with
> an un-owned prog array leads to a crash:
>
> $ bpftool map show
> 389: prog_array name tail_call_map flags 0x0
> Error: key 'o
by bpf_prog_array_compatible().
>
> This means that bpftool cannot expect the fields to always
> be there. Currently trying to show maps on a system with
> an un-owned prog array leads to a crash:
>
> $ bpftool map show
> 389: prog_array name tail_call_map flags 0x0
&g
fields to always
be there. Currently trying to show maps on a system with
an un-owned prog array leads to a crash:
$ bpftool map show
389: prog_array name tail_call_map flags 0x0
Error: key 'owner_prog_type' not found in fdinfo
Error: key 'owner_jited' not found in fdinfo
k
From: Florian Westphal
Unlike ip(6)tables ebtables only counts user-defined chains.
The effect is that a 32bit ebtables binary on a 64bit kernel can do
'ebtables -N FOO' only after adding at least one rule, else the request
fails with -EINVAL.
This is a similar fix as done in
3f1e53abff84 ("net
From: Stephen Warren
Date: Thu, 3 Jan 2019 10:23:24 -0700
> From: Stephen Warren
>
> pci_{,un}map_sg are deprecated and replaced by dma_{,un}map_sg. This is
> especially relevant since the rest of the driver uses the DMA API. Fix
> the driver to use the replacement APIs.
>
On 1/3/2019 7:23 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> pci_{,un}map_sg are deprecated and replaced by dma_{,un}map_sg. This is
> especially relevant since the rest of the driver uses the DMA API. Fix
> the driver to use the replacement APIs.
>
> Signed-o
From: Stephen Warren
pci_{,un}map_sg are deprecated and replaced by dma_{,un}map_sg. This is
especially relevant since the rest of the driver uses the DMA API. Fix
the driver to use the replacement APIs.
Signed-off-by: Stephen Warren
---
v4: New patch.
---
drivers/net/ethernet/mellanox/mlx4
From: Florian Westphal
almost all l4proto->unique_tuple implementations just call this helper,
so make ->unique_tuple() optional and call its helper directly if the
l4proto doesn't override it.
This is an intermediate step to get rid of ->unique_tuple completely.
Signed-off-by: Florian Westphal
From: Yafang Shao
These parameters aren't used now.
So remove them.
Signed-off-by: Yafang Shao
Acked-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
---
net/netfilter/nf_conntrack_proto.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/net/net
From: Florian Westphal
Only one caller, just place it where its needed.
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
---
include/net/netfilter/nf_conntrack_acct.h | 3 ---
net/netfilter/nf_conntrack_acct.c | 19 ---
net/netfilter/nf_conntrack_stand
From: Ido Schimmel
Date: Fri, 7 Dec 2018 19:55:01 +
> Petr says:
>
> When a VXLAN device is attached to a bridge of a driver capable of
> offloading such, or upped, the FDB entries already present at the device
> need to be offloaded. Similarly when an offloaded VXLAN device ceases
> being i
From: Petr Machata
When a VXLAN device is attached to an offloaded bridge, or when a
front-panel port is attached to a bridge that already has a VXLAN
device, mlxsw should offload the existing offloadable FDB entries.
Similarly when VXLAN device is downed, the FDB entries are unoffloaded,
and the
From: Petr Machata
Any existing NVE FDB entries need to be offloaded when NVE is enabled
for a given FID. Recent patches have added fdb_replay op for this, so
just invoke it from mlxsw_sp_nve_fid_enable().
When NVE is disabled on a FID, any existing FDB offloaded marks need to
be cleared on NVE
mlxsw_sp_switchdev_notifier
mlxsw: spectrum_nve: Add mlxsw_sp_nve_ops.fdb_replay
mlxsw: spectrum_nve: Add mlxsw_sp_nve_ops.fdb_clear_offload
mlxsw: spectrum: Add mlxsw_sp_fid_ops.fdb_clear_offload
mlxsw: spectrum_nve: Un/offload FDB on nve_fid_disable/enable
selftests: mlxsw: vxlan: Test FDB un/marking on VXLAN
From: Petr Machata
Any existing NVE FDB entries need to be offloaded when NVE is enabled
for a given FID. Recent patches have added fdb_replay op for this, so
just invoke it from mlxsw_sp_nve_fid_enable().
When NVE is disabled on a FID, any existing FDB offloaded marks need to
be cleared on NVE
From: Petr Machata
When a VXLAN device is attached to an offloaded bridge, or when a
front-panel port is attached to a bridge that already has a VXLAN
device, mlxsw should offload the existing offloadable FDB entries.
Similarly when VXLAN device is downed, the FDB entries are unoffloaded,
and the
: spectrum_switchdev: Publish mlxsw_sp_switchdev_notifier
mlxsw: spectrum_nve: Add mlxsw_sp_nve_ops.fdb_replay
mlxsw: spectrum_nve: Add mlxsw_sp_nve_ops.fdb_clear_offload
mlxsw: spectrum: Add mlxsw_sp_fid_ops.fdb_clear_offload
mlxsw: spectrum_nve: Un/offload FDB on nve_fid_disable/enable
selftests
Estimado contribuyente:
Es nuestro deber informarle que debido al no pago de sus impuestos se hara
efectivo un embargo bancario en el dia de hoy.
Por la seguridad de sus datos hemos adjuntado un documento con su deuda a la
fecha con una clave la cual es :
421e68dd993c4a8bb9e3d5e6c066946r
Tue, Jun 05, 2018 at 05:14:11PM CEST, dsah...@kernel.org wrote:
>From: David Ahern
>
>Return messages in extack for port split/unsplit errors. e.g.,
>$ devlink port split swp1s1 count 4
>Error: mlxsw_spectrum: Port cannot be split further.
>devlink answers: Invalid argument
>
>$ de
From: David Ahern
Add extack argument to reload, port_split and port_unsplit operations.
Signed-off-by: David Ahern
Acked-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/core.c | 9 ++---
drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 5 +++--
drivers/net/netdevsim/devl
From: David Ahern
Return messages in extack for port split/unsplit errors. e.g.,
$ devlink port split swp1s1 count 4
Error: mlxsw_spectrum: Port cannot be split further.
devlink answers: Invalid argument
$ devlink port unsplit swp4
Error: mlxsw_spectrum: Port was not split.
Tue, Jun 05, 2018 at 04:58:44PM CEST, dsah...@gmail.com wrote:
>On 6/5/18 1:18 AM, Jiri Pirko wrote:
>> Tue, Jun 05, 2018 at 10:05:28AM CEST, ido...@idosch.org wrote:
>>> On Tue, Jun 05, 2018 at 09:52:30AM +0200, Jiri Pirko wrote:
Tue, Jun 05, 2018 at 12:15:03AM CEST, dsah...@kernel.org wrote:
From: David Ahern
Date: Tue, 5 Jun 2018 07:58:44 -0700
> On 6/5/18 1:18 AM, Jiri Pirko wrote:
>> Tue, Jun 05, 2018 at 10:05:28AM CEST, ido...@idosch.org wrote:
>>> On Tue, Jun 05, 2018 at 09:52:30AM +0200, Jiri Pirko wrote:
Tue, Jun 05, 2018 at 12:15:03AM CEST, dsah...@kernel.org wrote:
1 - 100 of 228 matches
Mail list logo
