Re: [PATCH net 2/2] bpf: fix overflow in prog accounting

Hi Daniel, [auto build test ERROR on net/master] url: https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-dynamically-allocate-digest-scratch-buffer/20161217-090046 config: openrisc-or1ksim_defconfig (attached as .config) compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1 reproduce:

Re: [PATCH net 2/2] bpf: fix overflow in prog accounting

Hi Daniel, [auto build test ERROR on net/master] url: https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-dynamically-allocate-digest-scratch-buffer/20161217-090046 config: sparc-defconfig (attached as .config) compiler: sparc-linux-gcc (GCC) 6.2.0 reproduce: wget

Re: [B.A.T.M.A.N.] [PATCH net-next 1/2] net: batman-adv: Treat NET_XMIT_CN as transmit successfully

On Fri, Dec 16, 2016 at 5:19 PM, Sven Eckelmann wrote: > On Montag, 21. November 2016 23:00:32 CET f...@ikuai8.com wrote: >> From: Gao Feng >> >> The tc could return NET_XMIT_CN as one congestion notification, but >> it does not mean the packet is lost.

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> I already did this. Check my branch. Do you think it should return "u32" (as you currently have it) or "unsigned long"? I thought the latter, since it doesn't cost any more and makes more > I wonder if this could also lead to a similar aliasing > with arch_get_random_int, since I'm pretty

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin wrote: > Ths advice I'd give now is: > - Implement > unsigned long hsiphash(const void *data, size_t len, const unsigned long > key[2]) > .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and >

[PATCH] net/x25: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] isdn: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] bna: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] WAN: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] net: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] ATM: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] isdn/gigaset: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH net 2/2] bpf: fix overflow in prog accounting

Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs") made a wrong assumption of charging against prog->pages. Unlike map->pages, prog->pages are still subject to change when we need to expand the program through bpf_prog_realloc(). This can for example happen during

[PATCH net 0/2] Two BPF fixes

This set contains two BPF fixes for net, one that addresses the complaint from Geert wrt static allocations, and the other is a fix wrt mem accounting that I found recently during testing. Thanks! Daniel Borkmann (2): bpf: dynamically allocate digest scratch buffer bpf: fix overflow in prog

[PATCH net 1/2] bpf: dynamically allocate digest scratch buffer

Geert rightfully complained that 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink") added a too large allocation of variable 'raw' from bss section, and should instead be done dynamically: # ./scripts/bloat-o-meter kernel/bpf/core.o.1 kernel/bpf/core.o.2 add/remove: 3/0

[PATCH] net: mv643xx_eth: fix build failure

safely use #if defined(CONFIG_OF_IRQ) in the code. Signed-off-by: Sudip Mukherjee <sudip.mukher...@codethink.co.uk> --- build log of next-20161216 is at: https://travis-ci.org/sudipm-mukherjee/parport/jobs/184652820 drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +- 1 file changed, 1 insertio

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On Sat, Dec 17, 2016 at 12:39:17AM +0100, Michal Hocko wrote: > On Fri 16-12-16 15:23:42, Alexei Starovoitov wrote: > > On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote: > > > On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote: > > > > On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal

Re: [PATCH] net: wan: Use dma_pool_zalloc

On Fri, 2016-12-16 at 19:25 +0530, Souptick Joarder wrote: > On Fri, Dec 16, 2016 at 11:40 AM, Joe Perches wrote: > > On Fri, 2016-12-16 at 11:33 +0530, Souptick Joarder wrote: > > > On Thu, Dec 15, 2016 at 10:18 PM, Joe Perches wrote: > > > > On Thu,

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> 64-bit security for an RNG is not reasonable even with rekeying. No no > no. Considering we already have a massive speed-up here with the > secure version, there's zero reason to start weakening the security > because we're trigger happy with our benchmarks. No no no. Just to clarify, I was

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On 12/17/2016 12:23 AM, Alexei Starovoitov wrote: On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote: On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote: On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote: From: Michal Hocko 01b3f52157ff ("bpf: fix

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On Fri 16-12-16 15:23:42, Alexei Starovoitov wrote: > On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote: > > On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote: > > > On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > >

Re: Soft lockup in inet_put_port on 4.6

On Fri, Dec 16, 2016 at 5:18 PM, Tom Herbert wrote: On Fri, Dec 16, 2016 at 2:08 PM, Josef Bacik wrote: On Fri, Dec 16, 2016 at 10:21 AM, Josef Bacik wrote: On Fri, Dec 16, 2016 at 9:54 AM, Josef Bacik wrote: On Thu,

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote: > On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote: > > On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > 01b3f52157ff ("bpf: fix allocation warnings in bpf maps and

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

An idea I had which mght be useful: You could perhaps save two rounds in siphash_*u64. The final word with the length (called "b" in your implementation) only needs to be there if the input is variable-sized. If every use of a given key is of a fixed-size input, you don't need a length suffix.

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, > Agreed. A simpler contruction would be: > > chaining++; > output = H(chaining, secret); > > And this looks a whole lot like Ted's ChaCha20 construction. In that simpler construction with counter-based secret rekeying and in Ted's ChaCha20 construction, the issue is that every X hits,

Re: Soft lockup in inet_put_port on 4.6

On Fri, Dec 16, 2016 at 2:08 PM, Josef Bacik wrote: > On Fri, Dec 16, 2016 at 10:21 AM, Josef Bacik wrote: >> >> On Fri, Dec 16, 2016 at 9:54 AM, Josef Bacik wrote: >>> >>> On Thu, Dec 15, 2016 at 7:07 PM, Hannes Frederic Sowa >>>

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 11:13 PM, George Spelvin wrote: > Remembering that on "real" machines it's full SipHash, then I'd say that > 64-bit security + rekeying seems reasonable. 64-bit security for an RNG is not reasonable even with rekeying. No no no. Considering we

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 2:13 PM, George Spelvin 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. >

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

On Fri, Dec 16, 2016 at 1:45 PM, Jason A. Donenfeld wrote: > Hi Andy, > > On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote: >> I think it would be nice to try to strenghen the PRNG construction. >> FWIW, I'm not an expert in PRNGs, and there's fairly

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> 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. This is tricky. The entire get_random_int() structure is an abuse of the hash function

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, Ted, I've made the requested changes. Keys now rotate and are per-CPU based. The chaining value is now additive instead of replacing. DavidL suggested I lower the velocity of `git-send-email` triggers, so if you'd like to take a look at this before I post v7, you can follow along at my

Re: [TSN RFC v2 5/9] Add TSN header for the driver

On Fri, Dec 16, 2016 at 06:59:09PM +0100, hen...@austad.us wrote: > +/* > + * List of current subtype fields in the common header of AVTPDU > + * > + * Note: AVTPDU is a remnant of the standards from when it was AVB. > + * > + * The list has been updated with the recent values from IEEE 1722,

Re: Soft lockup in inet_put_port on 4.6

On Fri, Dec 16, 2016 at 10:21 AM, Josef Bacik wrote: On Fri, Dec 16, 2016 at 9:54 AM, Josef Bacik wrote: On Thu, Dec 15, 2016 at 7:07 PM, Hannes Frederic Sowa wrote: Hi Josef, On 15.12.2016 19:53, Josef Bacik wrote: On Tue, Dec 13,

Re: [TSN RFC v2 0/9] TSN driver for the kernel

On Fri, Dec 16, 2016 at 06:59:04PM +0100, hen...@austad.us wrote: > 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. I complained about configfs before, but you didn't

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote: > On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > 01b3f52157ff ("bpf: fix allocation warnings in bpf maps and integer > > overflow") has added checks for the maximum allocateable

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote: > I think it would be nice to try to strenghen the PRNG construction. > FWIW, I'm not an expert in PRNGs, and there's fairly extensive > literature, but I can at least try. In an effort to keep this patchset

[PATCH] isdn: Constify some function parameters

From: Emese Revfy The coming initify gcc plugin expects const pointer types, and caught some __printf arguments that weren't const yet. This fixes those. Signed-off-by: Emese Revfy [kees: expanded commit message] Signed-off-by: Kees Cook

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

On Thu, Dec 15, 2016 at 7:03 PM, Jason A. Donenfeld wrote: > -static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) > - __aligned(sizeof(unsigned long)); > +static DEFINE_PER_CPU(u64, get_random_int_chaining); > [...] > unsigned long

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi George, On Fri, Dec 16, 2016 at 10:25 PM, George Spelvin wrote: > But yes, the sequence number is supposed to be (random base) + (timestamp). > In the old days before Canter & Siegel when the internet was a nice place, > people just used a counter that started at

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Jason A. Donenfeld wrote: > 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

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016, at 22:01, Jason A. Donenfeld wrote: > 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

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Daniel, On Fri, Dec 16, 2016 at 9:44 PM, Daniel Micay 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

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Ted, On Fri, Dec 16, 2016 at 9:43 PM, Theodore Ts'o 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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 12:41 PM, George Spelvin 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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 9:17 PM, George Spelvin 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

Re: [net-next PATCH v6 0/5] XDP for virtio_net

On Fri, Dec 16, 2016 at 01:20:02PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" > 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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi JP, On Fri, Dec 16, 2016 at 2:22 PM, Jean-Philippe Aumasson 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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

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.

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 9:41 PM, George Spelvin 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,

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

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

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

>> 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 >

RE: [PATCH] liquidio CN23XX: make timeout HZ independent

> -Original Message- > From: Nicholas Mc Guire [mailto:hof...@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-ker...@vger.kernel.org; Nicholas Mc Guire > Subject: [PATCH]

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 4:39 AM, Jason A. Donenfeld wrote: > Hey JP, > > On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson > wrote: >> Here's a tentative HalfSipHash: >> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c >> >>

Re: [PATCH 2/3] Bluetooth: btusb: Add out-of-band wakeup support

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 wrote: > Hi, > > On Wed, Dec 14, 2016 at 11:12:58AM -0800, Rajat Jain wrote: >> Some BT chips (e.g. Marvell 8997)

RE: [upstream-release] [PATCH net 2/4] fsl/fman: arm: call of_platform_populate() for arm64 platfrom

> From: Scott Wood > Sent: Thursday, December 15, 2016 8:42 PM > > On 12/15/2016 07:11 AM, Madalin Bucur wrote: > > From: Igal Liberman > > > > Signed-off-by: Igal Liberman > > --- > > drivers/net/ethernet/freescale/fman/fman.c | 10

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

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 NAK for obvious reasons ... --- tools/net/bpf_dbg.c | 2 +- 1 files changed, 1

[PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support

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

[PATCH v2 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

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

[PATCH v2 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain --- v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/bluetooth/btusb.c

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

16.12.2016, 21:08, "Sergei Shtylyov" : > 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

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

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 --- tools/net/bpf_dbg.c | 2 +- 1 files changed, 1 insertion(+), 1 deletions(-)

Re: [TSN RFC v2 0/9] TSN driver for the kernel

On Fri, Dec 16, 2016 at 01:20:57PM -0500, David Miller wrote: > From: Greg > Date: Fri, 16 Dec 2016 10:12:44 -0800 > > > On Fri, 2016-12-16 at 18:59 +0100, hen...@austad.us wrote: > >> From: Henrik Austad > >> > >> > >> The driver is directed via

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

16.12.2016, 20:35, "Joe Perches" : > 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

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

16.12.2016, 20:35, "Joe Perches" : > 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

[PATCHv5 perf/core 3/5] tools lib bpf: Add bpf_prog_{attach,detach}

Commit d8c5b17f2bc0 ("samples: bpf: add userspace example for attaching eBPF programs to cgroups") added these functions to samples/libbpf, but during this merge all of the samples libbpf functionality is shifting to tools/lib/bpf. Shift these functions there. Signed-off-by: Joe Stringer

[PATCHv5 perf/core 5/5] samples/bpf: Move open_raw_sock to separate header

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 Cc: Alexei Starovoitov Cc:

[PATCHv5 perf/core 4/5] samples/bpf: Remove perf_event_open() declaration

This declaration was made in samples/bpf/libbpf.c for convenience, but there's already one in tools/perf/perf-sys.h. Reuse that one. Committer notes: Testing it: $ make -j4 O=../build/v4.9.0-rc8+ samples/bpf/ make[1]: Entering directory '/home/build/v4.9.0-rc8+' CHK

Re: [PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

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.

[PATCHv5 perf/core 1/5] samples/bpf: Make samples more libbpf-centric

Switch all of the sample code to use the function names from tools/lib/bpf so that they're consistent with that, and to declare their own log buffers. This allow the next commit to be purely devoted to getting rid of the duplicate library in samples/bpf. Committer notes: Testing it: On a fedora

[PATCHv5 perf/core 0/5] Reuse libbpf from samples/bpf

Update tools/lib/bpf to provide the remaining bpf wrapper pieces needed by the samples/bpf/ code, then get rid of all of the duplicate BPF libraries in samples/bpf/libbpf.[ch]. --- v5: Fixed prog_size vs. instruction count API difference in bpf_load_program() REBASE: Rebased v3 that was applied

[PATCHv5 perf/core 2/5] samples/bpf: Switch over to libbpf

Now that libbpf under tools/lib/bpf/* is synced with the version from samples/bpf, we can get rid most of the libbpf library here. Committer notes: Tested it the same way as the previous patch in this series. Signed-off-by: Joe Stringer Tested-by: Arnaldo Carvalho de Melo

Re: [PATCH 2/2] encx24j600: Fix some checkstyle warnings

From: Date: Mon, 12 Dec 2016 14:29:09 +0100 > From: Jeroen De Wachter > > Signed-off-by: Jeroen De Wachter Applied.

Re: [PATCH 1/2] encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets

From: Date: Mon, 12 Dec 2016 14:29:08 +0100 > From: Jeroen De Wachter > > Before, encx24j600_rx_packets did not update encx24j600_priv's next_packet > member when an error occurred during packet handling (either because the >

Re: [PATCH 0/2] net: ethernet: hisilicon: set dev->dev.parent before PHY connect

From: Dongpo Li Date: Mon, 12 Dec 2016 20:03:41 +0800 > This patch series builds atop: > ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461 ("phy: Don't increment MDIO bus > refcount unless it's a different owner") > > I have checked all the hisilicon ethernet driver and found

[patch net] mlxsw: spectrum: Mark split ports as such

From: Ido Schimmel When a port is split we should mark it as such, as otherwise the split ports aren't renamed correctly (e.g. sw1p3 -> sw1p3s1) and the unsplit operation fails: $ devlink port split sw1p3 count 4 $ devlink port unsplit eth0 devlink answers: Invalid argument

RE: [PATCH RFC] liquidio: make timeout HZ independent

> -Original Message- > From: Nicholas Mc Guire [mailto:hof...@osadl.org] > Sent: Thursday, December 15, 2016 10:57 PM > To: Chickles, Derek > Cc: Burla, Satananda; Manlunas, Felix; Vatsavayi, Raghu; > netdev@vger.kernel.org; linux-ker...@vger.kernel.org; Nicholas Mc Guire > Subject: [PATCH

[PATCH 1/1] tools: net: bpf_dbg.c fixed keyboard typo

This patch fixed to keyboard typo, brackets not closed. I think, it should be close to parenthes. Signed-off-by: Ozgur Karatas --- 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

Re: [PATCH net] net: dsa: mv88e6xxx: Fix opps when adding vlan bridge

From: Andrew Lunn Date: Sun, 11 Dec 2016 21:07:19 +0100 > A port is not necessarily assigned to a netdev. And a port does not > need to be a member of a bridge. So when iterating over all ports, > check before using the netdev and bridge_dev for a port. Otherwise we > dereference

Re: net/3com/3c515: Fix timer handling, prevent leaks and crashes

From: Thomas Gleixner Date: Sun, 11 Dec 2016 18:31:22 +0100 (CET) > The timer handling in this driver is broken in several ways: > > - corkscrew_open() initializes and arms a timer before requesting the > device interrupt. If the request fails the timer stays armed. > >

Re: [TSN RFC v2 0/9] TSN driver for the kernel

From: Greg Date: Fri, 16 Dec 2016 10:12:44 -0800 > On Fri, 2016-12-16 at 18:59 +0100, hen...@austad.us wrote: >> From: Henrik Austad >> >> >> The driver is directed via ConfigFS as we need userspace to handle >> stream-reservation (MSRP), discovery and

Re: [PATCH] bpf: cgroup: annotate pointers in struct cgroup_bpf with __rcu

On Thu, Dec 15, 2016 at 10:53:21AM +0100, Daniel Mack wrote: > The member 'effective' in 'struct cgroup_bpf' is protected by RCU. > Annotate it accordingly to squelch a sparse warning. > > Signed-off-by: Daniel Mack Acked-by: Alexei Starovoitov was only

Re: [net-next PATCH v6 0/5] XDP for virtio_net

From: "Michael S. Tsirkin" 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

Re: [PATCH] cgroup: Fix CGROUP_BPF config

On Fri, Dec 16, 2016 at 08:33:45AM -0800, Andy Lutomirski wrote: > CGROUP_BPF depended on SOCK_CGROUP_DATA which can't be manually > enabled, making it rather challenging to turn CGROUP_BPF on. > > Signed-off-by: Andy Lutomirski Acked-by: Alexei Starovoitov

Re: [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

On Fri, 16 Dec 2016, Arnd Bergmann wrote: > With posix timers having become optional, we get a build error with > the cpts time sync option of the CPSW driver: > > drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': > drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of

Re: [TSN RFC v2 0/9] TSN driver for the kernel

On Fri, 2016-12-16 at 18:59 +0100, hen...@austad.us wrote: > From: Henrik Austad > > > 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

[TSN RFC v2 5/9] Add TSN header for the driver

From: Henrik Austad This defines the general TSN headers for network packets, the shim-interface and the central 'tsn_list' structure. Cc: "David S. Miller" Signed-off-by: Henrik Austad --- include/linux/tsn.h | 952

[TSN RFC v2 6/9] Add TSN machinery to drive the traffic from a shim over the network

From: Henrik Austad In short summary: * tsn_core.c is the main driver of tsn, all new links go through here and all data to/form the shims are handled here core also manages the shim-interface. * tsn_configfs.c is the API to userspace. TSN is driven from userspace and

[TSN RFC v2 8/9] AVB ALSA - Add ALSA shim for TSN

From: Henrik Austad This exposes a *very* rudimentary and simplistic ALSA driver that hooks into TSN to create a device for userspace. It currently only supports 44.1/48kHz sampling, 2ch, S16_LE Userspace is supposed to reserve bandwidth, find StreamID etc. To use as a

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi George, On Fri, Dec 16, 2016 at 6:36 PM, George Spelvin wrote: > A 128-bit output option was added to SipHash after the initial publication; > this is just the equivalent in 32-bit. > Personally, I'd put in a comment saying that "there's a 64-bit output > variant

[TSN RFC v2 7/9] Add TSN event-tracing

From: Henrik Austad Provide a fair debug-window into TSN. It tries to use TRACE_CLASS as much as possible and moves as much as possible of the logic into TP_printk() to minimize tracing overhead. Cc: "David S. Miller" Cc: Steven Rostedt

[TSN RFC v2 4/9] Adding TSN-driver to Intel I210 controller

From: Henrik Austad This adds support for loading the igb.ko module with tsn capabilities. This requires a 2-step approach. First enabling TSN in .config, then load the module with use_tsn=1. Once enabled and loaded, the controller will be placed in "Qav-mode" which is when

Re: [PATCH 1/2] bpf: do not use KMALLOC_SHIFT_MAX

On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote: > From: Michal Hocko > > 01b3f52157ff ("bpf: fix allocation warnings in bpf maps and integer > overflow") has added checks for the maximum allocateable size. It > (ab)used KMALLOC_SHIFT_MAX for that purpose. While

[TSN RFC v2 1/9] igb: add missing fields to TXDCTL-register

From: Henrik Austad The current list of E1000_TXDCTL-registers is incomplete. This adds the missing parts for the Transmit Descriptor Control (TXDCTL) register. The rest of these values (threshold for descriptor read/write) for TXDCTL seems to be defined in igb/igb.h, not sure

[TSN RFC v2 3/9] TSN: Add the standard formerly known as AVB to the kernel

From: Henrik Austad TSN provides a mechanism to create reliable, jitter-free, low latency guaranteed bandwidth links over a local network. It does this by reserving a path through the network. Support for TSN must be found in both the NIC as well as in the network itself. This

[TSN RFC v2 0/9] TSN driver for the kernel

From: Henrik Austad 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). Once we

[TSN RFC v2 9/9] MAINTAINERS: add TSN/AVB-entries

From: Henrik Austad Not sure how relevant this is other than making a point about maintaining it. Signed-off-by: Henrik Austad --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

[TSN RFC v2 2/9] TSN: add documentation

From: Henrik Austad Describe the overall design behind the TSN standard, the TSN-driver, requirements to userspace and new functionality introduced. Cc: "David S. Miller" Signed-off-by: Henrik Austad --- Documentation/TSN/tsn.txt |

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> It appears that hsiphash can produce either 32-bit output or 64-bit > output, with the output length parameter as part of the hash algorithm > in there. When I code this for my kernel patchset, I very likely will > only implement one output length size. Right now I'm leaning toward > 32-bit. A

Re: [PULL] virtio, vhost: new device, fixes, speedups

On Fri, Dec 16, 2016 at 9:09 AM, Michael S. Tsirkin wrote: > > Oh, that's because I set orderfile globally rather than > just for the qemu project which wants it. > Fixed, sorry about that. That explains it. I should have remembered, I think this came up once before with

  1   2   >