* RE: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: Jon Maloy @ 2014-08-25 22:45 UTC (permalink / raw)
To: David Miller, cwang@twopensource.com
Cc: netdev@vger.kernel.org, therbert@google.com, jhs@mojatatu.com,
hannes@stressinduktion.org, edumazet@google.com,
jeffrey.t.kirsher@intel.com, rusty@rustcorp.com.au
In-Reply-To: <20140825.153146.2165451041039058085.davem@davemloft.net>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of David Miller
> Sent: August-25-14 6:32 PM
> To: cwang@twopensource.com
> Cc: netdev@vger.kernel.org; therbert@google.com; jhs@mojatatu.com;
> hannes@stressinduktion.org; edumazet@google.com;
> jeffrey.t.kirsher@intel.com; rusty@rustcorp.com.au
> Subject: Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
>
> From: Cong Wang <cwang@twopensource.com>
> Date: Mon, 25 Aug 2014 15:21:00 -0700
>
> > When I tried to unify the list management of SKB's, I was surprised to
> > see there are still some places relying on skb->next and skb->prev to
> > be the head of the skb struct, since nowadays we have list API's, they
> > still play some magic on these pointers (sctp and tipc IIRC). This is
I am not aware of any such assumptions in TIPC. For me you can go ahead
with this.
Regards
///jon
> > why I gave up, maybe it's time to revise this again.
>
> I think SCTP should be OK, and yes I do remember that protocol being one of
> the last subsystems making such SKB list pointer assumptions.
>
> It was using list_*() operations on sk_buff objects or something like that.
>
> > Talking about skb->next, fortunately we do gso segmentation after
> > going out of qdisc queues, otherwise it's scary to play with these
> > pointers at same time. I think all queues of SKB's are either using
> > just ->next or both ->prev and ->next.
>
> It occurs to me that perhaps the thing to do is to pass sk_buff ** to
> dev_hard_start_xmit().
>
> If it really is important to free the original GSO skb after the segmented parts,
> we can run that as part of the destructor of the final segment.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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 net-next V1 0/3] Make is_kdump_kernel() accessible from modules
From: David Miller @ 2014-08-25 22:42 UTC (permalink / raw)
To: amirv; +Cc: andi, netdev, akpm, vgoyal, ogerlitz, yevgenyp
In-Reply-To: <1408972014-13319-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 25 Aug 2014 16:06:51 +0300
> I'm re-spinning this patchset. At the begining it was suggested to use a
> different name for the parameter, but at the end [3] the resolution was to
> leave it as it is in this patch.
>
> Drivers need to know if running from kdump kernel in order to change their
> memory profile - since kdump environment is limited by available memory.
> Currently there are drivers that are using reset_devices as suggested in [2].
> In [2] it was suggested to use reset_devices, but the context was, to enable
> driver to know when the hardware device is needed to be reset, and not if this
> is a kdump environment. We think that is_kdump_kernel() is better suited to
> select between different memory profiles.
>
> The first patch in this patchset exports a needed symbol in order to make
> is_kdump_kernel() accessible from the drivers. The rest of the patches change
> from reset_devices to is_kdump_kernel() in 2 networking drivers.
>
> The idea of this patchset was suggested by Vivek Goyal.
>
> Tested (only build) and applied on top of commit 8fc54f6: ("net: use
> reciprocal_scale() helper")
>
> [1] - ea1c1af: ("net/mlx4_en: Reduce memory consumption on kdump kernel")
> [2] - https://lkml.org/lkml/2011/1/27/341
> [3] - http://www.spinics.net/lists/netdev/msg291492.html
Series applied, thanks Amir.
^ permalink raw reply
* Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: David Miller @ 2014-08-25 22:41 UTC (permalink / raw)
To: eric.dumazet
Cc: cwang, netdev, therbert, jhs, hannes, edumazet, jeffrey.t.kirsher,
rusty
In-Reply-To: <1409006274.3173.0.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 25 Aug 2014 15:37:54 -0700
> On Mon, 2014-08-25 at 15:31 -0700, David Miller wrote:
>
>> It occurs to me that perhaps the thing to do is to pass sk_buff ** to
>> dev_hard_start_xmit().
>
> This was my suggestion ;)
>
> int ret = dev_hard_start_xmit(skb, dev, txq);
>
> ->
>
> int ret = dev_hard_start_xmit(&skb, dev, txq);
Ok and this can solve the GSO freeing issue too, if the caller was working
with a segmented SKB, he can pass &skb->next to dev_hard_start_xmit() then
if skb->next is NULL after dev_hard_start_xmit() returns we can free up
the head GSO skb.
^ permalink raw reply
* Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: Eric Dumazet @ 2014-08-25 22:37 UTC (permalink / raw)
To: David Miller
Cc: cwang, netdev, therbert, jhs, hannes, edumazet, jeffrey.t.kirsher,
rusty
In-Reply-To: <20140825.153146.2165451041039058085.davem@davemloft.net>
On Mon, 2014-08-25 at 15:31 -0700, David Miller wrote:
> It occurs to me that perhaps the thing to do is to pass sk_buff ** to
> dev_hard_start_xmit().
This was my suggestion ;)
int ret = dev_hard_start_xmit(skb, dev, txq);
->
int ret = dev_hard_start_xmit(&skb, dev, txq);
^ permalink raw reply
* Re: [PATCH (net.git) 2/2] stmmac: set ptp_clock to NULL while unregister
From: David Miller @ 2014-08-25 22:33 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1408971379-14871-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Mon, 25 Aug 2014 14:56:19 +0200
> This is to properly put to NULL the ptp_clock while un-register the PTP support.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 1/2] stmmac: fix rx checksum programming
From: David Miller @ 2014-08-25 22:33 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1408971379-14871-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Mon, 25 Aug 2014 14:56:18 +0200
> This patch is to fix the IPC bit into the GMAC control register
> that must be done after the core initialization otherwise it will
> not have any effect.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH net-next 1/3] ixgbe: support netdev_ops->ndo_xmit_flush()
From: David Miller @ 2014-08-25 22:32 UTC (permalink / raw)
To: brouer; +Cc: dborkman, netdev
In-Reply-To: <20140825140721.162a6c91@redhat.com>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 25 Aug 2014 14:07:21 +0200
> I've run some benchmarks with this patch only, which actually shows a
> performance regression.
>
> Using trafgen with QDISC_BYPASS and mmap mode, via cmdline:
> trafgen --cpp --dev eth5 --conf udp_example01.trafgen -V --cpus 1
>
> BASELINE(no-patch): trafgen QDISC_BYPASS and mmap:
> - tx:1562539 pps
>
> (This patch only): ixgbe use of .ndo_xmit_flush.
> - tx:1532299 pps
>
> Regression: -30240 pps
> * In nanosec: (1/1562539*10^9)-(1/1532299*10^9) = -12.63 ns
>
>
> As DaveM points out, me might not need the mmiowb().
> Result when not performing the mmiowb():
> - tx:1548352 pps
>
> Still a small regression: -14187 pps
> * In nanosec: (1/1562539*10^9)-(1/1548352*10^9) = -5.86 ns
>
> I was not expecting this "slowdown", with this rather simple use of the
> new ndo_xmit_flush API. Can anyone explain why this is happening?
Impressive amount of overhead for something that evaluates to just a
compiler barrier :-)
The extra indirect function call and walking down the data structures
to get to the queue pointer might account for the remaining cost.
This might be argument enough to contain the behavioral changes within
->ndo_start_xmit() itself.
Jesper, just for fun, could you revert all of the xmit flush stuff and
test this patch instead?
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 87bd53f..ba9ceaa 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6958,9 +6958,10 @@ static void ixgbe_tx_map(struct ixgbe_ring *tx_ring,
tx_ring->next_to_use = i;
- /* notify HW of packet */
- ixgbe_write_tail(tx_ring, i);
-
+ if (!skb->xmit_more) {
+ /* notify HW of packet */
+ ixgbe_write_tail(tx_ring, i);
+ }
return;
dma_error:
dev_err(tx_ring->dev, "TX DMA map failed\n");
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 18ddf96..dc6141da 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -558,6 +558,7 @@ struct sk_buff {
__u16 queue_mapping;
kmemcheck_bitfield_begin(flags2);
+ __u8 xmit_more:1;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: Header length compution function
From: David Miller @ 2014-08-25 22:32 UTC (permalink / raw)
To: alexander.h.duyck
Cc: eric.dumazet, amirv, netdev, ogerlitz, yevgenyp, idos, therbert
In-Reply-To: <53FBB702.8080905@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 25 Aug 2014 15:21:54 -0700
> On 08/23/2014 12:19 PM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> Date: Thu, 31 Jul 2014 08:34:22 -0700
>>
>>> On 07/30/2014 06:39 PM, David Miller wrote:
>>>> I don't think my proposed patch is a bad trade off. Where we have the
>>>> __skb_header_pointer() thing that takes preloaded pointers and header
>>>> length values. It adds only one test which frankly should never
>>>> trigger and can be moved down into skb_copy_bits() or similar.
>>>
>>> This works for me. Once it is in I can see about pushing a patch to add
>>> some FCoE support and work on moving over igb and ixgbe.
>>
>> You should be able to do this against net-next now, just FYI.
>>
>
> Actually I was just looking at the code. It looks like commit
> 19469a873bafd4e65daef3597db2bd724c1b03c9 "flow_dissector: Use IPv6 flow
> label in flow_dissector" is likely breaking things in terms of trying to
> use this function to get the header length since the code now returns
> early if an IPv6 flow label is present.
Feel free to insert a facility to disable that logic.
^ permalink raw reply
* Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: David Miller @ 2014-08-25 22:31 UTC (permalink / raw)
To: cwang; +Cc: netdev, therbert, jhs, hannes, edumazet, jeffrey.t.kirsher, rusty
In-Reply-To: <CAHA+R7O_RSyKVNqcHXePbahvU+ayf77w61jos=G38M93okVWKw@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 25 Aug 2014 15:21:00 -0700
> When I tried to unify the list management of SKB's, I was surprised to see
> there are still some places relying on skb->next and skb->prev to be
> the head of the skb struct, since nowadays we have list API's, they still
> play some magic on these pointers (sctp and tipc IIRC). This is why I
> gave up, maybe it's time to revise this again.
I think SCTP should be OK, and yes I do remember that protocol being one of
the last subsystems making such SKB list pointer assumptions.
It was using list_*() operations on sk_buff objects or something like that.
> Talking about skb->next, fortunately we do gso segmentation after
> going out of qdisc queues, otherwise it's scary to play with these
> pointers at same time. I think all queues of SKB's are either using
> just ->next or both ->prev and ->next.
It occurs to me that perhaps the thing to do is to pass sk_buff ** to
dev_hard_start_xmit().
If it really is important to free the original GSO skb after the
segmented parts, we can run that as part of the destructor of the
final segment.
^ permalink raw reply
* [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280
From: Hagen Paul Pfeifer @ 2014-08-25 22:25 UTC (permalink / raw)
To: netdev; +Cc: Hagen Paul Pfeifer, Fernando Gont
In-Reply-To: <53F39E50.1020209@gont.com.ar>
Reduce the attack vector and stop generating ICMPv6 packet to big for
packets smaller then the minimal required IPv6 MTU.
See
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/ipv6/route.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f74b041..84ebacd 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1154,12 +1154,9 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
struct net *net = dev_net(dst->dev);
rt6->rt6i_flags |= RTF_MODIFIED;
- if (mtu < IPV6_MIN_MTU) {
- u32 features = dst_metric(dst, RTAX_FEATURES);
+ if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
- features |= RTAX_FEATURE_ALLFRAG;
- dst_metric_set(dst, RTAX_FEATURES, features);
- }
+
dst_metric_set(dst, RTAX_MTU, mtu);
rt6_update_expires(rt6, net->ipv6.sysctl.ip6_rt_mtu_expires);
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: Header length compution function
From: Alexander Duyck @ 2014-08-25 22:21 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, amirv, netdev, ogerlitz, yevgenyp, idos,
Tom Herbert
In-Reply-To: <20140823.121959.890509134482478336.davem@davemloft.net>
On 08/23/2014 12:19 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Thu, 31 Jul 2014 08:34:22 -0700
>
>> On 07/30/2014 06:39 PM, David Miller wrote:
>>> I don't think my proposed patch is a bad trade off. Where we have the
>>> __skb_header_pointer() thing that takes preloaded pointers and header
>>> length values. It adds only one test which frankly should never
>>> trigger and can be moved down into skb_copy_bits() or similar.
>>
>> This works for me. Once it is in I can see about pushing a patch to add
>> some FCoE support and work on moving over igb and ixgbe.
>
> You should be able to do this against net-next now, just FYI.
>
Actually I was just looking at the code. It looks like commit
19469a873bafd4e65daef3597db2bd724c1b03c9 "flow_dissector: Use IPv6 flow
label in flow_dissector" is likely breaking things in terms of trying to
use this function to get the header length since the code now returns
early if an IPv6 flow label is present.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: Cong Wang @ 2014-08-25 22:21 UTC (permalink / raw)
To: David Miller
Cc: netdev, Tom Herbert, Jamal Hadi Salim, Hannes Frederic Sowa,
Eric Dumazet, jeffrey.t.kirsher, rusty
In-Reply-To: <20140823.213839.1953243016141233125.davem@davemloft.net>
On Sat, Aug 23, 2014 at 9:38 PM, David Miller <davem@davemloft.net> wrote:
>
> So today I was looking more into this aspect.
>
> Like Tom Herbert has mentioned we have all the infrastructure (sort
> of) already to handle a list of SKBs going down into
> dev_hard_start_xmit() via the GSO handling.
>
> But that code is funny, because it keeps the original GSO head SKB
> around as a placeholder to maintain the list of segmented SKBs.
>
> So the list walker basically walks starting at skb->next. That's
> awkward for what we want to do, which is pass in an arbitrary list of
> SKBs.
>
> All it really wants that head SKB for is essentially list management,
> which seems like overkill to me.
>
> Anyways, this got me thinking that we should have something that
> provides the segment list management and stop keeping that head GSO
> SKB around.
>
> Then we can make that "gso:" label list walker generic enough that we
> could pass down arbitrary lists of SKBs from the qdisc_restart() path.
>
> This list management seems to be the only reason why we keep the GSO
> head SKB around after dev_gso_segment(), we should be able to free it
> up early without any problems right?
>
> I'm also thinking about whether we should hang the generic SKB list
> management off of the txq or the qdisc. Right now the gso_skb thing
> is in the qdisc.
>
> Thoughts?
When I tried to unify the list management of SKB's, I was surprised to see
there are still some places relying on skb->next and skb->prev to be
the head of the skb struct, since nowadays we have list API's, they still
play some magic on these pointers (sctp and tipc IIRC). This is why I
gave up, maybe it's time to revise this again.
Talking about skb->next, fortunately we do gso segmentation after
going out of qdisc queues, otherwise it's scary to play with these
pointers at same time. I think all queues of SKB's are either using
just ->next or both ->prev and ->next.
Just my two cents.
^ permalink raw reply
* Re: [PATCH] net: prevent of emerging cross-namespace symlinks
From: David Miller @ 2014-08-25 22:18 UTC (permalink / raw)
To: git.user; +Cc: netdev, vfalico
In-Reply-To: <1408969605-5800-1-git-send-email-git.user@gmail.com>
From: "Alexander Y. Fomichev" <git.user@gmail.com>
Date: Mon, 25 Aug 2014 16:26:45 +0400
> Code manipulating sysfs symlinks on adjacent net_devices(s)
> currently doesn't take into account that devices potentially
> belong to different namespaces.
>
> This patch trying to fix an issue as follows:
> - check for net_ns before creating / deleting symlink.
> for now only netdev_adjacent_rename_links and
> __netdev_adjacent_dev_remove are affected, afaics
> __netdev_adjacent_dev_insert implies both net_devs
> belong to the same namespace.
> - Drop all existing symlinks to / from all adj_devs before
> switching namespace and recreate them just after.
>
> Signed-off-by: Alexander Y. Fomichev <git.user@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH for -next] stmmac: simple cleanups
From: David Miller @ 2014-08-25 22:13 UTC (permalink / raw)
To: pavel; +Cc: peppe.cavallaro, netdev, linux-kernel
In-Reply-To: <20140825113116.GA21632@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Mon, 25 Aug 2014 13:31:16 +0200
> This adds simple cleanups for stmmac, removing test we know is always
> true, fixing whitespace, and moving code out of if().
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
From: Thomas Graf @ 2014-08-25 22:11 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Scott Feldman, John Fastabend, Jiri Pirko, netdev, davem, nhorman,
andy, dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye
In-Reply-To: <53FB68EB.9060308@mojatatu.com>
First of all, thanks for the animated discussion, wouldn't
want to miss our arguments ;-)
On 08/25/14 at 12:48pm, Jamal Hadi Salim wrote:
> On 08/25/14 10:54, Thomas Graf wrote:
> >On 08/24/14 at 11:15am, Jamal Hadi Salim wrote:
>
> >Let's keep vendors out of this discussion.
>
> The API is from a vendor. It is clearly labelled as an OF API.
> It covers well abstracting that vendors SDK to enable OF. That
> is relevant info.
> If it covers all other vendors (which is where
> the quark handling comes in), I will be fine with it.
> I dont believe it does.
If I understand you correctly you are referring to the rocker
patch here. That is not part of the API.
> >That is simply not the case. The fact that John is using this model
> >to replace the flow director ioctl API should prove this.
>
> depends what NIC classifier John is mapping to. The Intels have
> about 4-5 different types of classifier on different hardware
Sorry for not addressing this but I think John should speak for
himself here, I don't want to misrepresent his plans.
> I gave a simple example.
> There are a hell more quarks than that.
> There are cases where there are multiple tables in terms of net masks
> etc.
> Yes, this should be handled in the driver. The input is the route
> message we already specify and not some XXX_Flow_XXx struct.
I would argue that swflow is a superset of a Netlink route. It
may infact be very useful to extend the API with something that
understands the Netlink representation of a route and have the
API translate that to a classifier that can be offloaded.
> I would be tagging along with you guys for flows if you:
> a) allow for different classifiers. This allows me to implement
> u32 and offload it.
Agreed. What you seem to disagree on is:
- ndo_add_type1([...])
- ndo_add_type2([...])
- ndo_add_type3([...])
vs.
- ndo_add_classifier(type, [...])
I honestly have little against the 2nd. It sounds a bit like an
ioctl interface though where a giant switch statement will cast
the data to a classifier specific struct which is why I slightly
dislike it.
It looks to me that a specific chip may either work in a flow/filter
mode, in a generic programmable mode or by providing a list of very
specific filters without a generic flow -> action relation. Having
multiple classifier types for all of them gives the impression that
an API user could use them in any combination which I would say will
typically not be the case.
> b) different actions (I think this part is not controversial, you
> seem to be having it already).
Agreed
^ permalink raw reply
* Re: [PATCH v5 net-next 06/29] bpf: add lookup/update/delete/iterate methods to BPF maps
From: Alexei Starovoitov @ 2014-08-25 22:07 UTC (permalink / raw)
To: Cong Wang
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Daniel Borkmann, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, Brendan Gregg, Namhyung Kim, H. Peter Anvin,
Andrew Morton, Kees Cook, Linux API, netdev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAHA+R7MTJcsDpw=5P7hOsVf_pEOEZX_=cLrcw4ep4xntUxk=3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 25, 2014 at 2:33 PM, Cong Wang <cwang-xCSkyg8dI+0RB7SZvlqPiA@public.gmane.org> wrote:
> On Sun, Aug 24, 2014 at 1:21 PM, Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
>> 'maps' is a generic storage of different types for sharing data between kernel
>> and userspace.
>>
>> The maps are accessed from user space via BPF syscall, which has commands:
>>
>> - create a map with given type and attributes
>> fd = bpf_map_create(map_type, struct nlattr *attr, int len)
>> returns fd or negative error
>>
>> - lookup key in a given map referenced by fd
>> err = bpf_map_lookup_elem(int fd, void *key, void *value)
>> returns zero and stores found elem into value or negative error
>>
>> - create or update key/value pair in a given map
>> err = bpf_map_update_elem(int fd, void *key, void *value)
>> returns zero or negative error
>>
>> - find and delete element by key in a given map
>> err = bpf_map_delete_elem(int fd, void *key)
>>
>> - iterate map elements (based on input key return next_key)
>> err = bpf_map_get_next_key(int fd, void *key, void *next_key)
>
>
> I think you need to document the bpf() syscall instead of wrappers on it,
> from a developer's point of view. You will anyway need to document a new
> syscall with a man page as a general rule.
yep. I've mentioned before that man page is on todo list. I'm delaying
writing it, because it's the most difficult part and I don't want to keep
rewriting it when interface changes (like it did from global id to fd).
Once implementation lands, manpage will be the highest priority.
> In the changelog I mean something like:
>
> err = bpf(BPF_MAP_LOOKUP_ELEM, ...);
Are you saying instead of:
err = bpf_map_lookup_elem(int fd, void *key, void *value)
write
err = bpf(BPF_MAP_LOOKUP_ELEM, fd, key, value)
in commit log?
I think that style carries less information per line.
For man page I'll document the syscall in a traditional way, but
for commit log I like to have maximum info in the fewest lines.
^ permalink raw reply
* [PATCH net-next] neigh: document gc_thresh2
From: Stephen Hemminger @ 2014-08-25 22:05 UTC (permalink / raw)
To: David Miller, Randy Dunlap; +Cc: netdev, linux-doc
Missing documentation for gc_thresh2 sysctl.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/Documentation/networking/ip-sysctl.txt 2014-08-12 13:07:41.000000000 -0700
+++ b/Documentation/networking/ip-sysctl.txt 2014-08-22 12:19:05.020051095 -0700
@@ -65,6 +65,12 @@ neigh/default/gc_thresh1 - INTEGER
purge entries if there are fewer than this number.
Default: 128
+neigh/default/gc_thresh2 - INTEGER
+ Threshold when garbage collector becomes more aggressive about
+ purging entries. Entries older than 5 seconds will be cleared
+ when over this number.
+ Default: 512
+
neigh/default/gc_thresh3 - INTEGER
Maximum number of neighbor entries allowed. Increase this
when using large numbers of interfaces and when communicating
^ permalink raw reply
* Fw: [Bug 80201] general protection fault: 0000 [#1] SMP (while using HTB)
From: Stephen Hemminger @ 2014-08-25 21:48 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 25 Aug 2014 09:39:23 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 80201] general protection fault: 0000 [#1] SMP (while using HTB)
https://bugzilla.kernel.org/show_bug.cgi?id=80201
--- Comment #12 from Cenek Zach <cenek.zach@gmail.com> ---
I might have a clue. We are changing the limits imposed by HTB each minute
using following command:
$TC class change dev "$BL_DEVICE" parent 1: classid 1:1 htb rate "$LIMIT" burst
"$BL_BURST" cburst "$BL_CBURST" quantum 60000
And this command was definitely running in 3/4 cases at the time of crash
(found him in 'crash> bt -a')
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
From: KY Srinivasan @ 2014-08-25 21:48 UTC (permalink / raw)
To: Sitsofe Wheeler, Dan Carpenter
Cc: Greg Kroah-Hartman, Jason Wang, Haiyang Zhang,
linux-kernel@vger.kernel.org, Daniel Borkmann,
netdev@vger.kernel.org, devel@linuxdriverproject.org,
David S. Miller
In-Reply-To: <20140825214303.GA32390@sucs.org>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Monday, August 25, 2014 2:43 PM
> To: Dan Carpenter
> Cc: KY Srinivasan; Greg Kroah-Hartman; Jason Wang; linux-
> kernel@vger.kernel.org; David S. Miller; Daniel Borkmann;
> netdev@vger.kernel.org; devel@linuxdriverproject.org; Haiyang Zhang
> Subject: Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
>
> On Mon, Aug 25, 2014 at 12:36:48PM +0300, Dan Carpenter wrote:
> > The code here is:
> >
> > drivers/hv/channel.c
> > 460 BUG_ON(ret != 0);
> > 461 t = wait_for_completion_timeout(&info->waitevent, 5*HZ);
> > 462 BUG_ON(t == 0);
> >
>
> There is also a case of the BUG_ON at line 460 being hit (from
> https://lkml.org/lkml/2014/8/19/708 ):
>
> 457 ret = vmbus_post_msg(msg,
> 458 sizeof(struct vmbus_channel_gpadl_teardown));
> 459
> 460 BUG_ON(ret != 0);
>
> Aug 20 03:42:58 ubuntuhv kernel: [ 13.028182] input: TPPS/2 IBM TrackPoint
> as /devices/platform/i8042/serio1/input/input4
> Aug 20 03:41:09 ubuntuhv kernel: [ 179.973064] hv_netvsc vmbus_0_14: net
> device safe to remove Aug 20 03:41:09 ubuntuhv kernel: [ 179.974995]
> hv_netvsc: hv_netvsc channel opened successfully Aug 20 03:41:10 ubuntuhv
> kernel: [ 180.402957] hv_netvsc vmbus_0_14 eth0: unable to establish send
> buffer's gpadl Aug 20 03:41:10 ubuntuhv kernel: [ 180.403080] ------------[ cut
> here ]------------ Aug 20 03:41:10 ubuntuhv kernel: [ 180.403141] kernel BUG
> at drivers/hv/channel.c:460!
> Aug 20 03:41:10 ubuntuhv kernel: [ 180.403253] invalid opcode: 0000 [#1]
> SMP Aug 20 03:41:10 ubuntuhv kernel: [ 180.403328] CPU: 1 PID: 1482 Comm:
> ifconfig Not tainted 3.17.0-rc1.x86_64 #1 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403431] Hardware name: Microsoft Corporation Virtual Machine/Virtual
> Machine, BIOS 090006 05/23/2012 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] task: ffff88006e45b9f0 ti: ffff880070b20000 task.ti:
> ffff880070b20000 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RIP:
> 0010:[<ffffffff815a9901>] [<ffffffff815a9901>]
> vmbus_teardown_gpadl+0xc1/0x130 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] RSP: 0018:ffff880070b23c00 EFLAGS: 00010202 Aug 20 03:41:10
> ubuntuhv kernel: [ 180.403536] RAX: 0000000000000004 RBX:
> ffff88006fef0e38 RCX: 0000000000000006 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] RDX: 0000000000000006 RSI: ffff88006e45c130 RDI:
> 0000000000000246 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RBP:
> ffff880070b23c20 R08: 0000000000000000 R09: 0000000000000000 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] R10: 0000000000000001 R11:
> 0000000000000001 R12: 0000000000000296 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] R13: ffff88007b911520 R14: ffff88006fef0e58 R15:
> 0000000000000004 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] FS:
> 00007fe5cd41d740(0000) GS:ffff88007fc20000(0000) knlGS:0000000000000000
> Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CS: 0010 DS: 0000 ES: 0000
> CR0: 0000000080050033 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CR2:
> 00007f4e3766d410 CR3: 0000000074bcb000 CR4: 00000000000406e0 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] Stack:
> Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] ffff880074550000
> 0000000000000000 ffff880078154520 ffff880074550000 Aug 20 03:41:10
> ubuntuhv kernel: [ 180.403536] ffff880070b23c48 ffffffff814e8276
> ffff88007b916458 ffff880078154520 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] ffff880074550000 ffff880070b23cb8 ffffffff814e957f
> ffff88007b911520 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] Call Trace:
> Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814e8276>]
> netvsc_destroy_buf+0xb6/0x210 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] [<ffffffff814e957f>] netvsc_device_add+0x6ef/0x7c0 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814ea6e0>]
> rndis_filter_device_add+0x80/0x430
> Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff810b16c0>] ?
> __wake_up_common+0x90/0x90 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] [<ffffffff814e6dfc>] netvsc_change_mtu+0x15c/0x1f0 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815d19d0>]
> dev_set_mtu+0x80/0x130 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536]
> [<ffffffff815e67b4>] dev_ifsioc+0x124/0x390 Aug 20 03:41:10 ubuntuhv
> kernel: [ 180.403536] [<ffffffff815e7006>] dev_ioctl+0x516/0x5e0 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815b339d>]
> sock_ioctl+0x1fd/0x210 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536]
> [<ffffffff811d54b0>] do_vfs_ioctl+0x4d0/0x510 Aug 20 03:41:10 ubuntuhv
> kernel: [ 180.403536] [<ffffffff8132aa9e>] ? file_has_perm+0x7e/0x90 Aug
> 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff811d5543>]
> SyS_ioctl+0x53/0x90 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536]
> [<ffffffff816a38e9>] system_call_fastpath+0x16/0x1b Aug 20 03:41:10
> ubuntuhv kernel: [ 180.403536] Code: 89 df e8 c3 ba df ff 4c 89 e6 48 c7 c7 40
> 27 ce 81 e8 24 93 0f 00 48 8d bb 88 00 00 00 be 10 00 00 00 e8 13 f2 ff ff 85 c0 74
> 07 <0f> 0b 0f 1f 44 00 00 be 88 13 00 00 4c 89 f7 e8 5b 4d 0f 00 85 Aug 20
> 03:41:10 ubuntuhv kernel: [ 180.403536] RIP [<ffffffff815a9901>]
> vmbus_teardown_gpadl+0xc1/0x130 Aug 20 03:41:10 ubuntuhv kernel: [
> 180.403536] RSP <ffff880070b23c00> Aug 20 03:41:10 ubuntuhv kernel: [
> 180.405770] ---[ end trace 9ec56592fdff213b ]---
I will take care of all BUG_ON() instances in channel.c
Regards,
K. Y
>
> --
> Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* Re: [PATCH iproute2] nstat: 64bit support on 32bit arches
From: Stephen Hemminger @ 2014-08-25 21:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1408976874.5604.65.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, 25 Aug 2014 07:27:54 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> SNMP counters can be provided as 64bit numbers.
> nstat needs to cope with this even if running in 32bit mode.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> misc/nstat.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/misc/nstat.c b/misc/nstat.c
> index d3f8621..e54b3ae 100644
> --- a/misc/nstat.c
> +++ b/misc/nstat.c
> @@ -77,7 +77,6 @@ struct nstat_ent
> struct nstat_ent *next;
> char *id;
> unsigned long long val;
> - unsigned long ival;
> double rate;
> };
>
> @@ -143,7 +142,6 @@ static void load_good_table(FILE *fp)
> if ((n = malloc(sizeof(*n))) == NULL)
> abort();
> n->id = strdup(idbuf);
> - n->ival = (unsigned long)val;
> n->val = val;
> n->rate = rate;
> n->next = db;
> @@ -206,9 +204,8 @@ static void load_ugly_table(FILE *fp)
> if (!p)
> abort();
> *p = 0;
> - if (sscanf(p+1, "%lu", &n->ival) != 1)
> + if (sscanf(p+1, "%llu", &n->val) != 1)
> abort();
> - n->val = n->ival;
> /* Trick to skip "dummy" trailing ICMP MIB in 2.4 */
> if (strcmp(idbuf, "IcmpOutAddrMaskReps") == 0)
> idbuf[5] = 0;
> @@ -365,10 +362,10 @@ static void update_db(int interval)
> for (h1 = h; h1; h1 = h1->next) {
> if (strcmp(h1->id, n->id) == 0) {
> double sample;
> - unsigned long incr = h1->ival - n->ival;
> - n->val += incr;
> - n->ival = h1->ival;
> - sample = (double)(incr*1000)/interval;
> + unsigned long long incr = h1->val - n->val;
> +
> + n->val = h1->val;
> + sample = (double)incr * 1000.0 / interval;
> if (interval >= scan_interval) {
> n->rate += W*(sample-n->rate);
> } else if (interval >= 1000) {
>
>
Maybe time to convert to using uint64_t and the printf formats in inttypes.h
^ permalink raw reply
* Fw: [Bug 83131] New: can: ti_hecc.c: closing device while receiving can messages, effectively disables all socket transfer
From: Stephen Hemminger @ 2014-08-25 21:45 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 24 Aug 2014 06:07:49 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 83131] New: can: ti_hecc.c: closing device while receiving can messages, effectively disables all socket transfer
https://bugzilla.kernel.org/show_bug.cgi?id=83131
Bug ID: 83131
Summary: can: ti_hecc.c: closing device while receiving can
messages, effectively disables all socket transfer
Product: Networking
Version: 2.5
Kernel Version: 3.16.1
Hardware: All
OS: Linux
Tree: PREEMPT_RT
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: jan.sondhauss@gmail.com
Regression: No
drivers/net/can/ti_hecc.c:
When closing the can device, its not ensured that it gets removed from the
socket-poll list.
The problem here lies in the ti_hecc_rx_poll() function which returns early
when the device is closed already.
This leads to napi_complete() never being called, thus the device stays in the
napi's poll list forever and every task reading from any socket is polling this
device. The system is now basically unreachable.
The patch attached seams to fix this problem by removing the early return in
the ti_hecc_rx_poll function. But I'm not sure whether this is the correct
solution.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
From: Sitsofe Wheeler @ 2014-08-25 21:43 UTC (permalink / raw)
To: Dan Carpenter
Cc: Greg Kroah-Hartman, Jason Wang, Haiyang Zhang, linux-kernel,
Daniel Borkmann, netdev, devel, David S. Miller
In-Reply-To: <20140825093648.GB5046@mwanda>
On Mon, Aug 25, 2014 at 12:36:48PM +0300, Dan Carpenter wrote:
> The code here is:
>
> drivers/hv/channel.c
> 460 BUG_ON(ret != 0);
> 461 t = wait_for_completion_timeout(&info->waitevent, 5*HZ);
> 462 BUG_ON(t == 0);
>
There is also a case of the BUG_ON at line 460 being hit
(from https://lkml.org/lkml/2014/8/19/708 ):
457 ret = vmbus_post_msg(msg,
458 sizeof(struct vmbus_channel_gpadl_teardown));
459
460 BUG_ON(ret != 0);
Aug 20 03:42:58 ubuntuhv kernel: [ 13.028182] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4
Aug 20 03:41:09 ubuntuhv kernel: [ 179.973064] hv_netvsc vmbus_0_14: net device safe to remove
Aug 20 03:41:09 ubuntuhv kernel: [ 179.974995] hv_netvsc: hv_netvsc channel opened successfully
Aug 20 03:41:10 ubuntuhv kernel: [ 180.402957] hv_netvsc vmbus_0_14 eth0: unable to establish send buffer's gpadl
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403080] ------------[ cut here ]------------
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403141] kernel BUG at drivers/hv/channel.c:460!
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403253] invalid opcode: 0000 [#1] SMP
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403328] CPU: 1 PID: 1482 Comm: ifconfig Not tainted 3.17.0-rc1.x86_64 #1
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403431] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] task: ffff88006e45b9f0 ti: ffff880070b20000 task.ti: ffff880070b20000
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RIP: 0010:[<ffffffff815a9901>] [<ffffffff815a9901>] vmbus_teardown_gpadl+0xc1/0x130
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RSP: 0018:ffff880070b23c00 EFLAGS: 00010202
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RAX: 0000000000000004 RBX: ffff88006fef0e38 RCX: 0000000000000006
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RDX: 0000000000000006 RSI: ffff88006e45c130 RDI: 0000000000000246
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RBP: ffff880070b23c20 R08: 0000000000000000 R09: 0000000000000000
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000296
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] R13: ffff88007b911520 R14: ffff88006fef0e58 R15: 0000000000000004
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] FS: 00007fe5cd41d740(0000) GS:ffff88007fc20000(0000) knlGS:0000000000000000
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CR2: 00007f4e3766d410 CR3: 0000000074bcb000 CR4: 00000000000406e0
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] Stack:
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] ffff880074550000 0000000000000000 ffff880078154520 ffff880074550000
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] ffff880070b23c48 ffffffff814e8276 ffff88007b916458 ffff880078154520
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] ffff880074550000 ffff880070b23cb8 ffffffff814e957f ffff88007b911520
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] Call Trace:
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814e8276>] netvsc_destroy_buf+0xb6/0x210
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814e957f>] netvsc_device_add+0x6ef/0x7c0
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814ea6e0>] rndis_filter_device_add+0x80/0x430
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff810b16c0>] ? __wake_up_common+0x90/0x90
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff814e6dfc>] netvsc_change_mtu+0x15c/0x1f0
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815d19d0>] dev_set_mtu+0x80/0x130
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815e67b4>] dev_ifsioc+0x124/0x390
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815e7006>] dev_ioctl+0x516/0x5e0
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff815b339d>] sock_ioctl+0x1fd/0x210
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff811d54b0>] do_vfs_ioctl+0x4d0/0x510
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff8132aa9e>] ? file_has_perm+0x7e/0x90
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff811d5543>] SyS_ioctl+0x53/0x90
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] [<ffffffff816a38e9>] system_call_fastpath+0x16/0x1b
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] Code: 89 df e8 c3 ba df ff 4c 89 e6 48 c7 c7 40 27 ce 81 e8 24 93 0f 00 48 8d bb 88 00 00 00 be 10 00 00 00 e8 13 f2 ff ff 85 c0 74 07 <0f> 0b 0f 1f 44 00 00 be 88 13 00 00 4c 89 f7 e8 5b 4d 0f 00 85
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RIP [<ffffffff815a9901>] vmbus_teardown_gpadl+0xc1/0x130
Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RSP <ffff880070b23c00>
Aug 20 03:41:10 ubuntuhv kernel: [ 180.405770] ---[ end trace 9ec56592fdff213b ]---
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* RE: [tipc-discussion] [PATCH net-next 2/2] tipc: add name distributor resiliency queue
From: Jon Maloy @ 2014-08-25 21:40 UTC (permalink / raw)
To: Jon Maloy, Erik Hugne, ying.xue@windriver.com, Richard Alpe,
netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D1C2BED37@eusaamb103.ericsson.se>
> -----Original Message-----
> From: Jon Maloy [mailto:jon.maloy@ericsson.com]
> Sent: August-25-14 5:18 PM
> To: Erik Hugne; ying.xue@windriver.com; Richard Alpe;
> netdev@vger.kernel.org
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next 2/2] tipc: add name distributor
> resiliency queue
>
>
>
> > -----Original Message-----
> > From: Erik Hugne
> > Sent: August-25-14 10:54 AM
> > To: Jon Maloy; ying.xue@windriver.com; Richard Alpe;
> > netdev@vger.kernel.org
> > Cc: tipc-discussion@lists.sourceforge.net; Erik Hugne
> > Subject: [PATCH net-next 2/2] tipc: add name distributor resiliency
> > queue
> >
> > From: Erik Hugne <erik.hugne@ericsson.com>
> >
> > TIPC name table updates are distributed asynchronously in a cluster,
> > entailing a risk of certain race conditions. E.g., if two nodes
> > simultaneously issue conflicting (overlapping) publications, this may
> > not be detected until both publications have reached a third node, in
> > which case one of the publications will be silently dropped on that
> > node. Hence, we end up with an inconsistent name table.
> >
> > In most cases this conflict is just a temporary race, e.g., one node
> > is issuing a publication under the assumption that a previous,
> > conflicting, publication has already been withdrawn by the other node.
> > However, because of the (rtt related) distributed update delay, this
> > may not yet hold true on all nodes. The symptom of this failure is a syslog
> message:
> > "tipc: Cannot publish {%u,%u,%u}, overlap error".
> >
> > In this commit we add a resiliency queue at the receiving end of the
> > name table distributor. When insertion of an arriving publication
> > fails, we retain it in this queue for a short amount of time, assuming
> > that another update will arrive very soon and clear the conflict. If
> > so happens, we insert the publication, otherwise we drop it.
> >
> > The (configurable) retention value defaults to 2000 ms. Knowing from
> > experience that the situation described above is extremely rare, there
> > is no risk that the queue will accumulate any large number of items.
> >
> > Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> > Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
> > ---
> > Documentation/sysctl/net.txt | 14 +++++++++
> > net/tipc/core.h | 1 +
> > net/tipc/name_distr.c | 69
> > ++++++++++++++++++++++++++++++++++++++++++--
> > net/tipc/name_distr.h | 1 +
> > net/tipc/name_table.c | 8 ++---
> > net/tipc/sysctl.c | 7 +++++
> > 6 files changed, 93 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/sysctl/net.txt
> > b/Documentation/sysctl/net.txt index 9a0319a..89ce54e 100644
> > --- a/Documentation/sysctl/net.txt
> > +++ b/Documentation/sysctl/net.txt
> > @@ -241,6 +241,9 @@ address of the router (or Connected) for internal
> > networks.
> > 6. TIPC
> > -------------------------------------------------------
> >
> > +tipc_rmem
> > +----------
> > +
> > The TIPC protocol now has a tunable for the receive memory, similar
> > to the tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max)
> >
> > @@ -252,3 +255,14 @@ The max value is set to CONN_OVERLOAD_LIMIT,
> and
> > the default and min values are scaled (shifted) versions of that same
> > value. Note that the min value is not at this point in time used in
> > any meaningful way, but the triplet is preserved in order to be
> > consistent with things like tcp_rmem.
> > +
> > +named_timeout
> > +--------------
> > +
> > +TIPC name table updates are distributed asynchronous
>
> asynchronously
>
> >+ in a cluster,
> without any form of transaction handling.
>
> This means that different race scenarios are possible. One such is that a
> name withdrawal sent out by one node and received by a another node may
> arrive after a second, overlapping name publication already has been
> accepted from a third node, although the conflicting updates originally may
> have been issued in the correct sequential order.
>
> > +If named_timeout is nonzero, failed topology updates will be placed
> > +on a defer queue until another event arrives that clears the error,
> > +or until the timeout expires. Value is in milliseconds.
> > diff --git a/net/tipc/core.h b/net/tipc/core.h index d2607a8..f773b14
> > 100644
> > --- a/net/tipc/core.h
> > +++ b/net/tipc/core.h
> > @@ -81,6 +81,7 @@ extern u32 tipc_own_addr __read_mostly; extern int
> > tipc_max_ports __read_mostly; extern int tipc_net_id __read_mostly;
> > extern int sysctl_tipc_rmem[3] __read_mostly;
> > +extern int sysctl_tipc_named_timeout __read_mostly;
> >
> > /*
> > * Other global variables
> > diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c index
> > 0591f33..0cbe5e1 100644
> > --- a/net/tipc/name_distr.c
> > +++ b/net/tipc/name_distr.c
> > @@ -1,7 +1,7 @@
> > /*
> > * net/tipc/name_distr.c: TIPC name distribution code
> > *
> > - * Copyright (c) 2000-2006, Ericsson AB
> > + * Copyright (c) 2000-2006, 2014, Ericsson AB
> > * Copyright (c) 2005, 2010-2011, Wind River Systems
> > * All rights reserved.
> > *
> > @@ -71,6 +71,21 @@ static struct publ_list *publ_lists[] = { };
> >
> >
> > +int sysctl_tipc_named_timeout __read_mostly = 2000;
> > +
> > +/**
> > + * struct tipc_dist_queue - queue holding deferred name table updates
> > +*/ static struct list_head tipc_dist_queue =
> > +LIST_HEAD_INIT(tipc_dist_queue);
> > +
> > +struct distr_queue_item {
> > + struct distr_item i;
> > + u32 dtype;
> > + u32 node;
> > + u64 expiry;
> > + struct list_head next;
> > +};
> > +
> > /**
> > * publ_to_item - add publication info to a publication message
> > */
> > @@ -299,6 +314,52 @@ struct publication *tipc_update_nametbl(struct
> > distr_item *i, u32 node, }
> >
> > /**
> > + * tipc_named_add_backlog - add a failed name table update to the
> > +backlog
> > + *
> > + */
> > +static void tipc_named_add_backlog(struct distr_item *i, u32 type,
> > +u32
> > +node) {
> > + struct distr_queue_item *e;
> > + u64 now = get_jiffies_64();
> > +
> > + e = kzalloc(sizeof(*e), GFP_ATOMIC);
> > + if (!e)
> > + return;
> > + e->dtype = type;
> > + e->node = node;
> > + e->expiry = now + msecs_to_jiffies(sysctl_tipc_named_timeout);
> > + memcpy(e, i, sizeof(*i));
> > + list_add_tail(&e->next, &tipc_dist_queue); }
> > +
> > +/**
> > + * tipc_named_process_backlog - try to process any pending name table
> > +updates
> > + * from the network.
> > + */
> > +void tipc_named_process_backlog(void) {
> > + struct distr_queue_item *e, *tmp;
> > + char addr[16];
> > + u64 now = get_jiffies_64();
> > +
> > + list_for_each_entry_safe(e, tmp, &tipc_dist_queue, next) {
> > + if (e->expiry > now) {
> > + if (!tipc_update_nametbl(&e->i, e->node, e-
> > >dtype))
> > + continue;
> > + } else {
> > + tipc_addr_string_fill(addr, e->node);
> > + pr_warn_ratelimited("Dropping name table update
> > (%d) of {%u, %u, %u} from %s key=%u\n",
> > + e->dtype, ntohl(e->i.type),
> > + ntohl(e->i.lower),
> > + ntohl(e->i.upper),
>
>
> +
> + tipc_addr_string_fill(addr),
>
> Otherwise you'll have a nice little crash here ;)
Ahh, I see it is correct now. Sorry for the noice.
///jon
>
> Apart from this I am ok with it. You can add "Reviewed-by" from me.
>
> ///jon
>
>
> > + ntohl(e->i.key));
> > + }
> > + list_del(&e->next);
> > + kfree(e);
> > + }
> > +}
> > +
> > +/**
> > * tipc_named_rcv - process name table update message sent by another
> > node
> > */
> > void tipc_named_rcv(struct sk_buff *buf) @@ -306,13 +367,15 @@ void
> > tipc_named_rcv(struct sk_buff *buf)
> > struct tipc_msg *msg = buf_msg(buf);
> > struct distr_item *item = (struct distr_item *)msg_data(msg);
> > u32 count = msg_data_sz(msg) / ITEM_SIZE;
> > + u32 node = msg_orignode(msg);
> >
> > write_lock_bh(&tipc_nametbl_lock);
> > while (count--) {
> > - tipc_update_nametbl(item, msg_orignode(msg),
> > - msg_type(msg));
> > + if (!tipc_update_nametbl(item, node, msg_type(msg)))
> > + tipc_named_add_backlog(item, msg_type(msg),
> > node);
> > item++;
> > }
> > + tipc_named_process_backlog();
> > write_unlock_bh(&tipc_nametbl_lock);
> > kfree_skb(buf);
> > }
> > diff --git a/net/tipc/name_distr.h b/net/tipc/name_distr.h index
> > 8afe32b..b9e75fe 100644
> > --- a/net/tipc/name_distr.h
> > +++ b/net/tipc/name_distr.h
> > @@ -73,5 +73,6 @@ void named_cluster_distribute(struct sk_buff *buf);
> > void tipc_named_node_up(u32 dnode); void tipc_named_rcv(struct
> > sk_buff *buf); void tipc_named_reinit(void);
> > +void tipc_named_process_backlog(void);
> >
> > #endif
> > diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c index
> > c058e30..3a6a0a7 100644
> > --- a/net/tipc/name_table.c
> > +++ b/net/tipc/name_table.c
> > @@ -261,8 +261,6 @@ static struct publication
> > *tipc_nameseq_insert_publ(struct name_seq *nseq,
> >
> > /* Lower end overlaps existing entry => need an exact match
> */
> > if ((sseq->lower != lower) || (sseq->upper != upper)) {
> > - pr_warn("Cannot publish {%u,%u,%u}, overlap
> > error\n",
> > - type, lower, upper);
> > return NULL;
> > }
> >
> > @@ -284,8 +282,6 @@ static struct publication
> > *tipc_nameseq_insert_publ(struct name_seq *nseq,
> > /* Fail if upper end overlaps into an existing entry */
> > if ((inspos < nseq->first_free) &&
> > (upper >= nseq->sseqs[inspos].lower)) {
> > - pr_warn("Cannot publish {%u,%u,%u}, overlap
> > error\n",
> > - type, lower, upper);
> > return NULL;
> > }
> >
> > @@ -677,6 +673,8 @@ struct publication *tipc_nametbl_publish(u32 type,
> > u32 lower, u32 upper,
> > if (likely(publ)) {
> > table.local_publ_count++;
> > buf = tipc_named_publish(publ);
> > + /* Any pending external events? */
> > + tipc_named_process_backlog();
> > }
> > write_unlock_bh(&tipc_nametbl_lock);
> >
> > @@ -698,6 +696,8 @@ int tipc_nametbl_withdraw(u32 type, u32 lower,
> u32
> > ref, u32 key)
> > if (likely(publ)) {
> > table.local_publ_count--;
> > buf = tipc_named_withdraw(publ);
> > + /* Any pending external events? */
> > + tipc_named_process_backlog();
> > write_unlock_bh(&tipc_nametbl_lock);
> > list_del_init(&publ->pport_list);
> > kfree(publ);
> > diff --git a/net/tipc/sysctl.c b/net/tipc/sysctl.c index
> > f3fef93..1a779b1 100644
> > --- a/net/tipc/sysctl.c
> > +++ b/net/tipc/sysctl.c
> > @@ -47,6 +47,13 @@ static struct ctl_table tipc_table[] = {
> > .mode = 0644,
> > .proc_handler = proc_dointvec,
> > },
> > + {
> > + .procname = "named_timeout",
> > + .data = &sysctl_tipc_named_timeout,
> > + .maxlen =
> > sizeof(sysctl_tipc_named_timeout),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec,
> > + },
> > {}
> > };
> >
> > --
> > 1.8.3.2
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> tipc-discussion mailing list
> tipc-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
^ permalink raw reply
* Re: [PATCH v5 net-next 06/29] bpf: add lookup/update/delete/iterate methods to BPF maps
From: Cong Wang @ 2014-08-25 21:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Daniel Borkmann, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, Brendan Gregg, Namhyung Kim, H. Peter Anvin,
Andrew Morton, Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1408911690-7598-7-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On Sun, Aug 24, 2014 at 1:21 PM, Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
> 'maps' is a generic storage of different types for sharing data between kernel
> and userspace.
>
> The maps are accessed from user space via BPF syscall, which has commands:
>
> - create a map with given type and attributes
> fd = bpf_map_create(map_type, struct nlattr *attr, int len)
> returns fd or negative error
>
> - lookup key in a given map referenced by fd
> err = bpf_map_lookup_elem(int fd, void *key, void *value)
> returns zero and stores found elem into value or negative error
>
> - create or update key/value pair in a given map
> err = bpf_map_update_elem(int fd, void *key, void *value)
> returns zero or negative error
>
> - find and delete element by key in a given map
> err = bpf_map_delete_elem(int fd, void *key)
>
> - iterate map elements (based on input key return next_key)
> err = bpf_map_get_next_key(int fd, void *key, void *next_key)
I think you need to document the bpf() syscall instead of wrappers on it,
from a developer's point of view. You will anyway need to document a new
syscall with a man page as a general rule.
In the changelog I mean something like:
err = bpf(BPF_MAP_LOOKUP_ELEM, ...);
^ permalink raw reply
* Re: [PATCH net-next 2/2] tipc: add name distributor resiliency queue
From: Jon Maloy @ 2014-08-25 21:17 UTC (permalink / raw)
To: Erik Hugne, ying.xue@windriver.com, Richard Alpe,
netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net
In-Reply-To: <1408978469-10584-2-git-send-email-erik.hugne@ericsson.com>
> -----Original Message-----
> From: Erik Hugne
> Sent: August-25-14 10:54 AM
> To: Jon Maloy; ying.xue@windriver.com; Richard Alpe;
> netdev@vger.kernel.org
> Cc: tipc-discussion@lists.sourceforge.net; Erik Hugne
> Subject: [PATCH net-next 2/2] tipc: add name distributor resiliency queue
>
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> TIPC name table updates are distributed asynchronously in a cluster, entailing
> a risk of certain race conditions. E.g., if two nodes simultaneously issue
> conflicting (overlapping) publications, this may not be detected until both
> publications have reached a third node, in which case one of the publications
> will be silently dropped on that node. Hence, we end up with an inconsistent
> name table.
>
> In most cases this conflict is just a temporary race, e.g., one node is issuing a
> publication under the assumption that a previous, conflicting, publication has
> already been withdrawn by the other node.
> However, because of the (rtt related) distributed update delay, this may not
> yet hold true on all nodes. The symptom of this failure is a syslog message:
> "tipc: Cannot publish {%u,%u,%u}, overlap error".
>
> In this commit we add a resiliency queue at the receiving end of the name
> table distributor. When insertion of an arriving publication fails, we retain it in
> this queue for a short amount of time, assuming that another update will
> arrive very soon and clear the conflict. If so happens, we insert the
> publication, otherwise we drop it.
>
> The (configurable) retention value defaults to 2000 ms. Knowing from
> experience that the situation described above is extremely rare, there is no
> risk that the queue will accumulate any large number of items.
>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> Documentation/sysctl/net.txt | 14 +++++++++
> net/tipc/core.h | 1 +
> net/tipc/name_distr.c | 69
> ++++++++++++++++++++++++++++++++++++++++++--
> net/tipc/name_distr.h | 1 +
> net/tipc/name_table.c | 8 ++---
> net/tipc/sysctl.c | 7 +++++
> 6 files changed, 93 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
> index 9a0319a..89ce54e 100644
> --- a/Documentation/sysctl/net.txt
> +++ b/Documentation/sysctl/net.txt
> @@ -241,6 +241,9 @@ address of the router (or Connected) for internal
> networks.
> 6. TIPC
> -------------------------------------------------------
>
> +tipc_rmem
> +----------
> +
> The TIPC protocol now has a tunable for the receive memory, similar to the
> tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max)
>
> @@ -252,3 +255,14 @@ The max value is set to CONN_OVERLOAD_LIMIT,
> and the default and min values are scaled (shifted) versions of that same
> value. Note that the min value is not at this point in time used in any
> meaningful way, but the triplet is preserved in order to be consistent with
> things like tcp_rmem.
> +
> +named_timeout
> +--------------
> +
> +TIPC name table updates are distributed asynchronous
asynchronously
>+ in a cluster,
without any form of transaction handling.
This means that different race scenarios are possible. One such is that
a name withdrawal sent out by one node and received by a another node
may arrive after a second, overlapping name publication already has been
accepted from a third node, although the conflicting updates originally may
have been issued in the correct sequential order.
> +If named_timeout is nonzero, failed topology updates will be placed on
> +a defer queue until another event arrives that clears the error, or
> +until the timeout expires. Value is in milliseconds.
> diff --git a/net/tipc/core.h b/net/tipc/core.h index d2607a8..f773b14 100644
> --- a/net/tipc/core.h
> +++ b/net/tipc/core.h
> @@ -81,6 +81,7 @@ extern u32 tipc_own_addr __read_mostly; extern int
> tipc_max_ports __read_mostly; extern int tipc_net_id __read_mostly;
> extern int sysctl_tipc_rmem[3] __read_mostly;
> +extern int sysctl_tipc_named_timeout __read_mostly;
>
> /*
> * Other global variables
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c index
> 0591f33..0cbe5e1 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -1,7 +1,7 @@
> /*
> * net/tipc/name_distr.c: TIPC name distribution code
> *
> - * Copyright (c) 2000-2006, Ericsson AB
> + * Copyright (c) 2000-2006, 2014, Ericsson AB
> * Copyright (c) 2005, 2010-2011, Wind River Systems
> * All rights reserved.
> *
> @@ -71,6 +71,21 @@ static struct publ_list *publ_lists[] = { };
>
>
> +int sysctl_tipc_named_timeout __read_mostly = 2000;
> +
> +/**
> + * struct tipc_dist_queue - queue holding deferred name table updates
> +*/ static struct list_head tipc_dist_queue =
> +LIST_HEAD_INIT(tipc_dist_queue);
> +
> +struct distr_queue_item {
> + struct distr_item i;
> + u32 dtype;
> + u32 node;
> + u64 expiry;
> + struct list_head next;
> +};
> +
> /**
> * publ_to_item - add publication info to a publication message
> */
> @@ -299,6 +314,52 @@ struct publication *tipc_update_nametbl(struct
> distr_item *i, u32 node, }
>
> /**
> + * tipc_named_add_backlog - add a failed name table update to the
> +backlog
> + *
> + */
> +static void tipc_named_add_backlog(struct distr_item *i, u32 type, u32
> +node) {
> + struct distr_queue_item *e;
> + u64 now = get_jiffies_64();
> +
> + e = kzalloc(sizeof(*e), GFP_ATOMIC);
> + if (!e)
> + return;
> + e->dtype = type;
> + e->node = node;
> + e->expiry = now + msecs_to_jiffies(sysctl_tipc_named_timeout);
> + memcpy(e, i, sizeof(*i));
> + list_add_tail(&e->next, &tipc_dist_queue); }
> +
> +/**
> + * tipc_named_process_backlog - try to process any pending name table
> +updates
> + * from the network.
> + */
> +void tipc_named_process_backlog(void)
> +{
> + struct distr_queue_item *e, *tmp;
> + char addr[16];
> + u64 now = get_jiffies_64();
> +
> + list_for_each_entry_safe(e, tmp, &tipc_dist_queue, next) {
> + if (e->expiry > now) {
> + if (!tipc_update_nametbl(&e->i, e->node, e-
> >dtype))
> + continue;
> + } else {
> + tipc_addr_string_fill(addr, e->node);
> + pr_warn_ratelimited("Dropping name table update
> (%d) of {%u, %u, %u} from %s key=%u\n",
> + e->dtype, ntohl(e->i.type),
> + ntohl(e->i.lower),
> + ntohl(e->i.upper),
+ tipc_addr_string_fill(addr),
Otherwise you'll have a nice little crash here ;)
Apart from this I am ok with it. You can add "Reviewed-by" from me.
///jon
> + ntohl(e->i.key));
> + }
> + list_del(&e->next);
> + kfree(e);
> + }
> +}
> +
> +/**
> * tipc_named_rcv - process name table update message sent by another
> node
> */
> void tipc_named_rcv(struct sk_buff *buf) @@ -306,13 +367,15 @@ void
> tipc_named_rcv(struct sk_buff *buf)
> struct tipc_msg *msg = buf_msg(buf);
> struct distr_item *item = (struct distr_item *)msg_data(msg);
> u32 count = msg_data_sz(msg) / ITEM_SIZE;
> + u32 node = msg_orignode(msg);
>
> write_lock_bh(&tipc_nametbl_lock);
> while (count--) {
> - tipc_update_nametbl(item, msg_orignode(msg),
> - msg_type(msg));
> + if (!tipc_update_nametbl(item, node, msg_type(msg)))
> + tipc_named_add_backlog(item, msg_type(msg),
> node);
> item++;
> }
> + tipc_named_process_backlog();
> write_unlock_bh(&tipc_nametbl_lock);
> kfree_skb(buf);
> }
> diff --git a/net/tipc/name_distr.h b/net/tipc/name_distr.h index
> 8afe32b..b9e75fe 100644
> --- a/net/tipc/name_distr.h
> +++ b/net/tipc/name_distr.h
> @@ -73,5 +73,6 @@ void named_cluster_distribute(struct sk_buff *buf);
> void tipc_named_node_up(u32 dnode); void tipc_named_rcv(struct sk_buff
> *buf); void tipc_named_reinit(void);
> +void tipc_named_process_backlog(void);
>
> #endif
> diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c index
> c058e30..3a6a0a7 100644
> --- a/net/tipc/name_table.c
> +++ b/net/tipc/name_table.c
> @@ -261,8 +261,6 @@ static struct publication
> *tipc_nameseq_insert_publ(struct name_seq *nseq,
>
> /* Lower end overlaps existing entry => need an exact match
> */
> if ((sseq->lower != lower) || (sseq->upper != upper)) {
> - pr_warn("Cannot publish {%u,%u,%u}, overlap
> error\n",
> - type, lower, upper);
> return NULL;
> }
>
> @@ -284,8 +282,6 @@ static struct publication
> *tipc_nameseq_insert_publ(struct name_seq *nseq,
> /* Fail if upper end overlaps into an existing entry */
> if ((inspos < nseq->first_free) &&
> (upper >= nseq->sseqs[inspos].lower)) {
> - pr_warn("Cannot publish {%u,%u,%u}, overlap
> error\n",
> - type, lower, upper);
> return NULL;
> }
>
> @@ -677,6 +673,8 @@ struct publication *tipc_nametbl_publish(u32 type,
> u32 lower, u32 upper,
> if (likely(publ)) {
> table.local_publ_count++;
> buf = tipc_named_publish(publ);
> + /* Any pending external events? */
> + tipc_named_process_backlog();
> }
> write_unlock_bh(&tipc_nametbl_lock);
>
> @@ -698,6 +696,8 @@ int tipc_nametbl_withdraw(u32 type, u32 lower, u32
> ref, u32 key)
> if (likely(publ)) {
> table.local_publ_count--;
> buf = tipc_named_withdraw(publ);
> + /* Any pending external events? */
> + tipc_named_process_backlog();
> write_unlock_bh(&tipc_nametbl_lock);
> list_del_init(&publ->pport_list);
> kfree(publ);
> diff --git a/net/tipc/sysctl.c b/net/tipc/sysctl.c index f3fef93..1a779b1 100644
> --- a/net/tipc/sysctl.c
> +++ b/net/tipc/sysctl.c
> @@ -47,6 +47,13 @@ static struct ctl_table tipc_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> + {
> + .procname = "named_timeout",
> + .data = &sysctl_tipc_named_timeout,
> + .maxlen =
> sizeof(sysctl_tipc_named_timeout),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> {}
> };
>
> --
> 1.8.3.2
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
^ 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