* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Stephen Hemminger @ 2017-11-30 17:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <1512062799.19682.19.camel@gmail.com>
On Thu, 30 Nov 2017 09:26:39 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> >
> >
> > The problem goes back into the core GSO networking code.
> > Something like this is needed.
> >
> > static inline bool netif_needs_gso(struct sk_buff *skb,
> > const struct net_device *dev,
> > netdev_features_t features)
> > {
> > return skb_is_gso(skb) &&
> > (!skb_gso_ok(skb, features) ||
> > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > >gso_max_segs) || << new
> > unlikely(skb_shinfo(skb)->gso_size > dev-
> > >gso_max_size) || << new
> > unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > }
> >
> > What that will do is split up the monster GSO packets if they ever
> > bleed
> > across from one device to another through the twisty mazes of packet
> > processing paths.
>
>
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()
Agreed, we could do it there.
^ permalink raw reply
* Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: David Miller @ 2017-11-30 17:34 UTC (permalink / raw)
To: bhaskar.upadhaya; +Cc: andrew, netdev, linux-arm-kernel
In-Reply-To: <AM3PR04MB4494050122E413E2445BD348C380@AM3PR04MB449.eurprd04.prod.outlook.com>
From: Bhaskar Upadhaya <bhaskar.upadhaya@nxp.com>
Date: Thu, 30 Nov 2017 17:16:48 +0000
> Hi Andrew,
> Please find answer in lined.
...
> Is auto negotiation not supported in 2.5G SGMII in general, or just in the system you are using? Is it the PHY or the MAC which does not support it.
> [bhaskar] 2.5G in general needs to operate with auto negotiation in disabled mode. Its 2.5G requirement and not specific to our system.
> Are we going to get into trouble if we find an 2.5G SGMII link which does negotiate?
This is completely unreadable. Please do not respond to quoted
material this way, you are making more work for the people trying to
help you.
Proper quoting looks like this:
====================
> Quoted material.
> More quoted material.
Things you are saying in response.
====================
Thank you.
^ permalink raw reply
* Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Russell King - ARM Linux @ 2017-11-30 17:33 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Bhaskar Upadhaya, netdev, davem, linux-arm-kernel
In-Reply-To: <20171130155050.GD7483@lunn.ch>
On Thu, Nov 30, 2017 at 04:50:50PM +0100, Andrew Lunn wrote:
> On Thu, Nov 30, 2017 at 10:00:35AM +0530, Bhaskar Upadhaya wrote:
> > Add 2.5G SGMII interface mode(PHY_INTERFACE_MODE_2500SGMII)
> > in existing phy_interface list.As auto-negotiation is not
> > supported for 2.5G SGMII
>
> Hi Bhaskar
>
> I've been thinking about this some more...
>
> Is auto negotiation not supported in 2.5G SGMII in general, or just in
> the system you are using? Is it the PHY or the MAC which does not
> support it. Are we going to get into trouble if we find an 2.5G SGMII
> link which does negotiate?
I've been doing some research on this 2.5G SGMII "thing", and what
I've found so far (from Xilinx, I haven't been able to look through
anything else yet) is that at least Xilinx do the same thing.
There's a Xilinx document (pg047-gig-eth-pcs-pma.pdf) which says
throughout that the speed bits are not applicable for 2.5G SGMII.
Speeds > 1G appear to be defined only for full duplex (since the
latency through the PHY is too great for CDMA half-duplex to work.)
So, the duplex bits in SGMII would be meaningless for >1G. Many
MACs, incidentally, do not support half-duplex at 1G speeds either.
That just leaves pause mode in the SGMII word.
> My understanding is that one of the main differences between SGMII and
> 1000BASE-X is the negotiation.
True. 1000BASE-X is an 802.3 standard, with the configuration word
defined by IEEE. SGMII is derived from that by Cisco, but with the
configuration word replaced by a system whereby the PHY can inform
the MAC about the results of negotiation.
SGMII has a handshake so the PHY knows that the MAC has configured
itself, and some PHYs will not pass data until that handshake has
completed.
I suspect for 2.5G SGMII, I would expect that the handshake also has
to complete, so the PHY knows that the pause modes have been properly
received by the MAC.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level
From: David Miller @ 2017-11-30 17:31 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev, dhowells
In-Reply-To: <c661975b1c2987416f8e1bbd6926723bd557926d.1512058820.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 30 Nov 2017 08:21:14 -0800
> When enabled, the current debug logging does not have a KERN_<LEVEL>.
> Add KERN_DEBUG to the logging macros.
>
> Miscellanea:
>
> o Remove #define redundancy and neaten the macros a bit
>
> Signed-off-by: Joe Perches <joe@perches.com>
Please also CC: the proper mailing list and maintainer for rxrpc.
The MAINTAINERS entry for rxrpc needs to include more than just
net/rxrpc/af_rxrpc.c, David please fix this up as I know Joe is going
to use the excuse that he didn't CC: you and the AFS list because of
this.
Thanks.
^ permalink raw reply
* Re: [BUG] kernel stack corruption during/after Netlabel error
From: David Ahern @ 2017-11-30 17:30 UTC (permalink / raw)
To: Eric Dumazet, Casey Schaufler, James Morris
Cc: Paul Moore, netdev, Stephen Smalley, selinux, LSM
In-Reply-To: <b92c6b3d-5c7e-9859-4bb2-b1a0aa64d86b@gmail.com>
On 11/30/17 8:44 AM, David Ahern wrote:
> On 11/30/17 3:50 AM, Eric Dumazet wrote:
>> @@ -1631,24 +1659,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
>>
>> th = (const struct tcphdr *)skb->data;
>> iph = ip_hdr(skb);
>> - /* This is tricky : We move IPCB at its correct location into TCP_SKB_CB()
>> - * barrier() makes sure compiler wont play fool^Waliasing games.
>> - */
>> - memmove(&TCP_SKB_CB(skb)->header.h4, IPCB(skb),
>> - sizeof(struct inet_skb_parm));
>> - barrier();
>> -
>> - TCP_SKB_CB(skb)->seq = ntohl(th->seq);
>> - TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
>> - skb->len - th->doff * 4);
>> - TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
>> - TCP_SKB_CB(skb)->tcp_flags = tcp_flag_byte(th);
>> - TCP_SKB_CB(skb)->tcp_tw_isn = 0;
>> - TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
>> - TCP_SKB_CB(skb)->sacked = 0;
>> - TCP_SKB_CB(skb)->has_rxtstamp =
>> - skb->tstamp || skb_hwtstamps(skb)->hwtstamp;
>> -
>> lookup:
>> sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source,
>> th->dest, sdif, &refcounted);
>
> I believe moving the above is going to affect lookups with VRF. Let me
> take a look before this gets committed.
>
Eric:
Can you add this to the patch? Fixes socket lookups with VRF which
stashes a flag in the cb.
Thanks,
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 4e09398009c1..6c020015d556 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -849,7 +849,7 @@ static inline bool inet_exact_dif_match(struct net
*net, struct sk_buff *skb)
{
#if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
if (!net->ipv4.sysctl_tcp_l3mdev_accept &&
- skb && ipv4_l3mdev_skb(TCP_SKB_CB(skb)->header.h4.flags))
+ skb && ipv4_l3mdev_skb(IPCB(skb)->flags))
return true;
#endif
return false;
^ permalink raw reply related
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2017-11-30 17:29 UTC (permalink / raw)
To: jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1512058396-15907-1-git-send-email-jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Date: Thu, 30 Nov 2017 21:43:16 +0530
> + priv->eeprom_base = devm_memremap(&pdev->dev, eeprom_res->start,
> + resource_size(eeprom_res),
> + MEMREMAP_WT);
> + if (!priv->eeprom_base) {
> + dev_err(&pdev->dev, "devm_memremap() failed for EEPROM\n");
> + ret = -ENXIO;
> + goto free_ndev;
> + }
dev_memremap() is implemented via memremap() which for MEMREMAP_WT is
in turn implemented using ioremap_wt() which returns an "__iomem"
pointer.
The memremap() function talks about __iomem being about side effects.
That's not really the full story. The __iomem annotation is also
about whether a special accessor is necessary to "dereference" the
pointer. On sparc64, for example, the ioremap_*() functions return a
physical address not a virtual one. So you cannot directly
dereference pointers that are returned from the ioremap*() interfaces.
You'll also need to mark priv->eeprom_base as "__iomem".
devm_memremap() returns a straight "void *" without the __iomem
annotation, and this is wrong then ioremap_*() is used.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Daniel Borkmann @ 2017-11-30 17:27 UTC (permalink / raw)
To: Yonghong Song, peterz, rostedt, ast, kafai, netdev; +Cc: kernel-team
In-Reply-To: <20171129072036.467246-2-yhs@fb.com>
On 11/29/2017 08:20 AM, Yonghong Song wrote:
> Commit e87c6bc3852b ("bpf: permit multiple bpf attachments
> for a single perf event") added support to attach multiple
> bpf programs to a single perf event.
> Commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes") utilized the existing perf ioctl
> interface and added the command PERF_EVENT_IOC_SET_BPF
> to attach a bpf program to a tracepoint.
>
> This patch adds a new ioctl
> command, given a perf event fd, to query the bpf program array
> attached to the same perf tracepoint event.
>
> The new uapi ioctl command:
> PERF_EVENT_IOC_QUERY_BPF
>
> The new uapi/linux/perf_event.h structure:
> struct perf_event_query_bpf {
> __u64 prog_ids;
> __u32 prog_cnt;
> };
>
> The usage:
> struct perf_event_query_bpf query;
> query.prog_ids = (__u64)usr_prog_ids_buf;
> query.prog_cnt = usr_prog_ids_buf_len;
> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> include/linux/bpf.h | 4 ++++
> include/uapi/linux/perf_event.h | 6 ++++++
> kernel/bpf/core.c | 24 ++++++++++++++++++++++++
> kernel/events/core.c | 3 +++
> kernel/trace/bpf_trace.c | 23 +++++++++++++++++++++++
> 5 files changed, 60 insertions(+)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index e55e425..f812ac5 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -254,6 +254,7 @@ typedef unsigned long (*bpf_ctx_copy_t)(void *dst, const void *src,
>
> u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
> void *ctx, u64 ctx_size, bpf_ctx_copy_t ctx_copy);
> +int bpf_event_query_prog_array(struct perf_event *event, void __user *info);
>
> int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
> union bpf_attr __user *uattr);
> @@ -285,6 +286,9 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
>
> void bpf_prog_array_delete_safe(struct bpf_prog_array __rcu *progs,
> struct bpf_prog *old_prog);
> +int bpf_prog_array_copy_info(struct bpf_prog_array __rcu *array,
> + __u32 __user *prog_ids, u32 request_cnt,
> + __u32 __user *prog_cnt);
> int bpf_prog_array_copy(struct bpf_prog_array __rcu *old_array,
> struct bpf_prog *exclude_prog,
> struct bpf_prog *include_prog,
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index b9a4953..fee0b43 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -418,6 +418,11 @@ struct perf_event_attr {
> __u16 __reserved_2; /* align to __u64 */
> };
>
> +struct perf_event_query_bpf {
> + __u64 prog_ids;
> + __u32 prog_cnt;
> +};
> +
> #define perf_flags(attr) (*(&(attr)->read_format + 1))
>
> /*
> @@ -433,6 +438,7 @@ struct perf_event_attr {
> #define PERF_EVENT_IOC_ID _IOR('$', 7, __u64 *)
> #define PERF_EVENT_IOC_SET_BPF _IOW('$', 8, __u32)
> #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> +#define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
>
> enum perf_event_ioc_flags {
> PERF_IOC_FLAG_GROUP = 1U << 0,
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index b9f8686..40e3b8d 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1461,6 +1461,8 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
> rcu_read_lock();
> prog = rcu_dereference(progs)->progs;
> for (; *prog; prog++) {
> + if (*prog == &dummy_bpf_prog.prog)
> + continue;
> id = (*prog)->aux->id;
> if (copy_to_user(prog_ids + i, &id, sizeof(id))) {
> rcu_read_unlock();
> @@ -1544,6 +1546,28 @@ int bpf_prog_array_copy(struct bpf_prog_array __rcu *old_array,
> return 0;
> }
>
> +int bpf_prog_array_copy_info(struct bpf_prog_array __rcu *array,
> + __u32 __user *prog_ids, u32 request_cnt,
> + __u32 __user *prog_cnt)
> +{
> + struct bpf_prog **prog;
> + u32 cnt = 0;
> +
> + if (array) {
> + for (prog = array->progs; *prog; prog++)
> + if (*prog != &dummy_bpf_prog.prog)
> + cnt++;
> + }
> +
> + if (copy_to_user(prog_cnt, &cnt, sizeof(cnt)))
> + return -EFAULT;
> +
> + if (cnt == 0)
> + return 0;
One minor thing I still noticed in bpf_prog_array_copy_info() was
that potentially we could return 0 as well if request_cnt was 0 if
users only want to query if progs are present (resp. how many attached)
but don't care which ones.
Otherwise, in bpf_prog_array_copy_to_user() it tries to copy as much
prog ids as present if request_cnt == 0. Can we handle this in user
space e.g. by having an exposed max upper limit where user space can
define the prog id array with?
> + return bpf_prog_array_copy_to_user(array, prog_ids, request_cnt);
> +}
> +
> static void bpf_prog_free_deferred(struct work_struct *work)
> {
> struct bpf_prog_aux *aux;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 9404c63..93aec2c 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4723,6 +4723,9 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
> rcu_read_unlock();
> return 0;
> }
> +
> + case PERF_EVENT_IOC_QUERY_BPF:
> + return bpf_event_query_prog_array(event, (void __user *)arg);
> default:
> return -ENOTTY;
> }
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 27d1f4f..7fb7f74 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -812,3 +812,26 @@ void perf_event_detach_bpf_prog(struct perf_event *event)
> unlock:
> mutex_unlock(&bpf_event_mutex);
> }
> +
> +int bpf_event_query_prog_array(struct perf_event *event, void __user *info)
> +{
> + struct perf_event_query_bpf __user *uquery = info;
> + struct perf_event_query_bpf query = {};
> + int ret;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + if (event->attr.type != PERF_TYPE_TRACEPOINT)
> + return -EINVAL;
> + if (copy_from_user(&query, uquery, sizeof(query)))
> + return -EFAULT;
> +
> + mutex_lock(&bpf_event_mutex);
> + ret = bpf_prog_array_copy_info(event->tp_event->prog_array,
> + u64_to_user_ptr(query.prog_ids),
> + query.prog_cnt,
> + &uquery->prog_cnt);
> + mutex_unlock(&bpf_event_mutex);
> +
> + return ret;
> +}
>
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Eric Dumazet @ 2017-11-30 17:26 UTC (permalink / raw)
To: Stephen Hemminger, Solio Sarabia
Cc: David Ahern, davem, netdev, sthemmin, shiny.sebastian
In-Reply-To: <20171130091021.658869b0@xeon-e3>
On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
>
>
> The problem goes back into the core GSO networking code.
> Something like this is needed.
>
> static inline bool netif_needs_gso(struct sk_buff *skb,
> const struct net_device *dev,
> netdev_features_t features)
> {
> return skb_is_gso(skb) &&
> (!skb_gso_ok(skb, features) ||
> unlikely(skb_shinfo(skb)->gso_segs > dev-
> >gso_max_segs) || << new
> unlikely(skb_shinfo(skb)->gso_size > dev-
> >gso_max_size) || << new
> unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> }
>
> What that will do is split up the monster GSO packets if they ever
> bleed
> across from one device to another through the twisty mazes of packet
> processing paths.
Since very few drivers have these gso_max_segs / gso_max_size, check
could be done in their ndo_features_check()
^ permalink raw reply
* Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()
From: Serge E. Hallyn @ 2017-11-30 17:17 UTC (permalink / raw)
To: Theodore Ts'o, Serge E. Hallyn, David Miller, gnomes,
keescook, mcgrof, tixxdz, luto, akpm, james.l.morris,
ben.hutchings, solar, jeyu, rusty, linux-kernel,
linux-security-module, kernel-hardening, corbet, mingo, netdev,
peterz, torvalds
In-Reply-To: <20171130003531.gwpl22bxmweifjz2@thunk.org>
On Wed, Nov 29, 2017 at 07:35:31PM -0500, Theodore Ts'o wrote:
> On Wed, Nov 29, 2017 at 11:28:52AM -0600, Serge E. Hallyn wrote:
> >
> > Just to be clear, module loading requires - and must always continue to
> > require - CAP_SYS_MODULE against the initial user namespace. Containers
> > in user namespaces do not have that.
> >
> > I don't believe anyone has ever claimed that containers which are not in
> > a user namespace are in any way secure.
>
> Unless the container performs some action which causes the kernel to
> call request_module(), which then loads some kernel module,
A local unprivileged user can do the same thing. I reject the popular
notion that linux is a single user operating system. More interesting
are the (very real) cases where root in a container can do something
which a local unprivileged user could not do. Since a local unprivileged
user can always create a new namespace, *those* constitute a real and
interesting problem.
> potentially containing cr*p unmaintained code which was included when
> the distro compiled the world, into the host kernel.
> This is an attack vector that doesn't exist if you are using VM's.
Until the vm tenant uses a trivial vm escape.
> And in general, the attack surface of the entire Linux
> kernel<->userspace API is far larger than that which is exposed by the
> guest<->host interface.
>
> For that reason, containers are *far* more insecure than VM's, since
> once the attacker gets root on the guest VM, they then have to attack
> the hypervisor interface. And if you compare the attack surface of
> the two, it's pretty clear which is larger, and it's not the
> hypervisor interface.
Any time anyone spends a day looking at either the black hole that is
the hardware emulators or the xen and kvm code itself they walk away
with a set of cve's. It *should* be more secure, it's not. You're
telling me your house is safe because you put up a no tresspassing
sign.
-serge
^ permalink raw reply
* RE: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Bhaskar Upadhaya @ 2017-11-30 17:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171130155050.GD7483@lunn.ch>
Hi Andrew,
Please find answer in lined.
Regards
--Bhaskar
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Thursday, November 30, 2017 9:21 PM
To: Bhaskar Upadhaya <bhaskar.upadhaya@nxp.com>
Cc: netdev@vger.kernel.org; davem@davemloft.net; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
On Thu, Nov 30, 2017 at 10:00:35AM +0530, Bhaskar Upadhaya wrote:
> Add 2.5G SGMII interface mode(PHY_INTERFACE_MODE_2500SGMII)
> in existing phy_interface list.As auto-negotiation is not supported
> for 2.5G SGMII
Hi Bhaskar
I've been thinking about this some more...
Is auto negotiation not supported in 2.5G SGMII in general, or just in the system you are using? Is it the PHY or the MAC which does not support it.
[bhaskar] 2.5G in general needs to operate with auto negotiation in disabled mode. Its 2.5G requirement and not specific to our system.
Are we going to get into trouble if we find an 2.5G SGMII link which does negotiate?
My understanding is that one of the main differences between SGMII and 1000BASE-X is the negotiation.
[Bhaskar] which of SGMII and 1000BASE-X support negotiation ?
Andrew
^ permalink raw reply
* Re: [PATCH RFC 0/2] veth, bridge, and GSO maximums
From: Stephen Hemminger @ 2017-11-30 17:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sthemmin
In-Reply-To: <20171130.104721.823106331151241632.davem@davemloft.net>
On Thu, 30 Nov 2017 10:47:21 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Sun, 26 Nov 2017 10:17:47 -0800
>
> > This pair of patchesimproves the performance when running
> > containers in an environment where underlying device has lower
> > GSO maximum (such as Azure).
> >
> > With containers a veth pair is created and one end is attached
> > to the bridge device. The bridge device correctly reports
> > computes GSO parameters that are the minimum of the lower devices.
> >
> > The problem is that the other end of the veth device (in container)
> > reports the full GSO size. This patch propogates the upper
> > (bridge device) parameters to the other end of the veth device.
> >
> > Please consider it as alternative to the sysfs GSO changes.
>
> I like this approach a lot, please resubmit this formally.
Will do and add netif_needs_gso check as well.
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Stephen Hemminger @ 2017-11-30 17:10 UTC (permalink / raw)
To: Solio Sarabia; +Cc: David Ahern, davem, netdev, sthemmin, shiny.sebastian
In-Reply-To: <20171130003534.GA60@intel.com>
On Wed, 29 Nov 2017 16:35:37 -0800
Solio Sarabia <solio.sarabia@intel.com> wrote:
> On Mon, Nov 27, 2017 at 07:02:01PM -0700, David Ahern wrote:
> > On 11/27/17 6:42 PM, Solio Sarabia wrote:
> > > Adding ioctl support for 'ip link set' would work. I'm still concerned
> > > how to enforce the upper limit to not exceed that of the lower devices.
> > >
> Actually, giving the user control to change gso doesn't solve the issue.
> In a VM, user could simple ignore setting the gso, still hurting host
> perf. We need to enforce the lower gso on the bridge/veth.
>
> Should this issue be fixed at hv_netvsc level? Why is the driver passing
> down gso buffer sizes greater than what synthetic interface allows.
>
> > > Consider a system with three NICs, each reporting values in the range
> > > [60,000 - 62,780]. Users could set virtual interfaces' gso to 65,536,
> > > exceeding the limit, and having the host do sw gso (vms settings must
> > > not affect host performance.)
> > >
> > > Looping through interfaces? With the difference that now it'd be
> > > trigger upon user's request, not every time a veth is created (like one
> > > previous patch discussed.)
> > >
> >
> > You are concerned about the routed case right? One option is to have VRF
> > devices propagate gso sizes to all devices (veth, vlan, etc) enslaved to
> > it. VRF devices are Layer 3 master devices so an L3 parallel to a bridge.
> Having the VRF device propagate the gso to its slaves is opposite of
> what we do now: get minimum of all ports and assign it to bridge
> (net/bridge/br_if.c, br_min_mtu, br_set_gso_limits.)
>
> Would it be right to change the logic flow? If so, this this could work:
>
> (1) bridge gets gso from lower devices upon init/setup
> (2) when new device is attached to bridge, bridge sets gso for this new
> slave (and its peer if it's veth.)
> (3) as the code is now, there's an optimization opportunity: for every
> new interface attached to bridge, bridge loops through all ports to
> set gso, mtu. It's not necessary as bridge already has the minimum
> from previous interfaces attached. Could be O(1) instead of O(n).
The problem goes back into the core GSO networking code.
Something like this is needed.
static inline bool netif_needs_gso(struct sk_buff *skb,
const struct net_device *dev,
netdev_features_t features)
{
return skb_is_gso(skb) &&
(!skb_gso_ok(skb, features) ||
unlikely(skb_shinfo(skb)->gso_segs > dev->gso_max_segs) || << new
unlikely(skb_shinfo(skb)->gso_size > dev->gso_max_size) || << new
unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
(skb->ip_summed != CHECKSUM_UNNECESSARY)));
}
What that will do is split up the monster GSO packets if they ever bleed
across from one device to another through the twisty mazes of packet
processing paths.
^ permalink raw reply
* [PATCH net-next] samples/bpf: Convert magic numbers to names in multi-prog cgroup test case
From: David Ahern @ 2017-11-30 17:02 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, David Ahern
Attach flag 1 == BPF_F_ALLOW_OVERRIDE; attach flag 2 == BPF_F_ALLOW_MULTI.
Update the calls to bpf_prog_attach() in test_cgrp2_attach2.c to use the
names over the magic numbers.
Fixes: 39323e788cb67 ("samples/bpf: add multi-prog cgroup test case")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
samples/bpf/test_cgrp2_attach2.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/samples/bpf/test_cgrp2_attach2.c b/samples/bpf/test_cgrp2_attach2.c
index 3e8232cc04a8..1af412ec6007 100644
--- a/samples/bpf/test_cgrp2_attach2.c
+++ b/samples/bpf/test_cgrp2_attach2.c
@@ -78,7 +78,8 @@ static int test_foo_bar(void)
if (join_cgroup(FOO))
goto err;
- if (bpf_prog_attach(drop_prog, foo, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(drop_prog, foo, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to /foo");
goto err;
}
@@ -97,7 +98,8 @@ static int test_foo_bar(void)
printf("Attached DROP prog. This ping in cgroup /foo/bar should fail...\n");
assert(system(PING_CMD) != 0);
- if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to /foo/bar");
goto err;
}
@@ -114,7 +116,8 @@ static int test_foo_bar(void)
"This ping in cgroup /foo/bar should fail...\n");
assert(system(PING_CMD) != 0);
- if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to /foo/bar");
goto err;
}
@@ -128,7 +131,8 @@ static int test_foo_bar(void)
"This ping in cgroup /foo/bar should pass...\n");
assert(system(PING_CMD) == 0);
- if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to /foo/bar");
goto err;
}
@@ -161,13 +165,15 @@ static int test_foo_bar(void)
goto err;
}
- if (!bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (!bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
errno = 0;
log_err("Unexpected success attaching overridable prog to /foo/bar");
goto err;
}
- if (!bpf_prog_attach(allow_prog, foo, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (!bpf_prog_attach(allow_prog, foo, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
errno = 0;
log_err("Unexpected success attaching overridable prog to /foo");
goto err;
@@ -273,27 +279,33 @@ static int test_multiprog(void)
if (join_cgroup("/cg1/cg2/cg3/cg4/cg5"))
goto err;
- if (bpf_prog_attach(allow_prog[0], cg1, BPF_CGROUP_INET_EGRESS, 2)) {
+ if (bpf_prog_attach(allow_prog[0], cg1, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_MULTI)) {
log_err("Attaching prog to cg1");
goto err;
}
- if (!bpf_prog_attach(allow_prog[0], cg1, BPF_CGROUP_INET_EGRESS, 2)) {
+ if (!bpf_prog_attach(allow_prog[0], cg1, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_MULTI)) {
log_err("Unexpected success attaching the same prog to cg1");
goto err;
}
- if (bpf_prog_attach(allow_prog[1], cg1, BPF_CGROUP_INET_EGRESS, 2)) {
+ if (bpf_prog_attach(allow_prog[1], cg1, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_MULTI)) {
log_err("Attaching prog2 to cg1");
goto err;
}
- if (bpf_prog_attach(allow_prog[2], cg2, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(allow_prog[2], cg2, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to cg2");
goto err;
}
- if (bpf_prog_attach(allow_prog[3], cg3, BPF_CGROUP_INET_EGRESS, 2)) {
+ if (bpf_prog_attach(allow_prog[3], cg3, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_MULTI)) {
log_err("Attaching prog to cg3");
goto err;
}
- if (bpf_prog_attach(allow_prog[4], cg4, BPF_CGROUP_INET_EGRESS, 1)) {
+ if (bpf_prog_attach(allow_prog[4], cg4, BPF_CGROUP_INET_EGRESS,
+ BPF_F_ALLOW_OVERRIDE)) {
log_err("Attaching prog to cg4");
goto err;
}
--
2.14.1
^ permalink raw reply related
* Re: [BUG] kernel stack corruption during/after Netlabel error
From: Paul Moore @ 2017-11-30 16:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Casey Schaufler, James Morris, netdev, Stephen Smalley, selinux,
LSM
In-Reply-To: <CAHC9VhT5WAwBz2bo8OQ6WYQ237=BH48XkAhta77n6HTnAq3fbA@mail.gmail.com>
On Thu, Nov 30, 2017 at 7:47 AM, Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Nov 30, 2017 at 5:50 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Wed, 2017-11-29 at 19:16 -0800, Casey Schaufler wrote:
>>> On 11/29/2017 4:31 PM, James Morris wrote:
>>> > On Wed, 29 Nov 2017, Casey Schaufler wrote:
>>> >
>>> > > I see that there is a proposed fix later in the thread, but I
>>> > > don't see
>>> > > the patch. Could you send it to me, so I can try it on my
>>> > > problem?
>>> >
>>> > Forwarded off-list.
>>>
>>> The patch does fix the problem I was seeing in Smack.
>>
>> Can you guys test the following more complete patch ?
>>
>> It should cover IPv4 and IPv6, and also the corner cases.
>>
>> ( Note that I squashed ipv6 fix in https://patchwork.ozlabs.org/patch/8
>> 42844/ that I spotted while cooking this patch )
>
> Building a test kernel now, although it make take me a few hours to
> test it due to some commitments this morning.
I just realized I forgot to enable KASAN in the build, but I can
verify that the patch doesn't break anything in the selinux-testsuite.
Tested-by: Paul Moore <paul@paul-moore.com>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index c6bc0c4d19c624888b0d0b5a4246c7183edf63f5..77ea45da0fe9c746907a312989658af3ad3b198d 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -1591,6 +1591,34 @@ int tcp_filter(struct sock *sk, struct sk_buff *skb)
>> }
>> EXPORT_SYMBOL(tcp_filter);
>>
>> +static void tcp_v4_restore_cb(struct sk_buff *skb)
>> +{
>> + memmove(IPCB(skb), &TCP_SKB_CB(skb)->header.h4,
>> + sizeof(struct inet_skb_parm));
>> +}
>> +
>> +static void tcp_v4_fill_cb(struct sk_buff *skb, const struct iphdr *iph,
>> + const struct tcphdr *th)
>> +{
>> + /* This is tricky : We move IPCB at its correct location into TCP_SKB_CB()
>> + * barrier() makes sure compiler wont play fool^Waliasing games.
>> + */
>> + memmove(&TCP_SKB_CB(skb)->header.h4, IPCB(skb),
>> + sizeof(struct inet_skb_parm));
>> + barrier();
>> +
>> + TCP_SKB_CB(skb)->seq = ntohl(th->seq);
>> + TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
>> + skb->len - th->doff * 4);
>> + TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
>> + TCP_SKB_CB(skb)->tcp_flags = tcp_flag_byte(th);
>> + TCP_SKB_CB(skb)->tcp_tw_isn = 0;
>> + TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
>> + TCP_SKB_CB(skb)->sacked = 0;
>> + TCP_SKB_CB(skb)->has_rxtstamp =
>> + skb->tstamp || skb_hwtstamps(skb)->hwtstamp;
>> +}
>> +
>> /*
>> * From tcp_input.c
>> */
>> @@ -1631,24 +1659,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
>>
>> th = (const struct tcphdr *)skb->data;
>> iph = ip_hdr(skb);
>> - /* This is tricky : We move IPCB at its correct location into TCP_SKB_CB()
>> - * barrier() makes sure compiler wont play fool^Waliasing games.
>> - */
>> - memmove(&TCP_SKB_CB(skb)->header.h4, IPCB(skb),
>> - sizeof(struct inet_skb_parm));
>> - barrier();
>> -
>> - TCP_SKB_CB(skb)->seq = ntohl(th->seq);
>> - TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
>> - skb->len - th->doff * 4);
>> - TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
>> - TCP_SKB_CB(skb)->tcp_flags = tcp_flag_byte(th);
>> - TCP_SKB_CB(skb)->tcp_tw_isn = 0;
>> - TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
>> - TCP_SKB_CB(skb)->sacked = 0;
>> - TCP_SKB_CB(skb)->has_rxtstamp =
>> - skb->tstamp || skb_hwtstamps(skb)->hwtstamp;
>> -
>> lookup:
>> sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source,
>> th->dest, sdif, &refcounted);
>> @@ -1679,14 +1689,19 @@ int tcp_v4_rcv(struct sk_buff *skb)
>> sock_hold(sk);
>> refcounted = true;
>> nsk = NULL;
>> - if (!tcp_filter(sk, skb))
>> + if (!tcp_filter(sk, skb)) {
>> + th = (const struct tcphdr *)skb->data;
>> + iph = ip_hdr(skb);
>> + tcp_v4_fill_cb(skb, iph, th);
>> nsk = tcp_check_req(sk, skb, req, false);
>> + }
>> if (!nsk) {
>> reqsk_put(req);
>> goto discard_and_relse;
>> }
>> if (nsk == sk) {
>> reqsk_put(req);
>> + tcp_v4_restore_cb(skb);
>> } else if (tcp_child_process(sk, nsk, skb)) {
>> tcp_v4_send_reset(nsk, skb);
>> goto discard_and_relse;
>> @@ -1712,6 +1727,7 @@ int tcp_v4_rcv(struct sk_buff *skb)
>> goto discard_and_relse;
>> th = (const struct tcphdr *)skb->data;
>> iph = ip_hdr(skb);
>> + tcp_v4_fill_cb(skb, iph, th);
>>
>> skb->dev = NULL;
>>
>> @@ -1742,6 +1758,8 @@ int tcp_v4_rcv(struct sk_buff *skb)
>> if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
>> goto discard_it;
>>
>> + tcp_v4_fill_cb(skb, iph, th);
>> +
>> if (tcp_checksum_complete(skb)) {
>> csum_error:
>> __TCP_INC_STATS(net, TCP_MIB_CSUMERRORS);
>> @@ -1768,6 +1786,8 @@ int tcp_v4_rcv(struct sk_buff *skb)
>> goto discard_it;
>> }
>>
>> + tcp_v4_fill_cb(skb, iph, th);
>> +
>> if (tcp_checksum_complete(skb)) {
>> inet_twsk_put(inet_twsk(sk));
>> goto csum_error;
>> @@ -1784,6 +1804,7 @@ int tcp_v4_rcv(struct sk_buff *skb)
>> if (sk2) {
>> inet_twsk_deschedule_put(inet_twsk(sk));
>> sk = sk2;
>> + tcp_v4_restore_cb(skb);
>> refcounted = false;
>> goto process;
>> }
>> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
>> index 6bb98c93edfe2ed2f16fe5229605f8108cfc7f9a..1f04ec0e4a7aa2c11b8ee27cbdd4067b5bcf32e5 100644
>> --- a/net/ipv6/tcp_ipv6.c
>> +++ b/net/ipv6/tcp_ipv6.c
>> @@ -1454,7 +1454,6 @@ static int tcp_v6_rcv(struct sk_buff *skb)
>> struct sock *nsk;
>>
>> sk = req->rsk_listener;
>> - tcp_v6_fill_cb(skb, hdr, th);
>> if (tcp_v6_inbound_md5_hash(sk, skb)) {
>> sk_drops_add(sk, skb);
>> reqsk_put(req);
>> @@ -1467,8 +1466,12 @@ static int tcp_v6_rcv(struct sk_buff *skb)
>> sock_hold(sk);
>> refcounted = true;
>> nsk = NULL;
>> - if (!tcp_filter(sk, skb))
>> + if (!tcp_filter(sk, skb)) {
>> + th = (const struct tcphdr *)skb->data;
>> + hdr = ipv6_hdr(skb);
>> + tcp_v6_fill_cb(skb, hdr, th);
>> nsk = tcp_check_req(sk, skb, req, false);
>> + }
>> if (!nsk) {
>> reqsk_put(req);
>> goto discard_and_relse;
>> @@ -1492,8 +1495,6 @@ static int tcp_v6_rcv(struct sk_buff *skb)
>> if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
>> goto discard_and_relse;
>>
>> - tcp_v6_fill_cb(skb, hdr, th);
>> -
>> if (tcp_v6_inbound_md5_hash(sk, skb))
>> goto discard_and_relse;
>>
>> @@ -1501,6 +1502,7 @@ static int tcp_v6_rcv(struct sk_buff *skb)
>> goto discard_and_relse;
>> th = (const struct tcphdr *)skb->data;
>> hdr = ipv6_hdr(skb);
>> + tcp_v6_fill_cb(skb, hdr, th);
>>
>> skb->dev = NULL;
>>
>> @@ -1590,7 +1592,6 @@ static int tcp_v6_rcv(struct sk_buff *skb)
>> tcp_v6_timewait_ack(sk, skb);
>> break;
>> case TCP_TW_RST:
>> - tcp_v6_restore_cb(skb);
>> tcp_v6_send_reset(sk, skb);
>> inet_twsk_deschedule_put(inet_twsk(sk));
>> goto discard_it;
>>
>>
>>
>
>
>
> --
> paul moore
> www.paul-moore.com
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH net-next] tools/bpf: adjust rlimit RLIMIT_MEMLOCK for test_verifier_log
From: Yonghong Song @ 2017-11-30 16:52 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
The default rlimit RLIMIT_MEMLOCK is 64KB. In certain cases,
e.g. in a test machine mimicking our production system, this test may
fail due to unable to charge the required memory for prog load:
# ./test_verifier_log
Test log_level 0...
ERROR: Program load returned: ret:-1/errno:1, expected ret:-1/errno:22
Changing the default rlimit RLIMIT_MEMLOCK to unlimited makes
the test always pass.
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/testing/selftests/bpf/test_verifier_log.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_verifier_log.c b/tools/testing/selftests/bpf/test_verifier_log.c
index 3cc0b56..e9626cf 100644
--- a/tools/testing/selftests/bpf/test_verifier_log.c
+++ b/tools/testing/selftests/bpf/test_verifier_log.c
@@ -3,6 +3,8 @@
#include <stdio.h>
#include <string.h>
#include <unistd.h>
+#include <sys/time.h>
+#include <sys/resource.h>
#include <linux/bpf.h>
#include <linux/filter.h>
@@ -131,11 +133,16 @@ static void test_log_bad(char *log, size_t log_len, int log_level)
int main(int argc, char **argv)
{
+ struct rlimit limit = { RLIM_INFINITY, RLIM_INFINITY };
char full_log[LOG_SIZE];
char log[LOG_SIZE];
size_t want_len;
int i;
+ /* allow unlimited locked memory to have more consistent error code */
+ if (setrlimit(RLIMIT_MEMLOCK, &limit) < 0)
+ perror("Unable to lift memlock rlimit");
+
memset(log, 1, LOG_SIZE);
/* Test incorrect attr */
--
2.9.5
^ permalink raw reply related
* Re: Commit 05cf0d1bf4 ("net: stmmac: free an skb first when there are no longer any descriptors using it") breaks stmmac?
From: Jose Abreu @ 2017-11-30 16:50 UTC (permalink / raw)
To: Niklas Cassel; +Cc: Joao Pinto, linux-netdev, Giuseppe CAVALLARO
In-Reply-To: <20171130035153.GA28231@axis.com>
Hi Niklas,
Thanks for the detailed explanation!
On 30-11-2017 03:51, Niklas Cassel wrote:
>
> Could you try to see if the following patch
> solves your problem:
> (still don't see why it should be needed,
> considering stmmac_tx_clean() should set all non-NULL
> entries to NULL)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 1763e48c84e2..1d30b20b3740 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2830,6 +2830,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
>
> tx_q->tx_skbuff_dma[first_entry].buf = des;
> tx_q->tx_skbuff_dma[first_entry].len = skb_headlen(skb);
> + tx_q->tx_skbuff[first_entry] = NULL;
>
> first->des0 = cpu_to_le32(des);
>
> @@ -3003,6 +3004,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>
> first = desc;
>
> + tx_q->tx_skbuff[first_entry] = NULL;
> +
> enh_desc = priv->plat->enh_desc;
> /* To program the descriptors according to the size of the frame */
> if (enh_desc)
I confirm that applying 05cf0d1bf4 ("net: stmmac: free an skb
first when there are no longer any descriptors using it") and
this patch makes my setup work perfectly in multi-queue
configuration. Can you send an official patch to -net?
You can add my:
Tested-by: Jose Abreu <joabreu@synopsys.com>
Also, maybe we should try to understand why stmmac_tx_clean() is
not setting the entry to NULL?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH 2/3] staging: irda: Handle return value of platform_get_irq
From: arvindY @ 2017-11-30 16:45 UTC (permalink / raw)
To: Greg KH
Cc: devel, lars, Michael.Hennerich, linux-iio, netdev, linux-kernel,
samuel, pmeerw, knaack.h, jic23
In-Reply-To: <20171130164124.GB17869@kroah.com>
Hi Greg,
On Thursday 30 November 2017 10:11 PM, Greg KH wrote:
> On Thu, Nov 30, 2017 at 09:13:35PM +0530, Arvind Yadav wrote:
>> platform_get_irq() can fail here and we must check its return value.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> ---
>> drivers/staging/irda/drivers/pxaficp_ir.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
> Did you read drivers/staging/irda/TODO?
Sorry, Now I have read it. :(
>
> thanks,
>
> greg k-h
Thanks,
~arvind
^ permalink raw reply
* Re: [PATCH net-next 3/5] bpftool: implement cgattach command
From: Roman Gushchin @ 2017-11-30 16:44 UTC (permalink / raw)
To: David Ahern
Cc: netdev, linux-kernel, kernel-team, ast, daniel, jakub.kicinski,
kafai
In-Reply-To: <24b1be13-0f42-7695-7b06-7236b2c0beeb@gmail.com>
On Thu, Nov 30, 2017 at 09:17:17AM -0700, David Ahern wrote:
> On 11/30/17 6:43 AM, Roman Gushchin wrote:
> > @@ -75,12 +80,13 @@ static int do_help(int argc, char **argv)
> > fprintf(stderr,
> > "Usage: %s [OPTIONS] OBJECT { COMMAND | help }\n"
> > " %s batch file FILE\n"
> > + " %s cgattach FILE CGROUP TYPE\n"
>
> Can you change the order to:
> + " %s cgattach CGROUP TYPE FILE\n"
>
> Makes for better consistency with the detach command in the next patch:
> + " %s cgdetach CGROUP TYPE ID\n"
>
>
Good point.
I'll fix this and will add support for attach_flags in v2.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/3] staging: irda: Handle return value of platform_get_irq
From: Greg KH @ 2017-11-30 16:41 UTC (permalink / raw)
To: Arvind Yadav
Cc: lars, Michael.Hennerich, jic23, knaack.h, pmeerw, samuel,
linux-iio, devel, linux-kernel, netdev
In-Reply-To: <1512056616-21065-3-git-send-email-arvind.yadav.cs@gmail.com>
On Thu, Nov 30, 2017 at 09:13:35PM +0530, Arvind Yadav wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> drivers/staging/irda/drivers/pxaficp_ir.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Did you read drivers/staging/irda/TODO?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: Add entry for Socionext ethernet driver
From: Joe Perches @ 2017-11-30 16:33 UTC (permalink / raw)
To: jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Jassi Brar
In-Reply-To: <1512058416-15968-1-git-send-email-jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2017-11-30 at 21:43 +0530, jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Add entry for the Socionext Netsec controller driver and DT bindings.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -12617,6 +12617,14 @@ F: drivers/md/raid*
> F: include/linux/raid/
> F: include/uapi/linux/raid/
>
> +SOCIONEXT (SNI) NETSEC NETWORK DRIVER
> +M: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> +L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +S: Supported
> +S: Maintained
One S: line per customer...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 3/5] bpftool: implement cgattach command
From: David Ahern @ 2017-11-30 16:24 UTC (permalink / raw)
To: Roman Gushchin, netdev
Cc: linux-kernel, kernel-team, ast, daniel, jakub.kicinski, kafai
In-Reply-To: <20171130134302.2840-4-guro@fb.com>
On 11/30/17 6:43 AM, Roman Gushchin wrote:
> + if (bpf_prog_attach(prog_fd, cgroup_fd, attach_type, 0)) {
> + bpf_object__close(obj);
> + close(prog_fd);
> + close(cgroup_fd);
> + p_err("Failed to attach program");
> + return -1;
> + }
Also, what about support for BPF_F_ALLOW_OVERRIDE and BPF_F_ALLOW_MULTI
flags?
^ permalink raw reply
* [PATCH net-next 4/4] net: dsa: add switch mdb bitmap functions
From: Vivien Didelot @ 2017-11-30 16:24 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130162400.8617-1-vivien.didelot@savoirfairelinux.com>
This patch brings no functional changes.
It moves out the MDB code iterating on a multicast group into new
dsa_switch_mdb_{prepare,add}_bitmap() functions.
This gives us a better isolation of the two switchdev phases.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
net/dsa/switch.c | 48 +++++++++++++++++++++++++++++++++---------------
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 17cd03d6bc7d..9a01514ea9f3 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -108,13 +108,42 @@ static int dsa_switch_fdb_del(struct dsa_switch *ds,
info->vid);
}
+static int
+dsa_switch_mdb_prepare_bitmap(struct dsa_switch *ds,
+ const struct switchdev_obj_port_mdb *mdb,
+ const unsigned long *bitmap)
+{
+ int port, err;
+
+ if (!ds->ops->port_mdb_prepare || !ds->ops->port_mdb_add)
+ return -EOPNOTSUPP;
+
+ for_each_set_bit(port, bitmap, ds->num_ports) {
+ err = ds->ops->port_mdb_prepare(ds, port, mdb);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static void dsa_switch_mdb_add_bitmap(struct dsa_switch *ds,
+ const struct switchdev_obj_port_mdb *mdb,
+ const unsigned long *bitmap)
+{
+ int port;
+
+ for_each_set_bit(port, bitmap, ds->num_ports)
+ ds->ops->port_mdb_add(ds, port, mdb);
+}
+
static int dsa_switch_mdb_add(struct dsa_switch *ds,
struct dsa_notifier_mdb_info *info)
{
const struct switchdev_obj_port_mdb *mdb = info->mdb;
struct switchdev_trans *trans = info->trans;
DECLARE_BITMAP(group, ds->num_ports);
- int port, err;
+ int port;
/* Build a mask of Multicast group members */
bitmap_zero(group, ds->num_ports);
@@ -124,21 +153,10 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
if (dsa_is_dsa_port(ds, port))
set_bit(port, group);
- if (switchdev_trans_ph_prepare(trans)) {
- if (!ds->ops->port_mdb_prepare || !ds->ops->port_mdb_add)
- return -EOPNOTSUPP;
+ if (switchdev_trans_ph_prepare(trans))
+ return dsa_switch_mdb_prepare_bitmap(ds, mdb, group);
- for_each_set_bit(port, group, ds->num_ports) {
- err = ds->ops->port_mdb_prepare(ds, port, mdb);
- if (err)
- return err;
- }
-
- return 0;
- }
-
- for_each_set_bit(port, group, ds->num_ports)
- ds->ops->port_mdb_add(ds, port, mdb);
+ dsa_switch_mdb_add_bitmap(ds, mdb, group);
return 0;
}
--
2.15.0
^ permalink raw reply related
* [PATCH net-next 3/4] net: dsa: add switch vlan bitmap functions
From: Vivien Didelot @ 2017-11-30 16:23 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130162400.8617-1-vivien.didelot@savoirfairelinux.com>
This patch brings no functional changes.
It moves out the VLAN code iterating on a list of VLAN members into new
dsa_switch_vlan_{prepare,add}_bitmap() functions.
This gives us a better isolation of the two switchdev phases.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
net/dsa/switch.c | 49 ++++++++++++++++++++++++++++++++++---------------
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 5ee04e9b5796..17cd03d6bc7d 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -157,13 +157,43 @@ static int dsa_switch_mdb_del(struct dsa_switch *ds,
return 0;
}
+static int
+dsa_switch_vlan_prepare_bitmap(struct dsa_switch *ds,
+ const struct switchdev_obj_port_vlan *vlan,
+ const unsigned long *bitmap)
+{
+ int port, err;
+
+ if (!ds->ops->port_vlan_prepare || !ds->ops->port_vlan_add)
+ return -EOPNOTSUPP;
+
+ for_each_set_bit(port, bitmap, ds->num_ports) {
+ err = ds->ops->port_vlan_prepare(ds, port, vlan);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static void
+dsa_switch_vlan_add_bitmap(struct dsa_switch *ds,
+ const struct switchdev_obj_port_vlan *vlan,
+ const unsigned long *bitmap)
+{
+ int port;
+
+ for_each_set_bit(port, bitmap, ds->num_ports)
+ ds->ops->port_vlan_add(ds, port, vlan);
+}
+
static int dsa_switch_vlan_add(struct dsa_switch *ds,
struct dsa_notifier_vlan_info *info)
{
const struct switchdev_obj_port_vlan *vlan = info->vlan;
struct switchdev_trans *trans = info->trans;
DECLARE_BITMAP(members, ds->num_ports);
- int port, err;
+ int port;
/* Build a mask of VLAN members */
bitmap_zero(members, ds->num_ports);
@@ -173,21 +203,10 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
set_bit(port, members);
- if (switchdev_trans_ph_prepare(trans)) {
- if (!ds->ops->port_vlan_prepare || !ds->ops->port_vlan_add)
- return -EOPNOTSUPP;
+ if (switchdev_trans_ph_prepare(trans))
+ return dsa_switch_vlan_prepare_bitmap(ds, vlan, members);
- for_each_set_bit(port, members, ds->num_ports) {
- err = ds->ops->port_vlan_prepare(ds, port, vlan);
- if (err)
- return err;
- }
-
- return 0;
- }
-
- for_each_set_bit(port, members, ds->num_ports)
- ds->ops->port_vlan_add(ds, port, vlan);
+ dsa_switch_vlan_add_bitmap(ds, vlan, members);
return 0;
}
--
2.15.0
^ permalink raw reply related
* [PATCH net-next 2/4] net: dsa: remove trans argument from mdb ops
From: Vivien Didelot @ 2017-11-30 16:23 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130162400.8617-1-vivien.didelot@savoirfairelinux.com>
The DSA switch MDB ops pass the switchdev_trans structure down to the
drivers, but no one is using them and they aren't supposed to anyway.
Remove the trans argument from MDB prepare and add operations.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/lan9303-core.c | 6 ++----
drivers/net/dsa/microchip/ksz_common.c | 6 ++----
drivers/net/dsa/mv88e6xxx/chip.c | 6 ++----
include/net/dsa.h | 10 ++++------
net/dsa/switch.c | 4 ++--
5 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index b24566bb74d2..ea59dadefb33 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -1217,8 +1217,7 @@ static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
}
static int lan9303_port_mdb_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
struct lan9303 *chip = ds->priv;
@@ -1235,8 +1234,7 @@ static int lan9303_port_mdb_prepare(struct dsa_switch *ds, int port,
}
static void lan9303_port_mdb_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
struct lan9303 *chip = ds->priv;
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 25b94edc5526..663b0d5b982b 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -856,16 +856,14 @@ static int ksz_port_fdb_dump(struct dsa_switch *ds, int port,
}
static int ksz_port_mdb_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
/* nothing to do */
return 0;
}
static void ksz_port_mdb_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
struct ksz_device *dev = ds->priv;
u32 static_table[4];
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index eff624fbd220..b5e0987c88f0 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3786,8 +3786,7 @@ static const char *mv88e6xxx_drv_probe(struct device *dsa_dev,
}
static int mv88e6xxx_port_mdb_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
/* We don't need any dynamic resource from the kernel (yet),
* so skip the prepare phase.
@@ -3797,8 +3796,7 @@ static int mv88e6xxx_port_mdb_prepare(struct dsa_switch *ds, int port,
}
static void mv88e6xxx_port_mdb_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_mdb *mdb)
{
struct mv88e6xxx_chip *chip = ds->priv;
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 0c4fbb34379e..6700dff46a80 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -431,12 +431,10 @@ struct dsa_switch_ops {
/*
* Multicast database
*/
- int (*port_mdb_prepare)(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans);
- void (*port_mdb_add)(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_mdb *mdb,
- struct switchdev_trans *trans);
+ int (*port_mdb_prepare)(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb);
+ void (*port_mdb_add)(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb);
int (*port_mdb_del)(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_mdb *mdb);
/*
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 205f074fa524..5ee04e9b5796 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -129,7 +129,7 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
return -EOPNOTSUPP;
for_each_set_bit(port, group, ds->num_ports) {
- err = ds->ops->port_mdb_prepare(ds, port, mdb, trans);
+ err = ds->ops->port_mdb_prepare(ds, port, mdb);
if (err)
return err;
}
@@ -138,7 +138,7 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
}
for_each_set_bit(port, group, ds->num_ports)
- ds->ops->port_mdb_add(ds, port, mdb, trans);
+ ds->ops->port_mdb_add(ds, port, mdb);
return 0;
}
--
2.15.0
^ permalink raw reply related
* [PATCH net-next 1/4] net: dsa: remove trans argument from vlan ops
From: Vivien Didelot @ 2017-11-30 16:23 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130162400.8617-1-vivien.didelot@savoirfairelinux.com>
The DSA switch VLAN ops pass the switchdev_trans structure down to the
drivers, but no one is using them and they aren't supposed to anyway.
Remove the trans argument from VLAN prepare and add operations.
At the same time, fix the following checkpatch warning:
WARNING: line over 80 characters
#74: FILE: drivers/net/dsa/dsa_loop.c:177:
+ const struct switchdev_obj_port_vlan *vlan)
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/b53/b53_common.c | 6 ++----
drivers/net/dsa/b53/b53_priv.h | 6 ++----
drivers/net/dsa/dsa_loop.c | 9 ++++-----
drivers/net/dsa/microchip/ksz_common.c | 6 ++----
drivers/net/dsa/mv88e6xxx/chip.c | 6 ++----
include/net/dsa.h | 10 ++++------
net/dsa/switch.c | 4 ++--
7 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index f5a8dd96fd75..5936ee9faa35 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1029,8 +1029,7 @@ int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering)
EXPORT_SYMBOL(b53_vlan_filtering);
int b53_vlan_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
struct b53_device *dev = ds->priv;
@@ -1047,8 +1046,7 @@ int b53_vlan_prepare(struct dsa_switch *ds, int port,
EXPORT_SYMBOL(b53_vlan_prepare);
void b53_vlan_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
struct b53_device *dev = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index daaaa1ecb996..88382c5dfee4 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -295,11 +295,9 @@ void b53_br_set_stp_state(struct dsa_switch *ds, int port, u8 state);
void b53_br_fast_age(struct dsa_switch *ds, int port);
int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering);
int b53_vlan_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans);
+ const struct switchdev_obj_port_vlan *vlan);
void b53_vlan_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans);
+ const struct switchdev_obj_port_vlan *vlan);
int b53_vlan_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan);
int b53_fdb_add(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index bb71d3d6f65b..7aa84ee4e771 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -174,9 +174,9 @@ static int dsa_loop_port_vlan_filtering(struct dsa_switch *ds, int port,
return 0;
}
-static int dsa_loop_port_vlan_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+static int
+dsa_loop_port_vlan_prepare(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan)
{
struct dsa_loop_priv *ps = ds->priv;
struct mii_bus *bus = ps->bus;
@@ -193,8 +193,7 @@ static int dsa_loop_port_vlan_prepare(struct dsa_switch *ds, int port,
}
static void dsa_loop_port_vlan_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index b5be93a1e0df..25b94edc5526 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -559,8 +559,7 @@ static int ksz_port_vlan_filtering(struct dsa_switch *ds, int port, bool flag)
}
static int ksz_port_vlan_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
/* nothing needed */
@@ -568,8 +567,7 @@ static int ksz_port_vlan_prepare(struct dsa_switch *ds, int port,
}
static void ksz_port_vlan_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
struct ksz_device *dev = ds->priv;
u32 vlan_table[3];
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 8171055fde7a..eff624fbd220 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1185,8 +1185,7 @@ static int mv88e6xxx_port_vlan_filtering(struct dsa_switch *ds, int port,
static int
mv88e6xxx_port_vlan_prepare(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
struct mv88e6xxx_chip *chip = ds->priv;
int err;
@@ -1295,8 +1294,7 @@ static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
}
static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans)
+ const struct switchdev_obj_port_vlan *vlan)
{
struct mv88e6xxx_chip *chip = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 2a05738570d8..0c4fbb34379e 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -412,12 +412,10 @@ struct dsa_switch_ops {
*/
int (*port_vlan_filtering)(struct dsa_switch *ds, int port,
bool vlan_filtering);
- int (*port_vlan_prepare)(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans);
- void (*port_vlan_add)(struct dsa_switch *ds, int port,
- const struct switchdev_obj_port_vlan *vlan,
- struct switchdev_trans *trans);
+ int (*port_vlan_prepare)(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan);
+ void (*port_vlan_add)(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan);
int (*port_vlan_del)(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan);
/*
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 29608d087a7c..205f074fa524 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -178,7 +178,7 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
return -EOPNOTSUPP;
for_each_set_bit(port, members, ds->num_ports) {
- err = ds->ops->port_vlan_prepare(ds, port, vlan, trans);
+ err = ds->ops->port_vlan_prepare(ds, port, vlan);
if (err)
return err;
}
@@ -187,7 +187,7 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
}
for_each_set_bit(port, members, ds->num_ports)
- ds->ops->port_vlan_add(ds, port, vlan, trans);
+ ds->ops->port_vlan_add(ds, port, vlan);
return 0;
}
--
2.15.0
^ permalink raw reply related
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