* Re: [PATCH net-next] can/sja1000: add driver for EMS PCMCIA card
From: David Miller @ 2011-09-28 17:42 UTC (permalink / raw)
To: socketcan; +Cc: netdev, wg, plessing, socketcan-core
In-Reply-To: <4E7CBB04.8070807@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 23 Sep 2011 18:59:48 +0200
> This patch adds the driver for the SJA1000 based PCMCIA card 'CPC-Card' from
> EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [patch 1/1] connector: add comm change event report to proc connector
From: David Miller @ 2011-09-28 17:42 UTC (permalink / raw)
To: akpm; +Cc: netdev, vzapolskiy, zbr
In-Reply-To: <201109211926.p8LJQk0P007038@hpaq6.eem.corp.google.com>
From: akpm@google.com
Date: Wed, 21 Sep 2011 12:26:44 -0700
> From: Vladimir Zapolskiy <vzapolskiy@gmail.com>
> Subject: connector: add comm change event report to proc connector
>
> Add an event to monitor comm value changes of tasks. Such an event
> becomes vital, if someone desires to control threads of a process in
> different manner.
>
> A natural characteristic of threads is its comm value, and helpfully
> application developers have an opportunity to change it in runtime.
> Reporting about such events via proc connector allows to fine-grain
> monitoring and control potentials, for instance a process control daemon
> listening to proc connector and following comm value policies can place
> specific threads to assigned cgroup partitions.
>
> It might be possible to achieve a pale partial one-shot likeness without
> this update, if an application changes comm value of a thread generator
> task beforehand, then a new thread is cloned, and after that proc
> connector listener gets the fork event and reads new thread's comm value
> from procfs stat file, but this change visibly simplifies and extends the
> matter.
>
> Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>
> Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-28 17:42 UTC (permalink / raw)
To: Michał Mirosław
Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <CAHXqBF+ZVbCGEvnCcOtHk+sOWFLp1CuEnGLq+GEtHQTpu9PuYg@mail.gmail.com>
On 09/28/2011 10:32 AM, Michał Mirosław wrote:
> W dniu 28 września 2011 18:51 użytkownik David Daney
> <david.daney@cavium.com> napisał:
>> On 09/28/2011 12:25 AM, Michał Mirosław wrote:
>>>
>>> 2011/9/28 David Daney<david.daney@cavium.com>:
>>> [...]
>>>>
>>>> +Example :
>>>> +
>>>> + /* The parent MDIO bus. */
>>>> + smi1: mdio@1180000001900 {
>>>> + compatible = "cavium,octeon-3860-mdio";
>>>> + #address-cells =<1>;
>>>> + #size-cells =<0>;
>>>> + reg =<0x11800 0x00001900 0x0 0x40>;
>>>> + };
>>>> +
>>>> + /*
>>>> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
>>>> + pair of GPIO lines. Child busses 2 and 3 populated with 4
>>>> + PHYs each.
>>>> + */
>>>> + mdio-mux {
>>>> + compatible = "cavium,mdio-mux-sn74cbtlv3253",
>>>> "cavium,mdio-mux";
>>>> + gpios =<&gpio1 3 0>,<&gpio1 4 0>;
>>>> + mdio-parent-bus =<&smi1>;
>>>> + #address-cells =<1>;
>>>> + #size-cells =<0>;
>>>
>>> This should probably have 'compatible = "nxp,sn74cbtlv3253";' here.
>>>
>>
>> No, the sn74cbtlv3253 is a general purpose part that could be used to
>> multiplex anything (I2C, SPI, random analog signals, etc.). Only when it is
>> in the "cavium,mdio-mux-sn74cbtlv3253" configuration is it an MDIO bus
>> multiplexer.
>
> This should use some generic name then. 'mdio-mux-gpio' or something.
> There's no point in introducing chip's model for a gate-like discrete
> device.
That could be. We could define an "mdio-mux-gpio" as something that
selects the child bus based on the binary encoded value presented on the
GPIO lines.
I will regenerate the patch set with this in mind. Note that the only
part of this patch that will change is this mdio-mux.txt file, no actual
code is affected. In patch 3/3 I will add "mdio-mux-gpio" to the
.of_match_table.
Thanks,
David Daney
^ permalink raw reply
* Re: [PATCH net-next] net: rps: fix the support for PPPOE
From: David Miller @ 2011-09-28 17:35 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev
In-Reply-To: <1316594167-12313-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 21 Sep 2011 16:36:07 +0800
> The upper protocol numbers of PPPOE are different, and should be treated
> specially.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Michał Mirosław @ 2011-09-28 17:32 UTC (permalink / raw)
To: David Daney; +Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <4E8350A8.7090307@cavium.com>
W dniu 28 września 2011 18:51 użytkownik David Daney
<david.daney@cavium.com> napisał:
> On 09/28/2011 12:25 AM, Michał Mirosław wrote:
>>
>> 2011/9/28 David Daney<david.daney@cavium.com>:
>> [...]
>>>
>>> +Example :
>>> +
>>> + /* The parent MDIO bus. */
>>> + smi1: mdio@1180000001900 {
>>> + compatible = "cavium,octeon-3860-mdio";
>>> + #address-cells =<1>;
>>> + #size-cells =<0>;
>>> + reg =<0x11800 0x00001900 0x0 0x40>;
>>> + };
>>> +
>>> + /*
>>> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
>>> + pair of GPIO lines. Child busses 2 and 3 populated with 4
>>> + PHYs each.
>>> + */
>>> + mdio-mux {
>>> + compatible = "cavium,mdio-mux-sn74cbtlv3253",
>>> "cavium,mdio-mux";
>>> + gpios =<&gpio1 3 0>,<&gpio1 4 0>;
>>> + mdio-parent-bus =<&smi1>;
>>> + #address-cells =<1>;
>>> + #size-cells =<0>;
>>
>> This should probably have 'compatible = "nxp,sn74cbtlv3253";' here.
>>
>
> No, the sn74cbtlv3253 is a general purpose part that could be used to
> multiplex anything (I2C, SPI, random analog signals, etc.). Only when it is
> in the "cavium,mdio-mux-sn74cbtlv3253" configuration is it an MDIO bus
> multiplexer.
This should use some generic name then. 'mdio-mux-gpio' or something.
There's no point in introducing chip's model for a gate-like discrete
device.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: David Miller @ 2011-09-28 17:30 UTC (permalink / raw)
To: eric.dumazet
Cc: tim.c.chen, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316447547.2539.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Sep 2011 17:52:27 +0200
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call, and receiver not using SO_PASSCRED
> socket option.
>
> If SOCK_PASSCRED is set on source or destination socket, we still
> include credentials for mere write() syscalls.
I thought a lot about this and I think we should be able to get away
with this trick, so I've added this patch to net-next, thanks!
^ permalink raw reply
* Re: Draft manpage for recvmmsg [RESEND]
From: Michael Kerrisk @ 2011-09-28 17:29 UTC (permalink / raw)
To: Andi Kleen, acme-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Stephan Mueller, Anton Blanchard, Linux API
Hi Andi, Arnaldo,
Could you please review the revised recvmmsg.2 man page below.
Andi: I need to know what copyright and license to attach to the page
before I can release it.
Thanks,
Michael
---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, Sep 15, 2011 at 6:15 AM
Subject: Re: Draft manpage for recvmmsg
To: Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
acme-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Stephan Mueller <stephan.mueller-fwYZOkdEjagAvxtiuMwx3w@public.gmane.org>, Anton
Blanchard <anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
[CC list expanded]
Hi Andi, (and Arnaldo)
As noted in an earlier mail, I still need to know what copyright and
license to attach to the page before I can release it.
See below for further comments.
On Tue, Nov 23, 2010 at 11:15 AM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
>
> Here's a draft manpage for recvmmsg(2), which is one
> of the last undocumented syscalls currently.
> Please review and comment.
>
> -Andi
>
>
> .TH RECVMMSG 2 2010-11-23 "Linux" "Linux Programmer's Manual"
> .SH NAME
> recvmmsg \- receive multiple messages on a socket
> .SH SYNOPSIS
> .BI "#include <sys/socket.h>"
> .br
> .BI "int recvmmsg(int " fd ", struct mmsghdr *" mmsghdr \
> ", unsigned int " vlen ","
> .br
> .BI " unsigned int " flags ", struct timespec *" timeout ");"
> .SH DESCRIPTION
> The
> .B recvmmsg
> system call receives multiple messages in a socket.
> It acts similar to
> .B recvmsg(2),
> but allows to batch multiple receive operations into a single syscall.
> In addition it support an explicit timeout.
>
> .B fd
> is the file descriptor of the socket to receive data from.
> .B mmsghdr
> is a pointer to an array with length
> .B vlen
> of
> .I mmsghdr
> structures.
> .I struct mmsg
> is defined in
> .I sys/socket.h
> as:
> .in +4n
> .nf
> struct mmsghdr {
> struct msghdr msg_hdr; /* Message header */
> unsigned int msg_len; /* Number of received bytes for header */
> };
> .fi
> .in
> .PP
> .B msg_hdr
> is a struct
> .I msghdr
> as described in
> .I recvmsg(2).
> .B msg_len
> is the number of bytes returned for the message in the entry.
> This field has the same value as the return value of a single
> .I recvmsg(2)
> on the header.
>
> .B flags
> contains flags ored together. The flags are the same
> as documented for
> .I recvmsg(2).
> The additional
> .B MSG_WAITFORONE
> turns one
> .I MSG_DONTWAIT
> after the first message has been received.
>
> .B timeout
> points to a
> .I struct timespec
> (see
> .I clock_gettime(2)
> )
> defining a timeout for receiving, or
> .I NULL
> for no timeout. When the timeout expires
> .I recvmmsg
> returns.
> .SH RETURN VALUE
> .I recvmmsg
> returns the number of messages received in
> .I mmsghdr
> or
> -1
> when an error occurs. The
> .I msg_len
> members of
> .I mmsghdr
> are updated for each received message,
> in addition to other fields in the msg_hdr for each message,
> as described in
> .I recvmsg(2).
> .SH SEE ALSO
> .B recvmsg(2),
> .B sendmsg(2),
> .B socket(7),
> .B socket(2),
> .B clock_gettime(2)
> .SH VERSIONS
> The
> .I recvmmsg
> syscall was added with kernel 2.6.32.
> Support in glibc was added with 2.6.12.
> On earlier glibcs the function can be called
> manually using
> .I syscall(2).
I reworked a number of pieces of text, and added several other pieces.
Could you please take a look (for others interested: "man -l <file>")
at the version below and let me know of inaccuracies
Thanks,
Michael
.TH RECVMMSG 2 2011-09-09 "Linux" "Linux Programmer's Manual"
.SH NAME
recvmmsg \- receive multiple messages on a socket
.SH SYNOPSIS
.nf
.B "#define _GNU_SOURCE"
.BI "#include <sys/socket.h>"
.BI "int recvmmsg(int " sockfd ", struct mmsghdr *" msgvec \
", unsigned int " vlen ","
.br
.BI " unsigned int " flags ", struct timespec *" timeout ");"
.fi
.SH DESCRIPTION
The
.BR recvmmsg ()
system call is an extension of
.BR recvmsg (2)
that allows the caller to receive multiple messages from a socket
using a single system call.
(This has performance benefits for some applications.)
A further extension over
.BR recvmsg (2)
is support for a timeout on the receive operation.
The
.I sockfd
argument is the file descriptor of the socket to receive data from.
The
.I msgvec
argument is a pointer to an array of
.I mmsghdr
structures.
The size of this array is specified in
.IR vlen .
The
.I mmsghdr
structure is defined in
.I <sys/socket.h>
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.in
.PP
The
.I msg_hdr
field is a
.I msghdr
structure, as described in
.BR recvmsg (2).
The
.I msg_len
field is the number of bytes returned for the message in the entry.
This field has the same value as the return value of a single
.BR recvmsg (2)
on the header.
The
.I flags
argument contains flags ORed together.
The flags are the same as documented for
.BR recvmsg (2),
with the following addition:
.TP
.B MSG_WAITFORONE
Turns on
.B MSG_DONTWAIT
after the first message has been received.
.PP
The
.I timeout
argument points to a
.I struct timespec
(see
.BR clock_gettime (2))
defining a timeout (seconds plus nanoseconds) for the receive operation.
If
.I timeout
is
.I NULL
then the operation blocks indefinitely.
A blocking
.BR recvmmsg ()
call blocks until
.I vlen
messages have been received
or until the timeout expires.
A nonblocking call reads as many messages as are available
(up to the limit specified by
.IR vlen )
and returns immediately.
On return from
.BR recvmmsg (),
successive elements of
.IR msgvec
are updated to contain information about each received message:
.I msg_len
contains the size of the received message;
the subfields of
.I msg_hdr
are updated as described in
.BR recvmsg (2).
The return value of the call indicates the number of elements of
.I msgvec
that have been updated.
.SH RETURN VALUE
On success,
.BR recvmmsg ()
returns the number of messages received in
.IR msgvec ;
on error, \-1 is returned, and
.I errno
is set to indicate the error.
.SH ERRORS
Errors are as for
.BR recvmsg (2).
In addition, the following error can occur:
.TP
.B EINVAL
.I timeout
is invalid.
.SH VERSIONS
The
.BR recvmmsg ()
system call was added in Linux 2.6.32.
Support in glibc was added in version 2.12.
.SH CONFORMING TO
.BR recvmmsg ()
is Linux-specific.
.SH SEE ALSO
.BR clock_gettime (2),
.BR recvmsg (2),
.BR sendmmsg (2),
.BR sendmsg (2),
.BR socket (2),
.BR socket (7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-28 17:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Huajun Li, linux-mm@kvack.org, netdev, linux-kernel, Tejun Heo,
Christoph Lameter
In-Reply-To: <1317066395.2796.11.camel@edumazet-laptop>
On Mon, Sep 26, 2011 at 08:46:35PM +0100, Eric Dumazet wrote:
> Le lundi 26 septembre 2011 à 17:50 +0100, Catalin Marinas a écrit :
> > kmemleak_not_leak() definitely not the write answer. The alloc_percpu()
> > call does not have any kmemleak_alloc() callback, so it doesn't scan
> > them.
> >
> > Huajun, could you please try the patch below:
...
> Hmm, you need to call kmemleak_alloc() for each chunk allocated per
> possible cpu.
I tried this but it's tricky. The problem is that the percpu pointer
returned by alloc_percpu() does not directly point to the per-cpu chunks
and kmemleak would report most percpu allocations as leaks. So far the
workaround is to simply mark the alloc_percpu() objects as never leaking
and at least we avoid false positives in other areas. See the patch
below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
as there are many alloc_percpu() calls before kmemleak is fully
initialised):
------------8<------------------------------------
kmemleak: Handle percpu memory allocation
From: Catalin Marinas <catalin.marinas@arm.com>
This patch adds kmemleak callbacks from the percpu allocator, reducing a
number of false positives caused by kmemleak not scanning such memory
blocks.
Reported-by: Huajun Li <huajun.li.lee@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
mm/percpu.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index bf80e55..ece9f85 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -67,6 +67,7 @@
#include <linux/spinlock.h>
#include <linux/vmalloc.h>
#include <linux/workqueue.h>
+#include <linux/kmemleak.h>
#include <asm/cacheflush.h>
#include <asm/sections.h>
@@ -709,6 +710,8 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved)
const char *err;
int slot, off, new_alloc;
unsigned long flags;
+ void __percpu *ptr;
+ unsigned int cpu;
if (unlikely(!size || size > PCPU_MIN_UNIT_SIZE || align > PAGE_SIZE)) {
WARN(true, "illegal size (%zu) or align (%zu) for "
@@ -801,7 +804,16 @@ area_found:
mutex_unlock(&pcpu_alloc_mutex);
/* return address relative to base address */
- return __addr_to_pcpu_ptr(chunk->base_addr + off);
+ ptr = __addr_to_pcpu_ptr(chunk->base_addr + off);
+
+ /*
+ * Percpu allocations are currently reported as leaks (kmemleak false
+ * positives). To avoid this, just set min_count to 0.
+ */
+ for_each_possible_cpu(cpu)
+ kmemleak_alloc(per_cpu_ptr(ptr, cpu), size, 0, GFP_KERNEL);
+
+ return ptr;
fail_unlock:
spin_unlock_irqrestore(&pcpu_lock, flags);
@@ -911,10 +923,14 @@ void free_percpu(void __percpu *ptr)
struct pcpu_chunk *chunk;
unsigned long flags;
int off;
+ unsigned int cpu;
if (!ptr)
return;
+ for_each_possible_cpu(cpu)
+ kmemleak_free(per_cpu_ptr(ptr, cpu));
+
addr = __pcpu_ptr_to_addr(ptr);
spin_lock_irqsave(&pcpu_lock, flags);
@@ -1619,6 +1635,8 @@ int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
rc = -ENOMEM;
goto out_free_areas;
}
+ /* kmemleak tracks the percpu allocations separately */
+ kmemleak_free(ptr);
areas[group] = ptr;
base = min(ptr, base);
@@ -1733,6 +1751,8 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
"for cpu%u\n", psize_str, cpu);
goto enomem;
}
+ /* kmemleak tracks the percpu allocations separately */
+ kmemleak_free(ptr);
pages[j++] = virt_to_page(ptr);
}
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: Possible NULL dereference caused by -stable commit ef81bb40bf15f350fe865f31fa42f1082772a576
From: David Miller @ 2011-09-28 17:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, netdev, linux-kernel, gregkh, stable, mst, akong
In-Reply-To: <1317211749.2941.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Sep 2011 14:09:09 +0200
> All we need here is not the route but inet_peer, so that inet_getid()
> can be called on it.
It's not exactly that simple, you have to parse all hop-by-hop options
to get the correct "destination" address.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Neil Horman @ 2011-09-28 17:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, Andy Gospodarek, Stephen Hemminger,
jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <20110928081158.7273e9b4@nehalam.linuxnetplumber.net>
On Wed, Sep 28, 2011 at 08:11:58AM -0700, Stephen Hemminger wrote:
> On Wed, 28 Sep 2011 07:00:55 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
> > I was thinking of something along the lines of two more attributes in
> > /sys/class/net/<if>/queues:
> > napi_weight
> > irq
> >
> > The former is the napi weight of a given napi instance associated with a queue,
> > while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
> > (or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency). This
> > lets us tune the napi weight of a queue and know what interrupt is associated
> > with it. That seems fairly sane to me.
>
> This breaks for the case of some corner case devices like multi-port Marvell boards.
> There can be a N to 1 or 1 to N relationship between NAPI and the device.
>
I don't see that it has to explicitly _break_ anything. If a multiqueue device
uses a single napi instance to handle all queues, we can still create a napi
weight attribute for each queue, and simply let the device driver tie all the
weight sysfs objects to the same napi instance. It would be odd for certain,
but doable. In fact, since we'd have to get the driver involved in the creation
of such a per-queue napi weight attribute (since the driver is the only thing
with any knoweldge about which queue maps to which napi instance), we might be
able to explicitly export this information by allowing a single queue to hold
the napi wieght, and allowing the other queues sysfs symlinks back to that
object.
I'm just spitballing here on implementation, but I don't think the idea is
broken.
Neil
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-28 16:51 UTC (permalink / raw)
To: Michał Mirosław
Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <CAHXqBFLzrkH4AJVozbtT4k7ccgVgfaPoq69J48DeSJKSwEtxHw@mail.gmail.com>
On 09/28/2011 12:25 AM, Michał Mirosław wrote:
> 2011/9/28 David Daney<david.daney@cavium.com>:
> [...]
>> +Example :
>> +
>> + /* The parent MDIO bus. */
>> + smi1: mdio@1180000001900 {
>> + compatible = "cavium,octeon-3860-mdio";
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>> + reg =<0x11800 0x00001900 0x0 0x40>;
>> + };
>> +
>> + /*
>> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
>> + pair of GPIO lines. Child busses 2 and 3 populated with 4
>> + PHYs each.
>> + */
>> + mdio-mux {
>> + compatible = "cavium,mdio-mux-sn74cbtlv3253", "cavium,mdio-mux";
>> + gpios =<&gpio1 3 0>,<&gpio1 4 0>;
>> + mdio-parent-bus =<&smi1>;
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>
> This should probably have 'compatible = "nxp,sn74cbtlv3253";' here.
>
No, the sn74cbtlv3253 is a general purpose part that could be used to
multiplex anything (I2C, SPI, random analog signals, etc.). Only when
it is in the "cavium,mdio-mux-sn74cbtlv3253" configuration is it an MDIO
bus multiplexer.
David Daney.
^ permalink raw reply
* Re: linux-next: build failure after merge of the moduleh tree
From: Kalle Valo @ 2011-09-28 16:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Gortmaker, linux-next, linux-kernel,
Vasanthakumar Thiagarajan, Raja Mani, Vivek Natarajan,
Suraj Sumangala, Joe Perches, Jouni Malinen, John W. Linville,
David Miller, netdev, linux-wireless
In-Reply-To: <20110928183552.cb27a2b28b02fec275bca009@canb.auug.org.au>
On 09/28/2011 11:35 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the moduleh tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
>
> Caused by commit bdcd81707973 ("Add ath6kl cleaned up driver") from the
> net tree interacting with the module.h split up.
>
> I have applied the following patch for today (which sould be applied to
> the net or wireless trees).
>
> From 1875bfc8881cca3064c7d7fad024555fe1652926 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Sep 2011 18:32:34 +1000
> Subject: [PATCH] wireless/ath6kl: use of module_param requires the inclusion
> of moduleparam.h
>
> Otheriwse the module.h split up fails like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
Thanks, I applied this to ath6kl.git (had to fix just one conflict).
Later this week I will send a pull request to John so that the patch
should get to the wireless tree soon.
Unless John wants to take the patch directly, of course.
Kalle
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Stephen Clark @ 2011-09-28 16:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Kernel Network Developers
In-Reply-To: <20110928083021.2edf43a6@nehalam.linuxnetplumber.net>
On 09/28/2011 11:30 AM, Stephen Hemminger wrote:
> On Sat, 24 Sep 2011 18:28:06 -0400
> Stephen Clark<sclark46@earthlink.net> wrote:
>
>
>> Hi,
>>
>> Is there some reason Linux bridging won't let the ip address be on
>> one of the interfaces, like FreeBSD does, instead of the bridge device?
>>
>> This makes it very difficult or impossible to remotely add the interface
>> you are remoted in on to a bridge, or is there some sneaky way to
>> do this without losing your connection?
>>
>>
> I would like to see a clean solution to setting up a bridge.
> There was a patch that was never completed to allow migrating a ethernet
> interface into a bridge. It is possible to do it with a script, by
> dumping routes with ip command and replaying that into the bridge.
> To really do it right (including neighbor table and iptables rules)
> would be complex, especially considering the error cases.
>
> Having looked at the FreeBSD code, that is not the answer. Trying to keep
> a clean separation between IP and bridging is much better.
>
>
Hi Stephen,
Thanks for taking the time to reply. I had pretty much decided I would
have to do some kind
of script that would do everything at once, instead of trying to do the
commands one at a
time from the console.
Regards,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-28 15:45 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110928132802.GC7661@verge.net.au>
On Wed, Sep 28, 2011 at 10:28:03PM +0900, Simon Horman wrote:
> On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> > On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > > Hi,
> > >
> > > with all the excitement of kernel.org being offline and a bunch of trees
> > > likewise being offline I am a little unsure who should take this pull
> > > request which is based on the current net-next tree. But I guess it should
> > > be Patrick, Pablo or Dave.
> >
> > I'll try to set up one tree in one of my servers along today, I'll
> > send you the URI. We can use it until kernel.org comes back.
>
> Thanks. Would you like me to rebase my tree on yours?
For your patches, I put them in one branch and will cherrypick them
into master.
BTW, the trees are here:
http://1984.lsi.us.es/git/?p=net/.git;a=summary
http://1984.lsi.us.es/git/?p=net-next/.git;a=summary
I'll start iterating over the list collecting patches along today.
^ permalink raw reply
* [PATCH 1/1] ibmveth: Fix oops on request_irq failure
From: Brian King @ 2011-09-28 15:33 UTC (permalink / raw)
To: netdev; +Cc: brking
If request_irq fails, the ibmveth driver will overwrite
the rc and end up returning a successful rc on its open
function, resulting in an oops later when a packet gets
sent and buffers are not allocated due to the failed open.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
drivers/net/ibmveth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_bounce_oops2 drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_bounce_oops2 2011-09-28 09:53:09.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2011-09-28 09:53:09.000000000 -0500
@@ -636,8 +636,8 @@ static int ibmveth_open(struct net_devic
netdev_err(netdev, "unable to request irq 0x%x, rc %d\n",
netdev->irq, rc);
do {
- rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+ lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
+ } while (H_IS_LONG_BUSY(lpar_rc) || (lpar_rc == H_BUSY));
goto err_out;
}
_
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Stephen Hemminger @ 2011-09-28 15:30 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E7E5976.1070200@earthlink.net>
On Sat, 24 Sep 2011 18:28:06 -0400
Stephen Clark <sclark46@earthlink.net> wrote:
> Hi,
>
> Is there some reason Linux bridging won't let the ip address be on
> one of the interfaces, like FreeBSD does, instead of the bridge device?
>
> This makes it very difficult or impossible to remotely add the interface
> you are remoted in on to a bridge, or is there some sneaky way to
> do this without losing your connection?
>
I would like to see a clean solution to setting up a bridge.
There was a patch that was never completed to allow migrating a ethernet
interface into a bridge. It is possible to do it with a script, by
dumping routes with ip command and replaying that into the bridge.
To really do it right (including neighbor table and iptables rules)
would be complex, especially considering the error cases.
Having looked at the FreeBSD code, that is not the answer. Trying to keep
a clean separation between IP and bridging is much better.
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Michal Soltys @ 2011-09-28 15:21 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E7E5976.1070200@earthlink.net>
On 11-09-25 00:28, Stephen Clark wrote:
> Hi,
>
> Is there some reason Linux bridging won't let the ip address be on
> one of the interfaces, like FreeBSD does, instead of the bridge device?
>
You can do that, though you have to remember about proper routing, and
you will need ebtables to make some of the traffic not go through the
bridge.
Check http://ebtables.sourceforge.net/examples/basic.html#all for more
details.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Stephen Hemminger @ 2011-09-28 15:11 UTC (permalink / raw)
To: Neil Horman
Cc: Ben Hutchings, Andy Gospodarek, Stephen Hemminger,
jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <20110928110055.GA15340@hmsreliant.think-freely.org>
On Wed, 28 Sep 2011 07:00:55 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> I was thinking of something along the lines of two more attributes in
> /sys/class/net/<if>/queues:
> napi_weight
> irq
>
> The former is the napi weight of a given napi instance associated with a queue,
> while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
> (or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency). This
> lets us tune the napi weight of a queue and know what interrupt is associated
> with it. That seems fairly sane to me.
This breaks for the case of some corner case devices like multi-port Marvell boards.
There can be a N to 1 or 1 to N relationship between NAPI and the device.
^ permalink raw reply
* [PATCH v2 2/2] virtio-net: Prevent NULL dereference
From: Sasha Levin @ 2011-09-28 14:40 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Rusty Russell, Michael S. Tsirkin, virtualization,
netdev, kvm
In-Reply-To: <1317220855-9352-1-git-send-email-levinsasha928@gmail.com>
This patch prevents a NULL dereference when the user has passed a length
longer than an actual buffer to virtio-net.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
drivers/net/virtio_net.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index bde0dec..4a53d2a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -208,12 +208,22 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
return NULL;
}
- while (len) {
+ while (len && page) {
set_skb_frag(skb, page, offset, &len);
page = (struct page *)page->private;
offset = 0;
}
+ /*
+ * This is the case where we ran out of pages in our linked list, but
+ * supposedly have more data to read.
+ */
+ if (len > 0) {
+ pr_debug("%s: missing data to assemble skb\n", skb->dev->name);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+
if (page)
give_pages(vi, page);
--
1.7.6.1
^ permalink raw reply related
* [PATCH v2 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-28 14:40 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Rusty Russell, Michael S. Tsirkin, virtualization,
netdev, kvm
This patch verifies that the length of a buffer stored in a linked list
of pages is small enough to fit into a skb.
If the size is larger than a max size of a skb, it means that we shouldn't
go ahead building skbs anyway since we won't be able to send the buffer as
the user requested.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
drivers/net/virtio_net.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..bde0dec 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -195,6 +195,19 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
len -= copy;
offset += copy;
+ /*
+ * Verify that we can indeed put this data into a skb.
+ * This is here to handle cases when the device erroneously
+ * tries to receive more than is possible. This is usually
+ * the case of a broken device.
+ */
+ if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) {
+ if (net_ratelimit())
+ pr_debug("%s: too much data\n", skb->dev->name);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+
while (len) {
set_skb_frag(skb, page, offset, &len);
page = (struct page *)page->private;
--
1.7.6.1
^ permalink raw reply related
* Question about reply to a datagram sent to a Subnet-Router anycast address
From: François-Xavier Le Bail @ 2011-09-28 14:13 UTC (permalink / raw)
To: Linux Netdev List
Hi All,
I try to ping some routers on one of their Subnet-Router anycast addresses (SRAA).
(http://tools.ietf.org/html/rfc4291#section-2.6.1)
A Linux kernel 3.0 in IPv6 forwarding mode reply with an unicast source address (same subnet prefix).
An Alcatel router reply with the SRAA as source address.
The RFC 4291 removed the restrictions on using IPv6 anycast addresses, so a SRAA may be used as a source address, in a reply.
In the following draft, we have a rationale for the removal of restrictions regarding anycast as source address in RFC 4291 :
(http://tools.ietf.org/html/draft-jabley-v6-anycast-clarify-00#section-3.1)
"3.1 Anycast Source Addresses
For many conventional services to be distributed using anycast, it is
necessary for reply datagrams sent from servers to clients to be
sourced from the same address that was used as the destination in
request datagrams sent from clients to servers. When such a service
is distributed using anycast, the destination address used in request
datagrams is necessarily an anycast address; corresponding reply
packets must therefore use the same anycast address as their source
address.
Being able to use an anycast address as the source address in an IPv6
datagram is a prerequisite for the distribution of many services
using anycast over IPv6."
A SRAA is a special case of anycast address.
Is there a way to setup the Linux kernel to behave like Alcatel router, replying with the SRAA as source address ?
If not, why not update the behaviour of the Linux kernel to configurable ?
Please let me know your feedback.
Thanks,
Francois-Xavier Le Bail
^ permalink raw reply
* [PATCH v2] tcp: properly update lost_cnt_hint during shifting
From: Yan, Zheng @ 2011-09-28 14:13 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Ilpo Järvinen, Nandita Dukkipati, davem@davemloft.net
lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
lost_cnt_hint is the number of sacked packets before the lost_skb_hint. When
shifting a skb that is before the lost_skb_hint, tcp_shifted_skb() doesn't need
to adjust lost_cnt_hint by itself because it calls tcp_sacktag_one() which will
do the job right.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21fab3e..ae5a934 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1389,9 +1389,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
BUG_ON(!pcount);
- /* Tweak before seqno plays */
- if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
- !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
+ if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint == skb)
tp->lost_cnt_hint += pcount;
TCP_SKB_CB(prev)->end_seq += shifted;
^ permalink raw reply related
* Re: [GIT PULL net-next] IPVS
From: Simon Horman @ 2011-09-28 13:28 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110927081618.GA22655@1984>
On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > Hi,
> >
> > with all the excitement of kernel.org being offline and a bunch of trees
> > likewise being offline I am a little unsure who should take this pull
> > request which is based on the current net-next tree. But I guess it should
> > be Patrick, Pablo or Dave.
>
> I'll try to set up one tree in one of my servers along today, I'll
> send you the URI. We can use it until kernel.org comes back.
Thanks. Would you like me to rebase my tree on yours?
^ permalink raw reply
* [PATCH net-next v3] candev: allow SJW user setting for bittiming calculation
From: Oliver Hartkopp @ 2011-09-28 12:50 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List,
Wolfgang Grandegger
This patch adds support for SJW user settings to not set the synchronization
jump width (SJW) to 1 in any case when using the in-kernel bittiming
calculation.
The ip-tool from iproute2 already supports to pass the user defined SJW
value. The given SJW value is sanitized with the controller specific sjw_max
and the calculated tseg2 value. As the SJW can have values up to 4 providing
this value will lead to the maximum possible SJW automatically. A higher SJW
allows higher controller oscillator tolerances.
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
v2: Resend due to wrong mail address header encoding.
v3: - Detected malformed patch format due to line break in function name
- Added Acked-by: from Wolfgang Grandegger
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 9bf1116..25695bd 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -150,7 +150,19 @@ static int can_calc_bittiming(struct net_device *dev, struct can_bittiming *bt)
bt->prop_seg = tseg1 / 2;
bt->phase_seg1 = tseg1 - bt->prop_seg;
bt->phase_seg2 = tseg2;
- bt->sjw = 1;
+
+ /* check for sjw user settings */
+ if (!bt->sjw || !btc->sjw_max)
+ bt->sjw = 1;
+ else {
+ /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */
+ if (bt->sjw > btc->sjw_max)
+ bt->sjw = btc->sjw_max;
+ /* bt->sjw must not be higher than tseg2 */
+ if (tseg2 < bt->sjw)
+ bt->sjw = tseg2;
+ }
+
bt->brp = best_brp;
/* real bit-rate */
bt->bitrate = priv->clock.freq / (bt->brp * (tseg1 + tseg2 + 1));
^ permalink raw reply related
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-28 12:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <20110927123719.GB11276@redhat.com>
On Tue, 2011-09-27 at 15:37 +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 27, 2011 at 02:20:29PM +0300, Sasha Levin wrote:
> > On Tue, 2011-09-27 at 10:00 +0300, Michael S. Tsirkin wrote:
> > > > skb = page_to_skb(vi, page, len);
> > > > ...
> > >
> > > Sorry I don't get it yet. Where is mergeable ignored here?
> >
> > The NULL deref happens in page_to_skb(), before merge buffers are
> > handled.
>
> The len here is a single buffer length, so for mergeable
> buffers it is <= the size of the buffer we gave to hardware,
> which is PAGE_SIZE.
>
> err = virtqueue_add_buf_single(vi->rvq, page_address(page),
> PAGE_SIZE, false, page, gfp);
>
>
> Unless of course we are trying to work around broken hardware again,
> which I don't have a problem with, but should probably
> get appropriate comments in code and trigger a warning.
>
> > I'll test it and see if it's really the case.
I've verified it with VIRTIO_NET_F_MRG_RXBUF set, and we still get the
NULL deref.
--
Sasha.
^ 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