* Re: [PATCH] net: stmicro: stmac: do not grab a mutex in irq off section
From: David Miller @ 2014-02-19 20:23 UTC (permalink / raw)
To: bigeasy; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1392744843-6324-1-git-send-email-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Tue, 18 Feb 2014 18:34:03 +0100
> I captured this:
>
> |libphy: stmmac-0:04 - Link is Up - 1000/Full
> |BUG: sleeping function called from invalid context at kernel/mutex.c:616
> |in_atomic(): 1, irqs_disabled(): 128, pid: 31, name: kworker/1:1
> |CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 3.12.0-00324-g28301d2-dirty #5
> |[<8042f8e8>] (mutex_lock_nested+0x28/0x3cc) from [<802a226c>] (mdiobus_read+0x38/0x64)
> |[<802a226c>] (mdiobus_read+0x38/0x64) from [<802a1968>] (genphy_update_link+0x18/0x50)
> |[<802a1968>] (genphy_update_link+0x18/0x50) from [<802a19ac>] (genphy_read_status+0xc/0x180)
> |[<802a19ac>] (genphy_read_status+0xc/0x180) from [<8029fb0c>] (phy_init_eee+0x4c/0x2ac)
> |[<8029fb0c>] (phy_init_eee+0x4c/0x2ac) from [<802a7550>] (stmmac_eee_init+0x40/0x104)
> |[<802a7550>] (stmmac_eee_init+0x40/0x104) from [<802a8678>] (stmmac_adjust_link+0x118/0x228)
> |[<802a8678>] (stmmac_adjust_link+0x118/0x228) from [<802a0af4>] (phy_state_machine+0x23c/0x39c)
> |[<802a0af4>] (phy_state_machine+0x23c/0x39c) from [<800371b8>] (process_one_work+0x1a4/0x44c)
> |[<800371b8>] (process_one_work+0x1a4/0x44c) from [<80037884>] (worker_thread+0x138/0x390)
> |[<80037884>] (worker_thread+0x138/0x390) from [<8003e850>] (kthread+0xb4/0xb8)
> |[<8003e850>] (kthread+0xb4/0xb8) from [<8000e5a8>] (ret_from_fork+0x14/0x2c)
> |stmmac: Energy-Efficient Ethernet initialized
>
> stmmac_eee_init() is called in other places without this lock.
> phy_print_status() is just a printk() and the if condition is not
> protected by the lock so I moved the unlock part just before that.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
It does look like a problem though, two concurrent calls into
stmmac_eee_init would be really bad. Two threads could see
eee enabled being false at the same time, and both try to
initialize the eee state.
stmmac_hw_setup()'s invocation is fine because we doing something like
bringing the device up or bringing it back after resume, and thus are
synchonized by the RTNL semaphore.
Actually, the same "mutex in irq off section" problem exists in that
code path, because stmmac_resume() invokes stmmac_hw_setup() with
the priv->lock held.
This is a much deeper problem then what your patch is tackling, and
thus a lot more thought about how to fix this is needed.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH] of_mdio: fix phy interrupt passing
From: Sergei Shtylyov @ 2014-02-19 20:18 UTC (permalink / raw)
To: Florian Fainelli, Ben Dooks
Cc: Grant Likely, linux-kernel, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev, Linux-sh list
In-Reply-To: <CAGVrzcZGW05uNj75VG7w4iSGre4OzEMhHedQfaynekrbhP4NLQ@mail.gmail.com>
Hello.
On 02/17/2014 08:48 PM, Florian Fainelli wrote:
>>>> The of_mdiobus_register_phy() is not setting phy->irq this causing
>>>> some drivers to incorrectly assume that the PHY does not have an
>>>> IRQ associated with it or install an interrupt handler for the
>>>> PHY.
>>>> Simplify the code setting irq and set the phy->irq at the same
>>>> time so that the case if mdio->irq is not NULL is easier to read.
>>> The real bug fix, which is not properly explained here, is that
>>> irq_of_parse_and_map() should return values > 0 when the interrupt is
>>> valid, so this makes me wonder why we are not propagating the return
>>> value from irq_of_parse_and_map() in case the call to
>>> of_irq_parse_one() does return something non-zero?
>> No, the first issue is phy->dev never gets set, which causes the
>> issue. The cleanup was added as it seemed easier to put it in with
>> this.
> Ok, that really needs to be mentioned in the commit message, even
> being quite familiar (and possibly dumb too) with the code, I could
> not figure this out by reading your patch.
Yes, the main issue was that phy->irq wasn't overridden from the value set
by phy_device_create().
>> I think phy->irq is already initialised to PHY_POLL and thus there
>> is no need to set phy->irq if the irq_of_parse_and_map() fails.
> That is correct, the reason why I introduced 7d97637 ("net: of_mdio:
> do not overwrite PHY interrupt configuration") was that you are also
> allowed to change the irq type before calling into
> of_mdiobus_register(),
Not really: of_mdiobus_register() init's all of mdio->irq[] with IRQ_POLL,
thus wiping out all of the previous initialization, so I don't know what you
did achieve with the aforementioned commit.
> so we want to preserve other irq values being
> set here, such as PHY_IGNORE_INTERRUPT. Your patch does take care of
> that since it only overrides the irq in case we could parse it.
And it should have stayed that way. The latter change was unnecessary.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] net: tcp: RTO restart
From: Andreas Petlund @ 2014-02-19 20:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Per Hurtig, netdev, davem, edumazet, Anna Brunström,
Michael Welzl, ilpo.jarvinen
In-Reply-To: <1392832907.18849.10.camel@edumazet-glaptop2.roam.corp.google.com>
On 19 Feb 2014, at 19:01, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-02-19 at 18:17 +0100, Andreas Petlund wrote:
>> I’ve applied and tested the patch on VMs with both 32 bit and 64 bit kernel.
>>
>> Acked-by: Andreas Petlund <apetlund@simula.no>
>> Tested-by: Andreas Petlund <apetlund@simula.no>
>
> Sure the patch applies, but what experimental results did you get ?
>
> My concern is that TCP_SKB_CB(skb)->when doesn't account for sojourn
> time in host queues (qdisc and device).
>
Thank’s for the input. I didn’t run any specific tests with that in mind. I’ll look into it.
Best regards,
Andreas
^ permalink raw reply
* Re: [PATCH net-next v2] unix: add read side socket memory accounting for dgram sockets
From: Hannes Frederic Sowa @ 2014-02-19 20:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yannick, eric.dumazet, xiyou.wangcong, dan
In-Reply-To: <20140219.144927.1558282069067885839.davem@davemloft.net>
On Wed, Feb 19, 2014 at 02:49:27PM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Mon, 17 Feb 2014 14:03:53 +0100
>
> > We still allocate dgram packets with sock_alloc_send_pskb, which now
> > does normally not block if the socket has too many packets in flight.
>
> It seems like it does to me, it does sock_wait_for_wmem(), right?
We still do the sock_wait_for_wmem in sock_alloc_send_pskb, correct,
but we rarly block there, maybe in highly concurrent cases with big
payloads where one process got interrupted to account the memory to the
receiving socket.
> Or are you trying to say that usually this is not the point at which
> we block, but rather it's when we check the peer's receive queue?
Exactly.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 2/2] pcnet32: add missing check for pci_dma_mapping_error
From: David Miller @ 2014-02-19 19:59 UTC (permalink / raw)
To: pcnet32; +Cc: netdev
In-Reply-To: <1392699479.4020.28.camel@Linux>
From: Don Fry <pcnet32@frontier.com>
Date: Mon, 17 Feb 2014 20:57:59 -0800
> The pci_map_single calls never checked for error. Add error checking
> as requested by someone last year. Tested on 79c972.
>
> Signed-off-by: Don Fry <pcnet32@frontier.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] pcnet32: fix reallocation error
From: David Miller @ 2014-02-19 19:59 UTC (permalink / raw)
To: pcnet32; +Cc: netdev
In-Reply-To: <1392699466.4020.27.camel@Linux>
From: Don Fry <pcnet32@frontier.com>
Date: Mon, 17 Feb 2014 20:57:46 -0800
> pcnet32_realloc_rx_ring() only worked on the first log2 number of
> entries in the receive ring instead of the all the entries.
> Replaced "1 << size" with more descriptive variable.
> This is my original bug from 2006. Found while testing another problem.
> Tested on 79C972 and 79C976.
>
> Signed-off-by: Don Fry <pcnet32@frontier.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] unix: add read side socket memory accounting for dgram sockets
From: David Miller @ 2014-02-19 19:49 UTC (permalink / raw)
To: hannes; +Cc: netdev, yannick, eric.dumazet, xiyou.wangcong, dan
In-Reply-To: <20140217130353.GA22833@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 17 Feb 2014 14:03:53 +0100
> We still allocate dgram packets with sock_alloc_send_pskb, which now
> does normally not block if the socket has too many packets in flight.
It seems like it does to me, it does sock_wait_for_wmem(), right?
Or are you trying to say that usually this is not the point at which
we block, but rather it's when we check the peer's receive queue?
^ permalink raw reply
* Re: [PATCH net-next v5 1/9] xen-netback: Introduce TX grant map definitions
From: Zoltan Kiss @ 2014-02-19 19:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1392804319.23084.109.camel@kazak.uk.xensource.com>
On 19/02/14 10:05, Ian Campbell wrote:
> On Tue, 2014-02-18 at 20:36 +0000, Zoltan Kiss wrote:
>> On 18/02/14 17:06, Ian Campbell wrote:
>>> On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>>>> This patch contains the new definitions necessary for grant mapping.
>>>
>>> Is this just adding a bunch of (currently) unused functions? That's a
>>> slightly odd way to structure a series. They don't seem to be "generic
>>> helpers" or anything so it would be more normal to introduce these as
>>> they get used -- it's a bit hard to review them out of context.
>> I've created two patches because they are quite huge even now,
>> separately. Together they would be a ~500 line change. That was the best
>> I could figure out keeping in mind that bisect should work. But as I
>> wrote in the first email, I welcome other suggestions. If you and Wei
>> prefer this two patch in one big one, I merge them in the next version.
>
> I suppose it is hard to split a change like this up in a sensible way,
> but it is rather hard to review something which is split in two parts
> sensibly.
>
> If the combined patch too large to fit on the lists?
Well, it's ca. 30 kb, ~500 lines changed. I guess it's possible. It's up
to you and Wei, if you would like them to be merged, I can do that.
>>>
>>>> + struct xenvif,
>>>> + pending_tx_info[0]);
>>>> +
>>>> + spin_lock_irqsave(&vif->dealloc_lock, flags);
>>>> + do {
>>>> + pending_idx = ubuf->desc;
>>>> + ubuf = (struct ubuf_info *) ubuf->ctx;
>>>> + index = pending_index(vif->dealloc_prod);
>>>> + vif->dealloc_ring[index] = pending_idx;
>>>> + /* Sync with xenvif_tx_dealloc_action:
>>>> + * insert idx then incr producer.
>>>> + */
>>>> + smp_wmb();
>>>
>>> Is this really needed given that there is a lock held?
>> Yes, as the comment right above explains.
>
> My question is why do you need this sync if you are holding a lock, the
> comment doesn't tell me that. I suppose xenvif_tx_dealloc_action doesn't
> hold the dealloc_lock, but that is non-obvious from the names.
Ok, I'll clarify that in the comment.
>>>
>>>> + vif->dealloc_prod++;
>>>
>>> What happens if the dealloc ring becomes full, will this wrap and cause
>>> havoc?
>> Nope, if the dealloc ring is full, the value of the last increment won't
>> be used to index the dealloc ring again until some space made available.
>
> I don't follow -- what makes this the case?
The dealloc ring has the same size as the pending ring, and you can only
add slots to it which are already on the pending ring (the pending_idx
comes from ubuf->desc), as you are essentially free up slots here on the
pending ring.
So if the dealloc ring becomes full, vif->dealloc_prod -
vif->dealloc_cons will be 256, which would be bad. But the while loop
should exit here, as we shouldn't have any more pending slots. And if we
dealloc and create free pending slots in dealloc_action, dealloc_cons
will also advance.
>> Of course if something broke and we have more pending slots than tx ring
>> or dealloc slots then it can happen. Do you suggest a
>> BUG_ON(vif->dealloc_prod - vif->dealloc_cons >= MAX_PENDING_REQS)?
>
> A
> BUG_ON(space in dealloc ring < number of slots needed to dealloc this skb)
> would seem to be the right thing, if that really is the invariant the
> code is supposed to be implementing.
Not exactly, it means BUG_ON(number of slots to dealloc >
MAX_PENDING_REQS), and it should be at the end of the loop, without '='.
>>>> +static inline void xenvif_tx_dealloc_action(struct xenvif *vif)
>>>> +{
>>>> + struct gnttab_unmap_grant_ref *gop;
>>>> + pending_ring_idx_t dc, dp;
>>>> + u16 pending_idx, pending_idx_release[MAX_PENDING_REQS];
>>>> + unsigned int i = 0;
>>>> +
>>>> + dc = vif->dealloc_cons;
>>>> + gop = vif->tx_unmap_ops;
>>>> +
>>>> + /* Free up any grants we have finished using */
>>>> + do {
>>>> + dp = vif->dealloc_prod;
>>>> +
>>>> + /* Ensure we see all indices enqueued by all
>>>> + * xenvif_zerocopy_callback().
>>>> + */
>>>> + smp_rmb();
>>>> +
>>>> + while (dc != dp) {
>>>> + pending_idx =
>>>> + vif->dealloc_ring[pending_index(dc++)];
>>>> +
>>>> + /* Already unmapped? */
>>>> + if (vif->grant_tx_handle[pending_idx] ==
>>>> + NETBACK_INVALID_HANDLE) {
>>>> + netdev_err(vif->dev,
>>>> + "Trying to unmap invalid handle! "
>>>> + "pending_idx: %x\n", pending_idx);
>>>> + BUG();
>>>> + }
>>>> +
>>>> + pending_idx_release[gop-vif->tx_unmap_ops] =
>>>> + pending_idx;
>>>> + vif->pages_to_unmap[gop-vif->tx_unmap_ops] =
>>>> + vif->mmap_pages[pending_idx];
>>>> + gnttab_set_unmap_op(gop,
>>>> + idx_to_kaddr(vif, pending_idx),
>>>> + GNTMAP_host_map,
>>>> + vif->grant_tx_handle[pending_idx]);
>>>> + vif->grant_tx_handle[pending_idx] =
>>>> + NETBACK_INVALID_HANDLE;
>>>> + ++gop;
>>>
>>> Can we run out of space in the gop array?
>> No, unless the same thing happen as at my previous answer. BUG_ON() here
>> as well?
>
> Yes, or at the very least a comment explaining how/why gop is bounded
> elsewhere.
Ok, I'll do that.
>
>>>
>>>> + }
>>>> +
>>>> + } while (dp != vif->dealloc_prod);
>>>> +
>>>> + vif->dealloc_cons = dc;
>>>
>>> No barrier here?
>> dealloc_cons only used in the dealloc_thread. dealloc_prod is used by
>> the callback and the thread as well, that's why we need mb() in
>> previous. Btw. this function comes from classic's net_tx_action_dealloc
>
> Is this code close enough to that code architecturally that you can
> infer correctness due to that though?
Nope, I've just mentioned it because knowing that old code can help to
understand this new, as their logic is very similar some places, like here.
> So long as you have considered the barrier semantics in the context of
> the current code and you think it is correct to not have one here then
> I'm ok. But if you have just assumed it is OK because some older code
> didn't have it then I'll have to ask you to consider it again...
Nope, as I mentioned above, dealloc_cons only accessed in that funcion,
from the same thread. Dealloc_prod is written in the callback and read
out here, that's why we need the barrier there.
>
>>>> + netdev_err(vif->dev,
>>>> + " host_addr: %llx handle: %x status: %d\n",
>>>> + gop[i].host_addr,
>>>> + gop[i].handle,
>>>> + gop[i].status);
>>>> + }
>>>> + BUG();
>>>> + }
>>>> + }
>>>> +
>>>> + for (i = 0; i < gop - vif->tx_unmap_ops; ++i)
>>>> + xenvif_idx_release(vif, pending_idx_release[i],
>>>> + XEN_NETIF_RSP_OKAY);
>>>> +}
>>>> +
>>>> +
>>>> /* Called after netfront has transmitted */
>>>> int xenvif_tx_action(struct xenvif *vif, int budget)
>>>> {
>>>> @@ -1678,6 +1793,25 @@ static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
>>>> vif->mmap_pages[pending_idx] = NULL;
>>>> }
>>>>
>>>> +void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx)
>>>
>>> This is a single shot version of the batched xenvif_tx_dealloc_action
>>> version? Why not just enqueue the idx to be unmapped later?
>> This is called only from the NAPI instance. Using the dealloc ring
>> require synchronization with the callback which can increase lock
>> contention. On the other hand, if the guest sends small packets
>> (<PAGE_SIZE), the TLB flushing can cause performance penalty.
>
> Right. When/How often is this called from the NAPI instance?
When grant mapping error detected in xenvif_tx_check_gop, and if a
packet smaller than PKT_PROT_LEN is sent. The latter would be removed if
we will grant copy such packets entirely.
> Is the locking contention from this case so severe that it out weighs
> the benefits of batching the unmaps? That would surprise me. After all
> the locking contention is there for the zerocopy_callback case too
>
>> The above
>> mentioned upcoming patch which gntcopy the header can prevent that
>
> So this is only called when doing the pull-up to the linear area?
Yes, as mentioned above.
Zoli
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Eric Dumazet @ 2014-02-19 19:46 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Florian Westphal, David Miller, netdev
In-Reply-To: <20140219193038.GC1179@order.stressinduktion.org>
On Wed, 2014-02-19 at 20:30 +0100, Hannes Frederic Sowa wrote:
> NET_STATS only use 32 bit counter and thus need not be protected with a
> seqlock on 32 bit platforms. As such, it does not matter, but e.g. the IP
> counter are prone to deadlocks if used with wrong postfix because of 64 bit
> counter thus protected by seqlock.
>
> A pitty that the _STATS_BH postfixes have the opposite meaning of the bottom
> _bh postfixes.
>
> Basically always safe is _STATS and if we are sure we can omit the bh disable
> call because we only call the function from bh, we can use _STATS_BH calls.
Using __this_cpu_inc() is not safe in preemptable contexts.
Sure, x86 doesn't care, but other arches might.
Fortunately LINUX_MIB_TCPSPURIOUS_RTX_HOSTQUEUES can be incremented
only for a retransmit, and they should always happen from BH.
Better avoid the confusion for this ultra rare case, I'll send a patch.
^ permalink raw reply
* Re: [ovs-dev] [PATCH net-next] openvswitch: Use ether_addr_copy
From: Pravin Shelar @ 2014-02-19 19:32 UTC (permalink / raw)
To: David Miller; +Cc: joe, dev@openvswitch.org, netdev, LKML
In-Reply-To: <20140218.181507.1046967430290052114.davem@davemloft.net>
Jesse is on vacation. So I applied it to ovs master.
Thanks.
On Tue, Feb 18, 2014 at 3:15 PM, David Miller <davem@davemloft.net> wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 18 Feb 2014 11:15:45 -0800
>
>> It's slightly smaller/faster for some architectures.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>
> I'll let Jesse take this via his tree, thanks Joe.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Hannes Frederic Sowa @ 2014-02-19 19:32 UTC (permalink / raw)
To: Florian Westphal, Eric Dumazet, David Miller, netdev
In-Reply-To: <20140219193038.GC1179@order.stressinduktion.org>
Sorry...
On Wed, Feb 19, 2014 at 08:30:38PM +0100, Hannes Frederic Sowa wrote:
> NET_STATS only use 32 bit counter and thus need not be protected with a
> seqlock on 32 bit platforms. As such, it does not matter, but e.g. the IP
> counter are prone to deadlocks if used with wrong postfix because of 64 bit
> counter thus protected by seqlock.
>
> A pitty that the _STATS_BH postfixes have the opposite meaning of the bottom
s/bottom$/locking/
> _bh postfixes.
>
> Basically always safe is _STATS and if we are sure we can omit the bh disable
> call because we only call the function from bh, we can use _STATS_BH calls.
Should read mails again before sending. ;)
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Hannes Frederic Sowa @ 2014-02-19 19:30 UTC (permalink / raw)
To: Florian Westphal; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <20140219191831.GA7119@breakpoint.cc>
On Wed, Feb 19, 2014 at 08:18:31PM +0100, Florian Westphal wrote:
> Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> > On Wed, Feb 19, 2014 at 10:49:47AM -0800, Eric Dumazet wrote:
> > > On Wed, 2014-02-19 at 13:17 -0500, David Miller wrote:
> > > > From: Florian Westphal <fw@strlen.de>
> > > > Date: Mon, 17 Feb 2014 22:57:48 +0100
> > > >
> > > > > Three counters are added:
> > > > > - one to track when we went from non-zero to zero window
> > > > > - one to track the reverse
> > > > > - one counter incremented when we want to announce zero window.
> > > > >
> > > > > The latter is added because it can show cases where we want to close the
> > > > > window but can't because we would shrink window.
> > > > >
> > > > > Suggested-by: Eric Dumazet <edumazet@google.com>
> > > > > Signed-off-by: Florian Westphal <fw@strlen.de>
> > > > > ---
> > > > > Eric, is this what you had in mind?
> > > > >
> > > > > I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> > > > > scenario and, as expected, only TCPWANTZEROWINDOW increases.
> > > >
> > > > Eric, ping?
> > >
> > > Thanks, I missed this patch. Let me think about it, thanks !
> >
> > We need NET_INC_STATS instead of NET_INC_STATS_BH, no?
>
> sure, I can send v2 but I'll wait for (n)ack from Eric first
> before considering it.
>
> tcp_transmit_skb (caller of tcp_select_window) also uses _BH
> which is why it ended up in tcp_select_window.
NET_STATS only use 32 bit counter and thus need not be protected with a
seqlock on 32 bit platforms. As such, it does not matter, but e.g. the IP
counter are prone to deadlocks if used with wrong postfix because of 64 bit
counter thus protected by seqlock.
A pitty that the _STATS_BH postfixes have the opposite meaning of the bottom
_bh postfixes.
Basically always safe is _STATS and if we are sure we can omit the bh disable
call because we only call the function from bh, we can use _STATS_BH calls.
Greetings,
Hannnes
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Eric Dumazet @ 2014-02-19 19:27 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20140219191831.GA7119@breakpoint.cc>
On Wed, 2014-02-19 at 20:18 +0100, Florian Westphal wrote:
> sure, I can send v2 but I'll wait for (n)ack from Eric first
> before considering it.
>
> tcp_transmit_skb (caller of tcp_select_window) also uses _BH
> which is why it ended up in tcp_select_window.
Yes, it seems the NET_INC_STATS_BH() in tcp_transmit_skb() should really
be a NET_INC_STATS(), even if it currently doesn't matter, even on 32bit
arches.
^ permalink raw reply
* Re: [PATCH net] xen-netfront: reset skb network header before checksum
From: Sander Eikelenboom @ 2014-02-19 19:25 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, Konrad Rzeszutek Wilk, Paul Durrant
In-Reply-To: <1392835714-26480-1-git-send-email-wei.liu2@citrix.com>
Wednesday, February 19, 2014, 7:48:34 PM, you wrote:
> In ed1f50c3a ("net: add skb_checksum_setup") we introduced some checksum
> functions in core driver. Subsequent change b5cf66cd1 ("xen-netfront:
> use new skb_checksum_setup function") made use of those functions to
> replace its own implementation.
> However with that change netfront is broken. It sees a lot of checksum
> error. That's because its own implementation of checksum function was a
> bit hacky (dereferencing skb->data directly) while the new function was
> implemented using ip_hdr(). The network header is not reset before skb
> is passed to the new function. When the new function tries to do its
> job, it's confused and reports error.
> The fix is simple, we need to reset network header before passing skb to
> checksum function. Netback is not affected as it already does the right
> thing.
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> ---
> drivers/net/xen-netfront.c | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index ff04d4f..95041b6 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -907,6 +907,7 @@ static int handle_incoming_queue(struct net_device *dev,
>
> /* Ethernet work: Delayed to here as it peeks the header. */
> skb->protocol = eth_type_trans(skb, dev);
> + skb_reset_network_header(skb);
>
> if (checksum_setup(dev, skb)) {
> kfree_skb(skb);
Ah that also explains why ICMP was not affected :-)
Just tested and this patch indeed fixes my problem, so:
Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Thanks Wei !
--
Sander
^ permalink raw reply
* Re: [PATCH net-next v5 1/9] xen-netback: Introduce TX grant map definitions
From: Zoltan Kiss @ 2014-02-19 19:19 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1392744286.23084.52.camel@kazak.uk.xensource.com>
On 18/02/14 17:24, Ian Campbell wrote:
> On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>>
>> + spinlock_t dealloc_lock;
>> + spinlock_t response_lock;
>
> Please add comments to both of these describing what bits of the
> datastructure they are locking.
>
> You might find it is clearer to group the locks and the things they
> protect together rather than grouping the locks together.
Ok, I'll give more description here. The response_lock is actually quite
relevant to be here, but indeed that's not obvious, I'll explain that as
well.
Zoli
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Florian Westphal @ 2014-02-19 19:18 UTC (permalink / raw)
To: Eric Dumazet, David Miller, netdev
In-Reply-To: <20140219185949.GA1179@order.stressinduktion.org>
Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> On Wed, Feb 19, 2014 at 10:49:47AM -0800, Eric Dumazet wrote:
> > On Wed, 2014-02-19 at 13:17 -0500, David Miller wrote:
> > > From: Florian Westphal <fw@strlen.de>
> > > Date: Mon, 17 Feb 2014 22:57:48 +0100
> > >
> > > > Three counters are added:
> > > > - one to track when we went from non-zero to zero window
> > > > - one to track the reverse
> > > > - one counter incremented when we want to announce zero window.
> > > >
> > > > The latter is added because it can show cases where we want to close the
> > > > window but can't because we would shrink window.
> > > >
> > > > Suggested-by: Eric Dumazet <edumazet@google.com>
> > > > Signed-off-by: Florian Westphal <fw@strlen.de>
> > > > ---
> > > > Eric, is this what you had in mind?
> > > >
> > > > I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> > > > scenario and, as expected, only TCPWANTZEROWINDOW increases.
> > >
> > > Eric, ping?
> >
> > Thanks, I missed this patch. Let me think about it, thanks !
>
> We need NET_INC_STATS instead of NET_INC_STATS_BH, no?
sure, I can send v2 but I'll wait for (n)ack from Eric first
before considering it.
tcp_transmit_skb (caller of tcp_select_window) also uses _BH
which is why it ended up in tcp_select_window.
^ permalink raw reply
* Re: [RFC v2 2/4] net: enables interface option to skip IP
From: Zoltan Kiss @ 2014-02-19 19:13 UTC (permalink / raw)
To: Luis R. Rodriguez, Dan Williams
Cc: netdev@vger.kernel.org, xen-devel, kvm,
linux-kernel@vger.kernel.org, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <CAB=NE6VpUqwNNY4pgbS6du2VsZ6dH0TzQYXmiw6GGN-EiOsV6g@mail.gmail.com>
On 19/02/14 17:20, Luis R. Rodriguez wrote:
> On Wed, Feb 19, 2014 at 8:45 AM, Dan Williams <dcbw@redhat.com> wrote:
>> On Tue, 2014-02-18 at 13:19 -0800, Luis R. Rodriguez wrote:
>>> On Mon, Feb 17, 2014 at 12:23 PM, Dan Williams <dcbw@redhat.com> wrote:
>>>> On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
>>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>>
>>>>> Some interfaces do not need to have any IPv4 or IPv6
>>>>> addresses, so enable an option to specify this. One
>>>>> example where this is observed are virtualization
>>>>> backend interfaces which just use the net_device
>>>>> constructs to help with their respective frontends.
>>>>>
>>>>> This should optimize boot time and complexity on
>>>>> virtualization environments for each backend interface
>>>>> while also avoiding triggering SLAAC and DAD, which is
>>>>> simply pointless for these type of interfaces.
>>>>
>>>> Would it not be better/cleaner to use disable_ipv6 and then add a
>>>> disable_ipv4 sysctl, then use those with that interface?
>>>
>>> Sure, but note that the both disable_ipv6 and accept_dada sysctl
>>> parameters are global. ipv4 and ipv6 interfaces are created upon
>>> NETDEVICE_REGISTER, which will get triggered when a driver calls
>>> register_netdev(). The goal of this patch was to enable an early
>>> optimization for drivers that have no need ever for ipv4 or ipv6
>>> interfaces.
>>
>> Each interface gets override sysctls too though, eg:
>>
>> /proc/sys/net/ipv6/conf/enp0s25/disable_ipv6
>
> I hadn't seen those, thanks!
>
>> which is the one I meant; you're obviously right that the global ones
>> aren't what you want here. But the specific ones should be suitable?
>
> Under the approach Stephen mentioned by first ensuring the interface
> is down yes. There's one use case I can consider to still want the
> patch though, more on that below.
>
>> If you set that on a per-interface basis, then you'll get EPERM or
>> something whenever you try to add IPv6 addresses or do IPv6 routing.
>
> Neat, thanks.
>
>>> Zoltan has noted though some use cases of IPv4 or IPv6 addresses on
>>> backends though, as such this is no longer applicable as a
>>> requirement. The ipv4 sysctl however still seems like a reasonable
>>> approach to enable optimizations of the network in topologies where
>>> its known we won't need them but -- we'd need to consider a much more
>>> granular solution, not just global as it is now for disable_ipv6, and
>>> we'd also have to figure out a clean way to do this to not incur the
>>> cost of early address interface addition upon register_netdev().
>>>
>>> Given that we have a use case for ipv4 and ipv6 addresses on
>>> xen-netback we no longer have an immediate use case for such early
>>> optimization primitives though, so I'll drop this.
>>>
>>>> The IFF_SKIP_IP seems to duplicate at least part of what disable_ipv6 is
>>>> already doing.
>>>
>>> disable_ipv6 is global, the goal was to make this granular and skip
>>> the cost upon early boot, but its been clarified we don't need this.
>>
>> Like Stephen says, you need to make sure you set them before IFF_UP, but
>> beyond that, wouldn't the interface-specific sysctls work?
>
> Yeah that'll do it, unless there is a measurable run time benefit cost
> to never even add these in the first place. Consider a host with tons
> of guests, not sure how many is 'a lot' these days. One would have to
> measure the cost of reducing the amount of time it takes to boot these
> up. As discussed in the other threads though there *is* some use cases
> of assigning IPv4 or IPv6 addresses to the backend interfaces though:
> routing them (although its unclear to me if iptables can be used
> instead, Zoltan?).
Not with OVS, it steals the packet before netfilter hooks.
Zoli
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Hannes Frederic Sowa @ 2014-02-19 19:06 UTC (permalink / raw)
To: Eric Dumazet, David Miller, fw, netdev
In-Reply-To: <20140219185949.GA1179@order.stressinduktion.org>
On Wed, Feb 19, 2014 at 07:59:49PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Feb 19, 2014 at 10:49:47AM -0800, Eric Dumazet wrote:
> > On Wed, 2014-02-19 at 13:17 -0500, David Miller wrote:
> > > From: Florian Westphal <fw@strlen.de>
> > > Date: Mon, 17 Feb 2014 22:57:48 +0100
> > >
> > > > Three counters are added:
> > > > - one to track when we went from non-zero to zero window
> > > > - one to track the reverse
> > > > - one counter incremented when we want to announce zero window.
> > > >
> > > > The latter is added because it can show cases where we want to close the
> > > > window but can't because we would shrink window.
> > > >
> > > > Suggested-by: Eric Dumazet <edumazet@google.com>
> > > > Signed-off-by: Florian Westphal <fw@strlen.de>
> > > > ---
> > > > Eric, is this what you had in mind?
> > > >
> > > > I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> > > > scenario and, as expected, only TCPWANTZEROWINDOW increases.
> > >
> > > Eric, ping?
> >
> > Thanks, I missed this patch. Let me think about it, thanks !
>
> We need NET_INC_STATS instead of NET_INC_STATS_BH, no?
Ok, not strictly needed but just to keep the style, as tcp_select_window can
be called from both, bh and process context.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Hannes Frederic Sowa @ 2014-02-19 18:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, fw, netdev
In-Reply-To: <1392835787.18849.11.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Feb 19, 2014 at 10:49:47AM -0800, Eric Dumazet wrote:
> On Wed, 2014-02-19 at 13:17 -0500, David Miller wrote:
> > From: Florian Westphal <fw@strlen.de>
> > Date: Mon, 17 Feb 2014 22:57:48 +0100
> >
> > > Three counters are added:
> > > - one to track when we went from non-zero to zero window
> > > - one to track the reverse
> > > - one counter incremented when we want to announce zero window.
> > >
> > > The latter is added because it can show cases where we want to close the
> > > window but can't because we would shrink window.
> > >
> > > Suggested-by: Eric Dumazet <edumazet@google.com>
> > > Signed-off-by: Florian Westphal <fw@strlen.de>
> > > ---
> > > Eric, is this what you had in mind?
> > >
> > > I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> > > scenario and, as expected, only TCPWANTZEROWINDOW increases.
> >
> > Eric, ping?
>
> Thanks, I missed this patch. Let me think about it, thanks !
We need NET_INC_STATS instead of NET_INC_STATS_BH, no?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Eric Dumazet @ 2014-02-19 18:49 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev
In-Reply-To: <20140219.131708.562226572566677127.davem@davemloft.net>
On Wed, 2014-02-19 at 13:17 -0500, David Miller wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Mon, 17 Feb 2014 22:57:48 +0100
>
> > Three counters are added:
> > - one to track when we went from non-zero to zero window
> > - one to track the reverse
> > - one counter incremented when we want to announce zero window.
> >
> > The latter is added because it can show cases where we want to close the
> > window but can't because we would shrink window.
> >
> > Suggested-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> > Eric, is this what you had in mind?
> >
> > I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> > scenario and, as expected, only TCPWANTZEROWINDOW increases.
>
> Eric, ping?
Thanks, I missed this patch. Let me think about it, thanks !
^ permalink raw reply
* [PATCH net] xen-netfront: reset skb network header before checksum
From: Wei Liu @ 2014-02-19 18:48 UTC (permalink / raw)
To: xen-devel, netdev; +Cc: linux, Wei Liu, Konrad Rzeszutek Wilk, Paul Durrant
In ed1f50c3a ("net: add skb_checksum_setup") we introduced some checksum
functions in core driver. Subsequent change b5cf66cd1 ("xen-netfront:
use new skb_checksum_setup function") made use of those functions to
replace its own implementation.
However with that change netfront is broken. It sees a lot of checksum
error. That's because its own implementation of checksum function was a
bit hacky (dereferencing skb->data directly) while the new function was
implemented using ip_hdr(). The network header is not reset before skb
is passed to the new function. When the new function tries to do its
job, it's confused and reports error.
The fix is simple, we need to reset network header before passing skb to
checksum function. Netback is not affected as it already does the right
thing.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ff04d4f..95041b6 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -907,6 +907,7 @@ static int handle_incoming_queue(struct net_device *dev,
/* Ethernet work: Delayed to here as it peeks the header. */
skb->protocol = eth_type_trans(skb, dev);
+ skb_reset_network_header(skb);
if (checksum_setup(dev, skb)) {
kfree_skb(skb);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/1] net: tcp: RTO restart
From: Bill Fink @ 2014-02-19 18:20 UTC (permalink / raw)
To: Per Hurtig
Cc: netdev, davem, edumazet, anna.brunstrom, apetlund, michawe,
ilpo.jarvinen
In-Reply-To: <20140218181205.GA7780@kau.se>
On Tue, 18 Feb 2014, Per Hurtig wrote:
> This patch implements the RTO restart modification described in
> http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-02
>
> RTO Restart's goal is to provide quicker loss recovery for segments lost in the
> end of a burst/connection. To accomplish this the algorithm adjusts the RTO
> value on each rearm of the retransmission timer to be exactly RTO ms after the
> earliest outstanding segment was sent. The offsetting against the earliest
> outstanding segment is not done by the regular rearm algorithm, which causes
> RTOs to occur, on average, after RTO+RTT ms.
>
> As a faster timeout is only beneficial in scenarios where fast retransmit/early
> retransmit cannot be triggered the algorithm will only kick in when there is a
> small amount of outstanding segments.
>
> The RTO Restart proposal is accepted as a working group item in the IETF TCP
> Maintenance and Minor Extensions (tcpm) TCP wg and is intended for experimental
> RFC status.
>
> Signed-off-by: Per Hurtig <per.hurtig@kau.se>
> ---
> include/net/tcp.h | 1 +
> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
> net/ipv4/tcp_input.c | 11 +++++++++++
> 3 files changed, 19 insertions(+)
This should also have a documentation update to ip-sysctl.txt.
A separate patch for the TCP(7) man page would also be useful
if the kernel patch is approved.
-Bill
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 56fc366..575e82a 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -278,6 +278,7 @@ extern int sysctl_tcp_slow_start_after_idle;
> extern int sysctl_tcp_thin_linear_timeouts;
> extern int sysctl_tcp_thin_dupack;
> extern int sysctl_tcp_early_retrans;
> +extern int sysctl_tcp_rto_restart;
> extern int sysctl_tcp_limit_output_bytes;
> extern int sysctl_tcp_challenge_ack_limit;
> extern unsigned int sysctl_tcp_notsent_lowat;
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index 44eba05..c605f4f 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -717,6 +717,13 @@ static struct ctl_table ipv4_table[] = {
> .extra2 = &four,
> },
> {
> + .procname = "tcp_rto_restart",
> + .data = &sysctl_tcp_rto_restart,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> + {
> .procname = "tcp_min_tso_segs",
> .data = &sysctl_tcp_min_tso_segs,
> .maxlen = sizeof(int),
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 227cba7..450ee30 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -98,6 +98,7 @@ int sysctl_tcp_thin_dupack __read_mostly;
>
> int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
> int sysctl_tcp_early_retrans __read_mostly = 3;
> +int sysctl_tcp_rto_restart __read_mostly = 1;
>
> #define FLAG_DATA 0x01 /* Incoming frame contained data. */
> #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
> @@ -2972,6 +2973,16 @@ void tcp_rearm_rto(struct sock *sk)
> */
> if (delta > 0)
> rto = delta;
> + } else if (icsk->icsk_pending == ICSK_TIME_RETRANS &&
> + sysctl_tcp_rto_restart &&
> + sk->sk_send_head == NULL &&
> + tp->packets_out < 4) {
> + struct sk_buff *skb = tcp_write_queue_head(sk);
> + const u32 rto_time_stamp = TCP_SKB_CB(skb)->when;
> + s32 delta = (s32)(tcp_time_stamp - rto_time_stamp);
> +
> + if (delta > 0)
> + rto -= delta;
> }
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, rto,
> TCP_RTO_MAX);
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: David Miller @ 2014-02-19 18:17 UTC (permalink / raw)
To: fw; +Cc: netdev, eric.dumazet
In-Reply-To: <1392674268-26005-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 17 Feb 2014 22:57:48 +0100
> Three counters are added:
> - one to track when we went from non-zero to zero window
> - one to track the reverse
> - one counter incremented when we want to announce zero window.
>
> The latter is added because it can show cases where we want to close the
> window but can't because we would shrink window.
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Eric, is this what you had in mind?
>
> I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
> scenario and, as expected, only TCPWANTZEROWINDOW increases.
Eric, ping?
^ permalink raw reply
* Re: [PATCH 0/6] Netfilter fixes for net
From: David Miller @ 2014-02-19 18:16 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1392810102-13877-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 19 Feb 2014 12:41:36 +0100
> The following patchset contains Netfilter fixes for your net tree,
> they are:
>
> * Fix nf_trace in nftables if XT_TRACE=n, from Florian Westphal.
>
> * Don't use the fast payload operation in nf_tables if the length is
> not power of 2 or it is not aligned, from Nikolay Aleksandrov.
>
> * Fix missing break statement the inet flavour of nft_reject, which
> results in evaluating IPv4 packets with the IPv6 evaluation routine,
> from Patrick McHardy.
>
> * Fix wrong kconfig symbol in nft_meta to match the routing realm,
> from Paul Bolle.
>
> * Allocate the NAT null binding when creating new conntracks via
> ctnetlink to avoid that several packets race at initializing the
> the conntrack NAT extension, original patch from Florian Westphal,
> revisited version from me.
>
> * Fix DNAT handling in the snmp NAT helper, the same handling was being
> done for SNAT and DNAT and 2.4 already contains that fix, from
> Francois-Xavier Le Bail.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
Pulled, thanks a lot Pablo.
^ permalink raw reply
* Re: [PATCH 1/1] net: tcp: RTO restart
From: Eric Dumazet @ 2014-02-19 18:01 UTC (permalink / raw)
To: Andreas Petlund
Cc: Per Hurtig, netdev, davem, edumazet, Anna Brunström,
Michael Welzl, ilpo.jarvinen
In-Reply-To: <50334B08-CD60-4C4C-9556-ACC758F75D7E@simula.no>
On Wed, 2014-02-19 at 18:17 +0100, Andreas Petlund wrote:
> I’ve applied and tested the patch on VMs with both 32 bit and 64 bit kernel.
>
> Acked-by: Andreas Petlund <apetlund@simula.no>
> Tested-by: Andreas Petlund <apetlund@simula.no>
Sure the patch applies, but what experimental results did you get ?
My concern is that TCP_SKB_CB(skb)->when doesn't account for sojourn
time in host queues (qdisc and device).
Note : Missing documentation for this new sysctl.
This patch certainly cannot be applied as is.
Thanks !
^ 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