* Re: [PATCH v1] net: cdc_ncm: update datagram size after changing mtu
From: Bjørn Mork @ 2016-04-06 14:36 UTC (permalink / raw)
To: Robert Dobrowolski
Cc: linux-usb, rafal.f.redzimski, stable, oliver, netdev,
linux-kernel
In-Reply-To: <1459942869-13587-1-git-send-email-robert.dobrowolski@linux.intel.com>
Robert Dobrowolski <robert.dobrowolski@linux.intel.com> writes:
> From: Rafal Redzimski <rafal.f.redzimski@intel.com>
>
> Current implementation updates the mtu size and notify cdc_ncm
> device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
> size change instead of changing rx_urb_size.
>
> Whenever mtu is being changed, datagram size should also be
> updated.
Definitely! Thanks for this. But looking at the code I believe you
need to fix the calculation of maxmtu too. It is currently:
int maxmtu = ctx->max_datagram_size - cdc_ncm_eth_hlen(dev);
And cdc_ncm_set_dgram_size() updates ctx->max_datagram_size with the new
mtu, meaning that you can only reduce the mtu. We should probably use
cdc_ncm_max_dgram_size() instead here.
And cdc_ncm_set_dgram_size() takes the datagram size with header as
input (ref the above maxmtu calucalution), so it probably needs to
called as
cdc_ncm_set_dgram_size(dev, new_mtu + cdc_ncm_eth_hlen(dev));
to get it right. I think. None of this is tested on an actual device
yet... Care to test if I'm right, and do a v2 if necessry?
> Cc: <stable@vger.kernel.org>
This should be dropped for net. Ask David to queue it for stable
instead. I usually do that by using a subject prefix like
[PATCH net,stable v1] ...
Bjørn
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void
From: Vivien Didelot @ 2016-04-06 14:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Jiri Pirko, Scott Feldman
In-Reply-To: <20160406125421.GF19409@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
>> >> mutex_lock(&ps->smi_mutex);
>> >> - ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state);
>> >> + if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state))
>> >> + netdev_warn(ds->ports[port], "cannot load address\n");
>> >
>> > In the SF2 driver you use pr_err, but here netdev_warn. We probably
>> > should be consistent if we error or warn. I would use netdev_error,
>> > since if this fails we probably have a real hardware problem.
>>
>> I used pr_err in the SF2 driver to be consistent with the rest of the
>> code which only uses pr_err and pr_info.
>
> O.K, good.
>
>> I was thinking about adding ds_err and ds_port_err to print errors for
>> ds->master_dev and ds->ports[port], but that might be overkill.
>
> I'm also trying to kill off the use of ds within the mv88e6xxx driver.
>
>> What do you think? Or local to the driver for the moment, like
>> mvsw_err maybe?
>
> I would keep it local. Also, for this sort of error, it does not need
> to differentiate on port. It is a hardware access error, something is
> wrong with the mdio bus/switch. So i would even put the message in the
> very low level reg_read/reg_write functions, and no where else.
OK, so I will keep a netdev_err() in _mv88e6xxx_port_fdb_add since I
don't like to ignore return values, and will send a future separate
patch to add such message in low level functions as you suggested, and
maybe voidify a few high level functions using them.
Thanks,
Vivien
^ permalink raw reply
* Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Edward Cree @ 2016-04-06 14:26 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Herbert Xu, Alexander Duyck, Alex Duyck,
Jesse Gross, Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <CALx6S34Sqp7tnmkPRWH0RF_CKrBLLNWFjHbr6Uq2r=6=scMMow@mail.gmail.com>
On 06/04/16 14:53, Tom Herbert wrote:
> But again, this scheme is optimizing for forwarding case and doesn't
> help (and probably hurts) the use case of locally terminated
> connections
Not really. I think this has a chance to outperform GRO for locally
terminated connections, for a number of reasons:
* Doesn't look at higher-layer or inner headers until later in packet
processing, for instance we (maybe) process every L3 header in a NAPI poll
before looking at a single L4. This could delay touching the second
cacheline of some packets.
* Doesn't have to re-write headers to produce a coherent superframe.
Instead, each segment carries its original headers around with it. Also
means we can skip _checking_ some headers to see if we're 'allowed' to
coalesce (e.g. TCP TS differences, and the current fun with IP IDs).
* Can be used for protocols like UDP where the original packet boundaries
are important (so you can't coalesce into a superframe).
Really the last of those was the original reason for this idea, helping with
forwarding is just another nice bonus that we (might) get from it.
And it's all speculative and I don't know for sure what the performance
would be like, but I won't know until I try it!
> which I would claim is more important.
No argument there :-)
> Packets that are
> forwarded really should not be GRO'ed in the first place because of
> the loss of information and added latency. The difficultly is that we
> don't currently make the forwarding decision before GRO, if we can
> change this to decide whether packets are to be forwarded earlier then
> we can avoid doing GRO for those.
That certainly would be nice, XDP is exciting and I look forward to it.
-Ed
^ permalink raw reply
* Re: [PATCH] Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"
From: Bart Van Assche @ 2016-04-06 14:13 UTC (permalink / raw)
To: Bjorn Helgaas, David S. Miller
Cc: Neil Horman, Nikolay Aleksandrov, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Alexander Duyck
In-Reply-To: <20160405205822.24724.95522.stgit@bhelgaas-glaptop2.roam.corp.google.com>
On 04/05/16 13:58, Bjorn Helgaas wrote:
> This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7.
>
> Direct callers of __netpoll_setup() depend on it to set np->dev,
> so we can't simply move that assignment up to netpoll_stup().
>
> Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
Thanks!
Bart.
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paul Moore @ 2016-04-06 14:07 UTC (permalink / raw)
To: Paolo Abeni
Cc: linux-security-module, David S. Miller, James Morris,
Andreas Gruenbacher, Stephen Smalley, Florian Westphal, netdev,
selinux
In-Reply-To: <1459951424.5425.12.camel@redhat.com>
On Wed, Apr 6, 2016 at 10:03 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> On Wed, 2016-04-06 at 08:33 -0400, Paul Moore wrote:
>> On Wed, Apr 6, 2016 at 5:51 AM, Paolo Abeni <pabeni@redhat.com> wrote:
>> > Currently, selinux always registers iptables POSTROUTING hooks regarless of
>> > the running policy needs for any action to be performed by them.
>> >
>> > Even the socket_sock_rcv_skb() is always registered, but it can result in a no-op
>> > depending on the current policy configuration.
>> >
>> > The above invocations in the kernel datapath are cause of measurable
>> > overhead in networking performance test.
>> >
>> > This patch series adds explicit notification for netlabel status change
>> > (other relevant status change, like xfrm and secmark, are already notified to
>> > LSM) and use this information in selinux to register the above hooks only when
>> > the current status makes them relevant, deregistering them when no-op
>> >
>> > Avoiding the LSM hooks overhead, in netperf UDP_STREAM test with small packets,
>> > gives about 5% performance improvement on rx and about 8% on tx.
>>
>> [NOTE: added the SELinux mailing list to the CC line, please include
>> when submitting SELinux patches]
>>
>> While I appreciate the patch and the work that went into development
>> and testing, I'm going to reject this patch on the grounds that it
>> conflicts with work we've just started thinking about which should
>> bring some tangible security benefit.
>>
>> The recent addition of post-init read only memory opens up some
>> interesting possibilities for SELinux and LSMs in general, the thing
>> which we've just started looking at is marking the LSM hook structure
>> read only after init. There are some complicating factors for
>> SELinux, but I'm confident those can be resolved, and from what I can
>> tell marking the hooks read only will have no effect on other LSMs.
>> While marking the LSM hook structure doesn't directly affect the
>> SELinux netfilter hooks, once we remove the ability to deregister the
>> LSM hooks we will have no need to support deregistering netfilter
>> hooks and I expect we will drop that functionality as well to help
>> decrease the risk of tampering.
>
> What if we drops the selinux hook related changes in the second patch
> (the on-demand socket_sock_rcv_skb() [de-]registration)?
>
> The patch will not conflict with the LSM hook structure becoming
> read-only, we still retain the ability of registering/de-registering the
> netfilter hooks, and that will still affect positively the tx network
> performance.
As I already said above:
"While marking the LSM hook structure doesn't directly affect the
SELinux netfilter hooks, once we remove the ability to deregister the
LSM hooks we will have no need to support deregistering netfilter
hooks and I expect we will drop that functionality as well to help
decrease the risk of tampering."
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paolo Abeni @ 2016-04-06 14:03 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, David S. Miller, James Morris,
Andreas Gruenbacher, Stephen Smalley, Florian Westphal, netdev,
selinux
In-Reply-To: <CAHC9VhS6aJdPR6xTH2-ehikS5qvj6jFbZAUtzoBXp+WC9Ugi=Q@mail.gmail.com>
On Wed, 2016-04-06 at 08:33 -0400, Paul Moore wrote:
> On Wed, Apr 6, 2016 at 5:51 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> > Currently, selinux always registers iptables POSTROUTING hooks regarless of
> > the running policy needs for any action to be performed by them.
> >
> > Even the socket_sock_rcv_skb() is always registered, but it can result in a no-op
> > depending on the current policy configuration.
> >
> > The above invocations in the kernel datapath are cause of measurable
> > overhead in networking performance test.
> >
> > This patch series adds explicit notification for netlabel status change
> > (other relevant status change, like xfrm and secmark, are already notified to
> > LSM) and use this information in selinux to register the above hooks only when
> > the current status makes them relevant, deregistering them when no-op
> >
> > Avoiding the LSM hooks overhead, in netperf UDP_STREAM test with small packets,
> > gives about 5% performance improvement on rx and about 8% on tx.
>
> [NOTE: added the SELinux mailing list to the CC line, please include
> when submitting SELinux patches]
>
> While I appreciate the patch and the work that went into development
> and testing, I'm going to reject this patch on the grounds that it
> conflicts with work we've just started thinking about which should
> bring some tangible security benefit.
>
> The recent addition of post-init read only memory opens up some
> interesting possibilities for SELinux and LSMs in general, the thing
> which we've just started looking at is marking the LSM hook structure
> read only after init. There are some complicating factors for
> SELinux, but I'm confident those can be resolved, and from what I can
> tell marking the hooks read only will have no effect on other LSMs.
> While marking the LSM hook structure doesn't directly affect the
> SELinux netfilter hooks, once we remove the ability to deregister the
> LSM hooks we will have no need to support deregistering netfilter
> hooks and I expect we will drop that functionality as well to help
> decrease the risk of tampering.
What if we drops the selinux hook related changes in the second patch
(the on-demand socket_sock_rcv_skb() [de-]registration)?
The patch will not conflict with the LSM hook structure becoming
read-only, we still retain the ability of registering/de-registering the
netfilter hooks, and that will still affect positively the tx network
performance.
Regards,
Paolo
^ permalink raw reply
* Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Tom Herbert @ 2016-04-06 13:53 UTC (permalink / raw)
To: Edward Cree
Cc: David Miller, Herbert Xu, Alexander Duyck, Alex Duyck,
Jesse Gross, Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <5704F156.8030804@solarflare.com>
On Wed, Apr 6, 2016 at 8:21 AM, Edward Cree <ecree@solarflare.com> wrote:
> On 06/04/16 00:45, David Miller wrote:
>> From: Edward Cree <ecree@solarflare.com>
>> Date: Tue, 5 Apr 2016 16:07:49 +0100
>>
>>> On the gripping hand, I feel like GRO+TSO is the wrong model for
>>> speeding up forwarding/routing workloads. Instead we should be
>>> looking into having lists of SKBs traverse the stack together,
>>> splitting the list whenever e.g. the destination changes.
>> "Destination" is a very complicated beast. It's not just a
>> destination IP address.
>>
>> It's not even just a full saddr/daddr/TOS triplet.
>>
>> Packets can be forwarded around based upon any key whatsoever in the
>> headers. Netfilter can mangle them based upon arbitrary bits in the
>> packet, as can the packet scheduler classifier actions.
>>
>> It's therefore not profitable to try this at all, it's completely
>> pointless unless all the keys match up exactly.
> Possibly I wasn't completely clear (or maybe I was and I'm just
> wrong...), but I meant that _each layer_ in the stack would split the
> list whenever it wants to treat two packets differently. Whether
> that's a protocol receive handler, or a netfilter or tc operation.
>
> Obviously if you want to decide at the _beginning_ whether "all the
> keys match", then you do essentially need GRO's flow-matching logic.
> But even then, I find myself wondering if having GRO coalesce the
> segments into a superpacket is really better than having it just make
> lists of segments, and have that list traverse the stack as a single
> entity. That way lossless resegmentation remains easy. But I suppose
> that could make life difficult for things like BPF, if they want to
> act upon the superframe (because we haven't built it). If instead
> they act on each of the segments, we might get different actions for
> each segment and that might also be awkward; so you'd still need this
> concept of 'any layer in the stack can decide to split lists up'.
>
But again, this scheme is optimizing for forwarding case and doesn't
help (and probably hurts) the use case of locally terminated
connections which I would claim is more important. Packets that are
forwarded really should not be GRO'ed in the first place because of
the loss of information and added latency. The difficultly is that we
don't currently make the forwarding decision before GRO, if we can
change this to decide whether packets are to be forwarded earlier then
we can avoid doing GRO for those.
Tom
> -Ed
^ permalink raw reply
* Re: [PATCH] Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"
From: Neil Horman @ 2016-04-06 13:48 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: David S. Miller, Nikolay Aleksandrov, netdev, linux-kernel,
Alexander Duyck, Bart Van Assche
In-Reply-To: <20160405205822.24724.95522.stgit@bhelgaas-glaptop2.roam.corp.google.com>
On Tue, Apr 05, 2016 at 03:58:22PM -0500, Bjorn Helgaas wrote:
> This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7.
>
> Direct callers of __netpoll_setup() depend on it to set np->dev,
> so we can't simply move that assignment up to netpoll_stup().
>
> Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> net/core/netpoll.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index a57bd17..94acfc8 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -603,6 +603,7 @@ int __netpoll_setup(struct netpoll *np, struct net_device *ndev)
> const struct net_device_ops *ops;
> int err;
>
> + np->dev = ndev;
> strlcpy(np->dev_name, ndev->name, IFNAMSIZ);
> INIT_WORK(&np->cleanup_work, netpoll_async_cleanup);
>
> @@ -669,7 +670,6 @@ int netpoll_setup(struct netpoll *np)
> goto unlock;
> }
> dev_hold(ndev);
> - np->dev = ndev;
>
> if (netdev_master_upper_dev_get(ndev)) {
> np_err(np, "%s is a slave device, aborting\n", np->dev_name);
> @@ -770,7 +770,6 @@ int netpoll_setup(struct netpoll *np)
> return 0;
>
> put:
> - np->dev = NULL;
> dev_put(ndev);
> unlock:
> rtnl_unlock();
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-04-06
From: Johannes Berg @ 2016-04-06 13:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <1459949159-22399-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2016-04-06 at 15:25 +0200, Johannes Berg wrote:
> Hi Dave,
>
> For the 4.6 cycle, there's of course much more. The few things that
>
Err, -next, so that's 4.7.
johannes
^ permalink raw reply
* pull-request: mac80211-next 2016-04-06
From: Johannes Berg @ 2016-04-06 13:25 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
For the 4.6 cycle, there's of course much more. The few things that
stand out are in the tag message below.
There's a pending patchset to add NAN (Neighbor Awareness Networking,
a WFA protocol) API support, but the API isn't ready yet. I might
have that later in time for 4.6.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-04-01 20:03:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-04-06
for you to fetch changes up to 4ce2bd9c4c1dfb416206ff1ad5283f6d24af4031:
cfg80211: Allow reassociation to be requested with internal SME (2016-04-06 15:09:28 +0200)
----------------------------------------------------------------
For the 4.6 cycle, we have a number of changes:
* Bob's mesh mode rhashtable conversion, this includes
the rhashtable API change for allocation flags
* BSSID scan, connect() command reassoc support (Jouni)
* fast (optimised data only) and support for RSS in mac80211 (myself)
* various smaller changes
----------------------------------------------------------------
Akira Moroo (1):
cfg80211: fix kernel-doc struct name
Arend van Spriel (1):
nl80211: add feature for BSS selection support
Avraham Stern (1):
ieee80211: support parsing Fine Timing Measurement action frame
Ayala Beker (2):
cfg80211: allow userspace to specify client P2P PS support
mac80211: track and tell driver about GO client P2P PS abilities
Bob Copeland (14):
mac80211: mesh: move path tables into if_mesh
mac80211: mesh: don't hash sdata in mpath tables
mac80211: mesh: factor out common mesh path allocation code
mac80211: mesh: embed known gates list in struct mesh_path
rhashtable: accept GFP flags in rhashtable_walk_init
mac80211: mesh: convert path table to rhashtable
mac80211: mesh: fix crash in mesh_path_timer
mac80211: mesh: handle failed alloc for rmc cache
mac80211: mesh: use hlist for rmc cache
mac80211: mesh: embed gates hlist head directly
mac80211: mesh: reorder structure members
mac80211: mesh: fix mesh path kerneldoc
mac80211: mesh: fix cleanup for mesh pathtable
mac80211: mesh: flush paths outside of plink lock
Emmanuel Grumbach (1):
mac80211: Set global RRM capability
Felix Fietkau (4):
mac80211: do not pass injected frames without a valid rate to the driver
mac80211: minstrel_ht: improve sample rate skip logic
mac80211: add A-MSDU tx support
mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
Johannes Berg (17):
wext: unregister_pernet_subsys() on notifier registration failure
mac80211: allow drivers to report CLOCK_BOOTTIME for scan results
mac80211: remove sta_info debugfs sub-struct
mac80211: don't start dynamic PS timer if not needed
mac80211: clean up station flags debugfs
mac80211: fix cipher scheme function name
mac80211: avoid useless memory write on each frame RX
mac80211: allow passing transmitter station on RX
mac80211: count MSDUs in A-MSDU properly
mac80211: move semicolon out of CALL_RXH macro
mac80211: move averaged values out of rx_stats
mac80211: remove rx_stats.last_rx update after sta alloc
mac80211: add separate last_ack variable
mac80211: fix last RX rate data consistency
mac80211: fix RX u64 stats consistency on 32-bit platforms
mac80211: add fast-rx path
mac80211: enable collecting station statistics per-CPU
Jouni Malinen (5):
cfg80211: Allow a scan request for a specific BSSID
mac80211: Support a scan request for a specific BSSID
mac80211_hwsim: Support a hw scan request for a specific BSSID
cfg80211: Add option to specify previous BSSID for Connect command
cfg80211: Allow reassociation to be requested with internal SME
João Paulo Rechi Vita (1):
rfkill: Use switch to demux userspace operations
Lorenzo Bianconi (1):
mac80211: parse VHT info in injected frames
Mohammed Shafi Shajakhan (1):
mac80211: Remove unused variable in per STA debugfs struct
Sara Sharon (4):
mac80211: allow not sending MIC up from driver for HW crypto
mac80211: synchronize driver rx queues before removing a station
mac80211: add NETIF_F_RXCSUM to features white list
mac80211: enable starting BA session with custom timeout
Sven Eckelmann (2):
mac80211: document only injected *_RADIOTAP_* flags
mac80211: fix parsing of 40Mhz in injected radiotap header
Documentation/networking/mac80211-injection.txt | 17 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
drivers/net/wireless/ath/wcn36xx/txrx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 5 +
fs/gfs2/glock.c | 4 +-
include/linux/ieee80211.h | 24 +
include/linux/rhashtable.h | 3 +-
include/net/cfg80211.h | 42 +-
include/net/mac80211.h | 51 +-
include/uapi/linux/nl80211.h | 75 +-
lib/rhashtable.c | 6 +-
lib/test_rhashtable.c | 2 +-
net/ipv6/ila/ila_xlat.c | 3 +-
net/mac80211/agg-tx.c | 5 +
net/mac80211/cfg.c | 18 +-
net/mac80211/debugfs.c | 3 +
net/mac80211/debugfs_sta.c | 134 +--
net/mac80211/driver-ops.h | 15 +
net/mac80211/ibss.c | 17 +-
net/mac80211/ieee80211_i.h | 11 +
net/mac80211/iface.c | 2 +-
net/mac80211/key.c | 1 +
net/mac80211/main.c | 4 +-
net/mac80211/mesh.c | 38 +-
net/mac80211/mesh.h | 71 +-
net/mac80211/mesh_hwmp.c | 4 +
net/mac80211/mesh_pathtbl.c | 965 ++++++++--------------
net/mac80211/mesh_plink.c | 13 +-
net/mac80211/mlme.c | 16 +-
net/mac80211/ocb.c | 2 -
net/mac80211/rate.h | 4 +-
net/mac80211/rc80211_minstrel_ht.c | 77 +-
net/mac80211/rx.c | 479 +++++++++--
net/mac80211/scan.c | 8 +-
net/mac80211/sta_info.c | 289 +++++--
net/mac80211/sta_info.h | 130 ++-
net/mac80211/status.c | 4 +-
net/mac80211/trace.h | 12 +
net/mac80211/tx.c | 197 ++++-
net/mac80211/util.c | 5 +-
net/mac80211/wpa.c | 26 +-
net/netfilter/nft_hash.c | 4 +-
net/netlink/af_netlink.c | 3 +-
net/rfkill/core.c | 36 +-
net/sctp/proc.c | 3 +-
net/wireless/core.c | 7 +
net/wireless/nl80211.c | 158 +++-
net/wireless/scan.c | 2 +
net/wireless/sme.c | 16 +-
net/wireless/trace.h | 6 +-
net/wireless/wext-core.c | 5 +-
55 files changed, 2029 insertions(+), 1005 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull-request: mac80211 2016-04-06
From: Johannes Berg @ 2016-04-06 13:19 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
First set of fixes for 4.6. Nothing really stands out.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-04-01 20:03:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-04-06
for you to fetch changes up to b4201cc4fc6e1c57d6d306b1f787865043d60129:
mac80211: fix "warning: ‘target_metric’ may be used uninitialized" (2016-04-06 15:10:25 +0200)
----------------------------------------------------------------
For the current RC series, we have the following fixes:
* TDLS fixes from Arik and Ilan
* rhashtable fixes from Ben and myself
* documentation fixes from Luis
* U-APSD fixes from Emmanuel
* a TXQ fix from Felix
* and a compiler warning suppression from Jeff
----------------------------------------------------------------
Arik Nemtsov (3):
mac80211: TDLS: always downgrade invalid chandefs
mac80211: TDLS: change BW calculation for WIDER_BW peers
mac80211: recalc min_def chanctx even when chandef is identical
Ben Greear (1):
mac80211: ensure no limits on station rhashtable
Emmanuel Grumbach (2):
mac80211: don't send deferred frames outside the SP
mac80211: close the SP when we enqueue frames during the SP
Felix Fietkau (1):
mac80211: fix AP buffered multicast frames with queue control and txq
Ilan Peer (1):
mac80211: Fix BW upgrade for TDLS peers
Jeff Mahoney (1):
mac80211: fix "warning: ‘target_metric’ may be used uninitialized"
Johannes Berg (1):
mac80211: properly deal with station hashtable insert errors
Luis de Bethencourt (2):
mac80211: add doc for RX_FLAG_DUP_VALIDATED flag
mac80211: remove description of dropped member
include/net/mac80211.h | 2 ++
net/mac80211/chan.c | 4 +++-
net/mac80211/ieee80211_i.h | 4 ++++
net/mac80211/mesh_hwmp.c | 2 +-
net/mac80211/sta_info.c | 14 +++++++++-----
net/mac80211/sta_info.h | 1 -
net/mac80211/tdls.c | 43 +++++++++++++++++++++++++++++++++++--------
net/mac80211/tx.c | 13 +++++++++----
net/mac80211/vht.c | 30 +++++++++++++++++++++++++-----
9 files changed, 88 insertions(+), 25 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] net: sched: do not requeue a NULL skb
From: Lars Persson @ 2016-04-06 13:10 UTC (permalink / raw)
To: netdev; +Cc: jhs, linux-kernel, Lars Persson
A failure in validate_xmit_skb_list() triggered an unconditional call
to dev_requeue_skb with skb=NULL. This slowly grows the queue
discipline's qlen count until all traffic through the queue stops.
Fixes: 55a93b3ea780 ("qdisc: validate skb without holding lock")
Signed-off-by: Lars Persson <larper@axis.com>
---
net/sched/sch_generic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index f18c350..1031536 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -165,6 +165,9 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
skb = dev_hard_start_xmit(skb, dev, txq, &ret);
HARD_TX_UNLOCK(dev, txq);
+ } else {
+ spin_lock(root_lock);
+ return qdisc_qlen(q);
}
spin_lock(root_lock);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void
From: Andrew Lunn @ 2016-04-06 12:54 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Jiri Pirko, Scott Feldman
In-Reply-To: <87egajxwb5.fsf@ketchup.mtl.sfl>
On Tue, Apr 05, 2016 at 11:14:54PM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> >> mutex_lock(&ps->smi_mutex);
> >> - ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state);
> >> + if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state))
> >> + netdev_warn(ds->ports[port], "cannot load address\n");
> >
> > In the SF2 driver you use pr_err, but here netdev_warn. We probably
> > should be consistent if we error or warn. I would use netdev_error,
> > since if this fails we probably have a real hardware problem.
>
> I used pr_err in the SF2 driver to be consistent with the rest of the
> code which only uses pr_err and pr_info.
O.K, good.
> I was thinking about adding ds_err and ds_port_err to print errors for
> ds->master_dev and ds->ports[port], but that might be overkill.
I'm also trying to kill off the use of ds within the mv88e6xxx driver.
> What do you think? Or local to the driver for the moment, like
> mvsw_err maybe?
I would keep it local. Also, for this sort of error, it does not need
to differentiate on port. It is a hardware access error, something is
wrong with the mdio bus/switch. So i would even put the message in the
very low level reg_read/reg_write functions, and no where else.
Andrew
^ permalink raw reply
* [PATCH] neigh: remove duplicated log msg
From: Abdelmajid Mlayeh @ 2016-04-06 12:42 UTC (permalink / raw)
To: linux-kernel
Cc: Abdelmajid MLAYEH, David S. Miller, David Ahern, Eric Dumazet,
Martin Zhang, Konstantin Khlebnikov, Julian Anastasov, Rick Jones,
netdev
From: Abdelmajid MLAYEH <abdelmajidx.mlayeh@intel.com>
This will be printed anyways by neigh_suspect
Signed-off-by: Abdelmajid Mlayeh <abdelmajidx.mlayeh@intel.com>
---
net/core/neighbour.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index f18ae91..bf20118 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -896,7 +896,6 @@ static void neigh_timer_handler(unsigned long arg)
neigh_suspect(neigh);
next = now + NEIGH_VAR(neigh->parms, DELAY_PROBE_TIME);
} else {
- neigh_dbg(2, "neigh %p is suspected\n", neigh);
neigh->nud_state = NUD_STALE;
neigh->updated = jiffies;
neigh_suspect(neigh);
--
1.9.1
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paul Moore @ 2016-04-06 12:33 UTC (permalink / raw)
To: Paolo Abeni
Cc: linux-security-module, David S. Miller, James Morris,
Andreas Gruenbacher, Stephen Smalley, Florian Westphal, netdev,
selinux
In-Reply-To: <cover.1459934322.git.pabeni@redhat.com>
On Wed, Apr 6, 2016 at 5:51 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> Currently, selinux always registers iptables POSTROUTING hooks regarless of
> the running policy needs for any action to be performed by them.
>
> Even the socket_sock_rcv_skb() is always registered, but it can result in a no-op
> depending on the current policy configuration.
>
> The above invocations in the kernel datapath are cause of measurable
> overhead in networking performance test.
>
> This patch series adds explicit notification for netlabel status change
> (other relevant status change, like xfrm and secmark, are already notified to
> LSM) and use this information in selinux to register the above hooks only when
> the current status makes them relevant, deregistering them when no-op
>
> Avoiding the LSM hooks overhead, in netperf UDP_STREAM test with small packets,
> gives about 5% performance improvement on rx and about 8% on tx.
[NOTE: added the SELinux mailing list to the CC line, please include
when submitting SELinux patches]
While I appreciate the patch and the work that went into development
and testing, I'm going to reject this patch on the grounds that it
conflicts with work we've just started thinking about which should
bring some tangible security benefit.
The recent addition of post-init read only memory opens up some
interesting possibilities for SELinux and LSMs in general, the thing
which we've just started looking at is marking the LSM hook structure
read only after init. There are some complicating factors for
SELinux, but I'm confident those can be resolved, and from what I can
tell marking the hooks read only will have no effect on other LSMs.
While marking the LSM hook structure doesn't directly affect the
SELinux netfilter hooks, once we remove the ability to deregister the
LSM hooks we will have no need to support deregistering netfilter
hooks and I expect we will drop that functionality as well to help
decrease the risk of tampering.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Machani, Yaniv @ 2016-04-06 12:30 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, Balbi, Felipe, Chalmers, Kevin, Shahar Levi,
Kalle Valo, Davis, Andrew, Mishol, Guy, Arik Nemtsov, Gery Kahn,
Felipe Balbi, Luciano Coelho, David Woodhouse, Pavel Machek,
Aaro Koskinen, Ben Hutchings, David Gnedt, Ivaylo Dimitrov,
Sebastian Reichel, Tony Lindgren, Menon, Nishanth,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <201604061412.43684@pali>
On Wed, Apr 06, 2016 at 15:12:43, Pali Rohár wrote:
> > > > For other TI wilink chips there are <CHIP>-ap.bin firmware files
> > > > (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode.
> > > > But for
> > > > wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is
> > > > missing.
> > > >
> > > > Do you have any idea what happened with AP firmware for ti
> > > > wilink4 wl1251 wifi chip? Or where can be found? Guys from TI,
> > > > can you help?
> > > >
> > > > I see that STA firmware was added into linux-firmware tree in
> > > > year
> > > > 2013 by this pull request [2].
> > > >
> > > > [1] -
> > > > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firm
> > > > w
> > > > are .g
> > > > it/tree/ti-connectivity
> > > >
> > > > [2] -
> > > > http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
> > >
> > > Hi! Anybody has some idea about that AP firmware?
> >
> > Hi,
> > wl1251 does not support AP mode, so there is no firmware for it in
> > the tree.
> >
> > Regards,
> > Yaniv
>
> Hi Yaniv! I read on some TI whitepaper, that wl1251 hardware supports
> some Soft-AP mode. So I expect that either special FW is needed for it
> or somehow it is possible to use current released. Do you have any information about it?
>
> --
> Pali Rohár
> pali.rohar@gmail.com
Hi Pali,
This must be some typo, the device does not support Soft-AP.
More than that, wl1251 family is not officially supported via the mainline Linux.
For Soft-AP, and other new features based on Linux you should use WiLink8 chip family.
Regards,
Yaniv
^ permalink raw reply
* Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Pali Rohár @ 2016-04-06 12:12 UTC (permalink / raw)
To: Machani, Yaniv
Cc: Luciano Coelho, Balbi, Felipe, Chalmers, Kevin, Shahar Levi,
Kalle Valo, Davis, Andrew, Mishol, Guy, Arik Nemtsov, Gery Kahn,
Felipe Balbi, Luciano Coelho, David Woodhouse, Pavel Machek,
Aaro Koskinen, Ben Hutchings, David Gnedt, Ivaylo Dimitrov,
Sebastian Reichel, Tony Lindgren, Menon, Nishanth,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AE1C82FB3D0EC64DB1F752C81CBD1101390F6305@DFRE01.ent.ti.com>
[-- Attachment #1: Type: Text/Plain, Size: 1521 bytes --]
On Wednesday 06 April 2016 13:30:22 Machani, Yaniv wrote:
> On Mon, Apr 04, 2016 at 15:39:44, Pali Rohár wrote:
> > > In linux-firmware repository [1] is missing AP firmware for TI
> > > wl1251 chip. There is only STA firmware wl1251-fw.bin which
> > > supports managed and ad-hoc modes.
> > >
> > > For other TI wilink chips there are <CHIP>-ap.bin firmware files
> > > (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode.
> > > But for
> > > wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is
> > > missing.
> > >
> > > Do you have any idea what happened with AP firmware for ti
> > > wilink4 wl1251 wifi chip? Or where can be found? Guys from TI,
> > > can you help?
> > >
> > > I see that STA firmware was added into linux-firmware tree in
> > > year 2013 by this pull request [2].
> > >
> > > [1] -
> > > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmw
> > > are .g
> > > it/tree/ti-connectivity
> > >
> > > [2] -
> > > http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
> >
> > Hi! Anybody has some idea about that AP firmware?
>
> Hi,
> wl1251 does not support AP mode, so there is no firmware for it in
> the tree.
>
> Regards,
> Yaniv
Hi Yaniv! I read on some TI whitepaper, that wl1251 hardware supports
some Soft-AP mode. So I expect that either special FW is needed for it
or somehow it is possible to use current released. Do you have any
information about it?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v1] net: cdc_ncm: update datagram size after changing mtu
From: Robert Dobrowolski @ 2016-04-06 11:41 UTC (permalink / raw)
To: linux-usb
Cc: robert.dobrowolski, rafal.f.redzimski, stable, oliver, netdev,
linux-kernel
From: Rafal Redzimski <rafal.f.redzimski@intel.com>
Current implementation updates the mtu size and notify cdc_ncm
device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
size change instead of changing rx_urb_size.
Whenever mtu is being changed, datagram size should also be
updated.
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
---
drivers/net/usb/cdc_ncm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 2fb31ed..4a47656 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -746,6 +746,8 @@ int cdc_ncm_change_mtu(struct net_device *net, int new_mtu)
if (new_mtu <= 0 || new_mtu > maxmtu)
return -EINVAL;
net->mtu = new_mtu;
+ cdc_ncm_set_dgram_size(dev, new_mtu);
+
return 0;
}
EXPORT_SYMBOL_GPL(cdc_ncm_change_mtu);
--
1.9.1
^ permalink raw reply related
* RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Machani, Yaniv @ 2016-04-06 11:30 UTC (permalink / raw)
To: Pali Rohár, Luciano Coelho, Balbi, Felipe, Chalmers, Kevin,
Shahar Levi, Kalle Valo, Davis, Andrew, Mishol, Guy, Arik Nemtsov,
Gery Kahn, Felipe Balbi, Luciano Coelho
Cc: David Woodhouse, Pavel Machek, Aaro Koskinen, Ben Hutchings,
David Gnedt, Ivaylo Dimitrov, Sebastian Reichel, Tony Lindgren,
Menon, Nishanth, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20160404123944.GA8413@pali>
On Mon, Apr 04, 2016 at 15:39:44, Pali Rohár wrote:
> > In linux-firmware repository [1] is missing AP firmware for TI
> > wl1251 chip. There is only STA firmware wl1251-fw.bin which supports
> > managed and ad-hoc modes.
> >
> > For other TI wilink chips there are <CHIP>-ap.bin firmware files
> > (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode. But
> > for
> > wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is missing.
> >
> > Do you have any idea what happened with AP firmware for ti wilink4
> > wl1251 wifi chip? Or where can be found? Guys from TI, can you help?
> >
> > I see that STA firmware was added into linux-firmware tree in year
> > 2013 by this pull request [2].
> >
> > [1] -
> > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware
> > .g
> > it/tree/ti-connectivity
> >
> > [2] -
> > http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
> >
>
> Hi! Anybody has some idea about that AP firmware?
>
Hi,
wl1251 does not support AP mode, so there is no firmware for it in the tree.
Regards,
Yaniv
> --
> Pali Rohár
> pali.rohar@gmail.com
^ permalink raw reply
* Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Edward Cree @ 2016-04-06 11:21 UTC (permalink / raw)
To: David Miller
Cc: herbert, alexander.duyck, aduyck, tom, jesse, edumazet, netdev
In-Reply-To: <20160405.194517.431351466693438399.davem@davemloft.net>
On 06/04/16 00:45, David Miller wrote:
> From: Edward Cree <ecree@solarflare.com>
> Date: Tue, 5 Apr 2016 16:07:49 +0100
>
>> On the gripping hand, I feel like GRO+TSO is the wrong model for
>> speeding up forwarding/routing workloads. Instead we should be
>> looking into having lists of SKBs traverse the stack together,
>> splitting the list whenever e.g. the destination changes.
> "Destination" is a very complicated beast. It's not just a
> destination IP address.
>
> It's not even just a full saddr/daddr/TOS triplet.
>
> Packets can be forwarded around based upon any key whatsoever in the
> headers. Netfilter can mangle them based upon arbitrary bits in the
> packet, as can the packet scheduler classifier actions.
>
> It's therefore not profitable to try this at all, it's completely
> pointless unless all the keys match up exactly.
Possibly I wasn't completely clear (or maybe I was and I'm just
wrong...), but I meant that _each layer_ in the stack would split the
list whenever it wants to treat two packets differently. Whether
that's a protocol receive handler, or a netfilter or tc operation.
Obviously if you want to decide at the _beginning_ whether "all the
keys match", then you do essentially need GRO's flow-matching logic.
But even then, I find myself wondering if having GRO coalesce the
segments into a superpacket is really better than having it just make
lists of segments, and have that list traverse the stack as a single
entity. That way lossless resegmentation remains easy. But I suppose
that could make life difficult for things like BPF, if they want to
act upon the superframe (because we haven't built it). If instead
they act on each of the segments, we might get different actions for
each segment and that might also be awkward; so you'd still need this
concept of 'any layer in the stack can decide to split lists up'.
-Ed
^ permalink raw reply
* RE: [PATCH net-next] net: add the AF_KCM entries to family name tables
From: Dexuan Cui @ 2016-04-06 10:46 UTC (permalink / raw)
To: David S. Miller, netdev@vger.kernel.org; +Cc: Tom Herbert
In-Reply-To: <1459867271-14592-1-git-send-email-decui@microsoft.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Dexuan Cui
> Sent: Tuesday, April 5, 2016 22:41
> To: davem@davemloft.net; netdev@vger.kernel.org
> Subject: [PATCH net-next] net: add the AF_KCM entries to family name tables
>
> This is for the recent kcm driver, which introduces AF_KCM(41) in
> b7ac4eb(kcm: Kernel Connection Multiplexor module).
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Cc: Signed-off-by: Tom Herbert <tom@herbertland.com>
> ---
> net/core/sock.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index b67b9ae..7e73c26 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -221,7 +221,8 @@ static const char *const
> af_family_key_strings[AF_MAX+1] = {
> "sk_lock-AF_TIPC" , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV" ,
> "sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET" ,
> "sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG" ,
> - "sk_lock-AF_NFC" , "sk_lock-AF_VSOCK" , "sk_lock-AF_MAX"
> + "sk_lock-AF_NFC" , "sk_lock-AF_VSOCK" , "sk_lock-AF_KCM" ,
> + "sk_lock-AF_MAX"
> };
> static const char *const af_family_slock_key_strings[AF_MAX+1] = {
> "slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
> @@ -237,7 +238,8 @@ static const char *const
> af_family_slock_key_strings[AF_MAX+1] = {
> "slock-AF_TIPC" , "slock-AF_BLUETOOTH", "slock-AF_IUCV" ,
> "slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET" ,
> "slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG" ,
> - "slock-AF_NFC" , "slock-AF_VSOCK" ,"slock-AF_MAX"
> + "slock-AF_NFC" , "slock-AF_VSOCK" ,"slock-AF_KCM" ,
> + "slock-AF_MAX"
> };
> static const char *const af_family_clock_key_strings[AF_MAX+1] = {
> "clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
> @@ -253,7 +255,8 @@ static const char *const
> af_family_clock_key_strings[AF_MAX+1] = {
> "clock-AF_TIPC" , "clock-AF_BLUETOOTH", "clock-AF_IUCV" ,
> "clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET" ,
> "clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG" ,
> - "clock-AF_NFC" , "clock-AF_VSOCK" , "clock-AF_MAX"
> + "clock-AF_NFC" , "clock-AF_VSOCK" , "clock-AF_KCM" ,
> + "clock-AF_MAX"
> };
>
> /*
Added Tom to Cc.
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH v2 30/30] ethernet: use parity8 in broadcom/tg3.c
From: zengzhaoxiu @ 2016-04-06 10:21 UTC (permalink / raw)
To: siva.kallam, prashant, mchan; +Cc: netdev, linux-kernel, Zhaoxiu Zeng
In-Reply-To: <57031D9D.801@gmail.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3010080..802a429 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
err = -EIO;
for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
- u8 hw8 = hweight8(data[i]);
-
- if ((hw8 & 0x1) && parity[i])
- goto out;
- else if (!(hw8 & 0x1) && !parity[i])
+ if (parity8(data[i]) == !!parity[i])
goto out;
}
err = 0;
--
2.5.0
^ permalink raw reply related
* [PATCH v2 24/30] ethernet: use parity8 in sun/niu.c
From: zengzhaoxiu @ 2016-04-06 10:11 UTC (permalink / raw)
To: iamjoonsoo.kim, akpm, vbabka, davem, jiri
Cc: netdev, linux-kernel, Zhaoxiu Zeng
In-Reply-To: <57031D9D.801@gmail.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/sun/niu.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 9cc4564..8c344ef 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -2742,18 +2742,12 @@ static int niu_set_alt_mac_rdc_table(struct niu *np, int idx,
static u64 vlan_entry_set_parity(u64 reg_val)
{
- u64 port01_mask;
- u64 port23_mask;
-
- port01_mask = 0x00ff;
- port23_mask = 0xff00;
-
- if (hweight64(reg_val & port01_mask) & 1)
+ if (parity8(reg_val))
reg_val |= ENET_VLAN_TBL_PARITY0;
else
reg_val &= ~ENET_VLAN_TBL_PARITY0;
- if (hweight64(reg_val & port23_mask) & 1)
+ if (parity8((unsigned int)reg_val >> 8))
reg_val |= ENET_VLAN_TBL_PARITY1;
else
reg_val &= ~ENET_VLAN_TBL_PARITY1;
--
2.5.0
^ permalink raw reply related
* RE: [PATCH net-next V3 05/16] net: fec: reduce interrupts
From: Fugang Duan @ 2016-04-06 10:06 UTC (permalink / raw)
To: Troy Kisky, netdev@vger.kernel.org, davem@davemloft.net,
lznuaa@gmail.com
Cc: andrew@lunn.ch, stillcompiling@gmail.com, arnd@arndb.de,
sergei.shtylyov@cogentembedded.com, gerg@uclinux.org,
Fabio Estevam, johannes@sipsolutions.net, l.stach@pengutronix.de,
linux-arm-kernel@lists.infradead.org, tremyfr@gmail.com
In-Reply-To: <1459909562-22865-6-git-send-email-troy.kisky@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Wednesday, April 06, 2016 10:26 AM
> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> <fugang.duan@nxp.com>; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; Troy Kisky <troy.kisky@boundarydevices.com>
> Subject: [PATCH net-next V3 05/16] net: fec: reduce interrupts
>
> By clearing the NAPI interrupts in the NAPI routine and not in the interrupt
> handler, we can reduce the number of interrupts. We also don't need any status
> variables as the registers are still valid.
>
> Also, notice that if budget pkts are received, the next call to fec_enet_rx_napi
> will now continue to receive the previously pending packets.
>
> To test that this actually reduces interrupts, try this command before/after patch
>
> cat /proc/interrupts |grep ether; \
> ping -s2800 192.168.0.201 -f -c1000 ; \
> cat /proc/interrupts |grep ether
>
> For me, before this patch is 2996 interrupts.
> After patch is 2010 interrupts.
>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>
As my previous comments on V2, if you want to improve performance, you can try to separate tx and rx napi process like calling netif_tx_napi_add() to initialize tx NAPI context.
^ permalink raw reply
* [RFC PATCH 2/2] selinux: implement support for dynamic net hook [de-]registration
From: Paolo Abeni @ 2016-04-06 9:51 UTC (permalink / raw)
To: linux-security-module
Cc: David S. Miller, James Morris, Paul Moore, Andreas Gruenbacher,
Stephen Smalley, Florian Westphal, netdev
In-Reply-To: <cover.1459934322.git.pabeni@redhat.com>
This patch leverage the netlbl_changed() hook to perform on demand
registration and deregistration of the netfilter hooks and the
socket_sock_rcv_skb hook.
With default policy and empty netfilter/netlabel configuration, the
above hooks are not registered and this allows avoiding nf_hook_slow
in the xmit path and socket_sock_rcv_skb() in the rx path.
This gives measurable network performance improvement in both
directions.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
security/selinux/hooks.c | 72 +++++++++++++++++++++++++++++++------
security/selinux/include/security.h | 1 +
security/selinux/ss/services.c | 1 +
security/selinux/xfrm.c | 4 +++
4 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 912deee..a3baa69 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4745,11 +4745,13 @@ static int selinux_secmark_relabel_packet(u32 sid)
static void selinux_secmark_refcount_inc(void)
{
atomic_inc(&selinux_secmark_refcount);
+ selinux_net_update();
}
static void selinux_secmark_refcount_dec(void)
{
atomic_dec(&selinux_secmark_refcount);
+ selinux_net_update();
}
static void selinux_req_classify_flow(const struct request_sock *req,
@@ -4836,6 +4838,11 @@ static int selinux_tun_dev_open(void *security)
return 0;
}
+static void selinux_netlbl_changed(void)
+{
+ selinux_net_update();
+}
+
static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb)
{
int err = 0;
@@ -6091,7 +6098,6 @@ static struct security_hook_list selinux_hooks[] = {
LSM_HOOK_INIT(socket_getsockopt, selinux_socket_getsockopt),
LSM_HOOK_INIT(socket_setsockopt, selinux_socket_setsockopt),
LSM_HOOK_INIT(socket_shutdown, selinux_socket_shutdown),
- LSM_HOOK_INIT(socket_sock_rcv_skb, selinux_socket_sock_rcv_skb),
LSM_HOOK_INIT(socket_getpeersec_stream,
selinux_socket_getpeersec_stream),
LSM_HOOK_INIT(socket_getpeersec_dgram, selinux_socket_getpeersec_dgram),
@@ -6113,6 +6119,7 @@ static struct security_hook_list selinux_hooks[] = {
LSM_HOOK_INIT(tun_dev_attach_queue, selinux_tun_dev_attach_queue),
LSM_HOOK_INIT(tun_dev_attach, selinux_tun_dev_attach),
LSM_HOOK_INIT(tun_dev_open, selinux_tun_dev_open),
+ LSM_HOOK_INIT(netlbl_changed, selinux_netlbl_changed),
#ifdef CONFIG_SECURITY_NETWORK_XFRM
LSM_HOOK_INIT(xfrm_policy_alloc_security, selinux_xfrm_policy_alloc),
@@ -6145,6 +6152,11 @@ static struct security_hook_list selinux_hooks[] = {
#endif
};
+/* dynamically registered/unregisterd */
+static struct security_hook_list selinux_sock_hooks[] = {
+ LSM_HOOK_INIT(socket_sock_rcv_skb, selinux_socket_sock_rcv_skb),
+};
+
static __init int selinux_init(void)
{
if (!security_module_enable("selinux")) {
@@ -6240,7 +6252,9 @@ static struct nf_hook_ops selinux_nf_ops[] = {
#endif /* IPV6 */
};
-static int __init selinux_nf_ip_init(void)
+static bool nf_hooks_registered;
+
+static int selinux_nf_ip_init(void)
{
int err;
@@ -6253,25 +6267,21 @@ static int __init selinux_nf_ip_init(void)
if (err)
panic("SELinux: nf_register_hooks: error %d\n", err);
+ nf_hooks_registered = true;
return 0;
}
-__initcall(selinux_nf_ip_init);
-
-#ifdef CONFIG_SECURITY_SELINUX_DISABLE
static void selinux_nf_ip_exit(void)
{
printk(KERN_DEBUG "SELinux: Unregistering netfilter hooks\n");
nf_unregister_hooks(selinux_nf_ops, ARRAY_SIZE(selinux_nf_ops));
+ nf_hooks_registered = false;
}
-#endif
#else /* CONFIG_NETFILTER */
-#ifdef CONFIG_SECURITY_SELINUX_DISABLE
#define selinux_nf_ip_exit()
-#endif
#endif /* CONFIG_NETFILTER */
@@ -6300,8 +6310,8 @@ int selinux_disable(void)
/* Try to destroy the avc node cache */
avc_disable();
- /* Unregister netfilter hooks. */
- selinux_nf_ip_exit();
+ /* Unregister net hooks. */
+ selinux_net_update();
/* Unregister selinuxfs. */
exit_sel_fs();
@@ -6309,3 +6319,45 @@ int selinux_disable(void)
return 0;
}
#endif
+
+DEFINE_MUTEX(selinux_net_mutex);
+
+static bool nf_hooks_required(void)
+{
+ return (selinux_secmark_enabled() || selinux_peerlbl_enabled() ||
+ !selinux_policycap_netpeer) && selinux_enabled;
+}
+
+static bool sock_hooks_required(void)
+{
+ return (!selinux_policycap_netpeer || selinux_secmark_enabled() ||
+ selinux_peerlbl_enabled()) && selinux_enabled;
+}
+
+static bool sock_hooks_registered;
+
+void selinux_net_update(void)
+{
+ if ((nf_hooks_required() == nf_hooks_registered) &&
+ (sock_hooks_required() == sock_hooks_registered))
+ return;
+
+ mutex_lock(&selinux_net_mutex);
+ if (nf_hooks_required() != nf_hooks_registered) {
+ if (!nf_hooks_registered)
+ selinux_nf_ip_init();
+ else
+ selinux_nf_ip_exit();
+ }
+
+ if (sock_hooks_required() != sock_hooks_registered) {
+ if (!sock_hooks_registered)
+ security_add_hooks(selinux_sock_hooks,
+ ARRAY_SIZE(selinux_sock_hooks));
+ else
+ security_delete_hooks(selinux_sock_hooks,
+ ARRAY_SIZE(selinux_sock_hooks));
+ sock_hooks_registered = !sock_hooks_registered;
+ }
+ mutex_unlock(&selinux_net_mutex);
+}
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 38feb55..0428ab4 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -261,6 +261,7 @@ extern void selinux_status_update_setenforce(int enforcing);
extern void selinux_status_update_policyload(int seqno);
extern void selinux_complete_init(void);
extern int selinux_disable(void);
+extern void selinux_net_update(void);
extern void exit_sel_fs(void);
extern struct path selinux_null;
extern struct vfsmount *selinuxfs_mount;
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index ebda973..c509018 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2016,6 +2016,7 @@ static void security_load_policycaps(void)
POLICYDB_CAPABILITY_OPENPERM);
selinux_policycap_alwaysnetwork = ebitmap_get_bit(&policydb.policycaps,
POLICYDB_CAPABILITY_ALWAYSNETWORK);
+ selinux_net_update();
}
static int security_preserve_bools(struct policydb *p);
diff --git a/security/selinux/xfrm.c b/security/selinux/xfrm.c
index 56e354f..cc2b0d4 100644
--- a/security/selinux/xfrm.c
+++ b/security/selinux/xfrm.c
@@ -112,6 +112,7 @@ static int selinux_xfrm_alloc_user(struct xfrm_sec_ctx **ctxp,
*ctxp = ctx;
atomic_inc(&selinux_xfrm_refcount);
+ selinux_net_update();
return 0;
err:
@@ -128,6 +129,7 @@ static void selinux_xfrm_free(struct xfrm_sec_ctx *ctx)
return;
atomic_dec(&selinux_xfrm_refcount);
+ selinux_net_update();
kfree(ctx);
}
@@ -303,6 +305,7 @@ int selinux_xfrm_policy_clone(struct xfrm_sec_ctx *old_ctx,
if (!new_ctx)
return -ENOMEM;
atomic_inc(&selinux_xfrm_refcount);
+ selinux_net_update();
*new_ctxp = new_ctx;
return 0;
@@ -370,6 +373,7 @@ int selinux_xfrm_state_alloc_acquire(struct xfrm_state *x,
x->security = ctx;
atomic_inc(&selinux_xfrm_refcount);
+ selinux_net_update();
out:
kfree(ctx_str);
return rc;
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox