* Re: [PATCH 1/2] net, vxlan Fix compile warning [v3]
From: David Miller @ 2013-09-19 13:09 UTC (permalink / raw)
To: prarit; +Cc: netdev, jpirko, stephen, bhutchings
In-Reply-To: <1379595894-23200-1-git-send-email-prarit@redhat.com>
You must resend all of the patches in the series when you make
updates, not just the patches you have changed.
^ permalink raw reply
* Re: [PATCH] USBNET: fix handling padding packet
From: Ming Lei @ 2013-09-19 13:08 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, David S. Miller, Greg Kroah-Hartman,
Network Development, linux-usb
In-Reply-To: <87wqmd46vj.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
>> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>>> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
>>
>>> >No, USB 3.0 uses no companion controllers, so you can have devices
>>> >of any speed connected to it.
>>> >
>>>
>>> Ah, right. I don't own such modern hardware, but I should have known
>>> this anyway.
>>>
>>> This still doesn't change the fact that the driver is brand new for
>>> brand new devices. I believe we should assume such devices will
>>> support ZLPs unless we have documentation stating anything else.
>>
>> For such devices we might assume it. But how does that matter for
>> generic code?
>
> The code isn't generic yet. Most of it is placed inside the
> ax88179_178a minidriver.
No, the patch doesn't touch code of ax99179_178a.
And it is really generic to fix the padding in case of dma sg.
>
> But I do agree that adding this padding support can be seen as one step
> towards making the code generic. So if you really anticipate this being
> enabled for e.g. the ECM class driver, then yes, padding must be
> supported.
1byte padding frame is already supported by usbnet before, isn't it?
>
> I would have had less trouble understanding the value if this patch was
> part of a generalisation series, though...
As my below test on ax99179_178a, I believe the patch should fix padding
for dma sg, but need a little update, and I will send out v1 later:
$ping -s 974 another_machine #from host with ax99179_178a attached
If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any
more either on USB3.0 or USB 2.0 host controller.
So don't assume that these brand new devices can support ZLP well.
>
>> As any kind of device may be connected to XHCI, the sg
>> code is relevant for every driver. And I certainly don't want trouble
>> for older devices' drivers converted to sg.
>
> I wonder what the gain of that really is? Yes, I can see the advantage
> of making the class drivers more effective. But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?
Why is padding only relevant for the ECM? Of course, other devices
need it too, such as asix devices.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -net v2 2/2] netconsole: fix a deadlock with rtnl and netconsole's mutex
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1379595756-3527-1-git-send-email-nikolay@redhat.com>
This bug was introduced by commit
7a163bfb7ce50895bbe67300ea610d31b9c09230 ("netconsole: avoid a crash with
multiple sysfs writers"). In store_enabled() we have the following
sequence: acquire nt->mutex then rtnl, but in the netconsole netdev
notifier we have rtnl then nt->mutex effectively leading to a deadlock.
The NULL pointer dereference that the above commit tries to fix is
actually due to another bug in netpoll_cleanup(). This is fixed by dropping
the mutex from the netdev notifier as it's already protected by rtnl.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: new patch dependent on the fix from patch 01
drivers/net/netconsole.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index dcb2134..adeee61 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -684,15 +684,12 @@ restart:
case NETDEV_RELEASE:
case NETDEV_JOIN:
case NETDEV_UNREGISTER:
- /*
- * rtnl_lock already held
+ /* rtnl_lock already held
* we might sleep in __netpoll_cleanup()
*/
spin_unlock_irqrestore(&target_list_lock, flags);
- mutex_lock(&nt->mutex);
__netpoll_cleanup(&nt->np);
- mutex_unlock(&nt->mutex);
spin_lock_irqsave(&target_list_lock, flags);
dev_put(nt->np.dev);
--
1.8.1.4
^ permalink raw reply related
* [PATCH -net v2 1/2] netpoll: fix NULL pointer dereference in netpoll_cleanup
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1379595756-3527-1-git-send-email-nikolay@redhat.com>
I've been hitting a NULL ptr deref while using netconsole because the
np->dev check and the pointer manipulation in netpoll_cleanup are done
without rtnl and the following sequence happens when having a netconsole
over a vlan and we remove the vlan while disabling the netconsole:
CPU 1 CPU2
removes vlan and calls the notifier
enters store_enabled(), calls
netdev_cleanup which checks np->dev
and then waits for rtnl
executes the netconsole netdev
release notifier making np->dev
== NULL and releases rtnl
continues to dereference a member of
np->dev which at this point is == NULL
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: fix the style as requested
net/core/netpoll.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 2c637e9..2ba363d 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -1284,15 +1284,14 @@ EXPORT_SYMBOL_GPL(__netpoll_free_async);
void netpoll_cleanup(struct netpoll *np)
{
- if (!np->dev)
- return;
-
rtnl_lock();
+ if (!np->dev)
+ goto out;
__netpoll_cleanup(np);
- rtnl_unlock();
-
dev_put(np->dev);
np->dev = NULL;
+out:
+ rtnl_unlock();
}
EXPORT_SYMBOL(netpoll_cleanup);
--
1.8.1.4
^ permalink raw reply related
* [PATCH -net v2 0/2] net: netpoll and netconsole fixes
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi,
This small patchset fixes a possible race condition in netpoll_cleanup
which can lead to a NULL pointer dereference because the check and
manipulation of np->dev are done outside of the rtnl lock (patch 01).
The second patch fixes a deadlock in netconsole and does a trivial comment
style fix.
v2: fix the function style in patch 01
Best regards,
Nikolay Aleksandrov
Nikolay Aleksandrov (2):
netpoll: fix NULL pointer dereference in netpoll_cleanup
netconsole: fix a deadlock with rtnl and netconsole's mutex
drivers/net/netconsole.c | 5 +----
net/core/netpoll.c | 9 ++++-----
2 files changed, 5 insertions(+), 9 deletions(-)
--
1.8.1.4
^ permalink raw reply
* Re: [PATCH 1/2] net, vxlan Fix compile warning [v3]
From: Prarit Bhargava @ 2013-09-19 13:04 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, jpirko, davem, stephen, bhutchings
In-Reply-To: <1379449581.1644.17.camel@bwh-desktop.uk.level5networks.com>
Fix a unintialized variable warning.
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
vs->sock = sock;
^
drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
struct socket *sock;
^
[v2]: davem suggested resolving this by making create_v{4,6}_sock() return an err
pointer.
[v3]: Ben Hutchings pointed out a missed conversion
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: jpirko@redhat.com
Cc: davem@davemloft.net
Cc: stephen@networkplumber.org
Cc: bhutchings@solarflare.com
---
drivers/net/vxlan.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bf64b41..0583d45 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2184,7 +2184,7 @@ static void vxlan_del_work(struct work_struct *work)
* could be used for both IPv4 and IPv6 communications, but
* users may set bindv6only=1.
*/
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2197,7 +2197,7 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET6, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDPv6 socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2212,28 +2212,27 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDPv6 socket %pI6:%u (%d)\n",
&vxlan_addr.sin6_addr, ntohs(vxlan_addr.sin6_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
/* At this point, IPv6 module should have been loaded in
* sock_create_kern().
*/
BUG_ON(!ipv6_stub);
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
#else
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
- return -EPFNOSUPPORT;
+ return ERR_PTR(-EPFNOSUPPORT);
}
#endif
-static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v4_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2248,7 +2247,7 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDP socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2261,13 +2260,12 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDP socket %pI4:%u (%d)\n",
&vxlan_addr.sin_addr, ntohs(vxlan_addr.sin_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
/* Create new listen socket if needed */
@@ -2278,7 +2276,6 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
struct vxlan_sock *vs;
struct socket *sock;
struct sock *sk;
- int rc = 0;
unsigned int h;
vs = kmalloc(sizeof(*vs), GFP_KERNEL);
@@ -2291,12 +2288,12 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
INIT_WORK(&vs->del_work, vxlan_del_work);
if (ipv6)
- rc = create_v6_sock(net, port, &sock);
+ sock = create_v6_sock(net, port);
else
- rc = create_v4_sock(net, port, &sock);
- if (rc < 0) {
+ sock = create_v4_sock(net, port);
+ if (IS_ERR(sock)) {
kfree(vs);
- return ERR_PTR(rc);
+ return ERR_CAST(sock);
}
vs->sock = sock;
--
1.7.9.3
^ permalink raw reply related
* RE: [PATCH net-next v4] Don't destroy the netdev until the vif is shut down
From: Paul Durrant @ 2013-09-19 11:55 UTC (permalink / raw)
To: Ian Campbell
Cc: Wei Liu, xen-devel@lists.xen.org, netdev@vger.kernel.org,
David Vrabel
In-Reply-To: <1379521517.11304.274.camel@hastur.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 18 September 2013 17:25
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@lists.xen.org; netdev@vger.kernel.org; David Vrabel
> Subject: Re: [PATCH net-next v4] Don't destroy the netdev until the vif is
> shut down
>
> On Wed, 2013-09-18 at 17:04 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > > Sent: 18 September 2013 16:58
> > > To: Wei Liu
> > > Cc: Paul Durrant; xen-devel@lists.xen.org; netdev@vger.kernel.org;
> David
> > > Vrabel
> > > Subject: Re: [PATCH net-next v4] Don't destroy the netdev until the vif is
> > > shut down
> > >
> > > On Wed, 2013-09-18 at 11:37 +0100, Wei Liu wrote:
> > > > On Tue, Sep 17, 2013 at 05:46:08PM +0100, Paul Durrant wrote:
> > > > > Without this patch, if a frontend cycles through states Closing
> > > > > and Closed (which Windows frontends need to do) then the netdev
> > > > > will be destroyed and requires re-invocation of hotplug scripts
> > > > > to restore state before the frontend can move to Connected. Thus
> > > > > when udev is not in use the backend gets stuck in InitWait.
> > > > >
> > > > > With this patch, the netdev is left alone whilst the backend is
> > > > > still online and is only de-registered and freed just prior to
> > > > > destroying the vif (which is also nicely symmetrical with the
> > > > > netdev allocation and registration being done during probe) so
> > > > > no re-invocation of hotplug scripts is required.
> > > > >
> > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > > Cc: David Vrabel <david.vrabel@citrix.com>
> > > > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > >
> > > > Acked-by: Wei Liu <wei.liu2@citrix.com>
> > >
> > > yeah, looks good, thanks.
> > >
> > > Paul, did you test this with non-Windows frontends too? and do things
> > > like vif hot(un)plug still work?
> > >
> >
> > Ian,
> >
> > I tested with a debian (wheezy) PV guest but I didn't test unplug. I
> > cycled a windows frontend several times (which is how I spotted the
> > tx_irq thing), and shutdown and brought up both the debian and windows
> > guests several times. I can test unplug too if you'd like.
>
> I don't think it needs to be a blocker for accepting this patch but it
> would be good to try it, it's the sort of area which historically gets
> broken by this sort of change.
>
FWIW I just checked network-detach with a windows frontend and it worked ok.
Paul
^ permalink raw reply
* Re: [PATCH] net: tsi108: Prevent compiler warning
From: Thierry Reding @ 2013-09-19 11:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20130918.123853.1464055976885078627.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Wed, Sep 18, 2013 at 12:38:53PM -0400, David Miller wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Wed, 18 Sep 2013 14:49:55 +0200
>
> > The dump_eth_one() function is only used if DEBUG is enabled, so protect
> > it by a corresponding #ifdef DEBUG block.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> I would prefer that this function and the one call site is simply
> removed instead.
>
> This kind of thing can be provided via ethtool register dumps
> and therefore without all of the ugliness this ad-hoc stuff
> presents.
I just noticed the warning during some test builds I was doing due to
some unrelated patches and thought I'd clean it up along the way.
I'll send a patch to remove the functionality completely if that's what
you prefer, but I won't be able to reimplement it using ethtool. Perhaps
someone with actual hardware can do that.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Peter Hurley @ 2013-09-19 10:43 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Andre Naujoks, davem, Wolfgang Grandegger, linux-can, netdev,
linux-kernel, Greg KH
In-Reply-To: <523AD356.70607@pengutronix.de>
[ +cc Greg Kroah-Hartman]
On 09/19/2013 06:35 AM, Marc Kleine-Budde wrote:
> On 09/19/2013 12:29 PM, Andre Naujoks wrote:
>> On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
>>> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>>>> The locking is needed, since the the internal buffer for the CAN
>>>> frames is changed during the wakeup call. This could cause buffer
>>>> inconsistencies under high loads, especially for the outgoing
>>>> short CAN packet skbuffs.
>>>>
>>>> The needed locks led to deadlocks before commit
>>>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>>>> wakeup from pty write() path", which removed the direct callback
>>>> to the wakeup function from the tty layer.
>>>
>>> What does that mean for older kernels? (<
>>> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
>>
>> It seems the slcan (and slip) driver is broken for older kernels. See
>> this thread for a discussion about the patch in pty.c.
>>
>> http://marc.info/?l=linux-kernel&m=137269017002789&w=2
>
> Thanks for the info.
>
>> The patch from Peter Hurley was actually already in the queue, when I
>> ran into the problem, and is now in kernel 3.12.
>>
>> Without the pty patch and slow CAN traffic, the driver works, because
>> the wakeup is called directly from the pty driver. That is also the
>> reason why there was no locking. It would just deadlock.
>>
>> When the pty driver defers the wakeup, we ran into synchronisation
>> problems (which should be fixed by the locking) and eventually into a
>> kernel panic because of a recursive loop (which should be fixed by the
>> pty.c patch).
>>
>> Maybe it is possible to get both patches back into the stable branches?
>
> Sounds reasonable. You might get in touch with Peter Hurley, if his
> patch is scheduled for stable. Documentation/stable_kernel_rules.txt
> suggests a procedure if your patch depends on others to be cherry picked.
Already following along.
I'd like to wait for 3.12 release before the pty patch goes to -stable
(so that it gets more in-the-wild testing).
Regards,
Peter Hurley
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Marc Kleine-Budde @ 2013-09-19 10:35 UTC (permalink / raw)
To: Andre Naujoks; +Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <523AD21C.8030102@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
On 09/19/2013 12:29 PM, Andre Naujoks wrote:
> On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
>> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>>> The locking is needed, since the the internal buffer for the CAN
>>> frames is changed during the wakeup call. This could cause buffer
>>> inconsistencies under high loads, especially for the outgoing
>>> short CAN packet skbuffs.
>>>
>>> The needed locks led to deadlocks before commit
>>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>>> wakeup from pty write() path", which removed the direct callback
>>> to the wakeup function from the tty layer.
>>
>> What does that mean for older kernels? (<
>> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
>
> It seems the slcan (and slip) driver is broken for older kernels. See
> this thread for a discussion about the patch in pty.c.
>
> http://marc.info/?l=linux-kernel&m=137269017002789&w=2
Thanks for the info.
> The patch from Peter Hurley was actually already in the queue, when I
> ran into the problem, and is now in kernel 3.12.
>
> Without the pty patch and slow CAN traffic, the driver works, because
> the wakeup is called directly from the pty driver. That is also the
> reason why there was no locking. It would just deadlock.
>
> When the pty driver defers the wakeup, we ran into synchronisation
> problems (which should be fixed by the locking) and eventually into a
> kernel panic because of a recursive loop (which should be fixed by the
> pty.c patch).
>
> Maybe it is possible to get both patches back into the stable branches?
Sounds reasonable. You might get in touch with Peter Hurley, if his
patch is scheduled for stable. Documentation/stable_kernel_rules.txt
suggests a procedure if your patch depends on others to be cherry picked.
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* xmm registers in amd64 drivers
From: David Laight @ 2013-09-19 10:31 UTC (permalink / raw)
To: Network Development
I realise this isn't quite the right list for this question.
But I suspect someone will know the answer!
I've just compiled one of our drivers (an ss7 protocol stack)
on a much newer system than the one we usually use
(ubunto 13.04 with gcc 4.7.3 rather than debian lenny).
I've bodged around some strict-aliasing and const-cast warnings
- the usage all look safe.
Looking at the object code I noticed that all the stdarg
functions now contain code to conditionally save the xmm
registers.
Is this now considered 'normal' or am I missing a compiler flag?
I know I've looked at the code before since I tried adding
enough fixed parameters to one of the functions to get all
the variable ones on-stack hoping that would optimise the
accesses - it didn't.
David
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Andre Naujoks @ 2013-09-19 10:29 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <523AC589.5040006@pengutronix.de>
On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>> The locking is needed, since the the internal buffer for the CAN
>> frames is changed during the wakeup call. This could cause buffer
>> inconsistencies under high loads, especially for the outgoing
>> short CAN packet skbuffs.
>>
>> The needed locks led to deadlocks before commit
>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>> wakeup from pty write() path", which removed the direct callback
>> to the wakeup function from the tty layer.
>
> What does that mean for older kernels? (<
> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
It seems the slcan (and slip) driver is broken for older kernels. See
this thread for a discussion about the patch in pty.c.
http://marc.info/?l=linux-kernel&m=137269017002789&w=2
The patch from Peter Hurley was actually already in the queue, when I
ran into the problem, and is now in kernel 3.12.
Without the pty patch and slow CAN traffic, the driver works, because
the wakeup is called directly from the pty driver. That is also the
reason why there was no locking. It would just deadlock.
When the pty driver defers the wakeup, we ran into synchronisation
problems (which should be fixed by the locking) and eventually into a
kernel panic because of a recursive loop (which should be fixed by the
pty.c patch).
Maybe it is possible to get both patches back into the stable branches?
Regards
Andre
>
>> As slcan.c is based on slip.c the issue in the original code is
>> fixed, too.
>>
>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> Marc
>
^ permalink raw reply
* [PATCH] Confirm success for each tc -batch command
From: Petr Písař @ 2013-09-19 10:13 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Petr Písař
If `tc -force -batch' is fed by a controlling program from a pipe,
it's not possible to recognize when a command has been processes
successfully.
This patch adds an optional `-OK' option to the tc(8) tool, so `tc
-force -OK -batch' will print "OK\n" to standard output on each
successfully completed tc command.
Signed-off-by: Petr Písař <ppisar@redhat.com>
---
man/man8/tc.8 | 8 +++++++-
tc/tc.c | 8 +++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index e0acfeb..583eae2 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -49,7 +49,7 @@ DEV
DEV
.P
-.B tc [ -force ] -b\fR[\fIatch\fR] \fB[ filename ]
+.B tc [ -force ] [ -OK ] -b\fR[\fIatch\fR] \fB[ filename ]
.ti 8
.IR FORMAT " := {"
@@ -440,6 +440,12 @@ First failure will cause termination of tc.
don't terminate tc on errors in batch mode.
If there were any errors during execution of the commands, the application return code will be non zero.
+.TP
+.BR "\-OK"
+in batch mode, print
+.B OK
+and a new line on standard output after each successfully interpreted command.
+
.SH HISTORY
.B tc
was written by Alexey N. Kuznetsov and added in Linux 2.2.
diff --git a/tc/tc.c b/tc/tc.c
index 9b50e74..b43bb47 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -39,6 +39,7 @@ int batch_mode = 0;
int resolve_hosts = 0;
int use_iec = 0;
int force = 0;
+int ok = 0;
struct rtnl_handle rth;
static void *BODY = NULL; /* cached handle dlopen(NULL) */
@@ -183,7 +184,7 @@ noexist:
static void usage(void)
{
fprintf(stderr, "Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }\n"
- " tc [-force] -batch filename\n"
+ " tc [-force] [-OK] -batch filename\n"
"where OBJECT := { qdisc | class | filter | action | monitor }\n"
" OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -p[retty] | -b[atch] [filename] }\n");
}
@@ -251,6 +252,9 @@ static int batch(const char *name)
ret = 1;
if (!force)
break;
+ } else if (ok) {
+ printf("OK\n");
+ fflush(stdout);
}
}
if (line)
@@ -288,6 +292,8 @@ int main(int argc, char **argv)
return 0;
} else if (matches(argv[1], "-force") == 0) {
++force;
+ } else if (matches(argv[1], "-OK") == 0) {
+ ++ok;
} else if (matches(argv[1], "-batch") == 0) {
argc--; argv++;
if (argc <= 1)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net 2/3] lib: introduce upper case hex ascii helpers
From: Oliver Hartkopp @ 2013-09-19 9:57 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Andrew Morton, Thiago Farina, Andre Naujoks, David S. Miller,
Steven Rostedt, Rusty Russell, Arnd Bergmann, Michael S. Tsirkin,
Vladimir Kondratiev, Jason Baron, Greg Kroah-Hartman, linux list,
linux-can, netdev
In-Reply-To: <523AC615.9020204@pengutronix.de>
On 19.09.2013 11:38, Marc Kleine-Budde wrote:
> On 09/15/2013 06:35 AM, Andrew Morton wrote:
>> On Sun, 15 Sep 2013 01:27:03 -0300 Thiago Farina <tfransosi@gmail.com> wrote:
>>
>>> On Fri, Sep 13, 2013 at 2:37 PM, Andre Naujoks <nautsch2@gmail.com> wrote:
>>>> To be able to use the hex ascii functions in case sensitive environments
>>>> the array hex_asc_upper[] and the needed functions for hex_byte_pack_upper()
>>>> are introduced.
>>>>
>>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>>> ---
>>>> include/linux/kernel.h | 11 +++++++++++
>>>> lib/hexdump.c | 2 ++
>>>> 2 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>>> index 482ad2d..672ddc4 100644
>>>> --- a/include/linux/kernel.h
>>>> +++ b/include/linux/kernel.h
>>>> @@ -439,6 +439,17 @@ static inline char *hex_byte_pack(char *buf, u8 byte)
>>>> return buf;
>>>> }
>>>>
>>>> +extern const char hex_asc_upper[];
>>>> +#define hex_asc_upper_lo(x) hex_asc_upper[((x) & 0x0f)]
>>>> +#define hex_asc_upper_hi(x) hex_asc_upper[((x) & 0xf0) >> 4]
>>> Does using a macro instead of a real function (static inline)
>>> generates a better code?
>>
>> Yes, a static inline would be nicer, but these are derived from
>> hex_asc_lo/hex_asc_hi. If we change one we should change the other
>> and that becomes a separate cleanup. So I think this patch is
>> OK as-is.
>
> Is this an Acked-by?
>
>> Also, it would make sense to get all the *hex* stuff out of kernel.h
>> and into a new header file (hexchar.h?). They're a clean
>> self-contained thing and kernel.h is rather a dumping ground.
>
> Who is taking this series?
Andre suggested that Dave Miller could take these three patches for 3.12 as
they are mainly network fixes:
http://marc.info/?l=linux-can&m=137909384116115&w=2
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net 3/3] slcan: rewrite of slc_bump and slc_encaps
From: Marc Kleine-Budde @ 2013-09-19 9:47 UTC (permalink / raw)
To: Andre Naujoks; +Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <1379093833-4949-4-git-send-email-nautsch2@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On 09/13/2013 07:37 PM, Andre Naujoks wrote:
> The old implementation was heavy on str* functions and sprintf calls.
> This version is more manual, but faster.
>
> Profiling just the printing of a 3 char CAN-id resulted in 60 instructions
> for the manual method and over 2000 for the sprintf method. Bear in
> mind the profiling was done against libc and not the kernel sprintf.
>
> Together with this rewrite an issue with sending and receiving of RTR frames
> has been fixed by Oliver for the cases that the DLC is not zero.
>
> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH net 2/3] lib: introduce upper case hex ascii helpers
From: Marc Kleine-Budde @ 2013-09-19 9:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Thiago Farina, Andre Naujoks, David S. Miller, Steven Rostedt,
Rusty Russell, Arnd Bergmann, Michael S. Tsirkin,
Vladimir Kondratiev, Jason Baron, Greg Kroah-Hartman, linux list,
linux-can, netdev
In-Reply-To: <20130914213546.ae435cdd.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]
On 09/15/2013 06:35 AM, Andrew Morton wrote:
> On Sun, 15 Sep 2013 01:27:03 -0300 Thiago Farina <tfransosi@gmail.com> wrote:
>
>> On Fri, Sep 13, 2013 at 2:37 PM, Andre Naujoks <nautsch2@gmail.com> wrote:
>>> To be able to use the hex ascii functions in case sensitive environments
>>> the array hex_asc_upper[] and the needed functions for hex_byte_pack_upper()
>>> are introduced.
>>>
>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>> ---
>>> include/linux/kernel.h | 11 +++++++++++
>>> lib/hexdump.c | 2 ++
>>> 2 files changed, 13 insertions(+)
>>>
>>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>> index 482ad2d..672ddc4 100644
>>> --- a/include/linux/kernel.h
>>> +++ b/include/linux/kernel.h
>>> @@ -439,6 +439,17 @@ static inline char *hex_byte_pack(char *buf, u8 byte)
>>> return buf;
>>> }
>>>
>>> +extern const char hex_asc_upper[];
>>> +#define hex_asc_upper_lo(x) hex_asc_upper[((x) & 0x0f)]
>>> +#define hex_asc_upper_hi(x) hex_asc_upper[((x) & 0xf0) >> 4]
>> Does using a macro instead of a real function (static inline)
>> generates a better code?
>
> Yes, a static inline would be nicer, but these are derived from
> hex_asc_lo/hex_asc_hi. If we change one we should change the other
> and that becomes a separate cleanup. So I think this patch is
> OK as-is.
Is this an Acked-by?
> Also, it would make sense to get all the *hex* stuff out of kernel.h
> and into a new header file (hexchar.h?). They're a clean
> self-contained thing and kernel.h is rather a dumping ground.
Who is taking this series?
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Marc Kleine-Budde @ 2013-09-19 9:36 UTC (permalink / raw)
To: Andre Naujoks; +Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <1379093833-4949-2-git-send-email-nautsch2@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
On 09/13/2013 07:37 PM, Andre Naujoks wrote:
> The locking is needed, since the the internal buffer for the CAN frames is
> changed during the wakeup call. This could cause buffer inconsistencies
> under high loads, especially for the outgoing short CAN packet skbuffs.
>
> The needed locks led to deadlocks before commit
> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra wakeup from pty
> write() path", which removed the direct callback to the wakeup function from the
> tty layer.
What does that mean for older kernels?
(< 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
> As slcan.c is based on slip.c the issue in the original code is fixed, too.
>
> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [REGRESSION][BISECTED] skge: add dma_mapping check
From: Igor Gnatenko @ 2013-09-19 9:03 UTC (permalink / raw)
To: Francois Romieu
Cc: Mirko Lindner, linux-kernel, Stephen Hemminger, netdev,
Joseph Salisbury, member graysky
In-Reply-To: <20130918220819.GA11989@electric-eye.fr.zoreil.com>
Please, send patch.
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64
^ permalink raw reply
* [PATCH] iproute2: bridge: document mdb
From: Petr Písař @ 2013-09-19 8:41 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Petr Písař
In-Reply-To: <1379580086-31784-1-git-send-email-ppisar@redhat.com>
This augments bridge(8) manual page with `bridge mdb' and `bridge
monitor mdb' commands which have been added recently.
Signed-off-by: Petr Písař <ppisar@redhat.com>
---
man/man8/bridge.8 | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 85 insertions(+), 3 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 66678b5..9a34804 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -13,7 +13,7 @@ bridge \- show / manipulate bridge addresses and devices
.ti -8
.IR OBJECT " := { "
-.BR link " | " fdb " | " vlan " | " monitor " }"
+.BR link " | " fdb " | " mdb " | " vlan " | " monitor " }"
.sp
.ti -8
@@ -65,6 +65,21 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
+.BR "bridge mdb" " { " add " | " del " } "
+.B dev
+.IR DEV
+.B port
+.IR PORT
+.B grp
+.IR GROUP " [ "
+.BR permanent " | " temp " ]"
+
+.ti -8
+.BR "bridge mdb show " [ "
+.B dev
+.IR DEV " ]"
+
+.ti -8
.BR "bridge vlan" " { " add " | " del " } "
.B dev
.IR DEV
@@ -79,7 +94,7 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
-.BR "bridge monitor" " [ " all " | " neigh " | " link " ]"
+.BR "bridge monitor" " [ " all " | " neigh " | " link " | " mdb " ]"
.SH OPTIONS
@@ -110,6 +125,10 @@ As a rule, the information is statistics or some time values.
- Forwarding Database entry.
.TP
+.B mdb
+- Multicast group database entry.
+
+.TP
.B vlan
- VLAN filter list.
@@ -326,6 +345,69 @@ With the
option, the command becomes verbose. It prints out the last updated
and last used time for each entry.
+.SH bridge mdb - multicast group database management
+
+.B mdb
+objects contain known IP multicast group addresses on a link.
+
+.P
+The corresponding commands display mdb entries, add new entries,
+and delete old ones.
+
+.SS bridge mdb add - add a new multicast group database entry
+
+This command creates a new mdb entry.
+
+.TP
+.BI dev " DEV"
+the interface where this group address is associated.
+
+.TP
+.BI port " PORT"
+the port whose link is known to have members of this multicast group.
+
+.TP
+.BI grp " GROUP"
+the IP multicast group address whose members reside on the link connected to
+the port.
+
+.B permanent
+- the mdb entry is permanent
+.sp
+
+.B temp
+- the mdb entry is temporary (default)
+.sp
+
+.in -8
+.SS bridge mdb delete - delete a multicast group database entry
+This command removes an existing mdb entry.
+
+.PP
+The arguments are the same as with
+.BR "bridge mdb add" .
+
+.SS bridge mdb show - list multicast group database entries
+
+This command displays the current multicast group membership table. The table
+is populated by IGMP and MLD snooping in the bridge driver automatically. It
+can be altered by
+.B bridge mdb add
+and
+.B bridge mdb del
+commands manually too.
+
+.TP
+.BI dev " DEV"
+the interface only whose entries should be listed. Default is to list all
+bridge interfaces.
+
+.PP
+With the
+.B -details
+option, the command becomes verbose. It prints out the ports known to have
+a connected router.
+
.SH bridge vlan - VLAN filter list
.B vlan
@@ -395,7 +477,7 @@ command is the first in the command line and then the object list follows:
.I OBJECT-LIST
is the list of object types that we want to monitor.
It may contain
-.BR link ", and " fdb "."
+.BR link ", " fdb ", and " mdb "."
If no
.B file
argument is given,
--
1.8.3.1
^ permalink raw reply related
* (unknown),
From: Petr Písař @ 2013-09-19 8:41 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1379578543-31358-1-git-send-email-ppisar@redhat.com>
Ah, sorry. The patach has two trailing spaces. Following one should be better.
-- Petr
^ permalink raw reply
* RE: [PATCH] USBNET: fix handling padding packet
From: David Laight @ 2013-09-19 8:29 UTC (permalink / raw)
To: Bjørn Mork, Oliver Neukum
Cc: Ming Lei, David S. Miller, Greg Kroah-Hartman,
Network Development, linux-usb
In-Reply-To: <87wqmd46vj.fsf@nemi.mork.no>
> I wonder what the gain of that really is? Yes, I can see the advantage
> of making the class drivers more effective. But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?
AFAICT the requirement for avoiding ZLP is a property of the slave.
Support for scatter-gather is a property of the host.
So connect an old slave to a modern host and you may be able to use
sg to add the header or padding (and possibly have a fragmented skb).
Generating frames that would have a ZLP should just be a matter of
sending UDP frames with ever increasing lengths - although a
printf in the driver would confirm it.
However the is a report (somewhere) that it would work sometimes
and not others with certain targets.
I've got one of the ASIX USB3 devices here, but the system is running
ubuntu 12.04 - which doesn't have the sg changes. I've not looked far
enough to see if the sg changes in usbnet.c can be applied to that
kernel.
David
^ permalink raw reply
* Re: [REGRESSION][BISECTED] skge: add dma_mapping check
From: Igor Gnatenko @ 2013-09-19 8:18 UTC (permalink / raw)
To: Francois Romieu
Cc: Mirko Lindner, linux-kernel, Stephen Hemminger, netdev,
Joseph Salisbury, member graysky
In-Reply-To: <20130918220819.GA11989@electric-eye.fr.zoreil.com>
On Thu, 2013-09-19 at 00:08 +0200, Francois Romieu wrote:
> Igor Gnatenko <i.gnatenko.brain@gmail.com> :
> > Since 136d8f377e1575463b47840bc5f1b22d94bf8f63 commit we have kernel
> > panic on:
> > 01:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
> >
> > Screen: https://www.dropbox.com/s/mu3t3wxpxbn4ou5/IMAG0507.jpg
> >
> > RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1008323
>
> Does the ugly stuff below against mainline make a difference ?
>
> Note to testers: use a size argument above 500 for 'ping' to
> exercize the relevant code path.
Reported-and-tested-by: Vasiliy Glazov <vascom2@gmail.com>
Bisected-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
>
> diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
> index ef94a59..aa85a3f 100644
> --- a/drivers/net/ethernet/marvell/skge.c
> +++ b/drivers/net/ethernet/marvell/skge.c
> @@ -3086,6 +3086,7 @@ static struct sk_buff *skge_rx_get(struct net_device *dev,
> PCI_DMA_FROMDEVICE);
> skge_rx_reuse(e, skge->rx_buf_size);
> } else {
> + struct skge_element ee = *e;
> struct sk_buff *nskb;
>
> nskb = netdev_alloc_skb_ip_align(dev, skge->rx_buf_size);
> @@ -3098,10 +3099,10 @@ static struct sk_buff *skge_rx_get(struct net_device *dev,
> }
>
> pci_unmap_single(skge->hw->pdev,
> - dma_unmap_addr(e, mapaddr),
> - dma_unmap_len(e, maplen),
> + dma_unmap_addr(&ee, mapaddr),
> + dma_unmap_len(&ee, maplen),
> PCI_DMA_FROMDEVICE);
> - skb = e->skb;
> + skb = ee.skb;
> prefetch(skb->data);
> }
>
Yes. This patch fixes problem. ping www.ru -s 500 works fine.
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64
^ permalink raw reply
* [PATCH] iproute2: bridge: document mdb
From: Petr Písař @ 2013-09-19 8:15 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Petr Písař
This augments bridge(8) manual page with `bridge mdb' and `bridge
monitor mdb' commands which have been added recently.
Signed-off-by: Petr Písař <ppisar@redhat.com>
---
man/man8/bridge.8 | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 85 insertions(+), 3 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 66678b5..635e801 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -13,7 +13,7 @@ bridge \- show / manipulate bridge addresses and devices
.ti -8
.IR OBJECT " := { "
-.BR link " | " fdb " | " vlan " | " monitor " }"
+.BR link " | " fdb " | " mdb " | " vlan " | " monitor " }"
.sp
.ti -8
@@ -65,6 +65,21 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
+.BR "bridge mdb" " { " add " | " del " } "
+.B dev
+.IR DEV
+.B port
+.IR PORT
+.B grp
+.IR GROUP " [ "
+.BR permanent " | " temp " ]"
+
+.ti -8
+.BR "bridge mdb show " [ "
+.B dev
+.IR DEV " ]"
+
+.ti -8
.BR "bridge vlan" " { " add " | " del " } "
.B dev
.IR DEV
@@ -79,7 +94,7 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
-.BR "bridge monitor" " [ " all " | " neigh " | " link " ]"
+.BR "bridge monitor" " [ " all " | " neigh " | " link " | " mdb " ]"
.SH OPTIONS
@@ -110,6 +125,10 @@ As a rule, the information is statistics or some time values.
- Forwarding Database entry.
.TP
+.B mdb
+- Multicast group database entry.
+
+.TP
.B vlan
- VLAN filter list.
@@ -326,6 +345,69 @@ With the
option, the command becomes verbose. It prints out the last updated
and last used time for each entry.
+.SH bridge mdb - multicast group database management
+
+.B mdb
+objects contain known IP multicast group addresses on a link.
+
+.P
+The corresponding commands display mdb entries, add new entries,
+and delete old ones.
+
+.SS bridge mdb add - add a new multicast group database entry
+
+This command creates a new mdb entry.
+
+.TP
+.BI dev " DEV"
+the interface where this group address is associated.
+
+.TP
+.BI port " PORT"
+the port whose link is known to have members of this multicast group.
+
+.TP
+.BI grp " GROUP"
+the IP multicast group address whose members reside on the link connected to
+the port.
+
+.B permanent
+- the mdb entry is permanent
+.sp
+
+.B temp
+- the mdb entry is temporary (default)
+.sp
+
+.in -8
+.SS bridge mdb delete - delete a multicast group database entry
+This command removes an existing mdb entry.
+
+.PP
+The arguments are the same as with
+.BR "bridge mdb add" .
+
+.SS bridge mdb show - list multicast group database entries
+
+This command displays the current multicast group membership table. The table
+is populated by IGMP and MLD snooping in the bridge driver automatically. It
+can be altered by
+.B bridge mdb add
+and
+.B bridge mdb del
+commands manually too.
+
+.TP
+.BI dev " DEV"
+the interface only whose entries should be listed. Default is to list all
+bridge interfaces.
+
+.PP
+With the
+.B -details
+option, the command becomes verbose. It prints out the ports known to have
+a connected router.
+
.SH bridge vlan - VLAN filter list
.B vlan
@@ -395,7 +477,7 @@ command is the first in the command line and then the object list follows:
.I OBJECT-LIST
is the list of object types that we want to monitor.
It may contain
-.BR link ", and " fdb "."
+.BR link ", " fdb ", and " mdb "."
If no
.B file
argument is given,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] USBNET: fix handling padding packet
From: Bjørn Mork @ 2013-09-19 7:18 UTC (permalink / raw)
To: Oliver Neukum
Cc: Ming Lei, David S. Miller, Greg Kroah-Hartman,
Network Development, linux-usb
In-Reply-To: <1379573843.8608.7.camel-B2T3B9s34ElbnMAlSieJcQ@public.gmane.org>
Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
>
>> >No, USB 3.0 uses no companion controllers, so you can have devices
>> >of any speed connected to it.
>> >
>>
>> Ah, right. I don't own such modern hardware, but I should have known
>> this anyway.
>>
>> This still doesn't change the fact that the driver is brand new for
>> brand new devices. I believe we should assume such devices will
>> support ZLPs unless we have documentation stating anything else.
>
> For such devices we might assume it. But how does that matter for
> generic code?
The code isn't generic yet. Most of it is placed inside the
ax88179_178a minidriver.
But I do agree that adding this padding support can be seen as one step
towards making the code generic. So if you really anticipate this being
enabled for e.g. the ECM class driver, then yes, padding must be
supported.
I would have had less trouble understanding the value if this patch was
part of a generalisation series, though...
> As any kind of device may be connected to XHCI, the sg
> code is relevant for every driver. And I certainly don't want trouble
> for older devices' drivers converted to sg.
I wonder what the gain of that really is? Yes, I can see the advantage
of making the class drivers more effective. But padding is only
relevant for the ECM class, isn't it? And are there any ECM class
devices where SG support matters?
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] USBNET: fix handling padding packet
From: Oliver Neukum @ 2013-09-19 6:57 UTC (permalink / raw)
To: Bjørn Mork
Cc: Ming Lei, David S. Miller, Greg Kroah-Hartman,
Network Development, linux-usb
In-Reply-To: <be5ecff3-27e1-4ab7-b3af-9d7c4376140f@email.android.com>
On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
> Oliver Neukum <oneukum@suse.de> wrote:
> >No, USB 3.0 uses no companion controllers, so you can have devices
> >of any speed connected to it.
> >
>
> Ah, right. I don't own such modern hardware, but I should have known this anyway.
>
> This still doesn't change the fact that the driver is brand new for brand new devices. I believe we should assume such devices will support ZLPs unless we have documentation stating anything else.
For such devices we might assume it. But how does that matter for
generic code? As any kind of device may be connected to XHCI, the sg
code is relevant for every driver. And I certainly don't want trouble
for older devices' drivers converted to sg.
Regards
Oliver
^ 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