Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH kernel v2] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)
From: Alexey Kardashevskiy @ 2016-10-11  4:08 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Bjorn Helgaas, Netdev, Santosh Raspatur,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <CAKgT0Ue6VNb1Fko_OmFAn=3kOhesNVH+NsROiabR-NpKmwWvww@mail.gmail.com>

On 11/10/16 02:23, Alexander Duyck wrote:
> On Wed, Sep 28, 2016 at 10:21 PM, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>> 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 situation when the guest "cxgb3"
>> driver fails to probe the device. The host system does not have this
>> problem as the drives accesses the config space directly without
>> pci_read_vpd()/...
>>
>> This adds a quirk to override the VPD size to a bigger value.
>> The maximum size is taken from EEPROMSIZE in
>> drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag
>> as the cxgb3 driver does as the driver supports writing to EEPROM/VPD
>> and when it writes, it only checks for 8192 bytes boundary. The quirk
>> is registerted for all devices supported by the cxgb3 driver.
>>
>> This adds a quirk to the PCI layer (not to the cxgb3 driver) as
>> the cxgb3 driver itself accesses VPD directly and the problem only exists
>> with the vfio-pci driver (when cxgb3 is not running on the host and
>> may not be even loaded) which blocks accesses beyond the first block
>> of VPD data. However vfio-pci itself does not have quirks mechanism so
>> we add it to PCI.
>>
>> Tested on:
>> Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]
>>
>> This is its VPD:
>> 0000 Large item 42 bytes; name 0x2 Identifier String
>>         b'10 Gigabit Ethernet-SR PCI Express Adapter'
>>         #00 [EC] len=7: b'D76809 '
>>         #0a [FN] len=7: b'46K7897'
>>         #14 [PN] len=7: b'46K7897'
>>         #1e [MN] len=4: b'1037'
>>         #25 [FC] len=4: b'5769'
>>         #2c [SN] len=12: b'YL102035603V'
>>         #3b [NA] len=12: b'00145E992ED1'
>>
>> 0c00 Large item 16 bytes; name 0x2 Identifier String
>>         b'S310E-SR-X      '
>> 0c13 Large item 234 bytes; name 0x10
>>         #00 [PN] len=16: b'TBD             '
>>         #13 [EC] len=16: b'110107730D2     '
>>         #26 [SN] len=16: b'97YL102035603V  '
>>         #39 [NA] len=12: b'00145E992ED1'
>>         #48 [V0] len=6: b'175000'
>>         #51 [V1] len=6: b'266666'
>>         #5a [V2] len=6: b'266666'
>>         #63 [V3] len=6: b'2000  '
>>         #6c [V4] len=2: b'1 '
>>         #71 [V5] len=6: b'c2    '
>>         #7a [V6] len=6: b'0     '
>>         #83 [V7] len=2: b'1 '
>>         #88 [V8] len=2: b'0 '
>>         #8d [V9] len=2: b'0 '
>>         #92 [VA] len=2: b'0 '
>>         #97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
>> 0d00 Large item 252 bytes; name 0x11
>>         #00 [VC] len=16: b'122310_1222 dp  '
>>         #13 [VD] len=16: b'610-0001-00 H1\x00\x00'
>>         #26 [VE] len=16: b'122310_1353 fp  '
>>         #39 [VF] len=16: b'610-0001-00 H1\x00\x00'
>>         #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
>> 0dff Small item 0 bytes; name 0xf End Tag
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * used pci_set_vpd_size() helper
>> * added explicit list of IDs from cxgb3 driver
>> * added a note in the commit log why the quirk is not in cxgb3
>> ---
>>  drivers/pci/quirks.c | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 44e0ff3..b22fce5 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3243,6 +3243,28 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
>>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
>>                         quirk_thunderbolt_hotplug_msi);
>>
>> +static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
>> +{
>> +       if (!dev->vpd)
>> +               return;
>> +
>> +       pci_set_vpd_size(dev, max_t(unsigned int, dev->vpd->len, 8192));
> 
> What is the point of the max_t?  From what I can tell you aren't
> writing 8192, you will always end up writing 32K since that is the
> starting value for dev->vpd->len assuming there have yet to be any
> reads.

At this stage dev->vpd->len is always 32k? I thought here VPD was scanned
already, I'll double check.


> 
> What you may want to do instead is just modify the pci_vpd_size
> function you can use that in your quirk, and modify it so that you can
> pass an offset  Then you could just start it with an offset of 0x0c00
> and have it read to get the exact size of the region covered in this
> second block of the VPD.

Sorry, I am totally missing the point. The device allows writing to it, the
driver claims it is 8192, we can be pretty sure that accessing anything
between 0 and 8191 won't break the device (which was the initial point of
limiting VPD access), why do this scan? The format can be actually not
exactly as PCI VPD and probably there is some extension which I failed to
parse without knowing it (there are non zero bytes after the end of the
second block).



> 
>> +}
>> +
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
>> +
>>  #ifdef CONFIG_ACPI
>>  /*
>>   * Apple: Shutdown Cactus Ridge Thunderbolt controller.
>> --
>> 2.5.0.rc3
>>


-- 
Alexey

^ permalink raw reply

* Re: BUILD_BUG_ON error in mlx5/core/pagealloc.c
From: Tom Herbert @ 2016-10-11  3:58 UTC (permalink / raw)
  To: Saeed Mahameed; +Cc: Linux Kernel Network Developers, Saeed Mahameed
In-Reply-To: <CALzJLG911C=Chxgy0Fm_jLf7s8L21yqmQA4fqfn909o3VgnvRg@mail.gmail.com>

On Mon, Oct 10, 2016 at 8:17 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
>
>
> On Tuesday, October 11, 2016, Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Mon, Oct 10, 2016 at 4:41 PM, Tom Herbert <tom@herbertland.com> wrote:
>> > I am hitting this in mlx5
>> >
>> > drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
>> > ‘reclaim_pages_cmd.clone.0’:
>> > drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
>> > to ‘__compiletime_assert_346’ declared with attribute error:
>> > BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
>> > drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
>> > ‘give_pages’:
>> > drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
>> > to ‘__compiletime_assert_291’ declared with attribute error:
>> > BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64
>> >
>>
>> The expression in BUILD_BUG_ON expands to "((unsigned)(unsigned
>> long)(&(((struct mlx5_ifc_manage_pages_in_bits *)0)->pas[i]))) % 64".
>> The variable array index to pas makes this expression non-constant, I
>> imagine that is where the problem lies.
>>
>> > Bisecting points to:
>> >
>> > commit a533ed5e179cd15512d40282617909d3482a771c
>> > Author: Saeed Mahameed <saeedm@mellanox.com>
>> > Date:   Sun Jul 17 13:27:25 2016 +0300
>> >
>> >     net/mlx5: Pages management commands via mlx5 ifc
>
>
> Hi Tom,
> We know about this issue, it happens only with gcc4.4  or gcc 4.2 i don't
> remember exactly which.
> Most likely it is a gcc issue.
>
I don't believe that is the case. As I pointed out this is giving
BUILD_BUG_ON a non-constant expression. To fix this should just be a
matter of using a constant argument for the BUILD_BUG_ON. AFAICT
there's only two instances of MLX5_SET64 where this can be a problem.
I will post a fix shortly.

Tom

> Anyway, we are working on the issue and we will provide a fix or a W/A
> hopefully next week. This week most of the team are on vacation.
>
> Thanks
> Saeed.

^ permalink raw reply

* Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?
From: Chris Caputo @ 2016-10-11  3:57 UTC (permalink / raw)
  To: Liping Zhang
  Cc: Vishwanath Pai, Pablo Neira Ayuso, Justin Piszcz, linux-kernel,
	Linux Kernel Network Developers
In-Reply-To: <CAML_gOeNcgH-26iL6W5GDf0Ke0Sbpe9MTSULTvTnuiR9Cj_ZLA@mail.gmail.com>

On Tue, 11 Oct 2016, Liping Zhang wrote:
> Yes, thanks for clarifying this. There's a bug in kernel, can you try
> this patch:
> 
> diff --git a/net/netfilter/xt_NFLOG.c b/net/netfilter/xt_NFLOG.c
> index 018eed7..8c069b4 100644
> --- a/net/netfilter/xt_NFLOG.c
> +++ b/net/netfilter/xt_NFLOG.c
> @@ -32,6 +32,7 @@ nflog_tg(struct sk_buff *skb, const struct
> xt_action_param *par)
>         li.u.ulog.copy_len   = info->len;
>         li.u.ulog.group      = info->group;
>         li.u.ulog.qthreshold = info->threshold;
> +       li.u.ulog.flags      = 0;
> 
>         if (info->flags & XT_NFLOG_F_COPY_LEN)
>                 li.u.ulog.flags |= NF_LOG_F_COPY_LEN;

I have tested the above patch with 4.8.1, with and without nflog-size 
defined in an iptables configuration, and it works well.

The ulogd-2.0.5 segfaults no longer happen when nflog-size is not present 
in a target.

I recommend this fix.

Thanks,
Chris

^ permalink raw reply

* RFH: problems with adjacency graph
From: David Ahern @ 2016-10-11  2:18 UTC (permalink / raw)
  To: Jiri Pirko, vfalico, Nikolay Aleksandrov, roopa; +Cc: netdev@vger.kernel.org

Jiri / Veaceslav:

As author's of the adjacency tracking code in dev.c I am hoping you can help with suggested patches for a couple of problems. The start point needs to include commit 93409033ae65 which resolved a different problem from what I am seeing now.

At the moment I have 2 cases both for this topology:
        +--------+
        |  myvrf |
        +--------+
          |    |
          |  +---------+
          |  | macvlan |
          |  +---------+
          |    |
      +----------+
      |  bridge  |
      +----------+
          |
      +--------+
      | bond0  |
      +--------+
          |
      +--------+
      |  eth3  |
      +--------+


Base set of commands for both cases:

ip link add bond1 type bond
ip link set bond1 up
ip link set eth3 down
ip link set eth3 master bond1
ip link set eth3 up

ip link add bridge type bridge
ip link set bridge up
ip link add macvlan link bridge type macvlan
ip link set macvlan up

ip link add myvrf type vrf table 1234
ip link set myvrf up

ip link set bridge master myvrf


############################################################
# case 1

ip link set macvlan master myvrf
ip link set bond1 master bridge

ip link delete myvrf

dmesg has a splat triggered in __netdev_adjacent_dev_remove() where you currently see the BUG(). If you convert that to a WARN_ON (which it should be, no need to panic on the remove path) it will show you 4 missing adjacencies: eth3 - myvrf, mvrf - eth3, bond1 - myvrf and myvrf - bond1. All of those are because the dev_link function does not link macvlan lower devices to myvrf when it is enslaved. (Enable the debugging to see that those messages are missing.)



############################################################
# case 2

This case just flips the ordering of the enslavements:

ip link set bond1 master bridge
ip link set macvlan master myvrf

Then run:
ip link delete bond1
ip link delete myvrf

The last command hangs because myvrf has a reference that has not been released. If you do not have commit 93409033ae65 the delete of bond1 hangs for the same reason. For this case, the debug messages show that the macvlan lower devices (eth3 and bond1) are connected to myvrf on the enslavement, but the link delete the path only removes one of them hence the unreleased refcnt on myvrf.


In the end it seems that the code for the dependency graph is not making the complete mesh which causes problems on the tear down. I have attempted a few changes that so far fix 1 problem and uncover a different one. Hence the request for help from the author's of this code.

It seems like the complete mesh is not really needed, but cscope shows spectrum, ixgbe and bonding all using the for_each upper and lower device macros.

Suggestions?

David

^ permalink raw reply

* Re: [PATCH net] net: add recursion limit to GRO
From: Hannes Frederic Sowa @ 2016-10-11  1:13 UTC (permalink / raw)
  To: Eric Dumazet, Sabrina Dubroca; +Cc: netdev, Jiri Benc
In-Reply-To: <1476108236.28155.299.camel@edumazet-glaptop3.roam.corp.google.com>

Hi,

On Mon, Oct 10, 2016, at 16:03, Eric Dumazet wrote:
> On Mon, 2016-10-10 at 15:43 +0200, Sabrina Dubroca wrote:
> > Currently, GRO can do unlimited recursion through the gro_receive
> > handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
> > to one level with encap_mark, but both VLAN and TEB still have this
> > problem.  Thus, the kernel is vulnerable to a stack overflow, if we
> > receive a packet composed entirely of VLAN headers.
> > 
> > This patch adds a recursion counter to the GRO layer to prevent stack
> > overflow.  When a gro_receive function hits the recursion limit, GRO is
> > aborted for this skb and it is processed normally.
> > 
> > Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
>
> [...]
>
> Have you considered using a per cpu counter ?
> 
> It might be cheaper than using a 4-bit field in skb.
> 
> Really this counter does not need to be stored in skb. GRO already uses
> way too much space in skb->cb[]

The idea was to use some padding space and not bother with another
static per cpu allocation as long as there is space in the cb, which is
certainly more expensive in terms of memory consumption.

We can add a comment to make future users in gro_cb aware that this can
easily be moved to per cpu allocation if necessary in future?

Bye,
Hannes

^ permalink raw reply

* Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?
From: Liping Zhang @ 2016-10-11  0:58 UTC (permalink / raw)
  To: Chris Caputo
  Cc: Vishwanath Pai, Pablo Neira Ayuso, Justin Piszcz, linux-kernel,
	Linux Kernel Network Developers
In-Reply-To: <Pine.LNX.4.64.1610101818110.28174@nacho.alt.net>

2016-10-11 2:33 GMT+08:00 Chris Caputo <ccaputo@alt.net>:
>>
>> What numbers did you specify after --nflog-size option?
>> --nflog-size 0 or ...? If you want log the whole packet to
>> the ulogd, please do not specify this nflog-size option.
>
> Not specifying nflog-size does not appear to log the whole packet...
>
> If "--nflog-size" is unspecified, and the iptables config is left
> unchanged when the kernel is upgraded to 4.8, ulogd-2.0.5 crashes.
>
> If "--nflog-size 0" is used, ulogd-2.0.5 crashes.
>
> If "--nflog-size" is used with size 1 or greater, ulogd-2.0.5 is fine.
>
>> > I'm surprised to see a kernel change cause unexpected userspace segfaults,
>> > so further investigation into a kernel fix would seem a good idea.
>>
>> According to the original user's manual, nflog-range option was
>> designed to be the number of bytes copied to userspace, but
>> unfortunately there's a bug from the beginning and it never works,
>> i.e. in kernel, it just ignored this option.
>>
>> Try to change the current nflog-range option's semantics may
>> cause unexpected results(maybe like this ulogd crash) ...
>>
>> In order to keep compatibility, Vishwanath introduce a new
>> nflog-size option and keep nflog-range unchanged. If you just
>> upgrade the kernel, and do not change iptables rules, this
>> problem will not happen.
>
> I am reporting that the problem does happen simply with an upgrade to
> kernel 4.8 and no other changes.  When "--nflog-size" is unspecified or
> set to 0, the bug in ulogd-2.0.5 gets triggered.
>
> I agree there is a bug in ulogd-2.0.5 that this kernel change exposed, but
> I am trying to explain that all ulogd users risk this segfault if they
> upgrade to kernel 4.8 and don't either update to a fixed ulogd (possibly
> using your patch below) or an unreleased iptables with iptables config
> changes to implement nflog-size on each NFLOG target.

Yes, thanks for clarifying this. There's a bug in kernel, can you try
this patch:

diff --git a/net/netfilter/xt_NFLOG.c b/net/netfilter/xt_NFLOG.c
index 018eed7..8c069b4 100644
--- a/net/netfilter/xt_NFLOG.c
+++ b/net/netfilter/xt_NFLOG.c
@@ -32,6 +32,7 @@ nflog_tg(struct sk_buff *skb, const struct
xt_action_param *par)
        li.u.ulog.copy_len   = info->len;
        li.u.ulog.group      = info->group;
        li.u.ulog.qthreshold = info->threshold;
+       li.u.ulog.flags      = 0;

        if (info->flags & XT_NFLOG_F_COPY_LEN)
                li.u.ulog.flags |= NF_LOG_F_COPY_LEN;

Thanks

^ permalink raw reply related

* Re: slab corruption with current -git
From: Linus Torvalds @ 2016-10-11  0:54 UTC (permalink / raw)
  To: David Miller
  Cc: Aaron Conole, Florian Westphal, Al Viro, Andrew Morton,
	Jens Axboe, Theodore Ts'o, Christoph Lameter,
	Pablo Neira Ayuso, Linux Kernel Mailing List, linux-fsdevel,
	Network Development, NetFilter
In-Reply-To: <20161010.203019.388602181022157591.davem@davemloft.net>

On Mon, Oct 10, 2016 at 5:30 PM, David Miller <davem@davemloft.net> wrote:
>
> Linus can you add some extra info to that:

Sure. I made it a WARN_ON_ONCE(), but then always just printed the
pf/hooknum. It's all over the map:

 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=2
 reg->pf=2 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=2
 reg->pf=10 and reg->hooknum=3
 reg->pf=7 and reg->hooknum=1
 reg->pf=7 and reg->hooknum=2
 reg->pf=7 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=0
 reg->pf=2 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=0
 reg->pf=2 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=1
 reg->pf=2 and reg->hooknum=1
 reg->pf=10 and reg->hooknum=0
 reg->pf=10 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=0
 reg->pf=10 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=1
 reg->pf=10 and reg->hooknum=1
 reg->pf=7 and reg->hooknum=3
 reg->pf=7 and reg->hooknum=4
 reg->pf=7 and reg->hooknum=0
 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=2
 reg->pf=2 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=2
 reg->pf=10 and reg->hooknum=3
 reg->pf=7 and reg->hooknum=1
 reg->pf=7 and reg->hooknum=2
 reg->pf=7 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=0
 reg->pf=2 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=0
 reg->pf=2 and reg->hooknum=3
 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=4
 reg->pf=2 and reg->hooknum=1
 reg->pf=2 and reg->hooknum=1
 reg->pf=10 and reg->hooknum=0
 reg->pf=10 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=0
 reg->pf=10 and reg->hooknum=3
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=4
 reg->pf=10 and reg->hooknum=1
 reg->pf=10 and reg->hooknum=1
 reg->pf=7 and reg->hooknum=3
 reg->pf=7 and reg->hooknum=4
 reg->pf=7 and reg->hooknum=0

and putting that through "sort -n" and "uniq -c", I get:

      4  reg->pf=10 and reg->hooknum=0
      4  reg->pf=10 and reg->hooknum=1
      2  reg->pf=10 and reg->hooknum=2
      6  reg->pf=10 and reg->hooknum=3
      6  reg->pf=10 and reg->hooknum=4
      4  reg->pf=2 and reg->hooknum=0
      4  reg->pf=2 and reg->hooknum=1
      2  reg->pf=2 and reg->hooknum=2
      6  reg->pf=2 and reg->hooknum=3
      6  reg->pf=2 and reg->hooknum=4
      2  reg->pf=7 and reg->hooknum=0
      2  reg->pf=7 and reg->hooknum=1
      2  reg->pf=7 and reg->hooknum=2
      4  reg->pf=7 and reg->hooknum=3

which doesn't look much better. But clearly there's a lot of those
"try to unregister stuff that you can't even find".

Maybe it tells you something.

               Linus

^ permalink raw reply

* Re: slab corruption with current -git
From: David Miller @ 2016-10-11  0:30 UTC (permalink / raw)
  To: torvalds
  Cc: aconole, fw, viro, akpm, axboe, tytso, cl, pablo, linux-kernel,
	linux-fsdevel, netdev, netfilter-devel
In-Reply-To: <CA+55aFy0szySf+SnysjXTyfiU=RMBo9U1sHAVaTKG=tUTF+XGw@mail.gmail.com>

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 10 Oct 2016 12:05:17 -0700

> David - I think that also explains what was wrong with the old code.
> In the old code, this loop:
> 
>         while (hooks_entry && nf_entry_dereference(hooks_entry->next)) {
> 
> would exit with "hooks_entry" pointing to the last list entry (because
> ->next was NULL). Nothing was ever unlinked in the loop itself,
> because it never actually found a matching entry, but then after the
> loop it would free that last entry because it *thought* that was the
> match.

It only does this when the ops don't match, but yes it can happen.

Linus can you add some extra info to that:

		WARN(1, "nf_unregister_net_hook: hook not found!\n");

diagnostic, such as the reg->pf and reg->hooknum values?

That might help track down why this is happening in the first
place.

^ permalink raw reply

* [PATCH net-next] tcp: Change txhash on some non-RTO retransmits
From: Lawrence Brakmo @ 2016-10-11  0:18 UTC (permalink / raw)
  To: netdev; +Cc: Kernel Team, Eric Dumazet, Yuchung Cheng, Neal Cardwell

The purpose of this patch is to help balance flows across paths. A new
sysctl "tcp_retrans_txhash_prob" specifies the probability (0-100) that
the txhash (IPv6 flowlabel) will be changed after a non-RTO retransmit.
A probability is used in order to control how many flows are moved
during a congestion event and prevent the congested path from becoming
under utilized (which could occur if too many flows leave the current
path). Txhash changes may be delayed in order to decrease the likelihood
that it will trigger retransmists due to too much reordering.

Another sysctl "tcp_retrans_txhash_mode" determines the behavior after
RTOs. If the sysctl is 0, then after an RTO, only RTOs can trigger
txhash changes. The idea is to decrease the likelihood of going back
to a broken path. That is, we don't want flow balancing to trigger
changes to broken paths. The drawback is that flow balancing does
not work as well. If the sysctl is greater than 1, then we always
do flow balancing, even after RTOs.

Tested with packedrill tests (for correctness) and performance
experiments with 2 and 3 paths. Performance experiments looked at
aggregate goodput and fairness. For each run, we looked at the ratio of
the goodputs for the fastest and slowest flows. These were averaged for
all the runs. A fairness of 1 means all flows had the same goodput, a
fairness of 2 means the fastest flow was twice as fast as the slowest
flow.

The setup for the performance experiments was 4 or 5 serves in a rack,
10G links. I tested various probabilities, but 20 seemed to have the
best tradeoff for my setup (small RTTs).

                      --- node1 -----
    sender --- switch --- node2 ----- switch ---- receiver
                      --- node3 -----

Scenario 1: One sender sends to one receiver through 2 routes (node1 or
node 2). The output from node1 and node2 is 1G (1gbit/sec). With only 2
flows, without flow balancing (prob=0) the average goodput is 1.6G vs.
1.9G with flow balancing due to 2 flows ending up in one link and either
not moving and taking some time to move. Fairness was 1 in all cases.
For 7 flows, goodput was 1.9G for all, but fairness was 1.5, 1.4 or 1.2
for prob=0, prob=20,mode=0 and prob=20,mode=1 respectively. That is,
flow balancing increased fairness.

Scenario 2: One sender to one receiver, through 3 routes (node1,...
node2). With 6 or 16 flows the goodput was the same for all, but
fairness was 1.8, 1.5 and 1.2 respectively. Interestingly, the worst
case fairness out of 10 runs were 2.2, 1.8 and 1.4 repectively. That is,
prob=20,mode=1 improved average and worst case fairness.

Scenario 3: One sender to one receiver, 2 routes, one route drops 50% of
the packets. With 7 flows, goodput was the same 1.1G, but fairness was
1.8, 2.0 and 2.1 respectively. That is, if there is a bad route, then
balancing, which does more re-routes, is less fair.

Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
---
 Documentation/networking/ip-sysctl.txt | 15 +++++++++++++++
 include/linux/tcp.h                    |  4 +++-
 include/net/tcp.h                      |  2 ++
 net/ipv4/sysctl_net_ipv4.c             | 18 ++++++++++++++++++
 net/ipv4/tcp_input.c                   | 10 ++++++++++
 net/ipv4/tcp_output.c                  | 23 ++++++++++++++++++++++-
 net/ipv4/tcp_timer.c                   |  4 ++++
 7 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 3db8c67..87a984c 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -472,6 +472,21 @@ tcp_max_reordering - INTEGER
 	if paths are using per packet load balancing (like bonding rr mode)
 	Default: 300
 
+tcp_retrans_txhash_mode - INTEGER
+	If zero, disable txhash recalculation due to non-RTO retransmissions
+	after an RTO. The idea is that broken paths will trigger an RTO and
+	we don't want going back to that path due to standard retransmissons
+	(flow balancing). The drawback is that balancing is less robust.
+	If greater than zero, can always (probabilistically) recalculate
+	txhash after non-RTO retransmissions.
+
+tcp_retrans_txhash_prob - INTEGER
+	Probability [0 to 100] that we will recalculate txhash when a
+	packet is resent not due to RTO (for RTO txhash is always recalculated).
+	The recalculation of the txhash may be delayed to decrease the
+	likelihood that reordering will trigger retransmissons.
+	The purpose is to help balance the flows among the possible paths.
+
 tcp_retrans_collapse - BOOLEAN
 	Bug-to-bug compatibility with some broken printers.
 	On retransmit try to send bigger packets to work around bugs in
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index a17ae7b..e0e3b7d 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -214,7 +214,9 @@ struct tcp_sock {
 	} rack;
 	u16	advmss;		/* Advertised MSS			*/
 	u8	rate_app_limited:1,  /* rate_{delivered,interval_us} limited? */
-		unused:7;
+		txhash_rto:1,	/* If set, don't do flow balancing	*/
+		txhash_want:1,	/* We want to change txhash when safe	*/
+		unused:5;
 	u8	nonagle     : 4,/* Disable Nagle algorithm?             */
 		thin_lto    : 1,/* Use linear timeouts for thin streams */
 		thin_dupack : 1,/* Fast retransmit on first dupack      */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f83b7f2..3abd304 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -271,6 +271,8 @@ extern int sysctl_tcp_autocorking;
 extern int sysctl_tcp_invalid_ratelimit;
 extern int sysctl_tcp_pacing_ss_ratio;
 extern int sysctl_tcp_pacing_ca_ratio;
+extern int sysctl_tcp_retrans_txhash_prob;
+extern int sysctl_tcp_retrans_txhash_mode;
 
 extern atomic_long_t tcp_memory_allocated;
 extern struct percpu_counter tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 1cb67de..00d6f26 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -28,6 +28,7 @@
 static int zero;
 static int one = 1;
 static int four = 4;
+static int hundred = 100;
 static int thousand = 1000;
 static int gso_max_segs = GSO_MAX_SEGS;
 static int tcp_retr1_max = 255;
@@ -624,6 +625,23 @@ static struct ctl_table ipv4_table[] = {
 		.proc_handler	= proc_dointvec_ms_jiffies,
 	},
 	{
+		.procname	= "tcp_retrans_txhash_prob",
+		.data		= &sysctl_tcp_retrans_txhash_prob,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &zero,
+		.extra2		= &hundred,
+	},
+	{
+		.procname	= "tcp_retrans_txhash_mode",
+		.data		= &sysctl_tcp_retrans_txhash_mode,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &zero,
+	},
+	{
 		.procname	= "icmp_msgs_per_sec",
 		.data		= &sysctl_icmp_msgs_per_sec,
 		.maxlen		= sizeof(int),
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a27b9c0..fed5366 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -101,6 +101,9 @@ int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
 int sysctl_tcp_early_retrans __read_mostly = 3;
 int sysctl_tcp_invalid_ratelimit __read_mostly = HZ/2;
 
+int sysctl_tcp_retrans_txhash_prob __read_mostly;
+int sysctl_tcp_retrans_txhash_mode __read_mostly;
+
 #define FLAG_DATA		0x01 /* Incoming frame contained data.		*/
 #define FLAG_WIN_UPDATE		0x02 /* Incoming ACK was a window update.	*/
 #define FLAG_DATA_ACKED		0x04 /* This ACK acknowledged new data.		*/
@@ -3674,6 +3677,13 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
 	flag |= tcp_clean_rtx_queue(sk, prior_fackets, prior_snd_una, &acked,
 				    &sack_state, &now);
 
+	/* Check if we should set txhash (would not cause reordering) */
+	if (tp->txhash_want &&
+	    (tp->packets_out - tp->sacked_out) < tp->reordering) {
+		sk_set_txhash(sk);
+		tp->txhash_want = 0;
+	}
+
 	if (tcp_ack_is_dubious(sk, flag)) {
 		is_dupack = !(flag & (FLAG_SND_UNA_ADVANCED | FLAG_NOT_DUP));
 		tcp_fastretrans_alert(sk, acked, is_dupack, &flag, &rexmit);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 896e9df..58490ac 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2738,9 +2738,30 @@ int tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb, int segs)
 		tp->retrans_out += tcp_skb_pcount(skb);
 
 		/* Save stamp of the first retransmit. */
-		if (!tp->retrans_stamp)
+		if (!tp->retrans_stamp) {
 			tp->retrans_stamp = tcp_skb_timestamp(skb);
 
+			/* Determine if we should reset hash, only done once
+			 * per recovery
+			 */
+			if ((!tp->txhash_rto ||
+			     sysctl_tcp_retrans_txhash_mode > 0) &&
+			    sk->sk_txhash &&
+			    (prandom_u32_max(100) <
+			     sysctl_tcp_retrans_txhash_prob)) {
+				/* If not too much reordering, or RTT is
+				 * small enough that we don't care about
+				 * reordering, then change it now.
+				 * Else, wait until it is safe.
+				 */
+				if ((tp->packets_out - tp->sacked_out) <
+				    tp->reordering)
+					sk_set_txhash(sk);
+				else
+					tp->txhash_want = 1;
+			}
+		}
+
 	} else if (err != -EBUSY) {
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRETRANSFAIL);
 	}
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 3ea1cf8..e66baad 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -186,6 +186,8 @@ static int tcp_write_timeout(struct sock *sk)
 
 	if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
 		if (icsk->icsk_retransmits) {
+			tp->txhash_rto = 1;
+			tp->txhash_want = 0;
 			dst_negative_advice(sk);
 			if (tp->syn_fastopen || tp->syn_data)
 				tcp_fastopen_cache_set(sk, 0, NULL, true, 0);
@@ -218,6 +220,8 @@ static int tcp_write_timeout(struct sock *sk)
 		} else {
 			sk_rethink_txhash(sk);
 		}
+		tp->txhash_rto = 1;
+		tp->txhash_want = 0;
 
 		retry_until = net->ipv4.sysctl_tcp_retries2;
 		if (sock_flag(sk, SOCK_DEAD)) {
-- 
2.9.3

^ permalink raw reply related

* Re: BUILD_BUG_ON error in mlx5/core/pagealloc.c
From: Tom Herbert @ 2016-10-11  0:10 UTC (permalink / raw)
  To: Linux Kernel Network Developers, Saeed Mahameed
In-Reply-To: <CALx6S348UQF_oSqVSJ5h=K74_Q6cesR8g1Wf3rn14XRnRRBwgQ@mail.gmail.com>

On Mon, Oct 10, 2016 at 4:41 PM, Tom Herbert <tom@herbertland.com> wrote:
> I am hitting this in mlx5
>
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
> ‘reclaim_pages_cmd.clone.0’:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
> to ‘__compiletime_assert_346’ declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function ‘give_pages’:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
> to ‘__compiletime_assert_291’ declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64
>

The expression in BUILD_BUG_ON expands to "((unsigned)(unsigned
long)(&(((struct mlx5_ifc_manage_pages_in_bits *)0)->pas[i]))) % 64".
The variable array index to pas makes this expression non-constant, I
imagine that is where the problem lies.

> Bisecting points to:
>
> commit a533ed5e179cd15512d40282617909d3482a771c
> Author: Saeed Mahameed <saeedm@mellanox.com>
> Date:   Sun Jul 17 13:27:25 2016 +0300
>
>     net/mlx5: Pages management commands via mlx5 ifc
>
> Thanks,
> Tom

^ permalink raw reply

* BUILD_BUG_ON error in mlx5/core/pagealloc.c
From: Tom Herbert @ 2016-10-10 23:41 UTC (permalink / raw)
  To: Linux Kernel Network Developers, Saeed Mahameed

I am hitting this in mlx5

drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
‘reclaim_pages_cmd.clone.0’:
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
to ‘__compiletime_assert_346’ declared with attribute error:
BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function ‘give_pages’:
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
to ‘__compiletime_assert_291’ declared with attribute error:
BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64

Bisecting points to:

commit a533ed5e179cd15512d40282617909d3482a771c
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Sun Jul 17 13:27:25 2016 +0300

    net/mlx5: Pages management commands via mlx5 ifc

Thanks,
Tom

^ permalink raw reply

* RE: Accelerated receive flow steering (aRFS) for UDP
From: Chopra, Manish @ 2016-10-10 19:41 UTC (permalink / raw)
  To: Eric Dumazet, Rick Jones
  Cc: netdev@vger.kernel.org, maorg@mellanox.com, tom@herbertland.com
In-Reply-To: <1476119297.5650.0.camel@edumazet-glaptop3.roam.corp.google.com>

> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Monday, October 10, 2016 10:38 PM
> To: Rick Jones <rick.jones2@hpe.com>
> Cc: Chopra, Manish <Manish.Chopra@cavium.com>; netdev@vger.kernel.org;
> maorg@mellanox.com; tom@herbertland.com
> Subject: Re: Accelerated receive flow steering (aRFS) for UDP
> 
> On Mon, 2016-10-10 at 09:23 -0700, Rick Jones wrote:
> > On 10/10/2016 09:08 AM, Rick Jones wrote:
> > > On 10/09/2016 03:33 PM, Eric Dumazet wrote:
> > >> OK, I am adding/CC Rick Jones, netperf author, since it seems a netperf
> > >> bug, not a kernel one.
> > >>
> > >> I believe I already mentioned fact that "UDP_STREAM -- -N" was not doing
> > >> a connect() on the receiver side.
> > >
> > > I can confirm that the receive side of the netperf omni path isn't
> > > trying to connect UDP datagrams.  I will see what I can put together.
> >
> > I've put something together and pushed it to the netperf top of trunk.
> > It seems to have been successful on a quick loopback UDP_STREAM test.
> 
> Indeed, it looks better, thanks !
> 

Thanks Eric and Rick.  With this, problem got resolved now.
I do see flows getting steered for UDP packets now :-)

^ permalink raw reply

* Re: [PATCH net-next] sctp: remove the old ttl expires policy
From: Marcelo Ricardo Leitner @ 2016-10-10 21:19 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, Vlad Yasevich, daniel, davem
In-Reply-To: <db5df5806c3c0b7c37ab9039a906664a33c74563.1475898016.git.lucien.xin@gmail.com>

On Sat, Oct 08, 2016 at 11:40:16AM +0800, Xin Long wrote:
> The prsctp polices include ttl expires policy already, we should remove
> the old ttl expires codes, and just adjust the new polices' codes to be
> compatible with the old one for users.
> 
> This patch is to remove all the old expires codes, and if prsctp polices
> are not set, it will still set msg's expires_at and check the expires in
> sctp_check_abandoned.
> 
> Note that asoc->prsctp_enable is set by default, so users can't feel any
> difference even if they use the old expires api in userspace.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  include/net/sctp/structs.h |  1 -
>  net/sctp/chunk.c           | 32 ++++++++------------------------
>  net/sctp/output.c          |  3 ---
>  3 files changed, 8 insertions(+), 28 deletions(-)
> 
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 11c3bf2..61732e9 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -530,7 +530,6 @@ struct sctp_datamsg {
>  	/* Did the messenge fail to send? */
>  	int send_error;
>  	u8 send_failed:1,
> -	   can_abandon:1,   /* can chunks from this message can be abandoned. */
>  	   can_delay;	    /* should this message be Nagle delayed */
>  };
>  
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 7a1cdf4..615f0dd 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -52,7 +52,6 @@ static void sctp_datamsg_init(struct sctp_datamsg *msg)
>  	atomic_set(&msg->refcnt, 1);
>  	msg->send_failed = 0;
>  	msg->send_error = 0;
> -	msg->can_abandon = 0;
>  	msg->can_delay = 1;
>  	msg->expires_at = 0;
>  	INIT_LIST_HEAD(&msg->chunks);
> @@ -182,20 +181,11 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
>  	/* Note: Calculate this outside of the loop, so that all fragments
>  	 * have the same expiration.
>  	 */
> -	if (sinfo->sinfo_timetolive) {
> -		/* sinfo_timetolive is in milliseconds */
> +	if (asoc->peer.prsctp_capable && sinfo->sinfo_timetolive &&
> +	    (SCTP_PR_TTL_ENABLED(sinfo->sinfo_flags) ||
> +	     !SCTP_PR_POLICY(sinfo->sinfo_flags)))
>  		msg->expires_at = jiffies +
>  				    msecs_to_jiffies(sinfo->sinfo_timetolive);
> -		msg->can_abandon = 1;
> -
> -		pr_debug("%s: msg:%p expires_at:%ld jiffies:%ld\n", __func__,
> -			 msg, msg->expires_at, jiffies);
> -	}
> -
> -	if (asoc->peer.prsctp_capable &&
> -	    SCTP_PR_TTL_ENABLED(sinfo->sinfo_flags))
> -		msg->expires_at =
> -			jiffies + msecs_to_jiffies(sinfo->sinfo_timetolive);
>  
>  	/* This is the biggest possible DATA chunk that can fit into
>  	 * the packet
> @@ -354,18 +344,8 @@ errout:
>  /* Check whether this message has expired. */
>  int sctp_chunk_abandoned(struct sctp_chunk *chunk)
>  {
> -	if (!chunk->asoc->peer.prsctp_capable ||
> -	    !SCTP_PR_POLICY(chunk->sinfo.sinfo_flags)) {
> -		struct sctp_datamsg *msg = chunk->msg;
> -
> -		if (!msg->can_abandon)
> -			return 0;
> -
> -		if (time_after(jiffies, msg->expires_at))
> -			return 1;
> -
> +	if (!chunk->asoc->peer.prsctp_capable)
>  		return 0;
> -	}
>  
>  	if (SCTP_PR_TTL_ENABLED(chunk->sinfo.sinfo_flags) &&
>  	    time_after(jiffies, chunk->msg->expires_at)) {
> @@ -378,6 +358,10 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
>  		   chunk->sent_count > chunk->sinfo.sinfo_timetolive) {
>  		chunk->asoc->abandoned_sent[SCTP_PR_INDEX(RTX)]++;
>  		return 1;
> +	} else if (!SCTP_PR_POLICY(chunk->sinfo.sinfo_flags) &&
> +		   chunk->msg->expires_at &&
> +		   time_after(jiffies, chunk->msg->expires_at)) {
> +		return 1;
>  	}
>  	/* PRIO policy is processed by sendmsg, not here */
>  
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 2a5c189..f0af831 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -865,9 +865,6 @@ static void sctp_packet_append_data(struct sctp_packet *packet,
>  		rwnd = 0;
>  
>  	asoc->peer.rwnd = rwnd;
> -	/* Has been accepted for transmission. */
> -	if (!asoc->peer.prsctp_capable)
> -		chunk->msg->can_abandon = 0;
>  	sctp_chunk_assign_tsn(chunk);
>  	sctp_chunk_assign_ssn(chunk);
>  }
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [PATCH 4/4] gpio: ptxpmb-ext-cpld: Document bindings of PTXPMB extended CPLD
From: Rob Herring @ 2016-10-10 20:19 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
	Frank Rowand, Georgi Vlaev, Guenter Roeck,
	JawaharBalaji Thirumalaisamy, devicetree, linux-kernel,
	linux-gpio, linux-i2c, linux-mtd, linux-watchdog, netdev
In-Reply-To: <1475853574-22339-5-git-send-email-pantelis.antoniou@konsulko.com>

On Fri, Oct 07, 2016 at 06:19:34PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
> 
> Add device tree bindings document for the GPIO driver of
> Juniper's PTXPMB extended CPLD.
> 
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  .../bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt     | 36 ++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
> new file mode 100644
> index 0000000..87f01b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
> @@ -0,0 +1,36 @@
> +Juniper PTXPMB extended CPLD GPIO block
> +
> +Required properties:
> +
> +- compatible:
> +    Must be "jnx,gpio-ptxpmb-ext-cpld"

Generally, '-gpio' would be last.

> +
> +- #gpio-cells:
> +    Should be <2>.  The first cell is the pin number (within the controller's
> +    pin space), and the second is used for the following flags:
> +	bit[0]: direction (0 = out, 1 = in)
> +	bit[1]: init high
> +	bit[2]: active low

Same comment as all the other gpio bindings...

> +
> +- gpio-controller:
> +    Specifies that the node is a GPIO controller.
> +
> +- interrupt-controller:
> +    Specifies that the node is an interrupt controller.
> +
> +Optional properties:
> +
> +- reg:
> +    Address and length of the register set for the device. Usually supplied
> +    by the parent MFD device.

Make it required.

> +
> +
> +Example:
> +
> +gpio_ext_cpld: cpld-ext-gpio {
> +	compatible = "jnx,gpio-ptxpmb-ext-cpld";
> +	#gpio-cells = <2>;
> +	#interrupt-cells = <2>;
> +	gpio-controller;
> +	interrupt-controller;
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH 2/4] mfd: ptxpmb-ext-cpld: Add documentation for PTXPMB extended CPLD
From: Rob Herring @ 2016-10-10 20:10 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Mark Rutland, Alexandre Courbot, linux-watchdog, devicetree,
	Frank Rowand, Linus Walleij, linux-kernel,
	JawaharBalaji Thirumalaisamy, linux-gpio, linux-mtd, linux-i2c,
	netdev, Georgi Vlaev, Lee Jones, Guenter Roeck
In-Reply-To: <1475853574-22339-3-git-send-email-pantelis.antoniou@konsulko.com>

On Fri, Oct 07, 2016 at 06:19:32PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
> 
> Add DT bindings document for the PTXPMB extended CPLD device.
> 
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  .../bindings/mfd/jnx-ptxpmb-ext-cpld.txt           | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
> new file mode 100644
> index 0000000..098a548a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
> @@ -0,0 +1,35 @@
> +* Device tree bindings for Juniper's PTXPMB Extended CPLD FPGA MFD driver
> +
> +The device supports a gpio block which is described in the
> +jnx-gpio-ptxpmb-ext-cpld document.
> +
> +Required properties:
> +
> +- compatible:		"jnx,ptxpmb-ext-cpld"
> +
> +- reg:			contains offset/length value for device state control
> +			registers space.
> +
> +Optional properties:
> +
> +- interrupts:		The interrupt line(s) the /IRQ signal(s) for the device is
> +			connected to.
> +
> +- interrupt-parent:	The parent interrupt controller.
> +
> +Example:
> +
> +ext-cpld@1,0 {
> +	compatible = "jnx,ptxpmb-ext-cpld";
> +	reg = <0x1 0 0x1000>;

What's the bus type here? Unit address is probably wrong.

> +	interrupt-parent = <&mpic>;
> +	interrupts = <7 2>, <8 2>;
> +
> +	gpio_ext_cpld: cpld-ext-gpio {
> +		compatible = "jnx,gpio-ptxpmb-ext-cpld";
> +		#gpio-cells = <2>;
> +		#interrupt-cells = <2>;
> +		gpio-controller;
> +		interrupt-controller;
> +	};
> +};
> -- 
> 1.9.1
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH 08/10] mtd: flash-sam: Bindings for Juniper's SAM FPGA flash
From: Rob Herring @ 2016-10-10 20:07 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
	Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
	Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
	Georgi Vlaev, Guenter Roeck, Maryam Seraj,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475853518-22264-9-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>

gOn Fri, Oct 07, 2016 at 06:18:36PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> 
> Add binding document for Junipers Flash IP block present
> in the SAM FPGA on PTX series of routers.
> 
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
>  .../devicetree/bindings/mtd/flash-sam.txt          | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/flash-sam.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/flash-sam.txt b/Documentation/devicetree/bindings/mtd/flash-sam.txt
> new file mode 100644
> index 0000000..bdf1d78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/flash-sam.txt
> @@ -0,0 +1,31 @@
> +Flash device on a Juniper SAM FPGA
> +
> +These flash chips are found in the PTX series of Juniper routers.
> +
> +They are regular CFI compatible (Intel or AMD extended) flash chips with
> +some special write protect/VPP bits that can be controlled by the machine's
> +system controller.

And where's the description of the sys ctrlr?

> +
> +Required properties:
> +- compatible : must be "jnx,flash-sam"
> +
> +Optional properties:
> +- reg : memory address for the flash chip, note that this is not
> +required since usually the device is a subdevice of the SAM MFD
> +driver which fills in the register fields.
> +
> +For the rest of the properties, see mtd-physmap.txt.
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> +flash_sam {
> +	compatible = "jnx,flash-sam";
> +	partition@0 {

This should have a heirarchy of a controller node, a flash child node, 
partitions child node, and partition child nodes.

> +		reg = <0x0 0x400000>;
> +		label = "pic0-golden";
> +		read-only;
> +	};
> +};
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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

* Re: [PATCH net 2/3] openvswitch: fix vlan subtraction from packet length
From: Pravin Shelar @ 2016-10-10 20:05 UTC (permalink / raw)
  To: Jiri Benc; +Cc: Linux Kernel Network Developers, Eric Garver
In-Reply-To: <310ec523056b4f4747e800333498ef27ad1248aa.1476111550.git.jbenc@redhat.com>

On Mon, Oct 10, 2016 at 8:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
> header is not counted in skb->len. It doesn't make sense to subtract it.
>
> Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>

Acked-by: Pravin B Shelar <pshelar@ovn.org>

^ permalink raw reply

* Re: [PATCH net 3/3] openvswitch: add NETIF_F_HW_VLAN_STAG_TX to internal dev
From: Pravin Shelar @ 2016-10-10 20:05 UTC (permalink / raw)
  To: Jiri Benc; +Cc: Linux Kernel Network Developers, Eric Garver
In-Reply-To: <688ddda46c331c1b85450d6f28b1441af6cee1de.1476111550.git.jbenc@redhat.com>

On Mon, Oct 10, 2016 at 8:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> The internal device does support 802.1AD offloading since 018c1dda5ff1
> ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink
> attributes").
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>

Acked-by: Pravin B Shelar <pshelar@ovn.org>

^ permalink raw reply

* Re: [PATCH net 1/3] openvswitch: vlan: remove wrong likely statement
From: Pravin Shelar @ 2016-10-10 20:05 UTC (permalink / raw)
  To: Jiri Benc; +Cc: Linux Kernel Network Developers, Eric Garver
In-Reply-To: <a4b63fa787569359d227beecbdbf9b023081cffc.1476111550.git.jbenc@redhat.com>

On Mon, Oct 10, 2016 at 8:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> This code is called whenever flow key is being extracted from the packet.
> The packet may be as likely vlan tagged as not.
>
> Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>

Acked-by: Pravin B Shelar <pshelar@ovn.org>

^ permalink raw reply

* Re: [PATCH 06/10] gpio: sam: Document bindings of SAM FPGA GPIO block
From: Rob Herring @ 2016-10-10 20:03 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
	Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
	Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
	Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
	linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
	netdev
In-Reply-To: <1475853518-22264-7-git-send-email-pantelis.antoniou@konsulko.com>

On Fri, Oct 07, 2016 at 06:18:34PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
> 
> Add device tree bindings document for the GPIO driver of
> Juniper's SAM FPGA.
> 
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  .../devicetree/bindings/gpio/jnx,gpio-sam.txt      | 110 +++++++++++++++++++++
>  1 file changed, 110 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
> new file mode 100644
> index 0000000..514c350
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
> @@ -0,0 +1,110 @@
> +Juniper SAM FPGA GPIO block
> +
> +The controller's registers are organized as sets of eight 32-bit
> +registers with each set controlling a bank of up to 32 pins.  A single
> +interrupt is shared for all of the banks handled by the controller.
> +
> +Required properties:
> +
> +- compatible:
> +    Must be "jnx,gpio-sam"
> +
> +- #gpio-cells:
> +    Should be <2>.  The first cell is the pin number (within the controller's
> +    pin space), and the second is used for the following flags:
> +	bit[0]: direction (0 = out, 1 = in)
> +	bit[1]: init high
> +	bit[2]: active low
> +	bit[3]: open drain
> +	bit[4]: open drain

Use and/or add to standard flags.

> +
> +- gpio-controller:
> +    Specifies that the node is a GPIO controller.
> +
> +Optional properties:
> +
> +- reg:
> +    This driver is part of the SAM FPGA MFD driver, so the
> +    address range is supplied by that driver. However you can
> +    override using this property.
> +
> +- gpio-base:
> +    Base of the GPIO pins of this instance. If not present use system allocated.

This probably needs to go.

> +
> +- gpio-count:

ngpios instead.

> +    Number of GPIO pins of this instance. If not present read the number from
> +    the one configured in the FPGA data. Maximum number is 512.
> +
> +- #interrupt-cells:
> +    Should be <2>.  The first cell is the GPIO number, the second should specify
> +    flags.  The following subset of flags is supported:
> +    - bits[16,4:0] trigger type and level flags
> +	bit  0: rising edge interrupt
> +	bit  1: falling edge interrupt
> +	bit  2: active high interrupt
> +	bit  3: active low interrupt
> +	bit  4: enable debounce
> +	bit 16: signal is active low

What does this mean?

> +    See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +- gpio-interrupts:
> +    A number of triples that define the mapping of interrupt groupsb to a range of
> +    pins. The first cell defines the interrupt group, the second is the start of
> +    the pin range and the third the number of pins in the range.

Needs a vendor prefix.

> +
> +- gpio-exports:
> +    A subnode containing the list of pins that will be exported to user-space.

DT doesn't know about userspace. Drop this.

> +    Each subnode contains:
> +    Required properties:
> +	- pin: The gpio to be exported and the relevant flags.
> +    Optional properties:
> +        - label: The label to use for export; if not supplied use the node name.
> +
> +Example:
> +
> +gpio20: gpio-sam {
> +	compatible = "jnx,gpio-sam";
> +	gpio-controller;
> +	interrupt-controller;
> +	/* 1st cell: gpio pin
> +	 * 2nd cell: flags (bit mask)
> +	 * bit  0: rising edge interrupt
> +	 * bit  1: falling edge interrupt
> +	 * bit  2: active high interrupt
> +	 * bit  3: active low interrupt
> +	 * bit  4: enable debounce
> +	 * bit 16: signal is active low
> +	 */
> +	#interrupt-cells = <2>;
> +	#gpio-cells = <2>;
> +	gpio-count = <340>;
> +	/* 1st cell: gpio interrupt status bit
> +	 * 2nd cell: 1st pin
> +	 * 3rd cell: # of pins
> +	 */
> +	gpio-interrupts =
> +		<0 0 32>,	/* TL / TQ */
> +		<1 32 32>,	/* PIC 1 */
> +		<2 32 32>,	/* PIC 1 spare */
> +		<7 148 32>,	/* PIC 0 */
> +		<8 170 32>,	/* PIC 0 spare */
> +		<16 318 22>;	/* FPC */
> +
> +	gpio-exports {
> +		/*
> +		 * flags:
> +		 * GPIOF_DIR_IN			bit 0=1
> +		 * GPIOF_DIR_OUT		bit 0=0
> +		 * GPIOF_INIT_HIGH		bit 1=1
> +		 *   GPIOF_INIT_HIGH is raw, not translated
> +		 * GPIOF_ACTIVE_LOW		bit 2=1
> +		 * GPIOF_OPEN_DRAIN		bit 3=1
> +		 * GPIOF_OPEN_SOURCE		bit 4=1
> +		 * GPIOF_EXPORT			bit 5=1
> +		 * GPIOF_EXPORT_CHANGEABLE      bit 6=1
> +		 */
> +		tl0-rst {
> +			pin = < 8 0x24 >;
> +		};
> +	};
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH net-next] sctp: reuse sent_count to avoid retransmitted chunks for RTT measurements
From: Marcelo Ricardo Leitner @ 2016-10-10 19:56 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, Vlad Yasevich, daniel, davem
In-Reply-To: <20161010174825.GC2958@localhost.localdomain>

On Mon, Oct 10, 2016 at 02:48:25PM -0300, Marcelo Ricardo Leitner wrote:
> On Sat, Oct 08, 2016 at 11:36:05AM +0800, Xin Long wrote:
> > Now sctp uses chunk->resent to record if a chunk is retransmitted, for
> > RTT measurements with retransmitted DATA chunks. chunk->sent_count was
> > introduced to record how many times one chunk has been sent for prsctp
> > RTX policy before. We actually can know if one chunk is retransmitted
> > by checking chunk->sent_count is greater than 1.
> > 
> > This patch is to remove resent from sctp_chunk and reuse sent_count
> > to avoid retransmitted chunks for RTT measurements.
> > 
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> 
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

Though you may have to resend later, as we are still in merge window and
we shouldn't be posting net-next patches during it.

^ permalink raw reply

* Re: [PATCH 04/10] i2c: i2c-sam: Add device tree bindings
From: Rob Herring @ 2016-10-10 19:54 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
	Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
	Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
	Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
	linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
	netdev
In-Reply-To: <1475853518-22264-5-git-send-email-pantelis.antoniou@konsulko.com>

On Fri, Oct 07, 2016 at 06:18:32PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
> 
> Add binding document for the i2c driver of SAM FPGA.
> 
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  .../devicetree/bindings/i2c/i2c-sam-mux.txt        | 20 ++++++++++
>  Documentation/devicetree/bindings/i2c/i2c-sam.txt  | 44 ++++++++++++++++++++++
>  2 files changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sam.txt
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
> new file mode 100644
> index 0000000..10ddffa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam-mux.txt
> @@ -0,0 +1,20 @@
> +Juniper's SAM FPGA I2C accelerator mux
> +
> +The SAM FPGA I2C mux is present only on Juniper SAM FPGA PTX series
> +of routers.
> +
> +The definition of the i2c sam bus is located in the i2c-sam.txt document.
> +
> +Required properties:
> +- compatible: should be "jnx,i2c-sam-mux".
> +- reg: master number and mux number.

This is not how i2c muxes are done.

> +
> +Optional properties:
> +- speed: If present must be either 100000 or 400000. No other values supported.
> +
> +Examples:
> +
> +pe1i2c: i2c-sam-mux@1,0 {

i2c-mux@...

> +	compatible = "jnx,i2c-sam-mux";
> +	reg = <1 0>;
> +};
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-sam.txt b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
> new file mode 100644
> index 0000000..4830b48
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-sam.txt
> @@ -0,0 +1,44 @@
> +Juniper's SAM FPGA I2C accelerator
> +
> +The SAM FPGA accelerator is used to connect the large number of
> +I2C muxes that are present on Juniper PTX series of routers.
> +While it's an i2c bus, no other devices are located besides
> +i2c-sam-mux devices.
> +
> +The definition of the i2c sam mux is located in the i2c-sam-mux.txt document.
> +
> +Required properties:
> +- compatible: should be "jnx,i2c-sam".
> +- #address-cells: should be 2.
> +- #size-cells: should be 0.
> +- mux-channels: number of mux channels present

What is this needed for?

> +
> +Optional properties:
> +- reg: offset and length of the register set for the device are optional since
> +  typically the register range is provided by the parent SAM MFD device.
> +- master-offset: Offset of where the master register memory starts.
> +  Default value is 0x8000.

Make this required.

> +- reverse-fill: Fill the start entries of transactions in reverse order

Needs a better explanation.

> +- priority-tables: Use the pre-programmed priority tables in the FPGA

What does not present mean?

> +- i2c-options: list of options to be written to the option field in the
> +  FPGA controlling things like SCL push-pull drives, hold-times, etc.

> +- bus-range: start of bus master range and number of masters.

Needs a better explanation.

> +
> +Examples:
> +
> +i2c-sam {
> +	compatible = "jnx,i2c-sam";
> +	mux-channels = <2>;
> +	#size-cells = <0>;
> +	#address-cells = <2>;
> +
> +	/* PE0 */ pe0i2c: i2c-sam-mux@0,0 {

i2c-mux@...

> +		compatible = "jnx,i2c-sam-mux";
> +		reg = <0 0>;
> +	};
> +
> +	/* PE1 */ pe1i2c: i2c-sam-mux@1,0 {
> +		compatible = "jnx,i2c-sam-mux";
> +		reg = <1 0>;
> +	};
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH 02/10] mfd: sam: Add documentation for the SAM FPGA
From: Rob Herring @ 2016-10-10 19:47 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Lee Jones, Linus Walleij, Alexandre Courbot, Mark Rutland,
	Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
	Florian Fainelli, Wim Van Sebroeck, Peter Rosin, Debjit Ghosh,
	Georgi Vlaev, Guenter Roeck, Maryam Seraj, devicetree,
	linux-kernel, linux-gpio, linux-i2c, linux-mtd, linux-watchdog,
	netdev
In-Reply-To: <1475853518-22264-3-git-send-email-pantelis.antoniou@konsulko.com>

On Fri, Oct 07, 2016 at 06:18:30PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev@juniper.net>
> 
> Add DT bindings document for the SAM MFD device.
> 
> Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  Documentation/devicetree/bindings/mfd/jnx-sam.txt | 94 +++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/jnx-sam.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/jnx-sam.txt b/Documentation/devicetree/bindings/mfd/jnx-sam.txt
> new file mode 100644
> index 0000000..b4af7ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/jnx-sam.txt
> @@ -0,0 +1,94 @@
> +Device-Tree bindings for Juniper Networks SAM MFD
> +
> +Required properties:
> +
> +- compatible - Must be: "jnx,sam"

Kind of generic. Only 1 FPGA version or some other way to tell the 
version?

> +
> +Optional properties:
> +
> +- pma-coefficients: A set of tupples containing the configuration of the PMA.

What's a PMA? What type of configuration? How many entries?

> +Device                   Description
> +------                   -----------
> +jnx,i2c-sam		: I2C mux driver
> +jnx,gpio-sam		: GPIO block
> +jnx,flash-sam		: MTD Flash
> +jnx,mdio-sam		: MDIO interfaces
> +
> +All these optional nodes are described in their respective binding
> +documents.
> +
> +Example node:
> +
> +pci-0000-10-00.0 {

What are the numbers?

> +	compatible = "jnx,sam";

If this is a PCI device, then it should use PCI compatible string 
syntax.

> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	pma-coefficients = <4 0x0>;
> +
> +	i2c-sam@10 {
> +		compatible = "jnx,i2c-sam";
> +		mux-channels = <2>;
> +		master-offset = <0x10000>;
> +	};
> +
> +	gpiogpqam0: gpio-sam@10 {

gpio@...

Where does 10 come from?

> +		compatible = "jnx,gpio-sam";
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-count = <297>;
> +		interrupt-controller;
> +		/*
> +		* 1st cell: gpio interrupt status bit
> +		* 2nd cell: 1st pin
> +		* 3rd cell: # of pins
> +		*/
> +		gpio-interrupts =
> +			<0 0 12>,   /* phy_int_monitor_en [16] */
> +			<1 235 24>, /* qsfpp_fpga_int_monitor [17] */
> +			<2 259 24>, /* qsfpp_fpga_modprs_monitor [18] */
> +			<3 295 1>,  /* si5345_fpga_monitor [19] */
> +			<4 294 1>;  /* fpc_pic_int_monitor [20] */
> +	};
> +
> +	flash-sam@10 {
> +		compatible = "jnx,flash-sam";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		partition@0 {
> +		reg = <0x0 0x400000>;
> +			label = "pic0-golden";
> +			read-only;
> +		};
> +		partition@400000 {
> +			reg = <0x400000 0x400000>;
> +			label = "pic0-user";
> +		};
> +	};
> +
> +	mdio-sam@10 {
> +		compatible = "jnx,mdio-sam";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x40000>;
> +
> +		/* mii_bus types */
> +		mdio0: mdio-sam@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x0>;
> +		};
> +
> +		mdio1: mdio-sam@4000 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x4000>;
> +		};
> +
> +		mdio2: mdio-sam@8000 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x8000>;
> +		};
> +	};
> +};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Julia Cartwright @ 2016-10-10 19:39 UTC (permalink / raw)
  To: Koehrer Mathias (ETAS/ESW5)
  Cc: Williams, Mitch A, Kirsher, Jeffrey T, Greg,
	netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	linux-rt-users@vger.kernel.org, Sebastian Andrzej Siewior
In-Reply-To: <29250f87b1d84aacb8aa312935582291@FE-MBX1012.de.bosch.com>

Hello Mathias-

On Fri, Oct 07, 2016 at 08:58:08AM +0000, Koehrer Mathias (ETAS/ESW5) wrote:
[..]
> I modified the in-kernel's igb_main.c (function igb_watchdog_task) to comment out
> the access to the EICS registers:
> 
> --- igb_main.c.orig     2016-10-07 10:43:37.855873754 +0200
> +++ igb_main.c  2016-10-07 10:31:51.451346292 +0200
> @@ -4613,6 +4613,7 @@ no_wait:
>         }
> 
>         /* Cause software interrupt to ensure Rx ring is cleaned */
> +#if 0
>         if (adapter->flags & IGB_FLAG_HAS_MSIX) {
>                 u32 eics = 0;
> 
> @@ -4622,6 +4623,7 @@ no_wait:
>         } else {
>                 wr32(E1000_ICS, E1000_ICS_RXDMT0);
>         }
> +#endif
> 
>         igb_spoof_check(adapter);
>         igb_ptp_rx_hang(adapter);
> 
> 
> The result is now slighty better, however the max latency that has been measured by
> cyclictest is still much higher compared to the values of kernel 3.18.27-rt27.
> I have now enabled all events, the execution of 
> # cyclictest -a -i 105 -m -n -p 80 -t 1  -b 30 -C
> delivers the following trace values

There is something still fishy with these traces...

> cyclicte-10062   0....... 10025813402us : sys_exit: NR 230 = 0
> cyclicte-10062   0....... 10025813402us : sys_enter: NR 230 (1, 1, 7ffff73ff930, 0, 0, 2bd7e12e)
> cyclicte-10062   0....... 10025813402us : hrtimer_init: hrtimer=ffff88040a017e18 clockid=CLOCK_MONOTONIC mode=HRTIMER_MODE_ABS
> cyclicte-10062   0d...1.. 10025813403us : hrtimer_start: hrtimer=ffff88040a017e18 function=hrtimer_wakeup expires=10024735653388 softexpires=10024735653388

cyclictest thread sleeps waiting for wakeup at 10024735653388.

> cyclicte-10062   0d...1.. 10025813403us : write_msr: 6e0, value 20ca630b9aef
> cyclicte-10062   0d...1.. 10025813403us : rcu_utilization: Start context switch
> cyclicte-10062   0d...1.. 10025813403us : rcu_utilization: End context switch
> cyclicte-10062   0d...2.. 10025813404us : sched_switch: prev_comm=cyclictest prev_pid=10062 prev_prio=19 prev_state=S ==> next_comm=kworker/0:3 next_pid=1388 next_prio=120
> cyclicte-10062   0d...2.. 10025813404us+: x86_fpu_regs_deactivated: x86/fpu: ffff88040c603ec0 fpregs_active: 0 fpstate_active: 1 counter: 69 xfeatures: 2 xcomp_bv: 0
> kworker/-1388    0d..h... 10025813468us : irq_handler_entry: irq=48 name=eth2-tx-0
> kworker/-1388    0d..h... 10025813468us : irq_handler_exit: irq=48 ret=handled
> kworker/-1388    0d..h1.. 10025813469us : sched_waking: comm=irq/48-eth2-tx- pid=10057 prio=49 target_cpu=000
> kworker/-1388    0dN.h2.. 10025813469us : sched_wakeup: comm=irq/48-eth2-tx- pid=10057 prio=49 target_cpu=000
> kworker/-1388    0dN.h1.. 10025813470us : irq_handler_entry: irq=47 name=eth2-rx-0
> kworker/-1388    0dN.h1.. 10025813470us : irq_handler_exit: irq=47 ret=handled
> kworker/-1388    0dN.h2.. 10025813471us : sched_waking: comm=irq/47-eth2-rx- pid=10056 prio=49 target_cpu=000
> kworker/-1388    0dN.h3.. 10025813471us : sched_wakeup: comm=irq/47-eth2-rx- pid=10056 prio=49 target_cpu=000

So, kworker/0:3 was busy doing something, and we received both tx and rx
interrupts from eth2, waking up the relevant threads.

> kworker/-1388    0dN..1.. 10025813472us : rcu_utilization: Start context switch
> kworker/-1388    0dN..1.. 10025813472us : rcu_utilization: End context switch
> kworker/-1388    0dN..2.. 10025813472us : sched_stat_runtime: comm=kworker/0:3 pid=1388 runtime=67566 [ns] vruntime=101216288332 [ns]
> kworker/-1388    0d...2.. 10025813472us : sched_switch: prev_comm=kworker/0:3 prev_pid=1388 prev_prio=120 prev_state=R+ ==> next_comm=irq/48-eth2-tx- next_pid=10057 next_prio=49
> irq/48-e-10057   0d....11 10025813473us : softirq_raise: vec=3 [action=NET_RX]
> irq/48-e-10057   0.....12 10025813474us : softirq_entry: vec=3 [action=NET_RX]
> irq/48-e-10057   0.....12 10025813475us : napi_poll: napi poll on napi struct ffff88040a582850 for device eth2 work 0 budget 64

Hmm, the irq/48-eth2-tx- thread is raising NET_RX?  That seems...wrong.

> irq/48-e-10057   0.....12 10025813475us : softirq_exit: vec=3 [action=NET_RX]
> irq/48-e-10057   0d...1.. 10025813475us : rcu_utilization: Start context switch
> irq/48-e-10057   0d...1.. 10025813476us : rcu_utilization: End context switch
> irq/48-e-10057   0d...2.. 10025813476us : sched_switch: prev_comm=irq/48-eth2-tx- prev_pid=10057 prev_prio=49 prev_state=S ==> next_comm=irq/47-eth2-rx- next_pid=10056 next_prio=49
> irq/47-e-10056   0d....11 10025813477us : softirq_raise: vec=3 [action=NET_RX]
> irq/47-e-10056   0.....12 10025813477us : softirq_entry: vec=3 [action=NET_RX]
> irq/47-e-10056   0.....12 10025813478us : napi_poll: napi poll on napi struct ffff88040a580850 for device eth2 work 0 budget 64
> irq/47-e-10056   0.....12 10025813478us : softirq_exit: vec=3 [action=NET_RX]

Oh, then we do the same thing again?  Hrmph...why?

> irq/47-e-10056   0d...1.. 10025813479us : rcu_utilization: Start context switch
> irq/47-e-10056   0d...1.. 10025813479us : rcu_utilization: End context switch
> irq/47-e-10056   0d...2.. 10025813479us+: sched_switch: prev_comm=irq/47-eth2-rx- prev_pid=10056 prev_prio=49 prev_state=S ==> next_comm=kworker/0:3 next_pid=1388 next_prio=120

Done handling the two interrupts.  Back to whatever kworker/0:3 was up
to...

> kworker/-1388    0d..h... 10025813516us : local_timer_entry: vector=239
> kworker/-1388    0d..h1.. 10025813516us : hrtimer_interrupt: cpu=0 offset=-28999 curr=kworker/0:3[120] thread=cyclictest[19]
> kworker/-1388    0d..h1.. 10025813517us : hrtimer_cancel: hrtimer=ffff88040a017e18
> kworker/-1388    0d..h... 10025813517us : hrtimer_expire_entry: hrtimer=ffff88040a017e18 function=hrtimer_wakeup now=10024735682387

Okay, we finally received our wakeup event.  We were expecting to be
woken up at 10024735653388ns, but were actually woken up at 10024735682387ns.

  10024735682387 - 10024735653388 = 28999ns

Our timer fired ~29us late!  But why...?

Sorry I don't have answers, just more questions.  I do wonder what
kworker/0:3 was up to at the time the timer interrupt should have fired.

   Julia

^ permalink raw reply

* Re: slab corruption with current -git (was Re: [git pull] vfs pile 1 (splice))
From: Aaron Conole @ 2016-10-10 19:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Florian Westphal, Al Viro, Andrew Morton, Jens Axboe,
	Ted Ts'o, Christoph Lameter, David Miller, Pablo Neira Ayuso,
	Linux Kernel Mailing List, linux-fsdevel, Network Development,
	NetFilter
In-Reply-To: <CA+55aFy0szySf+SnysjXTyfiU=RMBo9U1sHAVaTKG=tUTF+XGw@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, Oct 10, 2016 at 9:28 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So as I already answered to Dave, I'm not actually sure that this was
>> the buggy code, or that my patch would make any difference at all.
>
> My patch does seem to fix things, and in fact the warning about "hook
> not found" now triggers.
>
> So I think the bug really was that the singly-linked list handling
> code did not correctly handle the case of not finding the entry, and
> then freed (incorrectly) the last one that wasn't actually unlinked.
>
> In fact, I get quite a few warnings (56 total) about 30 seconds after
> logging in:
>
> [   54.213170] WARNING: CPU: 1 PID: 111 at net/netfilter/core.c:151
> nf_unregister_net_hook+0x8e/0x170
> ... repeat 54 times ...
> [   54.445520] WARNING: CPU: 7 PID: 111 at net/netfilter/core.c:151
> nf_unregister_net_hook+0x8e/0x170
>
> and looking in the journal, the first one is (again) immediately
> preceded by that systemd-hostnamed service stopping:
>
>   Oct 10 11:45:47 i7 audit[1546]: USER_LOGIN
>   ...
>   Oct 10 11:46:11 i7 audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
>   Oct 10 11:46:13 i7 pulseaudio[1697]: [pulseaudio] bluez5-util.c:
> GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did
> not receive a reply. Possible causes include: the remote application
> did not send a reply, the message bus security policy blocked the
> reply, the reply timeout expir
>   Oct 10 11:46:13 i7 dbus-daemon[1003]: [system] Failed to activate
> service 'org.bluez': timed out
>   Oct 10 11:46:20 i7 audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-hostnamed comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
>   Oct 10 11:46:20 i7 kernel: ------------[ cut here ]------------
>   Oct 10 11:46:20 i7 kernel: WARNING: CPU: 1 PID: 111 at
> net/netfilter/core.c:151 nf_unregister_net_hook+0x8e/0x170
>
> so I do think it's something to do with some network startup service
> thing (perhaps dhcp, perhaps chrome, who knows) as I do my initial
> login.
>
> David - I think that also explains what was wrong with the old code.
> In the old code, this loop:
>
>         while (hooks_entry && nf_entry_dereference(hooks_entry->next)) {
>
> would exit with "hooks_entry" pointing to the last list entry (because
> ->next was NULL). Nothing was ever unlinked in the loop itself,
> because it never actually found a matching entry, but then after the
> loop it would free that last entry because it *thought* that was the
> match.
>
> My list rewrite fixes that.
>
> Anyway, I'm assuming it will come to me from the networking tree after
> more testing by the maintainers. You can add my
>
>   Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> to the patch, though.
>
> David, if you want me to just commit that thing directly, I can
> obviously do so, but I do think somebody should look at
>
>  (a) that I actually got the priority list ordering right on the
>  insertion side

It looks correct.

Reviewed-by: Aaron Conole <aconole@bytheb.org>

>  (b) what it is that makes it try to unregister that hook that isn't
> on the list in the first place

This is a still problem, I think.  I wasn't able to reproduce the issue
on a fedora-23 VM.  My fedora 24 bare-metal system does trigger this,
though.  Not sure what changed in userspace/kernel interaction side (not
an excuse, but just an observation).

> but on the whole I consider this issue explained and solved. I'll
> continue to run with my patch on my machine (just not committed).

Okay.  Very sorry for this, again.

>               Linus

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox