* Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel
From: Johan Hedberg @ 2016-10-06 8:38 UTC (permalink / raw)
To: Joe Perches
Cc: Pavel Machek, Marcel Holtmann, Gustavo F. Padovan,
David S. Miller, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <1475737676.3224.1.camel@perches.com>
Hi,
On Thu, Oct 06, 2016, Joe Perches wrote:
> On Thu, 2016-10-06 at 09:02 +0200, Pavel Machek wrote:
> > I believe you are wrong. bit addressability does not matter, cpu can
> > definitely get the bit values.
> >
> > u8 foo:1;
> > u8 bar:1;
> > u8 baz:1;
> >
> > should take 1 byte, where
> >
> > bool foo, bar, baz;
> >
> > will take more like 3.
>
> Definitely true.
>
> There is only one single bitfield foo here though
> so what you wrote doesn't apply.
What's in the tree is a left-over from times when there were multiple
bit fields in this struct. By the time others were removed and there was
only one left no-one has apparently bothered to update it to a bool or
single u8.
Johan
^ permalink raw reply
* Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel
From: Joe Perches @ 2016-10-06 7:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
David S. Miller, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <20161006070237.GB25972@amd>
On Thu, 2016-10-06 at 09:02 +0200, Pavel Machek wrote:
> I believe you are wrong. bit addressability does not matter, cpu can
> definitely get the bit values.
>
> u8 foo:1;
> u8 bar:1;
> u8 baz:1;
>
> should take 1 byte, where
>
> bool foo, bar, baz;
>
> will take more like 3.
Definitely true.
There is only one single bitfield foo here though
so what you wrote doesn't apply.
^ permalink raw reply
* Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel
From: Pavel Machek @ 2016-10-06 7:02 UTC (permalink / raw)
To: Joe Perches
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
David S. Miller, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <1475706531.1941.4.camel@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Wed 2016-10-05 15:28:51, Joe Perches wrote:
> On Thu, 2016-10-06 at 00:13 +0200, Pavel Machek wrote:
> > On Wed 2016-10-05 12:15:34, Joe Perches wrote:
> > > On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote:
> > > > On Wed 2016-10-05 10:53:16, Joe Perches wrote:
> []
> > > > > trivia:
> > > > > It's generally faster to use bool instead of u8 foo:1;
> > > > Ok, but I'm not changing that in this patch.
> > > > (And actually, bool will take a lot more memory, right?)
> > > No worries, and bool is the same size as u8.
> > Exactly what I'm talking about :-). One byte vs. one bit, right?
>
> Memory isn't bit addressable.
> So it's the same byte, it just doesn't use a read/modify/write
> operation to update a value.
I believe you are wrong. bit addressability does not matter, cpu can
definitely get the bit values.
u8 foo:1;
u8 bar:1;
u8 baz:1;
should take 1 byte, where
bool foo, bar, baz;
will take more like 3.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Koehrer Mathias (ETAS/ESW5) @ 2016-10-06 7:01 UTC (permalink / raw)
To: Julia Cartwright, Jeff Kirsher, Greg
Cc: Sebastian Andrzej Siewior, linux-rt-users@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20161005155959.GH10625@jcartwri.amer.corp.natinst.com>
[-- Attachment #1: Type: text/plain, Size: 7308 bytes --]
Hi all,
>
> Although, to be clear, it isn't the fact that there exists 8 threads, it's that the device is
> firing all 8 interrupts at the same time. The time spent in hardirq context just waking
> up all 8 of those threads (and the cyclictest wakeup) is enough to cause your
> regression.
>
> netdev/igb folks-
>
> Under what conditions should it be expected that the i350 trigger all of the TxRx
> interrupts simultaneously? Any ideas here?
>
> See the start of this thread here:
>
> http://lkml.kernel.org/r/d648628329bc446fa63b5e19d4d3fb56@FE-
> MBX1012.de.bosch.com
>
Greg recommended to use "ethtool -L eth2 combined 1" to reduce the number of queues.
I tried that. Now, I have actually only three irqs (eth2, eth2-rx-0, eth2-tx-0).
However the issue remains the same.
I ran the cyclictest again:
# cyclictest -a -i 105 -m -n -p 80 -t 1 -b 23 -C
(Note: When using 105us instead of 100us the long latencies seem to occur more often).
Here are the final lines of the kernel trace output:
<idle>-0 4d...2.. 1344661649us : sched_switch: prev_comm=swapper/4 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcuc/4 next_pid=56 next_prio=98
ktimerso-46 3d...2.. 1344661650us : sched_switch: prev_comm=ktimersoftd/3 prev_pid=46 prev_prio=98 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
ktimerso-24 1d...2.. 1344661650us : sched_switch: prev_comm=ktimersoftd/1 prev_pid=24 prev_prio=98 prev_state=S ==> next_comm=swapper/1 next_pid=0 next_prio=120
ktimerso-79 6d...2.. 1344661650us : sched_switch: prev_comm=ktimersoftd/6 prev_pid=79 prev_prio=98 prev_state=S ==> next_comm=swapper/6 next_pid=0 next_prio=120
ktimerso-35 2d...2.. 1344661650us : sched_switch: prev_comm=ktimersoftd/2 prev_pid=35 prev_prio=98 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120
rcuc/5-67 5d...2.. 1344661650us : sched_switch: prev_comm=rcuc/5 prev_pid=67 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/5 next_pid=68 next_prio=98
rcuc/7-89 7d...2.. 1344661650us : sched_switch: prev_comm=rcuc/7 prev_pid=89 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/7 next_pid=90 next_prio=98
ktimerso-4 0d...211 1344661650us : sched_wakeup: comm=rcu_preempt pid=8 prio=98 target_cpu=000
rcuc/4-56 4d...2.. 1344661651us : sched_switch: prev_comm=rcuc/4 prev_pid=56 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/4 next_pid=57 next_prio=98
ktimerso-4 0d...2.. 1344661651us : sched_switch: prev_comm=ktimersoftd/0 prev_pid=4 prev_prio=98 prev_state=S ==> next_comm=rcu_preempt next_pid=8 next_prio=98
ktimerso-90 7d...2.. 1344661651us : sched_switch: prev_comm=ktimersoftd/7 prev_pid=90 prev_prio=98 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120
ktimerso-68 5d...2.. 1344661651us : sched_switch: prev_comm=ktimersoftd/5 prev_pid=68 prev_prio=98 prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120
rcu_pree-8 0d...3.. 1344661652us : sched_wakeup: comm=rcuop/0 pid=10 prio=120 target_cpu=000
ktimerso-57 4d...2.. 1344661652us : sched_switch: prev_comm=ktimersoftd/4 prev_pid=57 prev_prio=98 prev_state=S ==> next_comm=swapper/4 next_pid=0 next_prio=120
rcu_pree-8 0d...2.. 1344661653us+: sched_switch: prev_comm=rcu_preempt prev_pid=8 prev_prio=98 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344661741us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344661742us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0d...2.. 1344661743us : sched_switch: prev_comm=cyclictest prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=rcuop/0 next_pid=10 next_prio=120
rcuop/0-10 0d...2.. 1344661744us!: sched_switch: prev_comm=rcuop/0 prev_pid=10 prev_prio=120 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344661858us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344661859us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0d...2.. 1344661860us!: sched_switch: prev_comm=cyclictest prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344661966us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344661966us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0d...2.. 1344661967us+: sched_switch: prev_comm=cyclictest prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344662052us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344662053us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0d...2.. 1344662054us!: sched_switch: prev_comm=cyclictest prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344662168us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344662168us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0d...2.. 1344662169us+: sched_switch: prev_comm=cyclictest prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344662255us : sched_wakeup: comm=irq/48-eth2-tx- pid=6310 prio=49 target_cpu=000
kworker/-5 0dN.h3.. 1344662256us : sched_wakeup: comm=irq/47-eth2-rx- pid=6309 prio=49 target_cpu=000
kworker/-5 0d...2.. 1344662256us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=irq/48-eth2-tx- next_pid=6310 next_prio=49
irq/48-e-6310 0d...2.. 1344662259us : sched_switch: prev_comm=irq/48-eth2-tx- prev_pid=6310 prev_prio=49 prev_state=S ==> next_comm=irq/47-eth2-rx- next_pid=6309 next_prio=49
irq/47-e-6309 0d...2.. 1344662260us+: sched_switch: prev_comm=irq/47-eth2-rx- prev_pid=6309 prev_prio=49 prev_state=S ==> next_comm=kworker/0:0 next_pid=5 next_prio=120
kworker/-5 0dN.h2.. 1344662300us : sched_wakeup: comm=cyclictest pid=6314 prio=19 target_cpu=000
kworker/-5 0d...2.. 1344662300us : sched_switch: prev_comm=kworker/0:0 prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest next_pid=6314 next_prio=19
cyclicte-6314 0.....11 1344662306us : tracing_mark_write: hit latency threshold (39 > 23)
Just before the long latency, the irqs "48-eth2-tx" and "48-eth2-rx" are active.
When looking at the 4th line from the bottom, the time for irq/47 is 1344662260us, for the next line (kworker) it is 1344662300us.
Does this mean that the irq/47 took 40us for irq processing? Or is this a misinterpretation?
For more lines of the trace please see the attached trace-extract.gz.
Thanks for any feedback.
Regard
Mahias
[-- Attachment #2: trace-extract.gz --]
[-- Type: application/x-gzip, Size: 1118 bytes --]
^ permalink raw reply
* 4.9-rc0: nf_hooks_ingress missing, breaking compilation
From: Pavel Machek @ 2016-10-06 6:58 UTC (permalink / raw)
To: kernel list, Netdev list, pablo, aconole
[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]
Hi!
In kernel based on edadd0e, I get plenty of errors such as:
net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’
rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
^
In file included from ./include/linux/linkage.h:4:0,
from ./include/linux/kernel.h:6,
from net/netfilter/core.c:10:
net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’
rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
^
Config is attached.
[Ok, I guess testing -rc0 is "a bit too brave" :-)]
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: delme.gz --]
[-- Type: application/gzip, Size: 26370 bytes --]
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Robert Jarzmik @ 2016-10-06 6:47 UTC (permalink / raw)
To: Mark Rutland
Cc: Rob Herring, Nicolas Pitre, Russell King - ARM Linux,
Arnd Bergmann, netdev, devicetree, linux-kernel
In-Reply-To: <871szx9rhc.fsf@belgarion.home>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Mark Rutland <mark.rutland@arm.com> writes:
>
>> On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
>>> Mark Rutland <mark.rutland@arm.com> writes:
>>>
>>> reg-u16-align4 tells that a specific hardware doesn't support 16 bit writes not
>>> being 32 bits aligned, or said differently that a "store" 16 bits wide on an
>>> address of the format 4*n + 2 deserves a special handling in the driver, while a
>>> store 16 bits wide on an address of the format 4*n can follow the simple casual
>>> case.
>>
>> If I've understood correctly, effectively the low 2 address lines to the
>> device are hard-wired to zero, e.g. a 16-bit access to 4*n + 2 would go
>> to 4*n + 0 on the device? Or is the failure case distinct from that?
> It is distinct.
>
> The "awful truth" is that an FPGA lies between the system bus and the
> smc91c111. And this FPGA cannot handle correctly the 4*n + 2 u16 writes.
>
>> Do we have other platforms where similar is true? e.g. u8 accesses
>> requiring 16-bit alignment?
>
> Not really, ie. not with a alignement requirement.
>
> But there are of course these ones are handled by reg-io-width and the
> SMC_USE_xxx_BITS flags as far as I understand it. These cases are when a
> platform declares SMC91X_USE_16BIT or SMC91X_USE_32BIT, but not SMC91X_USE_8BIT,
> which would make me think of :
> - CONFIG_SH_SH4202_MICRODEV,
> - CONFIG_M32R
> - several omap1 boards
> - 1 sa1100 board
> - several MMP and realview boards
>
> With all these platforms, each u8 access is replaced with a u16 access and a
> mask / shift + mask.
Or so what should I call this entry if reg-u16-align4 is not a good candidate ?
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.
From: Krister Johansen @ 2016-10-06 6:11 UTC (permalink / raw)
To: Cong Wang
Cc: Krister Johansen, Jamal Hadi Salim,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUya1ORUUNC9-spLKHjsjNyj6xHO79kvoDGaZcWT_mEwg@mail.gmail.com>
On Wed, Oct 05, 2016 at 11:01:38AM -0700, Cong Wang wrote:
> On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen
> <kjlx@templeofstupid.com> wrote:
> > On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote:
> >> Please try the attached patch. I also convert the read path to RCU
> >> to avoid a possible deadlock. A quick test shows no lockdep splat.
> >
> > I tried this patch, but it doesn't solve the problem. I got a panic on
> > my very first try:
>
> Thanks for testing it.
Absolutely; thanks for helping to try to simplify this fix.
> > The problem here is the same as before: by using RCU the race isn't
> > fixed because the module is still discoverable from act_base before the
> > pernet initialization is completed.
> >
> > You can see from the trap frame that the first two arguments to
> > tcf_hash_check were 0. It couldn't look up the correct per-subsystem
> > pointer because the id hadn't yet been registered.
>
> I thought the problem is that we don't do pernet ops registration and
> action ops registration atomically therefore chose to use mutex+RCU,
> but I was wrong, the problem here is just ordering, we need to finish
> the pernet initialization before making action ops visible.
>
> If so, why not just reorder them? Does the attached patch make any
> sense now? Our pernet init doesn't rely on act_base, so even we have
> some race, the worst case is after we initialize the pernet netns for an
> action but its ops still not visible, which seems fine (at least no crash).
>
> Or I still miss something here?
I'm not sure. The reason I didn't take this approach from the outset is
that all of TC's callers of tcf_register_action pass a pointer to a
static structure as their *ops argument. The existence of code that
checks the action for uniqueness suggests that it's possible for
tcf_register_action to get passed two identical tc_action_ops. If that
happens in the current code base, we'll also get passed a duplicate
pernet_operations pointer. The code in register_pernet_subsys() makes
no attempt to check for duplicates. If we add a pointer that's already
in the list, and subsequently call unregister, the results seem
undefined. It looks like we'll remove the pernet_operations for the
existing action, assuming we don't corrupt the list in the process.
Is this actually safe? If so, what corner case is the act->type /
act->kind protecting us from?
> (Sorry that I don't have the environment to reproduce your bug)
I'm sorry that I didn't do a good job of explaining how we end up in
this situation in the first place. I can give a few more details,
because it may explain some of my concern about the request_module()
call.
The system that encounters this bug launches a bunch of containers from
systemd on boot. Each container creates a new user, net, pid, and mount
namespace and begins its setup. When the networking in all of these
containers, each in a new netns, try to configure TC and no modules are
loaded we end up with this race.
I can also reproduce by unloading the modules, and then launching a
bunch of processes that configure tc in new namespaces.
Part of the desire to inhibit extra modprobe calls is that if hundreds
of these all start at once on boot, it's really unnecessary to have all
of the rest of them wait while lots of extra modprobe calls are forked
by the kernel.
> Thanks for your patience and testing!
Thank you for taking the time to look through the fix and discuss
alternatives.
-K
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-10-06 5:49 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Here are the build and merge fixups for the networking
stuff.
Please pull, thanks a lot!
The following changes since commit 41844e36206be90cd4d962ea49b0abc3612a99d0:
Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2016-10-05 14:50:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to af70c1f92d3567035d2f73f39079459d58c706dc:
phy: micrel.c: Enable ksz9031 energy-detect power-down mode (2016-10-05 21:19:06 -0400)
----------------------------------------------------------------
Aaron Conole (2):
netfilter: Fix potential null pointer dereference
netfilter: accommodate different kconfig in nf_set_hooks_head
David S. Miller (1):
Merge git://git.kernel.org/.../pablo/nf-next
Jann Horn (1):
netfilter: fix namespace handling in nf_log_proc_dostring
Liping Zhang (1):
netfilter: nft_limit: fix divided by zero panic
Mike Looijmans (1):
phy: micrel.c: Enable ksz9031 energy-detect power-down mode
Stephen Rothwell (1):
netfilter: merge fixup for "nf_tables_netdev: remove redundant ip_hdr assignment"
Vishwanath Pai (1):
netfilter: xt_hashlimit: Fix link error in 32bit arch because of 64bit division
drivers/net/phy/micrel.c | 21 +++++++++++++++++++++
include/net/netfilter/nf_tables_ipv4.h | 1 -
net/netfilter/core.c | 17 ++++++++++++-----
net/netfilter/nf_log.c | 6 ++++--
net/netfilter/nft_limit.c | 4 ++--
net/netfilter/xt_hashlimit.c | 15 ++++++++-------
6 files changed, 47 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] openvswitch: remove unreachable code in vlan parsing
From: Pravin Shelar @ 2016-10-06 5:22 UTC (permalink / raw)
To: Jiri Benc; +Cc: Linux Kernel Network Developers, Eric Garver
In-Reply-To: <3b310a67f5a708da69ee3cf617e6cedd52f85842.1475672569.git.jbenc@redhat.com>
On Wed, Oct 5, 2016 at 6:07 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Now when the first vlan tag is always in skb->vlan_tci, drop code that
> assumed it might not be the case.
>
User can turn off TX vlan offload for OVS internal device that would
allow vlan tagged packet with vlan header on the skb-data. This case
will cause issue here.
We could handle this case by not allowing this configuration.
> This patch also removes the wrong likely() statement around
> skb_vlan_tag_present introduced by 018c1dda5ff1 ("openvswitch: 802.1AD Flow
> handling, actions, vlan parsing, netlink attributes"). This code is called
> whenever flow key is being extracted from the packet, the packet may be as
> likely vlan tagged as not.
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
^ permalink raw reply
* Re: [PATCH net] Fixing a bug in team driver due to incorrect 'unsigned int' to 'int' conversion
From: David Miller @ 2016-10-06 5:19 UTC (permalink / raw)
To: alexandre.sidorenko; +Cc: eric.dumazet, netdev
In-Reply-To: <2440068.EFRMUI8i5V@zbook>
From: Alex Sidorenko <alexandre.sidorenko@hpe.com>
Date: Wed, 05 Oct 2016 09:06:04 -0400
> Roundrobin runner of team driver uses 'unsigned int' variable to count the number of sent_packets.
> Later it is passed to a subroutine team_num_to_port_index(struct team *team, int num) as
> 'num' and when we reach MAXINT (2**31-1), 'num' becomes negative.
>
> This leads to using incorrect hash-bucket for port lookup and as a result, packets are dropped. The fix
> consists of changing 'int num' to 'unsigned int num'. Testing of a fixed kernel shows that there
> is no packet drop anymore.
>
>
> Signed-off-by: Alex Sidorenko <alexandre.sidorenko@hpe.com>
This patch has been corrupted by your email client, for example it
has transformed TAB charactes into spaces.
Please fix this up, email a test patch to yourself, and only resubmit
this patch to the mailing list when you are able to successfully apply
the test patch you send to yourself.
Thanks.
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy@3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Tony Lindgren, Russell King, Florian Fainelli,
David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161006051355.15947-1-mugunthanvnm-l0cyMroinI0@public.gmane.org>
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N <mugunthanvnm-l0cyMroinI0@public.gmane.org>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.0.372.g6fe1b14
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.0.372.g6fe1b14
^ permalink raw reply
* Re: [GIT] Networking
From: Stephen Rothwell @ 2016-10-06 5:07 UTC (permalink / raw)
To: David Miller
Cc: torvalds, netfilter-devel, netdev, linux-kernel, pablo,
liping.zhang
In-Reply-To: <20161005.225612.251098478131222998.davem@davemloft.net>
Hi Dave,
On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> Yes, this is where the change got lost.
No worries.
> I have all of the fixups queued up in my net tree and will send in a pull
> request later.
Thanks.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* web.upgrades
From: Sistemas administrador @ 2016-10-06 4:36 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación:666690opp4r56 es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'
From: Sergey Senozhatsky @ 2016-10-06 4:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michal Sojka, Sergey Senozhatsky, Aaron Conole, linux-next,
linux-kernel, Stephen Rothwell, Florian Westphal,
Pablo Neira Ayuso, netdev, netfilter-devel, Sergey Senozhatsky
In-Reply-To: <1475701886.28155.223.camel@edumazet-glaptop3.roam.corp.google.com>
On (10/06/16 06:11), Eric Dumazet wrote:
> On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote:
>
> > this commit is now in mainline as
> > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build:
> >
> > net/netfilter/core.c: In function 'nf_set_hooks_head':
> > net/netfilter/core.c:96:3: error: 'struct net_device' has no member named 'nf_hooks_ingress'
> >
> > Are the fixes (see below) on the way to mainline too?
>
> Yes the fixes are already in nf tree and _will_ get pushed.
>
> Pablo and David are attending netdev 1.2 in Tokyo and have obligations.
>
> https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/
well, I did my best to avoid it, but the guys didn't even bother to
reply. pushing a knowingly broken patch that
a) kills the build
b) introduces a race
c) requires two "Fixes:" followup patches
to the main line despite the fact that those problems were discovered
at linux-next stage is totally un-cool.
-ss
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2016-10-06 2:56 UTC (permalink / raw)
To: sfr; +Cc: torvalds, netfilter-devel, netdev, linux-kernel, pablo,
liping.zhang
In-Reply-To: <20161006135152.3fd229cb@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 6 Oct 2016 13:51:52 +1100
> On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > Except that commit effectively moved that function from
>> > net/netfilter/nf_tables_netdev.c to
>> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
>> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
>> > removed the assignment in the original file (and has been in your tree
>> > since v4.8-rc7) and that is where I originally actually got a conflict.
>>
>> Oh, interesting. Why didn't I get the conflict there then?
>>
>> I'm guessing (but too lazy to actually look up the history), that
>> David ended up doing that merge and that ends up being why I never saw
>> a conflict.
>
> Yeah, commit b50afd203a5e ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
> merges v4.8 into the net-next tree.
Yes, this is where the change got lost.
I have all of the fixups queued up in my net tree and will send in a pull
request later.
^ permalink raw reply
* Re: [GIT] Networking
From: Stephen Rothwell @ 2016-10-06 2:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, NetFilter, Network Development,
Linux Kernel Mailing List, Pablo Neira Ayuso, Liping Zhang
In-Reply-To: <CA+55aFz0jv3xAQTwrspM3HkXQLVv_H4QuHf9a0Fq2Zm+=_sDtQ@mail.gmail.com>
Hi Linus,
On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Except that commit effectively moved that function from
> > net/netfilter/nf_tables_netdev.c to
> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> > removed the assignment in the original file (and has been in your tree
> > since v4.8-rc7) and that is where I originally actually got a conflict.
>
> Oh, interesting. Why didn't I get the conflict there then?
>
> I'm guessing (but too lazy to actually look up the history), that
> David ended up doing that merge and that ends up being why I never saw
> a conflict.
Yeah, commit b50afd203a5e ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
merges v4.8 into the net-next tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2016-10-06 2:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, NetFilter, Network Development,
Linux Kernel Mailing List, Pablo Neira Ayuso, Liping Zhang
In-Reply-To: <20161006115235.1a89c0da@canb.auug.org.au>
On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Except that commit effectively moved that function from
> net/netfilter/nf_tables_netdev.c to
> include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> removed the assignment in the original file (and has been in your tree
> since v4.8-rc7) and that is where I originally actually got a conflict.
Oh, interesting. Why didn't I get the conflict there then?
I'm guessing (but too lazy to actually look up the history), that
David ended up doing that merge and that ends up being why I never saw
a conflict.
Linus
^ permalink raw reply
* Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode
From: David Miller @ 2016-10-06 1:19 UTC (permalink / raw)
To: mike.looijmans; +Cc: netdev, f.fainelli, linux-kernel
In-Reply-To: <1475560324-23346-1-git-send-email-mike.looijmans@topic.nl>
From: Mike Looijmans <mike.looijmans@topic.nl>
Date: Tue, 4 Oct 2016 07:52:04 +0200
> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> ---
> v2: Unconditionally enable EDPD mode
Applied.
^ permalink raw reply
* Re: [GIT] Networking
From: Stephen Rothwell @ 2016-10-06 0:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, NetFilter, Network Development,
Linux Kernel Mailing List, Pablo Neira Ayuso, Liping Zhang
In-Reply-To: <CA+55aFzbHD95PMUk4JQfAVkDDRcwzZ6vfvMR60tZnQNSwkDE6A@mail.gmail.com>
Hi Linus,
On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to have
> > got missed:
>
> Ugh. It doesn't seem to be a merge error, because that double iph
> assignment came from the original patch that introduced this function:
> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
> ipv6}_validate()").
Except that commit effectively moved that function from
net/netfilter/nf_tables_netdev.c to
include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
removed the assignment in the original file (and has been in your tree
since v4.8-rc7) and that is where I originally actually got a conflict.
> So I wouldn't call it a merge error - it just looks like a bug in the
> network layer. So I'm not going to apply your patch even though it
> looks plausible to me, simply because it's outside my area of
> expertise.
no worries.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2016-10-06 0:26 UTC (permalink / raw)
To: pablo; +Cc: torvalds, sfr, netfilter-devel, netdev, linux-kernel,
liping.zhang
In-Reply-To: <20161006000945.GA18976@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 6 Oct 2016 02:09:45 +0200
> On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > I have been carrying the following merge fix patch (for the merge of
>> > the net-next tree with Linus' tree) for a while now which seems to have
>> > got missed:
>>
>> Ugh. It doesn't seem to be a merge error, because that double iph
>> assignment came from the original patch that introduced this function:
>> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
>> ipv6}_validate()").
>>
>> So I wouldn't call it a merge error - it just looks like a bug in the
>> network layer. So I'm not going to apply your patch even though it
>> looks plausible to me, simply because it's outside my area of
>> expertise.
>>
>> David? Pablo?
>
> This looks good, please take it so we speed up things.
>
> Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Applied.
^ permalink raw reply
* Re: [PATCH 0/5] Netfilter fixes for net-next
From: David Miller @ 2016-10-06 0:26 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1475712469-17000-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 6 Oct 2016 02:07:44 +0200
> This is a pull request to address fallout from previous nf-next pull
> request, only fixes going on here:
>
> 1) Address a potential null dereference in nf_unregister_net_hook()
> when becomes nf_hook_entry_head is NULL, from Aaron Conole.
>
> 2) Missing ifdef for CONFIG_NETFILTER_INGRESS, also from Aaron.
>
> 3) Fix linking problems in xt_hashlimit in x86_32, from Pai.
>
> 4) Fix permissions of nf_log sysctl from unpriviledge netns, from
> Jann Horn.
>
> 5) Fix possible divide by zero in nft_limit, from Liping Zhang.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks Pablo.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox