[PATCH] pktgen: Fix memory leak in pktgen_if_write
_buf_ is an array and the one that must be freed is _tp_ instead.
Fixes: a870a02cc963 ("pktgen: use dynamic allocation for debug print buffer")
Reported-by: Wang Jian
Signed-off-by: Gustavo A. R. Silva
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index fd65761..545cf08 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -913,7 +913,7 @@ static ssize_t pktgen_if_write(struct file *file,
return PTR_ERR(tp);
pr_debug("%s,%zu buffer -:%s:-\n", name, count, tp);
- kfree(buf);
+ kfree(tp);
}
if (!strcmp(name, "min_pkt_size")) {
--
2.7.4
Re: WARNING: CPU: 3 PID: 0 at net/sched/sch_hfsc.c:1388 hfsc_dequeue+0x319/0x350 [sch_hfsc]
> Il 9 marzo 2018 alle 0.14 Cong Wang ha scritto: > > > On Thu, Mar 8, 2018 at 8:02 AM, Marco Berizzi wrote: > >> Marco Berizzi wrote: > >> > >> > >> Hello everyone, > >> > >> Yesterday I got this error on a slackware linux 4.16-rc4 system > >> running as a traffic shaping gateway and netfilter nat. > >> The error has been arisen after a partial ISP network outage, > >> so unfortunately it will not trivial for me to reproduce it again. > > > > Hello everyone, > > > > I'm getting this error twice/day, so fortunately I'm able to > > reproduce it. > > IIRC, there was a patch for this, but it got lost... > > I will take a look anyway. ok, thanks for the response. Let me know when there will be a patch available to test.
Re: [PATCH] pktgen: use dynamic allocation for debug print buffer
Arnd:
Thanks for the fix.
On 03/13/2018 10:02 PM, Wang Jian wrote:
+ kfree(buf);
free tb? buf is an array.
Wang:
Thanks for the report. I already sent a patch to fix this:
https://patchwork.kernel.org/patch/10281587/
--
Gustavo
On Wed, Mar 14, 2018 at 8:25 AM, David Miller wrote:
From: Arnd Bergmann
Date: Tue, 13 Mar 2018 21:58:39 +0100
After the removal of the VLA, we get a harmless warning about a large
stack frame:
net/core/pktgen.c: In function 'pktgen_if_write':
net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than
1024 bytes [-Werror=frame-larger-than=]
The function was previously shown to be safe despite hitting
the 1024 bye warning level. To get rid of the annoyging warning,
while keeping it readable, this changes it to use strndup_user().
Obviously this is not a fast path, so the kmalloc() overhead
can be disregarded.
Fixes: 35951393bbff ("pktgen: Remove VLA usage")
Signed-off-by: Arnd Bergmann
Applied, thanks.
Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
On Tue, Mar 13, 2018 at 08:06:50PM +0100, Mohammed Gamal wrote:
> @@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
>
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> }
>
> + ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
> if (ret == 0) {
> atomic_inc_return(&nvchan->queue_sends);
>
Could you move the assignment inside the "ret == 0" path closer to where
it's used?
regards,
dan carpenter
Re: [PATCH] pktgen: Fix memory leak in pktgen_if_write
On Wed, Mar 14, 2018 at 9:07 AM, Gustavo A. R. Silva
wrote:
> _buf_ is an array and the one that must be freed is _tp_ instead.
>
> Fixes: a870a02cc963 ("pktgen: use dynamic allocation for debug print buffer")
> Reported-by: Wang Jian
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Arnd Bergmann
Thanks for fixing up my mistake so quickly, and thanks to Wang for the report
I was about to send the same patch, but you got there first.
Re: [pci PATCH v6 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
On Tue, Mar 13, 2018 at 02:28:49PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch adds a common configuration function called
> pci_sriov_configure_simple that will allow for managing VFs on devices
> where the PF is not capable of managing VF resources.
>
> Signed-off-by: Alexander Duyck
> ---
>
> v5: New patch replacing pci_sriov_configure_unmanaged with
> pci_sriov_configure_simple
> Dropped bits related to autoprobe changes
> v6: Defined pci_sriov_configure_simple as NULL if IOV is disabled
>
> drivers/pci/iov.c | 32
> include/linux/pci.h |3 +++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 677924ae0350..bd7021491fdb 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -807,3 +807,35 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
> return dev->sriov->total_VFs;
> }
> EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
> +
> +/**
> + * pci_sriov_configure_simple - helper to configure unmanaged SR-IOV
> + * @dev: the PCI device
> + * @nr_virtfn: number of virtual functions to enable, 0 to disable
> + *
> + * Used to provide generic enable/disable SR-IOV option for devices
> + * that do not manage the VFs generated by their driver
> + */
> +int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn)
> +{
> + int err = -EINVAL;
This assignment seems like it is never used..
> +
> + might_sleep();
> +
> + if (!dev->is_physfn)
> + return -ENODEV;
> +
> + if (pci_vfs_assigned(dev)) {
> + pci_warn(dev,
> + "Cannot modify SR-IOV while VFs are assigned\n");
> + err = -EPERM;
Why not:
if (pci_vfs_assigned(dev)) {
pci_warn(dev,
"Cannot modify SR-IOV while VFs are assigned\n");
return -EPERM;
}
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Looks good, Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 4/5] nvme: Migrate over to unmanaged SR-IOV support
Looks good, Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
> +
> +/**
> + * pci_pf_stub_white_list - White list of devices to bind pci-pf-stub onto
> + *
> + * This table provides the list of IDs this driver is supposed to bind
> + * onto. You could think of this as a list of "quirked" devices where we
> + * are adding support for SR-IOV here since there are no other drivers
> + * that they would be running under.
> + *
> + * Layout of the table below is as follows:
> + * { Vendor ID, Device ID,
> + * SubVendor ID, SubDevice ID,
> + * Class, Class Mask,
> + * private data (not used) }
> + */
No need to document the PCI device table format in a random driver.
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
Re: [PATCH iproute2] Revert "iproute: "list/flush/save default" selected all of the routes"
Hello, There was a series of patches by Serhey and specifically this one: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=93fa12418dc6f5943692250244be303bb162175b It drops handling of special prefix names in get_prefix_1(), and in get_addr_1() they always receive family and bytelen. But as I unerstand for any case it was important to keep it with unspecified family for further filtering. As I do not know what is the global idea, I want to discuss it. Because there are options depending on how and where we want to handle those special names. Like keep unspecified family or change filtering logic. I have added Serhey Popovych in the recepients, so he can give some ideas on what his aim is and help choose better solution. 13.03.2018, 21:12, "Alexander Zubkov" : > Hi, > > I just realized that you need patch for v4.15.0, which is easier to do. > I'll send it as separate message now. I will make patch for the master > branch, but later. > > On 13.03.2018 13:02, Luca Boccassi wrote: >> On Tue, 2018-03-13 at 12:05 +0100, Alexander Zubkov wrote: >>> Hello again, >>> >>> The fun thing is that before the commit "ip route ls all" showed all >>> routes, but "ip -[4|6] route ls all" showed only default. So it was >>> broken too, but in other way. >>> I see parsing of prefix was changed since my patch. So I need several >>> days to propose fix. I think if "ip route ls [all|any]" shows all >>> routes and "ip route ls default" shows only default, everybody will >>> be happy with that? >> >> Hi, >> >> My only concern is that behaviour of existing commands that have been >> in releases is not changed, otherwise I get bugs raised :-) >> >> Thank you for your work! >> >>> 13.03.2018, 09:46, "Alexander Zubkov" : Hello. May be the better way would be to change how "all"/"any" argument behaves? My original concern was about "default" only. I agree too, that "all" or "any" should work for all routes. But not for the default. 12.03.2018, 22:37, "Luca Boccassi" : > On Mon, 2018-03-12 at 14:03 -0700, Stephen Hemminger wrote: >> This reverts commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2. >> >> Debian maintainer found that basic command: >> # ip route flush all >> No longer worked as expected which breaks user scripts and >> expectations. It no longer flushed all IPv4 routes. >> >> Reported-by: Luca Boccassi >> Signed-off-by: Stephen Hemminger >> --- >> ip/iproute.c | 65 ++-- >> >> >> lib/utils.c | 13 >> 2 files changed, 32 insertions(+), 46 deletions(-) > > Tested-by: Luca Boccassi > > Thanks, solves the problem. I'll backport it to Debian. > > Alexander, reproducing the issue is quite simple - before that > commit, > ip route ls all showed all routes, but with the change it > started > showing only the default table. Same for ip route flush. > > -- > Kind regards, > Luca Boccassi
Re: [RESEND] rsi: Remove stack VLA usage
tcharding writes: > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> tcharding wrote: >> >> > The kernel would like to have all stack VLA usage removed[1]. rsi uses >> > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size >> > is defined using a magic number. We can use a pre-processor defined >> > constant and declare the array to maximum size. We add a check before >> > accessing the array in case of programmer error. >> > >> > [1]: https://lkml.org/lkml/2018/3/7/621 >> > >> > Signed-off-by: Tobin C. Harding >> >> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should >> be >> "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from >> it's database instead of the From header of the patch in question. >> >> I can fix that manually but it would be helpful if you could register to >> patchwork and fix your name during registration. You have only one chance to >> fix your name (another braindead feature!) so be careful :) > > Hi Kalle, > > I logged into my patchwork account but I don't see any way to set the > name. Within 'profile' there is only 'change password' and 'link > email'. I thought I could unregister then re-register but I can't see > how to do that either. Ok, maybe you have registered (=logged on for the first time) already earlier so it's not possible to change the name anymore. > Is there a maintainer of patchwork.kernel.org who I can email to > manually remove me from the system? helpd...@kernel.org should be able to fix your name in patchwork, at least they have done it in the past. This is not the first time this has happened. -- Kalle Valo
Re: [RESEND] rsi: Remove stack VLA usage
"Tobin C. Harding" writes: > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> >> tcharding wrote: >> >> I'm pretty much sure it depends on the original email headers, like >> above ^^^ — no name. >> Perhaps git config on your side should be done. > > Thanks for the suggestion Andy but the 'tcharding' as the name was > munged by either Kalle or patchwork. I'm guessing patchwork. You guessed corretly, patchwork is here to blame. I sent my "please rebase" mail earlier in this thread using my custom patchwork client script (pwcli) which takes the name and address from patchwork. Andy, this is definitely a bug in patchwork and I have seen this issue multiple times already. I have understood that it has been fixed in a recent version but patchwork.kernel.org is still running an old version. In the original mail Tobin did have the correct From header which can be checked from the headers in patch page[1]: From: "Tobin C. Harding" [1] https://patchwork.kernel.org/patch/10274983/ -- Kalle Valo
Re: [RESEND] rsi: Remove stack VLA usage
"Tobin C. Harding" writes: > Added Konstantin in case he is in charge of administering > patchwork.kernel.org? > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding wrote: >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> >> >> tcharding wrote: >> >> >> >> I'm pretty much sure it depends on the original email headers, like >> >> above ^^^ — no name. >> >> Perhaps git config on your side should be done. >> > >> > Thanks for the suggestion Andy but the 'tcharding' as the name was >> > munged by either Kalle or patchwork. I'm guessing patchwork. >> >> Something you're sending from is using "tcharding" (see the email Andy >> quotes). I see the headers as: >> >> Date: Wed, 14 Mar 2018 07:17:57 +1100 >> From: tcharding >> ... >> Message-ID: <20180313201757.GK8631@eros> >> X-Mailer: Mutt 1.5.24 (2015-08-30) >> User-Agent: Mutt/1.5.24 (2015-08-30) >> >> Your most recently email shows "Tobin C. Harding" though, and also >> sent with Mutt... >> >> Do you have multiple Mutt configurations? Is something lacking a >> "From" header insertion and your MTA is filling it in for you from >> your username? > > Thanks for taking the time to respond Kees (and Tycho). I have mutt > configured to reply from whichever email address I receive from so if > patchwork sent an email to 'tcharding ' (which is the > details it has) and I hit reply it would have come from 'tcharding', > hence Andy's reply. I wouldn't bet my life on it but I'm kinda > confident that I cannot initiate an email from 'tcharding' with my > current set up. > > Super bad form to blame someone (or something else) but I think this is > a problem with how my patchwork account is configured. Either way, that > is still my fault I should have added my real name to patchwork when I > signed up (not just username 'tcharding'). > > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added > Konstantin to CC's. Like I said earlier, just send a request to helpd...@kernel.org and admins should fix your name. -- Kalle Valo
[PATCH net v2] ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu
Prior to the rework of PMTU information storage in commit
2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."),
when a PMTU event advertising a PMTU smaller than
net.ipv4.route.min_pmtu was received, we would disable setting the DF
flag on packets by locking the MTU metric, and set the PMTU to
net.ipv4.route.min_pmtu.
Since then, we don't disable DF, and set PMTU to
net.ipv4.route.min_pmtu, so the intermediate router that has this link
with a small MTU will have to drop the packets.
This patch reestablishes pre-2.6.39 behavior by splitting
rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu.
rt_mtu_locked indicates that we shouldn't set the DF bit on that path,
and is checked in ip_dont_fragment().
One possible workaround is to set net.ipv4.route.min_pmtu to a value low
enough to accommodate the lowest MTU encountered.
Fixes: 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.")
Signed-off-by: Sabrina Dubroca
Reviewed-by: Stefano Brivio
---
v2: make rt_pmtu a bitfield
fix missing initializations of rt_mtu_locked
include/net/ip.h| 11 +--
include/net/ip_fib.h| 1 +
include/net/route.h | 3 ++-
net/ipv4/route.c| 26 +++---
net/ipv4/xfrm4_policy.c | 1 +
5 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 746abff9ce51..f49b3a576bec 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -328,6 +328,13 @@ int ip_decrease_ttl(struct iphdr *iph)
return --iph->ttl;
}
+static inline int ip_mtu_locked(const struct dst_entry *dst)
+{
+ const struct rtable *rt = (const struct rtable *)dst;
+
+ return rt->rt_mtu_locked || dst_metric_locked(dst, RTAX_MTU);
+}
+
static inline
int ip_dont_fragment(const struct sock *sk, const struct dst_entry *dst)
{
@@ -335,7 +342,7 @@ int ip_dont_fragment(const struct sock *sk, const struct
dst_entry *dst)
return pmtudisc == IP_PMTUDISC_DO ||
(pmtudisc == IP_PMTUDISC_WANT &&
-!(dst_metric_locked(dst, RTAX_MTU)));
+!ip_mtu_locked(dst));
}
static inline bool ip_sk_accept_pmtu(const struct sock *sk)
@@ -361,7 +368,7 @@ static inline unsigned int ip_dst_mtu_maybe_forward(const
struct dst_entry *dst,
struct net *net = dev_net(dst->dev);
if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
- dst_metric_locked(dst, RTAX_MTU) ||
+ ip_mtu_locked(dst) ||
!forwarding)
return dst_mtu(dst);
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index f80524396c06..77d0a78cf7d2 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -59,6 +59,7 @@ struct fib_nh_exception {
int fnhe_genid;
__be32 fnhe_daddr;
u32 fnhe_pmtu;
+ boolfnhe_mtu_locked;
__be32 fnhe_gw;
unsigned long fnhe_expires;
struct rtable __rcu *fnhe_rth_input;
diff --git a/include/net/route.h b/include/net/route.h
index 1eb9ce470e25..3d21e3686838 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -63,7 +63,8 @@ struct rtable {
__be32 rt_gateway;
/* Miscellaneous cached information */
- u32 rt_pmtu;
+ u32 rt_mtu_locked:1,
+ rt_pmtu:31;
u32 rt_table_id;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 860b3fd2f54b..dc6909448f41 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -634,6 +634,7 @@ static inline u32 fnhe_hashfun(__be32 daddr)
static void fill_route_from_fnhe(struct rtable *rt, struct fib_nh_exception
*fnhe)
{
rt->rt_pmtu = fnhe->fnhe_pmtu;
+ rt->rt_mtu_locked = fnhe->fnhe_mtu_locked;
rt->dst.expires = fnhe->fnhe_expires;
if (fnhe->fnhe_gw) {
@@ -644,7 +645,7 @@ static void fill_route_from_fnhe(struct rtable *rt, struct
fib_nh_exception *fnh
}
static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw,
- u32 pmtu, unsigned long expires)
+ u32 pmtu, bool lock, unsigned long expires)
{
struct fnhe_hash_bucket *hash;
struct fib_nh_exception *fnhe;
@@ -681,8 +682,10 @@ static void update_or_create_fnhe(struct fib_nh *nh,
__be32 daddr, __be32 gw,
fnhe->fnhe_genid = genid;
if (gw)
fnhe->fnhe_gw = gw;
- if (pmtu)
+ if (pmtu) {
fnhe->fnhe_pmtu = pmtu;
+ fnhe->fnhe_mtu_locked = lock;
+ }
fnhe->fnhe_expires = max(1UL, expires);
/* Update all cached dsts too */
rt = rcu_dereference(fnhe->fnhe_rth_input);
@@ -706
Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
On Tue, 2018-03-13 at 12:35 -0700, Stephen Hemminger wrote:
> On Tue, 13 Mar 2018 20:06:50 +0100
> Mohammed Gamal wrote:
>
> > Dring high network traffic changes to network interface parameters
> > such as number of channels or MTU can cause a kernel panic with a
> > NULL
> > pointer dereference. This is due to netvsc_device_remove() being
> > called and deallocating the channel ring buffers, which can then be
> > accessed by netvsc_send_pkt() before they're allocated on calling
> > netvsc_device_add()
> >
> > The patch fixes this problem by checking the channel state and
> > returning
> > ENODEV if not yet opened. We also move the call to
> > hv_ringbuf_avail_percent()
> > which may access the uninitialized ring buffer.
> >
> > Signed-off-by: Mohammed Gamal
> > ---
> > drivers/net/hyperv/netvsc.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc.c
> > b/drivers/net/hyperv/netvsc.c
> > index 0265d70..44a8358 100644
> > --- a/drivers/net/hyperv/netvsc.c
> > +++ b/drivers/net/hyperv/netvsc.c
> > @@ -757,7 +757,7 @@ static inline int netvsc_send_pkt(
> > struct netdev_queue *txq = netdev_get_tx_queue(ndev,
> > packet->q_idx);
> > u64 req_id;
> > int ret;
> > - u32 ring_avail = hv_ringbuf_avail_percent(&out_channel-
> > >outbound);
> > + u32 ring_avail;
> >
> > nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
> > if (skb)
> > @@ -773,7 +773,7 @@ static inline int netvsc_send_pkt(
> >
> > req_id = (ulong)skb;
> >
> > - if (out_channel->rescind)
> > + if (out_channel->rescind || out_channel->state !=
> > CHANNEL_OPENED_STATE)
> > return -ENODEV;
> >
> > if (packet->page_buf_cnt) {
> > @@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
> > VMBUS_DATA_PACKET_FLAG_COMP
> > LETION_REQUESTED);
> > }
> >
> > + ring_avail = hv_ringbuf_avail_percent(&out_channel-
> > >outbound);
> > if (ret == 0) {
> > atomic_inc_return(&nvchan->queue_sends);
> >
>
> Thanks for your patch. Yes there are races with the current update
> logic. The root cause goes higher up in the flow; the send queues
> should
> be stopped before netvsc_device_remove is called. Solving it where
> you tried
> to is racy and not going to work reliably.
>
> Network patches should go to netdev@vger.kernel.org
>
> You can't move the ring_avail check until after the vmbus_sendpacket
> because
> that will break the flow control logic.
>
Why? I don't see ring_avail being used before that point.
> Instead, you should just move the avail_read check until just after
> the existing rescind
> check.
>
> Also, you shouldn't need to check for OPENED_STATE, just rescind is
> enough.
That rarely mitigated the race. channel->rescind flag is set on vmbus
exit - called on module unload - and when a rescind offer is received
from the host, which AFAICT doesn't happen on every call to
netvsc_device_remove, so it's quite possible that the ringbuffer is
accessed before it's allocated again on channel open and hence the
check for OPENED_STAT - which is only set after all vmbus data is
initialized.
>
>
>
>
Re: [RFC net-next 2/6] driver: net: bonding: allow registration of tc offload callbacks in bond
Tue, Mar 13, 2018 at 04:51:02PM CET, gerlitz...@gmail.com wrote: >On Wed, Mar 7, 2018 at 12:57 PM, Jiri Pirko wrote: >> Mon, Mar 05, 2018 at 02:28:30PM CET, john.hur...@netronome.com wrote: >>>Allow drivers to register netdev callbacks for tc offload in linux bonds. >>>If a netdev has registered and is a slave of a given bond, then any tc >>>rules offloaded to the bond will be relayed to it if both the bond and the >>>slave permit hw offload. > >>>Because the bond itself is not offloaded, just the rules, we don't care >>>about whether the bond ports are on the same device or whether some of >>>slaves are representor ports and some are not. > >John, I think we must design here for the case where the bond IS offloaded. >E.g some sort of HW LAG. For example, the mlxsw driver supports >LAG offload and support tcflower offload, we need to see how these >two live together, mlx5 supports tcflower offload and we are working on >bond offload, etc. > >>>+EXPORT_SYMBOL_GPL(tc_setup_cb_bond_register); >> >> Please, no "bond" specific calls from drivers. That would be wrong. >> The idea behing block callbacks was that anyone who is interested could >> register to receive those. In this case, slave device is interested. >> So it should register to receive block callbacks in the same way as if >> the block was directly on top of the slave device. The only thing you >> need to handle is to propagate block bind/unbind from master down to the >> slaves. > >Jiri, > >This sounds nice for the case where one install ingress tc rules on >the bond (lets >call them type 1, see next) > >One obstacle pointed by my colleague, Rabie, is that when the upper layer >issues stat call on the filter, they will get two replies, this can confuse >them >and lead to wrong decisions (aging). I wonder if/how we can set a knob The bonding itself would not do anything on stats update command (TC_CLSFLOWER_STATS for example). Only the slaves would do update. So there will be only reply from slaves. Bond/team is just going to probagare block bind/unbind down. Nothing else. >somewhere that unifies the stats (add packet/bytes, use the latest lastuse). > >Also, lets see what other rules have to be offloaded in that scheme >(call them type 2/3/4) >where one bonded two HW ports > >2. bond being egress port of a rule > >TC rules for overlay networks scheme, e.g in NIC SRIOV >scheme where one bonds the two uplink representors > >Starting with type 2, in our current NIC HW APIs we have to duplicate >these rules >into two rules set to HW: > >2.1 VF rep --> uplink 0 >2.2 VF rep --> uplink 1 > >and we do that in the driver (add/del two HW rules, combine the stat >results, etc) That is up to the driver. If the driver can share block between 2 devices, he can do that. If he cannot share, it will just report stats for every device separatelly (2 block cbs registered) and tc will see them both together. No need to do anything in driver. > >3. ingress rule on VF rep port with shared tunnel device being the >egress (encap) >and where the routing of the underlay (tunnel) goes through LAG. > >in our case, this is like 2.1/2.2 above, offload two rules, combine stats > Same as "2." >4. ingress rule shared tunnel device being the ingress and VF rep port >being the egress (decap) I don't follow :( > >this uses the egdev facility to be offloaded into the our driver, and >then in the driver >we will treat it like type 1, two rules need to be installed into HW, >but now, we can't delegate them >from the vxlan device b/c it has no direct connection with the bond. I see another thing we need to sanitize: vxlan rule ingress match action mirred redirect to lag > >All to all, for the mlx5 use case, seems we have elegant solution only >for type 1. > >I think we should do the elegant solution for the case where it applicable. > >In parallel if/when newer HW APIs are there such that type 2 and 3 can be set >using one HW rule whose dest is the bond, we are good. As for type 4, >need to see >if/how it can be nicer. > >Or.
[PATCH net-next 2/3] net/smc: free link group without pending free_work only
Make sure there is no pending or running free_work worker for the link
group when freeing the link group.
Signed-off-by: Ursula Braun
---
net/smc/af_smc.c | 1 +
net/smc/smc_core.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 2c6f4e0a9f3d..649489f825a5 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1477,6 +1477,7 @@ static void __exit smc_exit(void)
spin_unlock_bh(&smc_lgr_list.lock);
list_for_each_entry_safe(lgr, lg, &lgr_freeing_list, list) {
list_del_init(&lgr->list);
+ cancel_delayed_work_sync(&lgr->free_work);
smc_lgr_free(lgr); /* free link group */
}
static_branch_disable(&tcp_have_smc);
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index f76f60e463cb..ec6189fe2a48 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -140,7 +140,8 @@ static void smc_lgr_free_work(struct work_struct *work)
list_del_init(&lgr->list); /* remove from smc_lgr_list */
free:
spin_unlock_bh(&smc_lgr_list.lock);
- smc_lgr_free(lgr);
+ if (!delayed_work_pending(&lgr->free_work))
+ smc_lgr_free(lgr);
}
/* create a new SMC link group */
--
2.13.5
[PATCH net-next 1/3] net/smc: pay attention to MAX_ORDER for CQ entries
smc allocates a certain number of CQ entries for used RoCE devices. For
mlx5 devices the chosen constant number results in a large allocation
causing this warning:
[13355.124656] WARNING: CPU: 3 PID: 16535 at mm/page_alloc.c:3883
__alloc_pages_nodemask+0x2be/0x10c0
[13355.124657] Modules linked in: smc_diag(O) smc(O) xt_CHECKSUM iptable_mangle
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT
nf_reject_ipv4 xt_tcpudp bridge stp llc ip6table_filter ip6_tables
iptable_filter mlx5_ib ib_core sunrpc mlx5_core s390_trng rng_core ghash_s390
prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common
ptp pps_core eadm_sch dm_multipath dm_mod vhost_net tun vhost tap sch_fq_codel
kvm ip_tables x_tables autofs4 [last unloaded: smc]
[13355.124672] CPU: 3 PID: 16535 Comm: kworker/3:0 Tainted: G O
4.14.0uschi #1
[13355.124673] Hardware name: IBM 3906 M04 704 (LPAR)
[13355.124675] Workqueue: events smc_listen_work [smc]
[13355.124677] task: e2f22100 task.stack: 8472
[13355.124678] Krnl PSW : 0704c0018000 0029da76
(__alloc_pages_nodemask+0x2be/0x10c0)
[13355.124681]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0
RI:0 EA:3
[13355.124682] Krnl GPRS: 00550e00014080c0
0001
[13355.124684]0029d8b6 f3bfd710
014080c0
[13355.124685]0009 ec277a00 0020
[13355.124686] 01ff 0029d8b6
84723720
[13355.124708] Krnl Code: 0029da6a: a7110200tmll%r1,512
0029da6e: a774ff29brc 7,29d8c0
#0029da72: a7f40001brc
15,29da74
>0029da76: a7f4ff25brc
15,29d8c0
0029da7a: a738lhi %r3,0
0029da7e: a7f4fef1brc
15,29d860
0029da82: 5820f0c4l
%r2,196(%r15)
0029da86: a53e0048llilh %r3,72
[13355.124720] Call Trace:
[13355.124722] ([<0029d8b6>] __alloc_pages_nodemask+0xfe/0x10c0)
[13355.124724] [<0013bd1e>] s390_dma_alloc+0x6e/0x148
[13355.124733] [<03ff802eeba6>] mlx5_dma_zalloc_coherent_node+0x8e/0xe0
[mlx5_core]
[13355.124740] [<03ff802eee18>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core]
[13355.124744] [<03ff804eb410>] mlx5_ib_create_cq+0x558/0x898 [mlx5_ib]
[13355.124749] [<03ff80407d40>] ib_create_cq+0x48/0x88 [ib_core]
[13355.124751] [<03ff80109fba>] smc_ib_setup_per_ibdev+0x52/0x118 [smc]
[13355.124753] [<03ff8010bcb6>] smc_conn_create+0x65e/0x728 [smc]
[13355.124755] [<03ff801081a2>] smc_listen_work+0x2d2/0x540 [smc]
[13355.124756] [<00162c66>] process_one_work+0x1be/0x440
[13355.124758] [<00162f40>] worker_thread+0x58/0x458
[13355.124759] [<00169e7e>] kthread+0x14e/0x168
[13355.124760] [<009ce8be>] kernel_thread_starter+0x6/0xc
[13355.124762] [<009ce8b8>] kernel_thread_starter+0x0/0xc
[13355.124762] Last Breaking-Event-Address:
[13355.124764] [<0029da72>] __alloc_pages_nodemask+0x2ba/0x10c0
[13355.124764] ---[ end trace 34be38b581c0b585 ]---
This patch reduces the smc constant for the maximum number of allocated
completion queue entries SMC_MAX_CQE by 2 to avoid high round up values
in the mlx5 code, and reduces the number of allocated completion queue
entries even more, if the final allocation for an mlx5 device hits the
MAX_ORDER limit.
Reported-by: Ihnken Menssen
Signed-off-by: Ursula Braun
---
net/smc/smc_ib.c | 10 +-
net/smc/smc_wr.h | 1 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c
index 2a8957bd6d38..26df554f7588 100644
--- a/net/smc/smc_ib.c
+++ b/net/smc/smc_ib.c
@@ -23,6 +23,8 @@
#include "smc_wr.h"
#include "smc.h"
+#define SMC_MAX_CQE 32766 /* max. # of completion queue elements */
+
#define SMC_QP_MIN_RNR_TIMER 5
#define SMC_QP_TIMEOUT 15 /* 4096 * 2 ** timeout usec */
#define SMC_QP_RETRY_CNT 7 /* 7: infinite */
@@ -438,9 +440,15 @@ int smc_ib_remember_port_attr(struct smc_ib_device
*smcibdev, u8 ibport)
long smc_ib_setup_per_ibdev(struct smc_ib_device *smcibdev)
{
struct ib_cq_init_attr cqattr = {
- .cqe = SMC_WR_MAX_CQE, .comp_vector = 0 };
+ .cqe = SMC_MAX_CQE, .comp_vector = 0 };
+ int cqe_size_order, smc_order;
long rc;
+ /* the calculated number of cq entries fits to mlx5 cq allocation */
+ cqe_size_order = cache_line_size() == 128 ? 7 : 6;
+ smc_order = MAX_ORDER -
[PATCH net-next 0/3] net/smc: fixes 2018-03-14
here are smc changes for the net-next tree. The first patch enables SMC to work with mlx5-RoCE-devices. Patches 2 and 3 deal with link group freeing. Thanks, Ursula Karsten Graul (1): net/smc: schedule free_work when link group is terminated Ursula Braun (2): net/smc: pay attention to MAX_ORDER for CQ entries net/smc: free link group without pending free_work only net/smc/af_smc.c | 1 + net/smc/smc_core.c | 23 +++ net/smc/smc_ib.c | 10 +- net/smc/smc_wr.h | 1 - 4 files changed, 25 insertions(+), 10 deletions(-) -- 2.13.5
[PATCH net-next 3/3] net/smc: schedule free_work when link group is terminated
From: Karsten Graul
The free_work worker must be scheduled when the link group is
abnormally terminated.
Signed-off-by: Karsten Graul
Signed-off-by: Ursula Braun
---
net/smc/smc_core.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index ec6189fe2a48..f44f6803f7ff 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -32,6 +32,17 @@
static u32 smc_lgr_num;/* unique link group number */
+static void smc_lgr_schedule_free_work(struct smc_link_group *lgr)
+{
+ /* client link group creation always follows the server link group
+* creation. For client use a somewhat higher removal delay time,
+* otherwise there is a risk of out-of-sync link groups.
+*/
+ mod_delayed_work(system_wq, &lgr->free_work,
+lgr->role == SMC_CLNT ? SMC_LGR_FREE_DELAY_CLNT :
+SMC_LGR_FREE_DELAY_SERV);
+}
+
/* Register connection's alert token in our lookup structure.
* To use rbtrees we have to implement our own insert core.
* Requires @conns_lock
@@ -111,13 +122,7 @@ static void smc_lgr_unregister_conn(struct smc_connection
*conn)
write_unlock_bh(&lgr->conns_lock);
if (!reduced || lgr->conns_num)
return;
- /* client link group creation always follows the server link group
-* creation. For client use a somewhat higher removal delay time,
-* otherwise there is a risk of out-of-sync link groups.
-*/
- mod_delayed_work(system_wq, &lgr->free_work,
-lgr->role == SMC_CLNT ? SMC_LGR_FREE_DELAY_CLNT :
-SMC_LGR_FREE_DELAY_SERV);
+ smc_lgr_schedule_free_work(lgr);
}
static void smc_lgr_free_work(struct work_struct *work)
@@ -344,6 +349,7 @@ void smc_lgr_terminate(struct smc_link_group *lgr)
}
write_unlock_bh(&lgr->conns_lock);
wake_up(&lgr->lnk[SMC_SINGLE_LINK].wr_reg_wait);
+ smc_lgr_schedule_free_work(lgr);
}
/* Determine vlan of internal TCP socket.
--
2.13.5
Re: [bug, bisected] pfifo_fast causes packet reordering
On 14.03.18 05:03, John Fastabend wrote: During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are delivered out-of-order. Is the stress-testing tool available somewhere? What type of packets are being sent? Not public, no, the problem is that you'd need a CAN adapter as well. The test is simple, sending CAN frames with an increasing counter and a random length payload: [ tx thread rx thread] | ^ v | [ interface 0 ] cable > [ interface 1 ] I'll see if I can come up with a UDP testcase that works with normal ethernet interfaces. Is this a single queue device or a multiqueue device? Running 'tc -s qdisc show dev foo' would help some. Here you go: root@rk3399-q7:~# tc -s qdisc show dev can0 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 If we introduced a OOO edge case somewhere that was not intended so I'll take a look into it. But, if you can provide a bit more details on how stress testing is done to cause the issue that would help. Will do. Thanks, Jakob
[PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares. This is an obsoleted standard
and its implementation is something that:
1) Most people don't need / want to use
2) Can allow local DoS attacks
3) Breaks AP interfaces in some specific bridge setups
To solve issues it can cause this commit modifies brcmfmac to drop IAPP
packets. If affects:
1) Rx path: driver won't be sending these unwanted packets up.
2) Tx path: driver will reject packets that would trigger STA
disassociation perfromed by a firmware (possible local DoS attack).
It appears there are some Broadcom's clients/users who care about this
feature despite the drawbacks. They can switch it on by a newly added
Kconfig option.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/Kconfig| 20 +++
.../wireless/broadcom/brcm80211/brcmfmac/core.c| 39 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig
b/drivers/net/wireless/broadcom/brcm80211/Kconfig
index 9d99eb42d917..876787ef991a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -68,6 +68,26 @@ config BRCMFMAC_PCIE
IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
use the driver for an PCIE wireless card.
+config BRCMFMAC_IAPP
+ bool "Partial support for obsoleted Inter-Access Point Protocol"
+ depends on BRCMFMAC
+ ---help---
+ Most of Broadcom's firmwares can send 802.11f ADD frame every
+ time new STA connects to the AP interface. Some recent ones
+ can also disassociate STA when they receive such a frame.
+
+ It's important to understand this behavior can lead to a local
+ DoS security issue. Attacker may trigger disassociation of any
+ STA by sending a proper Ethernet frame to the wireless
+ interface.
+
+ Moreover this feature may break AP interfaces in some specific
+ setups. This applies e.g. to the bridge with hairpin mode
+ enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet
+ generated by a firmware will get passed back to the wireless
+ interface and cause immediate disassociation of just-connected
+ STA.
+
config BRCM_TRACING
bool "Broadcom device tracing"
depends on BRCMSMAC || BRCMFMAC
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 19048526b4af..db6987015fb1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -230,6 +230,34 @@ static void brcmf_netdev_set_multicast_list(struct
net_device *ndev)
schedule_work(&ifp->multicast_work);
}
+/**
+ * brcmf_skb_is_iapp - checks if skb is an IAPP packet
+ *
+ * @skb: skb to check
+ */
+static bool brcmf_skb_is_iapp(struct sk_buff *skb)
+{
+ const u8 iapp_l2_update_packet[6] __aligned(2) = {
+ 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
+ };
+ unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
+#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
+ const u16 *a = (const u16 *)eth_data;
+ const u16 *b = (const u16 *)iapp_l2_update_packet;
+#endif
+
+ if (skb->len - skb->mac_len != 6 ||
+ !is_multicast_ether_addr(eth_hdr(skb)->h_dest))
+ return false;
+
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
+ return !(((*(const u32 *)eth_data) ^ (*(const u32
*)iapp_l2_update_packet)) |
+((*(const u16 *)(eth_data + 4)) ^ (*(const u16
*)(iapp_l2_update_packet + 4;
+#else
+ return !((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2]));
+#endif
+}
+
static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
{
@@ -250,6 +278,12 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff
*skb,
goto done;
}
+ if (!IS_ENABLED(CONFIG_BRCMFMAC_IAPP) && brcmf_skb_is_iapp(skb)) {
+ dev_kfree_skb(skb);
+ ret = -EINVAL;
+ goto done;
+ }
+
/* Make sure there's enough writeable headroom */
if (skb_headroom(skb) < drvr->hdrlen || skb_header_cloned(skb)) {
head_delta = max_t(int, drvr->hdrlen - skb_headroom(skb), 0);
@@ -325,6 +359,11 @@ void brcmf_txflowblock_if(struct brcmf_if *ifp,
void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb)
{
+ if (!IS_ENABLED(CONFIG_BRCMFMAC_IAPP) && brcmf_skb_is_iapp(skb)) {
+ brcmu_pkt_buf_free_skb(skb);
+ return;
+ }
+
if (skb->pkt_type == PACKET_MULTICAST)
ifp->ndev->stats.multicast++;
--
2
[PATCH net-next 0/5] sctp: add support for some sctp auth APIs from RFC6458
This patchset mainly adds support for SCTP AUTH Information for sendmsg, described in RFC6458: 5.3.8. SCTP AUTH Information Structure (SCTP_AUTHINFO) and also adds a sockopt described in RFC6458: 8.3.4. Deactivate a Shared Key (SCTP_AUTH_DEACTIVATE_KEY) and two types of events for AUTHENTICATION_EVENT described in RFC6458: 6.1.8. SCTP_AUTHENTICATION_EVENT: - SCTP_AUTH_NO_AUTH - SCTP_AUTH_FREE_KEY After this patchset, we have fully support for sctp_sendv in kernel. Note that this patchset won't touch that sctp options merge conflict. Xin Long (5): sctp: add refcnt support for sh_key sctp: add support for SCTP AUTH Information for sendmsg sctp: add sockopt SCTP_AUTH_DEACTIVATE_KEY sctp: add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT include/net/sctp/auth.h| 21 --- include/net/sctp/command.h | 1 + include/net/sctp/sm.h | 3 +- include/net/sctp/structs.h | 10 +++- include/uapi/linux/sctp.h | 22 ++- net/sctp/auth.c| 146 +++-- net/sctp/chunk.c | 14 + net/sctp/output.c | 18 +- net/sctp/sm_make_chunk.c | 33 +- net/sctp/sm_sideeffect.c | 13 net/sctp/sm_statefuns.c| 56 ++--- net/sctp/socket.c | 77 12 files changed, 342 insertions(+), 72 deletions(-) -- 2.1.0
[PATCH net-next 1/5] sctp: add refcnt support for sh_key
With refcnt support for sh_key, chunks auth sh_keys can be decided
before enqueuing it. Changing the active key later will not affect
the chunks already enqueued.
Furthermore, this is necessary when adding the support for authinfo
for sendmsg in next patch.
Note that struct sctp_chunk can't be grown due to that performance
drop issue on slow cpu, so it just reuses head_skb memory for shkey
in sctp_chunk.
Signed-off-by: Xin Long
---
include/net/sctp/auth.h| 9 +++--
include/net/sctp/sm.h | 3 +-
include/net/sctp/structs.h | 9 +++--
net/sctp/auth.c| 86 +++---
net/sctp/chunk.c | 5 +++
net/sctp/output.c | 18 --
net/sctp/sm_make_chunk.c | 15 ++--
net/sctp/sm_statefuns.c| 11 +++---
net/sctp/socket.c | 6
9 files changed, 104 insertions(+), 58 deletions(-)
diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
index e5c57d0..017c1aa 100644
--- a/include/net/sctp/auth.h
+++ b/include/net/sctp/auth.h
@@ -62,8 +62,9 @@ struct sctp_auth_bytes {
/* Definition for a shared key, weather endpoint or association */
struct sctp_shared_key {
struct list_head key_list;
- __u16 key_id;
struct sctp_auth_bytes *key;
+ refcount_t refcnt;
+ __u16 key_id;
};
#define key_for_each(__key, __list_head) \
@@ -103,8 +104,10 @@ int sctp_auth_send_cid(enum sctp_cid chunk,
int sctp_auth_recv_cid(enum sctp_cid chunk,
const struct sctp_association *asoc);
void sctp_auth_calculate_hmac(const struct sctp_association *asoc,
- struct sk_buff *skb,
- struct sctp_auth_chunk *auth, gfp_t gfp);
+ struct sk_buff *skb, struct sctp_auth_chunk *auth,
+ struct sctp_shared_key *ep_key, gfp_t gfp);
+void sctp_auth_shkey_release(struct sctp_shared_key *sh_key);
+void sctp_auth_shkey_hold(struct sctp_shared_key *sh_key);
/* API Helpers */
int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id);
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 2883c43..2d0e782 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -263,7 +263,8 @@ int sctp_process_asconf_ack(struct sctp_association *asoc,
struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
__u32 new_cum_tsn, size_t nstreams,
struct sctp_fwdtsn_skip *skiplist);
-struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
+struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc,
+ __u16 key_id);
struct sctp_chunk *sctp_make_strreset_req(const struct sctp_association *asoc,
__u16 stream_num, __be16 *stream_list,
bool out, bool in);
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index ec6e46b..49ad67b 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -577,8 +577,12 @@ struct sctp_chunk {
/* This points to the sk_buff containing the actual data. */
struct sk_buff *skb;
- /* In case of GSO packets, this will store the head one */
- struct sk_buff *head_skb;
+ union {
+ /* In case of GSO packets, this will store the head one */
+ struct sk_buff *head_skb;
+ /* In case of auth enabled, this will point to the shkey */
+ struct sctp_shared_key *shkey;
+ };
/* These are the SCTP headers by reverse order in a packet.
* Note that some of these may happen more than once. In that
@@ -1995,6 +1999,7 @@ struct sctp_association {
* The current generated assocaition shared key (secret)
*/
struct sctp_auth_bytes *asoc_shared_key;
+ struct sctp_shared_key *shkey;
/* SCTP AUTH: hmac id of the first peer requested algorithm
* that we support.
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index 00667c5..e5214fd 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -101,13 +101,14 @@ struct sctp_shared_key *sctp_auth_shkey_create(__u16
key_id, gfp_t gfp)
return NULL;
INIT_LIST_HEAD(&new->key_list);
+ refcount_set(&new->refcnt, 1);
new->key_id = key_id;
return new;
}
/* Free the shared key structure */
-static void sctp_auth_shkey_free(struct sctp_shared_key *sh_key)
+static void sctp_auth_shkey_destroy(struct sctp_shared_key *sh_key)
{
BUG_ON(!list_empty(&sh_key->key_list));
sctp_auth_key_put(sh_key->key);
@@ -115,6 +116,17 @@ static void sctp_auth_shkey_free(struct sctp_shared_key
*sh_key)
kfree(sh_key);
}
+void sctp_auth_shkey_release(struct sctp_shared_key *sh_key)
+{
+ if (refcount_dec_and_test(&sh_key->refcnt))
+ sctp_auth_shkey_de
[PATCH net-next 5/5] sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT
This patch is to add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT,
as described in section 6.1.8 of RFC6458.
SCTP_AUTH_NO_AUTH: This report indicates that the peer does not
support SCTP authentication as defined in [RFC4895].
Note that the implementation is quite similar as that of
SCTP_ADAPTATION_INDICATION.
Signed-off-by: Xin Long
---
include/net/sctp/command.h | 1 +
include/uapi/linux/sctp.h | 1 +
net/sctp/sm_sideeffect.c | 13 +
net/sctp/sm_statefuns.c| 43 +--
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
index b55c6a4..6640f84 100644
--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -100,6 +100,7 @@ enum sctp_verb {
SCTP_CMD_SET_SK_ERR, /* Set sk_err */
SCTP_CMD_ASSOC_CHANGE, /* generate and send assoc_change event */
SCTP_CMD_ADAPTATION_IND, /* generate and send adaptation event */
+ SCTP_CMD_PEER_NO_AUTH, /* generate and send authentication event */
SCTP_CMD_ASSOC_SHKEY,/* generate the association shared keys */
SCTP_CMD_T1_RETRAN, /* Mark for retransmission after T1 timeout */
SCTP_CMD_UPDATE_INITTAG, /* Update peer inittag */
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index 18ebbfe..afd4346 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -522,6 +522,7 @@ enum {
SCTP_AUTH_NEW_KEY,
#defineSCTP_AUTH_NEWKEYSCTP_AUTH_NEW_KEY /* compatible with
before */
SCTP_AUTH_FREE_KEY,
+ SCTP_AUTH_NO_AUTH,
};
/*
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index b71e7fb..298112c 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1049,6 +1049,16 @@ static void sctp_cmd_assoc_change(struct sctp_cmd_seq
*commands,
asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
}
+static void sctp_cmd_peer_no_auth(struct sctp_cmd_seq *commands,
+ struct sctp_association *asoc)
+{
+ struct sctp_ulpevent *ev;
+
+ ev = sctp_ulpevent_make_authkey(asoc, 0, SCTP_AUTH_NO_AUTH, GFP_ATOMIC);
+ if (ev)
+ asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
+}
+
/* Helper function to generate an adaptation indication event */
static void sctp_cmd_adaptation_ind(struct sctp_cmd_seq *commands,
struct sctp_association *asoc)
@@ -1755,6 +1765,9 @@ static int sctp_cmd_interpreter(enum sctp_event
event_type,
case SCTP_CMD_ADAPTATION_IND:
sctp_cmd_adaptation_ind(commands, asoc);
break;
+ case SCTP_CMD_PEER_NO_AUTH:
+ sctp_cmd_peer_no_auth(commands, asoc);
+ break;
case SCTP_CMD_ASSOC_SHKEY:
error = sctp_auth_asoc_init_active_key(asoc,
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 1e41dee..cc56a67 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -659,7 +659,7 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
void *arg,
struct sctp_cmd_seq *commands)
{
- struct sctp_ulpevent *ev, *ai_ev = NULL;
+ struct sctp_ulpevent *ev, *ai_ev = NULL, *auth_ev = NULL;
struct sctp_association *new_asoc;
struct sctp_init_chunk *peer_init;
struct sctp_chunk *chunk = arg;
@@ -820,6 +820,14 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
goto nomem_aiev;
}
+ if (!new_asoc->peer.auth_capable) {
+ auth_ev = sctp_ulpevent_make_authkey(new_asoc, 0,
+SCTP_AUTH_NO_AUTH,
+GFP_ATOMIC);
+ if (!auth_ev)
+ goto nomem_authev;
+ }
+
/* Add all the state machine commands now since we've created
* everything. This way we don't introduce memory corruptions
* during side-effect processing and correclty count established
@@ -847,8 +855,14 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
SCTP_ULPEVENT(ai_ev));
+ if (auth_ev)
+ sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
+ SCTP_ULPEVENT(auth_ev));
+
return SCTP_DISPOSITION_CONSUME;
+nomem_authev:
+ sctp_ulpevent_free(ai_ev);
nomem_aiev:
sctp_ulpevent_free(ev);
nomem_ev:
@@ -953,6 +967,15 @@ enum sctp_disposition sctp_sf_do_5_1E_ca(struct net *net,
SCTP_ULPEVENT(ev));
}
+ if (!asoc->peer.auth_capable) {
+ ev = sctp_ulpevent_make_authke
[PATCH net-next 3/5] sctp: add sockopt SCTP_AUTH_DEACTIVATE_KEY
This patch is to add sockopt SCTP_AUTH_DEACTIVATE_KEY, as described in
section 8.3.4 of RFC6458.
This set option indicates that the application will no longer send user
messages using the indicated key identifier.
Note that RFC requires that only deactivated keys that are no longer used
by an association can be deleted, but for the backward compatibility, it
is not to check deactivated when deleting or replacing one sh_key.
Signed-off-by: Xin Long
---
include/net/sctp/auth.h | 12 ++--
include/uapi/linux/sctp.h | 1 +
net/sctp/auth.c | 46 +++---
net/sctp/socket.c | 31 +++
4 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
index 017c1aa..687e7f8 100644
--- a/include/net/sctp/auth.h
+++ b/include/net/sctp/auth.h
@@ -65,6 +65,7 @@ struct sctp_shared_key {
struct sctp_auth_bytes *key;
refcount_t refcnt;
__u16 key_id;
+ __u8 deactivated;
};
#define key_for_each(__key, __list_head) \
@@ -113,14 +114,13 @@ void sctp_auth_shkey_hold(struct sctp_shared_key *sh_key);
int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id);
int sctp_auth_ep_set_hmacs(struct sctp_endpoint *ep,
struct sctp_hmacalgo *hmacs);
-int sctp_auth_set_key(struct sctp_endpoint *ep,
- struct sctp_association *asoc,
+int sctp_auth_set_key(struct sctp_endpoint *ep, struct sctp_association *asoc,
struct sctp_authkey *auth_key);
int sctp_auth_set_active_key(struct sctp_endpoint *ep,
- struct sctp_association *asoc,
- __u16 key_id);
+struct sctp_association *asoc, __u16 key_id);
int sctp_auth_del_key_id(struct sctp_endpoint *ep,
- struct sctp_association *asoc,
- __u16 key_id);
+struct sctp_association *asoc, __u16 key_id);
+int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
+ struct sctp_association *asoc, __u16 key_id);
#endif
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index 47e781e..08fc313 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -99,6 +99,7 @@ typedef __s32 sctp_assoc_t;
#define SCTP_RECVRCVINFO 32
#define SCTP_RECVNXTINFO 33
#define SCTP_DEFAULT_SNDINFO 34
+#define SCTP_AUTH_DEACTIVATE_KEY 35
/* Internal Socket Options. Some of the sctp library functions are
* implemented using these socket options.
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index e5214fd..a073123 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -449,8 +449,11 @@ struct sctp_shared_key *sctp_auth_get_shkey(
/* First search associations set of endpoint pair shared keys */
key_for_each(key, &asoc->endpoint_shared_keys) {
- if (key->key_id == key_id)
- return key;
+ if (key->key_id == key_id) {
+ if (!key->deactivated)
+ return key;
+ break;
+ }
}
return NULL;
@@ -905,7 +908,7 @@ int sctp_auth_set_active_key(struct sctp_endpoint *ep,
}
}
- if (!found)
+ if (!found || key->deactivated)
return -EINVAL;
if (asoc) {
@@ -956,3 +959,40 @@ int sctp_auth_del_key_id(struct sctp_endpoint *ep,
return 0;
}
+
+int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
+ struct sctp_association *asoc, __u16 key_id)
+{
+ struct sctp_shared_key *key;
+ struct list_head *sh_keys;
+ int found = 0;
+
+ /* The key identifier MUST NOT be the current active key
+* The key identifier MUST correst to an existing key
+*/
+ if (asoc) {
+ if (asoc->active_key_id == key_id)
+ return -EINVAL;
+
+ sh_keys = &asoc->endpoint_shared_keys;
+ } else {
+ if (ep->active_key_id == key_id)
+ return -EINVAL;
+
+ sh_keys = &ep->endpoint_shared_keys;
+ }
+
+ key_for_each(key, sh_keys) {
+ if (key->key_id == key_id) {
+ found = 1;
+ break;
+ }
+ }
+
+ if (!found)
+ return -EINVAL;
+
+ key->deactivated = 1;
+
+ return 0;
+}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9ffdecb..65cc354 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3647,6 +3647,33 @@ static int sctp_setsockopt_del_key(struct sock *sk,
}
/*
+ * 8.3.4 Deactivate a Shared Key (SCTP_AUTH_DEACTIVATE_KEY)
+ *
+ * This set option will deactivate a shared secret key.
+ */
+static int sctp_setsockopt_deactivate_key(struct sock *sk, char __user *optval,
+
[PATCH net-next 4/5] sctp: add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT
This patch is to add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT,
as described in section 6.1.8 of RFC6458.
SCTP_AUTH_FREE_KEY: This report indicates that the SCTP
implementation will no longer use the key identifier specified
in auth_keynumber.
After deactivating a key, it would never be used again, which means
it's refcnt can't be held/increased by new chunks. But there may be
some chunks in out queue still using it. So only when refcnt is 1,
which means no chunk in outqueue is using/holding this key either,
this EVENT would be sent.
When users receive this notification, they could do DEL_KEY sockopt to
remove this shkey, and also tell the peer that this key won't be used
in any chunk thoroughly from now on, then the peer can remove it as
well safely.
Signed-off-by: Xin Long
---
include/uapi/linux/sctp.h | 6 +-
net/sctp/auth.c | 14 ++
net/sctp/sm_make_chunk.c | 20 +++-
net/sctp/sm_statefuns.c | 2 +-
net/sctp/socket.c | 19 ++-
5 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index 08fc313..18ebbfe 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -518,7 +518,11 @@ struct sctp_authkey_event {
sctp_assoc_t auth_assoc_id;
};
-enum { SCTP_AUTH_NEWKEY = 0, };
+enum {
+ SCTP_AUTH_NEW_KEY,
+#defineSCTP_AUTH_NEWKEYSCTP_AUTH_NEW_KEY /* compatible with
before */
+ SCTP_AUTH_FREE_KEY,
+};
/*
* 6.1.9. SCTP_SENDER_DRY_EVENT
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index a073123..e64630c 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -992,6 +992,20 @@ int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
if (!found)
return -EINVAL;
+ /* refcnt == 1 and !list_empty mean it's not being used anywhere
+* and deactivated will be set, so it's time to notify userland
+* that this shkey can be freed.
+*/
+ if (asoc && !list_empty(&key->key_list) &&
+ refcount_read(&key->refcnt) == 1) {
+ struct sctp_ulpevent *ev;
+
+ ev = sctp_ulpevent_make_authkey(asoc, key->key_id,
+ SCTP_AUTH_FREE_KEY, GFP_KERNEL);
+ if (ev)
+ asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
+ }
+
key->deactivated = 1;
return 0;
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 10f071c..cc20bc3 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -89,8 +89,26 @@ static void sctp_control_release_owner(struct sk_buff *skb)
{
struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
- if (chunk->shkey)
+ if (chunk->shkey) {
+ struct sctp_shared_key *shkey = chunk->shkey;
+ struct sctp_association *asoc = chunk->asoc;
+
+ /* refcnt == 2 and !list_empty mean after this release, it's
+* not being used anywhere, and it's time to notify userland
+* that this shkey can be freed if it's been deactivated.
+*/
+ if (shkey->deactivated && !list_empty(&shkey->key_list) &&
+ refcount_read(&shkey->refcnt) == 2) {
+ struct sctp_ulpevent *ev;
+
+ ev = sctp_ulpevent_make_authkey(asoc, shkey->key_id,
+ SCTP_AUTH_FREE_KEY,
+ GFP_KERNEL);
+ if (ev)
+ asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
+ }
sctp_auth_shkey_release(chunk->shkey);
+ }
}
static void sctp_control_set_owner_w(struct sctp_chunk *chunk)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 792e0e2..1e41dee 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -4246,7 +4246,7 @@ enum sctp_disposition sctp_sf_eat_auth(struct net *net,
struct sctp_ulpevent *ev;
ev = sctp_ulpevent_make_authkey(asoc, ntohs(auth_hdr->shkey_id),
- SCTP_AUTH_NEWKEY, GFP_ATOMIC);
+ SCTP_AUTH_NEW_KEY, GFP_ATOMIC);
if (!ev)
return -ENOMEM;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 65cc354..aeecdd6 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -8166,8 +8166,25 @@ static void sctp_wfree(struct sk_buff *skb)
sk->sk_wmem_queued -= skb->truesize;
sk_mem_uncharge(sk, skb->truesize);
- if (chunk->shkey)
+ if (chunk->shkey) {
+ struct sctp_shared_key *shkey = chunk->shkey;
+
+ /* refcnt == 2 and !list_empty mean after this release, it's
+* not being used anywhere, and it's time to notify
[PATCH net-next 2/5] sctp: add support for SCTP AUTH Information for sendmsg
This patch is to add support for SCTP AUTH Information for sendmsg,
as described in section 5.3.8 of RFC6458.
With this option, you can provide shared key identifier used for
sending the user message.
It's also a necessary send info for sctp_sendv.
Note that it reuses sinfo->sinfo_tsn to indicate if this option is
set and sinfo->sinfo_ssn to save the shkey ID which can be 0.
Signed-off-by: Xin Long
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 14 +-
net/sctp/chunk.c | 11 ++-
net/sctp/socket.c | 23 +++
4 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 49ad67b..012fb3e 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -2118,6 +2118,7 @@ struct sctp_cmsgs {
struct sctp_sndrcvinfo *srinfo;
struct sctp_sndinfo *sinfo;
struct sctp_prinfo *prinfo;
+ struct sctp_authinfo *authinfo;
struct msghdr *addrs_msg;
};
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index e94b6d2..47e781e 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -273,6 +273,18 @@ struct sctp_prinfo {
__u32 pr_value;
};
+/* 5.3.8 SCTP AUTH Information Structure (SCTP_AUTHINFO)
+ *
+ * This cmsghdr structure specifies SCTP options for sendmsg().
+ *
+ * cmsg_levelcmsg_type cmsg_data[]
+ * ---
+ * IPPROTO_SCTP SCTP_AUTHINFO struct sctp_authinfo
+ */
+struct sctp_authinfo {
+ __u16 auth_keynumber;
+};
+
/*
* sinfo_flags: 16 bits (unsigned integer)
*
@@ -310,7 +322,7 @@ typedef enum sctp_cmsg_type {
#define SCTP_NXTINFO SCTP_NXTINFO
SCTP_PRINFO,/* 5.3.7 SCTP PR-SCTP Information Structure */
#define SCTP_PRINFOSCTP_PRINFO
- SCTP_AUTHINFO, /* 5.3.8 SCTP AUTH Information Structure
(RESERVED) */
+ SCTP_AUTHINFO, /* 5.3.8 SCTP AUTH Information Structure */
#define SCTP_AUTHINFO SCTP_AUTHINFO
SCTP_DSTADDRV4, /* 5.3.9 SCTP Destination IPv4 Address
Structure */
#define SCTP_DSTADDRV4 SCTP_DSTADDRV4
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index 9f28a9a..f889a84 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chunk.c
@@ -206,7 +206,16 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct
sctp_association *asoc,
max_data -= SCTP_PAD4(sizeof(struct sctp_auth_chunk) +
hmac_desc->hmac_len);
- shkey = asoc->shkey;
+ if (sinfo->sinfo_tsn &&
+ sinfo->sinfo_ssn != asoc->active_key_id) {
+ shkey = sctp_auth_get_shkey(asoc, sinfo->sinfo_ssn);
+ if (!shkey) {
+ err = -EINVAL;
+ goto errout;
+ }
+ } else {
+ shkey = asoc->shkey;
+ }
}
/* Check what's our max considering the above */
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 003a4ad..9ffdecb 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1987,6 +1987,14 @@ static void sctp_sendmsg_update_sinfo(struct
sctp_association *asoc,
if (!cmsgs->srinfo && !cmsgs->prinfo)
sinfo->sinfo_timetolive = asoc->default_timetolive;
+
+ if (cmsgs->authinfo) {
+ /* Reuse sinfo_tsn to indicate that authinfo was set and
+* sinfo_ssn to save the keyid on tx path.
+*/
+ sinfo->sinfo_tsn = 1;
+ sinfo->sinfo_ssn = cmsgs->authinfo->auth_keynumber;
+ }
}
static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
@@ -7874,6 +7882,21 @@ static int sctp_msghdr_parse(const struct msghdr *msg,
struct sctp_cmsgs *cmsgs)
if (cmsgs->prinfo->pr_policy == SCTP_PR_SCTP_NONE)
cmsgs->prinfo->pr_value = 0;
break;
+ case SCTP_AUTHINFO:
+ /* SCTP Socket API Extension
+* 5.3.8 SCTP AUTH Information Structure (SCTP_AUTHINFO)
+*
+* This cmsghdr structure specifies SCTP options for
sendmsg().
+*
+* cmsg_levelcmsg_type cmsg_data[]
+* -
+* IPPROTO_SCTP SCTP_AUTHINFO struct sctp_authinfo
+*/
+ if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct
sctp_authinfo)))
+ return -EINVAL;
+
+ cmsgs->authinfo = CMSG_DATA(cmsg);
+ break;
case SCTP_DSTADDRV4:
case SCTP_DSTADDRV6:
Re: [PATCH] can: enable multi-queue for SocketCAN devices
On 03/14/2018 11:33 AM, Mark Jonas wrote:
> From: Zhu Yi
>
> The existing SocketCAN implementation provides alloc_candev() to
> allocate a CAN device using a single Tx and Rx queue. This can lead to
> priority inversion in case the single Tx queue is already full with low
> priority messages and a high priority message needs to be sent while the
> bus is fully loaded with medium priority messages.
>
> This problem can be solved by using the existing multi-queue support of
> the network subsystem. The commit makes it possible to use multi-queue in
> the CAN subsystem in the same way it is used in the Ethernet subsystem
> by adding an alloc_candev_mqs() call and accompanying macros. With this
> support a CAN device can use multi-queue qdisc (e.g. mqprio) to avoid
> the aforementioned priority inversion.
>
> The existing functionality of alloc_candev() is the same as before.
>
> CAN devices need to have prioritized multiple hardware queues or are
> able to abort waiting for arbitration to make sensible use of
> multi-queues.
>
> Signed-off-by: Zhu Yi
> Signed-off-by: Mark Jonas
> Reviewed-by: Heiko Schocher
Do you have a driver or a patch to make a driver mq aware?
> ---
> drivers/net/can/dev.c | 8 +---
> include/linux/can/dev.h | 7 ++-
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> index b177956..636f853 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
> @@ -703,7 +703,8 @@ EXPORT_SYMBOL_GPL(alloc_can_err_skb);
> /*
> * Allocate and setup space for the CAN network device
> */
> -struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max)
> +struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int
> echo_skb_max,
> + unsigned int txqs, unsigned int rxqs)
> {
> struct net_device *dev;
> struct can_priv *priv;
> @@ -715,7 +716,8 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned
> int echo_skb_max)
> else
> size = sizeof_priv;
>
> - dev = alloc_netdev(size, "can%d", NET_NAME_UNKNOWN, can_setup);
> + dev = alloc_netdev_mqs(size, "can%d", NET_NAME_UNKNOWN, can_setup,
> +txqs, rxqs);
> if (!dev)
> return NULL;
>
> @@ -734,7 +736,7 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned
> int echo_skb_max)
>
> return dev;
> }
> -EXPORT_SYMBOL_GPL(alloc_candev);
> +EXPORT_SYMBOL_GPL(alloc_candev_mqs);
>
> /*
> * Free space of the CAN network device
> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> index 055aaf5..a83e1f6 100644
> --- a/include/linux/can/dev.h
> +++ b/include/linux/can/dev.h
> @@ -143,7 +143,12 @@ u8 can_dlc2len(u8 can_dlc);
> /* map the sanitized data length to an appropriate data length code */
> u8 can_len2dlc(u8 len);
>
> -struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max);
> +struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int
> echo_skb_max,
> + unsigned int txqs, unsigned int rxqs);
> +#define alloc_candev(sizeof_priv, echo_skb_max) \
> + alloc_candev_mqs(sizeof_priv, echo_skb_max, 1, 1)
> +#define alloc_candev_mq(sizeof_priv, echo_skb_max, count) \
> + alloc_candev_mqs(sizeof_priv, echo_skb_max, count, count)
Can you make this a static inline function.
> void free_candev(struct net_device *dev);
>
> /* a candev safe wrapper around netdev_priv */
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[PATCH] can: enable multi-queue for SocketCAN devices
From: Zhu Yi
The existing SocketCAN implementation provides alloc_candev() to
allocate a CAN device using a single Tx and Rx queue. This can lead to
priority inversion in case the single Tx queue is already full with low
priority messages and a high priority message needs to be sent while the
bus is fully loaded with medium priority messages.
This problem can be solved by using the existing multi-queue support of
the network subsystem. The commit makes it possible to use multi-queue in
the CAN subsystem in the same way it is used in the Ethernet subsystem
by adding an alloc_candev_mqs() call and accompanying macros. With this
support a CAN device can use multi-queue qdisc (e.g. mqprio) to avoid
the aforementioned priority inversion.
The existing functionality of alloc_candev() is the same as before.
CAN devices need to have prioritized multiple hardware queues or are
able to abort waiting for arbitration to make sensible use of
multi-queues.
Signed-off-by: Zhu Yi
Signed-off-by: Mark Jonas
Reviewed-by: Heiko Schocher
---
drivers/net/can/dev.c | 8 +---
include/linux/can/dev.h | 7 ++-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index b177956..636f853 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -703,7 +703,8 @@ EXPORT_SYMBOL_GPL(alloc_can_err_skb);
/*
* Allocate and setup space for the CAN network device
*/
-struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max)
+struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
+ unsigned int txqs, unsigned int rxqs)
{
struct net_device *dev;
struct can_priv *priv;
@@ -715,7 +716,8 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned
int echo_skb_max)
else
size = sizeof_priv;
- dev = alloc_netdev(size, "can%d", NET_NAME_UNKNOWN, can_setup);
+ dev = alloc_netdev_mqs(size, "can%d", NET_NAME_UNKNOWN, can_setup,
+ txqs, rxqs);
if (!dev)
return NULL;
@@ -734,7 +736,7 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned
int echo_skb_max)
return dev;
}
-EXPORT_SYMBOL_GPL(alloc_candev);
+EXPORT_SYMBOL_GPL(alloc_candev_mqs);
/*
* Free space of the CAN network device
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 055aaf5..a83e1f6 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -143,7 +143,12 @@ u8 can_dlc2len(u8 can_dlc);
/* map the sanitized data length to an appropriate data length code */
u8 can_len2dlc(u8 len);
-struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max);
+struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
+ unsigned int txqs, unsigned int rxqs);
+#define alloc_candev(sizeof_priv, echo_skb_max) \
+ alloc_candev_mqs(sizeof_priv, echo_skb_max, 1, 1)
+#define alloc_candev_mq(sizeof_priv, echo_skb_max, count) \
+ alloc_candev_mqs(sizeof_priv, echo_skb_max, count, count)
void free_candev(struct net_device *dev);
/* a candev safe wrapper around netdev_priv */
--
2.7.4
RE: [PATCH] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca > Sent: 13 March 2018 22:01 > 2018-03-13 20:58 GMT+01:00 Vivien Didelot > : > > Hi Salvatore, > > Hi Vivien, > > > Salvatore Mesoraca writes: > > > >> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid > >> 2 VLAs[1] by using DSA_MAX_PORTS instead of ds->num_ports. > >> > >> [1] https://lkml.org/lkml/2018/3/7/621 > >> > >> Signed-off-by: Salvatore Mesoraca > > > > NAK. > > > > We are in the process to remove hardcoded limits such as DSA_MAX_PORTS > > and DSA_MAX_SWITCHES, so we have to stick with ds->num_ports. > > I can rewrite the patch using kmalloc. > Although, if ds->num_ports will always be less than or equal to 12, it > should be better to > just use DSA_MAX_PORTS. Isn't using DECLARE_BITMAP() completely OTT when the maximum size is less than the number of bits in a word? David
Re: [RFC net-next 2/6] driver: net: bonding: allow registration of tc offload callbacks in bond
On Wed, Mar 14, 2018 at 11:50 AM, Jiri Pirko wrote: > Tue, Mar 13, 2018 at 04:51:02PM CET, gerlitz...@gmail.com wrote: >>On Wed, Mar 7, 2018 at 12:57 PM, Jiri Pirko wrote: >>This sounds nice for the case where one install ingress tc rules on >>the bond (lets >>call them type 1, see next) >> >>One obstacle pointed by my colleague, Rabie, is that when the upper layer >>issues stat call on the filter, they will get two replies, this can confuse >>them >>and lead to wrong decisions (aging). I wonder if/how we can set a knob > > The bonding itself would not do anything on stats update > command (TC_CLSFLOWER_STATS for example). Only the slaves would do > update. So there will be only reply from slaves. > > Bond/team is just going to probagare block bind/unbind down. Nothing else. Do we agree that user space will get the replies of all lower (slave) devices, or I am missing something here? >>2. bond being egress port of a rule >>2.1 VF rep --> uplink 0 >>2.2 VF rep --> uplink 1 >> >>and we do that in the driver (add/del two HW rules, combine the stat >>results, etc) > > That is up to the driver. If the driver can share block between 2 > devices, he can do that. If he cannot share, it will just report stats > for every device separatelly (2 block cbs registered) and tc will see > them both together. No need to do anything in driver. right >>3. ingress rule on VF rep port with shared tunnel device being the >>egress (encap) >>and where the routing of the underlay (tunnel) goes through LAG. > Same as "2." ok >>4. ingress rule shared tunnel device being the ingress and VF rep port >>being the egress (decap) > I don't follow :( the way tunneling is handled in tc classifier/action is encap: ingress: net port, action1: tunnel key set action2: mirred to shared-tunnel device decap: ingress: shared tunnel device, action1: tunnel key unset action2: mirred to net port type 4 are the decap rules, when we offload it to as HW ACL we stretch the line and the ingress in a HW port too (e.g uplink port in NICs) >>this uses the egdev facility to be offloaded into the our driver, and >>then in the driver >>we will treat it like type 1, two rules need to be installed into HW, >>but now, we can't delegate them >>from the vxlan device b/c it has no direct connection with the bond. > I see another thing we need to sanitize: vxlan rule ingress match action > mirred redirect to lag right, we don't have for NIC but for switch ASIC, I guess it is applicable
RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()
From: Kees Cook > Sent: 13 March 2018 22:15 ... > I'll send a "const_max()" which will refuse to work on > non-constant-values (so it doesn't get accidentally used on variables > that could be exposed to double-evaluation), and will work for stack > array declarations (to avoid the overly-sensitive -Wvla checks). ISTR the definitions were of the form: char foo[max(sizeof (struct bah), sizeof (struct baz))]; This doesn't generate a 'foo' with the required alignment. It would be much better to use a union. David
pull-request: can 2018-03-14
Hello David, this is a pull request of two patches for net/master. Both patches are by Andri Yngvason and fix problems in the cc770 driver, that show up quite fast on RT systems, but also on non RT setups. regards, Marc --- The following changes since commit f89782c2d131e6eae0d1ea2569ba76bc4c5875fe: qed: Use after free in qed_rdma_free() (2018-03-13 10:54:17 -0400) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.16-20180314 for you to fetch changes up to 746201235b3f876792099079f4c6fea941d76183: can: cc770: Fix queue stall & dropped RTR reply (2018-03-14 13:01:22 +0100) linux-can-fixes-for-4.16-20180314 Andri Yngvason (2): can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack can: cc770: Fix queue stall & dropped RTR reply drivers/net/can/cc770/cc770.c | 103 ++ drivers/net/can/cc770/cc770.h | 2 + 2 files changed, 65 insertions(+), 40 deletions(-)
[PATCH 1/2] can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack
From: Andri Yngvason This has been reported to cause stalls on rt-linux. Suggested-by: Richard Weinberger Tested-by: Richard Weinberger Signed-off-by: Andri Yngvason Cc: linux-stable Signed-off-by: Marc Kleine-Budde --- drivers/net/can/cc770/cc770.c | 15 --- 1 file changed, 15 deletions(-) diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c index 1e37313054f3..9fed163262e0 100644 --- a/drivers/net/can/cc770/cc770.c +++ b/drivers/net/can/cc770/cc770.c @@ -447,15 +447,6 @@ static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev) stats->tx_bytes += dlc; - - /* -* HM: We had some cases of repeated IRQs so make sure the -* INT is acknowledged I know it's already further up, but -* doing again fixed the issue -*/ - cc770_write_reg(priv, msgobj[mo].ctrl0, - MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES); - return NETDEV_TX_OK; } @@ -684,12 +675,6 @@ static void cc770_tx_interrupt(struct net_device *dev, unsigned int o) /* Nothing more to send, switch off interrupts */ cc770_write_reg(priv, msgobj[mo].ctrl0, MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES); - /* -* We had some cases of repeated IRQ so make sure the -* INT is acknowledged -*/ - cc770_write_reg(priv, msgobj[mo].ctrl0, - MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES); stats->tx_packets++; can_get_echo_skb(dev, 0); -- 2.16.1
[PATCH 2/2] can: cc770: Fix queue stall & dropped RTR reply
From: Andri Yngvason
While waiting for the TX object to send an RTR, an external message with a
matching id can overwrite the TX data. In this case we must call the rx
routine and then try transmitting the message that was overwritten again.
The queue was being stalled because the RX event did not generate an
interrupt to wake up the queue again and the TX event did not happen
because the TXRQST flag is reset by the chip when new data is received.
According to the CC770 datasheet the id of a message object should not be
changed while the MSGVAL bit is set. This has been fixed by resetting the
MSGVAL bit before modifying the object in the transmit function and setting
it after. It is not enough to set & reset CPUUPD.
It is important to keep the MSGVAL bit reset while the message object is
being modified. Otherwise, during RTR transmission, a frame with matching
id could trigger an rx-interrupt, which would cause a race condition
between the interrupt routine and the transmit function.
Signed-off-by: Andri Yngvason
Tested-by: Richard Weinberger
Cc: linux-stable
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/cc770/cc770.c | 94 ++-
drivers/net/can/cc770/cc770.h | 2 +
2 files changed, 68 insertions(+), 28 deletions(-)
diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c
index 9fed163262e0..2743d82d4424 100644
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -390,37 +390,23 @@ static int cc770_get_berr_counter(const struct net_device
*dev,
return 0;
}
-static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device
*dev)
+static void cc770_tx(struct net_device *dev, int mo)
{
struct cc770_priv *priv = netdev_priv(dev);
- struct net_device_stats *stats = &dev->stats;
- struct can_frame *cf = (struct can_frame *)skb->data;
- unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+ struct can_frame *cf = (struct can_frame *)priv->tx_skb->data;
u8 dlc, rtr;
u32 id;
int i;
- if (can_dropped_invalid_skb(dev, skb))
- return NETDEV_TX_OK;
-
- if ((cc770_read_reg(priv,
- msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
- netdev_err(dev, "TX register is still occupied!\n");
- return NETDEV_TX_BUSY;
- }
-
- netif_stop_queue(dev);
-
dlc = cf->can_dlc;
id = cf->can_id;
- if (cf->can_id & CAN_RTR_FLAG)
- rtr = 0;
- else
- rtr = MSGCFG_DIR;
+ rtr = cf->can_id & CAN_RTR_FLAG ? 0 : MSGCFG_DIR;
+
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
cc770_write_reg(priv, msgobj[mo].ctrl1,
RMTPND_RES | TXRQST_RES | CPUUPD_SET | NEWDAT_RES);
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_SET | TXIE_SET | RXIE_RES | INTPND_RES);
+
if (id & CAN_EFF_FLAG) {
id &= CAN_EFF_MASK;
cc770_write_reg(priv, msgobj[mo].config,
@@ -439,13 +425,30 @@ static netdev_tx_t cc770_start_xmit(struct sk_buff *skb,
struct net_device *dev)
for (i = 0; i < dlc; i++)
cc770_write_reg(priv, msgobj[mo].data[i], cf->data[i]);
- /* Store echo skb before starting the transfer */
- can_put_echo_skb(skb, dev, 0);
-
cc770_write_reg(priv, msgobj[mo].ctrl1,
- RMTPND_RES | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ RMTPND_UNC | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_SET | TXIE_SET | RXIE_SET | INTPND_UNC);
+}
+
+static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device
*dev)
+{
+ struct cc770_priv *priv = netdev_priv(dev);
+ unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+
+ if (can_dropped_invalid_skb(dev, skb))
+ return NETDEV_TX_OK;
- stats->tx_bytes += dlc;
+ netif_stop_queue(dev);
+
+ if ((cc770_read_reg(priv,
+ msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
+ netdev_err(dev, "TX register is still occupied!\n");
+ return NETDEV_TX_BUSY;
+ }
+
+ priv->tx_skb = skb;
+ cc770_tx(dev, mo);
return NETDEV_TX_OK;
}
@@ -671,13 +674,47 @@ static void cc770_tx_interrupt(struct net_device *dev,
unsigned int o)
struct cc770_priv *priv = netdev_priv(dev);
struct net_device_stats *stats = &dev->stats;
unsigned int mo = obj2msgobj(o);
+ struct can_frame *cf;
+ u8 ctrl1;
+
+ ctrl1 = cc770_read_reg(priv, msgobj[mo].ctrl1);
- /* Nothing more to send, switch off interrupts */
cc770_write_reg(priv, msgobj[mo].ctrl0,
MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
+ cc770_write_reg(priv, ms
Re: [PATCH 3/7] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs
On 2018-03-14 00:12, Jason Gunthorpe wrote: On Tue, Mar 13, 2018 at 11:20:24PM -0400, Sinan Kaya wrote: Code includes wmb() followed by writel() in multiple places. writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing writel() to writel_relaxed(). Signed-off-by: Sinan Kaya drivers/infiniband/hw/qedr/verbs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Sure matches my understanding of writel_relaxed This is part of a series, should we take just this patch through the rdma tree? If not: Acked-by: Jason Gunthorpe Feel free to take pieces. Thanks, Jason
Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs
On 2018-03-14 01:08, Timur Tabi wrote:
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and
device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32
value)
{
- writel(value, ring->tail);
+ writel_relaxed(value, ring->tail);
}
Why not put the wmb() in this function, or just get rid of the wmb()
in the rest of the file and keep this as writel? That way, you can
avoid the comment and the risk that comes with it.
Sure, both solutions will work. I want to see what the maintainer
prefers. I can repost accordingly.
Re: [PATCH v5 1/6] staging: fsl-dpaa2/ethsw: Add APIs for DPSW object
On Tue, Mar 13, 2018 at 08:51:51AM -0500, Razvan Stefanescu wrote:
> Add the command build/parse APIs for operating on DPSW objects through
> the DPAA2 Management Complex.
>
> Signed-off-by: Razvan Stefanescu
> ---
> Changelog:
> v2:
> - use u8 for en parameter of dpsw_if_set_flooding/broadcast()
> v3:
> - no changes
> v4:
> - adjust to moving MC-bus out of staging
> - fix sparse warnings
> v5:
>- no changes
>
> drivers/staging/fsl-dpaa2/Kconfig |8 +
> drivers/staging/fsl-dpaa2/Makefile |1 +
> drivers/staging/fsl-dpaa2/ethsw/Makefile |7 +
> drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 358 +
> drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 1116
>
> drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 579 +++
> 6 files changed, 2069 insertions(+)
> create mode 100644 drivers/staging/fsl-dpaa2/ethsw/Makefile
> create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
> create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.c
> create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.h
>
> diff --git a/drivers/staging/fsl-dpaa2/Kconfig
> b/drivers/staging/fsl-dpaa2/Kconfig
> index dfff675..8a508ef 100644
> --- a/drivers/staging/fsl-dpaa2/Kconfig
> +++ b/drivers/staging/fsl-dpaa2/Kconfig
> @@ -16,3 +16,11 @@ config FSL_DPAA2_ETH
> ---help---
> Ethernet driver for Freescale DPAA2 SoCs, using the
> Freescale MC bus driver
> +
> +config FSL_DPAA2_ETHSW
> + tristate "Freescale DPAA2 Ethernet Switch"
> + depends on FSL_DPAA2
> + depends on NET_SWITCHDEV
> + ---help---
> + Driver for Freescale DPAA2 Ethernet Switch. Select
> + BRIDGE to have support for bridge tools.
> diff --git a/drivers/staging/fsl-dpaa2/Makefile
> b/drivers/staging/fsl-dpaa2/Makefile
> index 0836ba8..6cfd76b 100644
> --- a/drivers/staging/fsl-dpaa2/Makefile
> +++ b/drivers/staging/fsl-dpaa2/Makefile
> @@ -3,3 +3,4 @@
> #
>
> obj-$(CONFIG_FSL_DPAA2_ETH) += ethernet/
> +obj-$(CONFIG_FSL_DPAA2_ETHSW)+= ethsw/
> diff --git a/drivers/staging/fsl-dpaa2/ethsw/Makefile
> b/drivers/staging/fsl-dpaa2/ethsw/Makefile
> new file mode 100644
> index 000..db137f7
> --- /dev/null
> +++ b/drivers/staging/fsl-dpaa2/ethsw/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the Freescale DPAA2 Ethernet Switch
> +#
> +
> +obj-$(CONFIG_FSL_DPAA2_ETHSW) += dpaa2-ethsw.o
> +
> +dpaa2-ethsw-objs := dpsw.o
> diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
> b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
> new file mode 100644
> index 000..36edef6
> --- /dev/null
> +++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
> @@ -0,0 +1,358 @@
> +/* Copyright 2013-2016 Freescale Semiconductor Inc.
> + * Copyright 2017-2018 NXP
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + * * Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + * * Neither the name of the above-listed copyright holders nor the
> + *names of any contributors may be used to endorse or promote products
> + *derived from this software without specific prior written permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
Can you resend this series and just use the correct SPDX identifiers for
all of the new files, instead of all of this horrid boiler-plate code?
That will save me time when I have to go delete all of this in the near
future :)
Also, why dual license it? Are you _SURE_ you want to do that, and are
totally aware of all of the crazy iss
Re: [PATCH v4 net-next 1/6] net/ipv6: Refactor gateway validation on route add
On Tue, Mar 13, 2018 at 08:29:36AM -0700, David Ahern wrote: > Move gateway validation code from ip6_route_info_create into > ip6_validate_gw. Code move plus adjustments to handle the potential > reset of dev and idev and to make checkpatch happy. > > Signed-off-by: David Ahern Reviewed-by: Ido Schimmel
Re: [PATCH v4 net-next 2/6] net/ipv6: Change address check to always take a device argument
On Tue, Mar 13, 2018 at 08:29:37AM -0700, David Ahern wrote: > ipv6_chk_addr_and_flags determines if an address is a local address and > optionally if it is an address on a specific device. For example, it is > called by ip6_route_info_create to determine if a given gateway address > is a local address. The address check currently does not consider L3 > domains and as a result does not allow a route to be added in one VRF > if the nexthop points to an address in a second VRF. e.g., > > $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23 > Error: Invalid gateway address. > > where 2001:db8:102::23 is an address on an interface in vrf r1. > > ipv6_chk_addr_and_flags needs to allow callers to always pass in a device > with a separate argument to not limit the address to the specific device. > The device is used used to determine the L3 domain of interest. > > To that end add an argument to skip the device check and update callers > to always pass a device where possible and use the new argument to mean > any address in the domain. > > Update a handful of users of ipv6_chk_addr with a NULL dev argument. This > patch handles the change to these callers without adding the domain check. > > ip6_validate_gw needs to handle 2 cases - one where the device is given > as part of the nexthop spec and the other where the device is resolved. > There is at least 1 VRF case where deferring the check to only after > the route lookup has resolved the device fails with an unintuitive error > "RTNETLINK answers: No route to host" as opposed to the preferred > "Error: Gateway can not be a local address." The 'no route to host' > error is because of the fallback to a full lookup. The check is done > twice to avoid this error. > > Signed-off-by: David Ahern Reviewed-by: Ido Schimmel Thanks for the detailed commit message.
Re: pull-request: can 2018-03-14
On Wed, Mar 14, 2018 at 01:05:21PM +0100, Marc Kleine-Budde wrote: > Hello David, > > this is a pull request of two patches for net/master. > > Both patches are by Andri Yngvason and fix problems in the cc770 driver, > that show up quite fast on RT systems, but also on non RT setups. > > regards, > Marc > > --- > > The following changes since commit f89782c2d131e6eae0d1ea2569ba76bc4c5875fe: > > qed: Use after free in qed_rdma_free() (2018-03-13 10:54:17 -0400) > > are available in the Git repository at: > > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git > tags/linux-can-fixes-for-4.16-20180314 > > for you to fetch changes up to 746201235b3f876792099079f4c6fea941d76183: > > can: cc770: Fix queue stall & dropped RTR reply (2018-03-14 13:01:22 +0100) > > ---- > linux-can-fixes-for-4.16-20180314 > > > Andri Yngvason (2): > can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack > can: cc770: Fix queue stall & dropped RTR reply > > drivers/net/can/cc770/cc770.c | 103 > ++ > drivers/net/can/cc770/cc770.h | 2 + > 2 files changed, 65 insertions(+), 40 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-can" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Wait, do we not want Wolfgang's signed-off-by or reviewed-by? Thanks, Andri
Re: [PATCH v4 net-next 3/6] net/ipv6: Add l3mdev check to ipv6_chk_addr_and_flags
On Tue, Mar 13, 2018 at 08:29:38AM -0700, David Ahern wrote: > Lookup the L3 master device for the passed in device. Only consider > addresses on netdev's with the same master device. If the device is > not enslaved or is NULL, then the l3mdev is NULL which means only > devices not enslaved (ie, in the default domain) are considered. > > Signed-off-by: David Ahern Reviewed-by: Ido Schimmel Thanks for working on this. I also encountered this problem when working on the selftests, but didn't have an immediate use case which required me to use a non-linklocal address as a gateway.
Re: [PATCH] can: enable multi-queue for SocketCAN devices
Hello Marc, > > The existing SocketCAN implementation provides alloc_candev() to > > allocate a CAN device using a single Tx and Rx queue. This can lead to > > priority inversion in case the single Tx queue is already full with low > > priority messages and a high priority message needs to be sent while the > > bus is fully loaded with medium priority messages. > > > > This problem can be solved by using the existing multi-queue support of > > the network subsystem. The commit makes it possible to use multi-queue in > > the CAN subsystem in the same way it is used in the Ethernet subsystem > > by adding an alloc_candev_mqs() call and accompanying macros. With this > > support a CAN device can use multi-queue qdisc (e.g. mqprio) to avoid > > the aforementioned priority inversion. > > > > The existing functionality of alloc_candev() is the same as before. > > > > CAN devices need to have prioritized multiple hardware queues or are > > able to abort waiting for arbitration to make sensible use of > > multi-queues. > > > > Signed-off-by: Zhu Yi > > Signed-off-by: Mark Jonas > > Reviewed-by: Heiko Schocher > > Do you have a driver or a patch to make a driver mq aware? Yes, we have CAN hardware with multiple queues and we also have a SocketCAN driver for it. IMHO the driver will be of very little use for the Linux community because the HW is proprietary. Our motivation to separate this patch from the proprietary SocketCAN driver is that we felt it was odd that the multi-queue infrastructure is in place and only very few lines of code are missing to offer it to the CAN networking subsystem as well. Greetings, Mark
Re: [PATCH] can: enable multi-queue for SocketCAN devices
On 03/14/2018 01:26 PM, Jonas Mark (BT-FIR/ENG1) wrote: >> Do you have a driver or a patch to make a driver mq aware? > > Yes, we have CAN hardware with multiple queues and we also have a > SocketCAN driver for it. > > IMHO the driver will be of very little use for the Linux community > because the HW is proprietary. That doesn't matter. It would be the first driver that makes use of the feature, so we can learn from it. And you might get a free review of your driver. > Our motivation to separate this patch from the proprietary SocketCAN > driver Looking at your email address I assume your employer sells devices with this hardware and the driver. So someone has to provide the sources for it anyways to fulfil the GPL license requirements. :) > is that we felt it was odd that the multi-queue infrastructure is in > place and only very few lines of code are missing to offer it to the > CAN networking subsystem as well. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] net: dsa: drop some VLAs in switch.c
2018-03-14 12:24 GMT+01:00 David Laight : > Isn't using DECLARE_BITMAP() completely OTT when the maximum size is less > than the number of bits in a word? It allocates ceiling(size/8) "unsigned long"s, so yes.
[PATCH net 0/2] qed: iWARP related fixes
This series contains two fixes related to iWARP flow. Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Michal Kalderon (2): qed: Fix MPA unalign flow in case header is split across two packets. qed: Fix non TCP packets should be dropped on iWARP ll2 connection drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) -- 2.9.5
[PATCH net 2/2] qed: Fix non TCP packets should be dropped on iWARP ll2 connection
FW workaround. The iWARP LL2 connection did not expect TCP packets
to arrive on it's connection. The fix drops any non-tcp packets
Fixes b5c29ca ("qed: iWARP CM - setup a ll2 connection for handling
SYN packets")
Signed-off-by: Michal Kalderon
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index fefe527..d5d02be 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -1703,6 +1703,13 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
iph = (struct iphdr *)((u8 *)(ethh) + eth_hlen);
if (eth_type == ETH_P_IP) {
+ if (iph->protocol != IPPROTO_TCP) {
+ DP_NOTICE(p_hwfn,
+ "Unexpected ip protocol on ll2 %x\n",
+ iph->protocol);
+ return -EINVAL;
+ }
+
cm_info->local_ip[0] = ntohl(iph->daddr);
cm_info->remote_ip[0] = ntohl(iph->saddr);
cm_info->ip_version = TCP_IPV4;
@@ -1711,6 +1718,14 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
*payload_len = ntohs(iph->tot_len) - ip_hlen;
} else if (eth_type == ETH_P_IPV6) {
ip6h = (struct ipv6hdr *)iph;
+
+ if (ip6h->nexthdr != IPPROTO_TCP) {
+ DP_NOTICE(p_hwfn,
+ "Unexpected ip protocol on ll2 %x\n",
+ iph->protocol);
+ return -EINVAL;
+ }
+
for (i = 0; i < 4; i++) {
cm_info->local_ip[i] =
ntohl(ip6h->daddr.in6_u.u6_addr32[i]);
--
2.9.5
[PATCH net 1/2] qed: Fix MPA unalign flow in case header is split across two packets.
There is a corner case in the MPA unalign flow where a FPDU header is
split over two tcp segments. The length of the first fragment in this
case was not initialized properly and should be '1'
Fixes: c7d1d839 ("qed: Add support for MPA header being split over two tcp
packets")
Signed-off-by: Michal Kalderon
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index ca4a81d..fefe527 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -1928,8 +1928,8 @@ qed_iwarp_update_fpdu_length(struct qed_hwfn *p_hwfn,
/* Missing lower byte is now available */
mpa_len = fpdu->fpdu_length | *mpa_data;
fpdu->fpdu_length = QED_IWARP_FPDU_LEN_WITH_PAD(mpa_len);
- fpdu->mpa_frag_len = fpdu->fpdu_length;
/* one byte of hdr */
+ fpdu->mpa_frag_len = 1;
fpdu->incomplete_bytes = fpdu->fpdu_length - 1;
DP_VERBOSE(p_hwfn,
QED_MSG_RDMA,
--
2.9.5
Re: pull-request: can 2018-03-14
On 03/14/2018 01:24 PM, Andri Yngvason wrote: > On Wed, Mar 14, 2018 at 01:05:21PM +0100, Marc Kleine-Budde wrote: >> Hello David, >> >> this is a pull request of two patches for net/master. >> >> Both patches are by Andri Yngvason and fix problems in the cc770 driver, >> that show up quite fast on RT systems, but also on non RT setups. >> >> regards, >> Marc >> >> --- >> >> The following changes since commit f89782c2d131e6eae0d1ea2569ba76bc4c5875fe: >> >> qed: Use after free in qed_rdma_free() (2018-03-13 10:54:17 -0400) >> >> are available in the Git repository at: >> >> ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git >> tags/linux-can-fixes-for-4.16-20180314 >> >> for you to fetch changes up to 746201235b3f876792099079f4c6fea941d76183: >> >> can: cc770: Fix queue stall & dropped RTR reply (2018-03-14 13:01:22 +0100) >> >> >> linux-can-fixes-for-4.16-20180314 >> >> >> Andri Yngvason (2): >> can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack >> can: cc770: Fix queue stall & dropped RTR reply >> >> drivers/net/can/cc770/cc770.c | 103 >> ++ >> drivers/net/can/cc770/cc770.h | 2 + >> 2 files changed, 65 insertions(+), 40 deletions(-) >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-can" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Wait, do we not want Wolfgang's signed-off-by or reviewed-by? In the review Wolfgang was involved in "[PATCH v2 2/3] can: cc770: Stop queue on NETDEV_TX_BUSY" and we all agreed to drop the patch. The other patches were successfully tested by Richard, AFAIK there are no open points anymore and there was no discussion on these patches for more than 10 days. So assumed the patches are "ready" for upstreaming now. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH net] qede: Fix qedr link update
Link updates were not reported to qedr correctly.
Leading to cases where a link could be down, but qedr
would see it as up.
In addition, once qede was loaded, link state would be up,
regardless of the actual link state.
Signed-off-by: Michal Kalderon
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c
b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 2db70ea..5c28209 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -2067,8 +2067,6 @@ static int qede_load(struct qede_dev *edev, enum
qede_load_mode mode,
link_params.link_up = true;
edev->ops->common->set_link(edev->cdev, &link_params);
- qede_rdma_dev_event_open(edev);
-
edev->state = QEDE_STATE_OPEN;
DP_INFO(edev, "Ending successfully qede load\n");
@@ -2169,12 +2167,14 @@ static void qede_link_update(void *dev, struct
qed_link_output *link)
DP_NOTICE(edev, "Link is up\n");
netif_tx_start_all_queues(edev->ndev);
netif_carrier_on(edev->ndev);
+ qede_rdma_dev_event_open(edev);
}
} else {
if (netif_carrier_ok(edev->ndev)) {
DP_NOTICE(edev, "Link is down\n");
netif_tx_disable(edev->ndev);
netif_carrier_off(edev->ndev);
+ qede_rdma_dev_event_close(edev);
}
}
}
--
2.9.5
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares. This is an obsoleted standard
and its implementation is something that:
1) Most people don't need / want to use
2) Can allow local DoS attacks
3) Breaks AP interfaces in some specific bridge setups
To solve issues it can cause this commit modifies brcmfmac to drop IAPP
packets. If affects:
1) Rx path: driver won't be sending these unwanted packets up.
2) Tx path: driver will reject packets that would trigger STA
disassociation perfromed by a firmware (possible local DoS attack).
It appears there are some Broadcom's clients/users who care about this
feature despite the drawbacks. They can switch it on by a newly added
Kconfig option.
Thanks for taking this approach. Looks fine except for (see below)
Reviewed-by: Arend van Spriel
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/Kconfig| 20 +++
.../wireless/broadcom/brcm80211/brcmfmac/core.c| 39 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig
b/drivers/net/wireless/broadcom/brcm80211/Kconfig
index 9d99eb42d917..876787ef991a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -68,6 +68,26 @@ config BRCMFMAC_PCIE
IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
use the driver for an PCIE wireless card.
+config BRCMFMAC_IAPP
+ bool "Partial support for obsoleted Inter-Access Point Protocol"
+ depends on BRCMFMAC
+ ---help---
+ Most of Broadcom's firmwares can send 802.11f ADD frame every
+ time new STA connects to the AP interface. Some recent ones
+ can also disassociate STA when they receive such a frame.
I do not see any evidence that this would occur only for recent
firmware. That stuff is old and not touched recently.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 19048526b4af..db6987015fb1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
[...]
static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
{
@@ -250,6 +278,12 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff
*skb,
goto done;
}
+ if (!IS_ENABLED(CONFIG_BRCMFMAC_IAPP) && brcmf_skb_is_iapp(skb)) {
+ dev_kfree_skb(skb);
+ ret = -EINVAL;
+ goto done;
+ }
This is not right. The function must return netdev_tx_t type. Here is
kerneldoc of .start_xmit():
* netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb,
* struct net_device *dev);
* Called when a packet needs to be transmitted.
* Returns NETDEV_TX_OK. Can return NETDEV_TX_BUSY, but you should stop
* the queue before that can happen; it's for obsolete devices and weird
* corner cases, but the stack really does a non-trivial amount
* of useless work if you return NETDEV_TX_BUSY.
* Required; cannot be NULL.
You may want to increase dropped netstat or add driver internal
statistic counter so there is visibility of IAPP packets being dropped.
Regards,
Arend
Re: [PATCH net 2/2] qed: Fix non TCP packets should be dropped on iWARP ll2 connection
On Wed, 2018-03-14 at 14:49 +0200, Michal Kalderon wrote:
> FW workaround. The iWARP LL2 connection did not expect TCP packets
> to arrive on it's connection. The fix drops any non-tcp packets
[]
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
[]
> @@ -1703,6 +1703,13 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
> iph = (struct iphdr *)((u8 *)(ethh) + eth_hlen);
>
> if (eth_type == ETH_P_IP) {
> + if (iph->protocol != IPPROTO_TCP) {
> + DP_NOTICE(p_hwfn,
> + "Unexpected ip protocol on ll2 %x\n",
> + iph->protocol);
> + return -EINVAL;
> + }
Perhaps this should be ratelimited.
> +
> cm_info->local_ip[0] = ntohl(iph->daddr);
> cm_info->remote_ip[0] = ntohl(iph->saddr);
> cm_info->ip_version = TCP_IPV4;
> @@ -1711,6 +1718,14 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
> *payload_len = ntohs(iph->tot_len) - ip_hlen;
> } else if (eth_type == ETH_P_IPV6) {
> ip6h = (struct ipv6hdr *)iph;
> +
> + if (ip6h->nexthdr != IPPROTO_TCP) {
> + DP_NOTICE(p_hwfn,
> + "Unexpected ip protocol on ll2 %x\n",
> + iph->protocol);
> + return -EINVAL;
here too
> + }
> +
> for (i = 0; i < 4; i++) {
> cm_info->local_ip[i] =
> ntohl(ip6h->daddr.in6_u.u6_addr32[i]);
Re: pull-request: can 2018-03-14
On Wed, Mar 14, 2018 at 01:52:46PM +0100, Marc Kleine-Budde wrote: > On 03/14/2018 01:24 PM, Andri Yngvason wrote: > > On Wed, Mar 14, 2018 at 01:05:21PM +0100, Marc Kleine-Budde wrote: > >> Hello David, > >> > >> this is a pull request of two patches for net/master. > >> > >> Both patches are by Andri Yngvason and fix problems in the cc770 driver, > >> that show up quite fast on RT systems, but also on non RT setups. > >> > >> regards, > >> Marc > >> > >> --- > >> > >> The following changes since commit > >> f89782c2d131e6eae0d1ea2569ba76bc4c5875fe: > >> > >> qed: Use after free in qed_rdma_free() (2018-03-13 10:54:17 -0400) > >> > >> are available in the Git repository at: > >> > >> > >> ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git > >> tags/linux-can-fixes-for-4.16-20180314 > >> > >> for you to fetch changes up to 746201235b3f876792099079f4c6fea941d76183: > >> > >> can: cc770: Fix queue stall & dropped RTR reply (2018-03-14 13:01:22 > >> +0100) > >> > >> > >> linux-can-fixes-for-4.16-20180314 > >> > >> > >> Andri Yngvason (2): > >> can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack > >> can: cc770: Fix queue stall & dropped RTR reply > >> > >> drivers/net/can/cc770/cc770.c | 103 > >> ++ > >> drivers/net/can/cc770/cc770.h | 2 + > >> 2 files changed, 65 insertions(+), 40 deletions(-) > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-can" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Wait, do we not want Wolfgang's signed-off-by or reviewed-by? > > In the review Wolfgang was involved in "[PATCH v2 2/3] can: cc770: Stop > queue on NETDEV_TX_BUSY" and we all agreed to drop the patch. > > The other patches were successfully tested by Richard, AFAIK there are > no open points anymore and there was no discussion on these patches for > more than 10 days. So assumed the patches are "ready" for upstreaming now. > All right! Thanks, Andri
RE: [PATCH net 2/2] qed: Fix non TCP packets should be dropped on iWARP ll2 connection
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Wednesday, March 14, 2018 3:03 PM
> To: Kalderon, Michal ;
> da...@davemloft.net
> Cc: netdev@vger.kernel.org; dledf...@redhat.com; j...@mellanox.com;
> linux-r...@vger.kernel.org; Elior, Ariel
> Subject: Re: [PATCH net 2/2] qed: Fix non TCP packets should be dropped on
> iWARP ll2 connection
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> On Wed, 2018-03-14 at 14:49 +0200, Michal Kalderon wrote:
> > FW workaround. The iWARP LL2 connection did not expect TCP packets to
> > arrive on it's connection. The fix drops any non-tcp packets
> []
> > diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> > b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> []
> > @@ -1703,6 +1703,13 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn
> *p_hwfn,
> > iph = (struct iphdr *)((u8 *)(ethh) + eth_hlen);
> >
> > if (eth_type == ETH_P_IP) {
> > + if (iph->protocol != IPPROTO_TCP) {
> > + DP_NOTICE(p_hwfn,
> > + "Unexpected ip protocol on ll2 %x\n",
> > + iph->protocol);
> > + return -EINVAL;
> > + }
>
> Perhaps this should be ratelimited.
The rate of the packets that could arrive here is very low. It has to do with a
corner case
Of RoCEv2 packets being sent to a device that was enabled with iWARP.
>
> > +
> > cm_info->local_ip[0] = ntohl(iph->daddr);
> > cm_info->remote_ip[0] = ntohl(iph->saddr);
> > cm_info->ip_version = TCP_IPV4; @@ -1711,6 +1718,14 @@
> > qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
> > *payload_len = ntohs(iph->tot_len) - ip_hlen;
> > } else if (eth_type == ETH_P_IPV6) {
> > ip6h = (struct ipv6hdr *)iph;
> > +
> > + if (ip6h->nexthdr != IPPROTO_TCP) {
> > + DP_NOTICE(p_hwfn,
> > + "Unexpected ip protocol on ll2 %x\n",
> > + iph->protocol);
> > + return -EINVAL;
>
> here too
>
> > + }
> > +
> > for (i = 0; i < 4; i++) {
> > cm_info->local_ip[i] =
> > ntohl(ip6h->daddr.in6_u.u6_addr32[i]);
[PATCH 5/5] dpaa_eth: remove duplicate increment of the tx_errors counter
From: Camelia Groza
The tx_errors counter is incremented by the dpaa_xmit caller.
Signed-off-by: Camelia Groza
Signed-off-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 76b3c9e..fd43f98 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2021,7 +2021,6 @@ static inline int dpaa_xmit(struct dpaa_priv *priv,
}
if (unlikely(err < 0)) {
- percpu_stats->tx_errors++;
percpu_stats->tx_fifo_errors++;
return err;
}
--
2.1.0
[PATCH 4/5] dpaa_eth: increment the RX dropped counter when needed
From: Camelia Groza
Signed-off-by: Camelia Groza
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 3e83d79..76b3c9e 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2321,8 +2321,10 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
skb_len = skb->len;
- if (unlikely(netif_receive_skb(skb) == NET_RX_DROP))
+ if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) {
+ percpu_stats->rx_dropped++;
return qman_cb_dqrr_consume;
+ }
percpu_stats->rx_packets++;
percpu_stats->rx_bytes += skb_len;
--
2.1.0
[PATCH 2/5] dpaa_eth: fix error in dpaa_remove()
The recent changes that make the driver probing compatible with DSA were not propagated in the dpa_remove() function, breaking the module unload function. Using the proper device to address the issue. Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c index 159dc2d..128e0a4 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2871,7 +2871,7 @@ static int dpaa_remove(struct platform_device *pdev) struct device *dev; int err; - dev = &pdev->dev; + dev = pdev->dev.parent; net_dev = dev_get_drvdata(dev); priv = netdev_priv(net_dev); -- 2.1.0
[PATCH 3/5] dpaa_eth: remove duplicate initialization
From: Camelia Groza The fd_format has already been initialized at this point. Signed-off-by: Camelia Groza --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c index 128e0a4..3e83d79 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2289,7 +2289,6 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct qman_portal *portal, vaddr = phys_to_virt(addr); prefetch(vaddr + qm_fd_get_offset(fd)); - fd_format = qm_fd_get_format(fd); /* The only FD types that we may receive are contig and S/G */ WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg)); -- 2.1.0
[PATCH 1/5] soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
The wait_for_completion() call in qman_delete_cgr_safe()
was triggering a scheduling while atomic bug, replacing the
kthread with a smp_call_function_single() call to fix it.
Signed-off-by: Madalin Bucur
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index e4f5bb0..ba3cfa8 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2443,39 +2443,21 @@ struct cgr_comp {
struct completion completion;
};
-static int qman_delete_cgr_thread(void *p)
+static void qman_delete_cgr_smp_call(void *p)
{
- struct cgr_comp *cgr_comp = (struct cgr_comp *)p;
- int ret;
-
- ret = qman_delete_cgr(cgr_comp->cgr);
- complete(&cgr_comp->completion);
-
- return ret;
+ qman_delete_cgr((struct qman_cgr *)p);
}
void qman_delete_cgr_safe(struct qman_cgr *cgr)
{
- struct task_struct *thread;
- struct cgr_comp cgr_comp;
-
preempt_disable();
if (qman_cgr_cpus[cgr->cgrid] != smp_processor_id()) {
- init_completion(&cgr_comp.completion);
- cgr_comp.cgr = cgr;
- thread = kthread_create(qman_delete_cgr_thread, &cgr_comp,
- "cgr_del");
-
- if (IS_ERR(thread))
- goto out;
-
- kthread_bind(thread, qman_cgr_cpus[cgr->cgrid]);
- wake_up_process(thread);
- wait_for_completion(&cgr_comp.completion);
+ smp_call_function_single(qman_cgr_cpus[cgr->cgrid],
+qman_delete_cgr_smp_call, cgr, true);
preempt_enable();
return;
}
-out:
+
qman_delete_cgr(cgr);
preempt_enable();
}
--
2.1.0
[PATCH 0/5] DPAA Ethernet fixes
Hi, This patch set is addressing several issues in the DPAA Ethernet driver suite: - module unload crash caused by wrong reference to device being left in the cleanup code after the DSA related changes - scheduling wile atomic bug in QMan code revealed during dpaa_eth module unload - a couple of error counter fixes, a duplicated init in dpaa_eth. Madalin Camelia Groza (3): dpaa_eth: remove duplicate initialization dpaa_eth: increment the RX dropped counter when needed dpaa_eth: remove duplicate increment of the tx_errors counter Madalin Bucur (2): soc/fsl/qbman: fix issue in qman_delete_cgr_safe() dpaa_eth: fix error in dpaa_remove() drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 drivers/soc/fsl/qbman/qman.c | 28 +- 2 files changed, 9 insertions(+), 27 deletions(-) -- 2.1.0
Re: [PATCH net-next 1/5] sctp: add refcnt support for sh_key
On Wed, Mar 14, 2018 at 07:05:30PM +0800, Xin Long wrote:
> With refcnt support for sh_key, chunks auth sh_keys can be decided
> before enqueuing it. Changing the active key later will not affect
> the chunks already enqueued.
>
> Furthermore, this is necessary when adding the support for authinfo
> for sendmsg in next patch.
>
> Note that struct sctp_chunk can't be grown due to that performance
> drop issue on slow cpu, so it just reuses head_skb memory for shkey
> in sctp_chunk.
>
> Signed-off-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
> ---
> include/net/sctp/auth.h| 9 +++--
> include/net/sctp/sm.h | 3 +-
> include/net/sctp/structs.h | 9 +++--
> net/sctp/auth.c| 86
> +++---
> net/sctp/chunk.c | 5 +++
> net/sctp/output.c | 18 --
> net/sctp/sm_make_chunk.c | 15 ++--
> net/sctp/sm_statefuns.c| 11 +++---
> net/sctp/socket.c | 6
> 9 files changed, 104 insertions(+), 58 deletions(-)
>
> diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
> index e5c57d0..017c1aa 100644
> --- a/include/net/sctp/auth.h
> +++ b/include/net/sctp/auth.h
> @@ -62,8 +62,9 @@ struct sctp_auth_bytes {
> /* Definition for a shared key, weather endpoint or association */
> struct sctp_shared_key {
> struct list_head key_list;
> - __u16 key_id;
> struct sctp_auth_bytes *key;
> + refcount_t refcnt;
> + __u16 key_id;
> };
>
> #define key_for_each(__key, __list_head) \
> @@ -103,8 +104,10 @@ int sctp_auth_send_cid(enum sctp_cid chunk,
> int sctp_auth_recv_cid(enum sctp_cid chunk,
> const struct sctp_association *asoc);
> void sctp_auth_calculate_hmac(const struct sctp_association *asoc,
> - struct sk_buff *skb,
> - struct sctp_auth_chunk *auth, gfp_t gfp);
> + struct sk_buff *skb, struct sctp_auth_chunk *auth,
> + struct sctp_shared_key *ep_key, gfp_t gfp);
> +void sctp_auth_shkey_release(struct sctp_shared_key *sh_key);
> +void sctp_auth_shkey_hold(struct sctp_shared_key *sh_key);
>
> /* API Helpers */
> int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id);
> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> index 2883c43..2d0e782 100644
> --- a/include/net/sctp/sm.h
> +++ b/include/net/sctp/sm.h
> @@ -263,7 +263,8 @@ int sctp_process_asconf_ack(struct sctp_association *asoc,
> struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
> __u32 new_cum_tsn, size_t nstreams,
> struct sctp_fwdtsn_skip *skiplist);
> -struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
> +struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc,
> + __u16 key_id);
> struct sctp_chunk *sctp_make_strreset_req(const struct sctp_association
> *asoc,
> __u16 stream_num, __be16 *stream_list,
> bool out, bool in);
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index ec6e46b..49ad67b 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -577,8 +577,12 @@ struct sctp_chunk {
> /* This points to the sk_buff containing the actual data. */
> struct sk_buff *skb;
>
> - /* In case of GSO packets, this will store the head one */
> - struct sk_buff *head_skb;
> + union {
> + /* In case of GSO packets, this will store the head one */
> + struct sk_buff *head_skb;
> + /* In case of auth enabled, this will point to the shkey */
> + struct sctp_shared_key *shkey;
> + };
>
> /* These are the SCTP headers by reverse order in a packet.
>* Note that some of these may happen more than once. In that
> @@ -1995,6 +1999,7 @@ struct sctp_association {
>* The current generated assocaition shared key (secret)
>*/
> struct sctp_auth_bytes *asoc_shared_key;
> + struct sctp_shared_key *shkey;
>
> /* SCTP AUTH: hmac id of the first peer requested algorithm
>* that we support.
> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
> index 00667c5..e5214fd 100644
> --- a/net/sctp/auth.c
> +++ b/net/sctp/auth.c
> @@ -101,13 +101,14 @@ struct sctp_shared_key *sctp_auth_shkey_create(__u16
> key_id, gfp_t gfp)
> return NULL;
>
> INIT_LIST_HEAD(&new->key_list);
> + refcount_set(&new->refcnt, 1);
> new->key_id = key_id;
>
> return new;
> }
>
> /* Free the shared key structure */
> -static void sctp_auth_shkey_free(struct sctp_shared_key *sh_key)
> +static void sctp_auth_shkey_destroy(struct sctp_shared_key *sh_key)
> {
> BUG_ON(!list_empty(&sh_key->key_list));
> sctp_auth_key_put(sh_key->key);
> @@ -115,6 +116,
Re: [PATCH net-next 4/5] sctp: add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT
On Wed, Mar 14, 2018 at 07:05:33PM +0800, Xin Long wrote:
> This patch is to add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT,
> as described in section 6.1.8 of RFC6458.
>
> SCTP_AUTH_FREE_KEY: This report indicates that the SCTP
> implementation will no longer use the key identifier specified
> in auth_keynumber.
>
> After deactivating a key, it would never be used again, which means
> it's refcnt can't be held/increased by new chunks. But there may be
> some chunks in out queue still using it. So only when refcnt is 1,
> which means no chunk in outqueue is using/holding this key either,
> this EVENT would be sent.
>
> When users receive this notification, they could do DEL_KEY sockopt to
> remove this shkey, and also tell the peer that this key won't be used
> in any chunk thoroughly from now on, then the peer can remove it as
> well safely.
>
> Signed-off-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
> ---
> include/uapi/linux/sctp.h | 6 +-
> net/sctp/auth.c | 14 ++
> net/sctp/sm_make_chunk.c | 20 +++-
> net/sctp/sm_statefuns.c | 2 +-
> net/sctp/socket.c | 19 ++-
> 5 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index 08fc313..18ebbfe 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -518,7 +518,11 @@ struct sctp_authkey_event {
> sctp_assoc_t auth_assoc_id;
> };
>
> -enum { SCTP_AUTH_NEWKEY = 0, };
> +enum {
> + SCTP_AUTH_NEW_KEY,
> +#define SCTP_AUTH_NEWKEYSCTP_AUTH_NEW_KEY /* compatible with
> before */
> + SCTP_AUTH_FREE_KEY,
> +};
>
> /*
> * 6.1.9. SCTP_SENDER_DRY_EVENT
> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
> index a073123..e64630c 100644
> --- a/net/sctp/auth.c
> +++ b/net/sctp/auth.c
> @@ -992,6 +992,20 @@ int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
> if (!found)
> return -EINVAL;
>
> + /* refcnt == 1 and !list_empty mean it's not being used anywhere
> + * and deactivated will be set, so it's time to notify userland
> + * that this shkey can be freed.
> + */
> + if (asoc && !list_empty(&key->key_list) &&
> + refcount_read(&key->refcnt) == 1) {
> + struct sctp_ulpevent *ev;
> +
> + ev = sctp_ulpevent_make_authkey(asoc, key->key_id,
> + SCTP_AUTH_FREE_KEY, GFP_KERNEL);
> + if (ev)
> + asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
> + }
> +
> key->deactivated = 1;
>
> return 0;
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 10f071c..cc20bc3 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -89,8 +89,26 @@ static void sctp_control_release_owner(struct sk_buff *skb)
> {
> struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
>
> - if (chunk->shkey)
> + if (chunk->shkey) {
> + struct sctp_shared_key *shkey = chunk->shkey;
> + struct sctp_association *asoc = chunk->asoc;
> +
> + /* refcnt == 2 and !list_empty mean after this release, it's
> + * not being used anywhere, and it's time to notify userland
> + * that this shkey can be freed if it's been deactivated.
> + */
> + if (shkey->deactivated && !list_empty(&shkey->key_list) &&
> + refcount_read(&shkey->refcnt) == 2) {
> + struct sctp_ulpevent *ev;
> +
> + ev = sctp_ulpevent_make_authkey(asoc, shkey->key_id,
> + SCTP_AUTH_FREE_KEY,
> + GFP_KERNEL);
> + if (ev)
> + asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
> + }
> sctp_auth_shkey_release(chunk->shkey);
> + }
> }
>
> static void sctp_control_set_owner_w(struct sctp_chunk *chunk)
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 792e0e2..1e41dee 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -4246,7 +4246,7 @@ enum sctp_disposition sctp_sf_eat_auth(struct net *net,
> struct sctp_ulpevent *ev;
>
> ev = sctp_ulpevent_make_authkey(asoc, ntohs(auth_hdr->shkey_id),
> - SCTP_AUTH_NEWKEY, GFP_ATOMIC);
> + SCTP_AUTH_NEW_KEY, GFP_ATOMIC);
>
> if (!ev)
> return -ENOMEM;
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 65cc354..aeecdd6 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -8166,8 +8166,25 @@ static void sctp_wfree(struct sk_buff *skb)
> sk->sk_wmem_queued -= skb->truesize;
> sk_mem_uncharge(sk, skb->truesize);
>
> - if (chunk-
Re: [PATCH net-next 3/5] sctp: add sockopt SCTP_AUTH_DEACTIVATE_KEY
On Wed, Mar 14, 2018 at 07:05:32PM +0800, Xin Long wrote:
> This patch is to add sockopt SCTP_AUTH_DEACTIVATE_KEY, as described in
> section 8.3.4 of RFC6458.
>
> This set option indicates that the application will no longer send user
> messages using the indicated key identifier.
>
> Note that RFC requires that only deactivated keys that are no longer used
> by an association can be deleted, but for the backward compatibility, it
> is not to check deactivated when deleting or replacing one sh_key.
>
> Signed-off-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
> ---
> include/net/sctp/auth.h | 12 ++--
> include/uapi/linux/sctp.h | 1 +
> net/sctp/auth.c | 46 +++---
> net/sctp/socket.c | 31 +++
> 4 files changed, 81 insertions(+), 9 deletions(-)
>
> diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
> index 017c1aa..687e7f8 100644
> --- a/include/net/sctp/auth.h
> +++ b/include/net/sctp/auth.h
> @@ -65,6 +65,7 @@ struct sctp_shared_key {
> struct sctp_auth_bytes *key;
> refcount_t refcnt;
> __u16 key_id;
> + __u8 deactivated;
> };
>
> #define key_for_each(__key, __list_head) \
> @@ -113,14 +114,13 @@ void sctp_auth_shkey_hold(struct sctp_shared_key
> *sh_key);
> int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id);
> int sctp_auth_ep_set_hmacs(struct sctp_endpoint *ep,
> struct sctp_hmacalgo *hmacs);
> -int sctp_auth_set_key(struct sctp_endpoint *ep,
> - struct sctp_association *asoc,
> +int sctp_auth_set_key(struct sctp_endpoint *ep, struct sctp_association
> *asoc,
> struct sctp_authkey *auth_key);
> int sctp_auth_set_active_key(struct sctp_endpoint *ep,
> - struct sctp_association *asoc,
> - __u16 key_id);
> + struct sctp_association *asoc, __u16 key_id);
> int sctp_auth_del_key_id(struct sctp_endpoint *ep,
> - struct sctp_association *asoc,
> - __u16 key_id);
> + struct sctp_association *asoc, __u16 key_id);
> +int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
> +struct sctp_association *asoc, __u16 key_id);
>
> #endif
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index 47e781e..08fc313 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -99,6 +99,7 @@ typedef __s32 sctp_assoc_t;
> #define SCTP_RECVRCVINFO 32
> #define SCTP_RECVNXTINFO 33
> #define SCTP_DEFAULT_SNDINFO 34
> +#define SCTP_AUTH_DEACTIVATE_KEY 35
>
> /* Internal Socket Options. Some of the sctp library functions are
> * implemented using these socket options.
> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
> index e5214fd..a073123 100644
> --- a/net/sctp/auth.c
> +++ b/net/sctp/auth.c
> @@ -449,8 +449,11 @@ struct sctp_shared_key *sctp_auth_get_shkey(
>
> /* First search associations set of endpoint pair shared keys */
> key_for_each(key, &asoc->endpoint_shared_keys) {
> - if (key->key_id == key_id)
> - return key;
> + if (key->key_id == key_id) {
> + if (!key->deactivated)
> + return key;
> + break;
> + }
> }
>
> return NULL;
> @@ -905,7 +908,7 @@ int sctp_auth_set_active_key(struct sctp_endpoint *ep,
> }
> }
>
> - if (!found)
> + if (!found || key->deactivated)
> return -EINVAL;
>
> if (asoc) {
> @@ -956,3 +959,40 @@ int sctp_auth_del_key_id(struct sctp_endpoint *ep,
>
> return 0;
> }
> +
> +int sctp_auth_deact_key_id(struct sctp_endpoint *ep,
> +struct sctp_association *asoc, __u16 key_id)
> +{
> + struct sctp_shared_key *key;
> + struct list_head *sh_keys;
> + int found = 0;
> +
> + /* The key identifier MUST NOT be the current active key
> + * The key identifier MUST correst to an existing key
> + */
> + if (asoc) {
> + if (asoc->active_key_id == key_id)
> + return -EINVAL;
> +
> + sh_keys = &asoc->endpoint_shared_keys;
> + } else {
> + if (ep->active_key_id == key_id)
> + return -EINVAL;
> +
> + sh_keys = &ep->endpoint_shared_keys;
> + }
> +
> + key_for_each(key, sh_keys) {
> + if (key->key_id == key_id) {
> + found = 1;
> + break;
> + }
> + }
> +
> + if (!found)
> + return -EINVAL;
> +
> + key->deactivated = 1;
> +
> + return 0;
> +}
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9ffdecb..65cc354 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3647,6 +3647,33 @@ static int sctp_setsockopt_del_key(struct s
Re: [PATCH net-next 2/5] sctp: add support for SCTP AUTH Information for sendmsg
On Wed, Mar 14, 2018 at 07:05:31PM +0800, Xin Long wrote:
> This patch is to add support for SCTP AUTH Information for sendmsg,
> as described in section 5.3.8 of RFC6458.
>
> With this option, you can provide shared key identifier used for
> sending the user message.
>
> It's also a necessary send info for sctp_sendv.
>
> Note that it reuses sinfo->sinfo_tsn to indicate if this option is
> set and sinfo->sinfo_ssn to save the shkey ID which can be 0.
>
> Signed-off-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
> ---
> include/net/sctp/structs.h | 1 +
> include/uapi/linux/sctp.h | 14 +-
> net/sctp/chunk.c | 11 ++-
> net/sctp/socket.c | 23 +++
> 4 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 49ad67b..012fb3e 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -2118,6 +2118,7 @@ struct sctp_cmsgs {
> struct sctp_sndrcvinfo *srinfo;
> struct sctp_sndinfo *sinfo;
> struct sctp_prinfo *prinfo;
> + struct sctp_authinfo *authinfo;
> struct msghdr *addrs_msg;
> };
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index e94b6d2..47e781e 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -273,6 +273,18 @@ struct sctp_prinfo {
> __u32 pr_value;
> };
>
> +/* 5.3.8 SCTP AUTH Information Structure (SCTP_AUTHINFO)
> + *
> + * This cmsghdr structure specifies SCTP options for sendmsg().
> + *
> + * cmsg_levelcmsg_type cmsg_data[]
> + * ---
> + * IPPROTO_SCTP SCTP_AUTHINFO struct sctp_authinfo
> + */
> +struct sctp_authinfo {
> + __u16 auth_keynumber;
> +};
> +
> /*
> * sinfo_flags: 16 bits (unsigned integer)
> *
> @@ -310,7 +322,7 @@ typedef enum sctp_cmsg_type {
> #define SCTP_NXTINFO SCTP_NXTINFO
> SCTP_PRINFO,/* 5.3.7 SCTP PR-SCTP Information Structure */
> #define SCTP_PRINFO SCTP_PRINFO
> - SCTP_AUTHINFO, /* 5.3.8 SCTP AUTH Information Structure
> (RESERVED) */
> + SCTP_AUTHINFO, /* 5.3.8 SCTP AUTH Information Structure */
> #define SCTP_AUTHINFOSCTP_AUTHINFO
> SCTP_DSTADDRV4, /* 5.3.9 SCTP Destination IPv4 Address
> Structure */
> #define SCTP_DSTADDRV4 SCTP_DSTADDRV4
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 9f28a9a..f889a84 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -206,7 +206,16 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct
> sctp_association *asoc,
> max_data -= SCTP_PAD4(sizeof(struct sctp_auth_chunk) +
> hmac_desc->hmac_len);
>
> - shkey = asoc->shkey;
> + if (sinfo->sinfo_tsn &&
> + sinfo->sinfo_ssn != asoc->active_key_id) {
> + shkey = sctp_auth_get_shkey(asoc, sinfo->sinfo_ssn);
> + if (!shkey) {
> + err = -EINVAL;
> + goto errout;
> + }
> + } else {
> + shkey = asoc->shkey;
> + }
> }
>
> /* Check what's our max considering the above */
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 003a4ad..9ffdecb 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1987,6 +1987,14 @@ static void sctp_sendmsg_update_sinfo(struct
> sctp_association *asoc,
>
> if (!cmsgs->srinfo && !cmsgs->prinfo)
> sinfo->sinfo_timetolive = asoc->default_timetolive;
> +
> + if (cmsgs->authinfo) {
> + /* Reuse sinfo_tsn to indicate that authinfo was set and
> + * sinfo_ssn to save the keyid on tx path.
> + */
> + sinfo->sinfo_tsn = 1;
> + sinfo->sinfo_ssn = cmsgs->authinfo->auth_keynumber;
> + }
> }
>
> static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
> @@ -7874,6 +7882,21 @@ static int sctp_msghdr_parse(const struct msghdr *msg,
> struct sctp_cmsgs *cmsgs)
> if (cmsgs->prinfo->pr_policy == SCTP_PR_SCTP_NONE)
> cmsgs->prinfo->pr_value = 0;
> break;
> + case SCTP_AUTHINFO:
> + /* SCTP Socket API Extension
> + * 5.3.8 SCTP AUTH Information Structure (SCTP_AUTHINFO)
> + *
> + * This cmsghdr structure specifies SCTP options for
> sendmsg().
> + *
> + * cmsg_levelcmsg_type cmsg_data[]
> + * -
> + * IPPROTO_SCTP SCTP_AUTHINFO struct sctp_authinfo
> + */
> + if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct
Re: [PATCH net-next 5/5] sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT
On Wed, Mar 14, 2018 at 07:05:34PM +0800, Xin Long wrote:
> This patch is to add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT,
> as described in section 6.1.8 of RFC6458.
>
> SCTP_AUTH_NO_AUTH: This report indicates that the peer does not
> support SCTP authentication as defined in [RFC4895].
>
> Note that the implementation is quite similar as that of
> SCTP_ADAPTATION_INDICATION.
>
> Signed-off-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
> ---
> include/net/sctp/command.h | 1 +
> include/uapi/linux/sctp.h | 1 +
> net/sctp/sm_sideeffect.c | 13 +
> net/sctp/sm_statefuns.c| 43 +--
> 4 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
> index b55c6a4..6640f84 100644
> --- a/include/net/sctp/command.h
> +++ b/include/net/sctp/command.h
> @@ -100,6 +100,7 @@ enum sctp_verb {
> SCTP_CMD_SET_SK_ERR, /* Set sk_err */
> SCTP_CMD_ASSOC_CHANGE, /* generate and send assoc_change event */
> SCTP_CMD_ADAPTATION_IND, /* generate and send adaptation event */
> + SCTP_CMD_PEER_NO_AUTH, /* generate and send authentication event */
> SCTP_CMD_ASSOC_SHKEY,/* generate the association shared keys */
> SCTP_CMD_T1_RETRAN, /* Mark for retransmission after T1 timeout */
> SCTP_CMD_UPDATE_INITTAG, /* Update peer inittag */
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index 18ebbfe..afd4346 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -522,6 +522,7 @@ enum {
> SCTP_AUTH_NEW_KEY,
> #define SCTP_AUTH_NEWKEYSCTP_AUTH_NEW_KEY /* compatible with
> before */
> SCTP_AUTH_FREE_KEY,
> + SCTP_AUTH_NO_AUTH,
> };
>
> /*
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index b71e7fb..298112c 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -1049,6 +1049,16 @@ static void sctp_cmd_assoc_change(struct sctp_cmd_seq
> *commands,
> asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
> }
>
> +static void sctp_cmd_peer_no_auth(struct sctp_cmd_seq *commands,
> + struct sctp_association *asoc)
> +{
> + struct sctp_ulpevent *ev;
> +
> + ev = sctp_ulpevent_make_authkey(asoc, 0, SCTP_AUTH_NO_AUTH, GFP_ATOMIC);
> + if (ev)
> + asoc->stream.si->enqueue_event(&asoc->ulpq, ev);
> +}
> +
> /* Helper function to generate an adaptation indication event */
> static void sctp_cmd_adaptation_ind(struct sctp_cmd_seq *commands,
> struct sctp_association *asoc)
> @@ -1755,6 +1765,9 @@ static int sctp_cmd_interpreter(enum sctp_event
> event_type,
> case SCTP_CMD_ADAPTATION_IND:
> sctp_cmd_adaptation_ind(commands, asoc);
> break;
> + case SCTP_CMD_PEER_NO_AUTH:
> + sctp_cmd_peer_no_auth(commands, asoc);
> + break;
>
> case SCTP_CMD_ASSOC_SHKEY:
> error = sctp_auth_asoc_init_active_key(asoc,
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 1e41dee..cc56a67 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -659,7 +659,7 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
>void *arg,
>struct sctp_cmd_seq *commands)
> {
> - struct sctp_ulpevent *ev, *ai_ev = NULL;
> + struct sctp_ulpevent *ev, *ai_ev = NULL, *auth_ev = NULL;
> struct sctp_association *new_asoc;
> struct sctp_init_chunk *peer_init;
> struct sctp_chunk *chunk = arg;
> @@ -820,6 +820,14 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
> goto nomem_aiev;
> }
>
> + if (!new_asoc->peer.auth_capable) {
> + auth_ev = sctp_ulpevent_make_authkey(new_asoc, 0,
> + SCTP_AUTH_NO_AUTH,
> + GFP_ATOMIC);
> + if (!auth_ev)
> + goto nomem_authev;
> + }
> +
> /* Add all the state machine commands now since we've created
>* everything. This way we don't introduce memory corruptions
>* during side-effect processing and correclty count established
> @@ -847,8 +855,14 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net,
> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> SCTP_ULPEVENT(ai_ev));
>
> + if (auth_ev)
> + sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> + SCTP_ULPEVENT(auth_ev));
> +
> return SCTP_DISPOSITION_CONSUME;
>
> +nomem_authev:
> + sctp_ulpevent_free(ai_ev);
> nomem_aiev:
> sctp_ulpevent_free(ev);
> nomem_ev:
> @@
Re: [PATCH net-next 1/5] sctp: add refcnt support for sh_key
On Wed, Mar 14, 2018 at 07:05:30PM +0800, Xin Long wrote:
> With refcnt support for sh_key, chunks auth sh_keys can be decided
> before enqueuing it. Changing the active key later will not affect
> the chunks already enqueued.
>
> Furthermore, this is necessary when adding the support for authinfo
> for sendmsg in next patch.
>
> Note that struct sctp_chunk can't be grown due to that performance
> drop issue on slow cpu, so it just reuses head_skb memory for shkey
> in sctp_chunk.
>
> Signed-off-by: Xin Long
> ---
> include/net/sctp/auth.h| 9 +++--
> include/net/sctp/sm.h | 3 +-
> include/net/sctp/structs.h | 9 +++--
> net/sctp/auth.c| 86
> +++---
> net/sctp/chunk.c | 5 +++
> net/sctp/output.c | 18 --
> net/sctp/sm_make_chunk.c | 15 ++--
> net/sctp/sm_statefuns.c| 11 +++---
> net/sctp/socket.c | 6
> 9 files changed, 104 insertions(+), 58 deletions(-)
>
> diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
> index e5c57d0..017c1aa 100644
> --- a/include/net/sctp/auth.h
> +++ b/include/net/sctp/auth.h
> @@ -62,8 +62,9 @@ struct sctp_auth_bytes {
> /* Definition for a shared key, weather endpoint or association */
> struct sctp_shared_key {
> struct list_head key_list;
> - __u16 key_id;
> struct sctp_auth_bytes *key;
> + refcount_t refcnt;
> + __u16 key_id;
> };
>
> #define key_for_each(__key, __list_head) \
> @@ -103,8 +104,10 @@ int sctp_auth_send_cid(enum sctp_cid chunk,
> int sctp_auth_recv_cid(enum sctp_cid chunk,
> const struct sctp_association *asoc);
> void sctp_auth_calculate_hmac(const struct sctp_association *asoc,
> - struct sk_buff *skb,
> - struct sctp_auth_chunk *auth, gfp_t gfp);
> + struct sk_buff *skb, struct sctp_auth_chunk *auth,
> + struct sctp_shared_key *ep_key, gfp_t gfp);
> +void sctp_auth_shkey_release(struct sctp_shared_key *sh_key);
> +void sctp_auth_shkey_hold(struct sctp_shared_key *sh_key);
>
> /* API Helpers */
> int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id);
> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> index 2883c43..2d0e782 100644
> --- a/include/net/sctp/sm.h
> +++ b/include/net/sctp/sm.h
> @@ -263,7 +263,8 @@ int sctp_process_asconf_ack(struct sctp_association *asoc,
> struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
> __u32 new_cum_tsn, size_t nstreams,
> struct sctp_fwdtsn_skip *skiplist);
> -struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
> +struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc,
> + __u16 key_id);
> struct sctp_chunk *sctp_make_strreset_req(const struct sctp_association
> *asoc,
> __u16 stream_num, __be16 *stream_list,
> bool out, bool in);
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index ec6e46b..49ad67b 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -577,8 +577,12 @@ struct sctp_chunk {
> /* This points to the sk_buff containing the actual data. */
> struct sk_buff *skb;
>
> - /* In case of GSO packets, this will store the head one */
> - struct sk_buff *head_skb;
> + union {
> + /* In case of GSO packets, this will store the head one */
> + struct sk_buff *head_skb;
> + /* In case of auth enabled, this will point to the shkey */
> + struct sctp_shared_key *shkey;
> + };
Why do you need to add this at all? You add the shared key pointer to the
association in this patch, and sctp_chunk already has a pointer to the
association, so you should already be able to find the shared key via
chunk->asoc->shkey, no?
>
> /* These are the SCTP headers by reverse order in a packet.
>* Note that some of these may happen more than once. In that
> @@ -1995,6 +1999,7 @@ struct sctp_association {
>* The current generated assocaition shared key (secret)
>*/
> struct sctp_auth_bytes *asoc_shared_key;
> + struct sctp_shared_key *shkey;
>
> /* SCTP AUTH: hmac id of the first peer requested algorithm
>* that we support.
> diff --git a/net/sctp/auth.c b/net/sctp/auth.c
> index 00667c5..e5214fd 100644
> --- a/net/sctp/auth.c
> +++ b/net/sctp/auth.c
> @@ -101,13 +101,14 @@ struct sctp_shared_key *sctp_auth_shkey_create(__u16
> key_id, gfp_t gfp)
> return NULL;
>
> INIT_LIST_HEAD(&new->key_list);
> + refcount_set(&new->refcnt, 1);
> new->key_id = key_id;
>
> return new;
> }
>
> /* Free the shared key structure */
> -static void sctp_auth_shkey_free(struct s
Re: [PATCH] pktgen: Fix memory leak in pktgen_if_write
From: "Gustavo A. R. Silva"
Date: Wed, 14 Mar 2018 03:07:27 -0500
> _buf_ is an array and the one that must be freed is _tp_ instead.
>
> Fixes: a870a02cc963 ("pktgen: use dynamic allocation for debug print buffer")
> Reported-by: Wang Jian
> Signed-off-by: Gustavo A. R. Silva
Applied, thanks.
[PATCH] netlink: make sure nladdr has correct size in netlink_connect()
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
net/netlink/af_netlink.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 07e8478068f0..5d49b39e81c3 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1085,6 +1085,9 @@ static int netlink_connect(struct socket *sock, struct
sockaddr *addr,
if (addr->sa_family != AF_NETLINK)
return -EINVAL;
+ if (alen < sizeof(struct netlink_sock))
+ return -EINVAL;
+
if ((nladdr->nl_groups || nladdr->nl_pid) &&
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
--
2.16.2.804.g6dcf76e118-goog
Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()
On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko wrote:
> KMSAN reports use of uninitialized memory in the case when |alen| is
> smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't
> fully copied from the userspace.
>
> Signed-off-by: Alexander Potapenko
> Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
> ---
> net/netlink/af_netlink.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 07e8478068f0..5d49b39e81c3 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1085,6 +1085,9 @@ static int netlink_connect(struct socket *sock, struct
> sockaddr *addr,
> if (addr->sa_family != AF_NETLINK)
> return -EINVAL;
>
> + if (alen < sizeof(struct netlink_sock))
> + return -EINVAL;
> +
>
Hmmm. How was this patch tested exactly ?
Thanks.
[PATCH][next] rsi: remove redundant duplicate assignment of buffer_size
From: Colin Ian King Variable buffer_size is re-assigned the same value, this duplicated assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored to 'buffer_size' is never read Signed-off-by: Colin Ian King --- drivers/net/wireless/rsi/rsi_91x_usb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c index be8236f404b5..7b8bae313aa9 100644 --- a/drivers/net/wireless/rsi/rsi_91x_usb.c +++ b/drivers/net/wireless/rsi/rsi_91x_usb.c @@ -140,7 +140,6 @@ static int rsi_find_bulk_in_and_out_endpoints(struct usb_interface *interface, buffer_size = endpoint->wMaxPacketSize; dev->bulkout_endpoint_addr[bout_found] = endpoint->bEndpointAddress; - buffer_size = endpoint->wMaxPacketSize; dev->bulkout_size[bout_found] = buffer_size; bout_found++; } -- 2.15.1
[PATCH net-next 0/2] sfc: support FEC configuration
Implements the ethtool get & set fecparam operations. Edward Cree (2): sfc: update MCDI protocol headers sfc: support FEC configuration through ethtool drivers/net/ethernet/sfc/ethtool.c| 32 + drivers/net/ethernet/sfc/mcdi_pcol.h | 2822 + drivers/net/ethernet/sfc/mcdi_port.c | 150 ++ drivers/net/ethernet/sfc/net_driver.h |8 + 4 files changed, 1966 insertions(+), 1046 deletions(-)
[PATCH net-next 2/2] sfc: support FEC configuration through ethtool
As well as 'auto' and the forced 'off', 'rs' and 'baser' states, we also
handle combinations of settings (since the fecparam->fec field is a
bitmask), where auto|rs and auto|baser specify a preferred FEC mode but
will fall back to the other if the cable or link partner doesn't support
it. rs|baser (with or without auto bit) means prefer FEC even where
auto wouldn't use it, but let FW choose which encoding to use.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ethtool.c| 32
drivers/net/ethernet/sfc/mcdi_port.c | 150 ++
drivers/net/ethernet/sfc/net_driver.h | 8 ++
3 files changed, 190 insertions(+)
diff --git a/drivers/net/ethernet/sfc/ethtool.c
b/drivers/net/ethernet/sfc/ethtool.c
index 64049e71e6e7..bb1c80d48d12 100644
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -1488,6 +1488,36 @@ static int efx_ethtool_get_module_info(struct net_device
*net_dev,
return ret;
}
+static int efx_ethtool_get_fecparam(struct net_device *net_dev,
+ struct ethtool_fecparam *fecparam)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+ int rc;
+
+ if (!efx->phy_op || !efx->phy_op->get_fecparam)
+ return -EOPNOTSUPP;
+ mutex_lock(&efx->mac_lock);
+ rc = efx->phy_op->get_fecparam(efx, fecparam);
+ mutex_unlock(&efx->mac_lock);
+
+ return rc;
+}
+
+static int efx_ethtool_set_fecparam(struct net_device *net_dev,
+ struct ethtool_fecparam *fecparam)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+ int rc;
+
+ if (!efx->phy_op || !efx->phy_op->get_fecparam)
+ return -EOPNOTSUPP;
+ mutex_lock(&efx->mac_lock);
+ rc = efx->phy_op->set_fecparam(efx, fecparam);
+ mutex_unlock(&efx->mac_lock);
+
+ return rc;
+}
+
const struct ethtool_ops efx_ethtool_ops = {
.get_drvinfo= efx_ethtool_get_drvinfo,
.get_regs_len = efx_ethtool_get_regs_len,
@@ -1523,4 +1553,6 @@ const struct ethtool_ops efx_ethtool_ops = {
.get_module_eeprom = efx_ethtool_get_module_eeprom,
.get_link_ksettings = efx_ethtool_get_link_ksettings,
.set_link_ksettings = efx_ethtool_set_link_ksettings,
+ .get_fecparam = efx_ethtool_get_fecparam,
+ .set_fecparam = efx_ethtool_set_fecparam,
};
diff --git a/drivers/net/ethernet/sfc/mcdi_port.c
b/drivers/net/ethernet/sfc/mcdi_port.c
index ce8aabf9091e..9382bb0b4d5a 100644
--- a/drivers/net/ethernet/sfc/mcdi_port.c
+++ b/drivers/net/ethernet/sfc/mcdi_port.c
@@ -352,6 +352,64 @@ static void efx_mcdi_phy_decode_link(struct efx_nic *efx,
link_state->speed = speed;
}
+/* The semantics of the ethtool FEC mode bitmask are not well defined,
+ * particularly the meaning of combinations of bits. Which means we get to
+ * define our own semantics, as follows:
+ * OFF overrides any other bits, and means "disable all FEC" (with the
+ * exception of 25G KR4/CR4, where it is not possible to reject it if AN
+ * partner requests it).
+ * AUTO on its own means use cable requirements and link partner autoneg with
+ * fw-default preferences for the cable type.
+ * AUTO and either RS or BASER means use the specified FEC type if cable and
+ * link partner support it, otherwise autoneg/fw-default.
+ * RS or BASER alone means use the specified FEC type if cable and link partner
+ * support it and either requests it, otherwise no FEC.
+ * Both RS and BASER (whether AUTO or not) means use FEC if cable and link
+ * partner support it, preferring RS to BASER.
+ */
+static u32 ethtool_fec_caps_to_mcdi(u32 ethtool_cap)
+{
+ u32 ret = 0;
+
+ if (ethtool_cap & ETHTOOL_FEC_OFF)
+ return 0;
+
+ if (ethtool_cap & ETHTOOL_FEC_AUTO)
+ ret |= (1 << MC_CMD_PHY_CAP_BASER_FEC_LBN) |
+ (1 << MC_CMD_PHY_CAP_25G_BASER_FEC_LBN) |
+ (1 << MC_CMD_PHY_CAP_RS_FEC_LBN);
+ if (ethtool_cap & ETHTOOL_FEC_RS)
+ ret |= (1 << MC_CMD_PHY_CAP_RS_FEC_LBN) |
+ (1 << MC_CMD_PHY_CAP_RS_FEC_REQUESTED_LBN);
+ if (ethtool_cap & ETHTOOL_FEC_BASER)
+ ret |= (1 << MC_CMD_PHY_CAP_BASER_FEC_LBN) |
+ (1 << MC_CMD_PHY_CAP_25G_BASER_FEC_LBN) |
+ (1 << MC_CMD_PHY_CAP_BASER_FEC_REQUESTED_LBN) |
+ (1 << MC_CMD_PHY_CAP_25G_BASER_FEC_REQUESTED_LBN);
+ return ret;
+}
+
+/* Invert ethtool_fec_caps_to_mcdi. There are two combinations that function
+ * can never produce, (baser xor rs) and neither req; the implementation below
+ * maps both of those to AUTO. This should never matter, and it's not clear
+ * what a better mapping would be anyway.
+ */
+static u32 mcdi_fec_caps_to_ethtool(u32 caps, bool is_25g)
+{
+ bool rs = caps & (1 << MC_CMD_PHY_CAP_RS_FEC_LBN),
+r
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> Testing brcmfmac with more recent firmwares resulted in AP interfaces
> not working in some specific setups. Debugging resulted in discovering
> support for IAPP in Broadcom's firmwares. This is an obsoleted standard
> and its implementation is something that:
> 1) Most people don't need / want to use
> 2) Can allow local DoS attacks
> 3) Breaks AP interfaces in some specific bridge setups
>
> To solve issues it can cause this commit modifies brcmfmac to drop IAPP
> packets. If affects:
> 1) Rx path: driver won't be sending these unwanted packets up.
> 2) Tx path: driver will reject packets that would trigger STA
>disassociation perfromed by a firmware (possible local DoS attack).
>
> It appears there are some Broadcom's clients/users who care about this
> feature despite the drawbacks. They can switch it on by a newly added
> Kconfig option.
>
> Signed-off-by: Rafał Miłecki
[...]
> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -68,6 +68,26 @@ config BRCMFMAC_PCIE
> IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
> use the driver for an PCIE wireless card.
>
> +config BRCMFMAC_IAPP
> + bool "Partial support for obsoleted Inter-Access Point Protocol"
> + depends on BRCMFMAC
> + ---help---
> + Most of Broadcom's firmwares can send 802.11f ADD frame every
> + time new STA connects to the AP interface. Some recent ones
> + can also disassociate STA when they receive such a frame.
> +
> + It's important to understand this behavior can lead to a local
> + DoS security issue. Attacker may trigger disassociation of any
> + STA by sending a proper Ethernet frame to the wireless
> + interface.
> +
> + Moreover this feature may break AP interfaces in some specific
> + setups. This applies e.g. to the bridge with hairpin mode
> + enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet
> + generated by a firmware will get passed back to the wireless
> + interface and cause immediate disassociation of just-connected
> + STA.
Sorry for jumping late, but does it really make sense to have a Kconfig
option for this? I don't think we should add a Kconfig option for every
strange feature, there should be stronger reasons (size savings etc)
before adding a Kconfig option.
And in this case the size savings can't be much. Wouldn't a module
parameter be simpler for a functionality change like this?
> +/**
> + * brcmf_skb_is_iapp - checks if skb is an IAPP packet
> + *
> + * @skb: skb to check
> + */
> +static bool brcmf_skb_is_iapp(struct sk_buff *skb)
> +{
> + const u8 iapp_l2_update_packet[6] __aligned(2) = {
> + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
> + };
static?
> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
#ifndef?
> + const u16 *a = (const u16 *)eth_data;
> + const u16 *b = (const u16 *)iapp_l2_update_packet;
> +#endif
> +
> + if (skb->len - skb->mac_len != 6 ||
> + !is_multicast_ether_addr(eth_hdr(skb)->h_dest))
> + return false;
> +
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
#ifdef?
--
Kalle Valo
RE: [PATCH v5 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Tuesday, March 13, 2018 5:26 PM > To: Razvan Stefanescu > Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux- > ker...@vger.kernel.org; netdev@vger.kernel.org; Alexander Graf > ; a...@arndb.de; Alexandru Marginean > ; Ruxandra Ioana Ciocoi Radulescu > ; Ioana Ciornei ; > Laurentiu Tudor ; stuyo...@gmail.com > Subject: Re: [PATCH v5 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 > Ethernet Switch driver > > > Hello Andrew, > > > > The current driver implementation uses only a single FDB for the switch, > > so it is not possible configure multiple flooding domains to accommodate > > ports partitioning. > > Ah, O.K. Rather than break somebodies network by wrongly flooding, it > would be better to return -EOPNOTSUPP when the requirement for the > second FDB is met. The offload to hardware will then not happen, and > the software bridge will do all the work. > Thank you for your suggestion. I will add to the TODO list in v6. Razvan > Andrew
RE: [PATCH v5 1/6] staging: fsl-dpaa2/ethsw: Add APIs for DPSW object
> > Can you resend this series and just use the correct SPDX identifiers for > all of the new files, instead of all of this horrid boiler-plate code? > > That will save me time when I have to go delete all of this in the near > future :) > > Also, why dual license it? Are you _SURE_ you want to do that, and are > totally aware of all of the crazy issues surrounding it? Hint, it > almost never means what you might think it does, and I have yet to know > of anyone doing anything "real" with any dual-licensed Linux kernel > code. > > Remember, BSD is not the license you want/need for GPL header files that > are exposed to userspace... > > > thanks, > > greg k-h Thank you for your observation. I will update the patches with the SPDX identifiers. Razvan
[PATCH 00/16] remove eight obsolete architectures
Here is the collection of patches I have applied to my 'asm-generic' tree on top of the 'metag' removal. This does not include any of the device drivers, I'll send those separately to a someone different list of people. The removal came out of a discussion that is now documented at https://lwn.net/Articles/748074/ Following up from the state described there, I ended up removing the mn10300, tile, blackfin and cris architectures directly, rather than waiting, after consulting with the respective maintainers. However, the unicore32 architecture is no longer part of the removal, after its maintainer Xuetao Guan said that the port is still actively being used and that he intends to keep working on it, and that he will try to provide updated toolchain sources. In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. Arnd Arnd Bergmann (14): arch: remove frv port arch: remove m32r port arch: remove score port arch: remove blackfin port arch: remove tile port procfs: remove CONFIG_HARDWALL dependency mm: remove blackfin MPU support mm: remove obsolete alloc_remap() treewide: simplify Kconfig dependencies for removed archs asm-generic: siginfo: remove obsolete #ifdefs Documentation: arch-support: remove obsolete architectures asm-generic: clean up asm/unistd.h recordmcount.pl: drop blackin and tile support ktest: remove obsolete architectures David Howells (1): mn10300: Remove the architecture Jesper Nilsson (1): CRIS: Drop support for the CRIS port Dirstat only (full diffstat is over 100KB): 6.3% arch/blackfin/mach-bf548/include/mach/ 4.5% arch/blackfin/mach-bf609/include/mach/ 26.3% arch/blackfin/ 4.1% arch/cris/arch-v32/ 5.6% arch/cris/include/arch-v32/arch/hwregs/iop/ 4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/ 4.7% arch/cris/include/arch-v32/ 7.8% arch/cris/ 5.6% arch/frv/ 5.5% arch/m32r/ 7.0% arch/mn10300/ 7.6% arch/tile/include/ 6.4% arch/tile/kernel/ 0.0% Documentation/admin-guide/ 0.0% Documentation/blackfin/ 0.0% Documentation/cris/ 0.0% Documentation/devicetree/bindings/cris/ 0.0% Documentation/devicetree/bindings/interrupt-controller/ 2.8% Documentation/features/ 0.5% Documentation/frv/ 0.0% Documentation/ioctl/ 0.0% Documentation/mn10300/ 0.0% Documentation/ 0.0% block/ 0.0% crypto/ 0.0% drivers/ide/ 0.0% drivers/input/joystick/ 0.0% drivers/isdn/hisax/ 0.0% drivers/net/ethernet/davicom/ 0.0% drivers/net/ethernet/smsc/ 0.0% drivers/net/wireless/cisco/ 0.0% drivers/pci/ 0.0% drivers/pwm/ 0.0% drivers/rtc/ 0.0% drivers/spi/ 0.0% drivers/staging/speakup/ 0.0% drivers/usb/musb/ 0.0% drivers/video/console/ 0.0% drivers/watchdog/ 0.0% fs/minix/ 0.0% fs/proc/ 0.0% fs/ 0.0% include/asm-generic/ 0.0% include/linux/ 0.0% include/uapi/asm-generic/ 0.0% init/ 0.0% kernel/ 0.0% lib/ 0.0% mm/ 0.0% samples/blackfin/ 0.0% samples/kprobes/ 0.0% samples/ 0.0% scripts/mod/ 0.0% scripts/ 0.0% tools/arch/frv/include/uapi/asm/ 0.0% tools/arch/m32r/include/uapi/asm/ 0.0% tools/arch/mn10300/include/uapi/asm/ 0.0% tools/arch/score/include/uapi/asm/ 0.0% tools/arch/tile/include/asm/ 0.0% tools/arch/tile/include/uapi/asm/ 0.0% tools/include/asm-generic/ 0.0% tools/scripts/ 0.0% tools/testing/ktest/examples/ 0.0% tools/testing/ktest/ Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-bl...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org
Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind
On 03/14/2018 04:39 AM, Alexei Starovoitov wrote:
[...]
> +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) \
> + BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET4_BIND)
> +
> +#define BPF_CGROUP_RUN_PROG_INET6_BIND(sk, uaddr) \
> + BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET6_BIND)
> +
> #define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops)
>\
> ({ \
> int __ret = 0; \
> @@ -135,6 +154,8 @@ static inline int cgroup_bpf_inherit(struct cgroup *cgrp)
> { return 0; }
> #define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk,skb) ({ 0; })
> #define BPF_CGROUP_RUN_PROG_INET_EGRESS(sk,skb) ({ 0; })
> #define BPF_CGROUP_RUN_PROG_INET_SOCK(sk) ({ 0; })
> +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) ({ 0; })
> +#define BPF_CGROUP_RUN_PROG_INET6_BIND(sk, uaddr) ({ 0; })
> #define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops) ({ 0; })
> #define BPF_CGROUP_RUN_PROG_DEVICE_CGROUP(type,major,minor,access) ({ 0; })
>
> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> index 19b8349a3809..eefd877f8e68 100644
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
> @@ -8,6 +8,8 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_SCHED_ACT, tc_cls_act)
> BPF_PROG_TYPE(BPF_PROG_TYPE_XDP, xdp)
> BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SKB, cg_skb)
> BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SOCK, cg_sock)
> +BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_INET4_BIND, cg_inet4_bind)
> +BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_INET6_BIND, cg_inet6_bind)
> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_IN, lwt_inout)
> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_OUT, lwt_inout)
> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_XMIT, lwt_xmit)
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index fdb691b520c0..fe469320feab 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -1001,6 +1001,16 @@ static inline int bpf_tell_extensions(void)
> return SKF_AD_MAX;
> }
>
> +struct bpf_sock_addr_kern {
> + struct sock *sk;
> + struct sockaddr *uaddr;
> + /* Temporary "register" to make indirect stores to nested structures
> + * defined above. We need three registers to make such a store, but
> + * only two (src and dst) are available at convert_ctx_access time
> + */
> + u64 tmp_reg;
> +};
> +
> struct bpf_sock_ops_kern {
> struct sock *sk;
> u32 op;
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 2a66769e5875..78628a3f3cd8 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -133,6 +133,8 @@ enum bpf_prog_type {
> BPF_PROG_TYPE_SOCK_OPS,
> BPF_PROG_TYPE_SK_SKB,
> BPF_PROG_TYPE_CGROUP_DEVICE,
> + BPF_PROG_TYPE_CGROUP_INET4_BIND,
> + BPF_PROG_TYPE_CGROUP_INET6_BIND,
Could those all be merged into BPF_PROG_TYPE_SOCK_OPS? I'm slowly getting
confused by the many sock_*/sk_* prog types we have. The attach hook could
still be something like BPF_CGROUP_BIND/BPF_CGROUP_CONNECT. Potentially
storing some prog-type specific void *private_data in prog's aux during
verification could be a way (similarly as you mention) which can later be
retrieved at attach time to reject with -ENOTSUPP or such.
> };
>
> enum bpf_attach_type {
> @@ -143,6 +145,8 @@ enum bpf_attach_type {
> BPF_SK_SKB_STREAM_PARSER,
> BPF_SK_SKB_STREAM_VERDICT,
> BPF_CGROUP_DEVICE,
> + BPF_CGROUP_INET4_BIND,
> + BPF_CGROUP_INET6_BIND,
Binding to v4 mapped v6 address would work as well, right? Can't this be
squashed into one attach type as mentioned?
> __MAX_BPF_ATTACH_TYPE
> };
>
> @@ -953,6 +957,26 @@ struct bpf_map_info {
> __u64 netns_ino;
> } __attribute__((aligned(8)));
>
> +/* User bpf_sock_addr struct to access socket fields and sockaddr struct
> passed
> + * by user and intended to be used by socket (e.g. to bind to, depends on
> + * attach attach type).
> + */
> +struct bpf_sock_addr {
> + __u32 user_family; /* Allows 4-byte read, but no write. */
> + __u32 user_ip4; /* Allows 1,2,4-byte read and 4-byte write.
> + * Stored in network byte order.
> + */
> + __u32 user_ip6[4]; /* Allows 1,2,4-byte read an 4-byte write.
> + * Stored in network byte order.
> + */
> + __u32 user_port;/* Allows 4-byte read and write.
> + * Stored in network byte order
> + */
> + __u32 family; /* Allows 4-byte read, but no write */
> + __u32 type; /* Allows 4-byte read, but no write */
> + __u32 protocol; /* Allows 4-byte read, but no write */
I recall bind to prefix came up from time to time in BPF context in the sense
to let the app itself be more f
Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()
On Wed, Mar 14, 2018 at 7:16 AM, Alexander Potapenko wrote:
>
>
>
> On Wed, Mar 14, 2018 at 3:11 PM Eric Dumazet wrote:
>>
>> On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko
>> wrote:
>> > KMSAN reports use of uninitialized memory in the case when |alen| is
>> > smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't
>> > fully copied from the userspace.
>> >
>> > Signed-off-by: Alexander Potapenko
>> > Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
>> > ---
>> > net/netlink/af_netlink.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
>> > index 07e8478068f0..5d49b39e81c3 100644
>> > --- a/net/netlink/af_netlink.c
>> > +++ b/net/netlink/af_netlink.c
>> > @@ -1085,6 +1085,9 @@ static int netlink_connect(struct socket *sock,
>> > struct sockaddr *addr,
>> > if (addr->sa_family != AF_NETLINK)
>> > return -EINVAL;
>> >
>> > + if (alen < sizeof(struct netlink_sock))
>> > + return -EINVAL;
>> > +
>> >
>>
>> Hmmm. How was this patch tested exactly ?
>
> You're absolutely right, I should have been using sizeof(sockaddr_nl).
> The reproducer that I used to trigger the bug was passing alen=2, so the
> patch still worked despite being incorrect.
> Is there any generic set of networking tests that I can use for such bugs?
There are upstream tests in tools/testing/selftests/
In your case, making sure tools like iproute2 ss are still working
would have done the job.
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
On 3/14/2018 3:24 PM, Kalle Valo wrote: +config BRCMFMAC_IAPP >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >+ depends on BRCMFMAC >+ ---help--- >+ Most of Broadcom's firmwares can send 802.11f ADD frame every >+ time new STA connects to the AP interface. Some recent ones >+ can also disassociate STA when they receive such a frame. >+ >+ It's important to understand this behavior can lead to a local >+ DoS security issue. Attacker may trigger disassociation of any >+ STA by sending a proper Ethernet frame to the wireless >+ interface. >+ >+ Moreover this feature may break AP interfaces in some specific >+ setups. This applies e.g. to the bridge with hairpin mode >+ enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet >+ generated by a firmware will get passed back to the wireless >+ interface and cause immediate disassociation of just-connected >+ STA. Sorry for jumping late, but does it really make sense to have a Kconfig option for this? I don't think we should add a Kconfig option for every strange feature, there should be stronger reasons (size savings etc) before adding a Kconfig option. And in this case the size savings can't be much. Wouldn't a module parameter be simpler for a functionality change like this? Hi Kalle, Good to be wary about Kconfig option. So my reason for asking a Kconfig option is that this is directly in the datapaths (tx and rx) so I prefer to disable/enable it compile time rather then runtime. Regards, Arend
[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs
A lot of Kconfig symbols have architecture specific dependencies.
In those cases that depend on architectures we have already removed,
they can be omitted.
Signed-off-by: Arnd Bergmann
---
block/bounce.c | 2 +-
drivers/ide/Kconfig | 2 +-
drivers/ide/ide-generic.c| 12 +---
drivers/input/joystick/analog.c | 2 +-
drivers/isdn/hisax/Kconfig | 10 +-
drivers/net/ethernet/davicom/Kconfig | 2 +-
drivers/net/ethernet/smsc/Kconfig| 6 +++---
drivers/net/wireless/cisco/Kconfig | 2 +-
drivers/pwm/Kconfig | 2 +-
drivers/rtc/Kconfig | 2 +-
drivers/spi/Kconfig | 4 ++--
drivers/usb/musb/Kconfig | 2 +-
drivers/video/console/Kconfig| 3 +--
drivers/watchdog/Kconfig | 6 --
drivers/watchdog/Makefile| 6 --
fs/Kconfig.binfmt| 5 ++---
fs/minix/Kconfig | 2 +-
include/linux/ide.h | 7 +--
init/Kconfig | 5 ++---
lib/Kconfig.debug| 13 +
lib/test_user_copy.c | 2 --
mm/Kconfig | 7 ---
mm/percpu.c | 4
23 files changed, 31 insertions(+), 77 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 6a3e68292273..dd0b93f2a871 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -31,7 +31,7 @@
static struct bio_set *bounce_bio_set, *bounce_bio_split;
static mempool_t *page_pool, *isa_page_pool;
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
+#if defined(CONFIG_HIGHMEM)
static __init int init_emergency_pool(void)
{
#if defined(CONFIG_HIGHMEM) && !defined(CONFIG_MEMORY_HOTPLUG)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index cf1fb3fb5d26..901b8833847f 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -200,7 +200,7 @@ comment "IDE chipset support/bugfixes"
config IDE_GENERIC
tristate "generic/default IDE chipset support"
- depends on ALPHA || X86 || IA64 || M32R || MIPS || ARCH_RPC
+ depends on ALPHA || X86 || IA64 || MIPS || ARCH_RPC
default ARM && ARCH_RPC
help
This is the generic IDE driver. This driver attaches to the
diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 54d7c4685d23..80c0d69b83ac 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -13,13 +13,10 @@
#include
#include
-/* FIXME: convert arm and m32r to use ide_platform host driver */
+/* FIXME: convert arm to use ide_platform host driver */
#ifdef CONFIG_ARM
#include
#endif
-#ifdef CONFIG_M32R
-#include
-#endif
#define DRV_NAME "ide_generic"
@@ -35,13 +32,6 @@ static const struct ide_port_info ide_generic_port_info = {
#ifdef CONFIG_ARM
static const u16 legacy_bases[] = { 0x1f0 };
static const int legacy_irqs[] = { IRQ_HARDDISK };
-#elif defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_MAPPI2) || \
- defined(CONFIG_PLAT_OPSPUT)
-static const u16 legacy_bases[] = { 0x1f0 };
-static const int legacy_irqs[] = { PLD_IRQ_CFIREQ };
-#elif defined(CONFIG_PLAT_MAPPI3)
-static const u16 legacy_bases[] = { 0x1f0, 0x170 };
-static const int legacy_irqs[] = { PLD_IRQ_CFIREQ, PLD_IRQ_IDEIREQ };
#elif defined(CONFIG_ALPHA)
static const u16 legacy_bases[] = { 0x1f0, 0x170, 0x1e8, 0x168 };
static const int legacy_irqs[] = { 14, 15, 11, 10 };
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index be1b4921f22a..eefac7978f93 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) ||
defined(CONFIG_RISCV) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) ||
defined(CONFIG_RISCV)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "get_cycles"
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index eb83d94ab4fe..38cfc8baae19 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -109,7 +109,7 @@ config HISAX_16_3
config HISAX_TELESPCI
bool "Teles PCI"
- depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS
&& !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
+ depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS
&& !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
help
This enables HiSax support for the Teles PCI.
See on how to configure it.
@@ -237,7 +237,7 @@ config HISAX_MIC
config HISAX_NETJET
bool "NET
[PATCH] lan78xx: Connect phy early
When using wicked with a lan78xx device attached to the system, we
end up with ethtool commands issued on the device before an ifup
got issued. That lead to the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 039c
pgd = 800035b3
[039c] *pgd=
Internal error: Oops: 9604 [#1] SMP
Modules linked in: [...]
Supported: Yes
CPU: 3 PID: 638 Comm: wickedd Tainted: GE
4.12.14-0-default #1
Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018
task: 800035e74180 task.stack: 800036718000
PC is at phy_ethtool_ksettings_get+0x20/0x98
LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
pc : [] lr : [] pstate: 2005
sp : 80003671bb20
x29: 80003671bb20 x28: 800035e74180
x27: 08912000 x26: 001d
x25: 0124 x24: 08f74d00
x23: 004000114809 x22:
x21: 80003671bbd0 x20:
x19: 80003671bbd0 x18: 040d
x17: 0001 x16:
x15: x14:
x13: x12: 0020
x11: 0101010101010101 x10: fefefefefefefeff
x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364
x7 : 80808080 x6 : 80003671bc9c
x5 : 80003671b9f8 x4 : 80002c296190
x3 : x2 :
x1 : 80003671bbd0 x0 : 80003671bc00
Process wickedd (pid: 638, stack limit = 0x800036718000)
Call trace:
Exception stack(0x80003671b9e0 to 0x80003671bb20)
b9e0: 80003671bc00 80003671bbd0
ba00: 80002c296190 80003671b9f8 80003671bc9c 80808080
ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101
ba40: 0020
ba60: 0001 040d 80003671bbd0
ba80: 80003671bbd0 004000114809
baa0: 08f74d00 0124 001d 08912000
bac0: 800035e74180 80003671bb20 00dcca84 80003671bb20
bae0: 086f7f30 2005 80002c296000 800035223900
bb00: 80003671bb20 086f7f30
[] phy_ethtool_ksettings_get+0x20/0x98
[] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx]
[] ethtool_get_settings+0x68/0x210
[] dev_ethtool+0x214/0x2180
[] dev_ioctl+0x400/0x630
[] sock_do_ioctl+0x70/0x88
[] sock_ioctl+0x208/0x368
[] do_vfs_ioctl+0xb0/0x848
[] SyS_ioctl+0x8c/0xa8
Exception stack(0x80003671bec0 to 0x80003671c000)
bec0: 0009 8946 f4e841d0 aa0032687465
bee0: fa2319d4 f4e841d4 32687465 32687465
bf00: 001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f
bf20: 0101010101010101 0020 7f510c68
bf40: 7f6a9d18 7f44ce30 040d 7f6f98f0
bf60: f4e842c0 0001 fa2c2e00 7f6ab000
bf80: f4e842c0 7f62a000 fa2b9f20 fa2c2e00
bfa0: f4e84818 f4e841a0 7f5ad0cc f4e841a0
bfc0: 7f44ce3c 8000 0009 001d
bfe0:
The culprit is quite simple: The driver tries to access the phy left and right,
but only actually has a working reference to it when the device is up.
The fix thus is quite simple too: Get a reference to the phy on probe already
and keep it even when the device is going down.
With this patch applied, I can successfully run wicked on my system and bring
the interface up and down as many times as I want, without getting NULL pointer
dereferences in between.
Signed-off-by: Alexander Graf
---
drivers/net/usb/lan78xx.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 60a604cc7647..931cc124ab0c 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
dev->fc_autoneg = phydev->autoneg;
- phy_start(phydev);
-
netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
return 0;
@@ -2512,9 +2510,7 @@ static int lan78xx_open(struct net_device *net)
if (ret < 0)
goto done;
- ret = lan78xx_phy_init(dev);
- if (ret < 0)
- goto done;
+ phy_start(net->phydev);
/* for Link Check */
if (dev->urb_intr) {
@@ -2575,13 +2571,7 @@ static int lan78xx_stop(struct net_device *net)
if (ti
Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind
On 03/14/2018 03:37 PM, Daniel Borkmann wrote:
> On 03/14/2018 04:39 AM, Alexei Starovoitov wrote:
> [...]
>> +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) \
>> +BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET4_BIND)
>> +
>> +#define BPF_CGROUP_RUN_PROG_INET6_BIND(sk, uaddr) \
>> +BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET6_BIND)
>> +
>> #define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops)
>>\
>> ({ \
>> int __ret = 0; \
>> @@ -135,6 +154,8 @@ static inline int cgroup_bpf_inherit(struct cgroup
>> *cgrp) { return 0; }
>> #define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk,skb) ({ 0; })
>> #define BPF_CGROUP_RUN_PROG_INET_EGRESS(sk,skb) ({ 0; })
>> #define BPF_CGROUP_RUN_PROG_INET_SOCK(sk) ({ 0; })
>> +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) ({ 0; })
>> +#define BPF_CGROUP_RUN_PROG_INET6_BIND(sk, uaddr) ({ 0; })
>> #define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops) ({ 0; })
>> #define BPF_CGROUP_RUN_PROG_DEVICE_CGROUP(type,major,minor,access) ({ 0; })
>>
>> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
>> index 19b8349a3809..eefd877f8e68 100644
>> --- a/include/linux/bpf_types.h
>> +++ b/include/linux/bpf_types.h
>> @@ -8,6 +8,8 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_SCHED_ACT, tc_cls_act)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_XDP, xdp)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SKB, cg_skb)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SOCK, cg_sock)
>> +BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_INET4_BIND, cg_inet4_bind)
>> +BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_INET6_BIND, cg_inet6_bind)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_IN, lwt_inout)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_OUT, lwt_inout)
>> BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_XMIT, lwt_xmit)
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index fdb691b520c0..fe469320feab 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -1001,6 +1001,16 @@ static inline int bpf_tell_extensions(void)
>> return SKF_AD_MAX;
>> }
>>
>> +struct bpf_sock_addr_kern {
>> +struct sock *sk;
>> +struct sockaddr *uaddr;
>> +/* Temporary "register" to make indirect stores to nested structures
>> + * defined above. We need three registers to make such a store, but
>> + * only two (src and dst) are available at convert_ctx_access time
>> + */
>> +u64 tmp_reg;
>> +};
>> +
>> struct bpf_sock_ops_kern {
>> struct sock *sk;
>> u32 op;
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 2a66769e5875..78628a3f3cd8 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -133,6 +133,8 @@ enum bpf_prog_type {
>> BPF_PROG_TYPE_SOCK_OPS,
>> BPF_PROG_TYPE_SK_SKB,
>> BPF_PROG_TYPE_CGROUP_DEVICE,
>> +BPF_PROG_TYPE_CGROUP_INET4_BIND,
>> +BPF_PROG_TYPE_CGROUP_INET6_BIND,
>
> Could those all be merged into BPF_PROG_TYPE_SOCK_OPS? I'm slowly getting
> confused by the many sock_*/sk_* prog types we have. The attach hook could
> still be something like BPF_CGROUP_BIND/BPF_CGROUP_CONNECT. Potentially
> storing some prog-type specific void *private_data in prog's aux during
> verification could be a way (similarly as you mention) which can later be
> retrieved at attach time to reject with -ENOTSUPP or such.
>
>> };
>>
>> enum bpf_attach_type {
>> @@ -143,6 +145,8 @@ enum bpf_attach_type {
>> BPF_SK_SKB_STREAM_PARSER,
>> BPF_SK_SKB_STREAM_VERDICT,
>> BPF_CGROUP_DEVICE,
>> +BPF_CGROUP_INET4_BIND,
>> +BPF_CGROUP_INET6_BIND,
>
> Binding to v4 mapped v6 address would work as well, right? Can't this be
> squashed into one attach type as mentioned?
>
>> __MAX_BPF_ATTACH_TYPE
>> };
>>
>> @@ -953,6 +957,26 @@ struct bpf_map_info {
>> __u64 netns_ino;
>> } __attribute__((aligned(8)));
>>
>> +/* User bpf_sock_addr struct to access socket fields and sockaddr struct
>> passed
>> + * by user and intended to be used by socket (e.g. to bind to, depends on
>> + * attach attach type).
>> + */
>> +struct bpf_sock_addr {
>> +__u32 user_family; /* Allows 4-byte read, but no write. */
>> +__u32 user_ip4; /* Allows 1,2,4-byte read and 4-byte write.
>> + * Stored in network byte order.
>> + */
>> +__u32 user_ip6[4]; /* Allows 1,2,4-byte read an 4-byte write.
>> + * Stored in network byte order.
>> + */
>> +__u32 user_port;/* Allows 4-byte read and write.
>> + * Stored in network byte order
>> + */
>> +__u32 family; /* Allows 4-byte read, but no write */
>> +__u32 type; /* Allows 4-byte read, but no write */
>> +__u32 protocol; /* Allows 4-byte
Fw: [Bug 199109] New: pptp: kernel printk "recursion detected", and then reboot itself
Begin forwarded message:
Date: Wed, 14 Mar 2018 06:56:09 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 199109] New: pptp: kernel printk "recursion detected", and then
reboot itself
https://bugzilla.kernel.org/show_bug.cgi?id=199109
Bug ID: 199109
Summary: pptp: kernel printk "recursion detected", and then
reboot itself
Product: Networking
Version: 2.5
Kernel Version: 4.9.77
Hardware: Mips32
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: step...@networkplumber.org
Reporter: xuheng...@zoho.com
Regression: No
Created attachment 274715
--> https://bugzilla.kernel.org/attachment.cgi?id=274715&action=edit
system log
Use openwrt LEDE, (gcc version 5.5.0 (OpenWrt GCC 5.5.0 r5932-9c4fe10) ).
When use pptp, make WAN(eth1) down and then make WAN(eth1) up, pptp will redial
itself. Do this in a loop.
After a while, kernel print "recursion detected" and "net_ratelimit: 49422
callbacks suppressed", print this many times, then system reboot.
When add more printk in driver "driver/net/ppp/ppp_generic.c", fond it fall in
loop in "static void __ppp_xmit_process(struct ppp *ppp)", which called by
"static void __ppp_channel_push(struct channel *pch)".
__ppp_channel_push() locked ppp->xmit_recursion, and loop for long time( while
(!ppp->xmit_pending && (skb = skb_dequeue(&ppp->file.xq))) ppp_send_frame(ppp,
skb); ). Some other thread want to lock ppp->xmit_recursion, but failed.
static void __ppp_channel_push(struct channel *pch)
{
struct sk_buff *skb;
struct ppp *ppp;
spin_lock_bh(&pch->downl);
if (pch->chan) {
while (!skb_queue_empty(&pch->file.xq)) {
skb = skb_dequeue(&pch->file.xq);
if (!pch->chan->ops->start_xmit(pch->chan, skb)) {
/* put the packet back and try again later */
skb_queue_head(&pch->file.xq, skb);
break;
}
}
} else {
/* channel got deregistered */
skb_queue_purge(&pch->file.xq);
}
spin_unlock_bh(&pch->downl);
/* see if there is anything from the attached unit to be sent */
if (skb_queue_empty(&pch->file.xq)) {
ppp = pch->ppp;
if (ppp)
__ppp_xmit_process(ppp);
}
}
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [v4.15.9] BUG: KASAN: slab-out-of-bounds in __dev_queue_xmit+0x2e5/0x14c0
On 03/13/2018 11:55 PM, Andrei Vagin wrote: Hi, I got the following warning on the v4.15.9 kernel. :[ 4483.052174] == :[ 4483.052659] BUG: KASAN: slab-out-of-bounds in __dev_queue_xmit+0x2e5/0x14c0 :[ 4483.052937] Read of size 1 at addr 880067ef7bc0 by task objtool/26177 : :[ 4483.053361] CPU: 0 PID: 26177 Comm: objtool Not tainted 4.15.9 #1 :[ 4483.053603] Hardware name: Parallels Software International Inc. Parallels Virtual Platform/Parallels Virtual Platform, BIOS 6.12.26068.1232434 02/27/2017 :[ 4483.054116] Call Trace: :[ 4483.054272] :[ 4483.054419] dump_stack+0xda/0x16f :[ 4483.054589] ? _atomic_dec_and_lock+0x101/0x101 :[ 4483.054810] ? rcu_lockdep_current_cpu_online+0xba/0x120 :[ 4483.055077] print_address_description+0x6a/0x270 :[ 4483.055312] kasan_report+0x277/0x360 :[ 4483.055491] ? __dev_queue_xmit+0x2e5/0x14c0 :[ 4483.055688] __dev_queue_xmit+0x2e5/0x14c0 :[ 4483.055892] ? do_raw_spin_unlock+0x147/0x220 :[ 4483.056122] ? netdev_pick_tx+0x150/0x150 :[ 4483.056369] ? mark_held_locks+0x52/0x90 :[ 4483.056560] ? __lock_acquire+0x61b/0x2060 :[ 4483.056771] ? match_held_lock+0x8d/0x420 :[ 4483.056969] ? mark_lock+0x1c9/0xa30 :[ 4483.057173] ? save_trace+0x1e0/0x1e0 :[ 4483.057367] ? print_irqtrace_events+0x110/0x110 :[ 4483.057602] ? nf_conntrack_alter_reply+0x2a0/0x2a0 [nf_conntrack] :[ 4483.057867] ? tcp_new+0x510/0x510 [nf_conntrack] :[ 4483.058101] ? debug_check_no_locks_freed+0x1b0/0x1b0 :[ 4483.058360] ? kernel_text_address+0xec/0x100 :[ 4483.058562] ? find_held_lock+0x6d/0xd0 :[ 4483.058754] ? lock_downgrade+0x320/0x320 :[ 4483.058959] ? lock_release+0x4d0/0x4d0 :[ 4483.059184] ? nf_ct_get_tuple+0x98/0xd0 [nf_conntrack] :[ 4483.059422] ? rcu_lockdep_current_cpu_online+0xba/0x120 :[ 4483.059655] ? mark_held_locks+0x52/0x90 :[ 4483.059845] ? ip_finish_output2+0x83d/0xb10 :[ 4483.060068] ip_finish_output2+0x93f/0xb10 :[ 4483.060292] ? ip_copy_metadata+0x320/0x320 :[ 4483.060485] ? save_trace+0x1e0/0x1e0 :[ 4483.060659] ? rcu_is_watching+0x81/0xc0 :[ 4483.060872] ? ipv4_nlattr_to_tuple+0x80/0x80 [nf_conntrack_ipv4] :[ 4483.061166] ? nf_ct_deliver_cached_events+0x1a3/0x450 [nf_conntrack] :[ 4483.061461] ? __local_bh_enable_ip+0x9a/0x110 :[ 4483.061662] ? ipt_do_table+0x65c/0x7e0 :[ 4483.061845] ? ipv4_mtu+0x1ac/0x220 :[ 4483.062025] ? find_held_lock+0x6d/0xd0 :[ 4483.062267] ? ip_finish_output+0x435/0x590 :[ 4483.062462] ip_finish_output+0x435/0x590 :[ 4483.062649] ? ip_fragment.constprop.45+0xf0/0xf0 :[ 4483.062860] ? ipv4_nlattr_to_tuple+0x80/0x80 [nf_conntrack_ipv4] :[ 4483.063142] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat] :[ 4483.063393] ? iptable_nat_ipv4_local_fn+0x20/0x20 [iptable_nat] :[ 4483.063634] ? rcu_is_watching+0x81/0xc0 :[ 4483.063829] ? nf_hook_slow+0xa4/0xe0 :[ 4483.064031] ip_output+0x12a/0x450 :[ 4483.064237] ? ip_mc_output+0xc30/0xc30 :[ 4483.064435] ? ip_fragment.constprop.45+0xf0/0xf0 :[ 4483.064644] ? tcp_make_synack+0x7b9/0x950 :[ 4483.064849] ip_build_and_send_pkt+0x2f7/0x480 :[ 4483.065086] ? ip_local_out+0x90/0x90 :[ 4483.065283] ? __lockdep_init_map+0x98/0x2a0 :[ 4483.065485] ? inet_bind_hash+0x130/0x130 :[ 4483.065681] tcp_v4_send_synack+0x1b7/0x280 :[ 4483.065878] ? tcp_v4_send_check+0x40/0x40 :[ 4483.066094] ? ip_mc_output+0x4b0/0xc30 :[ 4483.066344] ? inet_csk_reqsk_queue_hash_add+0x11b/0x170 :[ 4483.066569] ? inet_csk_route_child_sock+0x430/0x430 :[ 4483.066798] tcp_conn_request+0x152e/0x1a70 :[ 4483.067017] ? tcp_event_data_recv+0x6a0/0x6a0 :[ 4483.067259] ? __lock_acquire+0x61b/0x2060 :[ 4483.067483] ? debug_check_no_locks_freed+0x1b0/0x1b0 :[ 4483.067696] ? print_irqtrace_events+0x110/0x110 :[ 4483.067902] ? __lock_acquire+0x61b/0x2060 :[ 4483.068126] ? match_held_lock+0x8d/0x420 :[ 4483.068376] ? match_held_lock+0x8d/0x420 :[ 4483.068617] ? match_held_lock+0x8d/0x420 :[ 4483.068868] ? save_trace+0x1e0/0x1e0 :[ 4483.069132] ? save_trace+0x1e0/0x1e0 :[ 4483.069383] ? save_trace+0x1e0/0x1e0 :[ 4483.069615] ? find_held_lock+0x6d/0xd0 :[ 4483.069888] ? __lock_is_held+0x71/0xc0 :[ 4483.070181] ? tcp_rcv_state_process+0x507/0x1fb0 :[ 4483.070557] tcp_rcv_state_process+0x507/0x1fb0 :[ 4483.070824] ? rcu_is_watching+0x81/0xc0 :[ 4483.071103] ? tcp_finish_connect+0x180/0x180 :[ 4483.071394] ? sk_filter_trim_cap+0x30b/0x510 :[ 4483.071658] ? sk_skb_is_valid_access+0xd0/0xd0 :[ 4483.071933] ? tcp_parse_md5sig_option+0x6d/0x90 :[ 4483.072231] ? tcp_v4_inbound_md5_hash+0xca/0x2a0 :[ 4483.072530] ? tcp_v4_do_rcv+0x266/0x340 :[ 4483.072763] tcp_v4_do_rcv+0x266/0x340 :[ 4483.073018] tcp_v4_rcv+0x1255/0x1290 :[ 4483.073324] ? tcp_v4_early_demux+0x3b0/0x3b0 :[ 4483.073583] ? find_held_lock+0xb0/0xd0 :[ 4483.073840] ip_local_deliver_finish+0x1c9/0x5f0 :[ 4483.074137] ? ipv4_nlattr_to_tuple+0x80/0x80 [nf_conntrack_ipv4] :[ 4483.074425] ? inet_del_offload+0x40/0x40 :[ 4483.074618] ? nf_hook_slow+0xa4/0xe0 :[ 448
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
On Wed, 14 Mar 2018 12:01:19 +0100
Rafał Miłecki wrote:
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 19048526b4af..db6987015fb1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -230,6 +230,34 @@ static void brcmf_netdev_set_multicast_list(struct
> net_device *ndev)
> schedule_work(&ifp->multicast_work);
> }
>
> +/**
> + * brcmf_skb_is_iapp - checks if skb is an IAPP packet
> + *
> + * @skb: skb to check
> + */
> +static bool brcmf_skb_is_iapp(struct sk_buff *skb)
> +{
> + const u8 iapp_l2_update_packet[6] __aligned(2) = {
> + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
> + };
> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + const u16 *a = (const u16 *)eth_data;
> + const u16 *b = (const u16 *)iapp_l2_update_packet;
> +#endif
> +
> + if (skb->len - skb->mac_len != 6 ||
> + !is_multicast_ether_addr(eth_hdr(skb)->h_dest))
> + return false;
> +
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + return !(((*(const u32 *)eth_data) ^ (*(const u32
> *)iapp_l2_update_packet)) |
> + ((*(const u16 *)(eth_data + 4)) ^ (*(const u16
> *)(iapp_l2_update_packet + 4;
> +#else
> + return !((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2]));
> +#endif
> +}
> +
> static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
> struct net_device *ndev)
> {
> @@ -250,6 +278,12 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct
> sk_buff *skb,
> goto done;
> }
>
> + if (!IS_ENABLED(CONFIG_BRCMFMAC_IAPP) && brcmf_skb_is_iapp(skb)) {
> + dev_kfree_skb(skb);
> + ret = -EINVAL;
> + goto done;
> + }
> +
The usual way to handle config options in kernel is either inline
stub function or #define
#ifdef CONFIG_BRFMMAC_IAPP
static bool brcmf_skb_is_app(...) {
real code
}
#else
#define brcmf_skb_is_app (false)
#endif
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
Arend van Spriel writes: > On 3/14/2018 3:24 PM, Kalle Valo wrote: >>> +config BRCMFMAC_IAPP >>> >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >>> >+ depends on BRCMFMAC >>> >+ ---help--- >>> >+Most of Broadcom's firmwares can send 802.11f ADD frame every >>> >+time new STA connects to the AP interface. Some recent ones >>> >+can also disassociate STA when they receive such a frame. >>> >+ >>> >+It's important to understand this behavior can lead to a local >>> >+DoS security issue. Attacker may trigger disassociation of any >>> >+STA by sending a proper Ethernet frame to the wireless >>> >+interface. >>> >+ >>> >+Moreover this feature may break AP interfaces in some specific >>> >+setups. This applies e.g. to the bridge with hairpin mode >>> >+enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet >>> >+generated by a firmware will get passed back to the wireless >>> >+interface and cause immediate disassociation of just-connected >>> >+STA. >> Sorry for jumping late, but does it really make sense to have a Kconfig >> option for this? I don't think we should add a Kconfig option for every >> strange feature, there should be stronger reasons (size savings etc) >> before adding a Kconfig option. >> >> And in this case the size savings can't be much. Wouldn't a module >> parameter be simpler for a functionality change like this? > > Hi Kalle, > > Good to be wary about Kconfig option. I think Linus doesn't like pointless Kconfig options, me neither for that matter, so I try to make sure the justifications are really there before adding anything new. > So my reason for asking a Kconfig option is that this is directly in > the datapaths (tx and rx) so I prefer to disable/enable it compile > time rather then runtime. I'm no cpu profile expert but is really one (or two?) if checks of a cached variable in the datapath really measurable? My guess is that it's just noise in the results. But I'm not going to argue about it, if you think it's still needed I'm fine with that. Just mention in the commit log the justification the new Kconfig option. -- Kalle Valo
Re: [Intel-wired-lan] [PATCH 12/15] ice: Add stats and ethtool support
On Tue, 13 Mar 2018 14:14:14 -0700 Jesse Brandeburg wrote: > Maybe it's just that I've been doing this too long, but I regularly > (and many other customers/users do as well) depend on the ethtool stats > being atomically updated w.r.t. each other. This means that if I'm > getting the over rx_packets, as well as the per-queue rx_packets, and I > read them all at once from the driver with ethtool, then I can check > that things are working as expected. Any application depending on this behavior is really fragile. It is unportable to other devices (which I guess is to Intel's benefit) and relying on guarantees not provided by current Linux network devices.
Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
On Tue, Mar 13, 2018 at 06:13:45PM +0200, Yuval Shaia wrote:
> On Tue, Mar 13, 2018 at 05:07:22PM +0200, Liran Alon wrote:
> > Before this commit, dev_forward_skb() always cleared packet's
> > per-network-namespace info. Even if the packet doesn't cross
> > network namespaces.
> >
> > The comment above dev_forward_skb() describes that this is done
> > because the receiving device may be in another network namespace.
> > However, this case can easily be tested for and therefore we can
> > scrub packet's per-network-namespace info only when receiving device
> > is indeed in another network namespace.
> >
> > Therefore, this commit changes dev_forward_skb() to tell
> > skb_scrub_packet() that skb has crossed network-namespace only in case
> > transmitting device (skb->dev) network namespace is different then
> > receiving device (dev) network namespace.
> >
> > An example of a netdev that use skb_forward_skb() is veth.
> > Thus, before this commit a packet transmitted from one veth peer to
> > another when both veth peers are on same network namespace will lose
> > it's skb->mark. The bug could easily be demonstrated by the following:
> >
> > ip netns add test
> > ip netns exec test bash
> > ip link add veth-a type veth peer name veth-b
> > ip link set veth-a up
> > ip link set veth-b up
> > ip addr add dev veth-a 12.0.0.1/24
> > tc qdisc add dev veth-a root handle 1 prio
> > tc qdisc add dev veth-b ingress
> > tc filter add dev veth-a parent 1: u32 match u32 0 0 action skbedit mark
> > 1337
> > tc filter add dev veth-b parent : basic match 'meta(nf_mark eq 1337)'
> > action simple "skb->mark 1337!"
> > dmesg -C
> > ping 12.0.0.2
> > dmesg
> >
> > Before this change, the above will print nothing to dmesg.
> > After this change, "skb->mark 1337!" will be printed as necessary.
>
> Hi Liran,
>
> >
> > Signed-off-by: Liran Alon
> > Reviewed-by: Yuval Shaia
> > Signed-off-by: Yuval Shaia
>
> I did not earned the credits for SOB, only r-b.
Had an offlist conversation with Liran,
Turns out that this SOB is ok.
Yuval
>
> Yuval
>
> > ---
> > include/linux/netdevice.h | 2 +-
> > net/core/dev.c| 6 +++---
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 5eef6c8e2741..5908f1e31ee2 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -3371,7 +3371,7 @@ static __always_inline int dev_forward_skb(struct
> > net_device *dev,
> > return NET_RX_DROP;
> > }
> >
> > - skb_scrub_packet(skb, true);
> > + skb_scrub_packet(skb, !net_eq(dev_net(dev), dev_net(skb->dev)));
> > skb->priority = 0;
> > return 0;
> > }
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 2cedf520cb28..087787dd0a50 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1877,9 +1877,9 @@ int __dev_forward_skb(struct net_device *dev, struct
> > sk_buff *skb)
> > * start_xmit function of one device into the receive queue
> > * of another device.
> > *
> > - * The receiving device may be in another namespace, so
> > - * we have to clear all information in the skb that could
> > - * impact namespace isolation.
> > + * The receiving device may be in another namespace.
> > + * In that case, we have to clear all information in the
> > + * skb that could impact namespace isolation.
> > */
> > int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
> > {
> > --
> > 1.9.1
> >
RE: [PATCH] lan78xx: Connect phy early
Hi Alexander, Thanks for patch. We will look into it if there is any corner case Such as plug in/out while operations. Woojung > -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Wednesday, March 14, 2018 10:55 AM > To: Woojung Huh - C21699 > Cc: UNGLinuxDriver ; netdev@vger.kernel.org; > linux- > u...@vger.kernel.org; linux-ker...@vger.kernel.org; Thomas Bogendoerfer > ; Phil Elwell > Subject: [PATCH] lan78xx: Connect phy early > > When using wicked with a lan78xx device attached to the system, we > end up with ethtool commands issued on the device before an ifup > got issued. That lead to the following crash: > > Unable to handle kernel NULL pointer dereference at virtual address > 039c > pgd = 800035b3 > [039c] *pgd= > Internal error: Oops: 9604 [#1] SMP > Modules linked in: [...] > Supported: Yes > CPU: 3 PID: 638 Comm: wickedd Tainted: GE > 4.12.14-0-default #1 > Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018 > task: 800035e74180 task.stack: 800036718000 > PC is at phy_ethtool_ksettings_get+0x20/0x98 > LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx] > pc : [] lr : [] pstate: 2005 > sp : 80003671bb20 > x29: 80003671bb20 x28: 800035e74180 > x27: 08912000 x26: 001d > x25: 0124 x24: 08f74d00 > x23: 004000114809 x22: > x21: 80003671bbd0 x20: > x19: 80003671bbd0 x18: 040d > x17: 0001 x16: > x15: x14: > x13: x12: 0020 > x11: 0101010101010101 x10: fefefefefefefeff > x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364 > x7 : 80808080 x6 : 80003671bc9c > x5 : 80003671b9f8 x4 : 80002c296190 > x3 : x2 : > x1 : 80003671bbd0 x0 : 80003671bc00 > Process wickedd (pid: 638, stack limit = 0x800036718000) > Call trace: > Exception stack(0x80003671b9e0 to 0x80003671bb20) > b9e0: 80003671bc00 80003671bbd0 > ba00: 80002c296190 80003671b9f8 80003671bc9c 80808080 > ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101 > ba40: 0020 > ba60: 0001 040d 80003671bbd0 > ba80: 80003671bbd0 004000114809 > baa0: 08f74d00 0124 001d 08912000 > bac0: 800035e74180 80003671bb20 00dcca84 80003671bb20 > bae0: 086f7f30 2005 80002c296000 800035223900 > bb00: 80003671bb20 086f7f30 > [] phy_ethtool_ksettings_get+0x20/0x98 > [] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx] > [] ethtool_get_settings+0x68/0x210 > [] dev_ethtool+0x214/0x2180 > [] dev_ioctl+0x400/0x630 > [] sock_do_ioctl+0x70/0x88 > [] sock_ioctl+0x208/0x368 > [] do_vfs_ioctl+0xb0/0x848 > [] SyS_ioctl+0x8c/0xa8 > Exception stack(0x80003671bec0 to 0x80003671c000) > bec0: 0009 8946 f4e841d0 aa0032687465 > bee0: fa2319d4 f4e841d4 32687465 32687465 > bf00: 001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f > bf20: 0101010101010101 0020 7f510c68 > bf40: 7f6a9d18 7f44ce30 040d 7f6f98f0 > bf60: f4e842c0 0001 fa2c2e00 7f6ab000 > bf80: f4e842c0 7f62a000 fa2b9f20 fa2c2e00 > bfa0: f4e84818 f4e841a0 7f5ad0cc f4e841a0 > bfc0: 7f44ce3c 8000 0009 001d > bfe0: > > The culprit is quite simple: The driver tries to access the phy left and > right, > but only actually has a working reference to it when the device is up. > > The fix thus is quite simple too: Get a reference to the phy on probe already > and keep it even when the device is going down. > > With this patch applied, I can successfully run wicked on my system and bring > the interface up and down as many times as I want, without getting NULL > pointer > dereferences in between. > > Signed-off-by: Alexander Graf > --- > drivers/net/usb/lan78xx.c | 21 ++--- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c > index 60a604cc7647..931cc124ab0c 100644 > --- a/drivers/net/usb/lan78xx.c > +++
Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
On Wed, 14 Mar 2018 17:08:48 +0200 Kalle Valo wrote: > Arend van Spriel writes: > > > On 3/14/2018 3:24 PM, Kalle Valo wrote: > >>> +config BRCMFMAC_IAPP > >>> >+bool "Partial support for obsoleted Inter-Access Point Protocol" > >>> >+depends on BRCMFMAC > >>> >+---help--- > >>> >+ Most of Broadcom's firmwares can send 802.11f ADD frame every > >>> >+ time new STA connects to the AP interface. Some recent ones > >>> >+ can also disassociate STA when they receive such a frame. > >>> >+ > >>> >+ It's important to understand this behavior can lead to a local > >>> >+ DoS security issue. Attacker may trigger disassociation of any > >>> >+ STA by sending a proper Ethernet frame to the wireless > >>> >+ interface. > >>> >+ > >>> >+ Moreover this feature may break AP interfaces in some specific > >>> >+ setups. This applies e.g. to the bridge with hairpin mode > >>> >+ enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet > >>> >+ generated by a firmware will get passed back to the wireless > >>> >+ interface and cause immediate disassociation of just-connected > >>> >+ STA. > >> Sorry for jumping late, but does it really make sense to have a Kconfig > >> option for this? I don't think we should add a Kconfig option for every > >> strange feature, there should be stronger reasons (size savings etc) > >> before adding a Kconfig option. > >> > >> And in this case the size savings can't be much. Wouldn't a module > >> parameter be simpler for a functionality change like this? > > > > Hi Kalle, > > > > Good to be wary about Kconfig option. > > I think Linus doesn't like pointless Kconfig options, me neither for > that matter, so I try to make sure the justifications are really there > before adding anything new. > > > So my reason for asking a Kconfig option is that this is directly in > > the datapaths (tx and rx) so I prefer to disable/enable it compile > > time rather then runtime. > > I'm no cpu profile expert but is really one (or two?) if checks of a > cached variable in the datapath really measurable? My guess is that it's > just noise in the results. > > But I'm not going to argue about it, if you think it's still needed I'm > fine with that. Just mention in the commit log the justification the new > Kconfig option. If you have to disable it a module parameter is not a complete disaster
Re: [pci PATCH v6 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
On Wed, Mar 14, 2018 at 1:54 AM, Christoph Hellwig wrote:
> On Tue, Mar 13, 2018 at 02:28:49PM -0700, Alexander Duyck wrote:
>> From: Alexander Duyck
>>
>> This patch adds a common configuration function called
>> pci_sriov_configure_simple that will allow for managing VFs on devices
>> where the PF is not capable of managing VF resources.
>>
>> Signed-off-by: Alexander Duyck
>> ---
>>
>> v5: New patch replacing pci_sriov_configure_unmanaged with
>> pci_sriov_configure_simple
>> Dropped bits related to autoprobe changes
>> v6: Defined pci_sriov_configure_simple as NULL if IOV is disabled
>>
>> drivers/pci/iov.c | 32
>> include/linux/pci.h |3 +++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>> index 677924ae0350..bd7021491fdb 100644
>> --- a/drivers/pci/iov.c
>> +++ b/drivers/pci/iov.c
>> @@ -807,3 +807,35 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
>> return dev->sriov->total_VFs;
>> }
>> EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
>> +
>> +/**
>> + * pci_sriov_configure_simple - helper to configure unmanaged SR-IOV
>> + * @dev: the PCI device
>> + * @nr_virtfn: number of virtual functions to enable, 0 to disable
>> + *
>> + * Used to provide generic enable/disable SR-IOV option for devices
>> + * that do not manage the VFs generated by their driver
>> + */
>> +int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn)
>> +{
>> + int err = -EINVAL;
>
> This assignment seems like it is never used..
It applies in the case where we are setting a number of VFs when VFs
are already allocated. It was needed since the last statement ended in
an if.
>> +
>> + might_sleep();
>> +
>> + if (!dev->is_physfn)
>> + return -ENODEV;
>> +
>> + if (pci_vfs_assigned(dev)) {
>> + pci_warn(dev,
>> + "Cannot modify SR-IOV while VFs are assigned\n");
>> + err = -EPERM;
>
> Why not:
>
> if (pci_vfs_assigned(dev)) {
> pci_warn(dev,
> "Cannot modify SR-IOV while VFs are assigned\n");
> return -EPERM;
> }
Symmetry. I had this as one of 3 blocks and just did it this way to be
consistent with the next two statements. I could probably just return
from each if block if that is preferred.
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig
For v7 I can probably drop the err parameter and just return the
necessary error values directly.
interdependencies with cxgb4 and iw_cxgb4
Hey Dave, We've been discussing dependency issues between cxgb4 and the upper layer drivers including iw_cxgb4 on linux-rdma [1], and I want to broaden this discussion to include netdev and you, since this involves both linux-rdma and netdev. (note the SRQ patch submission that triggered this discussion was sent to linux-rdma, but it should have also included netdev. This was an oversight and will be corrected on the next submission depending on how chelsio decides to proceed) In a nutshell, Chelsio has a few patch series to submit that require enabling some feature in cxgb4 that is then used by iw_cxgb4. SRQ support is one such series. The series as a whole spans both netdev and linux-rdma maintainers. Because of the compile dependency between iw_cxgb4 and cxgb4 introduced by this series, the cxgb4 parts and iw_cxgb4 parts cannot be split across maintainers. Further, if one maintainer merges the entire series, then there are issues if commits are submitted to the other maintainer that conflict. This issue has also been dealt-with for Mellanox drivers, I believe. I take it the solution for them was a k.o. signed repo, that they maintain, where both linux-rdma and netdev take PRs from for commits that are needed in both repos. Then these are reconciled when both repos are merged into Linus' repo. (I hope my understanding of this is correct) For Chelsio, this is perhaps a possibility, but I'm wondering if there is a simpler solution? A few other option we've been discussing include: 1) submit the cxgb4-only changes to netdev in release cycle X, and then only submit the iw_cxgb4 (or other upper drivers) changes that use them in release cycle X+1. The pro of this is simplicity. The con is timeliness - it takes 2 release cycles to get the feature upstream. 2) run the entire series through one maintainer's repo (with all maintainers' ACK on the content and plan, of course), and ensuring no conflicting commits are submitted for the rest of that release cycle. I'm not really sure that this is feasible given anyone could create commits for upstream drivers. So how could Chelsio really control this? Do you have any suggestions on how we should proceed? [1] https://www.spinics.net/lists/linux-rdma/msg61856.html Thanks, Steve.
Re: [pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
On Wed, Mar 14, 2018 at 1:56 AM, Christoph Hellwig wrote:
>> +
>> +/**
>> + * pci_pf_stub_white_list - White list of devices to bind pci-pf-stub onto
>> + *
>> + * This table provides the list of IDs this driver is supposed to bind
>> + * onto. You could think of this as a list of "quirked" devices where we
>> + * are adding support for SR-IOV here since there are no other drivers
>> + * that they would be running under.
>> + *
>> + * Layout of the table below is as follows:
>> + * { Vendor ID, Device ID,
>> + * SubVendor ID, SubDevice ID,
>> + * Class, Class Mask,
>> + * private data (not used) }
>> + */
>
> No need to document the PCI device table format in a random driver.
I realize this probably isn't necessary, but I wanted to document it
to make it clear in terms of layout so that it is't confused with the
quirk structure layout since this has been referred to as a "quirk"
driver a few times.
> Otherwise looks fine:
>
> Reviewed-by: Christoph Hellwig
[PATCH 02/47] net: tile: remove ethernet drivers
The tile architecture is obsolete and getting removed. From all I can tell, later ARM based products use a different ethernet driver, so we should remove this one as well. Signed-off-by: Arnd Bergmann --- drivers/net/ethernet/Kconfig|1 - drivers/net/ethernet/Makefile |1 - drivers/net/ethernet/tile/Kconfig | 18 - drivers/net/ethernet/tile/Makefile | 11 - drivers/net/ethernet/tile/tilegx.c | 2279 - drivers/net/ethernet/tile/tilepro.c | 2397 --- 6 files changed, 4707 deletions(-) delete mode 100644 drivers/net/ethernet/tile/Kconfig delete mode 100644 drivers/net/ethernet/tile/Makefile delete mode 100644 drivers/net/ethernet/tile/tilegx.c delete mode 100644 drivers/net/ethernet/tile/tilepro.c diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig index b6cf4b6962f5..92be1ad3df59 100644 --- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -176,7 +176,6 @@ source "drivers/net/ethernet/stmicro/Kconfig" source "drivers/net/ethernet/sun/Kconfig" source "drivers/net/ethernet/tehuti/Kconfig" source "drivers/net/ethernet/ti/Kconfig" -source "drivers/net/ethernet/tile/Kconfig" source "drivers/net/ethernet/toshiba/Kconfig" source "drivers/net/ethernet/tundra/Kconfig" source "drivers/net/ethernet/via/Kconfig" diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile index 3cdf01e96e0b..edef6069dd4b 100644 --- a/drivers/net/ethernet/Makefile +++ b/drivers/net/ethernet/Makefile @@ -88,7 +88,6 @@ obj-$(CONFIG_NET_VENDOR_STMICRO) += stmicro/ obj-$(CONFIG_NET_VENDOR_SUN) += sun/ obj-$(CONFIG_NET_VENDOR_TEHUTI) += tehuti/ obj-$(CONFIG_NET_VENDOR_TI) += ti/ -obj-$(CONFIG_TILE_NET) += tile/ obj-$(CONFIG_NET_VENDOR_TOSHIBA) += toshiba/ obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/ obj-$(CONFIG_NET_VENDOR_VIA) += via/ diff --git a/drivers/net/ethernet/tile/Kconfig b/drivers/net/ethernet/tile/Kconfig deleted file mode 100644 index bdfeaf3d4fce.. diff --git a/drivers/net/ethernet/tile/Makefile b/drivers/net/ethernet/tile/Makefile deleted file mode 100644 index 3d0ae1f07fc9.. diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c deleted file mode 100644 index b3e5816a4678.. diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c deleted file mode 100644 index 56d06282fbde.. -- 2.9.0
[PATCH 03/47] net: adi: remove blackfin ethernet drivers
The blackfin architecture is getting removed, so the bfin_mac driver is now obsolete. Signed-off-by: Arnd Bergmann --- drivers/net/ethernet/Kconfig|1 - drivers/net/ethernet/Makefile |1 - drivers/net/ethernet/adi/Kconfig| 66 -- drivers/net/ethernet/adi/Makefile |5 - drivers/net/ethernet/adi/bfin_mac.c | 1881 --- drivers/net/ethernet/adi/bfin_mac.h | 104 -- include/linux/bfin_mac.h| 30 - 7 files changed, 2088 deletions(-) delete mode 100644 drivers/net/ethernet/adi/Kconfig delete mode 100644 drivers/net/ethernet/adi/Makefile delete mode 100644 drivers/net/ethernet/adi/bfin_mac.c delete mode 100644 drivers/net/ethernet/adi/bfin_mac.h delete mode 100644 include/linux/bfin_mac.h diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig index 92be1ad3df59..074d760a568b 100644 --- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -34,7 +34,6 @@ source "drivers/net/ethernet/arc/Kconfig" source "drivers/net/ethernet/atheros/Kconfig" source "drivers/net/ethernet/aurora/Kconfig" source "drivers/net/ethernet/cadence/Kconfig" -source "drivers/net/ethernet/adi/Kconfig" source "drivers/net/ethernet/broadcom/Kconfig" source "drivers/net/ethernet/brocade/Kconfig" source "drivers/net/ethernet/calxeda/Kconfig" diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile index edef6069dd4b..135dae67d671 100644 --- a/drivers/net/ethernet/Makefile +++ b/drivers/net/ethernet/Makefile @@ -21,7 +21,6 @@ obj-$(CONFIG_NET_VENDOR_ARC) += arc/ obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/ obj-$(CONFIG_NET_VENDOR_AURORA) += aurora/ obj-$(CONFIG_NET_CADENCE) += cadence/ -obj-$(CONFIG_NET_BFIN) += adi/ obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/ obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/ obj-$(CONFIG_NET_CALXEDA_XGMAC) += calxeda/ diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig deleted file mode 100644 index 98cc8f535021.. diff --git a/drivers/net/ethernet/adi/Makefile b/drivers/net/ethernet/adi/Makefile deleted file mode 100644 index b1fbe195d0e8.. diff --git a/drivers/net/ethernet/adi/bfin_mac.c b/drivers/net/ethernet/adi/bfin_mac.c deleted file mode 100644 index 7120f2b9c6ef.. diff --git a/drivers/net/ethernet/adi/bfin_mac.h b/drivers/net/ethernet/adi/bfin_mac.h deleted file mode 100644 index 4ad5b9be3f84.. diff --git a/include/linux/bfin_mac.h b/include/linux/bfin_mac.h deleted file mode 100644 index a69554ef8476.. -- 2.9.0
[PATCH 05/47] net: remove cris etrax ethernet driver
The cris architecture is getting removed, so we don't need the ethernet driver any more either. Signed-off-by: Arnd Bergmann --- drivers/net/Makefile |1 - drivers/net/cris/Makefile |1 - drivers/net/cris/eth_v10.c | 1742 3 files changed, 1744 deletions(-) delete mode 100644 drivers/net/cris/Makefile delete mode 100644 drivers/net/cris/eth_v10.c diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 04c3b747812c..91e67e375dd4 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -40,7 +40,6 @@ obj-$(CONFIG_ARCNET) += arcnet/ obj-$(CONFIG_DEV_APPLETALK) += appletalk/ obj-$(CONFIG_CAIF) += caif/ obj-$(CONFIG_CAN) += can/ -obj-$(CONFIG_ETRAX_ETHERNET) += cris/ obj-$(CONFIG_NET_DSA) += dsa/ obj-$(CONFIG_ETHERNET) += ethernet/ obj-$(CONFIG_FDDI) += fddi/ diff --git a/drivers/net/cris/Makefile b/drivers/net/cris/Makefile deleted file mode 100644 index b4e8932227b6.. diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c deleted file mode 100644 index 8b1a859f5140.. -- 2.9.0
[PATCH 00/47] arch-removal: device drivers
Hi driver maintainers, I just posted one series with the removal of eight architectures, see https://lkml.org/lkml/2018/3/14/505 for details, or https://lwn.net/Articles/748074/ for more background. These are the device drivers that go along with them. I have already picked up the drivers for arch/metag/ into my tree, they were reviewed earlier. Please let me know if you have any concerns with the patch, or if you prefer to pick up the patches in your respective trees. I created the patches with 'git format-patch -D', so they will not apply without manually removing those files. For anything else, I'd keep the removal patches in my asm-generic tree and will send a pull request for 4.17 along with the actual arch removal. Arnd Arnd Bergmann edac: remove tile driver net: tile: remove ethernet drivers net: adi: remove blackfin ethernet drivers net: 8390: remove m32r specific bits net: remove cris etrax ethernet driver net: smsc: remove m32r specific smc91x configuration raid: remove tile specific raid6 implementation rtc: remove tile driver rtc: remove bfin driver char: remove obsolete ds1302 rtc driver char: remove tile-srom.c char: remove blackfin OTP driver pcmcia: remove m32r drivers pcmcia: remove blackfin driver ASoC: remove blackfin drivers video/logo: remove obsolete logo files fbdev: remove blackfin drivers fbdev: s1d13xxxfb: remove m32r specific hacks crypto: remove blackfin CRC driver media: platform: remove blackfin capture driver media: platform: remove m32r specific arv driver cpufreq: remove blackfin driver cpufreq: remove cris specific drivers gpio: remove etraxfs driver pinctrl: remove adi2/blackfin drivers ata: remove bf54x driver input: keyboard: remove bf54x driver input: misc: remove blackfin rotary driver mmc: remove bfin_sdh driver can: remove bfin_can driver watchdog: remove bfin_wdt driver mtd: maps: remove bfin-async-flash driver mtd: nand: remove bf5xx_nand driver spi: remove blackfin related host drivers i2c: remove bfin-twi driver pwm: remobe pwm-bfin driver usb: host: remove tilegx platform glue usb: musb: remove blackfin port usb: isp1362: remove blackfin arch glue serial: remove cris/etrax uart drivers serial: remove blackfin drivers serial: remove m32r_sio driver serial: remove tile uart driver tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers tty: hvc: remove tile driver staging: irda: remove bfin_sir driver staging: iio: remove iio-trig-bfin-timer driver .../devicetree/bindings/gpio/gpio-etraxfs.txt | 22 - .../bindings/serial/axis,etraxfs-uart.txt | 22 - Documentation/watchdog/watchdog-parameters.txt |5 - MAINTAINERS|8 - drivers/ata/Kconfig|9 - drivers/ata/Makefile |1 - drivers/ata/pata_bf54x.c | 1703 drivers/char/Kconfig | 48 - drivers/char/Makefile |3 - drivers/char/bfin-otp.c| 237 -- drivers/char/ds1302.c | 357 -- drivers/char/tile-srom.c | 475 --- drivers/cpufreq/Makefile |3 - drivers/cpufreq/blackfin-cpufreq.c | 217 - drivers/cpufreq/cris-artpec3-cpufreq.c | 93 - drivers/cpufreq/cris-etraxfs-cpufreq.c | 92 - drivers/crypto/Kconfig |7 - drivers/crypto/Makefile|1 - drivers/crypto/bfin_crc.c | 753 drivers/crypto/bfin_crc.h | 124 - drivers/edac/Kconfig |8 - drivers/edac/Makefile |2 - drivers/edac/tile_edac.c | 265 -- drivers/gpio/Kconfig |9 - drivers/gpio/Makefile |1 - drivers/gpio/gpio-etraxfs.c| 475 --- drivers/i2c/busses/Kconfig | 18 - drivers/i2c/busses/Makefile|1 - drivers/i2c/busses/i2c-bfin-twi.c | 737 drivers/input/keyboard/Kconfig |9 - drivers/input/keyboard/Makefile|1 - drivers/input/keyboard/bf54x-keys.c| 396 -- drivers/input/misc/Kconfig |9 - drivers/input/misc/Makefile|1 - drivers/input/misc/bfin_rotary.c | 294 -- drivers/media/platform/Kconfig | 22 - drivers/media/platform/Makefile|4 - drivers/media/platform/arv.c | 884 drivers/media/platform/blackfin/Kconfig| 16 - drivers/media/platform/blackfin/Makefile |
[PATCH 06/47] net: smsc: remove m32r specific smc91x configuration
The m32r architecture is getting removed, so this part can be cleaned up as well. Signed-off-by: Arnd Bergmann --- drivers/net/ethernet/smsc/Kconfig | 4 ++-- drivers/net/ethernet/smsc/smc91x.h | 26 -- 2 files changed, 2 insertions(+), 28 deletions(-) diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig index 4c2f612e4414..1c2b6663f7ce 100644 --- a/drivers/net/ethernet/smsc/Kconfig +++ b/drivers/net/ethernet/smsc/Kconfig @@ -37,8 +37,8 @@ config SMC91X select CRC32 select MII depends on !OF || GPIOLIB - depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \ - M32R || MIPS || MN10300 || NIOS2 || SUPERH || XTENSA || H8300 + depends on ARM || ARM64 || ATARI_ETHERNAT || COLDFIRE || \ + MIPS || NIOS2 || SUPERH || XTENSA || H8300 ---help--- This is a driver for SMC's 91x series of Ethernet chipsets, including the SMC91C94 and the SMC91C111. Say Y if you want it diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h index 08b17adf0a65..b337ee97e0c0 100644 --- a/drivers/net/ethernet/smsc/smc91x.h +++ b/drivers/net/ethernet/smsc/smc91x.h @@ -144,32 +144,6 @@ static inline void _SMC_outw_align4(u16 val, void __iomem *ioaddr, int reg, #define SMC_IRQ_FLAGS (0) -#elif defined(CONFIG_M32R) - -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 - -#define SMC_inb(a, r) inb(((u32)a) + (r)) -#define SMC_inw(a, r) inw(((u32)a) + (r)) -#define SMC_outb(v, a, r) outb(v, ((u32)a) + (r)) -#define SMC_outw(lp, v, a, r) outw(v, ((u32)a) + (r)) -#define SMC_insw(a, r, p, l) insw(((u32)a) + (r), p, l) -#define SMC_outsw(a, r, p, l) outsw(((u32)a) + (r), p, l) - -#define SMC_IRQ_FLAGS (0) - -#define RPC_LSA_DEFAULTRPC_LED_TX_RX -#define RPC_LSB_DEFAULTRPC_LED_100_10 - -#elif defined(CONFIG_MN10300) - -/* - * MN10300/AM33 configuration - */ - -#include - #elif defined(CONFIG_ATARI) #define SMC_CAN_USE_8BIT1 -- 2.9.0
[PATCH net-next] ibmvnic: Fix reset return from closed state
The case in which we handle a reset from the state where the device is
closed seems to be bugged for all types of reset. For most types of reset
we currently exit the reset routine correctly, but don't set the state to
indicate that we are back in the "closed" state. For some specific cases,
we don't exit the reset routine at all and resetting will cause a closed
device to be opened.
This patch fixes the problem by unconditionally checking the reset_state
and correctly setting the adapter state before returning.
Signed-off-by: John Allen
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index 7be4b06..b103a7e 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1714,12 +1714,14 @@ static int do_reset(struct ibmvnic_adapter *adapter,
rc = reset_rx_pools(adapter);
if (rc)
return rc;
-
- if (reset_state == VNIC_CLOSED)
- return 0;
}
}
+ adapter->state = VNIC_CLOSED;
+
+ if (reset_state == VNIC_CLOSED)
+ return 0;
+
rc = __ibmvnic_open(netdev);
if (rc) {
if (list_empty(&adapter->rwi_list))
