Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.

On Fri, Nov 18, 2016 at 1:01 AM, Jarno Rajahalme wrote: > This patch is a proof-of-concept I did a few months ago for UDP tunnel > offload support in virtio_net interface [..] What's the use case you were considering for a guest running a UDP based VTEP? > Real implementation

sanity checking iov_iter patches

Some of the vfs.git#work.iov_iter stuff touches net/*; basically, there are several missing primitives (copy_from_iter_full(), etc.) for "try to copy, tell whether it has copied the full amount requested and advance the iterator only in case of success". Most of the callers were actually

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

Hi Michael, > That's the default now, no need for makefiles to set it. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/bluetooth/Makefile| 2 -- > drivers/net/can/Makefile | 1 - >

Re: [PATCH] net: wan: Use dma_pool_zalloc

On Mon, Dec 12, 2016 at 10:12 AM, Souptick Joarder wrote: > On Fri, Dec 9, 2016 at 6:33 PM, Krzysztof Hałasa wrote: >> Souptick Joarder writes: >> >>> We should use dma_pool_zalloc instead of dma_pool_alloc/memset >>> >>>

[PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

That's the default now, no need for makefiles to set it. Signed-off-by: Michael S. Tsirkin --- drivers/bluetooth/Makefile| 2 -- drivers/net/can/Makefile | 1 - drivers/net/ethernet/altera/Makefile

[PATCH 5/8] linux: drop __bitwise__ everywhere

__bitwise__ used to mean "yes, please enable sparse checks unconditionally", but now that we dropped __CHECK_ENDIAN__ __bitwise is exactly the same. There aren't many users, replace it by __bitwise everywhere. Signed-off-by: Michael S. Tsirkin ---

[PATCH 0/8] enable endian checks for all sparse builds

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all

Re: [PATCH] vhost/vsock: Remove unused but set variable

On Fri, Nov 11, 2016 at 02:26:31PM +0100, Tobias Klauser wrote: > Remove the unused but set variable vq in vhost_transport_send_pkt() to > fix the following GCC warning when building with 'W=1': > > drivers/vhost/vsock.c:198:26: warning: variable ‘vq’ set but not used > > Signed-off-by: Tobias

Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.

On Thu, Nov 17, 2016 at 03:01:57PM -0800, Jarno Rajahalme wrote: > This patch is a proof-of-concept I did a few months ago for UDP tunnel > offload support in virtio_net interface, and rebased on to the current > net-next. > > Real implementation needs to extend the virtio_net header rather than

[PATCH net] netfilter: check duplicate config when initializing in ipt_CLUSTERIP

Now when adding an ipt_CLUSTERIP rule, it only checks duplicate config in clusterip_config_find_get(). But after that, there may be still another thread to insert a config with the same ip, then it leaves proc_create_data to do duplicate check. It's more reasonable to check duplicate config by

Re: [PATCH v4 1/4] siphash: add cryptographically secure hashtable function

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161215] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH iproute2] Fix compile warning in get_addr_1

On Tue, 13 Dec 2016 15:34:32 -0800 David Ahern wrote: > A recent cleanup causes a compile warning on Debian jessie: > > CC utils.o > utils.c: In function ‘get_addr_1’: > utils.c:486:21: warning: passing argument 1 of ‘ll_addr_a2n’ from > incompatible pointer

Re: [PATCH iproute2 1/1] tc: pass correct conversion specifier to print 'unsigned int' action index.

On Tue, 13 Dec 2016 15:31:16 -0500 Roman Mashak wrote: > Signed-off-by: Roman Mashak > Signed-off-by: Jamal Hadi Salim Applied. There are lots of unsigned vs signed int things lurking in code.

Re: [PATCH 0/6] USB support for Broadcom NSP SoC

On Tue, Dec 13, 2016 at 7:50 AM, Florian Fainelli wrote: > On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote: >> This patch set contains the usb support for Broadcom NSP SoC. >> The usb phy is connected through mdio interface. The mdio interface >> can be used

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

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

Re: net/arp: ARP cache aging failed.

On 2016/12/15 4:15, Julian Anastasov wrote: > > Hello, > > On Wed, 14 Dec 2016, YueHaibing wrote: > >> On 2016/11/26 4:40, Julian Anastasov wrote: >>> >>> So, the idea is to move TCP and other similar >>> users to the new dst_confirm_sk() method. If other >>> dst_confirm() users are

Your response Is highly appreciated!

I am Mr. Saeed Bin Salem from the National Commercial Bank Libya. I have a secured business proposition for you.

[PATCH v4 1/4] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. There are a variety of attacks known as "hashtable poisoning" in which an attacker forms some data such

[PATCH v4 4/4] random: use siphash instead of MD5 for get_random_int/long

This duplicates the current algorithm for get_random_int/long, but uses siphash instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also separates hashed fields into three values instead of one, in order to increase diffusion.

[PATCH v4 3/4] secure_seq: use siphash instead of md5_transform

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

[PATCH v4 2/4] siphash: add N[qd]word helpers

These restore parity with the jhash interface by providing high performance helpers for common input sizes. Linus doesn't like the use of "qword" and "dword", but I haven't been able to come up with another name for these that fits as well. Signed-off-by: Jason A. Donenfeld Cc:

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 8:12 PM, Jason A. Donenfeld wrote: > I think this opens up a big window for optimizing it even > further. I optimized it a bit further and siphash is now the clear winner over chacha: [1.784801] random benchmark!! [1.785161]

Re: [BISECTED] v4.9: OCTEON ethernet crash

On 12/14/2016 05:12 PM, Aaro Koskinen wrote: > Hi, > > On Wed, Dec 14, 2016 at 05:00:59PM -0800, Florian Fainelli wrote: >> On 12/14/2016 04:57 PM, Aaro Koskinen wrote: >>> On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote: On 12/14/2016 04:32 PM, Aaro Koskinen wrote: >

[PATCH] staging: octeon: Call SET_NETDEV_DEV()

The Octeon driver calls into PHYLIB which now checks for net_device->dev.parent, so make sure we do set it before calling into any MDIO/PHYLIB related function. Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner") Reported-by: Aaro Koskinen

Re: [BISECTED] v4.9: OCTEON ethernet crash

Hi, On Wed, Dec 14, 2016 at 05:00:59PM -0800, Florian Fainelli wrote: > On 12/14/2016 04:57 PM, Aaro Koskinen wrote: > > On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote: > >> On 12/14/2016 04:32 PM, Aaro Koskinen wrote: > >>> Git bisect points to: > >>> > >>> commit

Re: [BISECTED] v4.9: OCTEON ethernet crash

On 12/14/2016 04:57 PM, Aaro Koskinen wrote: > Hi, > > On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote: >> On 12/14/2016 04:32 PM, Aaro Koskinen wrote: >>> Git bisect points to: >>> >>> commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461 >>> Author: Florian Fainelli

Re: [BISECTED] v4.9: OCTEON ethernet crash

Hi, On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote: > On 12/14/2016 04:32 PM, Aaro Koskinen wrote: > > Git bisect points to: > > > > commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461 > > Author: Florian Fainelli > > Date: Tue Dec 6 20:54:43 2016 -0800 > >

[PATCH net-next 1/2] inet: Don't go into port scan when looking for specific bind port

inet_csk_get_port is called with port number (snum argument) that may be zero or nonzero. If it is zero, then the intent is to find an available ephemeral port number to bind to. If snum is non-zero then the caller is asking to allocate a specific port number. In the latter case we never want to

[PATCH net-next 2/2] inet: Fix get port to handle zero port number with soreuseport set

A user may call listen with binding an explicit port with the intent that the kernel will assign an available port to the socket. In this case inet_csk_get_port does a port scan. For such sockets, the user may also set soreuseport with the intent a creating more sockets for the port that is

[PATCH net-next 0/2] inet: Fixes for inet_csk_get_port and soreusport

This patch set fixes a couple of issues I noticed while debugging our softlockup issue in inet_csk_get_port. - Don't allow jump into port scan in inet_csk_get_port if function was called with non-zero port number (looking up explicit port number). - When inet_csk_get_port is called with zero

Re: [PATCH net-next 1/1] driver: ipvlan: Define common functions to decrease duplicated codes used to add or del IP address

On Wed, Dec 14, 2016 at 10:52 PM, wrote: > From: Gao Feng > > There are some duplicated codes in ipvlan_add_addr6/4 and > ipvlan_del_addr6/4. Now define two common functions ipvlan_add_addr > and ipvlan_del_addr to decrease the duplicated codes. > It could

Re: [PATCH net] bpf, test_verifier: fix a test case error result on unprivileged

On 12/14/16 4:39 PM, Daniel Borkmann wrote: Running ./test_verifier as unprivileged lets 1 out of 98 tests fail: [...] #71 unpriv: check that printk is disallowed FAIL Unexpected error message! 0: (7a) *(u64 *)(r10 -8) = 0 1: (bf) r1 = r10 2: (07) r1 += -8 3: (b7) r2 = 8

Re: [BISECTED] v4.9: OCTEON ethernet crash

On 12/14/2016 04:32 PM, Aaro Koskinen wrote: > Hi, > > I'm getting the following crash on every boot on OCTEON (EdgeRouter Lite) > with v4.9 (right after setting up ethernet bridging): > > [ 16.814902] CPU 0 Unable to handle kernel paging request at virtual > address 0080, epc ==

[PATCH net] bpf, test_verifier: fix a test case error result on unprivileged

Running ./test_verifier as unprivileged lets 1 out of 98 tests fail: [...] #71 unpriv: check that printk is disallowed FAIL Unexpected error message! 0: (7a) *(u64 *)(r10 -8) = 0 1: (bf) r1 = r10 2: (07) r1 += -8 3: (b7) r2 = 8 4: (bf) r3 = r1 5: (85) call bpf_trace_printk#6

[BISECTED] v4.9: OCTEON ethernet crash

Hi, I'm getting the following crash on every boot on OCTEON (EdgeRouter Lite) with v4.9 (right after setting up ethernet bridging): [ 16.814902] CPU 0 Unable to handle kernel paging request at virtual address 0080, epc == 81458570, ra == 81458804 [ 16.827805]

[PATCH net] bpf: fix regression on verifier pruning wrt map lookups

Commit 57a09bf0a416 ("bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers") introduced a regression where existing programs stopped loading due to reaching the verifier's maximum complexity limit, whereas prior to this commit they were loading just fine; the affected program has roughly 2k

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 3:34 PM, Jason A. Donenfeld wrote: > > Or does your reasonable dislike of "word" still allow for the use of > dword and qword, so that the current function names of: dword really is confusing to people. If you have a MIPS background, it means 64 bits.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hey Linus, On Thu, Dec 15, 2016 at 12:30 AM, Linus Torvalds wrote: > No. The bug is talking about "words" in the first place. > > Depending on your background, a "word" can be generally be either 16 > bits or 32 bits (or, in some cases, 18 bits). > > In theory, a

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld wrote: > > So actually jhash_Nwords makes no sense, since it takes dwords > (32-bits) not words (16-bits). The siphash analog should be called > siphash24_Nqwords. No. The bug is talking about "words" in the first place.

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi Hannes, On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa wrote: > I fear that the alignment requirement will be a source of bugs on 32 bit > machines, where you cannot even simply take a well aligned struct on a > stack and put it into the normal

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hey Tom, On Thu, Dec 15, 2016 at 12:14 AM, Tom Herbert wrote: > I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword > functions are good enough. If someone needs to hash over some odd > length they can either put them in a structure padded to 64 bits or > call

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld wrote: > Hey Tom, > > On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote: >> Those look good, although I would probably just do 1,2,3 words and >> then have a function that takes n words like jhash. Might

[PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/sfc/ethtool.c| 35 --- drivers/net/ethernet/sfc/mcdi_port.c | 60

[PATCH perf/core REBASE 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:

[PATCH perf/core REBASE 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: Designing a safe RX-zero-copy Memory Model for Networking

On Wed, Dec 14, 2016 at 1:29 PM, Jesper Dangaard Brouer wrote: > On Wed, 14 Dec 2016 08:45:08 -0800 > Alexander Duyck wrote: > >> I agree. This is a no-go from the performance perspective as well. >> At a minimum you would have to be zeroing out the

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hey Tom, On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote: > Those look good, although I would probably just do 1,2,3 words and > then have a function that takes n words like jhash. Might want to call > these dword to distinguish from 32 bit words in jhash. So actually

[PATCH perf/core REBASE 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

Re: [PATCHv3 perf/core 0/7] Reuse libbpf from samples/bpf

On 14 December 2016 at 06:55, Arnaldo Carvalho de Melo wrote: > Em Wed, Dec 14, 2016 at 10:25:01AM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Fri, Dec 09, 2016 at 04:30:54PM +0100, Daniel Borkmann escreveu: >> > On 12/09/2016 04:09 PM, Arnaldo Carvalho de Melo wrote: >> >

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

Arnaldo, here's the refresh of this series that you requested after the merge with net-next. It is based on commit 1f125a4aa4d8 ("tools lib bpf: Add flags to bpf_create_map()") from perf/core today. Patch #3 is new, but trivial. It has the biggest changes compared to the version that you

[PATCH perf/core REBASE 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. Signed-off-by: Joe Stringer Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Wang Nan Link:

[PATCH perf/core REBASE 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. Signed-off-by: Joe Stringer

[PATCH net] net: vrf: Drop conntrack data after pass through VRF device on Tx

Locally originated traffic in a VRF fails in the presence of a POSTROUTING rule. For example, $ iptables -t nat -A POSTROUTING -s 11.1.1.0/24 -j MASQUERADE $ ping -I red -c1 11.1.1.3 ping: Warning: source address might be selected on device other than red. PING 11.1.1.3

Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 11:03 AM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. I have asked you twice already this question, but could not determine from your response what

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 14.12.2016 13:46, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:56 AM, David Laight > wrote: >> ... >>> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]) >> ... >>> + u64 k0 = get_unaligned_le64(key); >>> + u64

Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on next-20161214] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add

Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on next-20161214] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add

Re: [PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on next-20161214] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 12:55 PM, Jason A. Donenfeld wrote: > Hey Tom, > > Just following up on what I mentioned in my last email... > > On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld wrote: >> I think your suggestion for (2) will contribute to further >>

Re: Designing a safe RX-zero-copy Memory Model for Networking

On Wed, 14 Dec 2016 08:45:08 -0800 Alexander Duyck wrote: > I agree. This is a no-go from the performance perspective as well. > At a minimum you would have to be zeroing out the page between uses to > avoid leaking data, and that assumes that the program we are

Re: Designing a safe RX-zero-copy Memory Model for Networking

On Wed, 14 Dec 2016, Hannes Frederic Sowa wrote: > Wouldn't changing of the pages cause expensive TLB flushes? Yes so you would only want that feature if its realized at the page table level for debugging issues. Once you have memory registered with the hardware device then also the device

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Interesting. Evidently gcc 4.8 doesn't like my use of: enum siphash_lengths { SIPHASH24_KEY_LEN = 16, SIPHASH24_ALIGNMENT = 8 }; I'll convert this to the more boring: #define SIPHASH24_KEY_LEN 16 #define SIPHASH24_ALIGNMENT 8

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add-cryptographically

Re: Designing a safe RX-zero-copy Memory Model for Networking

On Wed, 14 Dec 2016 08:32:10 -0800 John Fastabend wrote: > On 16-12-14 01:39 AM, Jesper Dangaard Brouer wrote: > > On Tue, 13 Dec 2016 12:08:21 -0800 > > John Fastabend wrote: > > > >> On 16-12-13 11:53 AM, David Miller wrote: > >>> From:

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 9:12 PM, Tom Herbert wrote: > If you pad the data structure to 64 bits then we can call the version > of siphash that only deals in 64 bit words. Writing a zero in the > padding will be cheaper than dealing with odd lengths in siphash24. On Wed, Dec

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hey Tom, Just following up on what I mentioned in my last email... On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld wrote: > I think your suggestion for (2) will contribute to further > optimizations for (1). In v2, I had another patch in there adding > siphash_1word,

[PATCH net] vxlan: fix unused variable warning

Fixes commit 4528520d315ac1 ("vxlan: add ipv6 proxy support") which added code that caused this warning: drivers/net/vxlan.c: In function ‘neigh_reduce’: drivers/net/vxlan.c:1556:25: warning: variable ‘saddr’ set but not used Signed-off-by: Stephen Hemminger ---

Re: [PATCH net] ibmveth: calculate gso_segs for large packets

On Tue, Dec 13, 2016 at 06:15:09PM -0600, Thomas Falcon wrote: > Include calculations to compute the number of segments > that comprise an aggregated large packet. > > Signed-off-by: Thomas Falcon Reviewed-by: Marcelo Ricardo Leitner >

Re: Designing a safe RX-zero-copy Memory Model for Networking

On 14.12.2016 20:43, Christoph Lameter wrote: > On Wed, 14 Dec 2016, David Laight wrote: > >> If the kernel is doing ANY validation on the frames it must copy the >> data to memory the application cannot modify before doing the validation. >> Otherwise the application could change the data

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hey Jason, On 14.12.2016 20:38, Jason A. Donenfeld wrote: > On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa > wrote: >> I don't think this helps. Did you test it? I don't see reason why >> padding could be left out between `d' and `end' because of the flexible

Re: net/arp: ARP cache aging failed.

Hello, On Wed, 14 Dec 2016, YueHaibing wrote: > On 2016/11/26 4:40, Julian Anastasov wrote: > > > > So, the idea is to move TCP and other similar > > users to the new dst_confirm_sk() method. If other > > dst_confirm() users are left, they should be checked > > if dsts with

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 4:53 AM, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:51 AM, David Laight > wrote: >> From: Jason A. Donenfeld >>> Sent: 14 December 2016 00:17 >>> This gives a clear speed and security improvement. Rather

Re: [PATCH scsi 0/3] cxgb4i: add support for Chelsio T6 adapters

> "Varun" == Varun Prakash writes: Varun> This patch series adds support for Chelsio T6 adapters in iSCSI Varun> initiator offload driver(cxgb4i). Applied to 4.10/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v3 3/3] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

> "Manish" == Manish Rangankar writes: Manish> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI Manish> specific module for 41000 Series Converged Network Adapters by Manish> QLogic. Applied to 4.10/scsi-fixes. -- Martin K. Petersen Oracle Linux

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi Hannes, On Wed, Dec 14, 2016 at 4:09 PM, Hannes Frederic Sowa wrote: > Yes, numbers would be very usable here. I am mostly concerned about > small plastic router cases. E.g. assume you double packet processing > time with a change of the hashing function at what

RE: Designing a safe RX-zero-copy Memory Model for Networking

On Wed, 14 Dec 2016, David Laight wrote: > If the kernel is doing ANY validation on the frames it must copy the > data to memory the application cannot modify before doing the validation. > Otherwise the application could change the data afterwards. The application is not allowed to change the

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa wrote: > I don't think this helps. Did you test it? I don't see reason why > padding could be left out between `d' and `end' because of the flexible > array member? Because the type u8 doesn't require

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hi Tom, On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert wrote: > "super fast" is relative. My quick test shows that this faster than > Toeplitz (good, but not exactly hard to achieve), but is about 4x > slower than jhash. Fast relative to other cryptographically secure PRFs.

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 19:06, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: >> Just marking the structure __packed, whether necessary or not, makes >> the compiler assume that the members are not aligned and causes >> byte-by-byte

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > "super fast" is

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

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

[PATCH 3/3] Bluetooth: btusb: Configure Marvel 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 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. (This label will also be used in subsequent patches). Signed-off-by: Rajat Jain --- drivers/bluetooth/btusb.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hi again, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > [3.606139] random benchmark!! > [3.606276] get_random_int # cycles: 326578 > [3.606317] get_random_int_new # cycles: 95438 > [3.607423] get_random_bytes # cycles: 2653388 Looks to me like my siphash

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 08:25 AM, Arvind Yadav wrote: Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Have you ever seen this failure in the wild? How was the patch tested? Thanks, David Daney

[PATCH net] net: vrf: Fix NAT within a VRF

Connection tracking with VRF is broken because the pass through the VRF device drops the connection tracking info. Removing the call to nf_reset allows DNAT and MASQUERADE to work across interfaces within a VRF. Fixes: 73e20b761acf ("net: vrf: Add support for PREROUTING rules on vrf device")

[v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap

Here, If devm_ioremap will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 6 ++ 1 file changed, 6

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi, As per your suggestion, I have change the subject. Thanks On Thursday 15 December 2016 12:24 AM, Florian Fainelli wrote: On 12/14/2016 10:39 AM, arvind Yadav wrote: Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On

stmmac: lockups (was Re: Synopsys Ethernet QoS)

Hi! > I know that this is completely of topic, but I am facing a dificulty with > stmmac. I have interrupts, mac well configured rx packets being received > successfully, but TX is not working, resulting in Tx errors = Total TX > packets. > I have made a lot of debug and my conclusions is that

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:39 AM, arvind Yadav wrote: > Hi David, > > I have gave my comment. > > Thanks > Arvind > > On Wednesday 14 December 2016 11:44 PM, David Daney wrote: >> On 12/14/2016 10:06 AM, arvind Yadav wrote: >>> Yes, I have seen this error. We have a device with very less memory. >>>

[PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A.

[PATCH v3 1/3] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

[PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. This makes absolutely no sense

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi David, On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: > Just marking the structure __packed, whether necessary or not, makes > the compiler assume that the members are not aligned and causes > byte-by-byte accesses to be performed for words. > Never, _ever_, use

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has 3.10 kernel version. In this device, we were getting Page allocation failure. Vmalloc size was not enough to run all application. So we have decide to

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > One somewhat undesirable aspect of the current algorithm is that we > never change random_int_secret. Why exactly would this be a problem? So long as the secret is kept secret, the PRF is secure. If an attacker can

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 > In all current uses of __packed in the code, I think the impact is > precisely zero, because all structures have members in descending > order of size, with each member being a perfect multiple of the one > below

Re: [PATCH] infiniband: nes: nes_nic: use new api ethtool_{get|set}_link_ksettings

On 10/25/2016 11:29 AM, Philippe Reynes wrote: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Thanks, applied. -- Doug Ledford GPG Key ID: 0E572FDD

  1   2   >