Hi Dave,
the net-next tree is broken since a few days now when
CONFIG_NETFILTER_INGRESS=n is set.
CC net/netfilter/core.o
In file included from ./include/linux/linkage.h:4:0,
from ./include/linux/kernel.h:6,
from net/netfilter/core.c:10:
net/netfilter/cor
From: Gavin Shan
Date: Thu, 29 Sep 2016 15:03:08 +1000
> This replaces the atomic access to NCSI channel's state with READ_ONCE()
> and WRITE_ONCE() to avoid the above build warning. We needn't hold the
> channel's lock when updating its state as well. No logical changes
> introduced.
I don't un
From: Timur Tabi
Date: Wed, 28 Sep 2016 11:58:41 -0500
> This patch series adds support to the EMAC driver for extracting addresses,
> interrupts, and some _DSDs (properties) from ACPI. The first two patches
> clean up the code, and the third patch adds ACPI-specific functionality.
>
> The firs
From: Josef Bacik
Date: Wed, 28 Sep 2016 10:54:32 -0400
> Suppose you have a map array value that is something like this
>
> struct foo {
> unsigned iter;
> int array[SOME_CONSTANT];
> };
>
> You can easily insert this into an array, but you cannot modify the contents
> of
> foo->a
There is at least one Chelsio 10Gb card which uses VPD area to store
some custom blocks (example below). However pci_vpd_size() returns
the length of the first block only assuming that there can be only
one VPD "End Tag" and VFIO blocks access beyond that offset
(since 4e1a63555) which leads to the
This introduces ncsi_stop_dev(), as counterpart to ncsi_start_dev(),
to stop the NCSI device so that it can be reenabled in future. This
API should be called when the network device driver is going to
shutdown the device. There are 3 things done in the function: Stop
the channel monitoring; Reset c
This stops NCSI device when closing the network device so that the
NCSI device can be reenabled later.
Signed-off-by: Gavin Shan
Reviewed-by: Joel Stanley
---
drivers/net/ethernet/faraday/ftgmac100.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
This series of patches improves NCSI stack according to the comments
I received after the NCSI code was merged to 4.8.rc1:
* PATCH[1/8] fixes the build warning caused by xchg() with ia64-linux-gcc.
The atomic operations are replaced with {READ, WRITE}_ONCE().
* Channel ID (0x1f) is the res
xchg() is used to set NCSI channel's state in order for consistent
access to the state. xchg()'s return value should be used. Otherwise,
one build warning will be raised (with -Wunused-value) as below message
indicates. It is reported by ia64-linux-gcc (GCC) 4.9.0.
net/ncsi/ncsi-manage.c: In func
The original NCSI channel monitoring was implemented based on a
backoff algorithm: the GLS response should be received in the
specified interval. Otherwise, the channel is regarded as dead
and failover should be taken if current channel is an active one.
There are several problems in the implementa
There is only one NCSI request property for now: the response for
the sent command need drive the workqueue or not. So we had one
field (@driven) for the purpose. We lost the flexibility to extend
NCSI request properties.
This replaces @driven with @flags and @req_flags in NCSI request
and NCSI co
The NCSI request index (struct ncsi_request::id) is put into instance
ID (IID) field while sending NCSI command packet. It was designed the
available IDs are given in round-robin fashion. @ndp->request_id was
introduced to represent the next available ID, but it has been used
as number of successiv
We needn't send CIS (Clear Initial State) command to the NCSI
reserved channel (0x1f) in the enumeration. We shouldn't receive
a valid response from CIS on NCSI channel 0x1f.
Signed-off-by: Gavin Shan
Reviewed-by: Joel Stanley
---
net/ncsi/ncsi-manage.c | 4 ++--
1 file changed, 2 insertions(+)
This defines NCSI_RESERVED_CHANNEL as the reserved NCSI channel
ID (0x1f). No logical changes introduced.
Signed-off-by: Gavin Shan
Reviewed-by: Joel Stanley
---
net/ncsi/internal.h| 1 +
net/ncsi/ncsi-manage.c | 14 +++---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --g
On Wed, 2016-09-28 at 20:54 -0700, Tom Herbert wrote:
> xps_flows maintains a per device flow table that is indexed by the
> skbuff hash. The table is only consulted when there is no queue saved in
> a transmit socket for an skbuff.
>
> Each entry in the flow table contains a queue index and a que
This implements ndo_poll_controller in net_device_ops callbacks for mlx5,
which is necessary to use netconsole with this driver.
Acked-By: Saeed Mahameed
Signed-off-by: Calvin Owens
---
Changes in v2:
* Only iterate channels to avoid redundant napi_schedule() calls
drivers/net/ethernet/
On Wed, Sep 28, 2016 at 12:44:31PM +0200, Jesper Dangaard Brouer wrote:
>
> The idea is quite different. It has nothing to do with Edward's
> proposal[3]. The RX packet-vector is simply an array, either of pointers
> or index numbers (into the RX-ring). The needed changes are completely
> conta
Signed-off-by: Tom Herbert
---
Documentation/ABI/testing/sysfs-class-net | 8
Documentation/networking/scaling.txt | 26 ++
2 files changed, 34 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-net
b/Documentation/ABI/testing/sysfs-class-net
xps_flows maintains a per device flow table that is indexed by the
skbuff hash. The table is only consulted when there is no queue saved in
a transmit socket for an skbuff.
Each entry in the flow table contains a queue index and a queue
pointer. The queue pointer is set when a queue is chosen usin
Use the __skb_set_sw_hash to set the hash in an skbuff from the socket
txhash.
Signed-off-by: Tom Herbert
---
include/net/sock.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index ebf75db..17d379a 100644
--- a/include/net/sock.
Add two new counters to struct dql that are num_enqueue_ops and
num_completed_ops. num_enqueue_ops is incremented by one in each call to
dql_queued. num_enqueue_ops is incremented in dql_completed which takes
an argument indicating number of operations completed. These counters
are only intended fo
Add infrastructure and definitions to create XFS flow tables. This
creates the new sys entry /sys/class/net/eth*/xps_dev_flow_table_cnt
Signed-off-by: Tom Herbert
---
include/linux/netdevice.h | 24 +
net/core/net-sysfs.c | 89 +++
2 f
This patch set introduces transmit flow steering for socketless packets.
The idea is that we record the transmit queues in a flow table that is
indexed by skbuff hash. The flow table entries have two values: the
queue_index and the head cnt of packets from the TX queue. We only allow
a queue to ch
Hi David,
Please see inline:
On Wed, 28 Sep 2016, David Miller wrote:
> From: "R. Parameswaran"
> Date: Tue, 27 Sep 2016 12:17:21 -0700 (PDT)
>
> > Later, in vxlan_dev_configure(), called from vxlan_dev_create(), it gets
> > adjusted to account for the headers:
> >
> > vxlan_dev_configure(
Stefan Agner wrote:
> When using bridge without bridge netfilter enabled the message
> displayed is rather confusing and leads to belive that a deprecated
> feature is in use. Use IS_MODULE to be explicit that the message only
> affects users which use bridge netfilter as module and reword the
> m
Actually, on a little more searching of this list's archives, I think
that this discussion: https://patchwork.kernel.org/patch/9260733/ is
about exactly the same issue I've found, except from the TCP side. I'm
cc'ing a few of the participants from that discussion.
So is the patch proposed there (
On Wed, 2016-09-28 at 12:52 +0200, Paolo Abeni wrote:
> +static void udp_rmem_release(struct sock *sk, int partial)
> +{
> + struct udp_sock *up = udp_sk(sk);
> + int fwd, amt;
> +
> + if (partial && !udp_under_memory_pressure(sk))
> + return;
> +
> + /* we can have con
On Wed, 2016-09-28 at 17:18 -0700, Jay Smith wrote:
> I've spent the last week or so trying to track down a recurring
> problem I'm seeing with UDP datagram handling. I'm new to the
> internals of the Linux network stack, but it appears to me that
> there's a substantial error in recent kernels' h
Hi all,
On Tue, 13 Sep 2016 10:12:50 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the netfilter-next tree got a conflict in:
>
> net/netfilter/nf_tables_netdev.c
>
> between commit:
>
> c73c24849011 ("netfilter: nf_tables_netdev: remove redundant ip_hdr
> assignment")
>
From: Eric Dumazet
Date: Wed, 28 Sep 2016 08:41:16 -0700
> From: Eric Dumazet
>
> Since commit 900f65d361d3 ("tcp: move duplicate code from
> tcp_v4_init_sock()/tcp_v6_init_sock()") we no longer need
> to export sk_stream_write_space()
>
> From: Eric Dumazet
Applied, thanks Eric.
I've spent the last week or so trying to track down a recurring
problem I'm seeing with UDP datagram handling. I'm new to the
internals of the Linux network stack, but it appears to me that
there's a substantial error in recent kernels' handling of UDP
checksum errors.
The behavior I'm seeing: I
On Wed, 2016-09-28 at 22:37 +0200, Frans van de Wiel wrote:
> We compiled kernel 4.6.6 for our nas devices running on ARM kirkwood cpu’s.
> These nas devices have only 256 MB of RAM so limited memory resources
> When we fully load the cpu and are copying files via the interface we get
> frequentl
Hi everyone,
I'm Shyam, final year undergraduate student. I wanted to know how one can
submit potential linux kernel patch in networking subsystem.
Thanks,
Shyam
Set upper 32 bits of destination register to zeros after
load from the context structure.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/nfp_bpf_jit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_bpf_jit.c
b/drivers/net/ether
On 09/28/2016 12:06 PM, David Ahern wrote:
Andrew Collins posted this patch as RFC in March:
http://patchwork.ozlabs.org/patch/603101/
It has apparently fallen through the cracks and never applied.
It solves a refcnt problem (thanks Nik for pointing out this patch)
I have been running the
With centralized MTU checking, there's nothing productive done by
eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
deprecated and remove all usage of it in the kernel. All callers have been
audited for calls to alloc_etherdev* or ether_setup directly, which means
they all have a
While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 6
While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 6
When using bridge without bridge netfilter enabled the message
displayed is rather confusing and leads to belive that a deprecated
feature is in use. Use IS_MODULE to be explicit that the message only
affects users which use bridge netfilter as module and reword the
message.
Signed-off-by: Stefan
On 09/28/2016 01:32 AM, Andrew Lunn wrote:
> The phy_start() is used to indicate the PHY is now ready to do its
> work. The state is changed, normally to PHY_UP which means that both
> the MAC and the PHY are ready.
>
> If the phy driver is using polling, when the next poll happens, the
> state ma
While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 6
On Wed, Sep 28, 2016 at 02:38:03PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 9/28/2016 11:32 AM, Andrew Lunn wrote:
>
> >The interrupt lines from PHYs maybe connected to I2C bus expanders, or
> >from switches on MDIO busses. Such interrupts are sourced from devices
> >which sleep, so use thre
We compiled kernel 4.6.6 for our nas devices running on ARM kirkwood cpu’s.
These nas devices have only 256 MB of RAM so limited memory resources
When we fully load the cpu and are copying files via the interface we get
frequently this “ error” message in dmesg log
[ 1978.149929] mv643xx_eth_po
> + reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
> + if ((mdix == ETH_TP_MDI) || (mdix == ETH_TP_MDI_X)) {
> + reg_val |= (DISABLE_PAIR_SWAP_CORR_MASK |
> + DISABLE_POLARITY_CORR_MASK |
> + DISABLE_HP_AUTO_MDIX_MASK);
> +
On 09/28/2016 06:30 PM, David Laight wrote:
> From: Vlastimil Babka
>> Sent: 27 September 2016 12:51
> ...
>> Process name suggests it's part of db2 database. It seems it has to implement
>> its own interface to select() syscall, because glibc itself seems to have a
>> FD_SETSIZE limit of 1024, whi
On (09/28/16 11:08), Alexander Duyck wrote:
> > - then udp_gro_receive -> vxlan_gro_receive pulls up vxlan header
> > into linear part, and then..
>
> This is the point where we need to stop, drop the existing headers,
> call skb_reserve(NET_IP_ALIGN), and then pick back up where we left
> off.
When sctp dumps all the ep->assocs, it needs to lock_sock first,
but now it locks sock in rcu_read_lock, and lock_sock may sleep,
which would break rcu_read_lock.
This patch is to get and hold one sock when traversing the list.
After that and get out of rcu_read_lock, lock and dump it. Then
it wil
Now pahole sctp_chunk, it has 2 memory holes:
struct sctp_chunk {
struct list_head list;
atomic_t refcnt;
/* XXX 4 bytes hole, try to pack */
...
long unsigned int prsctp_param;
intsent_c
This patchset is to fix 2 issues for prsctp polices:
1. patch 1 and 2 fix "netperf-Throughput_Mbps -37.2% regression" issue
when overloading the CPU.
2. patch 3 fix "prsctp polices should check both sides' prsctp_capable,
instead of only local side".
Xin Long (3):
sctp: move sent
Now before using prsctp polices, sctp uses asoc->prsctp_enable to
check if prsctp is enabled. However asoc->prsctp_enable is set only
means local host support prsctp, sctp should not abandon packet if
peer host doesn't enable prsctp.
So this patch is to use asoc->peer.prsctp_capable to check if pr
Now sctp uses chunk->prsctp_param to save the prsctp param for all the
prsctp polices, we didn't need to introduce prsctp_param to sctp_chunk.
We can just use chunk->sinfo.sinfo_timetolive for RTX and BUF polices,
and reuse msg->expires_at for TTL policy, as the prsctp polices and old
expires polic
Currently, 'linkid' input by the user is parsed but 'handle' is appended to the
netlink message.
# tc filter add dev enp1s0f1 protocol ip parent : prio 99 u32 ht 800: \
order 1 link 1: offset at 0 mask 0f00 shift 6 plus 0 eat match ip \
protocol 6 ff
resulted in:
filter proto
On Wed, 2016-09-28 at 11:00 -0700, David Decotigny wrote:
> From: David Decotigny
>
> This also can address following UBSAN warnings:
> [ 36.640343]
>
> [ 36.648772] UBSAN: Undefined behaviour in
> drivers/net/
On Wed, Sep 28, 2016 at 10:03 AM, Sowmini Varadhan
wrote:
> On (09/23/16 17:43), Alexander Duyck wrote:
>> > On (09/23/16 10:38), Alexander Duyck wrote:
> ;
>> >> almost think of it as us doing something like the inverse of
>> >> pskb_pull_tail. The general idea here is we want to actua
Andrew Collins posted this patch as RFC in March:
http://patchwork.ozlabs.org/patch/603101/
It has apparently fallen through the cracks and never applied.
It solves a refcnt problem (thanks Nik for pointing out this patch)
with stacked devices that involves macvlan on a bridge, a bond into
th
Thanks Russell,
On 09/28/2016 10:25 AM, Russell King - ARM Linux wrote:
> On Wed, Sep 28, 2016 at 10:14:52AM -0700, Eric Nelson wrote:
>> Thanks David,
>>
>> On 09/28/2016 09:42 AM, David Laight wrote:
>>> From reading this it seems that the effect of FEC_RACC_SHIFT16 is to
>>> add two bytes of 'j
From: David Decotigny
This also can address following UBSAN warnings:
[ 36.640343]
[ 36.648772] UBSAN: Undefined behaviour in
drivers/net/ethernet/mellanox/mlx4/fw.c:857:26
[ 36.656853] shift exponent 64 is t
On Wed, 2016-09-28 at 18:50 +0200, SF Markus Elfring wrote:
> Would you like to look once more into an improved patch series for this
> software module a bit later?
I'm afraid I'm not looking forward to receiving an update of this
series, sorry.
Thanks,
Paul Bolle
On Wed, 2016-09-28 at 18:38 +0200, SF Markus Elfring wrote:
> > I'm not going to change code just because some checker suggests to
> > do so.
>
> The script "checkpatch.pl" can point information out like the
> following.
>
> WARNING: Prefer kmalloc_array over kmalloc with multiply
Am I being tro
On Wed, 28 Sep 2016 16:43:38 +0200 Daniel Borkmann wrote:
> Couldn't we end up with 1) for the act_vlan case when we'd have the
> offset-adjusted skb_vlan_push() fix from here, where we'd then redirect
> to ingress where skb_vlan_pop() would be called? If I'm not missing
> something, skb_vlan_push
On 09/28/2016 05:01 AM, Raju Lakkaraju wrote:
> From: Raju Lakkaraju
>
> Wake-on-LAN (WoL) is an Ethernet networking standard that allows
> a computer/device to be turned on or awakened by a network message.
> VSC8531 PHY can support this feature configure by driver set function.
> WoL status get
On Wed, Sep 28, 2016 at 10:14:52AM -0700, Eric Nelson wrote:
> Thanks David,
>
> On 09/28/2016 09:42 AM, David Laight wrote:
> > From reading this it seems that the effect of FEC_RACC_SHIFT16 is to
> > add two bytes of 'junk' to the start of every receive frame.
>
> That's right. Two bytes of jun
On 09/28/2016 01:32 AM, Andrew Lunn wrote:
> Using the fixed name "phy_interrupt" is not very informative in
> /proc/interrupts when there are a lot of phys, e.g. a device with an
> Ethernet switch. So when requesting the interrupt, use the name of the
> phy.
>
> Signed-off-by: Andrew Lunn
Acked
Thanks David,
On 09/28/2016 09:42 AM, David Laight wrote:
> From: Eric Nelson
>> Sent: 26 September 2016 19:40
>> Hi David,
>>
>> On 09/26/2016 02:26 AM, David Laight wrote:
>>> From: Eric Nelson
Sent: 24 September 2016 15:42
The FEC receive accelerator (RACC) supports shifting the data
On 09/28/2016 06:38 AM, Sergei Shtylyov wrote:
> On 09/28/2016 03:28 PM, Andrew Lunn wrote:
>
> The PHY interrupts are now handled in a threaded interrupt handler,
> which can sleep. The work queue is no longer needed, phy_change() can
> be called directly. Additionally, none of the ca
On Wed, 28 Sep 2016 16:43:38 +0200 Daniel Borkmann wrote:
> > (1) suppose upon entry we have
> >
> > DA,SA,0x8100,TCI,0x0800,
> > ^^
> > mac_hdr data
> >
> > initial offset is 18, and after current unwinding code we'll get
>
> You mean data points after t
On (09/23/16 17:43), Alexander Duyck wrote:
> > On (09/23/16 10:38), Alexander Duyck wrote:
;
> >> almost think of it as us doing something like the inverse of
> >> pskb_pull_tail. The general idea here is we want to actually leave
> >> the data in skb->data, but just reference it from f
This patch series adds support to the EMAC driver for extracting addresses,
interrupts, and some _DSDs (properties) from ACPI. The first two patches
clean up the code, and the third patch adds ACPI-specific functionality.
The first patch fixes a bug with handling the platform_device for the
inter
Replace the DT-specific of_get_mac_address() function with
device_get_mac_address, which works on both DT and ACPI platforms. This
change makes it easier to add ACPI support.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac.c | 10 --
1 file changed, 4 insertions(+)
The platform_device returned by of_find_device_by_node() is not
automatically released when the driver unprobes. Therefore,
managed calls like devm_ioremap_resource() should not be used.
Instead, we manually allocate the resources and then free them
on driver release.
Signed-off-by: Timur Tabi
-
Add support for reading addresses, interrupts, and _DSD properties
from ACPI tables, just like with device tree. The HID for the
EMAC device itself is QCOM8070. The internal PHY is represented
by a child node with a HID of QCOM8071.
The EMAC also has some complex clock initialization requirement
> Two of the five patches introduced bugs. The rest of the series isn't
> free of various nits either. Of course, I was in no mood to be lenient
> when I looked at those three patches.
>
> I won't take any of these patches, sorry.
Would you like to look once more into an improved patch series for
>
> That doesn't matter. This happens all the time.
>
> The way you handle this is you submit patch #1 targetting 'net' and
> wait for it to get into 'net' and propagate into 'net-next'. When
> that happens you can submit patches #2-5 as a second patch series
> targetting 'net-next'.
Thanks, wil
From: Eric Nelson
> Sent: 26 September 2016 19:40
> Hi David,
>
> On 09/26/2016 02:26 AM, David Laight wrote:
> > From: Eric Nelson
> >> Sent: 24 September 2016 15:42
> >> The FEC receive accelerator (RACC) supports shifting the data payload of
> >> received packets by 16-bits, which aligns the pa
>> * Multiplications for the size determination of memory allocations
>> indicated that array data structures should be processed.
>> Thus use the corresponding function "kmalloc_array".
>
> Was the current code incorrect?
I suggest to use a safer interface for array allocations.
> What mak
From: Vlastimil Babka
> Sent: 27 September 2016 12:51
...
> Process name suggests it's part of db2 database. It seems it has to implement
> its own interface to select() syscall, because glibc itself seems to have a
> FD_SETSIZE limit of 1024, which is probably why this wasn't an issue for all
> t
> +#define MSCC_PHY_WOL_MAC_CONTROL 27
> +#define EDGE_RATE_CNTL_POS 5
> +#define EDGE_RATE_CNTL_MASK0x00E0
This patch does not require these two #defines.
Please indicate in the cover note if the patches depends on other
patches in order to cleanly apply. Or if thes
On Wed, Sep 28, 2016 at 03:33:52PM +, Neftin, Sasha wrote:
>
> Since I worked with Sasha on this I will provide a bit of information from
> what I understand of this bug as well.
>
> On Tue, Sep 27, 2016 at 12:13 PM, Alex Williamson
> wrote:
> > On Tue, 27 Sep 2016 13:17:02 -0500
> > Bjorn
> +Optional properties:
> +- vsc8531,vddmac : The vddmac in mV.
> +- vsc8531,edge-slowdown : % the edge should be slowed down relative to
> + the fastest possible edge time. Native sign
> + need not enter.
> + Edge rate sets
On 28/09/16 14:45, hejianet wrote:
>
>
> On 9/28/16 5:08 PM, David Miller wrote:
>> From: Jia He
>> Date: Wed, 28 Sep 2016 14:22:21 +0800
>>
>>> v5:
>>> - order local variables from longest to shortest line
>> I still see many cases where this problem still exists. Please
>> do not resubmit this
On Wed, Sep 28, 2016 at 11:17:16AM -0400, David Miller wrote:
> From: Xin Long
> Date: Wed, 28 Sep 2016 20:35:40 +0800
>
> >>
> >>> This patchset is to improve some codes about prsctp polices, and also
> >>> to fix some issues.
> >>>
> >>> v1->v2:
> >>> - wrap the check of chunk->sent_count in
From: Eric Dumazet
Since commit 900f65d361d3 ("tcp: move duplicate code from
tcp_v4_init_sock()/tcp_v6_init_sock()") we no longer need
to export sk_stream_write_space()
From: Eric Dumazet
Cc: Neal Cardwell
---
net/core/stream.c |1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/st
Two possible error conditions were caught during an extended testing
session, and by a build robot. These patches fix the two issues (a
missing handler when config is changed, and a potential NULL
dereference).
Aaron Conole (2):
netfilter: Fix potential null pointer dereference
nf_set_hooks_h
It's possible for nf_hook_entry_head to return NULL. If two
nf_unregister_net_hook calls happen simultaneously with a single hook
entry in the list, both will enter the nf_hook_mutex critical section.
The first will successfully delete the head, but the second will see
this NULL pointer and attemp
Eric Dumazet writes:
> On Wed, 2016-09-28 at 10:56 -0400, Aaron Conole wrote:
>> Eric Dumazet writes:
>>
>> > On Wed, 2016-09-28 at 09:12 -0400, Aaron Conole wrote:
>> >> It's possible for nf_hook_entry_head to return NULL. If two
>> >> nf_unregister_net_hook calls happen simultaneously with a
When CONFIG_NETFILTER_INGRESS is unset (or no), we need to handle
the request for registration properly by dropping the hook. This
releases the entry during the set.
Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list")
Signed-off-by: Aaron Conole
---
net/netfilter/core.c
Since I worked with Sasha on this I will provide a bit of information from what
I understand of this bug as well.
On Tue, Sep 27, 2016 at 12:13 PM, Alex Williamson
wrote:
> On Tue, 27 Sep 2016 13:17:02 -0500
> Bjorn Helgaas wrote:
>
>> On Sun, Sep 25, 2016 at 10:02:43AM +0300, Neftin, Sasha w
On Wed, 2016-09-28 at 10:56 -0400, Aaron Conole wrote:
> Eric Dumazet writes:
>
> > On Wed, 2016-09-28 at 09:12 -0400, Aaron Conole wrote:
> >> It's possible for nf_hook_entry_head to return NULL. If two
> >> nf_unregister_net_hook calls happen simultaneously with a single hook
> >> entry in the
From: Maciej Żenczykowski
Date: Wed, 28 Sep 2016 22:23:10 +0900
> Anyway, enough, I give up, this isn't worth my time, and it's also not
> worth your time.
> I removed the dependency from the other patches and squashed them all into
> 1 to make reviewing easier.
Splitting things up is sometimes
From: Xin Long
Date: Wed, 28 Sep 2016 20:35:40 +0800
>>
>>> This patchset is to improve some codes about prsctp polices, and also
>>> to fix some issues.
>>>
>>> v1->v2:
>>> - wrap the check of chunk->sent_count in a macro:
>>> sctp_chunk_retransmitted in patch 2/5.
>>
>> This series is a m
Here is a quick look at performance tests for the result of trying the
prototype fix for the packet reordering problem with VMs sending over
an XPS-configured NIC. In particular, the Emulex/Avago/Broadcom
Skyhawk. The fix was applied to a 4.4 kernel.
Before: 3884 Mbit/s
After: 8897 Mbit/s
Tha
On 28/09/16 10:12, David Laight wrote:
> If you invert the above and add a goto...
> if (!efx->rx_hash_udp_4tuple)
> goto set_ip;
I don't mind gotos...
>> case SCTP_V4_FLOW:
>> case AH_ESP_V4_FLOW:
>> case IP
Eric Dumazet writes:
> On Wed, 2016-09-28 at 09:12 -0400, Aaron Conole wrote:
>> It's possible for nf_hook_entry_head to return NULL. If two
>> nf_unregister_net_hook calls happen simultaneously with a single hook
>> entry in the list, both will enter the nf_hook_mutex critical section.
>> The f
On Wed, Sep 28, 2016 at 06:49:51AM -0700, Eric Dumazet wrote:
> >
> > 4.7 is pretty widespread, so I've to think...
>
> Sorry, 4.4.7 it was
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg128714.html
Ah, thanks for info!
Suppose you have a map array value that is something like this
struct foo {
unsigned iter;
int array[SOME_CONSTANT];
};
You can easily insert this into an array, but you cannot modify the contents of
foo->array[] after the fact. This is because we have no way to verify we won't
g
This first patch updates the NHI Thunderbolt controller registers file to
reflect that it is not only for Cactus Ridge.
No functional change intended.
Signed-off-by: Amir Levy
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/nhi_regs.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletio
This patch builds the peer to peer communication path.
Communication is established by a negotiation process whereby messages are
sent back and forth between the peers until a connection is established.
This includes the Thunderbolt Network driver communication with the second
peer via Intel Connec
Update to the Kconfig Thunderbolt description to add
Thunderbolt networking as an option.
The menu item "Thunderbolt support" now offers:
"Apple Hardware Support" (existing)
and/or
"Thunderbolt Networking" (new)
You can choose the driver for your platform or build both drivers -
each drive
Adding Thunderbolt(TM) networking documentation.
Signed-off-by: Amir Levy
---
Documentation/00-INDEX | 2 +
Documentation/thunderbolt/networking.txt | 132 +++
2 files changed, 134 insertions(+)
create mode 100644 Documentation/thunderbolt/network
This patch provides the communication protocol between the
Intel Connection Manager(ICM) firmware that is operational in the
Thunderbolt controller in non-Apple hardware.
The ICM firmware-based controller is used for establishing and maintaining
the Thunderbolt Networking connection - we need to be
1 - 100 of 212 matches
Mail list logo