* Re: [RFC PATCH 2/2] bridge: export multicast database via netlink
From: Thomas Graf @ 2012-11-27 11:59 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, bridge, Herbert Xu, Stephen Hemminger, David S. Miller,
Jesper Dangaard Brouer
In-Reply-To: <1354009785-20014-2-git-send-email-amwang@redhat.com>
On 11/27/12 at 05:49pm, Cong Wang wrote:
> +static int br_rports_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
> + u32 seq, struct net_device *dev)
> +{
> + struct net_bridge *br = netdev_priv(dev);
> + struct net_bridge_port *p;
> + struct hlist_node *n;
> + struct nlattr *nest, *nest2;
> +
> + if (!br->multicast_router || hlist_empty(&br->router_list)) {
> + printk(KERN_INFO "no router on bridge\n");
> + return 0;
> + }
> +
> + nest = nla_nest_start(skb, MDBA_ROUTER);
> + if (nest == NULL)
> + return -EMSGSIZE;
> + nest2 = nla_nest_start(skb, MDBA_MDB_BRPORT);
> + if (nest2 == NULL)
> + goto fail;
> +
> + hlist_for_each_entry_rcu(p, n, &br->router_list, rlist) {
> + if (p && nla_put_u16(skb, MDBA_BRPORT_NO, p->port_no)) {
> + nla_nest_cancel(skb, nest2);
> + goto fail;
> + }
> + }
> +
> + nla_nest_end(skb, nest2);
> + nla_nest_end(skb, nest);
I would simplify the MDBA_ROUTER attribute to a u16[len(br->router_list)]. If
we ever need something more complex we can retire the MDBA_ROUTER
attribute and replace it with something newer.
> + nest = nla_nest_start(skb, MDBA_MDB);
> + if (nest == NULL)
> + return -EMSGSIZE;
> +
> + for (i = 0; i < mdb->max; i++) {
> + struct hlist_node *h;
> + struct net_bridge_mdb_entry *mp;
> + struct net_bridge_port_group *p, **pp;
> + struct net_bridge_port *port;
> +
> + hlist_for_each_entry_rcu(mp, h, &mdb->mhash[i], hlist[mdb->ver]) {
> + if (nla_put_be32(skb, MDBA_MDB_MCADDR, mp->addr.u.ip4))
> + goto fail;
> +
> + nest2 = nla_nest_start(skb, MDBA_MDB_BRPORT);
> + if (nest2 == NULL)
> + goto fail;
What if you can't fit all theh hash entries into a single netlink
message? You need to allow splitting theh hash across multiple
messages. Therefore I suggest that you add a container attribute
for each mdb_entry like this:
MDBA_MDB = {
1 = {
MDBA_MDB_MCADDR = { ... },
MDBA_MDB_BRPORT = { ... },
},
2 = {
MDBA_MDB_MCADDR = { ... },
MDBA_MDB_BR_PORT = { ... },
},
[...]
}
> +static int br_mdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> + struct net_device *dev;
> + struct net *net = sock_net(skb->sk);
> + struct nlmsghdr *nlh;
> + u32 seq = cb->nlh->nlmsg_seq;
> + int idx = 0, s_idx;
> +
> + s_idx = cb->args[0];
> +
> + rcu_read_lock();
> + cb->seq = net->dev_base_seq;
Using RCU read lock is OK but that means you must be prepared to
handle additions/removals to the table between dump iterations
and thus you must introduce a seq counter bumped on each table
change and add it to the dev_base_seq above.
> + for_each_netdev_rcu(net, dev) {
> + if (dev->priv_flags & IFF_EBRIDGE) {
> + struct br_port_msg *bpm;
> +
> + if (idx < s_idx)
> + goto cont;
> +
> + nlh = nlmsg_put(skb, NETLINK_CB(cb->skb).portid,
> + seq, RTM_GETMDB,
> + sizeof(*bpm), NLM_F_MULTI);
> + if (nlh == NULL)
> + break;
> +
> + bpm = nlmsg_data(nlh);
> + bpm->ifindex = dev->ifindex;
> + if (br_mdb_fill_info(skb, cb, seq, dev) < 0) {
> + printk(KERN_INFO "br_mdb_fill_info failed\n");
> + goto fail;
As stated above I believe that you should allow for hashtable to be
split across multiple messages so you need to store the hash table
offset as well and properly finalize and send the message on error
here.
^ permalink raw reply
* Re: [RFC PATCH 1/2] bridge: export port_no and port_id via IFA_INFO_DATA
From: Thomas Graf @ 2012-11-27 12:00 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, bridge, Herbert Xu, Stephen Hemminger, David S. Miller,
Jesper Dangaard Brouer
In-Reply-To: <1354009785-20014-1-git-send-email-amwang@redhat.com>
On 11/27/12 at 05:49pm, Cong Wang wrote:
> Based on net-next.
>
> This patch exports port->port_no port->port_id in the end of IFA_INFO_DATA.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* [PATCH 1/2] arping: Fix finding of a default interface when no -I is specified.
From: Jan Synacek @ 2012-11-27 12:19 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
By default, no interface string should be supplied. This ensures that we can
recognize if an interface was specified or omitted. Previously, when -I was not
used, default interface string was compiled-in and the automatic selection
didn't work correctly.
RH-Bugzilla: #879807
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
Makefile | 4 +---
arping.c | 11 ++---------
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index ae92f34..b5bf84f 100644
--- a/Makefile
+++ b/Makefile
@@ -24,8 +24,6 @@ USE_SYSFS=no
USE_IDN=no
# Do not use getifaddrs
WITHOUT_IFADDRS=no
-# arping default device
-ARPING_DEFAULT_DEVICE=eth0
# rdisc server (-r option) support
ENABLE_RDISC_SERVER=no
# ping6 source routing (deprecated by RFC5095)
@@ -99,7 +97,7 @@ $(TARGETS): %: %.o
# -------------------------------------
# arping
-DEF_arping = $(DEF_SYSFS) $(DEF_CAP) $(DEF_IDN) $(DEF_WITHOUT_IFADDRS) -DDEFAULT_DEVICE=\"$(ARPING_DEFAULT_DEVICE)\"
+DEF_arping = $(DEF_SYSFS) $(DEF_CAP) $(DEF_IDN) $(DEF_WITHOUT_IFADDRS)
LIB_arping = $(LIB_SYSFS) $(LIB_CAP) $(LIB_IDN)
# clockdiff
diff --git a/arping.c b/arping.c
index f6433c2..ccb68a0 100644
--- a/arping.c
+++ b/arping.c
@@ -55,13 +55,6 @@ struct sysf_devattr_values;
static void usage(void) __attribute__((noreturn));
-#ifdef DEFAULT_DEVICE
-# define DEFAULT_DEVICE_STR DEFAULT_DEVICE
-#else
-# define DEFAULT_DEVICE_STR "no default"
-# define DEFAULT_DEVICE NULL
-#endif
-
struct device {
char *name;
int ifindex;
@@ -75,7 +68,7 @@ struct device {
int quit_on_reply=0;
struct device device = {
- .name = DEFAULT_DEVICE,
+ .name = NULL,
};
char *source;
struct in_addr src, dst;
@@ -128,7 +121,7 @@ void usage(void)
" -V : print version and exit\n"
" -c count : how many packets to send\n"
" -w timeout : how long to wait for a reply\n"
- " -I device : which ethernet device to use (" DEFAULT_DEVICE_STR ")\n"
+ " -I device : which ethernet device to use\n"
" -s source : source ip address\n"
" destination : ask for what ip address\n"
);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/2] arping: Call usage() before limiting capabilities.
From: Jan Synacek @ 2012-11-27 12:19 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
In-Reply-To: <1354018775-4966-1-git-send-email-jsynacek@redhat.com>
Otherwise, running arping binary without the capabilities set results in printing
warnings with the usage.
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
arping.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arping.c b/arping.c
index ccb68a0..02e3d9c 100644
--- a/arping.c
+++ b/arping.c
@@ -959,19 +959,6 @@ main(int argc, char **argv)
int socket_errno;
int ch;
- limit_capabilities();
-
-#ifdef USE_IDN
- setlocale(LC_ALL, "");
-#endif
-
- enable_capability_raw();
-
- s = socket(PF_PACKET, SOCK_DGRAM, 0);
- socket_errno = errno;
-
- disable_capability_raw();
-
while ((ch = getopt(argc, argv, "h?bfDUAqc:w:s:I:V")) != EOF) {
switch(ch) {
case 'b':
@@ -1023,6 +1010,19 @@ main(int argc, char **argv)
target = *argv;
+ limit_capabilities();
+
+#ifdef USE_IDN
+ setlocale(LC_ALL, "");
+#endif
+
+ enable_capability_raw();
+
+ s = socket(PF_PACKET, SOCK_DGRAM, 0);
+ socket_errno = errno;
+
+ disable_capability_raw();
+
if (device.name && !*device.name)
device.name = NULL;
--
1.7.11.7
^ permalink raw reply related
* Re: smsc95xx: detect chip revision specific features
From: Steve Glendinning @ 2012-11-27 12:32 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev
In-Reply-To: <20121126204722.GA26463@elgon.mountain>
Hi Dan,
> drivers/net/usb/smsc95xx.c
> 1283 if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
> 1284 u32 *filter_mask = kzalloc(32, GFP_KERNEL);
> ^^
> We allocate 8 unsigned 32 bit values. I think this is the mistake here
> actually. It is a typo and should say:
>
> u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
>
> If 8 elements was the intent then that's nasty.
Good spot! 8 32-bit elements was the intent, but all the following
code is actually accessing it using what should be byte offsets. So I
think this should read:
u8 *filter_mask = kzalloc(32, GFP_KERNEL);
The rest of the code following makes sense then, up until:
> 1349 ret = smsc95xx_write_reg_nopm(dev, WUFF, filter_mask[i]);
Which we'll need to change so it dereferences a u32 at that offset
instead of a u8, something like *((u32 *)&filter_mask[i])
If this looks good to you I'll prepare a patch?
Steve
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-27 12:36 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <9AA65D849A88EB44B5D9B6A8BA098E23040A60D6EE70@Exchange1.lawo.de>
On Tue, 2012-11-27 at 10:36 +0100, Keitel, Tino (ALC NetworX GmbH)
wrote:
> On Mo, 2012-11-26 at 09:17 -0800, Eric Dumazet wrote:
> > On Mon, 2012-11-26 at 18:08 +0100, Keitel, Tino (ALC NetworX GmbH)
> > wrote:
> > > On Mo, 2012-11-26 at 08:34 -0800, Eric Dumazet wrote:
> > > > On Mon, 2012-11-26 at 11:01 +0100, Tino Keitel wrote:
> > > > > On Sat, Nov 24, 2012 at 15:43:36 -0800, Eric Dumazet wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > Hmm, I wonder if BQL makes a particular bug showing more often.
> > > > > >
> > > > > > I see gianfar uses a very small watchdog_timeo of 1 second, while many
> > > > > > drivers use 5 seconds.
> > > > > >
> > > > > > What happens if you change this to 5 seconds ?
> > > > >
> > > > > I still got the trace and a failing ptp client.
> > > > >
> > > >
> > > > Thanks. Is this bug easy to trigger ?
> > > >
> > > > I suspect a core issue and a race, likely to happen on your (non x86)
> > > > hardware
> > > >
> > > > Could you add the following debugging patch ?
> > >
> > > No visible difference:
> >
> > OK it seems you trigger the problem fast !
> >
> > Please try the following as well :
>
> Hi,
>
> yes, it can be triggered within 2 minutes.
>
> The patch makes no difference:
Can you reproduce the problem using a single cpu ?
^ permalink raw reply
* Re: smsc95xx: detect chip revision specific features
From: Dan Carpenter @ 2012-11-27 12:39 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev
In-Reply-To: <CAKh2mn4x=0HwUdH8hSbk3fsa16RUBqze_n5XegVjRBsTnT08SA@mail.gmail.com>
On Tue, Nov 27, 2012 at 12:32:26PM +0000, Steve Glendinning wrote:
> Hi Dan,
>
> > drivers/net/usb/smsc95xx.c
> > 1283 if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
> > 1284 u32 *filter_mask = kzalloc(32, GFP_KERNEL);
> > ^^
> > We allocate 8 unsigned 32 bit values. I think this is the mistake here
> > actually. It is a typo and should say:
> >
> > u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
> >
> > If 8 elements was the intent then that's nasty.
>
> Good spot! 8 32-bit elements was the intent, but all the following
> code is actually accessing it using what should be byte offsets. So I
> think this should read:
>
> u8 *filter_mask = kzalloc(32, GFP_KERNEL);
>
> The rest of the code following makes sense then, up until:
>
> > 1349 ret = smsc95xx_write_reg_nopm(dev, WUFF, filter_mask[i]);
>
> Which we'll need to change so it dereferences a u32 at that offset
> instead of a u8, something like *((u32 *)&filter_mask[i])
>
> If this looks good to you I'll prepare a patch?
>
Sound fine to me. Could you give me the Reported-by: tag?
regards,
dan carpenter
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Keitel, Tino (ALC NetworX GmbH) @ 2012-11-27 12:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <1354019816.7553.1585.camel@edumazet-glaptop>
On Di, 2012-11-27 at 04:36 -0800, Eric Dumazet wrote:
>
> Can you reproduce the problem using a single cpu ?
Yes, it is a single-CPU system.
Regards,
Tino
^ permalink raw reply
* Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
From: Richard Cochran @ 2012-11-27 12:47 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, davem, linux-arm-kernel, linux-omap, b-cousson, paul
In-Reply-To: <1354012034-31686-1-git-send-email-mugunthanvnm@ti.com>
On Tue, Nov 27, 2012 at 03:57:14PM +0530, Mugunthan V N wrote:
> CC drivers/net/ethernet/ti/cpts.o
> drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory
> compilation terminated.
> make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> make[3]: *** [drivers/net/ethernet/ti] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
>
> fix for build break as the header file is removed from plat-omap as part of
> the below patch
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [PATCH] ping,tracepath doc: Fix missing end tags.
From: Jan Synacek @ 2012-11-27 13:01 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
doc/ping.sgml | 1 +
doc/tracepath.sgml | 1 +
2 files changed, 2 insertions(+)
diff --git a/doc/ping.sgml b/doc/ping.sgml
index f77276b..fb3c3ac 100644
--- a/doc/ping.sgml
+++ b/doc/ping.sgml
@@ -130,6 +130,7 @@ If value is zero, kernel allocates random flow label.
<listitem><para>
Show help.
</para></listitem>
+ </varlistentry>
<varlistentry>
<term><option>-i <replaceable/interval/</option></term>
<listitem><para>
diff --git a/doc/tracepath.sgml b/doc/tracepath.sgml
index 8da7cc0..19c3903 100644
--- a/doc/tracepath.sgml
+++ b/doc/tracepath.sgml
@@ -72,6 +72,7 @@ Sets the initial packet length to <replaceable/pktlen/ instead of
<listitem><para>
Sets the initial destination port to use.
</para></listitem>
+ </varlistentry>
</variablelist>
</refsect1>
--
1.7.11.7
^ permalink raw reply related
* Re: [net-next RFC v2] net_cls: traffic counter based on classification control cgroup
From: Daniel Wagner @ 2012-11-27 13:02 UTC (permalink / raw)
To: Alexey Perevalov
Cc: Glauber Costa, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Kyungmin Park
In-Reply-To: <50B49DEA.7010000-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Hi Alexey,
On 27.11.2012 12:03, Glauber Costa wrote:
> On 11/27/2012 02:56 PM, Alexey Perevalov wrote:
>> Hello.
>>
>> It's second version of patch I already sent to netdev.
>>
>> The main goal of this patch it's counting traffic for process placed to
>> net_cls cgroup (ingress and egress).
>> It's based on res_counters and holds counter per network interfaces.
>>
>> Description of patch.
>> It handles packets in net/core/dev.c for egress and in
>> /net/ipv4/tcp.c|udp.c for ingress.
>> These places were chosen because we need to know also network interface.
>>
>> Cgroup fs interface provides following files additional to existing
>> net_cls files:
>> net_cls.ifacename.usage_in_bytes
>> Containing rcv/snd lines.
>> Also this patch adds to net_cls ability to handle a network device
>> registration.
>>
>> It could be included or excluded in compile time.
>> I moved the menu entry for "Control group classifier" from network/QoS to
>> General Option/Control Group.
>>
>> I'm waiting for you comments.
>>
>
> Daniel Wagner is working on something a lot similar.
Yes, basically what I try to do is explained by this excellent article
https://lwn.net/Articles/523058/
The short version: Per application routing and statistics.
I have two PoC implementation doing this. Both implementation have the same key
idea which is to set SO_MARK per application. The routing and statistics would
then be done by a bunch iptables rules.
In the first implementation extends net_cls to set SO_MARK:
void sock_update_classid(struct sock *sk, struct task_struct *task)
{
u32 classid;
+ u32 mark;
classid = task_cls_classid(task);
if (classid != sk->sk_classid)
sk->sk_classid = classid;
+
+ mark = task_cls_mark(task);
+ if (mark != sk->sk_mark)
+ sk->sk_mark = mark;
}
The second implementation is adding a new iptables matcher which matches
on LSM contexts. Then you can do something like this:
iptables -t mangle -A OUTPUT -m secmark --secctx unconfined_u:unconfined_r:foo_t:s0-s0:c0.c1023 -j MARK --set-mark 200
> Maybe you should be in contact, in case you are not yet.
>
> A few general comments:
> 1) res_counters are incredibly expensive. If you are more interested in
> counting than you are in limiting, they may not be your best choice.
>
> 2) When Daniel exposed his use case to me, it gave me the impression
> that "counting traffic" is something that is totally doable by having a
> dedicated interface in a separate namespace. Basically, we already count
> traffic (rx and tx) for all interfaces anyway, so it suggests that it
> could be an interesting way to see the problem.
Moving applications into separate net namespaces is for sure a valid solution.
Though there is a one drawback in this approach. The namespaces need to be
attached to a bridge and then some NATting. That means every application
would get it's own IP address. This might be okay for your certain use
cases but I am still trying to work around this. Glauber and I had some
discussion about this and he suggested to allow the physical networking
device to be attached to several namespaces (e.g. via macvlan). Every
namespace would get the same IP address. Unfortunately, this would result in
the same mess as several physical devices on a network get the same
IP address assigned.
> AFAIK, Daniel is still measuring this. But it would be great to know if
> that could work for your use case as well.
I have not started to measure :(
cheers,
daniel
^ permalink raw reply
* Re: [PATCH] ping,tracepath doc: Fix missing end tags.
From: YOSHIFUJI Hideaki @ 2012-11-27 13:09 UTC (permalink / raw)
To: Jan Synacek; +Cc: netdev, YOSHIFUJI Hideaki
In-Reply-To: <1354021311-16760-1-git-send-email-jsynacek@redhat.com>
Hello.
Jan Synacek wrote:
> Signed-off-by: Jan Synacek <jsynacek@redhat.com>
> ---
> doc/ping.sgml | 1 +
> doc/tracepath.sgml | 1 +
> 2 files changed, 2 insertions(+)
>
Applied, thank you.
--yoshfuji
^ permalink raw reply
* Re: smsc95xx: detect chip revision specific features
From: Steve Glendinning @ 2012-11-27 13:21 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev
In-Reply-To: <20121127123957.GT6186@mwanda>
>> > drivers/net/usb/smsc95xx.c
>> > 1283 if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
>> > 1284 u32 *filter_mask = kzalloc(32, GFP_KERNEL);
>> > ^^
>> > We allocate 8 unsigned 32 bit values. I think this is the mistake here
>> > actually. It is a typo and should say:
<snip>
On re-reading the datasheet we *do* need 32 u32's here so you were
right the first time! Patch on its way shortly.
Steve
^ permalink raw reply
* [PATCH] smsc95xx: fix suspend buffer overflow
From: Steve Glendinning @ 2012-11-27 13:23 UTC (permalink / raw)
To: netdev; +Cc: dan.carpenter, Steve Glendinning
This patch fixes a buffer overflow introduced by bbd9f9e, where
the filter_mask array is accessed beyond its bounds.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/net/usb/smsc95xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 79d495d..6cdc504 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1281,7 +1281,7 @@ static int smsc95xx_suspend(struct usb_interface *intf, pm_message_t message)
}
if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
- u32 *filter_mask = kzalloc(32, GFP_KERNEL);
+ u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
u32 command[2];
u32 offset[2];
u32 crc[4];
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH RFC 3/5] printk: modify printk interface for syslog_namespace
From: Libo Chen @ 2012-11-27 13:25 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W. Biederman
In-Reply-To: <20121125042802.GB4523-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 2012-11-25 12:28, Serge E. Hallyn wrote:
> Quoting Libo Chen (chenlibo.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
>> On 2012/11/22 1:49, Serge E. Hallyn wrote:
>>
>>> I notice that you haven't made any changes to the struct cont. I
>>> suspect this means that to-be-continued msgs from one ns can be
>>> erroneously mixed with another ns.
>>>
>> Yes, I confirmed this problem. There will be erroneously mixed with another ns.
>> Thank you very much.
>>
>>> You said you don't mind putting the syslogns into the userns. If
>>> there's no reason not to do that, then we should do so as it will
>>> remove a bunch of code (plus the use of a new CLONE flag) from your
>>> patch, and the new syslog(NEW_NS) command from mine.
>>>
>> I agree with you, both are removable.
>>
>>> Now IMO the ideal place for syslog_ns would be in the devices ns,
>>> but that does not yet exist, and may never. The bonus to that would
>>> be that the consoles sort of belong there. I avoid this by not
>>> having consoles in child syslog namespaces. You put the console in
>>> the ns. I haven't looked closely enough to see if what you do is
>>> ok (will do so soon).
>>>
>>> WOuld you mind looking through my patch to see if it suffices for
>>> your needs? Where it does not, patches would be greatly appreciated
>>> if simple enough.
>>
>> follow your patch, I can see inject message by "dmesg call" in container, is right?
>
> If I understand you right, yes.
>
>> I am worry that I debug or see messages from serial ports console in some embedded system,
>> since console belongs to init_syslog, so the message in container can`t be printed.
>
> Sorry, I don't understand which way you're going with that. Could you
> rephrase? You want to prevent console messages from going to a
> container? (That should definately not happen) Or something else?
>
I reviewed your patch, and found that console could only print messages
belonging to init_syslog.
So the message belongs to container syslog can not be printed from console,
but only "dmesg call" in user space. Is that right?
For example, the messages can not be outputed automatically from serial port
as a kind of consoles on some embedded system.
And I am not sure if there are no other problems.
thanks!
>>> Note I'm not at all wedded to my patchset. I'm happy to go with
>>> something else entirely. My set was just a proof of concept.
>
> thanks,
> -serge
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
>
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse @ 2012-11-27 13:27 UTC (permalink / raw)
To: Chas Williams (CONTRACTOR); +Cc: Krzysztof Mazur, netdev, linux-kernel, davem
In-Reply-To: <201211112257.qABMvhP4021769@thirdoffive.cmf.nrl.navy.mil>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
On Sun, 2012-11-11 at 17:57 -0500, Chas Williams (CONTRACTOR) wrote:
> In message <1352667081.9449.135.camel@shinybook.infradead.org>,David Woodhouse writes:
> >Acked-by: David Woodhouse <David.Woodhouse@intel.com> for your new
> >version of patch #6 (returning DROP_PACKET for !VF_READY), and your
> >followup to my patch #8, adding the 'need_wakeup' flag. Which we might
> >as well merge into (the pppoatm part of) my patch.
> >
> >Chas, are you happy with the generic ATM part of that? And the
> >nomenclature? I didn't want to call it 'release_cb' like the core socket
> >code does, because we use 'release' to mean something different in ATM.
> >So I called it 'unlock_cb' instead...
>
> i really would prefer not to use a strange name since it might confuse
> larger group of people who are more familiar with the traditional meaning
> of this function. vcc_release() isnt exported so we could rename it if
> things get too confusing.
>
> i have to look at this a bit more but we might be able to use release_cb
> to get rid of the null push to detach the underlying protocol. that would
> be somewhat nice.
In the meantime, should I resend this patch with the name 'release_cb'
instead of 'unlock_cb'? I'll just put a comment in to make sure it isn't
confused with vcc_release(), and if we need to change vcc_release()
later we can.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Ethernet deferred 'end of transmit' processing.
From: David Laight @ 2012-11-27 13:28 UTC (permalink / raw)
To: netdev
Eric and I have just had a private discussion about deferring
(or not) the ethernet 'end of tx' processing.
Below is Eric's last email.
> > Subject: RE: performance regression on HiperSockets depending on MTU size
> >
> > On Mon, 2012-11-26 at 16:38 +0000, David Laight wrote:
> > > > For example, I had to change mlx4 driver for the same problem : Make
> > > > sure a TX packet can be "TX completed" in a short amount of time.
> > >
> > > I'm intrigued that Linux is going that way.
> > > It (effectively) requires the hardware generate an interrupt
> > > for every transmit packet in order to get high throughput.
> > >
> > > I remember carefully designing ethernet drivers to avoid
> > > taking 'tx done' interrupts unless absolutely necessary
> > > in order to reduce system interrupt load.
> > > Some modern hardware probably allows finer control of 'tx done'
> > > interrupts, but it won't be universal.
> > >
> > > I realise that hardware TX segmentation offload can cause a
> > > single tx ring entry to take a significant amount of time to
> > > transmit - so allowing a lot of packets to sit in the tx
> > > ring causes latency issues.
> > >
> > > But there has to be a better solution than requiring every
> > > tx to complete very quickly - especially if the tx flow
> > > is actually a lot of small packets.
> > >
> > > David
> > >
> >
> > 20 years ago, interrupts were expensive so you had to batch packets.
> >
> > In 2012, we want low latencies, because hardware is fast and is able to
> > cope with the requirement.
> >
> > Instead of one cpu, we now have 24 cpus or more per host.
> >
> > And if there is enough load, NAPI will really avoid interrupts, and you
> > get full batch advantages (lowering the number of cpu cycles per packet)
>
> AFAICT some of the stuff being done to get 10G+ speeds is
> actually similar to what I was doing trying to saturate
> 10M ethernet. Network speeds have increased by a factor
> of (about) 800, cpu clock speeds only by 100 or so
> (we were doing quad cpu sparc systems with quite slow
> cache coherency operations).
> Somewhere in the last 20 years a lot of code has got very lazy!
>
> Using 'source allocated' byte counts for flow control
> (which is what I presume the socket send code does) so that
> each socket has a limited amount of live data in the kernel
> and can't allocate a new buffer (skb) until the amount of
> kernel memory allocated to the 'live' buffers decreases
> (ie a transmit completes) certainly works a lot better
> that the target queue size flow control attempted by SYSV
> STREAMS (which doesn't work very well at all!).
>
> What might work is to allow the ethernet driver to reassign
> some bytes of the SKB from the socket (or other source) to
> the transmit interface - then it need not request end of tx
> immediately for those bytes.
It seems you understood how it currently works.
> The amount it could take can be quite small - possibly one
> or two maximal sized ring entries, or (say) 100us of network
> time.
>
> With multiple flows this will make little difference to the
> size of the burst that each socket gets to add into the
> interfaces tx queue (unlike increasing the socket tx buffer).
> But with a single flow it will let the socket get the next
> tx data queued even if the tx interrupts are deferred.
>
> The only time it doesn't help is when the next transmit
> can't be done until the reference count on the skb decreases.
> (We had some NFS code like that!)
If you read the code, you'll see current implementation is able to keep
a 20Gbe link busy with a single tcp flow, with 2 TSO packets posted on
the device.
A TSO packet is about 545040 bits on wire, or 27 us.
That's 36694 interrupts per second. Even my phone is able to sustain this
rate of interrupts.
But if the device holds the TX completion interrupt for 100 us,
performance of a single TCP flow is hurt. I don't think it's hard to
understand.
mlx4 driver handles 40Gbe links, 13 us is the needed value, not 100 us.
Please post these mails to netdev, there is no secret to protect.
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-27 13:32 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <9AA65D849A88EB44B5D9B6A8BA098E23040A60D6EE71@Exchange1.lawo.de>
On Tue, 2012-11-27 at 13:42 +0100, Keitel, Tino (ALC NetworX GmbH)
wrote:
> On Di, 2012-11-27 at 04:36 -0800, Eric Dumazet wrote:
> >
> > Can you reproduce the problem using a single cpu ?
>
> Yes, it is a single-CPU system.
Can you reproduce the problem without PTP running, or disabled in the
driver ?
(comment the "priv->hwts_tx_en = 1;" line)
This looks like we miss an interrupt ( or TXBD_INTERRUPT not correctly
set)
And it could be a bug occurring if we try to send one skb with fragments
and skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP
^ permalink raw reply
* Re: [PATCH RFC] [INET]: Get cirtical word in first 64bit of cache line
From: Ling Ma @ 2012-11-27 13:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1353912241.30446.1257.camel@edumazet-glaptop>
> networking patches should be sent to netdev.
>
> (I understand this patch is more a generic one, but at least CC netdev)
Ling: OK, this is my first inet patch, I will send to netdev later.
> You give no performance numbers for this change...
Ling: after I get machine, I will send out test result.
> I never heard of this CWF/ER, where are the official Intel documents
> about this, and what models really benefit from it ?
Ling:
Arm implemented it.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Caccifbd.html
AMD also used it.
http://classes.soe.ucsc.edu/cmpe202/Fall04/papers/opteron.pdf
> Also, why not moving skc_net as well ?
>
> BTW, skc_daddr & skc_rcv_saddr are 'critical' as well, we use them in
> INET_MATCH()
Ling: in the looking-up routine, hash value is the most important key,
if it is matched, the other values have most possibility to be
satisfied, and CFW is limited by memory bandwidth(64bit usually), so
we only move hash value as critical first word.
Thanks
Ling
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-27 13:49 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Tino Keitel, Paul Gortmaker, netdev@vger.kernel.org
In-Reply-To: <1354023162.7553.1708.camel@edumazet-glaptop>
On Tue, 2012-11-27 at 05:32 -0800, Eric Dumazet wrote:
> Can you reproduce the problem without PTP running, or disabled in the
> driver ?
>
> (comment the "priv->hwts_tx_en = 1;" line)
>
>
> This looks like we miss an interrupt ( or TXBD_INTERRUPT not correctly
> set)
>
> And it could be a bug occurring if we try to send one skb with fragments
> and skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP
>
>
By the way are any errata flagged in gfar_detect_errata() ?
^ permalink raw reply
* Re: [PATCH RFC] [INET]: Get cirtical word in first 64bit of cache line
From: Eric Dumazet @ 2012-11-27 13:58 UTC (permalink / raw)
To: Ling Ma; +Cc: linux-kernel, netdev
In-Reply-To: <CAOGi=dPQWC8hgt4jhMEHcVPb6j+jMTguNAchiLjdvvHjarCW4Q@mail.gmail.com>
On Tue, 2012-11-27 at 21:48 +0800, Ling Ma wrote:
> Ling: in the looking-up routine, hash value is the most important key,
> if it is matched, the other values have most possibility to be
> satisfied, and CFW is limited by memory bandwidth(64bit usually), so
> we only move hash value as critical first word.
In practice, we have at most one TCP socket per hash slot.
99.9999 % of lookups need all fields to complete.
Your patch introduces a misalignment error. I am not sure all 64 bit
arches are able to cope with that gracefully.
It seems all CWF docs I could find are very old stuff, mostly academic,
without good performance data.
I was asking for up2date statements from Intel/AMD/... about current
cpus and current memory. Because optimizing for 10 years olds cpus is
not worth the pain.
I am assuming cpus are implementing the CWF/ER automatically, and that
only prefetches could have a slight disadvantage if the needed word is
not the first word in the cache line. Its not clear why the prefetch()
hint could not also use CWF. It seems it also could be done by the
hardware.
So before random patches in linux kernel adding their possible bugs, we
need a good study.
Thanks
^ permalink raw reply
* Re: [PATCH RFC 3/5] printk: modify printk interface for syslog_namespace
From: Serge Hallyn @ 2012-11-27 13:58 UTC (permalink / raw)
To: Libo Chen
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W. Biederman
In-Reply-To: <50B4BF64.6010707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Quoting Libo Chen (chenlibo.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> From: Libo Chen <clbchenlibo.chen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> On 2012-11-25 12:28, Serge E. Hallyn wrote:
> > Quoting Libo Chen (chenlibo.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> >> On 2012/11/22 1:49, Serge E. Hallyn wrote:
> >>
> >>> I notice that you haven't made any changes to the struct cont. I
> >>> suspect this means that to-be-continued msgs from one ns can be
> >>> erroneously mixed with another ns.
> >>>
> >> Yes, I confirmed this problem. There will be erroneously mixed with another ns.
> >> Thank you very much.
> >>
> >>> You said you don't mind putting the syslogns into the userns. If
> >>> there's no reason not to do that, then we should do so as it will
> >>> remove a bunch of code (plus the use of a new CLONE flag) from your
> >>> patch, and the new syslog(NEW_NS) command from mine.
> >>>
> >> I agree with you, both are removable.
> >>
> >>> Now IMO the ideal place for syslog_ns would be in the devices ns,
> >>> but that does not yet exist, and may never. The bonus to that would
> >>> be that the consoles sort of belong there. I avoid this by not
> >>> having consoles in child syslog namespaces. You put the console in
> >>> the ns. I haven't looked closely enough to see if what you do is
> >>> ok (will do so soon).
> >>>
> >>> WOuld you mind looking through my patch to see if it suffices for
> >>> your needs? Where it does not, patches would be greatly appreciated
> >>> if simple enough.
> >>
> >> follow your patch, I can see inject message by "dmesg call" in container, is right?
> >
> > If I understand you right, yes.
> >
> >> I am worry that I debug or see messages from serial ports console in some embedded system,
> >> since console belongs to init_syslog, so the message in container can`t be printed.
> >
> > Sorry, I don't understand which way you're going with that. Could you
> > rephrase? You want to prevent console messages from going to a
> > container? (That should definately not happen) Or something else?
> >
>
> I reviewed your patch, and found that console could only print messages
> belonging to init_syslog.
>
> So the message belongs to container syslog can not be printed from console,
> but only "dmesg call" in user space. Is that right?
>
> For example, the messages can not be outputed automatically from serial port
> as a kind of consoles on some embedded system.
Oh, I see. I basically thought this was a feature, not a problem :) But
that wasn't meant to be a core part of my patchset, rather I wasn't quite
sure how best to handle it, so I put it off for later. My main concern is
that if consoles in containers are supported, this must NOT lead to
kernel module loading from the container.
> And I am not sure if there are no other problems.
Ok, I will write a new patch which would (a) try to address the consoles,
(b) move the syslogns into the user_ns (making it no longer a syslog_ns),
and (c) adding some users of ns_printk (borrowing the ones from your
set for starters).
thanks,
-serge
^ permalink raw reply
* [PATCH] sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
From: Tommi Rantala @ 2012-11-27 14:01 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Neil Horman, Vlad Yasevich, Sridhar Samudrala, David S. Miller,
Dave Jones, Tommi Rantala
In-Reply-To: <20121126.173429.323283427379416132.davem@davemloft.net>
Trinity (the syscall fuzzer) discovered a memory leak in SCTP,
reproducible e.g. with the sendto() syscall by passing invalid
user space pointer in the second argument:
#include <string.h>
#include <arpa/inet.h>
#include <sys/socket.h>
int main(void)
{
int fd;
struct sockaddr_in sa;
fd = socket(AF_INET, SOCK_STREAM, 132 /*IPPROTO_SCTP*/);
if (fd < 0)
return 1;
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("127.0.0.1");
sa.sin_port = htons(11111);
sendto(fd, NULL, 1, 0, (struct sockaddr *)&sa, sizeof(sa));
return 0;
}
As far as I can tell, the leak has been around since ~2003.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
---
net/sctp/chunk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index 7c2df9c..f2aebdb 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chunk.c
@@ -284,7 +284,7 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
goto errout;
err = sctp_user_addto_chunk(chunk, offset, len, msgh->msg_iov);
if (err < 0)
- goto errout;
+ goto errout_chunk_free;
offset += len;
@@ -324,7 +324,7 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
__skb_pull(chunk->skb, (__u8 *)chunk->chunk_hdr
- (__u8 *)chunk->skb->data);
if (err < 0)
- goto errout;
+ goto errout_chunk_free;
sctp_datamsg_assign(msg, chunk);
list_add_tail(&chunk->frag_list, &msg->chunks);
@@ -332,6 +332,9 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
return msg;
+errout_chunk_free:
+ sctp_chunk_free(chunk);
+
errout:
list_for_each_safe(pos, temp, &msg->chunks) {
list_del_init(pos);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] smsc75xx enhancements
From: Steve Glendinning @ 2012-11-27 14:28 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
This patchset implements wake on PHY (link up or link down) for
smsc75xx, please consider for net-next.
Steve Glendinning (2):
smsc75xx: refactor entering suspend modes
smsc75xx: support PHY wakeup source
drivers/net/usb/smsc75xx.c | 224 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 186 insertions(+), 38 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/2] smsc75xx: refactor entering suspend modes
From: Steve Glendinning @ 2012-11-27 14:28 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
In-Reply-To: <1354026482-10443-1-git-send-email-steve.glendinning@shawell.net>
This patch splits out the logic for entering suspend modes
to separate functions, to reduce the complexity of the
smsc75xx_suspend function.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/net/usb/smsc75xx.c | 62 +++++++++++++++++++++++++++-----------------
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 953c4f4..4655c01 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -1213,6 +1213,42 @@ static int smsc75xx_write_wuff(struct usbnet *dev, int filter, u32 wuf_cfg,
return 0;
}
+static int smsc75xx_enter_suspend0(struct usbnet *dev)
+{
+ u32 val;
+ int ret;
+
+ ret = smsc75xx_read_reg_nopm(dev, PMT_CTL, &val);
+ check_warn_return(ret, "Error reading PMT_CTL\n");
+
+ val &= (~(PMT_CTL_SUS_MODE | PMT_CTL_PHY_RST));
+ val |= PMT_CTL_SUS_MODE_0 | PMT_CTL_WOL_EN | PMT_CTL_WUPS;
+
+ ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
+ check_warn_return(ret, "Error writing PMT_CTL\n");
+
+ smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
+
+ return 0;
+}
+
+static int smsc75xx_enter_suspend2(struct usbnet *dev)
+{
+ u32 val;
+ int ret;
+
+ ret = smsc75xx_read_reg_nopm(dev, PMT_CTL, &val);
+ check_warn_return(ret, "Error reading PMT_CTL\n");
+
+ val &= ~(PMT_CTL_SUS_MODE | PMT_CTL_WUPS | PMT_CTL_PHY_RST);
+ val |= PMT_CTL_SUS_MODE_2;
+
+ ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
+ check_warn_return(ret, "Error writing PMT_CTL\n");
+
+ return 0;
+}
+
static int smsc75xx_suspend(struct usb_interface *intf, pm_message_t message)
{
struct usbnet *dev = usb_get_intfdata(intf);
@@ -1244,17 +1280,7 @@ static int smsc75xx_suspend(struct usb_interface *intf, pm_message_t message)
ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
check_warn_return(ret, "Error writing PMT_CTL\n");
- /* enter suspend2 mode */
- ret = smsc75xx_read_reg_nopm(dev, PMT_CTL, &val);
- check_warn_return(ret, "Error reading PMT_CTL\n");
-
- val &= ~(PMT_CTL_SUS_MODE | PMT_CTL_WUPS | PMT_CTL_PHY_RST);
- val |= PMT_CTL_SUS_MODE_2;
-
- ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
- check_warn_return(ret, "Error writing PMT_CTL\n");
-
- return 0;
+ return smsc75xx_enter_suspend2(dev);
}
if (pdata->wolopts & (WAKE_MCAST | WAKE_ARP)) {
@@ -1368,19 +1394,7 @@ static int smsc75xx_suspend(struct usb_interface *intf, pm_message_t message)
/* some wol options are enabled, so enter SUSPEND0 */
netdev_info(dev->net, "entering SUSPEND0 mode\n");
-
- ret = smsc75xx_read_reg_nopm(dev, PMT_CTL, &val);
- check_warn_return(ret, "Error reading PMT_CTL\n");
-
- val &= (~(PMT_CTL_SUS_MODE | PMT_CTL_PHY_RST));
- val |= PMT_CTL_SUS_MODE_0 | PMT_CTL_WOL_EN | PMT_CTL_WUPS;
-
- ret = smsc75xx_write_reg_nopm(dev, PMT_CTL, val);
- check_warn_return(ret, "Error writing PMT_CTL\n");
-
- smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
-
- return 0;
+ return smsc75xx_enter_suspend0(dev);
}
static int smsc75xx_resume(struct usb_interface *intf)
--
1.7.10.4
^ permalink raw reply related
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