On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
For the new API a solution for "fallback mechanisms" should be clean
though and I am looking to stay as far as possible from the existing
mess. A solution to help both the old API and new API is possible for
the "fallback mechanism" though -- but f
schedule_timeout_* takes a timeout in jiffies but the code currently is
passing in a constant which makes this timeout HZ dependent, so pass it
through msecs_to_jiffies() to fix this up.
Fixes: commit b0d66369edcd ("liquidio VF error handling")
Signed-off-by: Nicholas Mc Guire
---
Problem found
On Thu, Dec 15, 2016 at 10:18 PM, Joe Perches wrote:
> On Thu, 2016-12-15 at 10:41 +0530, Souptick Joarder wrote:
>> 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 shou
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 wrote:
> > > On Mon, Dec 12, 2016 at 10:12 AM, Souptick Joarder
> > > wrote:
> > > > On Fri, Dec 9, 2016 at 6:33 PM, Krzysztof
On Thu, Dec 15, 2016 at 06:59:47PM -0800, Vishwanathapura, Niranjana wrote:
> We have made the hfi_vnic driver dependent on CONFIG_X86_64.
Er, don't do that either?
> >>+struct __hfi_vesw_info {
> >>+ u16 fabric_id;
> >>+ u16 vesw_id;
> >>+
> >>+ u8 rsvd0[6];
> >>+ u16 def_port_mask;
On Thu, Dec 15, 2016 at 08:24:05PM -0500, ira.weiny wrote:
> > The main share is the 'skb send' part, we've talked about hoisting
> > that out of ipoib in the past anyhow. A generic verb along those lines
> > would probably allow the sdma optimization for hfi for both this new
> > ulp and ipoib wit
On Thu, Dec 15, 2016 at 09:56:11AM -0700, Jason Gunthorpe wrote:
On Wed, Dec 14, 2016 at 11:59:32PM -0800, Vishwanathapura, Niranjana wrote:
create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Kconfig
create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Makefile
Stil NAK on these path
'ifconfig eth0 down' makes r6040_close() trigger:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
to outside of the module's private spin_lock_irq block.
Found on a Versalogic Tomcat SBC with a Vortex86 SoC
s1660e_
Jean-Philippe Aumasson wrote:
> If a halved version of SipHash can bring significant performance boost
> (with 32b words instead of 64b words) with an acceptable security level
> (64-bit enough?) then we may design such a version.
It would be fairly significant, a 2x speed benefit on a lot of 32-b
On Thu, 2016-12-15 at 14:17 +0530, shakya@samsung.com wrote:
> From: Shakya Sundar Das
>
> This patch will check segs for being NULL in tcp_gso_segment()
> before calling skb_shinfo(segs) from skb_is_gso(segs), otherwise
> kernel can run into a NULL-pointer dereference.
>
> Signed-off-by: Sh
Hey again,
This keeps getting more ambitious, which is good I suppose. If the frequency
of new versioned patchsets is too high for LKML and not customary, please let
me know. Otherwise, read on to see what's new this time...
With Hannes' suggestion, there is now only one siphash() function, which
The md5_transform function is no longer used any where in the tree,
except for the crypto api's actual implementation of md5, so we can drop
the function from lib and put it as a static function of the crypto
file, where it belongs. There should be no new users of md5_transform,
anyway, since there
SHA1 is slower and less secure than SipHash, and so replacing syncookie
generation with SipHash makes natural sense. Some BSDs have been doing
this for several years in fact.
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/syncookies.c | 20
net/ipv6/syncookies.c | 37 +++
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.
The
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 va
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, or as a
general PRF for short input use cases, such as sequence numbers or RNG
chaining.
For the first usa
On Thu, Dec 15, 2016 at 10:01:09AM -0700, Jason Gunthorpe wrote:
On Wed, Dec 14, 2016 at 11:59:35PM -0800, Vishwanathapura, Niranjana wrote:
+/**
+ * union hfi_vnic_bypass_hdr - VNIC bypass header
+ * @slid: source lid
+ * @length: length of packet
+ * @becn: backward explicit congestion notific
On Thu, Dec 15, 2016 at 10:07:13AM -0700, Jason Gunthorpe wrote:
On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
1) Since your intent is to make this work with multiple versions of the
hfi drivers, I disagree with Jason that just because there is only one
driver today that we shou
On Thu, Dec 15, 2016 at 08:24:05PM -0500, ira.weiny wrote:
On Thu, Dec 15, 2016 at 11:48:37AM -0700, Jason Gunthorpe wrote:
On Thu, Dec 15, 2016 at 01:19:18PM -0500, Doug Ledford wrote:
> On 12/15/2016 12:07 PM, Jason Gunthorpe wrote:
> > On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wr
On Thu, Dec 15, 2016 at 3:05 PM, Michael S. Tsirkin wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
Pulled, but I wonder...
> Documentation/translations/zh_CN/sparse.txt| 7 +-
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> dri
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:
https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add-cryptographically
On 2016/12/14 23:34, woojung@microchip.com wrote:
>> I just want to commit the unregister patch and found this patch. Good job!
>> But I consider this patch may miss something.
>> If one SoC has 2 MAC ports and each port uses the different network driver,
>> the 2 drivers may register fixup fo
On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
>> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
>>> (Adding Luis because he has been working on request_firmware() lately)
>>>
>>> Pali Rohár writes:
>>>
>> So no, there is no argument against.
On 15 December 2016 at 14:00, Joe Stringer wrote:
> On 15 December 2016 at 10:34, Arnaldo Carvalho de Melo
> wrote:
>> Em Thu, Dec 15, 2016 at 03:29:18PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> > Em Wed, Dec 1
On Thu, Dec 15, 2016 at 11:48:37AM -0700, Jason Gunthorpe wrote:
> On Thu, Dec 15, 2016 at 01:19:18PM -0500, Doug Ledford wrote:
> > On 12/15/2016 12:07 PM, Jason Gunthorpe wrote:
> > > On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
> > >
> > >> 1) Since your intent is to make this
On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the curent state of the trf7970a is reading but
> a request has been made to send a command.
>
> The solution is to proper
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry
Missing commit description.
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 2d2a077..b4c37ab 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1048,6 +1049,11
Hi Geoff.
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry
Please add an informative commit description to all of your commits.
No matter how trivial this patch may seem to you now, it may not be
to others (or to you in a few years).
> diff --git a/driver
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, 2016 at 3:03 PM, Craig Gallek
>> wrote:
>>> On Tue, Dec 13, 2016 at 3:51 PM, Tom Herbert
>>> wrote:
I think there may be some suspicious code in inet_csk_get_port. A
On 16.12.2016 00:43, Jason A. Donenfeld wrote:
> Hi Hannes,
>
> Good news.
>
> On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa
> wrote:
>>> How's that sound?
>>
>> I am still very much concerned about the API.
>
> Thanks for pushing me and putting up with my daftness... the constant
> fo
On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa
wrote:
> By the way, if you target net-next, it is currently closed. So no need
> to hurry.
Honestly I have no idea what I'm targeting. The hash function touches
lib/. The secure_seq stuff touches net/. The rng stuff touches
random.c. Shall t
Hi Hannes,
Good news.
On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa
wrote:
>> How's that sound?
>
> I am still very much concerned about the API.
Thanks for pushing me and putting up with my daftness... the constant
folding works absolutely perfectly. I've run several tests. When gcc
k
> If a halved version of SipHash can bring significant performance boost
> (with 32b words instead of 64b words) with an acceptable security level
> (64-bit enough?) then we may design such a version.
I was thinking if the key could be pushed to 80 bits, that would be nice,
but honestly 64 bits is
On Thu, Dec 15, 2016 at 5:39 PM, Tom Herbert wrote:
> On Thu, Dec 15, 2016 at 10:53 AM, Josef Bacik wrote:
>> On Tue, Dec 13, 2016 at 6:32 PM, Tom Herbert wrote:
>>>
>>> On Tue, Dec 13, 2016 at 3:03 PM, Craig Gallek
>>> wrote:
On Tue, Dec 13, 2016 at 3:51 PM, Tom Herbert
wrote:
On Thu, Dec 15, 2016 at 12:12:04PM -0800, John Fastabend wrote:
> This implements virtio_net for the mergeable buffers and big_packet
> modes. I tested this with vhost_net running on qemu and did not see
> any issues. For testing num_buf > 1 I added a hack to vhost driver
> to only but 100 bytes pe
> While SipHash is extremely fast for a cryptographically secure function,
> it is likely a tiny bit slower than the insecure jhash, and so replacements
> will be evaluated on a case-by-case basis based on whether or not the
> difference in speed is negligible and whether or not the current jhash u
On Thu, Dec 15, 2016 at 10:53 AM, Josef Bacik wrote:
> On Tue, Dec 13, 2016 at 6:32 PM, Tom Herbert wrote:
>>
>> On Tue, Dec 13, 2016 at 3:03 PM, Craig Gallek
>> wrote:
>>>
>>> On Tue, Dec 13, 2016 at 3:51 PM, Tom Herbert
>>> wrote:
I think there may be some suspicious code in inet_
On 15.12.2016 22:32, Lino Sanfilippo wrote:
> Ah ok. Then maybe priv->hw->dma->stop_tx() does not do the job correctly
> (stop the
> tx path properly) and the HW is still active on the tx path while the tx
> buffers are
> freed. OTOH stmmac_release() also stops the phy before the tx (and rx) pat
From: Jaret Cantu
Repeated polling attempts cause a NULL dereference error to occur.
This is because the curent state of the trf7970a is reading but
a request has been made to send a command.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
---
driver
From: Geoff Lansberry
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
drivers/nfc/trf7970a.c | 42 --
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documen
From: Geoff Lansberry
---
Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 13 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentat
On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
> wrote:
> > ARM64 and x86-64 have memory operations that are not vector operations
> > that operate on 128 bit memory.
>
> Fair enough. imull I guess.
imull is into rdx:ra
Hi!
> >> The driver uses a private lock for synchronization of the xmit function and
> >> the xmit completion handler, but since the NETIF_F_LLTX flag is not set,
> >> the xmit function is also called with the xmit_lock held.
> >>
> >> On the other hand the completion handler uses the reverse loc
On Wed, Dec 14, 2016 at 11:15 AM, Thomas Falcon
wrote:
> Include calculations to compute the number of segments
> that comprise an aggregated large packet.
>
> Signed-off-by: Thomas Falcon
Reviewed-by: Jonathan Maxwell
> ---
> drivers/net/ethernet/ibm/ibmveth.c | 12 ++--
> 1 file cha
On 15 December 2016 at 10:34, Arnaldo Carvalho de Melo wrote:
> Em Thu, Dec 15, 2016 at 03:29:18PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
>> > Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
>> > >
Hi Jarod,
On 12/15/16, Jarod Wilson wrote:
> On 2016-12-14 6:12 PM, 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
>> ---
>> drivers/net/ethernet/sfc/ethtool.c| 35
On 15.12.2016 22:25, Jason A. Donenfeld wrote:
> On Thu, Dec 15, 2016 at 10:17 PM, Hannes Frederic Sowa
> wrote:
>> And I was exactly questioning this.
>>
>> static unsigned int inet6_hash_frag(__be32 id, const struct in6_addr *saddr,
>> const struct in6_addr *d
From: Harald Welte
When generating a GTPv1 header in gtp1_push_header(), initialize the
'reserved' bit to zero. All 3GPP specifications for GTPv1 from Release
99 through Release 13 agree that a transmitter shall set this bit to
zero, see e.g. Note 0 of Figure 2 in Section 6 of 3GPP TS 29.060 v13
Hi David,
The following patchset contains two GTP tunneling fixes for your net
tree, they are:
1) Offset to IPv4 header in gtp_check_src_ms_ipv4() is incorrect, thus
this function always succeeds and therefore this defeats this sanity
check. This allows packets that have no PDP to go though
From: Lionel Gauthier
gtp_check_src_ms_ipv4() did not find the PDP context matching with the
UE IP address because the memory location is not right, but the result
is inverted by the Boolean "not" operator. So whatever is the PDP
context, any call to this function is successful.
Signed-off-by:
On 15.12.2016 22:03, Pavel Machek wrote:
>
> I actually did experiment with adding locking there, too, and no, no
> luck. It seems stmmac_tx_err() is more broken than just locking.
>
Ah ok. Then maybe priv->hw->dma->stop_tx() does not do the job correctly (stop
the
tx path properly) and the HW
On Thu, Dec 15, 2016 at 10:17 PM, Hannes Frederic Sowa
wrote:
> And I was exactly questioning this.
>
> static unsigned int inet6_hash_frag(__be32 id, const struct in6_addr *saddr,
> const struct in6_addr *daddr)
> {
> net_get_random_once(&ip6_frags.rnd,
This adds support for the XDP_TX action to virtio_net. When an XDP
program is run and returns the XDP_TX action the virtio_net XDP
implementation will transmit the packet on a TX queue that aligns
with the current CPU that the XDP packet was processed on.
Before sending the packet the header is ze
On 15.12.2016 21:43, Jason A. Donenfeld wrote:
> On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
> wrote:
>> ARM64 and x86-64 have memory operations that are not vector operations
>> that operate on 128 bit memory.
>
> Fair enough. imull I guess.
>
>> How do you know that the compiler for
On Thu, Dec 15, 2016 at 10:14 PM, Linus Torvalds
wrote:
> I think you can/should just use the natural alignment for "u64".
>
> For architectures that need 8-byte alignment, u64 will already be
> properly aligned. For architectures (like x86-32) that only need
> 4-byte alignment, you get it.
I sho
On Thu, Dec 15, 2016 at 1:11 PM, Jason A. Donenfeld wrote:
>
> Indeed, I stand corrected. But in any case, the use of __aligned(8) in
> the patchset ensures that things are fixed and that we don't have this
> issue.
I think you can/should just use the natural alignment for "u64".
For architectur
Hi!
> sorry for the late reply.
No problem. Thanks for the help.
> On 11.12.2016 21:11, Pavel Machek wrote:
> >
> > Do you understand what stmmac_tx_err(priv); is supposed to do? In
> > particular, if it is called while the driver is working ok -- should
> > the driver survive that?
>
> As far
On Thu, Dec 15, 2016 at 10:09 PM, Peter Zijlstra wrote:
> On Thu, Dec 15, 2016 at 07:50:36PM +0100, Jason A. Donenfeld wrote:
>> There's no 32-bit platform
>> that will trap on a 64-bit unaligned access because there's no such
>> thing as a 64-bit access there. In short, we're fine.
>
> ARMv7 LPAE
On 15.12.2016 22:04, Peter Zijlstra wrote:
> On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote:
>> On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
>> wrote:
>>> ARM64 and x86-64 have memory operations that are not vector operations
>>> that operate on 128 bit memory.
>>
>> F
On Thu, Dec 15, 2016 at 07:50:36PM +0100, Jason A. Donenfeld wrote:
> There's no 32-bit platform
> that will trap on a 64-bit unaligned access because there's no such
> thing as a 64-bit access there. In short, we're fine.
ARMv7 LPAE is a 32bit architecture that has 64bit load/stores IIRC.
x86 ha
On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
wrote:
> ARM64 and x86-64 have memory operations that are not vector operations
> that operate on 128 bit memory.
Fair enough. imull I guess.
> How do you know that the compiler for some architecture will not chose a
> more optimized instruct
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, or as a
general PRF for short input use cases, such as sequence numbers or RNG
chaining.
For the first usa
From: John Fastabend
This adds XDP support to virtio_net. Some requirements must be
met for XDP to be enabled depending on the mode. First it will
only be supported with LRO disabled so that data is not pushed
across multiple buffers. Second the MTU must be less than a page
size to avoid having t
XDP requires using isolated transmit queues to avoid interference
with normal networking stack (BQL, NETDEV_TX_BUSY, etc). This patch
adds a XDP queue per cpu when a XDP program is loaded and does not
expose the queues to the OS via the normal API call to
netif_set_real_num_tx_queues(). This way th
These restore parity with the jhash interface by providing high
performance helpers for common input sizes.
Signed-off-by: Jason A. Donenfeld
Cc: Tom Herbert
---
include/linux/siphash.h | 33 ++
lib/siphash.c | 157 +---
lib/test_si
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 va
This adds a warning for drivers to use when encountering an invalid
buffer for XDP. For normal cases this should not happen but to catch
this in virtual/qemu setups that I may not have expected from the
emulation layer having a standard warning is useful.
Signed-off-by: John Fastabend
---
includ
Rather than allocating efx_ptp_data, a buffer, a workqueue, etc., and then
ultimately deciding not to call ptp_clock_register() for non-primary
interfaces, just exit out of efx_ptp_prober() earlier. Saves a little
memory and speeds up init and teardown slightly.
CC: linux-net-driv...@solarflare.co
Hello,
On 15.12.2016 19:50, Jason A. Donenfeld wrote:
> Hi David & Hannes,
>
> This conversation is veering off course.
Why?
> I think this doesn't really
> matter at all. Gcc converts u64 into essentially a pair of u32 on
> 32-bit platforms, so the alignment requirements for 32-bit is at a
> m
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.
The
Hey folks,
I think we're approaching the end of the review for this patchset and we're
getting somewhat close to being ready for it being queued up. At this point,
I've incorporated all of the extremely helpful and instructive suggestions
from the list.
For this v5, we now accept u64[2] as the ke
On 15-12-2016 6:15, Michael S. Tsirkin wrote:
> 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/ne
virtio_net XDP support expects receive buffers to be contiguous.
If this is not the case we enable a slowpath to allow connectivity
to continue but at a significan performance overhead associated with
linearizing data. To make it painfully aware to users that XDP is
running in a degraded mode we th
This implements virtio_net for the mergeable buffers and big_packet
modes. I tested this with vhost_net running on qemu and did not see
any issues. For testing num_buf > 1 I added a hack to vhost driver
to only but 100 bytes per buffer.
There are some restrictions for XDP to be enabled and work we
On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár writes:
>>
> So no, there is no argument against... request_firmware() in
> fallback mode with userspace helper
Split ipvrf_identify into arg processing and a function that does the
actual cgroup file parsing. The latter function is used in a follow
on patch.
In the process, convert the reading of the cgroups file to use fopen
and fgets just in case the file ever grows beyond 4k. Move printing
of any error
Move the hint about CGROUP_BPF enabled to prog_load failure since
it fails before the attach. Update the existing error message to
print to stderr.
Signed-off-by: David Ahern
---
ip/ipvrf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ip/ipvrf.c b/ip/ipvrf.c
index 4d5
Some minor cleanups to the 'ip vrf' command.
Patch 1 moves the CGROUP_BPF hint to the failure of prog_load since it
fails first.
Patch 2 refactors ipvrf_identify. The action part is moved to a function
that can be used standalone and in the process flipped to fopen/fgets for
robustness should the
A vrf is local to a namespace. Drop any VRF association before trying
to exec a command in the new namespace.
Signed-off-by: David Ahern
---
ip/ip_common.h | 1 +
ip/ipnetns.c | 5 +
ip/ipvrf.c | 14 ++
3 files changed, 20 insertions(+)
diff --git a/ip/ip_common.h b/ip/i
Path in vrf_switch for "default" VRF is supposed to be MNT/vrf not
MNT/default. Also, default_vrf flag is redundant with ifindex. Remove
the flag in favor of ifindex != 0.
Signed-off-by: David Ahern
---
ip/ipvrf.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git
On 2016-12-14 6:12 PM, 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
---
drivers/net/ethernet/sfc/ethtool.c| 35 ---
drivers/net/ethernet/sfc/mcdi_port.c |
On 12/15/2016 10:21 AM, Manuel Bessler wrote:
> 'ifconfig eth0 down' makes r6040_close() trigger:
> INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>
> Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
> to outside of the module's private spin_lock_irq block.
>
> F
On 12/14/2016 09:15 PM, Michael S. Tsirkin wrote:
> __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.
Hi,
On 15.12.2016 10:45, Pavel Machek wrote:
> Hi!
>
>> The driver uses a private lock for synchronization of the xmit function and
>> the xmit completion handler, but since the NETIF_F_LLTX flag is not set,
>> the xmit function is also called with the xmit_lock held.
>>
>> On the other hand the
Hi,
On 15.12.2016 19:52, Niklas Cassel wrote:
> Since v1 of this patch has already been merged to net-next, I think that
> you should create a new patch on top of that, rather than submitting a v2.
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/stmi
Hi Pavel,
sorry for the late reply.
On 11.12.2016 21:11, Pavel Machek wrote:
>
> Do you understand what stmmac_tx_err(priv); is supposed to do? In
> particular, if it is called while the driver is working ok -- should
> the driver survive that?
As far as I understood it is supposed to fixup an
Em Thu, Dec 15, 2016 at 10:29:19AM -0800, Joe Stringer escreveu:
> On 15 December 2016 at 07:50, Arnaldo Carvalho de Melo
> wrote:
> > Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
> >> Now that libbpf under tools/lib/bpf/* is synced with the version from
> >> samples/bpf, we c
On Tue, Dec 13, 2016 at 6:32 PM, Tom Herbert
wrote:
On Tue, Dec 13, 2016 at 3:03 PM, Craig Gallek
wrote:
On Tue, Dec 13, 2016 at 3:51 PM, Tom Herbert
wrote:
I think there may be some suspicious code in inet_csk_get_port. At
tb_found there is:
if (((tb->fastreuse > 0 && r
Hi David,
On Thu, Dec 15, 2016 at 11:14 AM, David Laight wrote:
> From: Behalf Of Jason A. Donenfeld
>> Sent: 14 December 2016 18:46
> ...
>> + ret = *chaining = siphash24((u8 *)&combined,
>> offsetof(typeof(combined), end),
>
> If you make the first argument 'const void *' you won't need th
Hi David & Hannes,
This conversation is veering off course. I think this doesn't really
matter at all. Gcc converts u64 into essentially a pair of u32 on
32-bit platforms, so the alignment requirements for 32-bit is at a
maximum 32 bits. On 64-bit platforms the alignment requirements are
related a
On Thu, Dec 15, 2016 at 01:19:18PM -0500, Doug Ledford wrote:
> On 12/15/2016 12:07 PM, Jason Gunthorpe wrote:
> > On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
> >
> >> 1) Since your intent is to make this work with multiple versions of the
> >> hfi drivers, I disagree with Jason
Em Thu, Dec 15, 2016 at 03:29:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
> > > Now that libbpf under tools/lib/bpf/* is synced with the version fro
Em Thu, Dec 15, 2016 at 03:34:40PM -0300, Arnaldo Carvalho de Melo escreveu:
>
> So, I'm stopping here so that I can push what I have to Ingo, then I'll get
> back to this, hopefully by then you beat me and I have just to retest 8-)
Ah, I left what I have in the tmp.perf/samples-libbpf branch in
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 --git a/drivers/net/ethernet/freescale/fman/fman.c
> b/drivers/net/ethernet/frees
On 15 December 2016 at 07:50, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
>> 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 Stringe
Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
> > 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-
'ifconfig eth0 down' makes r6040_close() trigger:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
to outside of the module's private spin_lock_irq block.
Found on a Versalogic Tomcat SBC with a Vortex86 SoC
s1660e_
On 12/15/2016 12:07 PM, Jason Gunthorpe wrote:
> On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
>
>> 1) Since your intent is to make this work with multiple versions of the
>> hfi drivers, I disagree with Jason that just because there is only one
>> driver today that we should keep
'ifconfig eth0 down' makes r6040_close() trigger:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
to outside of the module's private spin_lock_irq block.
Found on a Versalogic Tomcat SBC with a Vortex86 SoC
s1660e_
Florian Fainelli writes:
>> In all cases *if caching is really needed*, I think it won't hurt to do
>> it in DSA core even if a switch support FDB dump operations on a
>> per-port basis, as Andrew mentioned.
>
> Agreed, and there does not appear to be any need to new dsa_switch_ops
> operations t
1 - 100 of 206 matches
Mail list logo
