* Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 21:09 UTC (permalink / raw)
To: Daniel Micay
Cc: kernel-hardening, Jean-Philippe Aumasson, George Spelvin,
Andi Kleen, David Miller, David Laight, Eric Biggers,
Hannes Frederic Sowa, Linux Crypto Mailing List, LKML,
Andy Lutomirski, Netdev, Linus Torvalds, Theodore Ts'o,
Vegard Nossum, Daniel J . Bernstein
In-Reply-To: <1481921067.1054.6.camel@gmail.com>
Hi Daniel,
On Fri, Dec 16, 2016 at 9:44 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote:
>>
>> That's about 3x of jhash speed (7 nsecs). So that might closer
>> to a more palatable replacement for jhash. Do we lose any security
>> advantages with halfsiphash?
>
> Have you tested a lower round SipHash? Probably best to stick with the
> usual construction for non-DoS mitigation, but why not try SipHash 1-3,
> 1-2, etc. for DoS mitigation?
>
> Rust and Swift both went with SipHash 1-3 for hash tables.
Maybe not a bad idea.
SipHash2-4 for MD5 replacement, as we've done so far. This is when we
actually want things to be secure (and fast).
And then HalfSipHash1-3 for certain jhash replacements. This is for
when we're talking only about DoS or sort of just joking about
security, and want things to be very competitive with jhash. (Of
course for 64-bit we'd use SipHash1-3 instead of HalfSipHash for the
speedup.)
I need to think on this a bit more, but preliminarily, I guess this
would be maybe okay...
George, JP - what do you think?
Jason
^ permalink raw reply
* Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 21:01 UTC (permalink / raw)
To: kernel-hardening, Theodore Ts'o, George Spelvin, Jason,
Andi Kleen, David Miller, David Laight, Daniel J . Bernstein,
Eric Biggers, Hannes Frederic Sowa, Jean-Philippe Aumasson,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Tom Herbert, Linus Torvalds, Vegard Nossum
Hi Ted,
On Fri, Dec 16, 2016 at 9:43 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> What should we do with get_random_int() and get_random_long()? In
> some cases it's being used in performance sensitive areas, and where
> anti-DoS protection might be enough. In others, maybe not so much.
>
> If we rekeyed the secret used by get_random_int() and
> get_random_long() frequently (say, every minute or every 5 minutes),
> would that be sufficient for current and future users of these
> interfaces?
get_random_int() and get_random_long() should quite clearly use
SipHash with its secure 128-bit key and not HalfSipHash with its
64-bit key. HalfSipHash is absolutely insufficient for this use case.
Remember, we're already an order of magnitude or more faster than
md5...
With regard to periodic rekeying... since the secret is 128-bits, I
believe this is likely sufficient for _not_ rekeying. There's also the
chaining variable, to tie together invocations of the function. If
you'd prefer, instead of the chaining variable, we could use some
siphash output to mutate the original key, but I don't think this
approach is actually better and might introduce vulnerabilities. In my
opinion chaining+128bitkey is sufficient. On the other hand, rekeying
every X minutes is 3 or 4 lines of code. If you want (just say so),
I'll add this to my next revision.
You asked about the security requirements of these functions. The
comment says they're not cryptographically secure. And right now with
MD5 they're not. So the expectations are pretty low. Moving to siphash
adds some cryptographic security, certainly. Moving to siphash plus
rekeying adds a bit more. Of course, on recent x86, RDRAND is used
instead, so the cryptographic strength then depends on the thickness
of your tinfoil hat. So probably we shouldn't change what we advertise
these functions provide, even though we're certainly improving them
performance-wise and security-wise.
> P.S. I'll note that my performance figures when testing changes to
> get_random_int() were done on a 32-bit x86; Jason, I'm guessing your
> figures were using a 64-bit x86 system?. I haven't tried 32-bit ARM
> or smaller CPU's (e.g., mips, et. al.) that might be more likely to be
> used on IoT devices, but I'm worried about those too, of course.
Yes, on x86-64. But on i386 chacha20 incurs nearly the same kind of
slowdown as siphash, so I expect the comparison to be more or less
equal. There's another thing I really didn't like about your chacha20
approach which is that it uses the /dev/urandom pool, which means
various things need to kick in in the background to refill this.
Additionally, having to refill the buffered chacha output every 32 or
so longs isn't nice. These things together make for inconsistent and
hard to understand general operating system performance, because
get_random_long is called at every process startup for ASLR. So, in
the end, I believe there's another reason for going with the siphash
approach: deterministic performance.
Jason
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Tom Herbert @ 2016-12-16 20:57 UTC (permalink / raw)
To: George Spelvin
Cc: Jason A. Donenfeld, Andi Kleen, David S. Miller, David Laight,
Daniel J . Bernstein, Eric Biggers, Hannes Frederic Sowa,
Jean-Philippe Aumasson, kernel-hardening,
Linux Crypto Mailing List, LKML, Andy Lutomirski,
Linux Kernel Network Developers, Linus Torvalds,
Theodore Ts'o, vegard.nossum
In-Reply-To: <20161216204128.25034.qmail@ns.sciencehorizons.net>
On Fri, Dec 16, 2016 at 12:41 PM, George Spelvin
<linux@sciencehorizons.net> wrote:
> Tom Herbert wrote:
>> Tested this. Distribution and avalanche effect are still good. Speed
>> wise I see about a 33% improvement over siphash (20 nsecs/op versus 32
>> nsecs). That's about 3x of jhash speed (7 nsecs). So that might closer
>> to a more palatable replacement for jhash. Do we lose any security
>> advantages with halfsiphash?
>
> What are you testing on? And what input size? And does "33% improvement"
> mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate?
>
Sorry, that is over an IPv4 tuple. Intel(R) Xeon(R) CPU E5-2660 0 @
2.20GHz. Recoded the function I was using to look like more like 64
bit version and yes it is indeed slower.
> These are very odd results. On a 64-bit machine, SipHash should be the
> same speed per round, and faster because it hashes more data per round.
> (Unless you're hitting some unexpected cache/decode effect due to REX
> prefixes.)
>
> On a 32-bit machine (other than ARM, where your results might make sense,
> or maybe if you're hashing large amounts of data), the difference should
> be larger.
>
> And yes, there is a *significant* security loss. SipHash is 128 bits
> ("don't worry about it"). hsiphash is 64 bits, which is known breakable
> ("worry about it"), so we have to do a careful analysis of the cost of
> a successful attack.
>
> As mentioned in the e-mails that just flew by, hsiphash is intended
> *only* for 32-bit machines which bog down on full SipHash. On all 64-bit
> machines, it will be implemented as an alias for SipHash and the security
> concerns will Just Go Away.
>
> The place where hsiphash is expected to make a big difference is 32-bit
> x86. If you only see 33% difference with "gcc -m32", I'm going to be
> very confused.
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 20:49 UTC (permalink / raw)
To: George Spelvin
Cc: Andi Kleen, David Miller, David Laight, Daniel J . Bernstein,
Eric Biggers, Hannes Frederic Sowa, Jean-Philippe Aumasson,
kernel-hardening, Linux Crypto Mailing List, LKML,
Andy Lutomirski, Netdev, Tom Herbert, Linus Torvalds,
Theodore Ts'o, Vegard Nossum
On Fri, Dec 16, 2016 at 9:17 PM, George Spelvin
<linux@sciencehorizons.net> wrote:
> My (speaking enerally; I should walk through every hash table you've
> converted) opinion is that:
>
> - Hash tables, even network-facing ones, can all use hsiphash as long
> as an attacker can only see collisions, i.e. ((H(x) ^ H(y)) & bits) ==
> 0, and the consequences of a successful attack is only more collisions
> (timing). While the attack is only 2x the cost (two hashes rather than
> one to test a key), the knowledge of the collision is statistical,
> especially for network attackers, which raises the cost of guessing
> beyond an even more brute-force attack.
> - When the hash value directly visible (e.g. included in a network
> packet), full SipHash should be the default.
> - Syncookies *could* use hsiphash, especially as there are
> two keys in there. Not sure if we need the performance.
> - For TCP ISNs, I'd prefer to use full SipHash. I know this is
> a very hot path, and if that's a performance bottleneck,
> we can work harder on it.
>
> In particular, TCP ISNs *used* to rotate the key periodically,
> limiting the time available to an attacker to perform an
> attack before the secret goes stale and is useless. commit
> 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upgraded to md5 and dropped
> the key rotation.
While I generally agree with this analysis for the most part, I do
think we should use SipHash and not HalfSipHash for syncookies.
Although the security risk is lower than with sequence numbers, it
previously used full MD5 for this, which means performance is not
generally a bottleneck and we'll get massive speedups no matter what,
whether using SipHash or HalfSipHash. In addition, using SipHash means
that the 128-bit key gives a larger margin and can be safe longterm.
So, I think we should err on the side of caution and stick with
SipHash in all cases in which we're upgrading from MD5.
In other words, only current jhash users should be potentially
eligible for hsiphash.
> Current code uses a 64 ns tick for the ISN, so it counts 2^24 per second.
> (32 bits wraps every 4.6 minutes.) A 4-bit counter and 28-bit hash
> (or even 3+29) would work as long as the key is regenerated no more
> than once per minute. (Just using the 4.6-minute ISN wrap time is the
> obvious simple implementation.)
>
> (Of course, I defer to DaveM's judgement on all network-related issues.)
I saw that jiffies addition in there and was wondering what it was all
about. It's currently added _after_ the siphash input, not before, to
keep with how the old algorithm worked. I'm not sure if this is
correct or if there's something wrong with that, as I haven't studied
how it works. If that jiffies should be part of the siphash input and
not added to the result, please tell me. Otherwise I'll keep things
how they are to avoid breaking something that seems to be working.
^ permalink raw reply
* Re: [net-next PATCH v6 0/5] XDP for virtio_net
From: Michael S. Tsirkin @ 2016-12-16 20:48 UTC (permalink / raw)
To: David Miller
Cc: john.fastabend, daniel, netdev, alexei.starovoitov,
john.r.fastabend, brouer, tgraf
In-Reply-To: <20161216.132002.2295377318615583719.davem@davemloft.net>
On Fri, Dec 16, 2016 at 01:20:02PM -0500, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Fri, 16 Dec 2016 01:17:44 +0200
>
> > OK, I think we can queue this for -next.
> >
> > It's fairly limited in the kind of hardware supported, we can and
> > probably should extend it further with time.
> >
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> Michael, thanks for reviewing.
>
> Since the substance of this patch series has honestly been ready since
> before the merge window, would you mind if I send this to Linus now?
>
> That's what I was hoping I would be able to do.
>
> Thanks again.
ACK, no problem.
BTW in case people wonder, I'll be offline for a couple of weeks.
This might delay review of some patches a bit.
--
MST
^ permalink raw reply
* Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Daniel Micay @ 2016-12-16 20:44 UTC (permalink / raw)
To: kernel-hardening, Jason A. Donenfeld
Cc: Jean-Philippe Aumasson, George Spelvin, Andi Kleen, David Miller,
David Laight, Eric Biggers, Hannes Frederic Sowa,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Linus Torvalds, Theodore Ts'o, vegard.nossum,
Daniel J . Bernstein
In-Reply-To: <CALx6S351VFRZmEQphRQy6YtmZYPnOtTN7=XiNrJmhWJGv4HUBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote:
>
> That's about 3x of jhash speed (7 nsecs). So that might closer
> to a more palatable replacement for jhash. Do we lose any security
> advantages with halfsiphash?
Have you tested a lower round SipHash? Probably best to stick with the
usual construction for non-DoS mitigation, but why not try SipHash 1-3,
1-2, etc. for DoS mitigation?
Rust and Swift both went with SipHash 1-3 for hash tables.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Theodore Ts'o @ 2016-12-16 20:43 UTC (permalink / raw)
To: George Spelvin
Cc: Jason, ak, davem, David.Laight, djb, ebiggers3, hannes,
jeanphilippe.aumasson, kernel-hardening, linux-crypto,
linux-kernel, luto, netdev, tom, torvalds, vegard.nossum
In-Reply-To: <20161216201739.24567.qmail@ns.sciencehorizons.net>
On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote:
> > That's a nice analysis. Might one conclude from that that hsiphash is
> > not useful for our purposes? Or does it still remain useful for
> > network facing code?
>
> I think for attacks where the threat is a DoS, it's usable. The point
> is you only have to raise the cost to equal that of a packet flood.
> (Just like in electronic warfare, the best you can possibly do is force
> the enemy to use broadband jamming.)
>
> Hash collision attacks just aren't that powerful. The original PoC
> was against an application that implemented a hard limit on hash chain
> length as a DoS defense, which the attack then exploited to turn it into
> a hard DoS.
What should we do with get_random_int() and get_random_long()? In
some cases it's being used in performance sensitive areas, and where
anti-DoS protection might be enough. In others, maybe not so much.
If we rekeyed the secret used by get_random_int() and
get_random_long() frequently (say, every minute or every 5 minutes),
would that be sufficient for current and future users of these
interfaces?
- Ted
P.S. I'll note that my performance figures when testing changes to
get_random_int() were done on a 32-bit x86; Jason, I'm guessing your
figures were using a 64-bit x86 system?. I haven't tried 32-bit ARM
or smaller CPU's (e.g., mips, et. al.) that might be more likely to be
used on IoT devices, but I'm worried about those too, of course.
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 20:43 UTC (permalink / raw)
To: George Spelvin
Cc: Tom Herbert, Andi Kleen, David Miller, David Laight,
Daniel J . Bernstein, Eric Biggers, Hannes Frederic Sowa,
Jean-Philippe Aumasson, kernel-hardening,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Linus Torvalds, Theodore Ts'o, Vegard Nossum
On Fri, Dec 16, 2016 at 9:41 PM, George Spelvin
<linux@sciencehorizons.net> wrote:
> What are you testing on? And what input size? And does "33% improvement"
> mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate?
How that I've published my hsiphash implementation to my tree, it
should be possible to conduct the tests back to back with nearly
identical implementation strategies, to remove a potential source of
error.
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: George Spelvin @ 2016-12-16 20:41 UTC (permalink / raw)
To: Jason, tom
Cc: ak, davem, David.Laight, djb, ebiggers3, hannes,
jeanphilippe.aumasson, kernel-hardening, linux-crypto,
linux-kernel, linux, luto, netdev, torvalds, tytso, vegard.nossum
In-Reply-To: <CALx6S351VFRZmEQphRQy6YtmZYPnOtTN7=XiNrJmhWJGv4HUBg@mail.gmail.com>
Tom Herbert wrote:
> Tested this. Distribution and avalanche effect are still good. Speed
> wise I see about a 33% improvement over siphash (20 nsecs/op versus 32
> nsecs). That's about 3x of jhash speed (7 nsecs). So that might closer
> to a more palatable replacement for jhash. Do we lose any security
> advantages with halfsiphash?
What are you testing on? And what input size? And does "33% improvement"
mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate?
These are very odd results. On a 64-bit machine, SipHash should be the
same speed per round, and faster because it hashes more data per round.
(Unless you're hitting some unexpected cache/decode effect due to REX
prefixes.)
On a 32-bit machine (other than ARM, where your results might make sense,
or maybe if you're hashing large amounts of data), the difference should
be larger.
And yes, there is a *significant* security loss. SipHash is 128 bits
("don't worry about it"). hsiphash is 64 bits, which is known breakable
("worry about it"), so we have to do a careful analysis of the cost of
a successful attack.
As mentioned in the e-mails that just flew by, hsiphash is intended
*only* for 32-bit machines which bog down on full SipHash. On all 64-bit
machines, it will be implemented as an alias for SipHash and the security
concerns will Just Go Away.
The place where hsiphash is expected to make a big difference is 32-bit
x86. If you only see 33% difference with "gcc -m32", I'm going to be
very confused.
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-16 20:39 UTC (permalink / raw)
To: Jean-Philippe Aumasson
Cc: George Spelvin, Andi Kleen, David Miller, David Laight,
Eric Biggers, Hannes Frederic Sowa, kernel-hardening,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Tom Herbert, Linus Torvalds, Theodore Ts'o, Vegard Nossum,
Daniel J . Bernstein
In-Reply-To: <CAGiyFddB_HT3H2yhYQ5rprYZ487rJ4iCaH9uPJQD57hiPbn9ng@mail.gmail.com>
Hi JP,
On Fri, Dec 16, 2016 at 2:22 PM, Jean-Philippe Aumasson
<jeanphilippe.aumasson@gmail.com> wrote:
> It needs some basic security review, which I'll try do next week (check for
> security margin, optimality of rotation counts, etc.). But after a lot of
> experience with this kind of construction (BLAKE, SipHash, NORX), I'm
> confident it will be safe as it is.
I've implemented it in my siphash kernel branch:
https://git.zx2c4.com/linux-dev/log/?h=siphash
It's the commit that has "HalfSipHash" in the log message. As the
structure is nearly identical to SipHash, there wasn't a lot to
change, and so the same implementation strategy exists for each.
When you've finished your security review and feel good about it, some
test vectors using the same formula (key={0x03020100, 07060504},
input={0x0, 0x1, 0x2, 0x3...}, output=test_vectors) would be nice for
verification.
Jason
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: George Spelvin @ 2016-12-16 20:17 UTC (permalink / raw)
To: Jason, linux
Cc: ak, davem, David.Laight, djb, ebiggers3, hannes,
jeanphilippe.aumasson, kernel-hardening, linux-crypto,
linux-kernel, luto, netdev, tom, torvalds, tytso, vegard.nossum
In-Reply-To: <CAHmME9pe39s5FWxfKNiRKkHnEO-9v2yLcEQc8rnMC89P6roTmA@mail.gmail.com>
>> On a 64-bit machine, 64-bit SipHash is *always* faster than 32-bit, and
>> should be used always. Don't even compile the 32-bit code, to prevent
>> anyone accidentally using it, and make hsiphash an alias for siphash.
> Fascinating! Okay. So I'll alias hsiphash to siphash on 64-bit then. I
> like this arrangement.
This is a basic assumption I make in the security analysis below:
on most machines, it's 128-bit-key SipHash everywhere and we can
consider security solved.
Our analysis *only* has to consider 32-bit machines. My big concern
is home routers, with IoT appliances coming second. The routers have
severe hardware cost constraints (so limited CPU power), but see a lot
of traffic and need to process (NAT) it.
> That's a nice analysis. Might one conclude from that that hsiphash is
> not useful for our purposes? Or does it still remain useful for
> network facing code?
I think for attacks where the threat is a DoS, it's usable. The point
is you only have to raise the cost to equal that of a packet flood.
(Just like in electronic warfare, the best you can possibly do is force
the enemy to use broadband jamming.)
Hash collision attacks just aren't that powerful. The original PoC
was against an application that implemented a hard limit on hash chain
length as a DoS defense, which the attack then exploited to turn it into
a hard DoS.
>> Let me consider your second example above, "secure against local users".
>> I should dig through your patchset and find the details, but what exactly
>> are the consequences of such an attack? Hasn't a local user already
>> got much better ways to DoS the system?
> For example, an unpriv'd user putting lots of entries in one hash
> bucket for a shared resource that's used by root, like filesystems or
> other lookup tables. If he can cause root to use more of root's cpu
> schedule budget than otherwise in a directed way, then that's a bad
> DoS.
This issue was recently discussed when we redesigned the dcache hash.
Even a successful attack doesn't slow things down all *that* much.
Before you overkill every hash table in the kernel, think about whether
it's a bigger problem than the dcache. (Hint: it's probably not.)
There's no point armor-plating the side door when the front door was
just upgraded from screen to wood.
>> These days, 32-bit CPUs are for embedded applications: network appliances,
>> TVs, etc. That means basically single-user. Even phones are 64 bit.
>> Is this really a threat that needs to be defended against?
> I interpret this to indicate all the more reason to alias hsiphash to
> siphash on 64-bit, and then the problem space collapses in a clear
> way.
Yes, exactly.
> Right. Hence the need for always using full siphash and not hsiphash
> for sequence numbers, per my earlier email to David.
>
>> I wish we could get away with 64-bit security, but given that the
>> modern internet involves attacks from NSA/Spetssvyaz/3PLA, I agree
>> it's just not enough.
>
> I take this comment to be relavent for the sequence number case.
Yes.
> For hashtables and hashtable flooding, is it still your opinion that
> we will benefit from hsiphash? Or is this final conclusion a rejection
> of hsiphash for that too? We're talking about two different use cases,
> and your email kind of interleaved both into your analysis, so I'm not
> certain so to precisely what your conclusion is for each use case. Can
> you clear up the ambiguity?
My (speaking enerally; I should walk through every hash table you've
converted) opinion is that:
- Hash tables, even network-facing ones, can all use hsiphash as long
as an attacker can only see collisions, i.e. ((H(x) ^ H(y)) & bits) ==
0, and the consequences of a successful attack is only more collisions
(timing). While the attack is only 2x the cost (two hashes rather than
one to test a key), the knowledge of the collision is statistical,
especially for network attackers, which raises the cost of guessing
beyond an even more brute-force attack.
- When the hash value directly visible (e.g. included in a network
packet), full SipHash should be the default.
- Syncookies *could* use hsiphash, especially as there are
two keys in there. Not sure if we need the performance.
- For TCP ISNs, I'd prefer to use full SipHash. I know this is
a very hot path, and if that's a performance bottleneck,
we can work harder on it.
In particular, TCP ISNs *used* to rotate the key periodically,
limiting the time available to an attacker to perform an
attack before the secret goes stale and is useless. commit
6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upgraded to md5 and dropped
the key rotation.
If 2x hsiphash is faster than siphash, we could use a double-hashing
system like syncookies. One 32-bit hash with a permanent key, summed
with a k-bit counter and a (32-k)-bit hash, where the key is rotated
(and the counter incremented) periodically.
The requirement is that the increment rate of the counter hash doesn't
shorten the sequence number wraparound too much. The old code used an
8-bit counter and 24-bit hash, with the counter bumped every 5 minutes.
Current code uses a 64 ns tick for the ISN, so it counts 2^24 per second.
(32 bits wraps every 4.6 minutes.) A 4-bit counter and 28-bit hash
(or even 3+29) would work as long as the key is regenerated no more
than once per minute. (Just using the 4.6-minute ISN wrap time is the
obvious simple implementation.)
(Of course, I defer to DaveM's judgement on all network-related issues.)
^ permalink raw reply
* RE: [PATCH] liquidio CN23XX: make timeout HZ independent
From: Chickles, Derek @ 2016-12-16 20:08 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Burla, Satananda, Manlunas, Felix, Vatsavayi, Raghu,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1481875839-30860-1-git-send-email-hofrat@osadl.org>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:hofrat@osadl.org]
> Sent: Friday, December 16, 2016 12:11 AM
> To: Chickles, Derek
> Cc: Burla, Satananda; Manlunas, Felix; Vatsavayi, Raghu;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Nicholas Mc Guire
> Subject: [PATCH] liquidio CN23XX: make timeout HZ independent
>
> schedule_timeout_* takes a timeout in jiffies but the code currently is
> passing in a constant which makes this timeout HZ dependent, so pass it
> through msecs_to_jiffies() to fix this up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> ---
>
> Problem found by coccinelle spatch
>
> The current delay can vary by a factor 10 depending on the HZ
> setting chose, which does not seem reasonable here.
>
> The below patch sets the timeout to 10ms - it is though not clear
> if this is the intent or if it should be longer/shorter as it is not
> clear what HZ setting was assumed during design and used for testing.
>
> This needs an ack by someone who knows the device and can confirm that
> 10ms is reasonable to wait for completion of queuing.
We were actually looking at this in parallel already to speed up driver
loading. It would be better if we changed LIO_MBOX_WRITE_WAIT_TIME
to 1 and applied the msecs_to_jiffies() to the line specified in your patch
and the loop just above that.
while (readq(mbox->mbox_write_reg) != OCTEON_PFVFSIG) {
schedule_timeout_uninterruptible(LIO_MBOX_WRITE_WAIT_TIME);
if (count++ == LIO_MBOX_WRITE_WAIT_CNT) {
ret = OCTEON_MBOX_STATUS_FAILED;
break;
}
}
If you can provide a new patch with both the changes we'll sign off on it.
Otherwise, it's on our list and we'll submit it soon ourselves.
Thanks,
Derek
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Tom Herbert @ 2016-12-16 19:47 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson, George Spelvin, Andi Kleen, David Miller,
David Laight, Eric Biggers, Hannes Frederic Sowa,
kernel-hardening, Linux Crypto Mailing List, LKML,
Andy Lutomirski, Netdev, Linus Torvalds, Theodore Ts'o,
vegard.nossum, Daniel J . Bernstein
In-Reply-To: <CAHmME9pjoAsoct1sVDpFFuqaqutv9X7DGJ5OBQXRAS57KFimUA@mail.gmail.com>
On Fri, Dec 16, 2016 at 4:39 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hey JP,
>
> On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson
> <jeanphilippe.aumasson@gmail.com> wrote:
>> Here's a tentative HalfSipHash:
>> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c
>>
>> Haven't computed the cycle count nor measured its speed.
>
Tested this. Distribution and avalanche effect are still good. Speed
wise I see about a 33% improvement over siphash (20 nsecs/op versus 32
nsecs). That's about 3x of jhash speed (7 nsecs). So that might closer
to a more palatable replacement for jhash. Do we lose any security
advantages with halfsiphash?
Tom
> This is incredible. Really. Wow!
>
> I'll integrate this into my patchset and will write up some
> documentation about when one should be used over the other.
>
> Thanks again. Quite exciting.
>
> Jason
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-16 19:43 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Rajat Jain
In-Reply-To: <20161215032105.GA88921-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Brian,
I've just posted a v2 patchset after taking care of your your
comments. Please see inline below.
On Wed, Dec 14, 2016 at 7:21 PM, Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> Hi,
>
> On Wed, Dec 14, 2016 at 11:12:58AM -0800, Rajat Jain wrote:
>> Some BT chips (e.g. Marvell 8997) contain a wakeup pin that can be
>> connected to a gpio on the CPU side, and can be used to wakeup
>> the host out-of-band. This can be useful in situations where the
>> in-band wakeup is not possible or not preferable (e.g. the in-band
>> wakeup may require the USB host controller to remain active, and
>> hence consuming more system power during system sleep).
>>
>> The oob gpio interrupt to be used for wakeup on the CPU side, is
>> read from the device tree node, (using standard interrupt descriptors).
>> A devcie tree binding document is also added for the driver.
>>
>> Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/btusb.txt | 38 ++++++++++++
>> drivers/bluetooth/btusb.c | 82 +++++++++++++++++++++++++
>> 2 files changed, 120 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
>> new file mode 100644
>> index 0000000..bb27f92
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/btusb.txt
>> @@ -0,0 +1,38 @@
>> +Generic Bluetooth controller over USB (btusb driver)
>> +---------------------------------------------------
>> +
>> +Required properties:
>> +
>> + - compatible : should comply with the format "usbVID,PID" specified in
>> + Documentation/devicetree/bindings/usb/usb-device.txt
>> + At the time of writing, the only OF supported devices
>> + (more may be added later) are:
>> +
>> + "usb1286,204e" (Marvell 8997)
>> +
>> +Optional properties:
>> +
>> + - interrupt-parent: phandle of the parent interrupt controller
>> + - interrupts : The first interrupt specified is the interrupt that shall be
>> + used for out-of-band wake-on-bt. Driver will request an irq
>> + based on this interrupt number. During system suspend, the irq
>> + will be enabled so that the bluetooth chip can wakeup host
>> + platform out of band. During system resume, the irq will be
>> + disabled to make sure unnecessary interrupt is not received.
>
> Might it be worthwhile to define an 'interrupt-names' property (e.g., =
> "wakeup") to help future-proof this?
Good idea, I've used the same.
>
>> +
>> +Example:
>> +
>> +Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
>> +
>> +&usb_host1_ehci {
>> + status = "okay";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mvl_bt1: bt@1 {
>> + compatible = "usb1286,204e";
>> + reg = <1>;
>> + interrupt-parent = <&gpio0>;
>> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index ce22cef..32a6f22 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -24,6 +24,8 @@
>> #include <linux/module.h>
>> #include <linux/usb.h>
>> #include <linux/firmware.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_irq.h>
>> #include <asm/unaligned.h>
>>
>> #include <net/bluetooth/bluetooth.h>
>> @@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
>> #define BTUSB_BOOTING 9
>> #define BTUSB_RESET_RESUME 10
>> #define BTUSB_DIAG_RUNNING 11
>> +#define BTUSB_OOB_WAKE_DISABLED 12
>>
>> struct btusb_data {
>> struct hci_dev *hdev;
>> @@ -416,6 +419,8 @@ struct btusb_data {
>> int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
>>
>> int (*setup_on_usb)(struct hci_dev *hdev);
>> +
>> + int oob_wake_irq; /* irq for out-of-band wake-on-bt */
>> };
>>
>> static inline void btusb_free_frags(struct btusb_data *data)
>> @@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
>> }
>> #endif
>>
>> +#ifdef CONFIG_PM
>> +static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
>> +{
>> + struct btusb_data *data = priv;
>> +
>> + /* Disable only if not already disabled (keep it balanced) */
>> + if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
>> + disable_irq_wake(irq);
>> + disable_irq_nosync(irq);
>> + }
>> + pm_wakeup_event(&data->udev->dev, 0);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static const struct of_device_id btusb_match_table[] = {
>> + { .compatible = "usb1286,204e" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, btusb_match_table);
>> +
>> +/* Use an oob wakeup pin? */
>> +static int btusb_config_oob_wake(struct hci_dev *hdev)
>> +{
>> + struct btusb_data *data = hci_get_drvdata(hdev);
>> + struct device *dev = &data->udev->dev;
>> + int irq, ret;
>> +
>> + if (!of_match_device(btusb_match_table, dev))
>> + return 0;
>> +
>> + /* Move on if no IRQ specified */
>> + irq = irq_of_parse_and_map(dev->of_node, 0);
>
> Better to use of_irq_get{,_byname}(), no?
I've used_irq_get_byname().
>
>> + if (!irq) {
>> + bt_dev_dbg(hdev, "%s: no oob wake irq in DT", __func__);
>> + return 0;
>> + }
>> +
>> + set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
>> +
>> + ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
>> + IRQF_TRIGGER_LOW, "oob wake-on-bt", data);
>
> You're assuming this is level-triggered, and active-low? Can't this just
> be specified in the device tree and just pass 0 here?
>
> Also, it seems like it would be a lot more convenient if we could treat
> this as edge-triggered, so we don't have to do the set/clear flags,
> disable IRQ, etc., dance. You'd just have to change the device tree
> definition. Is there any downside to doing that?
Now, I don't put any assumptions in the driver and use whatever is
specified in the device tree. So platforms can do whatever they want
(However, I think configuring as edge triggered in the device tree (if
some platform chooses to) may leave some corner cases where the
interrupt might be missed if it was already asserted for some reason).
Thanks,
Rajat
>
> It would also then be a better candidate for using something like
> dev_pm_set_dedicated_wake_irq() (although last time I tried using that,
> it didn't do so great if you don't have autosuspend enabled -- but I
> think there are patches outstanding for that; so maybe not yet).
>
>> + if (ret) {
>> + bt_dev_err(hdev, "%s: irq request failed", __func__);
>> + return ret;
>> + }
>> +
>> + ret = device_init_wakeup(dev, true);
>> + if (ret) {
>> + bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
>> + return ret;
>> + }
>> +
>> + data->oob_wake_irq = irq;
>> + disable_irq(irq);
>> + bt_dev_info(hdev, "oob wake-on-bt configured at irq %u\n", irq);
>
> oob and bt are typically capitalized in strings. And maybe irq too.
> Also, you declared irq as 'int', so %d instead of %u.
>
> Brian
>
>> + return 0;
>> +}
>> +#endif
>> +
>> static int btusb_probe(struct usb_interface *intf,
>> const struct usb_device_id *id)
>> {
>> @@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
>> hdev->send = btusb_send_frame;
>> hdev->notify = btusb_notify;
>>
>> +#ifdef CONFIG_PM
>> + err = btusb_config_oob_wake(hdev);
>> + if (err)
>> + goto out_free_dev;
>> +#endif
>> if (id->driver_info & BTUSB_CW6622)
>> set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
>>
>> @@ -3089,6 +3158,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>> btusb_stop_traffic(data);
>> usb_kill_anchored_urbs(&data->tx_anchor);
>>
>> + if (data->oob_wake_irq) {
>> + clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
>> + enable_irq(data->oob_wake_irq);
>> + enable_irq_wake(data->oob_wake_irq);
>> + }
>> +
>> /* Optionally request a device reset on resume, but only when
>> * wakeups are disabled. If wakeups are enabled we assume the
>> * device will stay powered up throughout suspend.
>> @@ -3126,6 +3201,13 @@ static int btusb_resume(struct usb_interface *intf)
>> if (--data->suspend_count)
>> return 0;
>>
>> + /* Disable only if not already disabled (keep it balanced) */
>> + if (data->oob_wake_irq &&
>> + !test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
>> + disable_irq_wake(data->oob_wake_irq);
>> + disable_irq(data->oob_wake_irq);
>> + }
>> +
>> if (!test_bit(HCI_RUNNING, &hdev->flags))
>> goto done;
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Daniel Borkmann @ 2016-12-16 19:31 UTC (permalink / raw)
To: Ozgur Karatas, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <5194151481912505@web1g.yandex.ru>
On 12/16/2016 07:21 PM, Ozgur Karatas wrote:
>
> This patch fixed to keyboard typo, brackets not closed.
> I think, it should be close to parenthes.
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
NAK for obvious reasons ...
> ---
> tools/net/bpf_dbg.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletions(-)
>
> diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
> index 4f254bc..f715f46 100644
> --- a/tools/net/bpf_dbg.c
> +++ b/tools/net/bpf_dbg.c
> @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>
> if (!bpf_prog_loaded())
> return CMD_ERR;
> - if (strlen(line_string) > 0 &&
> + if (strlen(line_string) > 0 &&)
> (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
> single_line = true;
> if (single_line)
>
^ permalink raw reply
* [PATCH v2 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup
From: Rajat Jain @ 2016-12-16 19:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <1481916604-114279-1-git-send-email-rajatja@google.com>
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v2: Fix the binding document to specify to use "wakeup" interrupt-name
.../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 ++++++++++++++---
drivers/bluetooth/btusb.c | 59 ++++++++++++++++++++++
2 files changed, 97 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (50%)
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63c..9be1059 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
Required properties:
- compatible : should be one of the following:
- * "marvell,sd8897-bt"
- * "marvell,sd8997-bt"
+ * "marvell,sd8897-bt" (for SDIO)
+ * "marvell,sd8997-bt" (for SDIO)
+ * "usb1286,204e" (for USB)
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
platform. The value will be configured to firmware. This
is needed to work chip's sleep feature as expected (u16).
- interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. Driver will request an irq based
- on this interrupt number. During system suspend, the irq will be
- enabled so that the bluetooth chip can wakeup host platform under
- certain condition. During system resume, the irq will be disabled
+ - interrupt-names: Used only for USB based devices (See below)
+ - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+ driver will use the first interrupt specified in the interrupt
+ array. For USB based devices, the driver will use the interrupt
+ named "wakeup" from the interrupt-names and interrupt arrays.
+ The driver will request an irq based on this interrupt number.
+ During system suspend, the irq will be enabled so that the
+ bluetooth chip can wakeup host platform under certain
+ conditions. During system resume, the irq will be disabled
to make sure unnecessary interrupt is not received.
Example:
@@ -29,7 +39,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-names = "wakeup";
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index beca4e9..455b3d0 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,58 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+static const struct of_device_id mvl_oob_wake_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mvl_oob_wake_match_table);
+
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ if (!of_match_device(mvl_oob_wake_match_table, dev))
+ return 0;
+
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return -EINVAL;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2917,6 +2969,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvell devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+ }
#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-16 19:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <1481916604-114279-1-git-send-email-rajatja@google.com>
Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).
The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.
Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
drivers/bluetooth/btusb.c | 84 +++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index 0000000..2c0355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---------------------------------------------------
+
+Required properties:
+
+ - compatible : should comply with the format "usbVID,PID" specified in
+ Documentation/devicetree/bindings/usb/usb-device.txt
+ At the time of writing, the only OF supported devices
+ (more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupt-names: (see below)
+ - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+ that shall be used for out-of-band wake-on-bt. Driver will
+ request this interrupt for wakeup. During system suspend, the
+ irq will be enabled so that the bluetooth chip can wakeup host
+ platform out of band. During system resume, the irq will be
+ disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+&usb_host1_ehci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-name = "wakeup";
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cef..beca4e9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
#include <linux/module.h>
#include <linux/usb.h>
#include <linux/firmware.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
#define BTUSB_BOOTING 9
#define BTUSB_RESET_RESUME 10
#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_DISABLED 12
struct btusb_data {
struct hci_dev *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
int (*setup_on_usb)(struct hci_dev *hdev);
+
+ int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
}
#endif
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+ struct btusb_data *data = priv;
+
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq_nosync(irq);
+ disable_irq_wake(irq);
+ }
+ pm_wakeup_event(&data->udev->dev, 0);
+ return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ int irq, ret;
+
+ if (!of_match_device(btusb_match_table, dev))
+ return 0;
+
+ /* Move on if no IRQ specified */
+ irq = of_irq_get_byname(dev->of_node, "wakeup");
+ if (irq <= 0) {
+ bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
+ return 0;
+ }
+
+ set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+
+ ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
+ 0, "OOB Wake-on-BT", data);
+ if (ret) {
+ bt_dev_err(hdev, "%s: IRQ request failed", __func__);
+ return ret;
+ }
+
+ ret = device_init_wakeup(dev, true);
+ if (ret) {
+ bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
+ return ret;
+ }
+
+ data->oob_wake_irq = irq;
+ disable_irq(irq);
+ bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u\n", irq);
+ return 0;
+}
+#endif
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
hdev->send = btusb_send_frame;
hdev->notify = btusb_notify;
+#ifdef CONFIG_PM
+ err = btusb_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
@@ -3061,6 +3130,9 @@ static void btusb_disconnect(struct usb_interface *intf)
usb_driver_release_interface(&btusb_driver, data->isoc);
}
+ if (data->oob_wake_irq)
+ device_init_wakeup(&data->udev->dev, false);
+
hci_free_dev(hdev);
}
@@ -3089,6 +3161,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
+ if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
+ clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+ enable_irq_wake(data->oob_wake_irq);
+ enable_irq(data->oob_wake_irq);
+ }
+
/* Optionally request a device reset on resume, but only when
* wakeups are disabled. If wakeups are enabled we assume the
* device will stay powered up throughout suspend.
@@ -3126,6 +3204,12 @@ static int btusb_resume(struct usb_interface *intf)
if (--data->suspend_count)
return 0;
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq(data->oob_wake_irq);
+ disable_irq_wake(data->oob_wake_irq);
+ }
+
if (!test_bit(HCI_RUNNING, &hdev->flags))
goto done;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 1/3] Bluetooth: btusb: Use an error label for error paths
From: Rajat Jain @ 2016-12-16 19:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
v2: same as v1
drivers/bluetooth/btusb.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df..ce22cef 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
- hci_free_dev(hdev);
- return err;
+ goto out_free_dev;
}
}
if (data->isoc) {
err = usb_driver_claim_interface(&btusb_driver,
data->isoc, data);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
}
#ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
#endif
err = hci_register_dev(hdev);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
usb_set_intfdata(intf, data);
return 0;
+
+out_free_dev:
+ hci_free_dev(hdev);
+ return err;
}
static void btusb_disconnect(struct usb_interface *intf)
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Ozgur Karatas @ 2016-12-16 19:13 UTC (permalink / raw)
To: Sergei Shtylyov, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <96578fd4-dd02-f39a-a252-c37aa714d3d0@cogentembedded.com>
16.12.2016, 21:08, "Sergei Shtylyov" <sergei.shtylyov@cogentembedded.com>:
> Hello.
Hi
> On 12/16/2016 09:21 PM, Ozgur Karatas wrote:
>
>> This patch fixed to keyboard typo, brackets not closed.
>> I think, it should be close to parenthes.
>>
>> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
>> ---
>> tools/net/bpf_dbg.c | 2 +-
>> 1 files changed, 1 insertion(+), 1 deletions(-)
>>
>> diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
>> index 4f254bc..f715f46 100644
>> --- a/tools/net/bpf_dbg.c
>> +++ b/tools/net/bpf_dbg.c
>> @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>>
>> if (!bpf_prog_loaded())
>> return CMD_ERR;
>> - if (strlen(line_string) > 0 &&
>> + if (strlen(line_string) > 0 &&)
>
> Have tried to you compile that? :-/
Yes, i compiled but I apologize if there was NAK.
Also, checkpatch give a error.
I could be wrong, will review again.
Best Regards!
>> (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
>
> I think the code was correct before your patch...
>
>> single_line = true;
>> if (single_line)
>
> MBR, Sergei
~Ozgur
^ permalink raw reply
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Sergei Shtylyov @ 2016-12-16 19:08 UTC (permalink / raw)
To: Ozgur Karatas, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <5194151481912505@web1g.yandex.ru>
Hello.
On 12/16/2016 09:21 PM, Ozgur Karatas wrote:
> This patch fixed to keyboard typo, brackets not closed.
> I think, it should be close to parenthes.
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
> ---
> tools/net/bpf_dbg.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletions(-)
>
> diff --git a/tools/net/bpf_dbg.c b/tools/net/bpf_dbg.c
> index 4f254bc..f715f46 100644
> --- a/tools/net/bpf_dbg.c
> +++ b/tools/net/bpf_dbg.c
> @@ -1213,7 +1213,7 @@ static int cmd_disassemble(char *line_string)
>
> if (!bpf_prog_loaded())
> return CMD_ERR;
> - if (strlen(line_string) > 0 &&
> + if (strlen(line_string) > 0 &&)
Have tried to you compile that? :-/
> (line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
I think the code was correct before your patch...
> single_line = true;
> if (single_line)
MBR, Sergei
^ permalink raw reply
* Re: [TSN RFC v2 0/9] TSN driver for the kernel
From: Henrik Austad @ 2016-12-16 19:07 UTC (permalink / raw)
To: David Miller
Cc: gvrose8192, linux-kernel, richardcochran, haustad, linux-media,
alsa-devel, netdev
In-Reply-To: <20161216.132057.1771215556712298530.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
On Fri, Dec 16, 2016 at 01:20:57PM -0500, David Miller wrote:
> From: Greg <gvrose8192@gmail.com>
> Date: Fri, 16 Dec 2016 10:12:44 -0800
>
> > On Fri, 2016-12-16 at 18:59 +0100, henrik@austad.us wrote:
> >> From: Henrik Austad <haustad@cisco.com>
> >>
> >>
> >> The driver is directed via ConfigFS as we need userspace to handle
> >> stream-reservation (MSRP), discovery and enumeration (IEEE 1722.1) and
> >> whatever other management is needed. This also includes running an
> >> appropriate PTP daemon (TSN favors gPTP).
> >
> > I suggest using a generic netlink interface to communicate with the
> > driver to set up and/or configure your drivers.
> >
> > I think configfs is frowned upon for network drivers. YMMV.
>
> Agreed.
Ok - thanks!
I will have look at netlink and see if I can wrap my head around it and if
I can apply it to how to bring the media-devices up once the TSN-link has
been configured.
Thanks! :)
--
Henrik Austad
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Ozgur Karatas @ 2016-12-16 18:58 UTC (permalink / raw)
To: Joe Perches, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <1481913321.29291.89.camel@perches.com>
16.12.2016, 20:35, "Joe Perches" <joe@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>> This patch fixed to keyboard typo, brackets not closed.
>> I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.
Also, checkpatch script give a error, it should not forget.
$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c
tools/net/bpf_dbg.c:1216: ERROR: do not use assignment in if condition
After fix:
$ ./scripts/checkpatch.pl --file --terse tools/net/bpf_dbg.c
total: 0 errors, 6 warnings, 1395 lines checked
Regards,
~Ozgur
^ permalink raw reply
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Ozgur Karatas @ 2016-12-16 18:53 UTC (permalink / raw)
To: Joe Perches, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <1481913321.29291.89.camel@perches.com>
16.12.2016, 20:35, "Joe Perches" <joe@perches.com>:
> On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
>> This patch fixed to keyboard typo, brackets not closed.
>> I think, it should be close to parenthes.
>
> No.
>
> Please compile and test your patches on your own system
> before you send them.
Dear Perches,
I have already tested and it was not a part of the code anyway. if there is no parentheses, the code works incorrectly and give a error.
I'm sorry, have a little problem with my english but "line_string" variables would not equal NULL, 10. So the code it skips it and runs to "bpf_prog_len".
If it should be equal "0 &&" and already be completed (>) right?
if (strlen(line_string) > 0 &&
(line = strtoul(line_string, NULL, 10)) < bpf_prog_len)
Testing:
$ make M=tools/
tools//Makefile:6: scripts/Makefile.include: No such file or directory
$ cp tools/scripts/Makefile.include scripts/Makefile
$ make M=tools/
Building modules, stage 2.
MODPOST 0 modules
I try to module (insmod) and worked.
Regards,
~Ozgur
^ permalink raw reply
* Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo
From: Joe Perches @ 2016-12-16 18:35 UTC (permalink / raw)
To: Ozgur Karatas, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <5194151481912505@web1g.yandex.ru>
On Fri, 2016-12-16 at 20:21 +0200, Ozgur Karatas wrote:
> This patch fixed to keyboard typo, brackets not closed.
> I think, it should be close to parenthes.
No.
Please compile and test your patches on your own system
before you send them.
^ permalink raw reply
* [PATCHv5 perf/core 5/5] samples/bpf: Move open_raw_sock to separate header
From: Joe Stringer @ 2016-12-16 18:32 UTC (permalink / raw)
To: acme; +Cc: linux-kernel, netdev, wangnan0, ast, daniel
In-Reply-To: <20161216183259.14840-1-joe@ovn.org>
This function was declared in libbpf.c and was the only remaining
function in this library, but has nothing to do with BPF. Shift it out
into a new header, sock_example.h, and include it from the relevant
samples.
Signed-off-by: Joe Stringer <joe@ovn.org>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20161209024620.31660-8-joe@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
v5: No change.
---
samples/bpf/Makefile | 2 +-
samples/bpf/fds_example.c | 1 +
samples/bpf/libbpf.h | 3 ---
samples/bpf/sock_example.c | 1 +
samples/bpf/{libbpf.c => sock_example.h} | 3 +--
samples/bpf/sockex1_user.c | 1 +
samples/bpf/sockex2_user.c | 1 +
samples/bpf/sockex3_user.c | 1 +
8 files changed, 7 insertions(+), 6 deletions(-)
rename samples/bpf/{libbpf.c => sock_example.h} (92%)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 5a73f5a7ace1..f01b66f277b0 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -36,7 +36,7 @@ hostprogs-y += lwt_len_hist
hostprogs-y += xdp_tx_iptunnel
# Libbpf dependencies
-LIBBPF := libbpf.o ../../tools/lib/bpf/bpf.o
+LIBBPF := ../../tools/lib/bpf/bpf.o
test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
sock_example-objs := sock_example.o $(LIBBPF)
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 6245062844d1..92592e38569b 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -14,6 +14,7 @@
#include "bpf_load.h"
#include "libbpf.h"
+#include "sock_example.h"
#define BPF_F_PIN (1 << 0)
#define BPF_F_GET (1 << 1)
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index 09aedc320009..3705fba453a0 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -185,7 +185,4 @@ struct bpf_insn;
.off = 0, \
.imm = 0 })
-/* create RAW socket and bind to interface 'name' */
-int open_raw_sock(const char *name);
-
#endif
diff --git a/samples/bpf/sock_example.c b/samples/bpf/sock_example.c
index 5546f8aac37e..6fc6e193ef1b 100644
--- a/samples/bpf/sock_example.c
+++ b/samples/bpf/sock_example.c
@@ -27,6 +27,7 @@
#include <linux/ip.h>
#include <stddef.h>
#include "libbpf.h"
+#include "sock_example.h"
char bpf_log_buf[BPF_LOG_BUF_SIZE];
diff --git a/samples/bpf/libbpf.c b/samples/bpf/sock_example.h
similarity index 92%
rename from samples/bpf/libbpf.c
rename to samples/bpf/sock_example.h
index bee473a494f1..09f7fe7e5fd7 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/sock_example.h
@@ -1,4 +1,3 @@
-/* eBPF mini library */
#include <stdlib.h>
#include <stdio.h>
#include <linux/unistd.h>
@@ -11,7 +10,7 @@
#include <arpa/inet.h>
#include "libbpf.h"
-int open_raw_sock(const char *name)
+static inline int open_raw_sock(const char *name)
{
struct sockaddr_ll sll;
int sock;
diff --git a/samples/bpf/sockex1_user.c b/samples/bpf/sockex1_user.c
index 9454448bf198..6cd2feb3e9b3 100644
--- a/samples/bpf/sockex1_user.c
+++ b/samples/bpf/sockex1_user.c
@@ -3,6 +3,7 @@
#include <linux/bpf.h>
#include "libbpf.h"
#include "bpf_load.h"
+#include "sock_example.h"
#include <unistd.h>
#include <arpa/inet.h>
diff --git a/samples/bpf/sockex2_user.c b/samples/bpf/sockex2_user.c
index 6a40600d5a83..0e0207c90841 100644
--- a/samples/bpf/sockex2_user.c
+++ b/samples/bpf/sockex2_user.c
@@ -3,6 +3,7 @@
#include <linux/bpf.h>
#include "libbpf.h"
#include "bpf_load.h"
+#include "sock_example.h"
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/resource.h>
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
index 9099c4255f23..b5524d417eb5 100644
--- a/samples/bpf/sockex3_user.c
+++ b/samples/bpf/sockex3_user.c
@@ -3,6 +3,7 @@
#include <linux/bpf.h>
#include "libbpf.h"
#include "bpf_load.h"
+#include "sock_example.h"
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/resource.h>
--
2.10.2
^ 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