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:
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
https://gi
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. Other modules like ipvlan,
>> macvlan, and
> 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 sur
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
> HalfSipHash on 32-bit.
I already
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
---
net/x25/sysctl_net_x25.
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
---
drivers/isdn/i4l/isdn_c
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
---
drivers/net/ethernet/br
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
---
drivers/net/wan/lmc/lmc
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
---
net/decnet/dn_dev.c | 2
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
---
net/atm/lec.c
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
---
drivers/isdn/gigaset/ba
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 verif
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 a
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 gro
ly use #if defined(CONFIG_OF_IRQ) in the code.
Signed-off-by: Sudip Mukherjee
---
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 insertion(+), 1 deletion(-)
diff --git a/d
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 Ho
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, 2016-12-15 at 10:41 +0530, Souptick Joarder w
> 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 disc
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 allocation warnings in
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
> > > >
> > > > 01b3f52157ff (
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, Dec 15, 2016 at 7:07 PM, Hannes Frederic Sowa
wrote:
Hi Josef,
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 integer
> > > over
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.
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,
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
>>> wrote:
Hi Josef,
On 15.12.2016 19:53, Josef
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 already have a massive speed-
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.
>
> This is tricky. The entir
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 extensive
>> literature, but I can at l
> 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
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 g
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, draft
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, 2016 at 6:32 PM, Tom Herbert
wrote:
On Tue, Dec 13, 201
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
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 size. It
> > (ab)used
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 as initially as uncont
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
---
drivers/isdn/hisax/config.c | 16
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 get_random_long(void)
> {
> -
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 boot time.
>
> But then someon
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 haven'
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 us
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 with halfsiphash?
>
> Ha
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 rekeyed the sec
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 nsecs). So that might closer
>
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 collisions, i.e. ((H(x) ^ H(y)) & bi
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 it further with t
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 construction (BLAKE, SipHash, NORX), I'm
>
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. Th
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
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, it
should be possible to cond
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 sec
>> 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
> l
> -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] l
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
>>
>> Haven't computed the cycle count nor measured its s
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) contain a wakeup pin that can
> 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 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff
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 insertion(+), 1 deletions(-)
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 ho
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
--
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 b/drivers/bluetooth/btusb.c
index 2f633df..ce2
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
>> ---
>> tools/net/bpf_dbg.c | 2 +-
>> 1 files
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(-)
diff --git a/tools/net/bpf
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 ConfigFS as we need userspace to handle
> >> st
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 send them.
Also, c
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 send them.
Dear Pe
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
---
v5:
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: Daniel Borkmann
Cc: Wang N
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.
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 include/config/ke
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
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 t
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
Cc: Alexei Starovoito
From:
Date: Mon, 12 Dec 2016 14:29:09 +0100
> From: Jeroen De Wachter
>
> Signed-off-by: Jeroen De Wachter
Applied.
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
> packet's RSV header indicates an error or because the
> encx24j600_r
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 only two drivers
> need to b
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
[ 598.565307] mlxsw_
> -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
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
index 4f254bc..f715f46 10
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 a NULL pointer.
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.
>
> A second call to cor
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 enumeration (IEEE 1722.1) and
>> whatever
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 wondering whether this is really needed
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
Michael, thanks for reviewing.
Sin
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
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
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 includes running an
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
1 file changed, 952 ins
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 Talker:
mkdir /config/t
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 that's not implemented" and pu
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 (maintainer:TRACING)
Cc: Ingo Molnar (maintainer:TRACING
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 a link is created, c
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 the credit-based shap
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 this is not incorrect
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 why this is split
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 adds required hook
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 have all the require
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 63cefa6..7c5afd2 100644
--- a/MAINTAINERS
+++ b/MAI
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 | 345 ++
1 file ch
> 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 1
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 somebody else.
Yeah, for
1 - 100 of 147 matches
Mail list logo
