On 4 November 2015 at 14:49, Toby Corkindale wrote:
> Hi,
> I've subscribed to this list to try and sort out a regression in the
> bonding network driver.
> I originally reported this in Dec 2014, as:
> https://bugzilla.kernel.org/show_bug.cgi?id=89161
>
> The bug is still present in the 4.2 Linux
On Wed, 4 Nov 2015, Fengguang Wu wrote:
> On Tue, Nov 03, 2015 at 11:17:36AM -0500, David Miller wrote:
> > From: kbuild test robot
> > Date: Tue, 3 Nov 2015 23:25:39 +0800
> >
> > > net/mpls/af_mpls.c:722:22-23: Unneeded semicolon
> > >
> > >
> > > Remove unneeded semicolon.
> > >
> > > G
On 2015-11-04 06:58, Eric Dumazet wrote:
On Tue, 2015-11-03 at 20:46 -0800, Eric Dumazet wrote:
On Wed, 2015-11-04 at 06:25 +0200, Denys Fedoryshchenko wrote:
> On 2015-11-04 00:06, Cong Wang wrote:
> > On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
> > wrote:
> >> Hi!
> >>
> >> Actually
On Wed, 2015-11-04 at 06:49 +0200, Denys Fedoryshchenko wrote:
> Tested now, can be reproduced on 4.3 as well.
> What is interesting, if i enable tso alone, and leave gso/gro off - it
> is working fine. gso+gro on, tso off - fine also.
> But if i enable them all together - i trigger the bug.
If G
On Tue, 2015-11-03 at 20:46 -0800, Eric Dumazet wrote:
> On Wed, 2015-11-04 at 06:25 +0200, Denys Fedoryshchenko wrote:
> > On 2015-11-04 00:06, Cong Wang wrote:
> > > On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
> > > wrote:
> > >> Hi!
> > >>
> > >> Actually seems i was getting this pani
On 2015-11-04 06:28, Eric Dumazet wrote:
On Wed, 2015-11-04 at 06:12 +0200, Denys Fedoryshchenko wrote:
Just enabling gro or gso (or together) is fine there. Thanks for
advice.
Seems only tso causing problems.
Also i guess if i keep tso disabled, it will solve my MTU issues (i
had
once issue,
On Wed, 2015-11-04 at 06:25 +0200, Denys Fedoryshchenko wrote:
> On 2015-11-04 00:06, Cong Wang wrote:
> > On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
> > wrote:
> >> Hi!
> >>
> >> Actually seems i was getting this panic for a while (once per week) on
> >> loaded pppoe server, but just n
On Wed, 2015-11-04 at 06:12 +0200, Denys Fedoryshchenko wrote:
> Just enabling gro or gso (or together) is fine there. Thanks for advice.
> Seems only tso causing problems.
> Also i guess if i keep tso disabled, it will solve my MTU issues (i had
> once issue, that traffic heading to pppoe users,
On 2015-11-04 00:06, Cong Wang wrote:
On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
wrote:
Hi!
Actually seems i was getting this panic for a while (once per week) on
loaded pppoe server, but just now was able to get full panic message.
After checking commit logs on sch_fq.c i didnt seen
On 2015-11-03 23:23, Eric Dumazet wrote:
On Tue, 2015-11-03 at 22:24 +0200, Denys Fedoryshchenko wrote:
I wont argue on that, you are right.
Ok, then it is a bit offtopic in current case, different setup, but i
know this one has easy to reproduce issues with offloading. but this
is
bug related
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly added with that flag disabled as
well. This currently happens, because we exit __netdev_update_features()
when we se
Hi,
I've subscribed to this list to try and sort out a regression in the
bonding network driver.
I originally reported this in Dec 2014, as:
https://bugzilla.kernel.org/show_bug.cgi?id=89161
The bug is still present in the 4.2 Linux kernel.
If you look at the code, here:
https://github.com/torval
On 11/04/2015 12:18 AM, Stephen Hemminger wrote:
> The TIPC case is a missing check for memory allocation failure.
>
Thanks for the report. I will fix it soon.
Regards,
Ying
>
> Begin forwarded message:
>
> Date: Mon, 02 Nov 2015 23:45:55 -0800
> From: scan-ad...@coverity.com
> To: step...@ne
On Tue, Nov 03, 2015 at 11:17:36AM -0500, David Miller wrote:
> From: kbuild test robot
> Date: Tue, 3 Nov 2015 23:25:39 +0800
>
> > net/mpls/af_mpls.c:722:22-23: Unneeded semicolon
> >
> >
> > Remove unneeded semicolon.
> >
> > Generated by: scripts/coccinelle/misc/semicolon.cocci
> >
> > C
Hi Igal,
[auto build test ERROR on net/master]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/igal-liberman-freescale-com/Freescale-DPAA-FMan/20151103-003323
base: https://github.com/0day-ci/linux
igal-liberman-freescale-com/Freescale-DPAA-FMan/20151103
Release of iproute2 for Linux 4.3
Update to iproute2 utility to support new features in Linux 4.3.
There are the usual array of small fixes to output and formatting.
Phil Sutter has done a lot of work on manual pages and getting Redhat
patches merged.
Source:
http://www.kernel.org/pub/linux/uti
On Thu, 29 Oct 2015 12:15:47 +0100
Phil Sutter wrote:
> This patch is based upon an old Fedora bug[1] regarding the routing
> setup of PPP links. I'm not quite sure if it still applies today or how
> to trigger it, but looking at the change introducing this, it's
> obviously a bug.
>
> [1] https
On Thu, 29 Oct 2015 17:05:38 +0100
Phil Sutter wrote:
> Instead of statically complaining about illegal inet address, use
> get_family() to get the address family right.
>
> Based on a patch by Hangbin Liu to print "inet6" for AF_INET6 made more
> generic by me.
>
> Signed-off-by: Phil Sutter
On Thu, 29 Oct 2015 09:55:20 +
Phil Sutter wrote:
> This series adds man pages for ifcfg, genl and ifstat utilities. Some of
> them have already been submitted once in 2013[1] but weren't picked up
> for unknown reasons.
>
> Along with this comes a final patch fixing bridge fdb help text.
>
A bug report (https://bugzilla.kernel.org/show_bug.cgi?id=107071) noted
that the follwoing ip command is failing with v4.3:
$ ip route add 10.248.5.0/24 dev bond0.250 table vlan_250 src 10.248.5.154
RTNETLINK answers: Invalid argument
021dd3b8a142d changed the lookup of the given preferre
On 2015-11-03, at 6:25 PM, Linus Torvalds wrote:
> But if it's actually possible that the pa-risc L1 line size is really
> just 16 bytes, I guess that objection to the patch goes away. My
> automatic reaction was "that's not real, it's some odd workaround",
> but if it is actually real...
See pag
On 2015-11-03, at 6:43 PM, Guy Harris wrote:
>
> On Nov 3, 2015, at 3:03 PM, Helge Deller wrote:
>
>> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
>> really is.
>
> To which particular PA-RISC processor are you referring? It might not be the
> same on all process
On Nov 3, 2015, at 3:43 PM, Guy Harris wrote:
> To which particular PA-RISC processor are you referring? It might not be the
> same on all processors.
Chapter 3 "Addressing and Access Control" of PA-RISC 2.0 Architecture:
http://h21007.www2.hp.com/portal/download/files/unprot/parisc
On 29/10/15 18:11, Florian Fainelli wrote:
> The EPHY on GENET v1->v3 is extremely finicky, and will show occasional
> failures based on the timing and reset sequence, ranging from duplicate
> packets, to extremely high latencies.
>
> Perform an additional software reset, and re-configuration to m
On Nov 3, 2015, at 3:03 PM, Helge Deller wrote:
> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
> really is.
To which particular PA-RISC processor are you referring? It might not be the
same on all processors.
If openpa.net is to be believed, then:
The 7100LC has
Sasha reported the following lockdep warning:
Possible unsafe locking scenario:
CPU0CPU1
lock(sk_lock-AF_INET);
lock(rtnl_mutex);
lock(sk_lock-AF_INET);
lock(rt
On Tue, Nov 03, 2015 at 12:46:21PM -0800, Stephen Hemminger wrote:
> On Thu, 29 Oct 2015 13:09:56 +0100
> Phil Sutter wrote:
>
> > If `tc -force -batch' is fed by a controlling program from a pipe,
> > it's not possible to recognize when a command has been processes
> > successfully.
> >
> > Thi
On Tue, Nov 3, 2015 at 3:03 PM, Helge Deller wrote:
>
> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
> really is.
Wow.
Particularly that "it might actually be 16 bytes" from the thread
according to John David Anglin. I didn't expect anybody to really have
that small
On Tue, Nov 03, 2015 at 01:32:44PM -0500, David Miller wrote:
> From: Phil Sutter
> Date: Tue, 3 Nov 2015 19:01:41 +0100
>
> > It looks like this has never been used at all.
> >
> > Signed-off-by: Phil Sutter
>
> Indeed, from day one this was completely unreferenced.
I found it by accident w
On 11/3/15, 10:54 AM, Eric W. Biederman wrote:
> roopa writes:
>
>> On 11/3/15, 7:08 AM, Robert Shearman wrote:
>>> On 03/11/15 05:13, Roopa Prabhu wrote:
From: Roopa Prabhu
Adds support for RTNH_F_DEAD and RTNH_F_LINKDOWN flags on mpls
routes due to link events. Also adds cod
Hi Linus,
On 03.11.2015 22:01, Linus Torvalds wrote:
> On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller wrote:
>>
>> please pull some patches for the parisc architecture for kernel v4.3 from:
>
> So no way was I going to pull that for 4.3,
Yes, since you didn't pulled I assumed you saw some kind o
On 11/03/2015 02:11 PM, Jarod Wilson wrote:
Alexander Duyck wrote:
On 11/03/2015 12:36 PM, Jarod Wilson wrote:
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly a
Hi Cong,
[auto build test WARNING on net/master]
[also WARNING on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/Cong-Wang/ipv4-fix-a-potential-deadlock-in-mcast-getsockopt-path/20151104-055733
base: https://github.com/0day-ci/linux
Cong-Wang/ipv4-fix-a-potential
This fixes the following lockdep warning:
[ INFO: inconsistent lock state ]
4.3.0-rc7+ #1197 Not tainted
-
inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
sysctl/1019 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&net->ipv4.ip_local_ports.lock)->seqcount){+.+-..}, a
On 11/3/15 2:08 PM, Stephen Hemminger wrote:
when I try to add sudo ip route add 10.248.5.0/24 dev bond0.250 table vlan_250
src 10.248.5.154
I get RTNETLINK answers: Invalid argument
Probably a side effect of one my patches for VRF. I'll take a look.
--
To unsubscribe from this list: send the
Alexander Duyck wrote:
On 11/03/2015 12:36 PM, Jarod Wilson wrote:
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly added with that flag
disabled as
well. This cu
Hi Sabrina,
[auto build test ERROR on net/master]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/Sabrina-Dubroca/ipv6-clean-up-dev_snmp6-proc-entry-when-we-fail-to-initialize-inet6_dev/20151104-021328
base: https://github.com/0day-ci/linux
Sabrina
On Tue, Nov 3, 2015 at 1:33 PM, David Miller wrote:
>
>> David: the issue wrt XPS is this:
>>
>>#define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map)) \
>>/ sizeof(u16))
>>
>> Comments?
>
> The PARISC folks did discuss this with us networking folks...
>
> http:/
On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
wrote:
> Hi!
>
> Actually seems i was getting this panic for a while (once per week) on
> loaded pppoe server, but just now was able to get full panic message.
> After checking commit logs on sch_fq.c i didnt seen any fixes, so probably
> upgrad
On Tue, 2015-11-03 at 23:04 +0200, Andrew wrote:
> Hi.
>
> This is common trouble due to hierarchical shapers realization (global
> tree lock on packet dequeuing - so when one CPU looks for parent class
> where tokens can be borrowed, other CPUs are waiting). It's mentioned
> even in academic p
Michal Kubecek wrote:
On Tue, Nov 03, 2015 at 03:36:57PM -0500, Jarod Wilson wrote:
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly added with that flag disabled
Sasha reported the following lockdep warning:
Possible unsafe locking scenario:
CPU0CPU1
lock(sk_lock-AF_INET);
lock(rtnl_mutex);
lock(sk_lock-AF_INET);
lock(rt
While the ring allocation is done by a single function, sh_eth_ring_init(),
the ring deallocation was split into two functions (almost always called
one after the other) for no good reason. Merge sh_eth_free_dma_buffer()
into sh_eth_ring_free() which allows us to save space not only on the
direct
On Tue, Nov 03, 2015 at 03:36:57PM -0500, Jarod Wilson wrote:
> With moving netdev_sync_lower_features() after the .ndo_set_features
> calls, I neglected to verify that devices added *after* a flag had been
> disabled on an upper device were properly added with that flag disabled as
> well. This cu
Hi, Oliver.
> Comparing to typical ethernet frames with 1500 bytes the 16 bytes for CAN
> frames or 72 bytes for CAN FD frames are already too small in relation to the
> socket buffer overhead.
Ok, if there is no big difference using 4-bytes structure or 16-bytes
structures, I do not have any obj
On Tuesday, November 03, 2015 at 08:28:43 PM, Oliver Hartkopp wrote:
> On 11/03/2015 08:19 PM, Marek Vasut wrote:
> > On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
> >> On 11/03/2015 06:41 PM, Marek Vasut wrote:
> >>> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartk
On Monday, November 02, 2015 at 07:16:18 PM, Marek Vasut wrote:
> On Monday, November 02, 2015 at 12:14:27 PM, Oliver Hartkopp wrote:
> > On 02.11.2015 10:47, Marc Kleine-Budde wrote:
> > > On 11/02/2015 12:16 AM, Marek Vasut wrote:
> > >> The ARINC-429 is a technical standard, which describes, amo
On Tuesday, November 03, 2015 at 10:24:23 PM, Oliver Hartkopp wrote:
> Hi Andrey,
>
> On 11/03/2015 09:26 PM, Vostrikov Andrey wrote:
> > Hi, Oliver.
> >
> >> So when thinking about using PF_CAN as ARINC429 base ...
> >>
> >> This is the CAN frame structure:
> >>
> >> https://git.kernel.org/cgi
From: Linus Torvalds
Date: Tue, 3 Nov 2015 13:01:21 -0800
> David: the issue wrt XPS is this:
>
>#define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map)) \
>/ sizeof(u16))
>
> Comments?
The PARISC folks did discuss this with us networking folks...
http://marc
Hi Andrey,
On 11/03/2015 09:26 PM, Vostrikov Andrey wrote:
> Hi, Oliver.
>
>> So when thinking about using PF_CAN as ARINC429 base ...
>
>> This is the CAN frame structure:
>
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.
On Tue, 2015-11-03 at 22:24 +0200, Denys Fedoryshchenko wrote:
> I wont argue on that, you are right.
> Ok, then it is a bit offtopic in current case, different setup, but i
> know this one has easy to reproduce issues with offloading. but this is
> bug related to that, directly appearing when i
On 11/03/2015 09:36 PM, Jarod Wilson wrote:
> With moving netdev_sync_lower_features() after the .ndo_set_features
> calls, I neglected to verify that devices added *after* a flag had been
> disabled on an upper device were properly added with that flag disabled as
> well. This currently happens, b
The 'ret' local variable in sh_eth_ring_init() serves no useful purpose as
the only values it gets assigned are 0 and -ENOMEM both of which could be
returned directly...
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git' repo.
drivers/net/ethernet/renesas/sh_eth.c
On 11/03/2015 12:36 PM, Jarod Wilson wrote:
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly added with that flag disabled as
well. This currently happens, because
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, November 3, 2015 2:50 PM
> To: Haiyang Zhang
> Cc: eric.duma...@gmail.com; KY Srinivasan ;
> eduma...@google.com; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: increase LL_MAX_HEADER if
On Tue, Nov 3, 2015 at 10:07 PM, Eric Dumazet wrote:
> On Tue, 2015-11-03 at 13:57 +0100, Wolfgang Walter wrote:
>> Am Montag, 19. Oktober 2015, 20:40:17 schrieb Eric Dumazet:
>> > From: Eric Dumazet
>> >
>> > Tom Herbert added SIT support to GRO with commit
>> > 19424e052fb4 ("sit: Add gro callb
Add support for a fixed-link devicetree sub-node in case the the
cpsw MAC is directly connected to a non-mdio PHY/device.
Signed-off-by: Markus Brunner
---
Documentation/devicetree/bindings/net/cpsw.txt |5 +
drivers/net/ethernet/ti/cpsw.c | 13 +
2 files
This is a 4.3 kernel bug, not iproute2
Begin forwarded message:
Date: Tue, 3 Nov 2015 04:37:03 +
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "shemmin...@linux-foundation.org"
Subject: [Bug 107071] New: ip route add with src failes with RTNETLINK answers:
Invalid argument
https://bug
Hi.
This is common trouble due to hierarchical shapers realization (global
tree lock on packet dequeuing - so when one CPU looks for parent class
where tokens can be borrowed, other CPUs are waiting). It's mentioned
even in academic publications :) You can read about it here:
http://www.ijcse
On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller wrote:
>
> please pull some patches for the parisc architecture for kernel v4.3 from:
So no way was I going to pull that for 4.3, and I delayed it to the
merge window.
However, even now that we're in the merge window, and I look at it again:
> The m
From: Markus Elfring
Date: Tue, 3 Nov 2015 21:10:51 +0100
The variables "tt_local_entry" and "tt_global_entry" were eventually checked
again despite of a corresponding null pointer test before.
Let us avoid this double check by reordering a function call sequence
and the better selection of jump
From: Markus Elfring
Date: Tue, 3 Nov 2015 20:41:02 +0100
Let us split a check for a condition at the beginning of the
batadv_is_ap_isolated() function so that a direct return can be performed
in this function if the variable "vlan" contained a null pointer.
Signed-off-by: Markus Elfring
---
n
From: Markus Elfring
Date: Tue, 3 Nov 2015 19:20:34 +0100
The batadv_softif_vlan_free_ref() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfr
On Thu, 29 Oct 2015 13:09:56 +0100
Phil Sutter wrote:
> If `tc -force -batch' is fed by a controlling program from a pipe,
> it's not possible to recognize when a command has been processes
> successfully.
>
> This patch adds an optional `-OK' option to the tc(8) tool, so `tc
> -force -OK -batch
From: Markus Elfring
Date: Tue, 3 Nov 2015 21:34:29 +0100
Further update suggestions were taken into account after a patch
was applied from static source code analysis.
Markus Elfring (3):
Delete an unnecessary check before the function call
"batadv_softif_vlan_free_ref"
Split a condition c
On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds
wrote:
> result = add_overflow(
> mul_overflow(sec, SEC_CONVERSION, &overflow),
> mul_overflow(nsec, NSEC_CONVERSION, &overflow),
> &overflow);
>
> return overflow ? MAX_JIFFIES : result;
Thinking more about this ex
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly added with that flag disabled as
well. This currently happens, because we exit __netdev_update_features()
when we se
Hi, Oliver.
> So when thinking about using PF_CAN as ARINC429 base ...
> This is the CAN frame structure:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n264
> struct can_frame {
> canid_t can_id; /* 32
Dear User
We recently detected an unusual activity from your email account, hence your
mailbox has been temporally suspended by the system administrator, please
recover your account by clicking on the following link OR copy to your browser:
http://systemuqdatepanelpad0088.w3x.in/BE3/ITupdate_10
On 2015-11-03 21:49, Eric Dumazet wrote:
Well, I am telling you.
Say no to people advising to turn off GRO/TSO.
If you were the guy adviding others to do so, it is time to see the
light.
Lets fix the bugs if any, instead of spreading disinformation.
I am so tired of telling these very simple
Hi, Marek.
> So, considering that hi3593 which as 2x RX and 1x TX port, what about
> registering one device per port and be done with it ?
Yes, that is fine. It could be easily done.
Just drop tx requests on rx channel and vice versa.
--
Best regards,
Andrey Vostrikov
--
To unsubscribe from thi
On Tue, Nov 3, 2015 at 4:53 AM, Hannes Frederic Sowa
wrote:
>
> And furthermore we don't actually have to rely on CSE if we want to, our
> overflow checks could look much more simpler as in "ordinary" C code
> because we tell the compiler that signed overflow is defined throughout
> the kernel ( -
From: Sergei Shtylyov
Date: Tue, 03 Nov 2015 22:36:04 +0300
> Commit 7d7355f58ba4 ("sh_eth: Ensure proper ordering of descriptor active
> bit write/read") did the right thing but used too "heavy" barriers while
> there were already "lighter" DMA barriers exactly for this case...
>
> Signed-of
From: Eric Dumazet
Date: Tue, 03 Nov 2015 11:49:16 -0800
> If you prefer, continue to work on linux-2.0 but don't ask help on
> netdev.
+1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
From: Haiyang Zhang
Date: Tue, 3 Nov 2015 18:49:05 +
>> -Original Message-
>> From: David Miller [mailto:da...@davemloft.net]
>> Sent: Tuesday, November 3, 2015 1:20 PM
>> To: Haiyang Zhang
>> Cc: eric.duma...@gmail.com; KY Srinivasan ;
>> eduma...@google.com; netdev@vger.kernel.org
On Tue, 2015-11-03 at 21:17 +0200, Denys Fedoryshchenko wrote:
> GSO/TSO on the output and watch performance coming back.
>
> It is not, since i have more than 120 servers installed over country
> (most of them handle small traffic), in forwarding mode, first thing i
> am doing on forwarding se
Hi Sabrina,
[auto build test ERROR on net/master]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/Sabrina-Dubroca/ipv6-clean-up-dev_snmp6-proc-entry-when-we-fail-to-initialize-inet6_dev/20151104-021328
base: https://github.com/0day-ci/linux
Sabrina
Commit 7d7355f58ba4 ("sh_eth: Ensure proper ordering of descriptor active
bit write/read") did the right thing but used too "heavy" barriers while
there were already "lighter" DMA barriers exactly for this case...
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git'
Hello.
On 11/03/2015 10:30 PM, Denis Kirjanov wrote:
Commit 7d7355f58ba4 ("sh_eth: Ensure proper ordering of descriptor active
bit write/read") did the right thing but used too "heavy" barriers while
there were already "lighter" DMA barriers exactly for this case...
Signed-off-by: Sergei Sh
This patch went to 'stable', so I am a little uncertain about how to handle it.
Do I need to post a trailing commit that also goes to stable, or is net-next
sufficient?
Personally, I would prefer the latter.
///jon
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplu
On 11/3/15, Sergei Shtylyov wrote:
> Commit 7d7355f58ba4 ("sh_eth: Ensure proper ordering of descriptor active
> bit write/read") did the right thing but used too "heavy" barriers while
> there were already "lighter" DMA barriers exactly for this case...
>
> Signed-off-by: Sergei Shtylyov
Fix
On 11/03/2015 08:19 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
>> On 11/03/2015 06:41 PM, Marek Vasut wrote:
>>> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
>>>
>>> [...]
>>>
It looks like you need to shift the stuff
Commit 7d7355f58ba4 ("sh_eth: Ensure proper ordering of descriptor active
bit write/read") did the right thing but used too "heavy" barriers while
there were already "lighter" DMA barriers exactly for this case...
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git'
On Wed, 21 Oct 2015, Thomas Gleixner wrote:
> On Tue, 20 Oct 2015, John Stultz wrote:
>> Being able to have various hardware sharing a time base is quite
>> useful, and methods for correlating timestamps together are useful.
>> But I don't yet really understand why its important that we can
>> tr
On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
> On 11/03/2015 06:41 PM, Marek Vasut wrote:
> > On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
> >
> > [...]
> >
> >> It looks like you need to shift the stuff in user space every time.
> >>
> >> So you m
On 2015-11-03 21:11, Eric Dumazet wrote:
On Tue, 2015-11-03 at 19:33 +0200, Denys Fedoryshchenko wrote:
Hi
Recently i was testing shaping over single 10G cards, for speeds up to
3-4Gbps, and noticed interesting effect.
Shaping scheme:
Incoming bandwidth comes to switch port, with access vlan 1
On Tue, 2015-11-03 at 19:33 +0200, Denys Fedoryshchenko wrote:
> Hi
>
> Recently i was testing shaping over single 10G cards, for speeds up to
> 3-4Gbps, and noticed interesting effect.
>
> Shaping scheme:
> Incoming bandwidth comes to switch port, with access vlan 100
> Outgoing bandwidth leave
roopa writes:
> On 11/3/15, 7:08 AM, Robert Shearman wrote:
>> On 03/11/15 05:13, Roopa Prabhu wrote:
>>> From: Roopa Prabhu
>>>
>>> Adds support for RTNH_F_DEAD and RTNH_F_LINKDOWN flags on mpls
>>> routes due to link events. Also adds code to ignore dead
>>> routes during route selection
>>>
>
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, November 3, 2015 1:20 PM
> To: Haiyang Zhang
> Cc: eric.duma...@gmail.com; KY Srinivasan ;
> eduma...@google.com; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: increase LL_MAX_HEADER if
2015-11-03, 13:38:37 -0500, David Miller wrote:
> From: Cong Wang
> Date: Tue, 3 Nov 2015 10:30:20 -0800
>
> > On Tue, Nov 3, 2015 at 10:09 AM, Sabrina Dubroca
> > wrote:
> >> In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
> >> the dev_snmp6 entry that we have already
From: Cong Wang
Date: Tue, 3 Nov 2015 10:30:20 -0800
> On Tue, Nov 3, 2015 at 10:09 AM, Sabrina Dubroca wrote:
>> In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
>> the dev_snmp6 entry that we have already registered for this device.
>>
>> It is safe to call snmp6_unregi
From: Jiri Pirko
Date: Tue, 3 Nov 2015 17:40:53 +0100
> From: Jiri Pirko
>
> Caller passing down the SKIP_EOPNOTSUPP switchdev flag expects that
> -EOPNOTSUPP cannot be returned. But in case of direct op call without
> recurtion, this may happen. So fix this by checking it always on the
> end
From: Sabrina Dubroca
Date: Tue, 3 Nov 2015 19:09:09 +0100
> In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
> the dev_snmp6 entry that we have already registered for this device.
>
> It is safe to call snmp6_unregister_dev unconditionally from
> in6_dev_finish_destroy,
From: Phil Sutter
Date: Tue, 3 Nov 2015 19:01:41 +0100
> It looks like this has never been used at all.
>
> Signed-off-by: Phil Sutter
Indeed, from day one this was completely unreferenced.
One downside from marking so much stuff const is that an
unreferenced static variable won't be warned
From: SF Markus Elfring
Date: Tue, 3 Nov 2015 18:30:58 +0100
> From: Markus Elfring
> Date: Tue, 3 Nov 2015 18:18:37 +0100
>
> The irlmp_unregister_service() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue
On Tue, Nov 3, 2015 at 10:09 AM, Sabrina Dubroca wrote:
> In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
> the dev_snmp6 entry that we have already registered for this device.
>
> It is safe to call snmp6_unregister_dev unconditionally from
> in6_dev_finish_destroy, so do
On Tue, Nov 3, 2015 at 7:09 PM, Sabrina Dubroca wrote:
> In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
> the dev_snmp6 entry that we have already registered for this device.
>
> It is safe to call snmp6_unregister_dev unconditionally from
> in6_dev_finish_destroy, so do
From: Haiyang Zhang
Date: Tue, 3 Nov 2015 17:34:47 +
> But we still keep this busy return in our code, just for "weird corner cases".
The queue_stopped condition must be precise.
If you cannot enqueue a maximally segmented SKB, you must stop the queue.
--
To unsubscribe from this list: send
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, November 3, 2015 7:33 AM
> To: KY Srinivasan
> Cc: eric.duma...@gmail.com; Haiyang Zhang ;
> eduma...@google.com; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: increase LL_MAX_HEADER if
In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
the dev_snmp6 entry that we have already registered for this device.
It is safe to call snmp6_unregister_dev unconditionally from
in6_dev_finish_destroy, so do it.
Reported-by: Dmitry Vyukov
Acked-by: Hannes Frederic Sowa
1 - 100 of 199 matches
Mail list logo
