* pull request: batman-adv 2013-10-09b
From: Antonio Quartulli @ 2013-10-09 19:32 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
here you have my fixed pull request intended for net-next.
The previous build error was due to an accidental remotion of the beginning of a
batadv_dbg() statement during a merge conflict resolution.
Sorry for that.
Please pull or let me know of any problem.
Thanks a lot,
Antonio
The following changes since commit 3d7d562ca4a884089344eb13451b5903a18d3817:
bnx2x: Add ndo_get_phys_port_id support (2013-10-09 14:55:13 -0400)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
for you to fetch changes up to 18c68d5960c8dfeb2db113f4b871bab259cfd565:
batman-adv: reorder batadv_iv_flags (2013-10-09 21:22:35 +0200)
----------------------------------------------------------------
Included changes:
- update emails for A. Quartulli and M. Lindner in MAINTAINERS
- switch to the next on-the-wire protocol version
- introduce the T(ype) V(ersion) L(ength) V(alue) framework
- adjust the existing components to make them use the new TVLV code
- make the TT component use CRC32 instead of CRC16
- totally remove the VIS functionality (has been moved to userspace)
- reorder packet types and flags
- add static checks on packet format
- remove __packed from batadv_ogm_packet
----------------------------------------------------------------
Antonio Quartulli (4):
MAINTAINERS: batman-adv - update emails
batman-adv: switch to a new packet compatibility version
batman-adv: use CRC32C instead of CRC16 in TT code
batman-adv: move BATADV_TT_CLIENT_TEMP to higher bit
Marek Lindner (7):
batman-adv: tvlv - basic infrastructure
batman-adv: tvlv - gateway download/upload bandwidth container
batman-adv: tvlv - add distributed arp table container
batman-adv: tvlv - add network coding container
batman-adv: tvlv - convert tt data sent within OGMs
batman-adv: tvlv - convert tt query packet to use tvlv unicast packets
batman-adv: tvlv - convert roaming adv packet to use tvlv unicast packets
Simon Wunderlich (5):
batman-adv: remove vis functionality
batman-adv: add build check macros for packet member offset
batman-adv: reorder packet types
batman-adv: remove packed from batadv_ogm_packet
batman-adv: reorder batadv_iv_flags
Documentation/ABI/testing/sysfs-class-net-mesh | 11 -
Documentation/networking/batman-adv.txt | 50 +-
MAINTAINERS | 4 +-
net/batman-adv/Makefile | 1 -
net/batman-adv/bat_iv_ogm.c | 111 +--
net/batman-adv/debugfs.c | 9 -
net/batman-adv/distributed-arp-table.c | 64 ++
net/batman-adv/distributed-arp-table.h | 5 +
net/batman-adv/gateway_client.c | 187 +++--
net/batman-adv/gateway_client.h | 2 +-
net/batman-adv/gateway_common.c | 230 +++---
net/batman-adv/gateway_common.h | 14 +-
net/batman-adv/hard-interface.c | 9 -
net/batman-adv/main.c | 623 +++++++++++++++-
net/batman-adv/main.h | 37 +-
net/batman-adv/network-coding.c | 63 ++
net/batman-adv/network-coding.h | 5 +
net/batman-adv/originator.c | 4 +-
net/batman-adv/packet.h | 248 ++++---
net/batman-adv/routing.c | 247 ++-----
net/batman-adv/routing.h | 6 +-
net/batman-adv/send.c | 1 -
net/batman-adv/soft-interface.c | 4 +-
net/batman-adv/sysfs.c | 96 +--
net/batman-adv/translation-table.c | 905 ++++++++++++++----------
net/batman-adv/translation-table.h | 13 +-
net/batman-adv/types.h | 178 ++---
net/batman-adv/vis.c | 938 -------------------------
net/batman-adv/vis.h | 36 -
29 files changed, 1968 insertions(+), 2133 deletions(-)
delete mode 100644 net/batman-adv/vis.c
delete mode 100644 net/batman-adv/vis.h
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: Sergei Shtylyov @ 2013-10-09 20:27 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, nh-ky, netdev, ryusuke.sakato.bx
In-Reply-To: <20131009042454.GA16885@verge.net.au>
Hello.
On 09-10-2013 6:24, Simon Horman wrote:
>>> This patch will fix RX packets errors when receiving big size of data.
>>> Moreover, I set suitable parameters for get more stable when receiving
>>> packets.
>>> It was created on the top of mainline kernel v3.11.
>>> I tested this patch on Armadillo800eva, it appears to be working well.
>>> Would you please review and apply it for me.
>> Applied, but at some point someone has to add definitions for the
>> RMCR register fields so that this driver is not full of magic constants.
> Sergei, would it be possible for you to address this?
Yes, perhaps, if I won't forget.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Daniel Borkmann @ 2013-10-09 19:12 UTC (permalink / raw)
To: Tejun Heo; +Cc: pablo, netfilter-devel, netdev, cgroups
In-Reply-To: <20131009170409.GH22495@htj.dyndns.org>
On 10/09/2013 07:04 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Oct 08, 2013 at 10:05:02AM +0200, Daniel Borkmann wrote:
>> Could you elaborate on "Wouldn't it be more logical to implement netfilter
>> rule to match the target cgroup paths?". I don't think (or hope) you mean
>> some string comparison on the dentry path here? :) With our proposal, we
>> have in the network stack's critical path only the following code that is
>> being executed here to match the cgroup ...
>
> Comparing path each time obviously doesn't make sense but you can
> determine the cgroup on config and hold onto the pointer while the
> rule exists.
>
>> ... where ``info->id == skb->sk->sk_cgrp_fwid'' is the actual work, so very
>> lightweight, which is good for high loads (1Gbit/s, 10Gbit/s and beyond), of
>> course. Also, it would be intuitive for admins familiar with other subsystems
>> to just set up and use these cgroup ids in iptabels. I'm not yet quite sure
>> how your suggestion would look like, so you would need to setup some "dummy"
>> subgroups first just to have a path that you can match on?
>
> Currently, it's tricky because we have multiple hierarchies to
> consider and there isn't an efficient way to map from task to cgroup
> on a specific hierarchy. I'm not sure whether we should add another
> mapping table in css_set or just allow using path matching on the
> unified hierarchy. The latter should be cleaner and easier but more
> restrictive.
>
> Anyways, it isn't manageable in the long term to keep adding
> controllers simply to tag tasks differently. If we want to do this,
> let's please work on a way to match a task's cgroup affiliation
> efficiently.
Agreed, let us solve that first, and then I go back to the netfilter module
to bring netfilter and cgroups together.
Thanks,
Daniel
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-09
From: Antonio Quartulli @ 2013-10-09 19:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20131009.145306.1949528592789606941.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
On Wed, Oct 09, 2013 at 02:53:06PM -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Oct 2013 13:56:52 -0400 (EDT)
>
> > Pulled, thanks.
>
> Please don't send me stuff that doesn't build:
>
> net/batman-adv/translation-table.c: In function ‘batadv_send_roam_adv’:
> net/batman-adv/translation-table.c:2210:49: warning: left-hand operand of comma expression has no effect [-Wunused-value]
> net/batman-adv/translation-table.c:2211:21: warning: left-hand operand of comma expression has no effect [-Wunused-value]
> net/batman-adv/translation-table.c:2210:6: warning: statement with no effect [-Wunused-value]
> net/batman-adv/translation-table.c:2211:29: error: expected ‘;’ before ‘)’ token
> net/batman-adv/translation-table.c:2211:29: error: expected statement before ‘)’ toke
>
> That looks like:
>
> /* before going on we have to check whether the client has
> * already roamed to us too many times
> */
> if (!batadv_tt_check_roam_count(bat_priv, client))
> goto out;
>
> "Sending ROAMING_ADV to %pM (client %pM)\n",
> orig_node->orig, client);
>
> Looks like a merge problem to me.
Oh damn. Sorry David.
I have probably done something wrong during my last rebase on top net-next.
I'll fix, double check and resend the pull request.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add ndo_get_phys_port_id support
From: David Miller @ 2013-10-09 18:55 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong
In-Reply-To: <1381327588-11137-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 9 Oct 2013 16:06:28 +0200
> Each network interface (either PF or VF) is identified by its port's MAC id.
>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> Hi Dave,
>
> Please consider applying this patch to 'net-next'.
Applied, thanks Yuval.
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-09
From: David Miller @ 2013-10-09 18:53 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20131009.135652.2086284751199593695.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 09 Oct 2013 13:56:52 -0400 (EDT)
> Pulled, thanks.
Please don't send me stuff that doesn't build:
net/batman-adv/translation-table.c: In function ‘batadv_send_roam_adv’:
net/batman-adv/translation-table.c:2210:49: warning: left-hand operand of comma expression has no effect [-Wunused-value]
net/batman-adv/translation-table.c:2211:21: warning: left-hand operand of comma expression has no effect [-Wunused-value]
net/batman-adv/translation-table.c:2210:6: warning: statement with no effect [-Wunused-value]
net/batman-adv/translation-table.c:2211:29: error: expected ‘;’ before ‘)’ token
net/batman-adv/translation-table.c:2211:29: error: expected statement before ‘)’ toke
That looks like:
/* before going on we have to check whether the client has
* already roamed to us too many times
*/
if (!batadv_tt_check_roam_count(bat_priv, client))
goto out;
"Sending ROAMING_ADV to %pM (client %pM)\n",
orig_node->orig, client);
Looks like a merge problem to me.
^ permalink raw reply
* Re: IPv6 kernel warning
From: dormando @ 2013-10-09 18:48 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <CAK6E8=fZnQXNjO_dh7sALOfsa=BL7qKzzZkzQrRtX3k9ehBZPA@mail.gmail.com>
On Wed, 9 Oct 2013, Yuchung Cheng wrote:
> On Tue, Oct 8, 2013 at 1:53 PM, Yuchung Cheng <ycheng@google.com> wrote:
> >
> > On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> > > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> > >
> > >> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
> > >> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> > >> >
> > >> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
> > >> >> >
> > >> >> > > >
> > >> >> > > > there's been multiple reports about this one:
> > >> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
> > >> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
> > >> >> > > >
> > >> >> > > > Could you try Yuchung's debug patch?
> > >> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
> > >> >> > > Yes it looks like the same bug. Please try that patch to help identify
> > >> >> > > this elusive bug.
> > >> >> > >
> > >> >> >
> > >> >> > Hi!
> > >> >> >
> > >> >> > We get this one a few times a day in production. Here's a warning with
> > >> >> > your debug trace in the line immediately following:
> > >> >> > (I censored a few things)
> > >> >> >
> > >> >> > [125311.721950] ------------[ cut here ]------------
> > >> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
> > >> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
> > >> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
> > >> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
> > >> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
> > >> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
> > >> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
> > >> >> > [125311.721991] Call Trace:
> > >> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
> > >> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
> > >> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
> > >> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
> > >> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
> > >> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
> > >> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
> > >> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
> > >> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
> > >> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
> > >> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> > >> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
> > >> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> > >> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
> > >> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
> > >> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
> > >> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
> > >> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
> > >> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
> > >> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
> > >> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
> > >> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
> > >> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
> > >> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
> > >> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
> > >> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
> > >> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
> > >> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
> > >> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
> > >> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
> > >> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
> > >> >> >
> > >> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
> > >> >> > stated in the trace.
> > >> >>
> > >> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
> > >> >>
> > >> >> I suspect tcp_process_tlp_ack() should not revert state to Open
> > >> >> directly, but calling tcp_try_keep_open() instead, similar to all the
> > >> >> undo processing in the tcp_fastretrans_alert(): after
> > >> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
> > >> >> stats before moving to CA_Open.
> > >> >>
> > >> >>
> > >> >> index 9c62257..9012b42 100644
> > >> >> --- a/net/ipv4/tcp_input.c
> > >> >> +++ b/net/ipv4/tcp_input.c
> > >> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
> > >> >> tcp_init_cwnd_reduction(sk, true);
> > >> >> tcp_set_ca_state(sk, TCP_CA_CWR);
> > >> >> tcp_end_cwnd_reduction(sk);
> > >> >> - tcp_set_ca_state(sk, TCP_CA_Open);
> > >> >> + tcp_try_keep_open(sk);
> > >> >> NET_INC_STATS_BH(sock_net(sk),
> > >> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
> > >> >> }
> > >> >>
> > >> >
> > >> > Should I apply this and see if the warning stops?
> Hi Dormando,
>
> Could you try this patch to make sure it fixes the warning (with
> sysctl net.ipv4.early_retrans=3)?
It's now running on one machine, with early_retrans=3. Will have to give
it 24 hours to confirm.
> > >> I'd like to hear what the authors of TLP think. In the mean time could
> > >> you help us collect more evidence by disabling TLP with
> > >> sysctl net.ipv4.tcp_early_retrans=2
> > >> and see if the problem still occurs? (it should not).
> > >>
> > >> thanks
> > >
> > > Box hasn't had a warning in the last 24ish hours. A neighboring machine
> > > with the default tcp_early_retrans setting has had 5-6 in the same
> > > timeframe.
> > >
> > > Is this a harmful situation to the socket in any way, or is it just
> > > informational weirdness?
> > It should be fairly harmless. The ack that triggers the warning should
> > set the TCP back to the good (non-Open) state, but it's still good to
> > get rid of.
>
^ permalink raw reply
* Re: pull request: wireless 2013-10-09
From: David Miller @ 2013-10-09 18:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20131009152841.GD14381@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Oct 2013 11:28:41 -0400
> Please pull this batch of fixes intended for 3.12...
>
> Most of the bits are for iwlwifi -- Johannes says:
>
> "I have a fix for WoWLAN/D3, a PCIe device fix, we're removing a
> warning, there's a fix for RF-kill while scanning (which goes together
> with a mac80211 fix) and last but not least we have many new PCI IDs."
>
> Also for iwlwifi is a patch from Johannes to correct some merge damage
> that crept into the tree before the last merge window.
>
> On top of that, Felix Fietkau sends an ath9k patch to avoid a Tx
> scheduling hang when changing channels to do a scan.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-3-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:42 +0300
> Enable workaround for P2020/P2010 erratum eTSEC 20,
> "Excess delays when transmitting TOE=1 large frames".
> The impact is that frames lager than 2500-bytes for which
> TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled
> may see excess delay before start of transmission.
> This erratum was fixed in Rev 2.0.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-2-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:41 +0300
> Use the macros and defines from mpc85xx.h to simplify
> and prevent errors in identifying a mpc85xx based SoC
> for errata detection.
> This should help enabling (and identifying) workarounds
> for various mpc85xx based chips and revisions.
> For instance, express MPC8548 Rev.2 as:
> (SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20)
> instead of:
> (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020)
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:40 +0300
> A002 is still in "no plans to fix" state, and applies to all
> the current P1/P2 parts as well, so it's resonable to enable
> its workaround by default, for all the soc's with etsec.
> The impact of not enabling this workaround for affected parts
> is that under certain conditons (runt frames or even frames
> with RX error detected at PHY level) during controller reset,
> the controller might fail to indicate Rx reset (GRS) completion.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-09
From: David Miller @ 2013-10-09 17:56 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Wed, 9 Oct 2013 14:40:02 +0200
> Hello David,
>
> this is a set of changes intended for net-next/linux-3.13.
>
> As introduced one year ago (http://article.gmane.org/gmane.org.freifunk.batman/8484)
> in the last period we have been busy working on giving our batman-adv
> protocol/packet-format all those means to get stable and avoid incompatibilities
> in the near future (this is also why we did not send many changes for
> linux-3.12..).
>
> With this patchset we are finally switching to a new compatibility version and
> within this development cycle I will send you all those changes aimed to
> introduce all the needed mechanism to avoid any further compatibility breakage.
>
> First of all, in this batch you have the new TVLV code (Type Version Value
> Length) which is the first very important milestone towards our goal[1].
> With this mechanism we will be able to improve/change the packet contents layout
> (used by the various features) without breaking compatibility with older
> protocol versions anymore.
> The development of this new component has been started by Spyros Gasteratos
> during his Google Summer of Code 2012 and then adjusted, finished and submitted
> by Marek Lindner.
>
> Together with it, you have a set of improvements that we are allowed to apply
> thanks to the switching to the new compat version.
> These changes are:
> - adapt the existing features to make them use the new TVLV mechanism
> - move from CRC16 to CRC32c for table correctness check in the TT component
> - reorder some of the flags sent over the wire
> - remove the __packed attribute from the OGM packet struct.
>
> Moreover, with this patchset we are totally removing our VISualisation component
> that is now implemented in userspace.
>
> Please pull let me know of any problem.
Pulled, thanks.
^ permalink raw reply
* Re: pull request (net): ipsec 2013-10-09
From: David Miller @ 2013-10-09 17:44 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1381316351-14418-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 9 Oct 2013 12:59:04 +0200
> 1) We used the wrong netlink attribute to verify the
> lenght of the replay window on async events. Fix this by
> using the right netlink attribute.
>
> 2) Policy lookups can not match the output interface on forwarding.
> Add the needed informations to the flow informations.
>
> 3) We update the pmtu when we receive a ICMPV6_DEST_UNREACH message
> on IPsec with ipv6. This is wrong and leads to strange fragmented
> packets, only ICMPV6_PKT_TOOBIG messages should update the pmtu.
> Fix this by removing the ICMPV6_DEST_UNREACH check from the IPsec
> protocol error handlers.
>
> 4) The legacy IPsec anti replay mechanism supports anti replay
> windows up to 32 packets. If a user requests for a bigger
> anti replay window, we use 32 packets but pretend that we use
> the requested window size. Fix from Fan Du.
>
> 5) If asynchronous events are enabled and replay_maxdiff is set to
> zero, we generate an async event for every received packet instead
> of checking whether a timeout occurred. Fix from Thomas Egerer.
>
> 6) Policies need a refcount when the state resolution timer is armed.
> Otherwise the timer can fire after the policy is deleted.
>
> 7) We might dreference a NULL pointer if the hold_queue is empty,
> add a check to avoid this.
>
> Please pull or let me know if there are problems.
Pulled, thanks a lot Steffen.
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-09 17:33 UTC (permalink / raw)
To: dormando
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <CAK6E8=d5VWMoOpDhZR4WaU6V6NJ9YSvJr=mm=rYNir0z644H=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6631 bytes --]
On Tue, Oct 8, 2013 at 1:53 PM, Yuchung Cheng <ycheng@google.com> wrote:
>
> On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> >
> >> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
> >> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> >> >
> >> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
> >> >> >
> >> >> > > >
> >> >> > > > there's been multiple reports about this one:
> >> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
> >> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
> >> >> > > >
> >> >> > > > Could you try Yuchung's debug patch?
> >> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
> >> >> > > Yes it looks like the same bug. Please try that patch to help identify
> >> >> > > this elusive bug.
> >> >> > >
> >> >> >
> >> >> > Hi!
> >> >> >
> >> >> > We get this one a few times a day in production. Here's a warning with
> >> >> > your debug trace in the line immediately following:
> >> >> > (I censored a few things)
> >> >> >
> >> >> > [125311.721950] ------------[ cut here ]------------
> >> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
> >> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
> >> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
> >> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
> >> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
> >> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
> >> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
> >> >> > [125311.721991] Call Trace:
> >> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
> >> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
> >> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
> >> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
> >> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
> >> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
> >> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
> >> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
> >> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
> >> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
> >> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
> >> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
> >> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
> >> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
> >> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
> >> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
> >> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
> >> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
> >> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
> >> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
> >> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
> >> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
> >> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
> >> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
> >> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
> >> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
> >> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
> >> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
> >> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
> >> >> >
> >> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
> >> >> > stated in the trace.
> >> >>
> >> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
> >> >>
> >> >> I suspect tcp_process_tlp_ack() should not revert state to Open
> >> >> directly, but calling tcp_try_keep_open() instead, similar to all the
> >> >> undo processing in the tcp_fastretrans_alert(): after
> >> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
> >> >> stats before moving to CA_Open.
> >> >>
> >> >>
> >> >> index 9c62257..9012b42 100644
> >> >> --- a/net/ipv4/tcp_input.c
> >> >> +++ b/net/ipv4/tcp_input.c
> >> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
> >> >> tcp_init_cwnd_reduction(sk, true);
> >> >> tcp_set_ca_state(sk, TCP_CA_CWR);
> >> >> tcp_end_cwnd_reduction(sk);
> >> >> - tcp_set_ca_state(sk, TCP_CA_Open);
> >> >> + tcp_try_keep_open(sk);
> >> >> NET_INC_STATS_BH(sock_net(sk),
> >> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
> >> >> }
> >> >>
> >> >
> >> > Should I apply this and see if the warning stops?
Hi Dormando,
Could you try this patch to make sure it fixes the warning (with
sysctl net.ipv4.early_retrans=3)?
> >> I'd like to hear what the authors of TLP think. In the mean time could
> >> you help us collect more evidence by disabling TLP with
> >> sysctl net.ipv4.tcp_early_retrans=2
> >> and see if the problem still occurs? (it should not).
> >>
> >> thanks
> >
> > Box hasn't had a warning in the last 24ish hours. A neighboring machine
> > with the default tcp_early_retrans setting has had 5-6 in the same
> > timeframe.
> >
> > Is this a harmful situation to the socket in any way, or is it just
> > informational weirdness?
> It should be fairly harmless. The ack that triggers the warning should
> set the TCP back to the good (non-Open) state, but it's still good to
> get rid of.
[-- Attachment #2: 0001-tcp-fix-incorrect-ca_state-in-tail-loss-probe.patch --]
[-- Type: application/octet-stream, Size: 1356 bytes --]
From 6aacfe24692341ac93c1d153a801c34066b86262 Mon Sep 17 00:00:00 2001
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 9 Oct 2013 10:08:52 -0700
Subject: [PATCH] tcp: fix incorrect ca_state in tail loss probe
On receiving an ACK that covers the loss probe sequence, TLP
immediately sets the congestion state to Open, even though some packets
are not recovered and retransmisssion are on the way. The later ACks
may trigger a WARN_ON check of step D in tcp_fastretrans_alert().
The fix is to follow the similar procedure in recovery by calling
tcp_try_keep_open(). The sender switches to Open state if no packets
are retransmissted. Otherwise it goes to Disorder and let subsequent
ACKs move the state to Recovery or Open.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 113dc5f..53974c7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3291,7 +3291,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack, int flag)
tcp_init_cwnd_reduction(sk, true);
tcp_set_ca_state(sk, TCP_CA_CWR);
tcp_end_cwnd_reduction(sk);
- tcp_set_ca_state(sk, TCP_CA_Open);
+ tcp_try_keep_open(sk);
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_TCPLOSSPROBERECOVERY);
}
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
Use the macros and defines from mpc85xx.h to simplify
and prevent errors in identifying a mpc85xx based SoC
for errata detection.
This should help enabling (and identifying) workarounds
for various mpc85xx based chips and revisions.
For instance, express MPC8548 Rev.2 as:
(SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20)
instead of:
(pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020)
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 33 ++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index db5fc7b..329a206 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -88,6 +88,7 @@
#include <asm/io.h>
#include <asm/reg.h>
+#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
#include <linux/module.h>
@@ -939,17 +940,13 @@ static void gfar_init_filer_table(struct gfar_private *priv)
}
}
-static void gfar_detect_errata(struct gfar_private *priv)
+static void __gfar_detect_errata_83xx(struct gfar_private *priv)
{
- struct device *dev = &priv->ofdev->dev;
unsigned int pvr = mfspr(SPRN_PVR);
unsigned int svr = mfspr(SPRN_SVR);
unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
unsigned int rev = svr & 0xffff;
- /* no plans to fix */
- priv->errata |= GFAR_ERRATA_A002;
-
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
@@ -960,10 +957,30 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
- /* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
- if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020) ||
- (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
+ /* MPC8313 Rev < 2.0 */
+ if (pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020)
+ priv->errata |= GFAR_ERRATA_12;
+}
+
+static void __gfar_detect_errata_85xx(struct gfar_private *priv)
+{
+ unsigned int svr = mfspr(SPRN_SVR);
+
+ if ((SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20))
priv->errata |= GFAR_ERRATA_12;
+}
+
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = &priv->ofdev->dev;
+
+ /* no plans to fix */
+ priv->errata |= GFAR_ERRATA_A002;
+
+ if (pvr_version_is(PVR_VER_E500V1) || pvr_version_is(PVR_VER_E500V2))
+ __gfar_detect_errata_85xx(priv);
+ else /* non-mpc85xx parts, i.e. e300 core based */
+ __gfar_detect_errata_83xx(priv);
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
A002 is still in "no plans to fix" state, and applies to all
the current P1/P2 parts as well, so it's resonable to enable
its workaround by default, for all the soc's with etsec.
The impact of not enabling this workaround for affected parts
is that under certain conditons (runt frames or even frames
with RX error detected at PHY level) during controller reset,
the controller might fail to indicate Rx reset (GRS) completion.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index c4eaade..db5fc7b 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -947,6 +947,9 @@ static void gfar_detect_errata(struct gfar_private *priv)
unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
unsigned int rev = svr & 0xffff;
+ /* no plans to fix */
+ priv->errata |= GFAR_ERRATA_A002;
+
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
@@ -957,11 +960,6 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
- /* MPC8313 and MPC837x all rev */
- if ((pvr == 0x80850010 && mod == 0x80b0) ||
- (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
- priv->errata |= GFAR_ERRATA_A002;
-
/* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020) ||
(pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
@@ -1599,7 +1597,7 @@ static int __gfar_is_rx_idle(struct gfar_private *priv)
/* Normaly TSEC should not hang on GRS commands, so we should
* actually wait for IEVENT_GRSC flag.
*/
- if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002)))
+ if (!gfar_has_errata(priv, GFAR_ERRATA_A002))
return 0;
/* Read the eTSEC register at offset 0xD1C. If bits 7-14 are
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: fix build errors if ipv6 is disabled
From: David Miller @ 2013-10-09 17:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381313148.4971.13.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Oct 2013 03:05:48 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> CONFIG_IPV6=n is still a valid choice ;)
>
> It appears we can remove dead code.
>
> Reported-by: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: add the missing right parenthesis in ping_bind()
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] veth: allow to setup multicast address for veth device
From: David Miller @ 2013-10-09 17:22 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, pablo, edumazet, kaber, hannes
In-Reply-To: <52551ABD.40603@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Wed, 09 Oct 2013 16:58:37 +0800
> Hi David,
>
> On 10/04/2013 04:52 PM, Gao feng wrote:
>> We can only setup multicast address for network device when
>> net_device_ops->ndo_set_rx_mode is not null.
>>
>> Some configurations need to add multicast address for net
>> device, such as netfilter cluster match module.
>>
>> Add a fake ndo_set_rx_mode function to allow this operation.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>
> I see this patch being marked as "Changes Requested" on patchwork.
> Is there something I missed?
It was a mistake, I put it back in Under Review.
^ permalink raw reply
* [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
Enable workaround for P2020/P2010 erratum eTSEC 20,
"Excess delays when transmitting TOE=1 large frames".
The impact is that frames lager than 2500-bytes for which
TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled
may see excess delay before start of transmission.
This erratum was fixed in Rev 2.0.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 329a206..9fbe4dd 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -968,6 +968,9 @@ static void __gfar_detect_errata_85xx(struct gfar_private *priv)
if ((SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20))
priv->errata |= GFAR_ERRATA_12;
+ if (((SVR_SOC_VER(svr) == SVR_P2020) && (SVR_REV(svr) < 0x20)) ||
+ ((SVR_SOC_VER(svr) == SVR_P2010) && (SVR_REV(svr) < 0x20)))
+ priv->errata |= GFAR_ERRATA_76; /* aka eTSEC 20 */
}
static void gfar_detect_errata(struct gfar_private *priv)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] tun: don't look at current when non-blocking
From: David Miller @ 2013-10-09 17:14 UTC (permalink / raw)
To: mst; +Cc: jasowang, netdev, linux-kernel, edumazet, xemul
In-Reply-To: <20131009081354.GA30882@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 9 Oct 2013 11:13:54 +0300
> On Wed, Oct 09, 2013 at 02:25:19PM +0800, Jason Wang wrote:
>> On 10/09/2013 03:46 AM, David Miller wrote:
>> > From: "Michael S. Tsirkin" <mst@redhat.com>
>> > Date: Sun, 6 Oct 2013 21:25:12 +0300
>> >
>> >> We play with a wait queue even if socket is
>> >> non blocking. This is an obvious waste.
>> >> Besides, it will prevent calling the non blocking
>> >> variant when current is not valid.
>> >>
>> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> > Applied and queued up for -stable, thanks.
>> > --
>>
>> Michael, I believe this is just an optimization or a required patch of
>> your following patches. So no need go for stable?
>
> I don't think it's required for stable.
Ok, removed from the -stable queue. Thanks.
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 17:05 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7386@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]
On Wed, Oct 09, 2013 at 05:19:44PM +0100, David Laight wrote:
> > On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > > > and the XORing the CRC together?
> > > > > That gives the same answer as XORing together the MAC addresses and
> > > > > then doing a CRC of the final value.
> > > >
> > > > I was not sure about this since the CRC32 is not a linear operation. However
> > > > this routine is not on the fast path, so we can also live with this order.
> > >
> > > All CRC are linear.
> > > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> > >
> > > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > > The CRC for each bit depends on how far it is from the end of the buffer.
> >
> > In our tables we cannot make any assumption about the order of the entries: the
> > node whom generated the table may store the entries in a different order from
> > what we have got.
> > This is why I did not implemented it as a simple CRC of the
> > whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> >
> ...
> >
> > Assuming what I said above (that we cannot make assumptions on the order of the
> > entries), what is your suggestion?
>
> I'm not sure what you are using this CRC for.
> If you are trying to use it to check that the two tables match - so a
> full update isn't needed then it just won't work.
No, we have a sequence number for this purpose.
The CRC is only used to check that (after having applied all the needed changes)
the content of the table is really the same as the one owned by whom generated
it.
Therefore the CRC is practically used only to check that the node memory has not
been corrupted and I can hardly imagine that such a case can lead to the same
CRC as the expected one (of course, probability is not zero, but that's because
it is an hash function..).
The conclusion is that we can live with this patch :-)
Thank you anyway for your explanation. This will surely help in case we decide
to change/improve it.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Tejun Heo @ 2013-10-09 17:04 UTC (permalink / raw)
To: Daniel Borkmann
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5253BCAE.5060409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello,
On Tue, Oct 08, 2013 at 10:05:02AM +0200, Daniel Borkmann wrote:
> Could you elaborate on "Wouldn't it be more logical to implement netfilter
> rule to match the target cgroup paths?". I don't think (or hope) you mean
> some string comparison on the dentry path here? :) With our proposal, we
> have in the network stack's critical path only the following code that is
> being executed here to match the cgroup ...
Comparing path each time obviously doesn't make sense but you can
determine the cgroup on config and hold onto the pointer while the
rule exists.
> ... where ``info->id == skb->sk->sk_cgrp_fwid'' is the actual work, so very
> lightweight, which is good for high loads (1Gbit/s, 10Gbit/s and beyond), of
> course. Also, it would be intuitive for admins familiar with other subsystems
> to just set up and use these cgroup ids in iptabels. I'm not yet quite sure
> how your suggestion would look like, so you would need to setup some "dummy"
> subgroups first just to have a path that you can match on?
Currently, it's tricky because we have multiple hierarchies to
consider and there isn't an efficient way to map from task to cgroup
on a specific hierarchy. I'm not sure whether we should add another
mapping table in css_set or just allow using path matching on the
unified hierarchy. The latter should be cleaner and easier but more
restrictive.
Anyways, it isn't manageable in the long term to keep adding
controllers simply to tag tasks differently. If we want to do this,
let's please work on a way to match a task's cgroup affiliation
efficiently.
Thanks.
--
tejun
^ permalink raw reply
* RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: David Laight @ 2013-10-09 16:19 UTC (permalink / raw)
To: Antonio Quartulli
Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009161028.GI3544@neomailbox.net>
> On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > > and the XORing the CRC together?
> > > > That gives the same answer as XORing together the MAC addresses and
> > > > then doing a CRC of the final value.
> > >
> > > I was not sure about this since the CRC32 is not a linear operation. However
> > > this routine is not on the fast path, so we can also live with this order.
> >
> > All CRC are linear.
> > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> >
> > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > The CRC for each bit depends on how far it is from the end of the buffer.
>
> In our tables we cannot make any assumption about the order of the entries: the
> node whom generated the table may store the entries in a different order from
> what we have got.
> This is why I did not implemented it as a simple CRC of the
> whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
>
...
>
> Assuming what I said above (that we cannot make assumptions on the order of the
> entries), what is your suggestion?
I'm not sure what you are using this CRC for.
If you are trying to use it to check that the two tables match - so a
full update isn't needed then it just won't work.
If you take out 11:22:33:44:55:60 and 11:22:33:44:55:61 and
change 99:88:77:66:55:40 to 99:88:77:66:55:41 then the XOR of
the CRCs won't change.
For MAC addresses such changes aren't that unlikely.
David
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 16:15 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009161028.GI3544@neomailbox.net>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Wed, Oct 09, 2013 at 06:10:28PM +0200, Antonio Quartulli wrote:
> On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > All CRC are linear.
> > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> >
> > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > The CRC for each bit depends on how far it is from the end of the buffer.
>
> In our tables we cannot make any assumption about the order of the entries: the
> node whom generated the table may store the entries in a different order from
> what we have got.
> This is why I did not implemented it as a simple CRC of the
> whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
>
>
> > Presetting the CRC to all-ones generates a value that is dependent on
> > the length of the buffer - otherwise missing/extra leading zeros are
> > not detected.
>
>
> Assuming what I said above (that we cannot make assumptions on the order of the
> entries), what is your suggestion?
Given that CRCs are commutative, the easiest answer to this question is probably to
perform the XOR of all the entries and than computing the CRC32 once
(and when computing the CRC I should start with 0xFFFFFFFF other than 0),
right?
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 16:10 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7385@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > and the XORing the CRC together?
> > > That gives the same answer as XORing together the MAC addresses and
> > > then doing a CRC of the final value.
> >
> > I was not sure about this since the CRC32 is not a linear operation. However
> > this routine is not on the fast path, so we can also live with this order.
>
> All CRC are linear.
> Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
>
> The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> The CRC for each bit depends on how far it is from the end of the buffer.
In our tables we cannot make any assumption about the order of the entries: the
node whom generated the table may store the entries in a different order from
what we have got.
This is why I did not implemented it as a simple CRC of the
whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> Presetting the CRC to all-ones generates a value that is dependent on
> the length of the buffer - otherwise missing/extra leading zeros are
> not detected.
Assuming what I said above (that we cannot make assumptions on the order of the
entries), what is your suggestion?
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox