On Thu, 2017-06-15 at 12:18 -0400, David Miller wrote:
> Although a bit disruptive, it might be nice to convert all of the
> other "char *" related data pointers in skbuff based interfaces.
I think it'd actually be pretty easy, since there are very few cases
where you need non-void, e.g.
*skb_pu
On Thu, 2017-06-15 at 14:36 -0400, David Miller wrote:
> Johannes these changes look good, please feel free to submit them
> formally.
Yeah, will do, just need to find the time to at least build-test them
(and we had a holiday here today) :)
johannes
On Thu, 2017-06-15 at 09:54 +, YUAN Linyu wrote:
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-owner@vger.kernel
> > .org]
> > On Behalf Of Johannes Berg
> > Sent: Thursday, June 15, 2017 5:28 PM
> > To: netdev@v
From: Johannes Berg
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type
On Thu, 2017-06-15 at 07:20 +, YUAN Linyu wrote:
> >
> In my opinion if spatch can do it even it found one place, keep it.
> Only leave difficult places like ndisc.c to me.
It's not so simple - I'd have to tailor the spatch to it pretty much I
guess, spending far more time on the spatch than
On Thu, 2017-06-15 at 07:05 +, YUAN Linyu wrote:
> > @@
> > type t;
> > expression skb, len;
> > identifier p;
> > @@
> > t *p
> > - = skb_put(skb, len);
> > + = skb_put_zero(skb, len);
> > -memset(p, 0, len);
> >
> > and it can't figure out that it should remove the variable, without
> > much
On Wed, 2017-06-14 at 23:45 +, YUAN Linyu wrote:
> >
> > But still a few more, I think that you didn't find, e.g.
> > in mac80211.
>
> Yes, I thought you already done in mac80211
So did I, but I also only applied my spatch :)
johannes
On Thu, 2017-06-15 at 00:23 +, YUAN Linyu wrote:
> Hi,
> Indeed, it find more.
> Compare with my patch, still lost pattern like below,
> 1. sctp and openvswitch
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -463,7 +463,7 @@ static int sctp_packet_pack(struct sctp_packet
> *packet,
>
On Wed, 2017-06-14 at 13:36 -0700, Joe Perches wrote:
>
> Given you are adding a lot of these, it might be better
> to add an exported function that duplicates most of
> skb_put with a memset at the end.
Yeah, could be done. I'm not sure why you'd want to duplicate it rather
than call it though?
From: Johannes Berg
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type
From: Johannes Berg
It's nicer to return void, since then there's no need to
cast to any structures. Currently none of the users have
a cast, but a number of future conversions do.
Signed-off-by: Johannes Berg
---
include/linux/skbuff.h | 4 ++--
1 file changed, 2 insertions(+), 2
On Wed, 2017-06-14 at 15:38 -0400, David Miller wrote:
> What do you think about Stephen Hemminger's feedback to make
> skb_put_zero() return "void *". It will avoid a lot of casts and
> make the conversions look nicer.
I think it's a good idea. I can send a patch, and remove some casts
where th
On Wed, 2017-06-14 at 12:14 -0700, Stephen Hemminger wrote:
>
> > I just copied it from skb_put() - you could ask the same there? :)
>
> My taste is to have less casts. Never understood why so many skb_
> functions returned char *, probably a leftover from older Unix style.
I agree, for many of
On Wed, 2017-06-14 at 08:44 -0700, Stephen Hemminger wrote:
>
> > memcpy(skb_put(skb, sizeof(ra)), ra, sizeof(ra));
> >
> > - hdr = (struct mld_msg *) skb_put(skb, sizeof(struct
> > mld_msg));
> > - memset(hdr, 0, sizeof(struct mld_msg));
> > + hdr = (struct mld_msg *) skb_put_zero(skb
On Wed, 2017-06-14 at 18:29 +0200, Johannes Berg wrote:
> On Wed, 2017-06-14 at 23:00 +0800, yuan linyu wrote:
>
> > sorry, I do them by hand.
>
> oh, ok.
>
> This seems to work:
>
> @@
> identifier p;
> expression len;
> expression skb;
> type t;
>
On Wed, 2017-06-14 at 23:00 +0800, yuan linyu wrote:
> sorry, I do them by hand.
oh, ok.
This seems to work:
@@
identifier p;
expression len;
expression skb;
type t;
@@
-p = (t)skb_put(skb, len);
-memset(p, 0, len);
+p = (t)skb_put_zero(skb, len);
johannes
On Wed, 2017-06-14 at 22:30 +0800, yuan linyu wrote:
> From: yuan linyu
>
>
> yuan linyu (11):
> ipv6: skb_put_zero() used to optimize code
> ipv4: skb_put_zero() used to optimize code
> ncsi: skb_put_zero() used to optimize code
> dsa: skb_put_zero() used to optimize code
> key: skb_p
From: Johannes Berg
There are no longer any drivers (in the tree proper, I didn't
check all the staging drivers) that take WEXT ioctls through
this API, the only remaining ones that even have ndo_do_ioctl
are using it only for private ioctls.
Therefore, we can remove this call.
Signed-o
From: Johannes Berg
To make it clear that we never use struct ifreq, cast from it
directly in the wext entrypoint and use struct iwreq from there
on. The next patch will remove the cast again and pass the
correct struct from the beginning.
Signed-off-by: Johannes Berg
---
net/wireless/wext
Robert O'Callahan reported that since struct iwreq is smaller than
struct ifreq, if it happens to land at the end of a mapped section
userspace will erroneously get -EFAULT.
Bug report is https://bugzilla.kernel.org/show_bug.cgi?id=195869.
This bug is ancient, it kernel 2.1.15 was the first to co
From: Johannes Berg
Unfortunately, struct iwreq isn't a proper subset of struct ifreq,
but is still handled by the same code path. Robert reported that
then applications may (randomly) fault if the struct iwreq they
pass happens to land within 8 bytes of the end of a mapping (the
struct is
From: Johannes Berg
Use the recently introduced helper to replace the pattern of
skb_put() && memset(), this transformation was done with the
following spatch:
@@
identifier p;
expression len;
expression skb;
@@
-p = skb_put(skb, len);
-memset(p, 0, len);
+p = skb_put_zero(skb, len);
cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK
Emmanuel Grumbach (1):
mac80211: add the action to the drv_ampdu_action tracepoint
Johannes Berg (5):
cfg80211: improve warnings in VHT rate calculation
mac80211: move clearing result into ieee80211_parse_ch_swi
mac80211: Fix incorrect condition when checking rx timestamp
Emmanuel Grumbach (2):
mac80211: don't look at the PM bit of BAR frames
mac80211: don't send SMPS action frame in AP mode when not needed
Jason A. Donenfeld (1):
mac80211/wpa: use constant time memory comp
On Sat, 2017-06-10 at 22:10 +0300, Andy Shevchenko wrote:
> Switch to use managed variant of acpi_dev_add_driver_gpios() to
> simplify
> error path and fix potentially wrong assingment if ->probe() fails.
>
Looks fine, applied.
johannes
From: Johannes Berg
The change to remove free_netdev() from ieee80211_if_free()
erroneously didn't add the necessary free_netdev() for when
ieee80211_if_free() is called directly in one place, rather
than as the priv_destructor. Add the missing call.
Fixes: cf124db566e6 ("net: Fix in
On Fri, 2017-06-09 at 10:17 -0400, David Miller wrote:
>
> > I guess this must mean that that all others are dealing with the
> > problem "manually", right? Perhaps needs_free_netdev isn't all that
> > necessary then?
>
> Yeah, the major two modes of operation are manual freeing of the
> netdev (
Hi Dave,
I hope you don't mind a question or two for my understanding here.
Actually, this got pretty long... but I think there's a bug in here.
(For background, I'm looking into this because I'm interested in what
to do about backporting this to older kernels, or better, how to deal
with it in
On Thu, 2017-06-08 at 14:10 +0200, Johannes Berg wrote:
> Hi Dave,
>
> Could you do me a favour and merge net into net-next? I want to merge
> that back in order to apply a patch to mac80211-next that otherwise
> conflicts fairly badly with a change in mac80211.
Wait, forget it.
Hi Dave,
Could you do me a favour and merge net into net-next? I want to merge
that back in order to apply a patch to mac80211-next that otherwise
conflicts fairly badly with a change in mac80211.
Thanks!
johannes
tion start/stop callback races by setting
bits instead of allocating and queueing an skb
----
Johannes Berg (2):
mac80211: fix TX aggregation start/stop callback race
mac80211: fix dropped counter in multiqueue RX
net/ma
Hi,
> The issue here is that line 56 implies that pointer tfm_michael
> might be NULL. If this is the case, there is a potential NULL
> pointer dereference at line 52 once pointer tfm_michael is
> indirectly dereferenced inside macro SHASH_DESC_ON_STACK().
>
> My question is if there is any chanc
On Wed, 2017-05-17 at 08:22 -0700, Ben Greear wrote:
>
> I saw it exactly once so far, and it happened overnight,
> but we have not been doing a lot of work with the 4.9 kernel until
> recently.
>
> I don't think there were many messages on this system, and certainly
> others have run much longer
On Sat, 2017-05-27 at 14:59 -0700, Bjorn Andersson wrote:
> ieee80211_tx_status() is only one of the possible ways a driver can
> report a handled packet, some drivers call this for every packet
> while
> others calls it rarely or never.
>
> In order to invoke the TX LED in the non-status reportin
On Thu, 2017-05-25 at 13:01 -0400, David Miller wrote:
> From: Johannes Berg
> Date: Wed, 24 May 2017 09:07:47 +0200
>
> > From: Johannes Berg
> >
> > This pattern was introduced a number of times in mac80211 just now,
> > and since it's present in a
From: Johannes Berg
This pattern was introduced a number of times in mac80211 just now,
and since it's present in a number of other places it makes sense
to add a little helper for it.
The transformations of all code were done with the following spatch:
@@
identifier p;
expressio
Hi Dave,
I have just two fixes here, one of the scheduled scan issue that
Sander Eikelenboom found, and the other properly makes mesh more
strictly check its extension headers.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 29cee56c0be4
On Tue, 2017-05-23 at 09:19 +0200, Arend Van Spriel wrote:
>
> > WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held());
>
> Thought about something like this after sending the email. So there
> are two call sites. One for scheduled scan results notification and
> one in scheduled sca
Hi Arend,
Sorry, I forgot that the original message wasn't Cc'ed to the wireless
list, only netdev.
> +++ b/net/wireless/scan.c
> @@ -322,9 +322,7 @@ static void cfg80211_del_sched_scan_req(struct
> cfg80211_regi
> {
> struct cfg80211_sched_scan_request *pos;
>
> - ASSERT_RTNL();
On Mon, 2017-05-22 at 18:19 +0200, Johannes Berg wrote:
>
> I'm not really all that convinced that we really need this -
> userspace should just be using the flush thing more often, and then
> it doesn't really matter.
>
> However, maybe that doesn't really m
> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
> create its own list? Given that the kernel provides the information
> userspace needs to figure out the age of a particular BSS, it doesn't
> seem like there needs to be a kernel tunable for this. Userspace can
> already a
On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote:
> The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in
> the
> past. Initially was set at 10 seconds (2a51931192), then increased at
> 15
> seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover
> the
> u
On Mon, 2017-05-22 at 12:36 +0200, Sander Eikelenboom wrote:
> Hi,
>
> I encountered this splat with 4.12-RC2.
Ugh, yeah, I should've seen that in the review.
Arend, please take a look at this. cfg80211_sched_scan_results() cannot
sleep, so you can't rtnl_lock() in there. Looks like you can just
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote:
>
> It seems very important to a lot of people...
I get blinking, I guess, but I don't get toggling for every packet :)
The throughput thing we did in iwlwifi seems like a so much better
idea. Not that it really matters for this discussion
On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
> * Ben Greear [17.05.2017 11:51]:
> > I have been keeping an 'iw events' program running with a perl
> > script gathering its
> > output and post-processing it. This has been working for several
> > years on 4.7 and earlier
> > kernels, b
On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote:
> On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> >
> > > > In fact, why should the *driver* care either? IOW - why should
> > > > &quo
On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
>
> > > This code intentionally checked if TX status was requested, and
> > > if not then it doesn't go to the effort of building it.
> > >
> >
> > What I'm finding puzzling is the fact that the only caller of
> > ieee80211_led_tx() is ieee802
On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
>
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package.
[...]
Oh,
On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > Now for N900 case there is a similar scenario
> > > alhtough it has additional requirement to go to user-space due to
> > > need to use a proprietary library to obtain the NVS calibration
> > > data. My thought: Why should firmware_c
On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote:
>
> In rt2x00 driver we use poor convention in other kind of registers
> accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
> accessors and leaving others in the old way. And changing all
> accessors would be massive and er
On Sun, 2017-05-14 at 16:14 -0600, David Ahern wrote:
> On 5/14/17 3:00 PM, Johannes Berg wrote:
> > On Sat, 2017-05-13 at 19:29 +0200, Jan Moskyto Matejka wrote:
> > >
> > > > When adding a route to the skb, track whether it contains at
> > > > least
>
On Sat, 2017-05-13 at 19:29 +0200, Jan Moskyto Matejka wrote:
>
> > When adding a route to the skb, track whether it contains at least
> > 1
> > route. If not, it means the next route in the dump is larger than
> > the
> > given buffer. Detect this condition and error out of the dump -
> > returni
On Tue, 2017-05-09 at 15:50 +0200, Jason A. Donenfeld wrote:
> The recent bug with macsec and historical one with virtio have
> indicated that letting skb_to_sgvec trounce all over an sglist
> without checking the length is probably a bad idea. And it's not
> necessary either: an sglist already exp
On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 8 May 2017 22:22:04 +0200
>
> Five single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
Please stop, this isn't really an issue worth worryi
for a recently merged change
* fix MU-MIMO group configuration (relevant only for monitor mode)
* more rate flags fix: remove stray RX_ENC_FLAG_40MHZ
* fix IBSS probe response allocation size
----
Johannes Berg (4):
mac80211:
> +static inline bool netif_is_lwd(struct net_device *dev)
> +{
> + return !!(dev->priv_flags & IFF_LWT_NETDEV);
> +}
Am I the only one who thinks that this "LWT_NETDEV" vs "LWD" is a bit
confusing?
Is "netif_is_lwt_netdev()" really too long?
johannes
On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > o Use explicit casts to proper types instead of casts to (void *)
> > > and have the compiler do the implicit cast
> >
> > I see no advantage
> o Use explicit casts to proper types instead of casts to (void *)
> and have the compiler do the implicit cast
I see no advantage in this, why? All it does is make the code longer,
and if anything changes, you have to change it in multiple places now.
johannes
On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
>
> Johannes, would you like me to merge this in via my tree directly?
I figured I'd give Linus to a chance to try or even apply it, but I
have no objection to you applying it either. I don't have anything else
yet right now, and sending a
From: Johannes Berg
Due to the way I did the RX bitrate conversions in mac80211 with
spatch, going setting flags to setting the value, many drivers now
don't set the bandwidth value for 20 MHz, since with the flags it
wasn't necessary to (there was no 20 MHz flag, only the others.)
R
Hi,
> Things still work, but when it starts warning, it generates a *lot*
> of noise (I got 36 of these within about ten minutes).
Yeah, that's kinda dumb - I just sent a patch to make that just warn
once and actually report the configuration.
> I have no idea what triggered it, because when I r
as suggested.
>
> References: https://www.spinics.net/lists/netdev/msg433267.html
> Signed-off-by: Daniel Borkmann
I did wonder about the whole _TRY_ thing. LGTM
Reviewed-by: Johannes Berg
johannes
ement frames in ieee80211_frame_acked
Felix Fietkau (3):
mac80211: make rate control tx status API more extensible
mac80211: move ieee80211_tx_status_noskb below ieee80211_tx_status
mac80211: add ieee80211_tx_status_ext
Johannes Berg (8):
mac80211: rewrite monitor mode
> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
> struct wcn36xx_dxe_ch *ch)
> info = IEEE80211_SKB_CB(ctl->skb);
> if (!(info->flags &
> IEEE80211_TX_CTL_REQ_TX_STATUS)) {
> /* Keep frame until TX status
On Tue, 2017-04-25 at 13:53 -0700, Jakub Kicinski wrote:
> On Tue, 25 Apr 2017 10:13:34 +0200, Johannes Berg wrote:
> > On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote:
> >
> > > +#define NL_SET_ERR_MSG(extack, msg) do { \
> > > + struct n
On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote:
> +#define NL_SET_ERR_MSG(extack, msg) do { \
> + struct netlink_ext_ack *_extack = (extack); \
> + static const char _msg[] = (msg); \
> + \
> + i
This is not a cfg80211 patch, please resend with the correct subject.
Thanks,
johannes
From: Johannes Berg
AP/AP_VLAN modes don't accept any real 802.11 multicast data
frames, but since they do need to accept broadcast management
frames the same is currently permitted for data frames. This
opens a security problem because such frames would be decrypted
with the GTK, and could
On Thu, 2017-04-20 at 16:46 +0200, Daniel Borkmann wrote:
> > Hmm. I don't see what "somewhere else" I could possibly have
> > though, given that I want the (kernel-side) context to be "struct
> > sk_buff *" to allow the skb helpers?
>
> I have not enough context on the wireless side, perhaps coul
On Thu, 2017-04-20 at 16:28 +0200, Daniel Borkmann wrote:
>
> I see what you mean now. Yes, that's fine. We already do something
> similar essentially with skb->ifindex access already (skb->dev +
> dev->ifindex), f.e.:
>
> [...]
> case offsetof(struct __sk_buff, ifindex):
> BU
On Thu, 2017-04-20 at 16:10 +0200, Daniel Borkmann wrote:
>
> I think this would be a rather more complex operation on the BPF
> side, it would need changes from LLVM (which assumes initial ctx sits
> in r1), verifier for tracking this ctx2, all the way down to JITs
> plus some way to handle 1 and
On Wed, 2017-04-19 at 23:55 -0700, Stefan Agner wrote:
> Use type enum nl80211_rate_info for bitrate information. This fixes
> a warning when compiling with clang:
> warning: implicit conversion from enumeration type 'enum
> nl80211_rate_info'
> to different enumeration type 'enum nl80211_attrs
On Thu, 2017-04-20 at 02:38 +0200, Daniel Borkmann wrote:
> > Since wifi skbs have only eth in headlen, there is not much
> > pointing adding support for data/data_end to wifi.
> > Just use ld_abs/ld_ind instructions and load_bytes() helper.
>
> Afaik, the ld_abs/ld_ind are not an option due to t
On Wed, 2017-04-19 at 17:12 -0700, Alexei Starovoitov wrote:
>
> also didn't we discuss that wifi has crazy non-linear skb?
Not always, depends on the driver.
But also, you have to remember that this filter would be before the
conversion to Ethernet header. Right now, when packets enter the stac
On Thu, 2017-04-20 at 02:01 +0200, Daniel Borkmann wrote:
>
> Yeah, should work as well for the 32 bit archs, on 64 bit we
> have this effectively already:
Right.
[...]
> Can you elaborate on why this works for mac80211? It uses cb
> only up to that point from where you invoke the prog?
No, it
On Wed, 2017-04-19 at 23:31 +0200, Johannes Berg wrote:
> Hi Alexei, Daniel,
>
> I'm looking at adding the __wifi_sk_buff I talked about, and I notice
> that it uses CB space to store data_end. Unfortunately, in a lot of
> cases, we don't have any CB space to spare in
Hi Alexei, Daniel,
I'm looking at adding the __wifi_sk_buff I talked about, and I notice
that it uses CB space to store data_end. Unfortunately, in a lot of
cases, we don't have any CB space to spare in wifi.
Is there any way to generate a series of instructions that instead does
the necessary ca
So actually, come to think of it ...
> > The mapping in samples/bpf/bpf_helpers.h, for example, for
> > mentioned
> > bpf_skb_load_bytes() would also work out of the box, since it takes
> > a
> > void *ctx as an argument, so you can just pass the __wifi_sk_buff
> > pointer as ctx there from progra
On Tue, 2017-04-18 at 12:58 +0200, Daniel Borkmann wrote:
>
> Note that for skbs the data / data_end model (aka direct read /
> write) is also supported. There's also a bpf_skb_pull_data() helper
> that pulls in data from non-linear parts if necessary (f.e. if data /
> data_end test in the program
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
>
> so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I prefer to have the SKB so that skb data
access
On Fri, 2017-04-14 at 12:41 -0700, Alexei Starovoitov wrote:
>
> ahh. i thought all drivers do at least copy-break (256) bytes
We do copy-break, but that's only applicable when there's no non-linear
data left afterwards :)
> or copy
> get_headlen or build_skb the whole thing.
> Since wireless
On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote
(something that never made it to the list, due to HTML formatting)
>
> I think that OVS was doing some more elaborate validation than most
> users, so over time we picked up a bunch of extra parsing code that
> layers on top of nla_parse(). I t
mac80211-hwsim: remove dmesg spam about get-survey.
Johannes Berg (24):
cfg80211: combine two nested ifs into a single condition
ieee80211: rename CCFS1/CCFS2 to CCFS0/CCFS1
mac80211: remove local pointer from rate_ctrl_ref
cfg80211: refactor cfg80211_ca
On Mon, 2017-04-17 at 15:59 -0700, Matthias Kaehlcke wrote:
> rate_flg is of type 'enum nl80211_attrs', however it is assigned with
> 'enum nl80211_rate_info' values. Change the type of rate_flg
> accordingly.
Applied this, and the other two patches you had (IBSS enum and array-
bounds)
johannes
ch is the case
for the only driver supporting this - iwlwifi.
----
Johannes Berg (1):
mac80211: fix MU-MIMO follow-MAC mode
net/mac80211/rx.c | 65 ---
1 file changed, 47 insertions(+), 18 deletions(-)
On Fri, 2017-04-14 at 11:42 -0700, Alexei Starovoitov wrote:
> bpf takes endianness of the cpu it runs on.
Ok, so then things are actually not as difficult as I thought.
> if we said that bpf 32-bit load insn is little endian, it would have
> screwed up all big-endian archs and the other way aro
On Thu, 2017-04-13 at 16:01 -0400, David Miller wrote:
> From: Johannes Berg
> Date: Thu, 13 Apr 2017 21:22:21 +0200
>
> > OTOH, it might depend on the frame data itself, if the program does
> > something like
> >
> > xdp->data[xdp->data[0] & 0xf]
>
On Thu, 2017-04-13 at 16:05 +0200, Nicolas Dichtel wrote:
> Sure. It was just to mention that attribute 0 exists somewhere.
> The other 0 attribute is OVS_TUNNEL_KEY_ATTR_ID.
That looks like some really awkward hand-grown parsing - with all these
"struct ovs_len_tbl" looking almost like a policy,
On Thu, 2017-04-13 at 11:37 -0400, David Miller wrote:
> If the capability is variable, it must be communicated to the user
> somehow at program load time.
>
> We are consistently finding that there is this real need to
> communicate XDP capabilities, or somehow verify that the needs
> of an XDP
On Thu, 2017-04-13 at 15:27 +0200, Nicolas Dichtel wrote:
>
> > Yes, some - very few - families still insist on using attribute 0,
> > perhaps parsing by hand or so. Like you say though, the entire
> > infrastructure makes that hard and undesirable, so I don't really
> > see
> > why we need to inv
On Thu, 2017-04-06 at 16:31 -0700, Matthias Kaehlcke wrote:
> When clang detects a non-boolean constant in a logical operation it
> generates a 'constant-logical-operand' warning. In
> ieee80211_try_rate_control_ops_get() the result of strlen( str>)
> is used in a logical operation, clang resolves
On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote:
> > + if (skb_linearize(skb))
> > + goto do_drop;
>
> when we discussed supporting jumbo frames in XDP, the idea
> was that the program would need to look at first 3+k bytes only
> and the rest of the packet will be in non-c
> @@ -551,6 +551,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
> priv_data_len,
> NL80211_FEATURE_FULL_AP_CLIENT_STATE;
> wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_FILS_STA);
>
> + if (IS_ENABLED(CONFIG_BPF_WIFIMON))
> + wiphy_ext_fe
On Wed, 2017-04-12 at 20:08 -0700, Alexei Starovoitov wrote:
> it's really llvm bug that i need fix. It's plain broken
> to generate what effectively is nop insn for march=bpfeb
> My only excuse that when that code was written llvm had only
> march=bpfel.
> bpfeb was added much later.
So I'm conf
On Wed, 2017-04-12 at 09:58 -0700, Alexei Starovoitov wrote:
>
> > Are these hooked up to llvm intrinsics or so? If not, can I do that
> > through some kind of inline asm statement?
>
> llvm doesn't support bpf inline asm yet.
Ok.
> > In the samples, I only see people doing
> >
> > #define _ht
On Wed, 2017-04-12 at 11:19 -0400, David Miller wrote:
>
> > Instead it may make more sense to just have a "wifi_info(skb,
> info)"
> > function you can call, e.g. with a structure that has various
> fields
> > and flags to see which you care about.
>
> I would advise against this, let the parsin
On Wed, 2017-04-12 at 11:22 -0400, David Miller wrote:
> From: Johannes Berg
> Date: Wed, 12 Apr 2017 16:29:07 +0200
>
> > On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> >>
> >> struct ieee80211_if_mntr {
> >> u32 flags;
> >>
On Wed, 2017-04-12 at 09:06 -0600, David Ahern wrote:
>
> There was a discussion about side effects of adding strings (bloat,
> internationalization). Should ATTR_MSG be removed until that is
> ironed out? Leaving it in suggests it is ok to start adding strings.
I really do want the strings; this
On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
>
> struct ieee80211_if_mntr {
> u32 flags;
>
[...]
+ bool deliver;
That's ... broken for multi-queue RX. I haven't really found a good
other way to do it. The best way will likely be to copy the SKB the
On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> Add a new program type for wifi monitor interfaces. This program
> type can
> * access __sk_buff, but only skb->len
> * call bpf_skb_load_bytes()
>
> The program type is only enabled
601 - 700 of 1980 matches
Mail list logo
