* Re: [PATCH net-next-2.6] l2tp: fix potential rcu race
From: Paul E. McKenney @ 2011-05-12 14:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, James Chapman
In-Reply-To: <1305174156.3232.26.camel@edumazet-laptop>
On Thu, May 12, 2011 at 06:22:36AM +0200, Eric Dumazet wrote:
> While trying to remove useless synchronize_rcu() calls, I found l2tp is
> indeed incorrectly using two of such calls, but also bumps tunnel
> refcount after list insertion.
>
> tunnel refcount must be incremented before being made publically visible
> by rcu readers.
>
> This fix can be applied to 2.6.35+ and might need a backport for older
> kernels, since things were shuffled in commit fd558d186df2c
> (l2tp: Split pppol2tp patch into separate l2tp and ppp parts)
Ouch! Good catch, Eric!
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> CC: James Chapman <jchapman@katalix.com>
> ---
>
> I based this patch on net-next-2.6 because of recent commits in this
> file and linux-2.6 being on late RC phase. But its a stable candidate.
>
> net/l2tp/l2tp_core.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 9be095e..ed8a233 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -1435,16 +1435,15 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
>
> /* Add tunnel to our list */
> INIT_LIST_HEAD(&tunnel->list);
> - spin_lock_bh(&pn->l2tp_tunnel_list_lock);
> - list_add_rcu(&tunnel->list, &pn->l2tp_tunnel_list);
> - spin_unlock_bh(&pn->l2tp_tunnel_list_lock);
> - synchronize_rcu();
> atomic_inc(&l2tp_tunnel_count);
>
> /* Bump the reference count. The tunnel context is deleted
> - * only when this drops to zero.
> + * only when this drops to zero. Must be done before list insertion
> */
> l2tp_tunnel_inc_refcount(tunnel);
> + spin_lock_bh(&pn->l2tp_tunnel_list_lock);
> + list_add_rcu(&tunnel->list, &pn->l2tp_tunnel_list);
> + spin_unlock_bh(&pn->l2tp_tunnel_list_lock);
>
> err = 0;
> err:
> @@ -1636,7 +1635,6 @@ struct l2tp_session *l2tp_session_create(int priv_size, struct l2tp_tunnel *tunn
> hlist_add_head_rcu(&session->global_hlist,
> l2tp_session_id_hash_2(pn, session_id));
> spin_unlock_bh(&pn->l2tp_session_hlist_lock);
> - synchronize_rcu();
> }
>
> /* Ignore management session in session count value */
>
>
> --
> 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
* [PATCH] bonding,llc: Fix structure sizeof incompatibility for some PDUs
From: Vitalii Demianets @ 2011-05-12 12:57 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Arnaldo Carvalho de Melo
Cc: netdev, bonding-devel
With some combinations of arch/compiler the sizeof operator on structure
returns value greater than expected. In cases when the structure is used for
mapping PDU fields it may lead to unexpected results (e.g. holes and
alignment problems in skb data). Attribute "packed" prevents this undesired
behavior.
Signed-off-by: Vitalii Demianets <vitas@nppfactor.kiev.ua>
---
drivers/net/bonding/bond_3ad.h | 10 +++++-----
include/net/llc_pdu.h | 8 ++++----
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h
index 291dbd4..6d6327a 100644
--- a/drivers/net/bonding/bond_3ad.h
+++ b/drivers/net/bonding/bond_3ad.h
@@ -39,7 +39,7 @@
typedef struct mac_addr {
u8 mac_addr_value[ETH_ALEN];
-} mac_addr_t;
+} __attribute__((packed)) mac_addr_t;
enum {
BOND_AD_STABLE = 0,
@@ -134,12 +134,12 @@ typedef struct lacpdu {
u8 tlv_type_terminator; // = terminator
u8 terminator_length; // = 0
u8 reserved_50[50]; // = 0
-} lacpdu_t;
+} __attribute__((packed)) lacpdu_t;
typedef struct lacpdu_header {
struct ethhdr hdr;
struct lacpdu lacpdu;
-} lacpdu_header_t;
+} __attribute__((packed)) lacpdu_header_t;
// Marker Protocol Data Unit(PDU) structure(43.5.3.2 in the 802.3ad standard)
typedef struct bond_marker {
@@ -155,12 +155,12 @@ typedef struct bond_marker {
u8 tlv_type_terminator; // = 0x00
u8 terminator_length; // = 0x00
u8 reserved_90[90]; // = 0
-} bond_marker_t;
+} __attribute__((packed)) bond_marker_t;
typedef struct bond_marker_header {
struct ethhdr hdr;
struct bond_marker marker;
-} bond_marker_header_t;
+} __attribute__((packed)) bond_marker_header_t;
#pragma pack()
diff --git a/include/net/llc_pdu.h b/include/net/llc_pdu.h
index 75b8e29..a8eeb3f 100644
--- a/include/net/llc_pdu.h
+++ b/include/net/llc_pdu.h
@@ -199,7 +199,7 @@ struct llc_pdu_sn {
u8 ssap;
u8 ctrl_1;
u8 ctrl_2;
-};
+} __attribute__((packed));
static inline struct llc_pdu_sn *llc_pdu_sn_hdr(struct sk_buff *skb)
{
@@ -211,7 +211,7 @@ struct llc_pdu_un {
u8 dsap;
u8 ssap;
u8 ctrl_1;
-};
+} __attribute__((packed));
static inline struct llc_pdu_un *llc_pdu_un_hdr(struct sk_buff *skb)
{
@@ -359,7 +359,7 @@ struct llc_xid_info {
u8 fmt_id; /* always 0x81 for LLC */
u8 type; /* different if NULL/non-NULL LSAP */
u8 rw; /* sender receive window */
-};
+} __attribute__((packed));
/**
* llc_pdu_init_as_xid_cmd - sets bytes 3, 4 & 5 of LLC header as XID
@@ -415,7 +415,7 @@ struct llc_frmr_info {
u8 curr_ssv; /* current send state variable val */
u8 curr_rsv; /* current receive state variable */
u8 ind_bits; /* indicator bits set with macro */
-};
+} __attribute__((packed));
extern void llc_pdu_set_cmd_rsp(struct sk_buff *skb, u8 type);
extern void llc_pdu_set_pf_bit(struct sk_buff *skb, u8 bit_value);
--
1.7.3.4
^ permalink raw reply related
* Get wireless network card or check whether an interface is a wireless card
From: Chin Shi Hong @ 2011-05-12 13:51 UTC (permalink / raw)
To: netdev
Dear all,
My application must display only wireless (802.11) network interface
card. Currently, by using some ioctl calls and ifreq structure, my
application currently can detect any network interface. But, I only
want my application to detect wireless network interface card.
What are the ioctl calls or c/c++ codes to do this?
Regards,
^ permalink raw reply
* [PATCH net-next] net:set valid name before calling ndo_init()
From: Weiping Pan(潘卫平) @ 2011-05-12 13:39 UTC (permalink / raw)
Cc: Pan Weiping, David S. Miller, Eric Dumazet, Tom Herbert,
Michał Mirosław, Ben Hutchings,
open list:NETWORKING [GENERAL], open list
From: Pan Weiping <panweiping3@gmail.com>
A bug of bonding was invloved by e815d19ffe02bdfda1260949ef2b1806171,
see example 1 and 2.
In register_netdevice(), the name of net_device is not valid until
dev_get_valid_name() is called. But dev->netdev_ops->ndo_init(that is
bond_init) is called before dev_get_valid_name(),
and it uses the invalid name of net_device.
I think register_netdevice() should make sure that the name of net_device is
valid before calling ndo_init().
example 1:
modprobe bonding
ls /proc/net/bonding/bond%d
ps -eLf
root 3398 2 3398 0 1 21:34 ? 00:00:00 [bond%d]
example 2:
modprobe bonding max_bonds=3
[ 170.100292] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 170.101090] bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
[ 170.102469] ------------[ cut here ]------------
[ 170.103150] WARNING: at /home/pwp/net-next-2.6/fs/proc/generic.c:586 proc_register+0x126/0x157()
[ 170.104075] Hardware name: VirtualBox
[ 170.105065] proc_dir_entry 'bonding/bond%d' already registered
[ 170.105613] Modules linked in: bonding(+) sunrpc ipv6 uinput microcode ppdev parport_pc parport joydev e1000 pcspkr i2c_piix4 i2c_core [last unloaded: bonding]
[ 170.108397] Pid: 3457, comm: modprobe Not tainted 2.6.39-rc2+ #14
[ 170.108935] Call Trace:
[ 170.109382] [<c0438f3b>] warn_slowpath_common+0x6a/0x7f
[ 170.109911] [<c051a42a>] ? proc_register+0x126/0x157
[ 170.110329] [<c0438fc3>] warn_slowpath_fmt+0x2b/0x2f
[ 170.110846] [<c051a42a>] proc_register+0x126/0x157
[ 170.111870] [<c051a4dd>] proc_create_data+0x82/0x98
[ 170.112335] [<f94e6af6>] bond_create_proc_entry+0x3f/0x73 [bonding]
[ 170.112905] [<f94dd806>] bond_init+0x77/0xa5 [bonding]
[ 170.113319] [<c0721ac6>] register_netdevice+0x8c/0x1d3
[ 170.113848] [<f94e0e30>] bond_create+0x6c/0x90 [bonding]
[ 170.114322] [<f94f4763>] bonding_init+0x763/0x7b1 [bonding]
[ 170.114879] [<c0401240>] do_one_initcall+0x76/0x122
[ 170.115317] [<f94f4000>] ? 0xf94f3fff
[ 170.115799] [<c0463f1e>] sys_init_module+0x1286/0x140d
[ 170.116879] [<c07c6d9f>] sysenter_do_call+0x12/0x28
[ 170.117404] ---[ end trace 64e4fac3ae5fff1a ]---
[ 170.117924] bond%d: Warning: failed to register to debugfs
[ 170.128728] ------------[ cut here ]------------
[ 170.129360] WARNING: at /home/pwp/net-next-2.6/fs/proc/generic.c:586 proc_register+0x126/0x157()
[ 170.130323] Hardware name: VirtualBox
[ 170.130797] proc_dir_entry 'bonding/bond%d' already registered
[ 170.131315] Modules linked in: bonding(+) sunrpc ipv6 uinput microcode ppdev parport_pc parport joydev e1000 pcspkr i2c_piix4 i2c_core [last unloaded: bonding]
[ 170.133731] Pid: 3457, comm: modprobe Tainted: G W 2.6.39-rc2+ #14
[ 170.134308] Call Trace:
[ 170.134743] [<c0438f3b>] warn_slowpath_common+0x6a/0x7f
[ 170.135305] [<c051a42a>] ? proc_register+0x126/0x157
[ 170.135820] [<c0438fc3>] warn_slowpath_fmt+0x2b/0x2f
[ 170.137168] [<c051a42a>] proc_register+0x126/0x157
[ 170.137700] [<c051a4dd>] proc_create_data+0x82/0x98
[ 170.138174] [<f94e6af6>] bond_create_proc_entry+0x3f/0x73 [bonding]
[ 170.138745] [<f94dd806>] bond_init+0x77/0xa5 [bonding]
[ 170.139278] [<c0721ac6>] register_netdevice+0x8c/0x1d3
[ 170.139828] [<f94e0e30>] bond_create+0x6c/0x90 [bonding]
[ 170.140361] [<f94f4763>] bonding_init+0x763/0x7b1 [bonding]
[ 170.140927] [<c0401240>] do_one_initcall+0x76/0x122
[ 170.141494] [<f94f4000>] ? 0xf94f3fff
[ 170.141975] [<c0463f1e>] sys_init_module+0x1286/0x140d
[ 170.142463] [<c07c6d9f>] sysenter_do_call+0x12/0x28
[ 170.142974] ---[ end trace 64e4fac3ae5fff1b ]---
[ 170.144949] bond%d: Warning: failed to register to debugfs
Signed-off-by: Pan Weiping <panweiping3@gmail.com>
---
net/core/dev.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 75898a3..f289117 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5412,6 +5412,10 @@ int register_netdevice(struct net_device *dev)
dev->iflink = -1;
+ ret = dev_get_valid_name(dev, dev->name);
+ if (ret < 0)
+ goto out;
+
/* Init, if this function is available */
if (dev->netdev_ops->ndo_init) {
ret = dev->netdev_ops->ndo_init(dev);
@@ -5422,10 +5426,6 @@ int register_netdevice(struct net_device *dev)
}
}
- ret = dev_get_valid_name(dev, dev->name);
- if (ret < 0)
- goto err_uninit;
-
dev->ifindex = dev_new_index(net);
if (dev->iflink == -1)
dev->iflink = dev->ifindex;
--
1.7.4
^ permalink raw reply related
* Re: ifreq flags or ioctl calls to turn an interface down?
From: Eric Dumazet @ 2011-05-12 13:32 UTC (permalink / raw)
To: Chin Shi Hong; +Cc: netdev
In-Reply-To: <BANLkTim=DPqz+pS3DDHw=C4MGMJmu6t=GA@mail.gmail.com>
Le jeudi 12 mai 2011 à 21:27 +0800, Chin Shi Hong a écrit :
> Dear all,
>
> I am developing an application that will turn a network interface down
> (something like command "ifconfig <network interface> down".
>
> What are the ifreq flags or ioctl calls to turn a network interface down?
>
> Or is there any other way to implement this feature into my application?
Quick answer :
strace ifconfig eth2 down
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth2", ifr_flags=IFF_UP|IFF_BROADCAST|
IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="eth2", ifr_flags=IFF_BROADCAST|
IFF_RUNNING|IFF_MULTICAST}) = 0
^ permalink raw reply
* [PATCH net-next-2.6] garp: remove last synchronize_rcu() call
From: Eric Dumazet @ 2011-05-12 13:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, Ben Greear, netdev, Paul E. McKenney
In-Reply-To: <4DC831B0.80107@trash.net>
Le lundi 09 mai 2011 à 20:25 +0200, Patrick McHardy a écrit :
> Am 09.05.2011 15:35, schrieb Eric Dumazet:
> > Speedup vlan dismantling in CONFIG_VLAN_8021Q_GVRP=y cases,
> > by using a call_rcu() to free the memory instead of waiting with
> > expensive synchronize_rcu() [ while RTNL is held ]
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Ben Greear <greearb@candelatech.com>
> > Cc: Patrick McHardy <kaber@trash.net>
> > Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > Note: I'll take care of using kfree_rcu() when available in net-next-2.6
> >
>
> Looks good to me.
>
Here is a followup on this patch, thanks !
[PATCH net-next-2.6] garp: remove last synchronize_rcu() call
When removing last vlan from a device, garp_uninit_applicant() calls
synchronize_rcu() to make sure no user can still manipulate struct
garp_applicant before we free it.
Use call_rcu() instead, as a step to further net_device dismantle
optimizations.
Add the temporary garp_cleanup_module() function to make sure no pending
call_rcu() are left at module unload time [ this will be removed when
kfree_rcu() is available ]
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Ben Greear <greearb@candelatech.com>
---
include/net/garp.h | 1 +
net/802/garp.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/net/garp.h b/include/net/garp.h
index 8cabbf08..834d8ad 100644
--- a/include/net/garp.h
+++ b/include/net/garp.h
@@ -104,6 +104,7 @@ struct garp_applicant {
struct sk_buff_head queue;
struct sk_buff *pdu;
struct rb_root gid;
+ struct rcu_head rcu;
};
struct garp_port {
diff --git a/net/802/garp.c b/net/802/garp.c
index 5dbe896..f8300a8 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -603,6 +603,11 @@ err1:
}
EXPORT_SYMBOL_GPL(garp_init_applicant);
+static void garp_app_kfree_rcu(struct rcu_head *head)
+{
+ kfree(container_of(head, struct garp_applicant, rcu));
+}
+
void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl)
{
struct garp_port *port = rtnl_dereference(dev->garp_port);
@@ -611,7 +616,6 @@ void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl
ASSERT_RTNL();
rcu_assign_pointer(port->applicants[appl->type], NULL);
- synchronize_rcu();
/* Delete timer and generate a final TRANSMIT_PDU event to flush out
* all pending messages before the applicant is gone. */
@@ -621,7 +625,7 @@ void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl
garp_queue_xmit(app);
dev_mc_del(dev, appl->proto.group_address);
- kfree(app);
+ call_rcu(&app->rcu, garp_app_kfree_rcu);
garp_release_port(dev);
}
EXPORT_SYMBOL_GPL(garp_uninit_applicant);
@@ -639,3 +643,9 @@ void garp_unregister_application(struct garp_application *appl)
stp_proto_unregister(&appl->proto);
}
EXPORT_SYMBOL_GPL(garp_unregister_application);
+
+static void __exit garp_cleanup_module(void)
+{
+ rcu_barrier(); /* Wait for completion of call_rcu()'s */
+}
+module_exit(garp_cleanup_module);
^ permalink raw reply related
* ifreq flags or ioctl calls to turn an interface down?
From: Chin Shi Hong @ 2011-05-12 13:27 UTC (permalink / raw)
To: netdev
Dear all,
I am developing an application that will turn a network interface down
(something like command "ifconfig <network interface> down".
What are the ifreq flags or ioctl calls to turn a network interface down?
Or is there any other way to implement this feature into my application?
^ permalink raw reply
* Re: [PATCH v4 1/1] can: add pruss CAN driver.
From: Marc Kleine-Budde @ 2011-05-12 13:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Subhasish Ghosh, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Wolfgang Grandegger,
Netdev-u79uwXL29TY76Z2rM5mHXA, m-watkins-l0cyMroinI0, Alan Cox
In-Reply-To: <201105121454.47781.arnd-r2nGTMty4D4@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]
On 05/12/2011 02:54 PM, Arnd Bergmann wrote:
> On Thursday 12 May 2011, Wolfgang Grandegger wrote:
>> Well, that seems sophisticated resulting in a complex implementation
>> (may code line) also because hardware filters are very hardware
>> dependent. Usually just one global filter can be defined. I think that's
>> overkill. A simple interface using:
>>
>> ip link set can0 type can filter <id>:<mask> [<id>:<mask> ...]
>>
>> would just be fine.
>
> Ok, fair enough. Still I would suggest you first come up with
> a reasonable user interface (the one you posted may be just right,
> I don't know), and then let someone do the implementation in the
> pruss firmware that is the best match for the user interface, rather
> than the other way around.
I suggested some time ago to implement the more-or-less standard
<id>:<mask> filter instead of just a single <id> (per filter entry). The
cost is probably quite low, it's just a single AND operation per filter
entry more expensive.
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* CONGRATS;
From: MICROSOFT @ 2011-05-12 12:57 UTC (permalink / raw)
To: microsoft_777
Dear Guaranteed Winner,
We are Pleased to inform you that you have won The Sum of Five Hundred Thousand Great British Pounds.
(500,000.00GBP) by Msn/Yahoo Lottery in conjunction with the MICROSOFT
WINDOWS.
we collects all the email addresses of the people that are active online,
among the millions that subscribed to Yahoo,Hotmail and various Microsoft
window users, we only select five people every year as
our winners, through electronic balloting system without the winner applying.
Ref Number: ...........XYL /26510460037/05
Batch Number: ................24/00319/IPD
Winning Number:.......................YM/09788
However you will have to fill and submit this form to the events manager
1.Full name..............
2.Contact Address........
3.Age....................
4.Telephone Number.......
5.Marital Status.........
6.Sex....................
7.Occupation.............
8.State:.................
9.Country................
10Winning E-mail Address...............
11.Amount Won.........
Your Reference and Batch number at the top of this mail:
(CONTACT EVENTS MANAGER)
Name: DR Don mike.
E-mail:clamunit55@hotmail.com
Tel:+447010047061
Congratulations from all members and staff of msn/yahoo lottery board.
^ permalink raw reply
* Re: [PATCH v4 1/1] can: add pruss CAN driver.
From: Arnd Bergmann @ 2011-05-12 12:54 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Subhasish Ghosh, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Marc Kleine-Budde,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Netdev-u79uwXL29TY76Z2rM5mHXA, m-watkins-l0cyMroinI0, Alan Cox
In-Reply-To: <4DCB88A4.2010901-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Thursday 12 May 2011, Wolfgang Grandegger wrote:
> Well, that seems sophisticated resulting in a complex implementation
> (may code line) also because hardware filters are very hardware
> dependent. Usually just one global filter can be defined. I think that's
> overkill. A simple interface using:
>
> ip link set can0 type can filter <id>:<mask> [<id>:<mask> ...]
>
> would just be fine.
Ok, fair enough. Still I would suggest you first come up with
a reasonable user interface (the one you posted may be just right,
I don't know), and then let someone do the implementation in the
pruss firmware that is the best match for the user interface, rather
than the other way around.
Arnd
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: fix mbox polling for signal reception
From: Ben Hutchings @ 2011-05-12 12:49 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <f816628b-a4b6-4a53-867e-12e75bc7b4de@exht1.ad.emulex.com>
On Thu, 2011-05-12 at 11:41 +0530, Sathya Perla wrote:
> Sending mbox cmds require multiple steps of writing to the DB register and polling
> for an ack. Gettting interrupted in the middle by a signal breaks the mbox protocol.
> So, set the task to UNINTERRUPTIBLE for mbox polling.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_cmds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
> index bff41ed..55c8301 100644
> --- a/drivers/net/benet/be_cmds.c
> +++ b/drivers/net/benet/be_cmds.c
> @@ -297,7 +297,7 @@ static int be_mbox_db_ready_wait(struct be_adapter *adapter, void __iomem *db)
> return -1;
> }
>
> - set_current_state(TASK_INTERRUPTIBLE);
> + set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(1));
msleep(1) is a lot more readable.
Ben.
> msecs++;
> } while (true);
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch 1/9] [PATCH] qeth: convert to hw_features part 2
From: Frank Blaschka @ 2011-05-12 11:59 UTC (permalink / raw)
To: Michał Mirosław; +Cc: davem, netdev, linux-s390
In-Reply-To: <BANLkTimUq-6E1F_ns_jTvXuYoPU-sLUmqw@mail.gmail.com>
On Thu, May 12, 2011 at 01:25:51PM +0200, Michał Mirosław wrote:
> W dniu 12 maja 2011 13:10 użytkownik Frank Blaschka
> <blaschka@linux.vnet.ibm.com> napisał:
> > On Thu, May 12, 2011 at 10:12:51AM +0200, Michał Mirosław wrote:
> >> W dniu 12 maja 2011 09:21 użytkownik Frank Blaschka
> >> <blaschka@linux.vnet.ibm.com> napisał:
> >> > On Thu, May 12, 2011 at 07:59:45AM +0200, Michał Mirosław wrote:
> >> >> 2011/5/12 <frank.blaschka@de.ibm.com>:
> >> >> > Set rx csum default to hw checksumming again.
> >> >> > Remove sysfs interface for rx csum (checksumming) and TSO (large_send).
> >> >> > With the new hw_features it does not work to keep the old sysfs
> >> >> > interface in parallel. Convert options.checksum_type to new hw_features.
> >> >> [...]
> >> >> > + /* hw may have changed during offline or recovery */
> >> >> > + if (!qeth_is_supported(card, IPA_INBOUND_CHECKSUM)) {
> >> >> [...]
> >> >>
> >> >> This check should go to ndo_fix_features callback. If it fails then
> >> >> just return features &~NETIF_F_RXCSUM from there ...
> >> >>
> > Ok so all I have to do to complete this is to remove
> > card->dev->hw_features &= ~NETIF_F_RXCSUM;
> > from here (ndo_fix_feature has already the check)?
> >
> > Since we might be in recovery it is smarter to keep the support check here so we
> > do not have to use try and error approach to see if capabilities have
> > changed. Do you aggree?
>
> The key is that the driver should call netdev_update_features()
> whenever some conditions affecting available features might have
> changed. If you can keep the checks contained inside ndo_fix_features
> callback, you can avoid caring about the offloads in the recovery
> process.
Ok, we have this now.
>
> There's also the question what happens when packets are queued while
> there's ongoing recovery? Simplest way would be to drop them all until
> recovery completes.
Since this is RX processing there is nothing queued during recovery. But
you are right for tx csum or TSO we have to think about this. For now
I would like to complete this patch.
>
> Best Regards,
> Michał Mirosław
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" 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] ethtool: bring back missing comma in netdev_features_strings
From: Michał Mirosław @ 2011-05-12 11:33 UTC (permalink / raw)
To: Franco Fichtner; +Cc: Netdev, Mahesh Bandewar
In-Reply-To: <4DCBA4C5.5040308@lastsummer.de>
W dniu 12 maja 2011 11:13 użytkownik Franco Fichtner
<franco@lastsummer.de> napisał:
> On 12/05/11 10:55, Michał Mirosław wrote:
>> 2011/5/12 Franco Fichtner <franco@lastsummer.de>:
>>> I found this while skimming through recent net-next patches.
>>> I'm not quite sure if the padding in this struct is correct now.
>> Nice catch. But please send the patch inline instead of as an attachment.
> Thanks, but I have a short question. Are the empty strings in
> this struct really needed?
>
> /* NETIF_F_TSO6 */ "tx-tcp6-segmentation",
> /* NETIF_F_FSO */ "tx-fcoe-segmentation",
> "",
> "",
>
> /* NETIF_F_FCOE_CRC */ "tx-checksum-fcoe-crc",
>
> They seem to have caused this mess in the first place and I would
> think they could be removed entirely.
Mahesh Bandewar tried to do some cleanup in how feature bits are
defined using an enum, but it wasn't completed. If that cleanup was
completed, this array could be initialized using C99 style:
[NETIF_F_TSO6_BIT] = "tx-tcp6-segmentation",
(This has more advantages than pure aesthetics.) For now those empty
strings have to stay, as the array positions are relevant.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch 1/9] [PATCH] qeth: convert to hw_features part 2
From: Michał Mirosław @ 2011-05-12 11:25 UTC (permalink / raw)
To: Frank Blaschka; +Cc: davem, netdev, linux-s390
In-Reply-To: <20110512111009.GA4176@tuxmaker.boeblingen.de.ibm.com>
W dniu 12 maja 2011 13:10 użytkownik Frank Blaschka
<blaschka@linux.vnet.ibm.com> napisał:
> On Thu, May 12, 2011 at 10:12:51AM +0200, Michał Mirosław wrote:
>> W dniu 12 maja 2011 09:21 użytkownik Frank Blaschka
>> <blaschka@linux.vnet.ibm.com> napisał:
>> > On Thu, May 12, 2011 at 07:59:45AM +0200, Michał Mirosław wrote:
>> >> 2011/5/12 <frank.blaschka@de.ibm.com>:
>> >> > Set rx csum default to hw checksumming again.
>> >> > Remove sysfs interface for rx csum (checksumming) and TSO (large_send).
>> >> > With the new hw_features it does not work to keep the old sysfs
>> >> > interface in parallel. Convert options.checksum_type to new hw_features.
>> >> [...]
>> >> > + /* hw may have changed during offline or recovery */
>> >> > + if (!qeth_is_supported(card, IPA_INBOUND_CHECKSUM)) {
>> >> [...]
>> >>
>> >> This check should go to ndo_fix_features callback. If it fails then
>> >> just return features &~NETIF_F_RXCSUM from there ...
>> >>
> Ok so all I have to do to complete this is to remove
> card->dev->hw_features &= ~NETIF_F_RXCSUM;
> from here (ndo_fix_feature has already the check)?
>
> Since we might be in recovery it is smarter to keep the support check here so we
> do not have to use try and error approach to see if capabilities have
> changed. Do you aggree?
The key is that the driver should call netdev_update_features()
whenever some conditions affecting available features might have
changed. If you can keep the checks contained inside ndo_fix_features
callback, you can avoid caring about the offloads in the recovery
process.
There's also the question what happens when packets are queued while
there's ongoing recovery? Simplest way would be to drop them all until
recovery completes.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] net/irda/ircomm_tty.c: Use flip buffers to deliver data
From: Alan Cox @ 2011-05-12 11:17 UTC (permalink / raw)
To: Amit Virdi
Cc: samuel, alan, davem, eric.dumazet, netdev, linux-kernel,
shiraz.hashim, armando.visconti, viresh.kumar
In-Reply-To: <1305198280-14449-1-git-send-email-amit.virdi@st.com>
On Thu, 12 May 2011 16:34:40 +0530
Amit Virdi <amit.virdi@st.com> wrote:
> use tty_insert_flip_string and tty_flip_buffer_push to deliver incoming data
> packets from the IrDA device instead of delivering the packets directly to the
> line discipline. Following later approach resulted in warning "Sleeping function
> called from invalid context".
>
> Signed-off-by: Amit Virdi <amit.virdi@st.com>
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [patch 1/9] [PATCH] qeth: convert to hw_features part 2
From: Frank Blaschka @ 2011-05-12 11:10 UTC (permalink / raw)
To: Michał Mirosław; +Cc: davem, netdev, linux-s390
In-Reply-To: <BANLkTimAisv82ZbFb8D1AkL8vuK1V5zAXw@mail.gmail.com>
On Thu, May 12, 2011 at 10:12:51AM +0200, Michał Mirosław wrote:
> W dniu 12 maja 2011 09:21 użytkownik Frank Blaschka
> <blaschka@linux.vnet.ibm.com> napisał:
> > On Thu, May 12, 2011 at 07:59:45AM +0200, Michał Mirosław wrote:
> >> 2011/5/12 <frank.blaschka@de.ibm.com>:
> >> > Set rx csum default to hw checksumming again.
> >> > Remove sysfs interface for rx csum (checksumming) and TSO (large_send).
> >> > With the new hw_features it does not work to keep the old sysfs
> >> > interface in parallel. Convert options.checksum_type to new hw_features.
> >> [...]
> >> > + /* hw may have changed during offline or recovery */
> >> > + if (!qeth_is_supported(card, IPA_INBOUND_CHECKSUM)) {
> >> [...]
> >>
> >> This check should go to ndo_fix_features callback. If it fails then
> >> just return features &~NETIF_F_RXCSUM from there ...
> >>
Ok so all I have to do to complete this is to remove
card->dev->hw_features &= ~NETIF_F_RXCSUM;
from here (ndo_fix_feature has already the check)?
Since we might be in recovery it is smarter to keep the support check here so we
do not have to use try and error approach to see if capabilities have
changed. Do you aggree?
> >> > +update_feature:
> >> > + rtnl_lock();
> >> > + card->dev->hw_features &= ~NETIF_F_RXCSUM;
> >> > + card->dev->features &= ~NETIF_F_RXCSUM;
> >> > + netdev_update_features(card->dev);
> >> > + rtnl_unlock();
> >>
> >> ... and then this should be just:
> >> rtnl_lock();
> >> netdev_update_features(card->dev);
> >> rtnl_unlock();
> >>
> > This code is part of the recovery, assuming the recovery detects the hw
> > has lost it's rx csum capability I still don't understand how ndo_fix_features
> > come into play?
>
> ndo_fix_features is always called before ndo_set_features to alter
> features that are to be enabled. So in this case, it should check if
> checksumming is available and remove NETIF_F_RXCSUM from the set if it
> isn't. The resulting set (after further cleanup by core code) is
> passed to ndo_set_features if the features had changed. hw_features
> only control what can be requested by user.
>
> I assume that if the device can loose the checksumming capability
> during runtime, it can also regain it. Above solution will
> automatically reenable checksumming if its requested and the
> capability comes back.
>
> Best Regards,
> Michał Mirosław
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" 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
* [PATCH] net/irda/ircomm_tty.c: Use flip buffers to deliver data
From: Amit Virdi @ 2011-05-12 11:04 UTC (permalink / raw)
To: samuel, alan, davem, eric.dumazet, netdev, linux-kernel
Cc: amit.virdi, shiraz.hashim, armando.visconti, viresh.kumar
use tty_insert_flip_string and tty_flip_buffer_push to deliver incoming data
packets from the IrDA device instead of delivering the packets directly to the
line discipline. Following later approach resulted in warning "Sleeping function
called from invalid context".
Signed-off-by: Amit Virdi <amit.virdi@st.com>
---
net/irda/ircomm/ircomm_tty.c | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/irda/ircomm/ircomm_tty.c b/net/irda/ircomm/ircomm_tty.c
index a39cca8..b3cc8b3 100644
--- a/net/irda/ircomm/ircomm_tty.c
+++ b/net/irda/ircomm/ircomm_tty.c
@@ -38,6 +38,7 @@
#include <linux/seq_file.h>
#include <linux/termios.h>
#include <linux/tty.h>
+#include <linux/tty_flip.h>
#include <linux/interrupt.h>
#include <linux/device.h> /* for MODULE_ALIAS_CHARDEV_MAJOR */
@@ -1132,7 +1133,6 @@ static int ircomm_tty_data_indication(void *instance, void *sap,
struct sk_buff *skb)
{
struct ircomm_tty_cb *self = (struct ircomm_tty_cb *) instance;
- struct tty_ldisc *ld;
IRDA_DEBUG(2, "%s()\n", __func__ );
@@ -1161,15 +1161,11 @@ static int ircomm_tty_data_indication(void *instance, void *sap,
}
/*
- * Just give it over to the line discipline. There is no need to
- * involve the flip buffers, since we are not running in an interrupt
- * handler
+ * Use flip buffer functions since the code may be called from interrupt
+ * context
*/
-
- ld = tty_ldisc_ref(self->tty);
- if (ld)
- ld->ops->receive_buf(self->tty, skb->data, NULL, skb->len);
- tty_ldisc_deref(ld);
+ tty_insert_flip_string(self->tty, skb->data, skb->len);
+ tty_flip_buffer_push(self->tty);
/* No need to kfree_skb - see ircomm_ttp_data_indication() */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v4 1/1] can: add pruss CAN driver.
From: Kurt Van Dijck @ 2011-05-12 10:58 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Arnd Bergmann, Subhasish Ghosh, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Marc Kleine-Budde, Alan Cox,
Netdev-u79uwXL29TY76Z2rM5mHXA, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4DCB88A4.2010901-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Thu, May 12, 2011 at 09:13:40AM +0200, Wolfgang Grandegger wrote:
> A simple interface using:
>
> ip link set can0 type can filter <id>:<mask> [<id>:<mask> ...]
>
> would just be fine.
Yep.
^ permalink raw reply
* Re: [PATCH net-next 1/2 RESEND v3] net: use NETIF_F_ALL_TSO for vlan features
From: Shan Wei @ 2011-05-12 9:54 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: David Miller, netdev, eilong, leedom
In-Reply-To: <4DCABABB.9040001@chelsio.com>
Dimitris Michailidis wrote, at 2011年05月12日 00:35:
> On 05/10/2011 11:24 PM, Shan Wei wrote:
>> As Dimitris Michailidis suggested, use NETIF_F_ALL_TSO for vlan_features,
>> which is a mask, but not hw_features.
>>
>> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
>
> While these changes aren't wrong I don't see a good reason to make them. I am also curious why you're changing only these three drivers.
A personal reason to quickly know what device supports ALL TSO,
not to search one by one. :;)
TSO offloads are assigned directly in these three drivers.
Other drivers set vlan_features as hw_features, or set TSO offloads after doing some check.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH net-next] ethtool: bring back missing comma in netdev_features_strings
From: Franco Fichtner @ 2011-05-12 9:13 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Franco Fichtner, Netdev
In-Reply-To: <BANLkTikH2uY_crot1DRBFZv9ifmvPQeRog@mail.gmail.com>
On 12/05/11 10:55, Michał Mirosław wrote:
> 2011/5/12 Franco Fichtner <franco@lastsummer.de>:
>> I found this while skimming through recent net-next patches.
>> I'm not quite sure if the padding in this struct is correct now.
> Nice catch. But please send the patch inline instead of as an attachment.
Thanks, but I have a short question. Are the empty strings in
this struct really needed?
/* NETIF_F_TSO6 */ "tx-tcp6-segmentation",
/* NETIF_F_FSO */ "tx-fcoe-segmentation",
"",
"",
/* NETIF_F_FCOE_CRC */ "tx-checksum-fcoe-crc",
They seem to have caused this mess in the first place and I would
think they could be removed entirely.
I will resend the patch later today as inline. Sorry about that.
Franco
^ permalink raw reply
* Re: [PATCH net-next] ethtool: bring back missing comma in netdev_features_strings
From: Michał Mirosław @ 2011-05-12 8:55 UTC (permalink / raw)
To: Franco Fichtner; +Cc: Netdev
In-Reply-To: <4DCB94E6.2020407@lastsummer.de>
2011/5/12 Franco Fichtner <franco@lastsummer.de>:
> I found this while skimming through recent net-next patches.
> I'm not quite sure if the padding in this struct is correct now.
Nice catch. But please send the patch inline instead of as an attachment.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH net-next] ethtool: bring back missing comma in netdev_features_strings
From: Franco Fichtner @ 2011-05-12 8:05 UTC (permalink / raw)
To: Netdev
[-- Attachment #1: Type: text/plain, Size: 144 bytes --]
Hi all,
I found this while skimming through recent net-next patches.
I'm not quite sure if the padding in this struct is correct now.
Franco
[-- Attachment #2: 0001-ethtool-bring-back-missing-comma-in-netdev_features_.patch --]
[-- Type: text/x-patch, Size: 990 bytes --]
>From c62ca7bb87baad78e285dc0e698e792051d8fa87 Mon Sep 17 00:00:00 2001
From: Franco Fichtner <franco@lastsummer.de>
Date: Wed, 11 May 2011 09:49:08 +0200
Subject: [PATCH net-next] ethtool: bring back missing comma in netdev_features_strings
The issue was introduced in commit eed2a12f1ed9aabf.
Signed-off-by: Franco Fichtner <franco@lastsummer.de>
---
net/core/ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b6f4058..b8c2b10 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -361,7 +361,7 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
/* NETIF_F_NTUPLE */ "rx-ntuple-filter",
/* NETIF_F_RXHASH */ "rx-hashing",
/* NETIF_F_RXCSUM */ "rx-checksum",
- /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy"
+ /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy",
/* NETIF_F_LOOPBACK */ "loopback",
};
--
1.7.3.2.493.g0b0cd
^ permalink raw reply related
* Re: [patch 1/9] [PATCH] qeth: convert to hw_features part 2
From: Michał Mirosław @ 2011-05-12 8:12 UTC (permalink / raw)
To: Frank Blaschka; +Cc: davem, netdev, linux-s390
In-Reply-To: <20110512072132.GA31817@tuxmaker.boeblingen.de.ibm.com>
W dniu 12 maja 2011 09:21 użytkownik Frank Blaschka
<blaschka@linux.vnet.ibm.com> napisał:
> On Thu, May 12, 2011 at 07:59:45AM +0200, Michał Mirosław wrote:
>> 2011/5/12 <frank.blaschka@de.ibm.com>:
>> > Set rx csum default to hw checksumming again.
>> > Remove sysfs interface for rx csum (checksumming) and TSO (large_send).
>> > With the new hw_features it does not work to keep the old sysfs
>> > interface in parallel. Convert options.checksum_type to new hw_features.
>> [...]
>> > + /* hw may have changed during offline or recovery */
>> > + if (!qeth_is_supported(card, IPA_INBOUND_CHECKSUM)) {
>> [...]
>>
>> This check should go to ndo_fix_features callback. If it fails then
>> just return features &~NETIF_F_RXCSUM from there ...
>>
>> > +update_feature:
>> > + rtnl_lock();
>> > + card->dev->hw_features &= ~NETIF_F_RXCSUM;
>> > + card->dev->features &= ~NETIF_F_RXCSUM;
>> > + netdev_update_features(card->dev);
>> > + rtnl_unlock();
>>
>> ... and then this should be just:
>> rtnl_lock();
>> netdev_update_features(card->dev);
>> rtnl_unlock();
>>
> This code is part of the recovery, assuming the recovery detects the hw
> has lost it's rx csum capability I still don't understand how ndo_fix_features
> come into play?
ndo_fix_features is always called before ndo_set_features to alter
features that are to be enabled. So in this case, it should check if
checksumming is available and remove NETIF_F_RXCSUM from the set if it
isn't. The resulting set (after further cleanup by core code) is
passed to ndo_set_features if the features had changed. hw_features
only control what can be requested by user.
I assume that if the device can loose the checksumming capability
during runtime, it can also regain it. Above solution will
automatically reenable checksumming if its requested and the
capability comes back.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: future developments of usbnet
From: Oliver Neukum @ 2011-05-12 7:59 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, stern, tom.leiming, netdev, linux-usb
In-Reply-To: <20110511.134727.957370621658043260.davem@davemloft.net>
Am Mittwoch, 11. Mai 2011, 19:47:27 schrieb David Miller:
> Basically once you take you interrupt, and disable device interrupts,
> the generic net device layer calls your ->poll() routing with a "weight"
> You should not process more RX packets than this value.
>
> If you have less than "weight" work to do, you should do a napi_complete(),
> which takes you out of the polling group, and re-enable device interrupts.
>
> So the idea is that you keep getting ->poll()'d until there is no more
> RX work to do.
>
> The "weight" argument implements fairness amongst competing, actively
> polling, devices on the same CPU.
>
Thank you, this is very informative. Our problem here is that USB doesn't work
sanely without interrupts. We can stop IO regarding rx, but we cannot stop
interrupts if we want to do rx.
Regards
Oliver
^ permalink raw reply
* Changing the default for net.ipv6.conf.*.use_tempaddr
From: Arnd Hannemann @ 2011-05-12 7:57 UTC (permalink / raw)
To: netdev
Hi,
while reading all the pro and cons mentioned in a recent discussion[1]
on debian-devel I wonder if there was a particular reason why
Privacy Extensions are disabled by default in linux?
Maybe it is time to reconsider the default?
Best regards
Arnd
[1] http://lists.debian.org/debian-devel/2011/05/msg00462.html
^ 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