Re: pull-request: mac80211-next 2016-06-09

2016-06-11 Thread Johannes Berg
On Fri, 2016-06-10 at 23:16 -0700, David Miller wrote: > > Can I ask you to pull net into net-next, preferably before merging > > this? > Looks good, pulled, thanks! Thanks! I see you also had pulled net in for other reasons, so I'll include the hwsim namespace patch in the next pull request :)

Re: [PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

2016-06-15 Thread Johannes Berg
I was about to apply this (with a typo fix for "responsile"), but noticed these messages: >   printk(KERN_DEBUG "mac80211_hwsim: received a REGISTER, " >      "switching to wmediumd mode with pid %d\n", info- > >snd_portid); > + if (notify->portid ==

Re: [PATCH] mac80211_hwsim: Allow wmediumd to attach to radios created in its netns

2016-06-15 Thread Johannes Berg
On Wed, 2016-06-15 at 14:37 +0200, Martin Willi wrote: > > > > > > >  printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink" > > >         " socket, switching to perfect channel medium\n"); > > > I wonder if we can do something better about them? Or perhaps if we > > should remove them,

Re: [PATCH] mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL

2016-05-31 Thread Johannes Berg
On Fri, 2016-05-13 at 12:41 +0200, Martin Willi wrote: > A wmediumd that does not send this attribute causes a NULL pointer > dereference, as the attribute is accessed even if it does not exist. > > The attribute was required but never checked ever since userspace > frame > forwarding has been

pull-request: mac80211 2016-06-01

2016-06-01 Thread Johannes Berg
Hi Dave, For now, I have just three fixes for the current cycle. One of them, the hwsim one, becomes interesting with some pending work to make hwsim work for unprivileged users in namespaces, and I don't want to allow them to crash the system ... I'll thus wait with that patch until you pull

Re: [PATCH v2 03/10] nl80211: Prefer ether_addr_copy

2016-05-31 Thread Johannes Berg
> The requirement is to be __aligned(2). I've added 4 instances of > ether_addr_copy with 8 addresses as arguments.  Of these, the 4 > src arguments are really the same type (i.e. nla_data acting on a > const nlattr*), so I'll try to reason about the 5 total cases below - > 1. cfg->dst_mac should

Re: [PATCH 1/3] nl80211: Fix checkpatch warnings

2016-05-31 Thread Johannes Berg
On Mon, 2016-05-30 at 10:30 +1000, Julian Calaby wrote: > Hi All, > > On Sun, May 29, 2016 at 1:30 PM, Kirtika Ruchandani > wrote: > > > > This patch fixes the following checkpatch.pl warnings about > > comments in nl80211.c : > > - networking block comments don't

Re: [PATCH 3/3] mac80211: mesh: Add support for HW RC implementation

2016-06-21 Thread Johannes Berg
> - if (sta->mesh->fail_avg >= 100) > - return MAX_METRIC; > + /* try to get rate based on HW RC algorithm */ > + rate = drv_get_expected_throughput(local, >sta); This doesn't look correct, since you should use the rate control op if available, to get data from rate

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

2016-06-21 Thread Johannes Berg
On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote: >  > (Actually, "::wifi" is super confusing, I'd expect that to be a led > that blinks when wifi is active.) Agree with that, yeah, that'd be confusing. > Well... "airplane" is quite confusing. I'd we use "rfkill" for > disabling radios, and

Re: [PATCH] wlcore: time sync : add support for 64 bit clock

2016-06-23 Thread Johannes Berg
On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote: > Changed the configuration to support 64bit instead of 32bit > this in order to offload the driver from handling a wraparound. [...] Since you Cc'ed me, and presumably want me to review it, I'll say that this looks like a terrible idea: >

Re: [PATCH] wlcore: time sync : add support for 64 bit clock

2016-06-23 Thread Johannes Berg
> > Additionally, this looks like it changes the firmware API, so that  > > older firmware images will no longer work? > > It is backwards compatible,  > although it changes a API structure, older firmware are using only > u16 for the field so there is no impact on that. > Oh, ok. I had also

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

2016-06-28 Thread Johannes Berg
On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote: >  > Johannes, I feel like being able to set calibration data at runtime > is something common to all wireless drivers, so instead of using > vendor commands what do you think if I pass the calibration data name > instead of using those

Re: [PATCH] nl80211: improve nl80211_parse_mesh_config type checking

2016-06-28 Thread Johannes Berg
On Wed, 2016-06-15 at 22:29 +0200, Arnd Bergmann wrote: > When building a kernel with W=1, the nl80211.c file causes a number > of > warnings, all about the same problem: > > net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config': > net/wireless/nl80211.c:5287:103: error: comparison is

Re: [PATCH] mac80211_hwsim: Added vendor echo command

2016-06-25 Thread Johannes Berg
On Sat, 2016-06-25 at 21:32 +0300, Jouni Malinen wrote: >  > All you need to do is to prepare a hostap.git contribution that > requests a new subcommand/attribute to be assigned and once that gets > applied to the hostap.git master branch, the values have been > assigned and can be used for

pull-request: mac80211 2016-06-29

2016-06-29 Thread Johannes Berg
Hi Dave, Another (pretty old) bug showed up, and I have a single fix for it from Jouni; would be nice to still get it in, but it's in mesh which seems to mostly have users who integrate everything themselves. Let me know if there's any problem. Thanks, johannes The following changes since

Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template

2016-06-29 Thread Johannes Berg
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote: >  >  net/mac80211/mesh.c | 33 - >  net/mac80211/util.c |  3 --- >  net/wireless/mesh.c |  2 +- That's not a good patch - one change is mac80211 and the other cfg80211. > - .ht_opmode =

Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

2016-06-29 Thread Johannes Berg
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote: > From: Maital Hahn > > Some drivers (e.g. wl18xx) expect that the last stage in the > de-initialization process will be stopping the beacons, similar to > ap. Update ieee80211_stop_mesh() flow accordingly. > How well have

Re: [PATCH] mac80211: util: mesh is not connected properly after recovery

2016-06-29 Thread Johannes Berg
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote: > From: Maital Hahn > > In the reconfigure process for mesh interface, moved the > reconfiguration > of the mesh peers to be done only after restarting the beacons, > the same as it is done for AP. > > Signed-off-by: Maital

Re: [PATCH] mac80211: util: mesh is not connected properly after recovery

2016-06-29 Thread Johannes Berg
Also - your subject lines should explain the *fix*, not the *bug* johannes

Re: [PATCH] mac80211: rx: frames received out of order

2016-06-29 Thread Johannes Berg
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote: > From: Meirav Kama > > MP received data frames from another MP. Frames are forwarded > from Rx to Tx to be transmitted to a third MP. > Upon cloning the skb, the tx_info was zeroed, and the > hw_queue wasn't set correctly,

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

2016-02-10 Thread Johannes Berg
On 2016-02-10 17:53, Dan Williams wrote: Yeah, I get that now.  It's just that to me, something called "AIRPLANE_MODE_CHANGE" seems like it should actually change airplane mode on/off, which implies killing radios.  I wouldn't have had the problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE,

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

2016-02-10 Thread Johannes Berg
On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote: > I'd like to clarify a bit, so tell me if I'm correct or not.  Using > RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device > state. It's just an indicator with no relationship to any of the > registered rfkill switches, right?

[PATCH v3 4/4] ipv6: add option to drop unsolicited neighbor advertisements

2016-02-04 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be NA proxies that use knowledge of the network to correctly answer requests. To prevent unsolicitd advertisements on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v3 3/4] ipv6: add option to drop unicast encapsulated in L2 multicast

2016-02-04 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv6 unicast packets encapsulated in link-layer multi- or

[PATCH v3 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

2016-02-04 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv4 unicast packets encapsulated in link-layer multi- or

[PATCH v3 2/4] ipv4: add option to drop gratuitous ARP packets

2016-02-04 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

2016-02-08 Thread Johannes Berg
On 2016-02-08 17:20, Marcel Holtmann wrote: as explained in an earlier response, the concept Airplane Mode seems to be imposing policy into the kernel. Do we really want have this as a kernel exposed API. This patch is the one that *solves* that problem ... please read it more carefully?

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

2016-01-29 Thread Johannes Berg
On Thu, 2016-01-28 at 19:54 -0600, Larry Finger wrote: >  > I have been running an RTL8821AE since kernel 3.18 without hitting > this problem > using a TRENDnet AC1750 dual-band AP. The UniFi may be doing > something that the > driver is not expecting. Are you quite sure you're actually using

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

2016-01-29 Thread Johannes Berg
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote: >  > Upon further inspection, my log has the line "rtl8821ae :02:00.0 > wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that > first. > Likely TKIP; enable only WPA2 (CCMP) on the AP. johannes

Re: [PATCH net-next 08/40] net: fec: move cbd_bufaddr assignment closer to the mapping function

2016-01-28 Thread Johannes Berg
On Thu, 2016-01-28 at 23:02 +0100, Arnd Bergmann wrote: > On Thursday 28 January 2016 14:25:32 Troy Kisky wrote: > > Signed-off-by: Troy Kisky > > --- > >  drivers/net/ethernet/freescale/fec_main.c | 4 ++-- > >  1 file changed, 2 insertions(+), 2 deletions(-) > >

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

2016-01-28 Thread Johannes Berg
On Thu, 2016-01-28 at 14:04 -0800, Linus Torvalds wrote: >  > Well, it "makes a difference" in the sense that the warning goes > away. > But it doesn't make things work. In fact, it might be making things > worse. Heh, ok. > Because with that patch, the wireless still authenticates and >

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

2016-01-28 Thread Johannes Berg
On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote: >  > I used to have the basic original UniFi UAP. I've replaced them with > the newer "AC Lite" version: > > https://www.ubnt.com/unifi/unifi-ap-ac-lite/ > > so it's a fairly big jump from a 2.4GHz-only network to a dual-band > one. >

pull-request: mac80211 2016-01-26

2016-01-26 Thread Johannes Berg
mac80211: clear local->sched_scan_req properly on reconfig mac80211: handle sched_scan_stopped vs. hw restart race Emmanuel Grumbach (1): mac80211: fix PS-Poll handling Helmut Schaa (1): mac80211: Don't buffer non-bufferable MMPDUs Johannes Berg (4): mac80211: recal

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

2016-01-28 Thread Johannes Berg
On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote: > .. except now I upgraded the nearest access point, and now wireless > on that machine no longer works. Can you describe the upgrade a bit more, just for background? > Or rather, it actually *does* work in the sense that it >

Re: [PATCH v3 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

2016-01-28 Thread Johannes Berg
Hi, Is there anything I should do about these patches? I see you marked them as "deferred" in patchwork, but I don't really know how you're using that state. johannes

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

2016-01-26 Thread Johannes Berg
On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: >  > seems to work fine. I wish we could instantiate this from device-tree > so we can finially get rid of this file. That'd be nice - anyone want to propose rfkill DT bindings? :) johannes

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

2016-01-26 Thread Johannes Berg
ather take the entire series through your tree to get it into one place for Marc? In which case, you have my Acked-by: Johannes Berg <johan...@sipsolutions.net> for the other 3 patches. Let me know which you prefer. johannes

Re: ibss.c backtrace when batman-adv adds wireless interface

2016-02-03 Thread Johannes Berg
On Wed, 2016-02-03 at 10:26 -0500, Josh Boyer wrote: > On Wed, Feb 3, 2016 at 10:24 AM, Josh Boyer g> wrote: > > Hi All, > > > > We've had a user report the backtrace below when loading batman-adv > > on > > his machine.  It looks like the cfg80211 layer is

Re: [PATCH] mac80211: minstrel_ht: fix out-of-bound in minstrel_ht_set_best_prob_rate

2016-02-02 Thread Johannes Berg
On Fri, 2016-01-29 at 11:35 +0300, Konstantin Khlebnikov wrote: > Patch fixes this splat > > BUG: KASAN: slab-out-of-bounds in > minstrel_ht_update_stats.isra.7+0x6e1/0x9e0 > [mac80211] at addr 8800cee640f4 Read of size 4 by task > swapper/3/0 > > Signed-off-by: Konstantin Khlebnikov

Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)

2016-02-24 Thread Johannes Berg
On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote: >  > Why would it need to? It could look at default triggers for the led > if it really wanted to. And then it needs to change them; if anything goes wrong error recovery is practically impossible since the trigger information is lost

Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)

2016-02-24 Thread Johannes Berg
On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote: > If you want different trigger, implement different trigger. If you > want to indicate all but wifi, implement all but wifi, and then > userspace can select it by writing trigger name. This is still mostly a strawman, since userspace

Re: pull-request: mac80211-next 2016-02-23

2016-02-24 Thread Johannes Berg
On Tue, 2016-02-23 at 15:45 +0100, Johannes Berg wrote: > Hi Dave, > > Here's a (first, even? I didn't have much until before the > conference...) pull request for net-next. > Hm, need to withdraw this, sorry about that. There appears to be some compilation issue that I'm not

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode

2016-02-24 Thread Johannes Berg
On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote: > Well "the airplane mode" is well defined. It means no intentional > transmitting at radio frequencies. > > The fact that you are allowed to use WIFI on certain flights does not > change anything. Nope, not that simple. Pick up any

pull-request: mac80211 2016-02-23

2016-02-23 Thread Johannes Berg
critical protocol session upon disconnect event Chris Bainbridge (1): mac80211: fix use of uninitialised values in RX aggregation Felix Fietkau (1): mac80211: minstrel_ht: set default tx aggregation timeout to 0 Johannes Berg (2): wext: fix message delay/ordering cfg80211

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

2016-02-23 Thread Johannes Berg
On Fri, 2016-02-19 at 19:03 +0100, Thierry Reding wrote: > On Thu, Feb 18, 2016 at 09:04:49PM +0100, Johannes Berg wrote: > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > > >   > > >

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode

2016-02-23 Thread Johannes Berg
On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote: > So... you add LED trigger to display the state of the airplane > mode. Ok, why not. Yes. However, consider that "the airplane mode" isn't a well-defined concept; some systems may want to light up that LED even when wifi is still enabled,

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

2016-02-23 Thread Johannes Berg
On Tue, 2016-02-23 at 16:06 +0100, Arnd Bergmann wrote: >  > Does rfkill always have a separate device in the Linux driver model? Yes, the rfkill core code registers and adds one in the rfkill class. > johannes

pull-request: mac80211-next 2016-02-26

2016-02-26 Thread Johannes Berg
l function Ilan Peer (1): mac80211: Recalc min chandef when station is associated Johannes Berg (8): cfg80211: remove CFG80211_REG_DEBUG mac80211: document status.freq restrictions mac80211: refactor HT/VHT to chandef code mac80211_hwsim: remove shadowing variable

pull-request: mac80211-next 2016-02-23

2016-02-23 Thread Johannes Berg
def when station is associated Johannes Berg (8): cfg80211: remove CFG80211_REG_DEBUG mac80211: document status.freq restrictions mac80211: refactor HT/VHT to chandef code mac80211_hwsim: remove shadowing variable rfkill: disentangle polling pause and suspend mac80

[PATCH] net: fec: make driver endian-safe

2016-01-23 Thread Johannes Berg
-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/Makefile | 2 + drivers/net/ethernet/freescale/fec.h | 39 ++--- drivers/net/ethernet/freescale/fec_main.c | 130 -- 3 files changed, 99 insertions(+), 72 deletions(-) diff

Re: net: fec: make driver endian-safe

2016-01-23 Thread Johannes Berg
On Sat, 2016-01-23 at 23:09 +0100, Johannes Berg wrote: >  > +/* buffer endianness appears to be a mess ... ARM is usually LE but > can be BE */ > +#if defined(CONFIG_ARM) && defined(CONFIG_CPU_BIG_ENDIAN) Just realized that this is, of course, completely wrong. If the ARM

Re: [PATCH v2] net: fec: make driver endian-safe

2016-01-24 Thread Johannes Berg
On Mon, 2016-01-25 at 10:52 +1000, Greg Ungerer wrote: >  > I tested this on a ColdFire (5208) target that uses this driver. > Simple testing showed it working with no problems. The ColdFire > SoC processors use a version of the FEC hardware module, and they > always run big-endian. > Great,

[PATCH v2] net: fec: make driver endian-safe

2016-01-24 Thread Johannes Berg
not clear that the ifdef there really is correct and shouldn't just be #ifdef CONFIG_ARM, but I also can't test on anything but the i.MX6 HummingBoard where this gets it working with a BE kernel. Signed-off-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/Ma

[PATCH v2] net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28

2016-01-25 Thread Johannes Berg
CONFIG_ARM is safe for them. Signed-off-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/fec.h | 8 +++- drivers/net/ethernet/freescale/fec_main.c | 3 +-- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec.h b/d

[PATCH] net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28

2016-01-25 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28 is wrong if some other ARM platform uses this device - the operation of the driver would depend on an unrelated ARM platform that might or might not be set for multi-platform k

Re: net/rfkill: WARNING in rfkill_fop_read

2016-01-26 Thread Johannes Berg
On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING message in rfkill_fop_read: > > [ cut here ] > WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663 > __might_sleep+0x138/0x1a0() > do not call blocking ops when

Re: [PATCH] net:mac80211:mesh_plink: remove redundant sta_info check

2016-01-26 Thread Johannes Berg
On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote: > Remove unnecessory "if" statement and club it with previos "if" > block. > Applied. johannes

Re: [PATCH 0/8] General RFKill improvements

2016-01-26 Thread Johannes Berg
Hi, On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote: > This series contains a few general improvements to the RFKill code, > found while > I was writing the rfkill-all / airplane mode LED trigger. All were > points where > I had to read twice or do some other kind of extra effort

[PATCH 2/2] cfg80211/wext: fix message ordering

2016-01-27 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> Since cfg80211 frequently takes actions from its netdev notifier call, wireless extensions messages could still be ordered badly since the wext netdev notifier, since wext is built into the kernel, runs before the cfg80211 netdev notifier. For e

[PATCH 1/2] wext: fix message delay/ordering

2016-01-27 Thread Johannes Berg
From: Johannes Berg <johannes.b...@intel.com> Beniamino reported that he was getting an RTM_NEWLINK message for a given interface, after the RTM_DELLINK for it. It turns out that the message is a wireless extensions message, which was sent because the interface had been con

Re: [PATCH v2] net: fec: make driver endian-safe

2016-01-24 Thread Johannes Berg
On Sun, 2016-01-24 at 17:49 +0100, Arnd Bergmann wrote: > I'd argue that the "(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)" > is definitely wrong, because if we ever get another ARM platform > that uses this driver, it may or may not work depending on whether > the ARCH_MXC is also set, and

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

2016-02-18 Thread Johannes Berg
On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > >   > > Johannes, I assume that you'll want to take this through your tree > > because of the dependency? In that case: > > > > Acked-by: Thierry R

Re: [PATCH 7/9] rfkill: Create "rfkill-airplane_mode" LED trigger

2016-02-18 Thread Johannes Berg
On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote: > This creates a new LED trigger to be used by platform drivers as a > default trigger for airplane-mode indicator LEDs. > > By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called > for all types (RFKILL_TYPE_ALL),

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

2016-02-18 Thread Johannes Berg
Hi, Sorry for the delay reviewing this. On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote: > Provide an interface for the airplane-mode indicator be controlled > from > userspace. User has to first acquire the control through > RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open

Re: pull-request: mac80211-next 2016-02-26

2016-03-01 Thread Johannes Berg
On Tue, 2016-03-01 at 17:11 -0500, David Miller wrote: >  > There was a minor merge conflict with net/mac80211/debugfs.c, take > a look and send me any fixups necessary. > Ah yes, I'd wondered when that change was coming in, but missed that you had it in net-next now. Looks good, thanks!

Re: [PATCH net-next v2 3/3] macsec: introduce IEEE 802.1AE driver

2016-03-15 Thread Johannes Berg
Hi, > +struct macsec_rx_sa_stats { > + __u32 InPktsOK; > + __u32 InPktsInvalid; > + __u32 InPktsNotValid; > + __u32 InPktsNotUsingSA; > + __u32 InPktsUnusedSA; > +}; > + > +struct macsec_tx_sa_stats { > + __u32 OutPktsProtected; > + __u32 OutPktsEncrypted; > +}; Just

Re: [PATCH net-next 1/3] uapi: add MACsec bits

2016-03-09 Thread Johannes Berg
On Wed, 2016-03-09 at 11:51 +0100, Sabrina Dubroca wrote: > > > +#define DEFAULT_CIPHER_NAME "GCM-AES-128" > > > +#define DEFAULT_CIPHER_ID   0x008002000101ULL > > > +#define DEFAULT_CIPHER_ALT  0x0080C2000101ULL > > > > > +enum macsec_attrs { > > [...] > > > + MACSEC_ATTR_CIPHER_SUITE,

Re: [PATCH net-next 3/3] macsec: introduce IEEE 802.1AE driver

2016-03-09 Thread Johannes Berg
Hi, Thanks for the comments. > > > +struct gcm_iv { > > > + union { > > > + u8 secure_channel_id[8]; > > > + sci_t sci; > > > + }; > > > + __be32 pn; > > > +}; > > > > Should this be __packed? > > I think that's not necessary here. Yeah, there's probably no way a compiler

Re: Question on rhashtable in worst-case scenario.

2016-03-31 Thread Johannes Berg
On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote: > If someone can fix rhashtable, then great. > I read some earlier comments [1] back when someone else reported > similar problems, and the comments seemed to indicate that rhashtable > was broken in this manner on purpose to protect against

Re: NETLINK_URELEASE non-bound socket problem (was: [PATCH] Fix local DoS in cfg80211 subsystem)

2016-04-06 Thread Johannes Berg
On Wed, 2016-04-06 at 11:20 +0300, Dmitrijs Ivanovs wrote: > Hi Johannes! > > I will prepare patch which does not send NETLINK_URELEASE for unbound > sockets as you suggest. But I think protocol check in nl80211 is > still needed because port_id is unique per-protocol. > Yes, good point. Can

[PATCH] netlink: don't send NETLINK_URELEASE for unbound sockets

2016-04-07 Thread Johannes Berg
e them to stop reporting events, as if NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called. Fix this problem by checking that the socket is bound before generating the NETLINK_URELEASE notification. Cc: sta...@vger.kernel.org Signed-off-by: Dmitry Ivanov <d...@ubnt.com> Signed-off-by: J

Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

2016-04-13 Thread Johannes Berg
> The patch was build-tested / debugged by removing the > "if VERBOSE > SHOW_ERROR_MESSAGES" guards. Stands to reason that we should just remove the (more or less) dead code, since I don't think anyone really ever touches this driver any more or will ever again ... johannes

Re: [PATCH net-next WIP] ethtool: generic netlink policy

2016-04-12 Thread Johannes Berg
Hi, > + [ETHTOOL_ATTR_FLAGS]= { .type = NLA_U32 }, I suppose this comes from the current API, but perhaps it'd be worthwhile to make provision for more flags? Perhaps even using NLA_BINARY and have "infinitely extensible" flags. > + [ETHTOOL_ATTR_SSET_COUNT] =

Re: pull-request: mac80211-next 2016-04-06

2016-04-06 Thread Johannes Berg
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

pull-request: mac80211-next 2016-04-06

2016-04-06 Thread Johannes Berg
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

pull-request: mac80211 2016-04-06

2016-04-06 Thread Johannes Berg
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 Lu

Re: [PATCH] mac80211: fix order of flag descriptions

2016-03-19 Thread Johannes Berg
On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote: > Fix order of mac80211_rx_flags description to match the enum. > > Signed-off-by: Luis de Bethencourt > --- > Hi, > > I want ahead and fixed the order of the descriptions. checkpatch.pl > was giving > a

Re: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()

2016-03-20 Thread Johannes Berg
On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote: > Use alloc_workqueue() to allocate the workqueue instead of > create_singlethread_workqueue() since the latter is deprecated and is > scheduled for removal. Scheduled where? >  static void iwl_setup_deferred_work(struct iwl_priv *priv)

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

2016-03-24 Thread Johannes Berg
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote: > If everything else is working, I'd be happy to throw in > WQ_MEM_RECLAIM but I really don't want to add it if it doesn't > actually achieve the goal.  Can a wireless person chime in here? > I think for many wireless devices the workqueue,

Re: [iproute PATCH] libnetlink: Double the dump buffer size

2016-03-05 Thread Johannes Berg
On Fri, 2016-03-04 at 15:35 -0800, Stephen Hemminger wrote: >  > > There have been reports about 'ip addr' printing "Message > > truncated" on [...] > I thought this was addressed in kernel by making the VF info > optional. > The netlink protocol is showing some strain, this is one of them. I

Re: [PATCH 2/2] mac80211: mesh: convert path table to rhashtable

2016-03-03 Thread Johannes Berg
On Wed, 2016-03-02 at 14:43 -0500, David Miller wrote: > From: Bob Copeland > Date: Wed,  2 Mar 2016 10:09:20 -0500 > > > In the time since the mesh path table was implemented as an > > RCU-traversable, dynamically growing hash table, a generic RCU > > hashtable

Re: [PATCH 1/2] rhashtable: accept GFP flags in rhashtable_walk_init

2016-03-03 Thread Johannes Berg
On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote: > In certain cases, the 802.11 mesh pathtable code wants to > iterate over all of the entries in the forwarding table from > the receive path, which is inside an RCU read-side critical > section.  Enable walks inside atomic sections by

Re: [PATCH RFC 1/2] rhashtable: accept GFP flags in rhashtable_walk_init

2016-03-01 Thread Johannes Berg
On Sun, 2016-02-28 at 20:06 -0500, Bob Copeland wrote: > In certain cases, the 802.11 mesh pathtable code wants to > iterate over all of the entries in the forwarding table from > the receive path, which is inside an RCU read-side critical > section.  Enable walks inside atomic sections by

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

2016-03-01 Thread Johannes Berg
On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote: > > +typedef u64 codel_time_t; Do we really need this? And if yes, does it have to be in the public header file? Why a typedef anyway? > - * @txq_ac_max_pending: maximum number of frames per AC pending in > all txq > - * entries for a

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

2016-03-01 Thread Johannes Berg
On Tue, 2016-03-01 at 00:39 +0200, Jouni Malinen wrote: > > I agree there is a difference in the logic here, Gah. I thought I'd reviewed the logic and made sure there's no difference ... :) > > thanks for taking the > > time to point it out so clearly, and sorry for missing this. But AFAIU > >

pull-request: mac80211 2016-03-02

2016-03-02 Thread Johannes Berg
for it Felix Fietkau (1): mac80211: minstrel_ht: fix a logic error in RTS/CTS handling Johannes Berg (2): mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs mac80211_hwsim: treat as part of mac80211 for MAINTAINERS

Re: [PATCH net-next 1/3] uapi: add MACsec bits

2016-03-08 Thread Johannes Berg
On Mon, 2016-03-07 at 18:12 +0100, Sabrina Dubroca wrote: > +++ b/include/uapi/linux/if_macsec.h Some bits of documentation in this file, regarding all the various operations and attributes, might be nice. At least the netlink types? E.g., given this: > +#define DEFAULT_CIPHER_NAME

Re: [PATCH net-next 3/3] macsec: introduce IEEE 802.1AE driver

2016-03-08 Thread Johannes Berg
On Mon, 2016-03-07 at 18:12 +0100, Sabrina Dubroca wrote: >  > +struct gcm_iv { > + union { > + u8 secure_channel_id[8]; > + sci_t sci; > + }; > + __be32 pn; > +}; Should this be __packed? But the struct is confusing; sci_t is a host type (that depends on

Re: [Odd commit author id merge via netdev]

2016-04-01 Thread Johannes Berg
On Fri, 2016-04-01 at 10:51 -0700, santosh shilimkar wrote: > Hi Dave, > > I noticed something odd while checking the recent > commits of mine in kernel.org tree made it via netdev. > > Don't know if its patchwork tool doing this. > Usual author line in my git objects : > Author: Santosh

Re: Question on rhashtable in worst-case scenario.

2016-04-01 Thread Johannes Berg
On Fri, 2016-04-01 at 08:46 +0800, Herbert Xu wrote: > On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: > > > > > > Does removing this completely disable the "-EEXIST" error? I can't > > say > > I fully understand the elasticity stuf

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

2016-04-04 Thread Johannes Berg
On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote: >  > Having a common check makes sense. The tricky thing is that the type can > only be checked after taking the reference, and I wanted to keep the > scope of the prog brief in the case of errors. I would have to move the > bpf_prog_get

Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

2016-04-04 Thread Johannes Berg
On Sun, 2016-04-03 at 11:28 +0900, Lorenzo Colitti wrote: > That said, getting BPF to the driver is part of the picture. On the > chipsets we're targeting for APF, we're only seeing 2k-4k of memory > (that's 256-512 BPF instructions) available for filtering code, which > means that BPF might be

Re: [PATCH] mac80211: add doc for RX_FLAG_DUP_VALIDATED flag

2016-04-05 Thread Johannes Berg
On Fri, 2016-03-18 at 16:09 +, Luis de Bethencourt wrote: > Add documentation for the flag for duplication check. > > Fixes the following warning when running make htmldocs: > warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum > 'mac80211_rx_flags' > Applied, thanks. johannes

NETLINK_URELEASE non-bound socket problem (was: [PATCH] Fix local DoS in cfg80211 subsystem)

2016-04-05 Thread Johannes Berg
Hi Dmitrijs, Thanks for reporting this problem. > The patch below corrects this problem in kernel space. I don't think that this is correct, there are four more users of NETLINK_URELEASE (nfnetlink, NFC), and afaict all of them have the same bug as nl80211. Rather than fix all of them, I

Re: [PATCH] mac80211: remove description of dropped member

2016-04-05 Thread Johannes Berg
On Fri, 2016-03-18 at 19:23 +, Luis de Bethencourt wrote: > Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd") > removed the member from the sta_info struct but the description > stayed > lingering. Remove it. > Also applied. johannes

Re: Question on rhashtable in worst-case scenario.

2016-03-30 Thread Johannes Berg
On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: > Looks like rhashtable has too much policy in it to properly deal with > cases where there are too many hash collisions, so I am going to work > on reverting it's use in mac80211. I'm not really all that happy with that approach - can't we fix

Re: Question on rhashtable in worst-case scenario.

2016-03-30 Thread Johannes Berg
On Wed, 2016-03-30 at 21:55 +0800, Herbert Xu wrote: > Well to start with you should assess whether you really want to > hash multiple objects with the same key.  In particular, can an > adversary generate a large number of such objects? No, the only reason this happens is local - if you take

Re: Question on rhashtable in worst-case scenario.

2016-03-31 Thread Johannes Berg
On Thu, 2016-03-31 at 08:13 -0700, Ben Greear wrote: >  > I see insertion failure, and then later, if of course fails to delete > as well since it was never inserted to begin with.  There is no good > way to deal with insertion error, so just need to fix the hashtable. Oh, that's an oversight in

Re: Question on rhashtable in worst-case scenario.

2016-03-31 Thread Johannes Berg
On Thu, 2016-03-31 at 15:50 +0800, Herbert Xu wrote: > On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote: > > > > > > In this case, I think perhaps you can just patch your local system > > with > > the many interfaces connecting to the same AP

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

2016-04-02 Thread Johannes Berg
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: > +static int mlx4_bpf_set(struct net_device *dev, int fd) > +{ [...] > + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) { > + bpf_prog_put(prog); > + return -EINVAL; > + } > +

<    4   5   6   7   8   9   10   11   12   13   >