* 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
* [PATCH v2 1/1] net: cdc-phonet: Staticize usbpn_probe
From: Sachin Kamat @ 2013-09-19 6:45 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Rémi Denis-Courmont
'usbpn_probe' is referenced only in this file. Make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Cc: Rémi Denis-Courmont <remi@remlab.net>
---
drivers/net/usb/cdc-phonet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index 7d78669..6358d42 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -328,7 +328,7 @@ MODULE_DEVICE_TABLE(usb, usbpn_ids);
static struct usb_driver usbpn_driver;
-int usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
+static int usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
{
static const char ifname[] = "usbpn%d";
const struct usb_cdc_union_desc *union_header = NULL;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH Resend 1/3] net: cdc-phonet: Staticize usbpn_probe
From: Sachin Kamat @ 2013-09-19 6:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, remi
In-Reply-To: <20130918.122124.464642242992278820.davem@davemloft.net>
On 18 September 2013 21:51, David Miller <davem@davemloft.net> wrote:
> From: Sachin Kamat <sachin.kamat@linaro.org>
> Date: Wed, 18 Sep 2013 08:59:59 +0530
>
>> @@ -328,7 +328,8 @@ MODULE_DEVICE_TABLE(usb, usbpn_ids);
>>
>> static struct usb_driver usbpn_driver;
>>
>> -int usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
>> +static int
>> +usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
>
> Please keep it to one line, it's 82 columns which is fine.
OK. Will re-send.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [RFC PATCHv2 3/4] of: provide a binding for fixed link PHYs
From: Sascha Hauer @ 2013-09-19 6:36 UTC (permalink / raw)
To: Grant Likely
Cc: Florian Fainelli, Thomas Petazzoni, David S. Miller, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lior Amsalem,
Mark Rutland, Christian Gmeiner, Ezequiel Garcia, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20130918150031.D9034C42CDF-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
On Wed, Sep 18, 2013 at 10:00:31AM -0500, Grant Likely wrote:
> On Wed, 18 Sep 2013 10:21:11 +0100, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > I understand what you're trying to do here, but it causes a troublesome
> > > leakage of implementation detail into the binding, making the whole
> > > thing look very odd. This binding tries to make a fixed link look
> > > exactly like a real PHY even to the point of including a phandle to the
> > > phy. But having a phandle to a node which is *always* a direct child of
> > > the MAC node is redundant and a rather looney. Yes, doing it that way
> > > makes it easy for of_phy_find_device() to be transparent for fixed link,
> > > but that should *not* drive bindings, especially when that makes the
> > > binding really rather weird.
> >
> > This is not exactly true in the sense that the "new" binding just
> > re-shuffles the properties representation into something that is
> > clearer and more extendible but there is not much difference in the
> > semantics.
>
> That's not my point in the above paragraph. My point is a binding that
> consists of a phandle to a node that is always a direct child is goofy
> and wrong.
It's not necessarily a direct child. Most of these fixed links are really
ethernet switches. These are (mostly) i2c devices which are under their
corresponding i2c bus node. Using a phandle from the ethernet MAC to
the port of a switch not only provides the link information, but also the
information to which port of the switch the MAC is connected.
Another situation is that some SoCs have a MDIO bus external to the MAC
and possibly shared for multiple ethernet MACs. This also requires a
phandle from the MAC to the MDIO bus.
So we have the situation that we need a phandle from the MAC to something
that provides a link. For consistency it would be good to always use a
phandle instead of having an inflexible 'fixed-link' property.
You're right, the binding doesn't provide anything new, but I think it
straightens things up for the future.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v2] ip6tnl: do route updating for redirect in ip6_tnl_err()
From: Duan Jiong @ 2013-09-18 3:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Duan Jiong
After the ip6_tnl_err() is called, the rel_msg is assigned to
0, and the ip4ip6_err() will return directly, the instruction
below will not be executed.
In rfc2473, we can know that the tunnel ICMP redirect message
should not be reported to the source of the original packet,
so we can handle it in ip6_tnl_err().
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/ip6_tunnel.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 61355f7..48034d8 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -529,6 +529,9 @@ ip6_tnl_err(struct sk_buff *skb, __u8 ipproto, struct inet6_skb_parm *opt,
rel_msg = 1;
}
break;
+ case NDISC_REDIRECT:
+ ip6_redirect(skb, dev_net(skb->dev), skb->dev->ifindex, 0);
+ break;
}
*type = rel_type;
@@ -576,9 +579,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
rel_type = ICMP_DEST_UNREACH;
rel_code = ICMP_FRAG_NEEDED;
break;
- case NDISC_REDIRECT:
- rel_type = ICMP_REDIRECT;
- rel_code = ICMP_REDIR_HOST;
default:
return 0;
}
@@ -637,8 +637,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2, rel_info);
}
- if (rel_type == ICMP_REDIRECT)
- skb_dst(skb2)->ops->redirect(skb_dst(skb2), NULL, skb2);
icmp_send(skb2, rel_type, rel_code, htonl(rel_info));
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH ] ipv6: handle the update of the NDISC_REDIRECT error code in icmpv6_err_convert
From: Duan Jiong @ 2013-09-19 5:24 UTC (permalink / raw)
To: David Miller, duanj.fnst; +Cc: netdev
In-Reply-To: <20130918.123613.61436246160249555.davem@davemloft.net>
于 2013/9/19 0:36, David Miller 写道:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Wed, 18 Sep 2013 20:04:48 +0800
>
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> when dealing with redirect message in udpv6_err() and
>> rawv6_err() the err shoud be assigned to 0, not EPROTO.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> No, you should fix this the same way you handled DCCP, but skipping
> the whole socket error setting path for NDISC_REDIRECT.
Your meaning is that we should return directly after calling
ip6_sk_redirect(), is that it?
Thanks,
Duan
> Clearing the socket error to zero is not correct, it means you will
> lose any existing error setting.
^ permalink raw reply
* All in one place. Visit today!
From: NathanRijckmans @ 2013-09-19 3:11 UTC (permalink / raw)
Dear Customer,
There is a lot of people in this world who spend so much time
watching their health that they have not the time to enjoy it.
No doctor visits
Lowest price World Wide
Discreet Packaging
http://onlinestore20.yolasite.com/shop
Best Regards,
^ 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