* Re: WARNING in ip_recv_error
From: Willem de Bruijn @ 2018-05-20 23:13 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, DaeLyong Jeong, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag, Willem de Bruijn
In-Reply-To: <CAF=yD-+Ai35L2=dGZzpjYYavBmBGNFXd-q9ju93WrPuewnhELg@mail.gmail.com>
On Fri, May 18, 2018 at 2:59 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 2:46 PM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn
>> <willemdebruijn.kernel@gmail.com> wrote:
>>> On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn
>>> <willemdebruijn.kernel@gmail.com> wrote:
>>>> On Fri, May 18, 2018 at 11:44 AM, David Miller <davem@davemloft.net> wrote:
>>>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>>>> Date: Fri, 18 May 2018 08:30:43 -0700
>>>>>
>>>>>> We probably need to revert Willem patch (7ce875e5ecb8562fd44040f69bda96c999e38bbc)
>>>>>
>>>>> Is it really valid to reach ip_recv_err with an ipv6 socket?
>>>>
>>>> I guess the issue is that setsockopt IPV6_ADDRFORM is not an
>>>> atomic operation, so that the socket is neither fully ipv4 nor fully
>>>> ipv6 by the time it reaches ip_recv_error.
>>>>
>>>> sk->sk_socket->ops = &inet_dgram_ops;
>>>> < HERE >
>>>> sk->sk_family = PF_INET;
>>>>
>>>> Even calling inet_recv_error to demux would not necessarily help.
>>>>
>>>> Safest would be to look up by skb->protocol, similar to what
>>>> ipv6_recv_error does to handle v4-mapped-v6.
>>>>
>>>> Or to make that function safe with PF_INET and swap the order
>>>> of the above two operations.
>>>>
>>>> All sound needlessly complicated for this rare socket option, but
>>>> I don't have a better idea yet. Dropping on the floor is not nice,
>>>> either.
>>>
>>> Ensuring that ip_recv_error correctly handles packets from either
>>> socket and removing the warning should indeed be good.
>>>
>>> It is robust against v4-mapped packets from an AF_INET6 socket,
>>> but see caveat on reconnect below.
>>>
>>> The code between ipv6_recv_error for v4-mapped addresses and
>>> ip_recv_error is essentially the same, the main difference being
>>> whether to return network headers as sockaddr_in with SOL_IP
>>> or sockaddr_in6 with SOL_IPV6.
>>>
>>> There are very few other locations in the stack that explicitly test
>>> sk_family in this way and thus would be vulnerable to races with
>>> IPV6_ADDRFORM.
>>>
>>> I'm not sure whether it is possible for a udpv6 socket to queue a
>>> real ipv6 packet on the error queue, disconnect, connect to an
>>> ipv4 address, call IPV6_ADDRFORM and then call ip_recv_error
>>> on a true ipv6 packet. That would return buggy data, e.g., in
>>> msg_name.
>>
>> In do_ipv6_setsockopt IPV6_ADDRFORM we can test that the
>> error queue is empty, and then take its lock for the duration of the
>> operation.
>
> Actually, no reason to hold the lock. This setsockopt holds the socket
> lock, which connect would need, too. So testing that the queue
> is empty after testing that it is connected to a v4 address is
> sufficient to ensure that no ipv6 packets are queued for reception.
>
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 4d780c7f0130..a975d6311341 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -199,6 +199,11 @@ static int do_ipv6_setsockopt(struct sock *sk,
> int level, int optname,
>
> if (ipv6_only_sock(sk) ||
> !ipv6_addr_v4mapped(&sk->sk_v6_daddr)) {
> retv = -EADDRNOTAVAIL;
> break;
> }
>
> + if (!skb_queue_empty(&sk->sk_error_queue)) {
> + retv = -EBUSY;
> + break;
> + }
> +
> fl6_free_socklist(sk);
> __ipv6_sock_mc_close(sk);
>
> After this it should be safe to remove the warning in ip_recv_error.
Hmm.. nope.
This ensures that the socket cannot produce any new true v6 packets.
But it does not guarantee that they are not already in the system, e.g.
queued in tc, and will find their way to the error queue later.
We'll have to just be able to handle ipv6 packets in ip_recv_error.
Since IPV6_ADDRFORM is used to pass to legacy v4-only
processes and those likely are only confused by SOL_IPV6
error messages, it is probably best to just drop them and perhaps
WARN_ONCE.
^ permalink raw reply
* Re: WARNING in __static_key_slow_dec
From: Willem de Bruijn @ 2018-05-20 23:07 UTC (permalink / raw)
To: DaeRyong Jeong
Cc: David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag
In-Reply-To: <CAF=yD-+jS5BJKHEDp+K4fB41YnY1mR8ksVg98oWPJV=mG01pfg@mail.gmail.com>
>
> -static void sock_disable_timestamp(struct sock *sk, unsigned long flags)
> +static void sock_disable_timestamp(struct sock *sk, unsigned long flag)
> {
> - if (sk->sk_flags & flags) {
> - sk->sk_flags &= ~flags;
> - if (sock_needs_netstamp(sk) &&
> - !(sk->sk_flags & SK_FLAGS_TIMESTAMP))
> - net_disable_timestamp();
> - }
> + unsigned long prev;
> +
> + do {
> + prev = READ_ONCE(sk->sk_flags);
> +
> + if (!(prev & flag))
> + return;
> +
> + if (cmpxchg(&sk->sk_flags, prev, prev & ~flag) == prev)
> + break;
> + } while (1);
and this can just use set_mask_bits
^ permalink raw reply
* [PATCH net-next] mv88e6xxx: Fix uninitialized variable warning.
From: David Miller @ 2018-05-20 23:05 UTC (permalink / raw)
To: andrew; +Cc: netdev
In mv88e6xxx_probe(), ("np" or "pdata") might be an invariant
but GCC can't see that, therefore:
drivers/net/dsa/mv88e6xxx/chip.c: In function ‘mv88e6xxx_probe’:
drivers/net/dsa/mv88e6xxx/chip.c:4420:13: warning: ‘compat_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
chip->info = compat_info;
Actually, it should have warned on the "if (!compat_info)" test, but
whatever.
Explicitly initialize to NULL in the variable declaration to
deal with this.
Fixes: 877b7cb0b6f2 ("net: dsa: mv88e6xxx: Add minimal platform_data support")
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1fa1f820a437..12df00f593b7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4382,9 +4382,9 @@ static const void *pdata_device_get_match_data(struct device *dev)
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
{
struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data;
+ const struct mv88e6xxx_info *compat_info = NULL;
struct device *dev = &mdiodev->dev;
struct device_node *np = dev->of_node;
- const struct mv88e6xxx_info *compat_info;
struct mv88e6xxx_chip *chip;
int port;
int err;
--
2.17.0
^ permalink raw reply related
* Re: WARNING in __static_key_slow_dec
From: Willem de Bruijn @ 2018-05-20 23:04 UTC (permalink / raw)
To: DaeRyong Jeong
Cc: David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Network Development, LKML, Byoungyoung Lee, Kyungtae Kim,
bammanag
In-Reply-To: <CAF=yD-JbiE0W6pv77DUO0pYrJCYfgszm6zwCEfkv8HedvRfujQ@mail.gmail.com>
On Fri, May 18, 2018 at 4:30 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 18, 2018 at 4:03 AM, DaeRyong Jeong <threeearcat@gmail.com> wrote:
>> We report the crash: WARNING in __static_key_slow_dec
>>
>> This crash has been found in v4.8 using RaceFuzzer (a modified
>> version of Syzkaller), which we describe more at the end of this
>> report.
>> Even though v4.8 is the relatively old version, we did manual verification
>> and we think the bug still exists.
>> Our analysis shows that the race occurs when invoking two syscalls
>> concurrently, setsockopt() with optname SO_TIMESTAMPING and ioctl() with
>> cmd SIOCGSTAMPNS.
>>
>>
>> Diagnosis:
>> We think if timestamp was previously enabled with
>> SOCK_TIMESTAMPING_RX_SOFTWARE flag, the concurrent execution of
>> sock_disable_timestamp() and sock_enable_timestamp() causes the crash.
>>
>>
>> Thread interleaving:
>> (Assume sk->flag has the SOCK_TIMESTAMPING_RX_SOFTWARE flag by the
>> previous setsockopt() call with SO_TIMESTAMPING)
>>
>> CPU0 (sock_disable_timestamp()) CPU1 (sock_enable_timestamp())
>> ===== =====
>> (flag == 1UL << SOCK_TIMESTAMPING_RX_SOFTWARE) (flag == SOCK_TIMESTAMP)
>>
>> if (!sock_flag(sk, flag)) {
>> unsigned long previous_flags = sk->sk_flags;
>>
>> if (sk->sk_flags & flags) {
>> sk->sk_flags &= ~flags;
>> if (sock_needs_netstamp(sk) &&
>> !(sk->sk_flags & SK_FLAGS_TIMESTAMP))
>> net_disable_timestamp();
>> sock_set_flag(sk, flag);
>>
>> if (sock_needs_netstamp(sk) &&
>> !(previous_flags & SK_FLAGS_TIMESTAMP))
>> net_enable_timestamp();
>> /* Here, net_enable_timestamp() is not called because
>> * previous_flags has the SOCK_TIMESTAMPING_RX_SOFTWARE
>> * flag
>> */
>> /* After the race, sk->sk has the flag SOCK_TIMESTAMP, but
>> * net_enable_timestamp() is not called one more time.
>> * Consequently, when the socket is closed, __sk_destruct()
>> * calls net_disable_timestamp() that leads WARNING.
>> */
>
> Thanks for the detailed analysis.
>
> Indeed the updates to sk->sk_flags and calls to net_(dis|en)able_timestamp
> should happen atomically, but this is not the case. The setsockopt
> path holds the socket lock, but not all ioctl paths.
>
> Perhaps we can take lock_sock_fast in sock_get_timestamp and
> variants.
Some callers of sock_get_timestamp already hold the socket lock,
e.g., ax25_ioctl, so that is out.
There is some known non-determinism in this path. Callers of
sock_get_timestamp do not necessarily expect a valid sk_stamp
when they enable the timestamp, so that function can continue
to test sk_flags lockless.
net_enable_timestamp enables timestamping using a static_branch
and possibly a workqueue, so already does not complete synchronously
in the sock_enable_timestamp call.
The only requirement is that updates to sk_flags do not race. This
should be solvable with cmpxchg. The situation is slightly complicated
because sk_flags has two bits that may toggle timestamping. Only the
first bit set must trigger a call to net_enable_timestamp and only the
last bit cleared must call net_disable_timestamp.
Something like
-static bool sock_needs_netstamp(const struct sock *sk)
+static bool sock_needs_netstamp(const struct sock *sk, unsigned long flags)
{
switch (sk->sk_family) {
case AF_UNSPEC:
case AF_UNIX:
return false;
default:
- return true;
+ return (flags & SK_FLAGS_TIMESTAMP);
}
}
-static void sock_disable_timestamp(struct sock *sk, unsigned long flags)
+static void sock_disable_timestamp(struct sock *sk, unsigned long flag)
{
- if (sk->sk_flags & flags) {
- sk->sk_flags &= ~flags;
- if (sock_needs_netstamp(sk) &&
- !(sk->sk_flags & SK_FLAGS_TIMESTAMP))
- net_disable_timestamp();
- }
+ unsigned long prev;
+
+ do {
+ prev = READ_ONCE(sk->sk_flags);
+
+ if (!(prev & flag))
+ return;
+
+ if (cmpxchg(&sk->sk_flags, prev, prev & ~flag) == prev)
+ break;
+ } while (1);
+
+ /* disable only if this operation removed the last tstamp flag */
+ if (!sock_needs_netstamp(sk, prev & ~flag))
+ net_disable_timestamp();
}
and analogous for enable.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: b53: Extend platform data to include DSA ports
From: David Miller @ 2018-05-20 22:59 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180520155630.23432-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 20 May 2018 08:56:30 -0700
> The b53 driver already defines and internally uses platform data to let the
> glue drivers specify parameters such as the chip id. What we were missing was
> a way to tell the core DSA layer about the ports and their type.
>
> Place a dsa_chip_data structure at the beginning of b53_platform_data for
> dsa_register_switch() to access it. This does not require modifications to
> b53_common.c which will pass platform_data trough.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] Platform data support for mv88exxx
From: David Miller @ 2018-05-20 22:58 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, f.fainelli, netdev
In-Reply-To: <1526761895-15839-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 19 May 2018 22:31:32 +0200
> There are a few Intel based platforms making use of the mv88exxx.
> These don't easily have access to device tree in order to instantiate
> the switch driver. These patches allow the use of platform data to
> hold the configuration.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/3] sh_eth: fix typos/grammar
From: David Miller @ 2018-05-20 22:56 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <d47afee4-6fd5-af6d-885c-5b07996749fc@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sat, 19 May 2018 23:57:50 +0300
> Here's a set of 3 patches against DaveM's 'net-next.git' repo plus the R8A77980
> support patches posted earlier. They fix the comments typos/grammar and another
> typo in the EESR bit...
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/9] Misc. bug fixes and cleanup for HNS3 driver
From: David Miller @ 2018-05-20 22:56 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180519155323.68960-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Sat, 19 May 2018 16:53:14 +0100
> This patch-set presents miscellaneous bug fixes and cleanups found
> during internal review, system testing and cleanup.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun
From: Willem de Bruijn @ 2018-05-20 22:51 UTC (permalink / raw)
To: Jon Rosen
Cc: David S. Miller, Willem de Bruijn, Eric Dumazet, Kees Cook,
David Windsor, Rosen, Rami, Reshetova, Elena, Mike Maloney,
Benjamin Poirier, Thomas Gleixner, Greg Kroah-Hartman,
open list:NETWORKING [GENERAL], open list
In-Reply-To: <1526731655-10087-1-git-send-email-jrosen@cisco.com>
On Sat, May 19, 2018 at 8:07 AM, Jon Rosen <jrosen@cisco.com> wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry. Track ownership in a shadow
> ring structure to prevent other kernel threads from reusing the same
> entry before it's fully filled in, passed to user space, and then
> eventually passed back to the kernel for use with a new packet.
>
> Signed-off-by: Jon Rosen <jrosen@cisco.com>
> ---
>
> There is a bug in net/packet/af_packet.c:tpacket_rcv in how it manages
> the PACKET_RX_RING for versions TPACKET_V1 and TPACKET_V2. This bug makes
> it possible for multiple kernel threads to claim ownership of the same
> ring entry, corrupting the ring and the corresponding packet(s).
>
> These diffs are the second proposed solution, previous proposal was described
> in https://www.mail-archive.com/netdev@vger.kernel.org/msg227468.html
> subject [RFC PATCH] packet: mark ring entry as in-use inside spin_lock
> to prevent RX ring overrun
>
> Those diffs would have changed the binary interface and have broken certain
> applications. Consensus was that such a change would be inappropriate.
>
> These new diffs use a shadow ring in kernel space for tracking intermediate
> state of an entry and prevent more than one kernel thread from simultaneously
> allocating a ring entry. This avoids any impact to the binary interface
> between kernel and userspace but comes at the additional cost of requiring a
> second spin_lock when passing ownership of a ring entry to userspace.
>
> Jon Rosen (1):
> packet: track ring entry use using a shadow ring to prevent RX ring
> overrun
>
> net/packet/af_packet.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++
> net/packet/internal.h | 14 +++++++++++
> 2 files changed, 78 insertions(+)
>
> @@ -2383,7 +2412,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
> #endif
>
> if (po->tp_version <= TPACKET_V2) {
> + spin_lock(&sk->sk_receive_queue.lock);
> __packet_set_status(po, h.raw, status);
> + packet_rx_shadow_release(rx_shadow_ring_entry);
> + spin_unlock(&sk->sk_receive_queue.lock);
> +
> sk->sk_data_ready(sk);
Thanks for continuing to look at this. I spent some time on it last time
around but got stuck, too.
This version takes an extra spinlock in the hot path. That will be very
expensive. Once we need to accept that, we could opt for a simpler
implementation akin to the one discussed in the previous thread:
stash a value in tp_padding or similar while tp_status remains
TP_STATUS_KERNEL to signal ownership to concurrent kernel
threads. The issue previously was that that field could not atomically
be cleared together with __packet_set_status. This is no longer
an issue when holding the queue lock.
With a field like tp_padding, unlike tp_len, it is arguably also safe to
clear it after flipping status (userspace should treat it as undefined).
With v1 tpacket_hdr, no explicit padding field is defined but due to
TPACKET_HDRLEN alignment it exists on both 32 and 64 bit
platforms.
The danger with using padding is that a process may write to it
and cause deadlock, of course. There is no logical reason for doing
so.
^ permalink raw reply
* Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions
From: Marcelo Ricardo Leitner @ 2018-05-20 22:43 UTC (permalink / raw)
To: Or Gerlitz
Cc: Vlad Buslov, Linux Netdev List, David Miller, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, Pablo Neira Ayuso, kadlec,
Florian Westphal, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, keescook, Linux Kernel, netfilter-devel, coreteam,
Yevgeny Kliteynik
In-Reply-To: <CAJ3xEMji3Mjb7sWnZyqt2nYjQ9c8s6Ok8DVTSwVdGqS1EVOjtg@mail.gmail.com>
On Mon, May 21, 2018 at 12:40:54AM +0300, Or Gerlitz wrote:
> On Mon, May 21, 2018 at 12:33 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote:
> >> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
> >> >> Substitute calls to action insert function with calls to action insert
> >> >> unique function that warns if insertion overwrites index in idr.
> >> >
> >> > I know this patch may be gone on V2, but a general comment, please use
> >> > the function names themselves instead of a textualized version. I.e.,
> >> > s/action insert unique/tcf_idr_insert_unique/
> >>
> >> disagree. While doing reviews I found out that if I ask the developer
> >> to use higher
> >> level / descriptive language and specifically to avoid putting
> >> variable / function names in
> >> patch titles and change logs, the quality gets ++ big time, vs if the
> >> developer is allowed to say
> >>
> >> net/mlx5: Changed add_vovo_bobo()
> >>
> >> Added variable do_it_right to add_vovo_bobo(), now we are terribly good.
> >
> > In your example I agree that it is not helping and it is even allowing
> > such empty changelog, just as in the section I highlighted, the
> > descriptive language is also not helping IMHO.
> >
> > I had to read it 3 times to make sure I wasn't missing a modifier word
> > when comparing the two functions and well, it's just saying
> > "Substitute calls to foo function to bar function". I don't see how
> > the textualized version helps in this case while, at least in this
> > one, I would have visually recognized the function names way faster.
> >
> > Sounds like 2 bad examples for either approach.
>
> Properly written descriptive language is maybe harder to come up with
> (specifically for those of us who are not native english speakers, like me)
> but is more expressive and helpful for reviews and maintenance. Lets try
> to add Vlad to come up with the right higher language and not ask him to
> quote function and variable named.
Alright.
^ permalink raw reply
* Re: [PATCH net-next] r8169: fix network error on resume from suspend
From: David Miller @ 2018-05-20 22:39 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <aa718c92-294e-d489-5a09-79acdc9eedfe@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 19 May 2018 10:29:33 +0200
> This commit removed calls to rtl_set_rx_mode(). This is ok for the
> standard path if the link is brought up, however it breaks system
> resume from suspend. Link comes up but no network traffic.
>
> Meanwhile common code from rtl_hw_start_8169/8101/8168() was moved
> to rtl_hw_start(), therefore re-add the call to rtl_set_rx_mode()
> there.
>
> Due to adding this call we have to move definition of rtl_hw_start()
> after definition of rtl_set_rx_mode().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Fixes: 82d3ff6dd199 ("r8169: remove calls to rtl_set_rx_mode")
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] isdn: eicon: fix a missing-check bug
From: David Miller @ 2018-05-20 22:37 UTC (permalink / raw)
To: wang6495; +Cc: kjlu, mac, isdn, netdev, linux-kernel
In-Reply-To: <1526679228-1596-1-git-send-email-wang6495@umn.edu>
From: Wenwen Wang <wang6495@umn.edu>
Date: Fri, 18 May 2018 16:33:47 -0500
> In divasmain.c, the function divas_write() firstly invokes the function
> diva_xdi_open_adapter() to open the adapter that matches with the adapter
> number provided by the user, and then invokes the function diva_xdi_write()
> to perform the write operation using the matched adapter. The two functions
> diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
This doesn't even compile:
In file included from drivers/isdn/hardware/eicon/divasmain.c:30:
drivers/isdn/hardware/eicon/diva.h:23:18: error: unknown type name ‘diva_xdi_um_cfg_cmd_t’
int length, diva_xdi_um_cfg_cmd_t *msg,
^~~~~~~~~~~~~~~~~~~~~
drivers/isdn/hardware/eicon/diva.h:27:20: error: unknown type name ‘diva_xdi_um_cfg_cmd_t’
int length, diva_xdi_um_cfg_cmd_t *msg,
^~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCHv2 net-next] erspan: set bso bit based on mirrored packet's len
From: David Miller @ 2018-05-20 22:32 UTC (permalink / raw)
To: u9012063; +Cc: netdev, tobin
In-Reply-To: <1526697661-8958-1-git-send-email-u9012063@gmail.com>
From: William Tu <u9012063@gmail.com>
Date: Fri, 18 May 2018 19:41:01 -0700
> Before the patch, the erspan BSO bit (Bad/Short/Oversized) is not
> handled. BSO has 4 possible values:
> 00 --> Good frame with no error, or unknown integrity
> 11 --> Payload is a Bad Frame with CRC or Alignment Error
> 01 --> Payload is a Short Frame
> 10 --> Payload is an Oversized Frame
>
> Based the short/oversized definitions in RFC1757, the patch sets
> the bso bit based on the mirrored packet's size.
>
> Reported-by: Xiaoyan Jin <xiaoyanj@vmware.com>
> Signed-off-by: William Tu <u9012063@gmail.com>
> ---
> v1->v2
> Improve code comments, make enum erspan_bso clearer
Applied, thanks William.
^ permalink raw reply
* Re: pull request: bluetooth-next 2018-05-18
From: David Miller @ 2018-05-20 22:25 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20180518195105.GA15231@x1c.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Fri, 18 May 2018 22:51:05 +0300
> Here's the first bluetooth-next pull request for the 4.18 kernel:
>
> - Refactoring of the btbcm driver
> - New USB IDs for QCA_ROME and LiteOn controllers
> - Buffer overflow fix if the controller sends invalid advertising data length
> - Various cleanups & fixes for Qualcomm controllers
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thank you.
^ permalink raw reply
* Re: [net-next] Revert "ixgbe: release lock for the duration of ixgbe_suspend_close()"
From: David Miller @ 2018-05-20 22:23 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180518185830.23681-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 18 May 2018 11:58:30 -0700
> This reverts commit 6710f970d9979d8f03f6e292bb729b2ee1526d0e.
>
> Gotta love when developers have offline discussions, thinking everyone
> is reading their responses/dialog.
>
> The change had the potential for a number of race conditions on
> shutdown, which is why we are reverting the change.
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: qcom/emac: Allocate buffers from local node
From: David Miller @ 2018-05-20 22:23 UTC (permalink / raw)
To: hpuranik; +Cc: netdev, linux-kernel, timur
In-Reply-To: <1526614169-9586-1-git-send-email-hpuranik@codeaurora.org>
From: Hemanth Puranik <hpuranik@codeaurora.org>
Date: Fri, 18 May 2018 08:59:29 +0530
> Currently we use non-NUMA aware allocation for TPD and RRD buffers,
> this patch modifies to use NUMA friendly allocation.
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
> ---
> Change since v1:
> - Addressed comments related to ordering
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions
From: Or Gerlitz @ 2018-05-20 21:40 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Buslov, Linux Netdev List, David Miller, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, Pablo Neira Ayuso, kadlec,
Florian Westphal, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, keescook, Linux Kernel, netfilter-devel, coreteam,
Yevgeny Kliteynik
In-Reply-To: <20180520213349.GC26212@localhost.localdomain>
On Mon, May 21, 2018 at 12:33 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote:
>> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
>> >> Substitute calls to action insert function with calls to action insert
>> >> unique function that warns if insertion overwrites index in idr.
>> >
>> > I know this patch may be gone on V2, but a general comment, please use
>> > the function names themselves instead of a textualized version. I.e.,
>> > s/action insert unique/tcf_idr_insert_unique/
>>
>> disagree. While doing reviews I found out that if I ask the developer
>> to use higher
>> level / descriptive language and specifically to avoid putting
>> variable / function names in
>> patch titles and change logs, the quality gets ++ big time, vs if the
>> developer is allowed to say
>>
>> net/mlx5: Changed add_vovo_bobo()
>>
>> Added variable do_it_right to add_vovo_bobo(), now we are terribly good.
>
> In your example I agree that it is not helping and it is even allowing
> such empty changelog, just as in the section I highlighted, the
> descriptive language is also not helping IMHO.
>
> I had to read it 3 times to make sure I wasn't missing a modifier word
> when comparing the two functions and well, it's just saying
> "Substitute calls to foo function to bar function". I don't see how
> the textualized version helps in this case while, at least in this
> one, I would have visually recognized the function names way faster.
>
> Sounds like 2 bad examples for either approach.
Properly written descriptive language is maybe harder to come up with
(specifically for those of us who are not native english speakers, like me)
but is more expressive and helpful for reviews and maintenance. Lets try
to add Vlad to come up with the right higher language and not ask him to
quote function and variable named.
^ permalink raw reply
* Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions
From: Marcelo Ricardo Leitner @ 2018-05-20 21:33 UTC (permalink / raw)
To: Or Gerlitz
Cc: Vlad Buslov, Linux Netdev List, David Miller, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, Pablo Neira Ayuso, kadlec,
Florian Westphal, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, keescook, Linux Kernel, netfilter-devel, coreteam,
Yevgeny Kliteynik
In-Reply-To: <CAJ3xEMhNC91YFcy-Qi+vk--DwSZ5wZdYMNp=-7mHUk9oag9HSg@mail.gmail.com>
On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote:
> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
> >> Substitute calls to action insert function with calls to action insert
> >> unique function that warns if insertion overwrites index in idr.
> >
> > I know this patch may be gone on V2, but a general comment, please use
> > the function names themselves instead of a textualized version. I.e.,
> > s/action insert unique/tcf_idr_insert_unique/
>
> disagree. While doing reviews I found out that if I ask the developer
> to use higher
> level / descriptive language and specifically to avoid putting
> variable / function names in
> patch titles and change logs, the quality gets ++ big time, vs if the
> developer is allowed to say
>
> net/mlx5: Changed add_vovo_bobo()
>
> Added variable do_it_right to add_vovo_bobo(), now we are terribly good.
In your example I agree that it is not helping and it is even allowing
such empty changelog, just as in the section I highlighted, the
descriptive language is also not helping IMHO.
I had to read it 3 times to make sure I wasn't missing a modifier word
when comparing the two functions and well, it's just saying
"Substitute calls to foo function to bar function". I don't see how
the textualized version helps in this case while, at least in this
one, I would have visually recognized the function names way faster.
Sounds like 2 bad examples for either approach.
^ permalink raw reply
* Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions
From: Or Gerlitz @ 2018-05-20 21:13 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Buslov, Linux Netdev List, David Miller, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, Pablo Neira Ayuso, kadlec,
Florian Westphal, Alexei Starovoitov, Daniel Borkmann,
Eric Dumazet, keescook, Linux Kernel, netfilter-devel, coreteam,
Yevgeny Kliteynik
In-Reply-To: <20180519222028.GF5488@localhost.localdomain>
On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
>> Substitute calls to action insert function with calls to action insert
>> unique function that warns if insertion overwrites index in idr.
>
> I know this patch may be gone on V2, but a general comment, please use
> the function names themselves instead of a textualized version. I.e.,
> s/action insert unique/tcf_idr_insert_unique/
disagree. While doing reviews I found out that if I ask the developer
to use higher
level / descriptive language and specifically to avoid putting
variable / function names in
patch titles and change logs, the quality gets ++ big time, vs if the
developer is allowed to say
net/mlx5: Changed add_vovo_bobo()
Added variable do_it_right to add_vovo_bobo(), now we are terribly good.
^ permalink raw reply
* Re: [PATCH net-next] sctp: add support for SCTP_REUSE_PORT sockopt
From: Tom Herbert @ 2018-05-20 19:44 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp @ vger . kernel . org,
Marcelo Ricardo Leitner, Neil Horman, David S. Miller
In-Reply-To: <be8e672439406e6c8b838321d63aa109b9620f4c.1526715880.git.lucien.xin@gmail.com>
On Sat, May 19, 2018 at 12:44 AM, Xin Long <lucien.xin@gmail.com> wrote:
> This feature is actually already supported by sk->sk_reuse which can be
> set by SO_REUSEADDR. But it's not working exactly as RFC6458 demands in
> section 8.1.27, like:
>
> - This option only supports one-to-one style SCTP sockets
> - This socket option must not be used after calling bind()
> or sctp_bindx().
>
> Besides, SCTP_REUSE_PORT sockopt should be provided for user's programs.
> Otherwise, the programs with SCTP_REUSE_PORT from other systems will not
> work in linux.
>
How is this different than SO_REUSEPORT?
> This patch reuses sk->sk_reuse and works pretty much as SO_REUSEADDR,
> just with some extra setup limitations that are neeeded when it is being
> enabled.
>
> "It should be noted that the behavior of the socket-level socket option
> to reuse ports and/or addresses for SCTP sockets is unspecified", so it
> leaves SO_REUSEADDR as is for the compatibility.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/uapi/linux/sctp.h | 1 +
> net/sctp/socket.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index b64d583..c02986a 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -100,6 +100,7 @@ typedef __s32 sctp_assoc_t;
> #define SCTP_RECVNXTINFO 33
> #define SCTP_DEFAULT_SNDINFO 34
> #define SCTP_AUTH_DEACTIVATE_KEY 35
> +#define SCTP_REUSE_PORT 36
>
> /* Internal Socket Options. Some of the sctp library functions are
> * implemented using these socket options.
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1b4593b..8dfcc79 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4170,6 +4170,28 @@ static int sctp_setsockopt_interleaving_supported(struct sock *sk,
> return retval;
> }
>
> +static int sctp_setsockopt_reuse_port(struct sock *sk, char __user *optval,
> + unsigned int optlen)
> +{
> + int val;
> +
> + if (!sctp_style(sk, TCP))
> + return -EOPNOTSUPP;
> +
> + if (sctp_sk(sk)->ep->base.bind_addr.port)
> + return -EFAULT;
> +
> + if (optlen < sizeof(int))
> + return -EINVAL;
> +
> + if (get_user(val, (int __user *)optval))
> + return -EFAULT;
> +
> + sk->sk_reuse = val ? SK_CAN_REUSE : SK_NO_REUSE;
> +
> + return 0;
> +}
> +
> /* API 6.2 setsockopt(), getsockopt()
> *
> * Applications use setsockopt() and getsockopt() to set or retrieve
> @@ -4364,6 +4386,9 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
> retval = sctp_setsockopt_interleaving_supported(sk, optval,
> optlen);
> break;
> + case SCTP_REUSE_PORT:
> + retval = sctp_setsockopt_reuse_port(sk, optval, optlen);
> + break;
> default:
> retval = -ENOPROTOOPT;
> break;
> @@ -7175,6 +7200,26 @@ static int sctp_getsockopt_interleaving_supported(struct sock *sk, int len,
> return retval;
> }
>
> +static int sctp_getsockopt_reuse_port(struct sock *sk, int len,
> + char __user *optval,
> + int __user *optlen)
> +{
> + int val = 0;
> +
> + if (len < sizeof(int))
> + return -EINVAL;
> +
> + len = sizeof(int);
> + if (sk->sk_reuse != SK_NO_REUSE)
> + val = 1;
> + if (put_user(len, optlen))
> + return -EFAULT;
> + if (copy_to_user(optval, &val, len))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int sctp_getsockopt(struct sock *sk, int level, int optname,
> char __user *optval, int __user *optlen)
> {
> @@ -7370,6 +7415,9 @@ static int sctp_getsockopt(struct sock *sk, int level, int optname,
> retval = sctp_getsockopt_interleaving_supported(sk, len, optval,
> optlen);
> break;
> + case SCTP_REUSE_PORT:
> + retval = sctp_getsockopt_reuse_port(sk, len, optval, optlen);
> + break;
> default:
> retval = -ENOPROTOOPT;
> break;
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH 09/14] net: sched: don't release reference on action overwrite
From: Vlad Buslov @ 2018-05-20 18:42 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: netdev, davem, jhs, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook, linux-kernel, netfilter-devel,
coreteam, kliteyn
In-Reply-To: <20180519215246.GD5488@localhost.localdomain>
On Sat 19 May 2018 at 21:52, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Mon, May 14, 2018 at 05:27:10PM +0300, Vlad Buslov wrote:
>> Return from action init function with reference to action taken,
>> even when overwriting existing action.
>
> Isn't this patch necessary before patch 7, to not break things up?
> AFAICU after patchset 7 it assumes the action init function is already
> behaving like this.
I have re-split these patches for V2.
^ permalink raw reply
* Re: [PATCH 10/32] aio: implement IOCB_CMD_POLL
From: Christoph Hellwig @ 2018-05-20 17:32 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Avi Kivity, linux-aio, linux-fsdevel, netdev,
linux-api, linux-kernel
In-Reply-To: <20180520073332.GA30522@ZenIV.linux.org.uk>
On Sun, May 20, 2018 at 08:33:39AM +0100, Al Viro wrote:
> > ... get buggered on attempt to dereference a pointer fetched from freed and
> > reused object.
>
> FWIW, how painful would it be to pull the following trick:
> * insert into wait queue under ->ctx_lock
> * have wakeup do schedule_work() with aio_complete() done from that
> * have ->ki_cancel() grab queue lock, remove from queue and use
> the same schedule_work()
>
> That way you'd get ->ki_cancel() with the same semantics as originally for
> everything - "ask politely to finish ASAP", and called in the same locking
> environment for everyone - under ->ctx_lock, that is. queue lock nests
> inside ->ctx_lock; no magical flags, etc.
>
> The cost is schedule_work() for each async poll-related completion as you
> have for fsync. I don't know whether that's too costly or not; it certainly
> simplifies the things, but whether it's OK performance-wise...
I think it is doable:
http://git.infradead.org/users/hch/vfs.git/commitdiff/c441130e405465268ea10c9ddd5639c155f779e8
downside is that sizeof(struct aio_kiocb) grows a bit.
For the completion performance we can use a spin_trylock to still avoid
the context switch for the common case:
http://git.infradead.org/users/hch/vfs.git/commitdiff/6cc1827afbea87c52fe425cf533bfcf5f3308163
^ permalink raw reply
* [PATCH 2/2] net: fec: Add a SPDX identifier
From: Fabio Estevam @ 2018-05-20 16:55 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, netdev, Fabio Estevam
In-Reply-To: <1526835319-17408-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Currently there is no license information in the header of
this file.
The MODULE_LICENSE field contains ("GPL"), which means
GNU Public License v2 or later, so add a corresponding
SPDX license identifier.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/net/ethernet/freescale/fec_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index f3e43db..1625b74 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
* Fast Ethernet Controller (FEC) driver for Motorola MPC8xx.
* Copyright (c) 1997 Dan Malek (dmalek@jlc.net)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] net: fec: ptp: Switch to SPDX identifier
From: Fabio Estevam @ 2018-05-20 16:55 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, netdev, Fabio Estevam
From: Fabio Estevam <fabio.estevam@nxp.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/net/ethernet/freescale/fec_ptp.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
index f814397..43d9732 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -1,20 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Fast Ethernet Controller (ENET) PTP driver for MX6x.
*
* Copyright (C) 2012 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
--
2.7.4
^ permalink raw reply related
* Re: [RFC V4 PATCH 0/8] Packed ring layout for vhost
From: Wei Xu @ 2018-05-20 16:25 UTC (permalink / raw)
To: Jason Wang
Cc: mst, kvm, virtualization, netdev, linux-kernel, jfreimann,
tiwei.bie
In-Reply-To: <1526473941-16199-1-git-send-email-jasowang@redhat.com>
On Wed, May 16, 2018 at 08:32:13PM +0800, Jason Wang wrote:
> Hi all:
>
> This RFC implement packed ring layout. The code were tested with
> Tiwei's RFC V3 ahttps://lkml.org/lkml/2018/4/25/34. Some fixups and
> tweaks were needed on top of Tiwei's code to make it run for event
> index.
Could you please show the change based on Tiwei's code to easy other's
test?
>
> Pktgen reports about 20% improvement on PPS (event index is off). More
> testing is ongoing.
>
> Notes for tester:
>
> - Start from this version, vhost need qemu co-operation to work
> correctly. Or you can comment out the packed specific code for
> GET/SET_VRING_BASE.
Do you mean the code in vhost_virtqueue_start/stop? Both Tiwei's and your v3
work fortunately correctly which should be avoided since the ring should be
definitely different.
Wei
>
> Changes from V3:
> - Fix math on event idx checking
> - Sync last avail wrap counter through GET/SET_VRING_BASE
> - remove desc_event prefix in the driver/device structure
>
> Changes from V2:
> - do not use & in checking desc_event_flags
> - off should be most significant bit
> - remove the workaround of mergeable buffer for dpdk prototype
> - id should be in the last descriptor in the chain
> - keep _F_WRITE for write descriptor when adding used
> - device flags updating should use ADDR_USED type
> - return error on unexpected unavail descriptor in a chain
> - return false in vhost_ve_avail_empty is descriptor is available
> - track last seen avail_wrap_counter
> - correctly examine available descriptor in get_indirect_packed()
> - vhost_idx_diff should return u16 instead of bool
>
> Changes from V1:
>
> - Refactor vhost used elem code to avoid open coding on used elem
> - Event suppression support (compile test only).
> - Indirect descriptor support (compile test only).
> - Zerocopy support.
> - vIOMMU support.
> - SCSI/VSOCK support (compile test only).
> - Fix several bugs
>
> Jason Wang (8):
> vhost: move get_rx_bufs to vhost.c
> vhost: hide used ring layout from device
> vhost: do not use vring_used_elem
> vhost_net: do not explicitly manipulate vhost_used_elem
> vhost: vhost_put_user() can accept metadata type
> virtio: introduce packed ring defines
> vhost: packed ring support
> vhost: event suppression for packed ring
>
> drivers/vhost/net.c | 136 ++----
> drivers/vhost/scsi.c | 62 +--
> drivers/vhost/vhost.c | 861 ++++++++++++++++++++++++++++++++-----
> drivers/vhost/vhost.h | 47 +-
> drivers/vhost/vsock.c | 42 +-
> include/uapi/linux/virtio_config.h | 9 +
> include/uapi/linux/virtio_ring.h | 32 ++
> 7 files changed, 928 insertions(+), 261 deletions(-)
>
> --
> 2.7.4
>
^ 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