* Re: Kernel IPSec Questions
From: Andreas Steffen @ 2011-07-29 7:03 UTC (permalink / raw)
To: T C; +Cc: netdev
In-Reply-To: <CAL0-=Wwb+T_VYgMnOW9UiqQ2gVe8FaJCZgcFmHMLX1Yv3tVAdQ@mail.gmail.com>
Hello Terry,
here a repost of my email including the netdev list and fixing
the last URL which was wrong.
Here the definition of strongSwan's IPsec high level kernel interface
http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/kernel/kernel_ipsec.h;h=986e21fca1bbd109445e95d86dbf458095299573;hb=HEAD
and here the link to the kernel-netlink plugin which implements
configuration and management of IPsec Policies and SAs via XFRM
http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=06720a0f4bddf9fde60288f796df0eca647ae995;hb=HEAD
Our plugin of course relies on the ipsec.h, netlink.h, rtnetlink.h,
and xfrm.h Linux header files which define the API of the XFRM Netlink
kernel interface
http://git.strongswan.org/?p=strongswan.git;a=tree;f=src/include/linux;h=a41d3e9a10954c47aff2efeb06576f323c039483;hb=HEAD
Much more documentation than the Linux header files and the XFRM kernel
source code itself does not exist.
Finally a link which shows how strongSwan installs, updates, queries
and deletes IPsec Policies and SAs
http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/child_sa.c;h=cda150f8736d010cf8d897071427daf8a02a337a;hb=HEAD
Just look for all "hydra->kernel_interface" function calls.
Best regards
Andreas
On 07/29/2011 07:40 AM, T C wrote:
> Hi all,
>
> I have some questions on how IPSec logic works in the kernel. There might be
> a difference between when XFRM was introduced and prior. If possible,
> I like to know both scenarios. If not, at least from XFRM perspective would
> be very helpful.
>
> Specifically, I am interested in knowing how does IPSec obtain the initial keys
> from IKE exchange (and likely from XFRM) to set up the SA. Also what happens
> during rekeying? Does the SA have to be terminated first, or somehow it can be
> rekey'ed and continue as the same SA? I'll be using strongswan for IKE.
>
> Function names and if possible some flow graphs would be greatly appreciated.
>
> Thanks,
> Terry
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
======================================================================
Andreas Steffen andreas.steffen@strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
^ permalink raw reply
* Re: IP forwarding regression since 3.0-rc6
From: Eric Dumazet @ 2011-07-29 7:33 UTC (permalink / raw)
To: Stephan Seitz; +Cc: Maciej Rutecki, linux-kernel, netdev
In-Reply-To: <20110729T091342.GA.06bf4.stse@fsing.rootsland.net>
Le vendredi 29 juillet 2011 à 09:15 +0200, Stephan Seitz a écrit :
> On Thu, Jul 28, 2011 at 03:46:33PM +0200, Maciej Rutecki wrote:
> >I created a Bugzilla entry at
> >https://bugzilla.kernel.org/show_bug.cgi?id=40282
> >for your bug report, please add your address to the CC list in there, thanks!
>
> Thank you for creating a bug report for me. I have added my address to
> the CC list.
>
CC netdev
I suspect your configuration is too complex, and maybe the only way to
track the bug is to perform a git bisection.
Your initial message was :
Since 3.0-rc6 I see that my Linux router is losing packets. I can see
them tracing the internal interface, but I don’t see them on the external
interface. I can reproduce the problem while using tin with
news.individual.de. At the startup when tin checks every newsgroup from
the server, many packets are suddenly not routed anymore but are dropped,
so tin hangs until it quits with a NNTP error.
All kernels until 3.0-rc5 are working.
Hardware:
- 2x Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
Ethernet controller
Sofware:
- Debian Testing, 64bit, with Xen 4.1.0
System:
Dom0 (Debian Testing, 64bit) is my working system. The two NICs have each
their own bridge interface. One bridge interface (A) has an internal IP
address (IPv4 and IPv6) of my internal network. The other bridge (B)
doesn’t have a IP address in Dom0. The DomU is connected to the two
bridges.
DomU (Debian Testing, 64bit) is my iptables firewall system with Bind,
Squid, and other services. The interface connected to bridge A has an
internal IP addresses (gateway for my internal network). The interface
connected to bridge B is used for PPPoE (the NIC is directly connected to
my DSL modem).
Kernels:
Dom0 has had all kernel versions from 3.0-rcX and is running 3.0 at the
moment.
DomU has had the same kernel versions but is running 3.0-rc5 at the
moment because of the network problems in newer kernels.
Long problem description:
From Dom0 I use tin to read different newsserver. One of them is
news.individual.de. The first time after DomU switched kernel to -rc6
I started tin (connecting to the mentioned news server) and tin hung
while reading groups from the newsrc and stopped with a NNTP connection
error.
Since the problem didn’t vanish, I wrote a mail to the support team of
the news server. They told me that I was the only one with a connection
problem and asked me to try the connection from another client. I tried
it from my vServer, and it worked. So the problem had to be in my setup.
I traced in Dom0 (bridge A), DomU (bridge A) und DomU (ppp0) and noticed
that all packets generated in Dom0 were visible in DomU bridge A. But not
all of the packets were visisble at the ppp0 interface. So my DomU was
dropping packets and the connection between tin in Dom0 and the news
server failed.
So I tried older kernels and noticed that 3.0-rc5 in DomU was working,
but rc6 and newer were not. The kernel configuration was the same for all
3.0 kernels.
Since I don’t know which maintainer I should contact with my problem,
I’ll write directly to lkml.
Thanks for your help.
Shade and sweet water!
Stephan
^ permalink raw reply
* Re: Fw: [PATCH] sunrpc: use better NUMA affinities
From: Greg Banks @ 2011-07-29 6:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: NeilBrown, linux-nfs-u79uwXL29TY76Z2rM5mHXA, David Miller,
linux-kernel, netdev
In-Reply-To: <1311921035.7845.10.camel@edumazet-laptop>
On 29/07/11 16:30, Eric Dumazet wrote:
> Le vendredi 29 juillet 2011 à 16:05 +1000, Greg Banks a écrit :
>> On 29/07/11 15:32, NeilBrown wrote:
>>
>> I seem to remember coming to the conclusion that Jeff eventually
>> addressed this problem...am I misremembering or did something regress?
>>
> Currently, all nfsd kthreads use memory for their kernel stack and
> various initial data from a _single_ node, even if you use
> sunrpc.pool_mode=pernode (or percpu)
That's just plain broken and I'm very pleased to see you fix it.
I was just surprised that it was still broken and wondering how that
happened. Looking at ToT I see that because I dropped the ball in 2008,
Jeff's patches didn't address the problem. In ToT
svc_pool_map_set_cpumask() is called *after* kthread_create() and
applies to the child thread, *after* it's stack has been allocated on
the wrong node. In the working SGI code, svc_pool_map_set_cpumask() is
called by the parent node on itself *before* calling kernel_thread() or
doing any of the data structure allocations, thus ensuring that
everything gets allocated using the default memory allocation policy,
which on SGI NFS servers was globally tuned to be "node-local".
> With my patch, we make sure each thread gets its stack from its local
> node.
>
> Check commit 94dcf29a11b3d20a (kthread: use kthread_create_on_node()) to
> see how this strategy already was adopted for ksoftirqd, kworker,
> migration, and pktgend kthreads.
Ah, I see. It's unfortunate that the kthread_create() API ends up being
passed a CPU number but that's only used to format the name and not for
sensible things :(
--
Greg.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: Fw: [PATCH] sunrpc: use better NUMA affinities
From: Eric Dumazet @ 2011-07-29 6:30 UTC (permalink / raw)
To: Greg Banks
Cc: NeilBrown, linux-nfs-u79uwXL29TY76Z2rM5mHXA, David Miller,
linux-kernel, netdev
In-Reply-To: <4E324DB4.7060600-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Le vendredi 29 juillet 2011 à 16:05 +1000, Greg Banks a écrit :
> On 29/07/11 15:32, NeilBrown wrote:
> >
> > Hi Greg,
> > I saw this patch float past and thought of you... You may not be interested
> > any more, and it may be a perfectly good patch that does not need any
> > comment, but I thought I would let you know anyway.
>
> Thanks Neil.
>
> I've trimmed the cc list to limit the number of copies Trond and Bruce get:)
>
> > From: Eric Dumazet<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > To: Trond Myklebust<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
> > Cc: "J. Bruce Fields"<bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>, Neil Brown<neilb@suse.de>,
> > David Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev
> > <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-kernel<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Subject: [PATCH] sunrpc: use better NUMA affinities
> >
> >
> > Use NUMA aware allocations to reduce latencies and increase throughput.
>
>
> Briefly looking at the patch, it doesn't seem wrong but I'm surprised
> it's (still) necessary.
>
> Some years ago at SGI we encountered that same problem; we solved it by
> delaying all the allocation of data structures associated with a thread
> so that they were performed in the thread itself, after the thread had
> been limited to run on a certain set of CPUs. Thus the thread's normal
> allocation behaviour resulted in all of it's allocations being from
> node-local pages. It was a pretty ugly patch, but it worked and made a
> huge difference to NFS throughput on large NUMA boxes.
>
> Later Jeff Layton converted the sunrpc svc startup code to use kthreads
> and at the time I read his patches, pointed out this problem, and posted
> my patch for comparison
>
> http://linux-nfs.org/pipermail/nfsv4/2008-May/008760.html
>
> I seem to remember coming to the conclusion that Jeff eventually
> addressed this problem...am I misremembering or did something regress?
>
Currently, all nfsd kthreads use memory for their kernel stack and
various initial data from a _single_ node, even if you use
sunrpc.pool_mode=pernode (or percpu)
With my patch, we make sure each thread gets its stack from its local
node.
Check commit 94dcf29a11b3d20a (kthread: use kthread_create_on_node()) to
see how this strategy already was adopted for ksoftirqd, kworker,
migration, and pktgend kthreads.
I only have small machines here (two nodes), so I cannot post
significative bench results, but it seems quite obvious to expect a good
increase.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Michael S. Tsirkin @ 2011-07-29 6:16 UTC (permalink / raw)
To: Neil Horman, mashirle; +Cc: netdev
In-Reply-To: <1311696338-4739-1-git-send-email-nhorman@tuxdriver.com>
On Tue, Jul 26, 2011 at 12:05:36PM -0400, Neil Horman wrote:
> Ok, after considering all your comments, Dave suggested this as an alternate
> approach:
>
> 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> handling shared skbs. Default is to not set this flag
>
> 2) Modify ether_setup to enable this flag, under the assumption that any driver
> calling this function is initalizing a real ethernet device and as such can
> handle shared skbs since they don't tend to store state in the skb struct.
> Pktgen can then query this flag when a user script attempts to issue the
> clone_skb command and decide if it is to be alowed or not.
>
> 3) Audit the network drivers calling ether_setup to identify any code doing so
> that can't actualy handle shared skbs and manually disable the new flag. There
> are about 10 drivers in this category.
>
> Change notes:
> v3) Fixed Erics note in which I tested the length of the passed in string rather
> than its converted value for beign > 0
>
> Thoughts/reviews aprpeciated.
> Neil
It might be a good idea to disable vhost-net zerocopy for
such devices as well: these skbs are shared with userspace.
Shirley, what do you think?
--
MST
^ permalink raw reply
* Re: Fw: [PATCH] sunrpc: use better NUMA affinities
From: Greg Banks @ 2011-07-29 6:05 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-nfs, David Miller, linux-kernel, netdev, Eric Dumazet
In-Reply-To: <20110729153207.17af3085@notabene.brown>
On 29/07/11 15:32, NeilBrown wrote:
>
> Hi Greg,
> I saw this patch float past and thought of you... You may not be interested
> any more, and it may be a perfectly good patch that does not need any
> comment, but I thought I would let you know anyway.
Thanks Neil.
I've trimmed the cc list to limit the number of copies Trond and Bruce get:)
> From: Eric Dumazet<eric.dumazet@gmail.com>
> To: Trond Myklebust<Trond.Myklebust@netapp.com>
> Cc: "J. Bruce Fields"<bfields@fieldses.org>, Neil Brown<neilb@suse.de>,
> David Miller<davem@davemloft.net>, linux-nfs@vger.kernel.org, netdev
> <netdev@vger.kernel.org>, linux-kernel<linux-kernel@vger.kernel.org>
> Subject: [PATCH] sunrpc: use better NUMA affinities
>
>
> Use NUMA aware allocations to reduce latencies and increase throughput.
Briefly looking at the patch, it doesn't seem wrong but I'm surprised
it's (still) necessary.
Some years ago at SGI we encountered that same problem; we solved it by
delaying all the allocation of data structures associated with a thread
so that they were performed in the thread itself, after the thread had
been limited to run on a certain set of CPUs. Thus the thread's normal
allocation behaviour resulted in all of it's allocations being from
node-local pages. It was a pretty ugly patch, but it worked and made a
huge difference to NFS throughput on large NUMA boxes.
Later Jeff Layton converted the sunrpc svc startup code to use kthreads
and at the time I read his patches, pointed out this problem, and posted
my patch for comparison
http://linux-nfs.org/pipermail/nfsv4/2008-May/008760.html
I seem to remember coming to the conclusion that Jeff eventually
addressed this problem...am I misremembering or did something regress?
--
Greg.
^ permalink raw reply
* 802.3ah on linux
From: Satendra... @ 2011-07-29 5:55 UTC (permalink / raw)
To: netdev
Hi,
Does linux kernel has support for 802.3ah ? if yes could u plz mention
the version?
Thanks,
Satendra
^ permalink raw reply
* Re: 802.1ad on linux
From: Satendra... @ 2011-07-29 5:54 UTC (permalink / raw)
To: David Lamparter; +Cc: Jens Osterkamp, netdev
In-Reply-To: <20110728124830.GA2144046@jupiter.n2.diac24.net>
Thanks Jens and David.
David, could you give little idea about how you are testing your changes?
I mean is there any test suite used (may be third party) ?
On 28 July 2011 18:18, David Lamparter <equinox@diac24.net> wrote:
> On Thu, Jul 28, 2011 at 01:21:46PM +0200, Jens Osterkamp wrote:
>> On Thursday 28 July 2011, Satendra... wrote:
>> > Hi,
>> >
>> > Does linux kernel has support for 802.1ad ? if yes could u plz mention
>> > the version?
>>
>> No, but David Lamparter has just recently posted patches which implement this.
>>
>> http://marc.info/?l=linux-netdev&m=131093613717022&w=2
>>
>> They work fine for me on top of net-next. I had to add EXPORT_SYMBOL for
>> vlan_untag and vlan_do_receive to be able to build as a module.
>> You will need his patch for iproute2 as well to be able to create 802.1ad
>> VLAN devices.
>
> I will be rebasing them onto current net-next HEAD this weekend. With
> the VLAN cleanup in, some bits changed; I'll also do some reordering to
> fix those symbols.
>
>
> -David
>
>
^ permalink raw reply
* Kernel IPSec Questions
From: T C @ 2011-07-29 5:40 UTC (permalink / raw)
To: netdev
Hi all,
I have some questions on how IPSec logic works in the kernel. There might be
a difference between when XFRM was introduced and prior. If possible,
I like to know both scenarios. If not, at least from XFRM perspective would
be very helpful.
Specifically, I am interested in knowing how does IPSec obtain the initial keys
from IKE exchange (and likely from XFRM) to set up the SA. Also what happens
during rekeying? Does the SA have to be terminated first, or somehow it can be
rekey'ed and continue as the same SA? I'll be using strongswan for IKE.
Function names and if possible some flow graphs would be greatly appreciated.
Thanks,
Terry
^ permalink raw reply
* RE: "mlx4_en: Enabling new steering" brokenness
From: Yevgeny Petrilin @ 2011-07-29 4:34 UTC (permalink / raw)
To: Roland Dreier
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1311887099-14339-1-git-send-email-roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hello Roland,
I'll check this ASAP.
Thanks,
Yevgeny
> -----Original Message-----
> From: Roland Dreier [mailto:roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org] On Behalf Of Roland
> Dreier
> Sent: Friday, July 29, 2011 12:05 AM
> To: Yevgeny Petrilin
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: "mlx4_en: Enabling new steering" brokenness
>
> Hi Yevgeny!
>
> So I have a system with an mlx4_en device with pretty old FW (version
> 2.7.700), old enough that the firmware doesn't have the capability
> MLX4_DEV_CAP_FLAG_VEP_UC_STEER set. And it looks like mlx4_en is
> completely broken in this case, at least since your commit
> 1679200f91da ("mlx4_en: Enabling new steering"). If I try to bring up
> the interface, I just see:
>
> mlx4_en: eth1: Failed to allocate RSS indirection QP
>
> And this is failing because the QPN in 0.
>
> The problem is in drivers/net/mlx4/port.c:mlx4_register_mac():
>
> if (!(dev->caps.flags & MLX4_DEV_CAP_FLAG_VEP_UC_STEER))
> *qpn = info->base_qpn + free;
>
> but absolutely nothing ever initializes info->base_qpn. It looks like
> the intention of the code is to initialize this in
> mlx4_init_port_info(); however even the below hack doesn't seem to fix
> things completely -- I still seem to have problems on the RX side
> unless I enable promiscuous mode by running tcpdump:
>
> diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
> index c94b342..38092c7 100644
> --- a/drivers/net/mlx4/main.c
> +++ b/drivers/net/mlx4/main.c
> @@ -1125,6 +1125,13 @@ static int mlx4_init_port_info(struct mlx4_dev
> *dev, int port)
> info->port_attr.store = set_port_type;
> sysfs_attr_init(&info->port_attr.attr);
>
> + err = mlx4_qp_reserve_range(dev, 1, 1, &info->base_qpn);
> + if (err) {
> + mlx4_err(dev, "Failed to reserve QP range for port %d\n",
> port);
> + info->port = -1;
> + return err;
> + }
> +
> err = device_create_file(&dev->pdev->dev, &info->port_attr);
> if (err) {
> mlx4_err(dev, "Failed to create file for port %d\n", port);
>
> Could you take a look at getting this working? (Or update the driver
> so it immediately fails with an informative message if you want to
> rely on certain FW versions; and then strip out the old broken
> compatibility code)
>
> Thanks!
> Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] netfilter: xt_rateest: fix xt_rateest_mt_checkentry()
From: Eric Dumazet @ 2011-07-29 3:51 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, netdev, Jan Engelhardt
commit 4a5a5c73b7cfee (slightly better error reporting) added some
useless code in xt_rateest_mt_checkentry().
Fix this so that different error codes can really be returned.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jan Engelhardt <jengelh@medozas.de>
---
net/netfilter/xt_rateest.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c
index 76a0831..ed0db15 100644
--- a/net/netfilter/xt_rateest.c
+++ b/net/netfilter/xt_rateest.c
@@ -78,7 +78,7 @@ static int xt_rateest_mt_checkentry(const struct xt_mtchk_param *par)
{
struct xt_rateest_match_info *info = par->matchinfo;
struct xt_rateest *est1, *est2;
- int ret = false;
+ int ret = -EINVAL;
if (hweight32(info->flags & (XT_RATEEST_MATCH_ABS |
XT_RATEEST_MATCH_REL)) != 1)
@@ -101,13 +101,12 @@ static int xt_rateest_mt_checkentry(const struct xt_mtchk_param *par)
if (!est1)
goto err1;
+ est2 = NULL;
if (info->flags & XT_RATEEST_MATCH_REL) {
est2 = xt_rateest_lookup(info->name2);
if (!est2)
goto err2;
- } else
- est2 = NULL;
-
+ }
info->est1 = est1;
info->est2 = est2;
@@ -116,7 +115,7 @@ static int xt_rateest_mt_checkentry(const struct xt_mtchk_param *par)
err2:
xt_rateest_put(est1);
err1:
- return -EINVAL;
+ return ret;
}
static void xt_rateest_mt_destroy(const struct xt_mtdtor_param *par)
^ permalink raw reply related
* Re: [PATCH] net/smsc911x: add device tree probe support
From: Shawn Guo @ 2011-07-29 2:36 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Grant Likely, patches, netdev, devicetree-discuss,
Steve Glendinning, Shawn Guo, David S. Miller, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1107252222540.12766@xanadu.home>
On Mon, Jul 25, 2011 at 10:28:05PM -0400, Nicolas Pitre wrote:
> On Tue, 26 Jul 2011, Shawn Guo wrote:
>
> > On Mon, Jul 25, 2011 at 09:16:40PM -0400, Nicolas Pitre wrote:
> > > On Tue, 26 Jul 2011, Shawn Guo wrote:
> > >
> > > > On Mon, Jul 25, 2011 at 03:37:23PM -0600, Grant Likely wrote:
> > > > > On Mon, Jul 25, 2011 at 05:44:00PM +0800, Shawn Guo wrote:
> > > > > > It adds device tree probe support for smsc911x driver.
> > > > > >
> > > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > > > > Cc: Grant Likely <grant.likely@secretlab.ca>
> > > > > > Cc: Steve Glendinning <steve.glendinning@smsc.com>
> > > > > > Cc: David S. Miller <davem@davemloft.net>
> > > > > > ---
> > > > > > Documentation/devicetree/bindings/net/smsc.txt | 34 +++++++
> > > > > > drivers/net/smsc911x.c | 123 +++++++++++++++++++-----
> > > > > > 2 files changed, 132 insertions(+), 25 deletions(-)
> > > > > > create mode 100644 Documentation/devicetree/bindings/net/smsc.txt
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/net/smsc.txt b/Documentation/devicetree/bindings/net/smsc.txt
> > > > > > new file mode 100644
> > > > > > index 0000000..1920695
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/net/smsc.txt
> > > > > > @@ -0,0 +1,34 @@
> > > > > > +* Smart Mixed-Signal Connectivity (SMSC) LAN Controller
> > > > > > +
> > > > > > +Required properties:
> > > > > > +- compatible : Should be "smsc,lan<model>""smsc,lan"
> > > > >
> > > > > Drop "smsc,lan". That's far too generic.
> > > > >
> > > > The following devices are supported by the driver.
> > > >
> > > > LAN9115, LAN9116, LAN9117, LAN9118
> > > > LAN9215, LAN9216, LAN9217, LAN9218
> > > > LAN9210, LAN9211
> > > > LAN9220, LAN9221
> > > >
> > > > If we only keep specific <model> as the compatible, we will have a
> > > > long match table which is actually used nowhere to distinguish the
> > > > device.
> > > >
> > > > So we need some level generic compatible to save the meaningless
> > > > long match table. What about:
> > > >
> > > > static const struct of_device_id smsc_dt_ids[] = {
> > > > { .compatible = "smsc,lan9", },
> > > > { /* sentinel */ }
> > > > };
> > > >
> > > > Or:
> > > >
> > > > static const struct of_device_id smsc_dt_ids[] = {
> > > > { .compatible = "smsc,lan91", },
> > > > { .compatible = "smsc,lan92", },
> > > > { /* sentinel */ }
> > > > };
> > >
> > > None of this unambiguously distinguish the devices supported by this
> > > driver and the smc91x driver which supports LAN91C92, LAN91C94,
> > > LAN91C95, LAN91C96, LAN91C100, LAN91C110.
> > >
> > So you suggest to make a long list to explicitly tell the device type
> > that the driver supports?
>
> I'm not suggesting anything. :-) I'm merely pointing out that the
> above .compatible = "smsc,lan9" or .compatible = "smsc,lan91" are too
> generic given that there is another driver with different devices to
> which they could also apply.
>
Since I do not get any suggestion here, I'm going to follow the driver
name to use '911' as the model number. Please tell me if there is any
better one.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-07-29 1:46 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A83C0F0752@HQ1-EXCH01.corp.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 18:45:11 -0700
> Can you please put these into net-next tree?
Ok.
^ permalink raw reply
* RE: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: Rasesh Mody @ 2011-07-29 1:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20110728.182835.1135590491635663404.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, July 28, 2011 6:29 PM
>
>So are these bug fixes or cleanups/features? You don't say where
>you intend these changes to go.
Can you please put these into net-next tree? These patches remove unnecessary code and updates h/w initialize code.
We'll submit the features/cleanups patches in subsequent submissions against net-next.
Thanks,
Rasesh
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: David Miller @ 2011-07-29 1:39 UTC (permalink / raw)
To: horms
Cc: lvs-devel, netdev, netfilter-devel, netfilter, wensong, ja, kaber,
pablo, davej, rdunlap, huajun.li.lee, davem
In-Reply-To: <20110729001203.GB31217@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Fri, 29 Jul 2011 09:12:06 +0900
> What is the best way forward to get this both in 3.1 and 3.0 -stable?
I'll take this directly and do the -stable submission too.
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-07-29 1:28 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
So are these bug fixes or cleanups/features? You don't say where
you intend these changes to go.
^ permalink raw reply
* Re: [PATCH] xfrm: Fix key lengths for rfc3686(ctr(aes))
From: David Miller @ 2011-07-29 1:25 UTC (permalink / raw)
To: tgohad; +Cc: latten, herbert, netdev
In-Reply-To: <alpine.LFD.1.10.1107281246381.11308@net-test1.az.mvista.com>
From: Tushar Gohad <tgohad@mvista.com>
Date: Thu, 28 Jul 2011 13:36:20 -0700 (MST)
>
> Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
> The number of bits in key spec is the key length (128/256)
> plus 32 bits of nonce.
>
> This change takes care of the "Invalid key length" errors
> reported by setkey when specifying 288 bit keys for aes-ctr.
>
> Signed-off-by: Tushar Gohad <tgohad@mvista.com>
APplied.
^ permalink raw reply
* Re: [patch 2/2] proc_fork_connector: a lockless ->real_parent usage is not safe
From: David Miller @ 2011-07-29 1:27 UTC (permalink / raw)
To: akpm; +Cc: netdev, oleg, johnpol, vzapolskiy, zbr
In-Reply-To: <201107282054.p6SKsPtJ007979@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 28 Jul 2011 13:54:25 -0700
> From: Oleg Nesterov <oleg@redhat.com>
>
> proc_fork_connector() uses ->real_parent lockless. This is not safe if
> copy_process() was called with CLONE_THREAD or CLONE_PARENT, in this case
> the parent != current can go away at any moment.
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> Cc: Vladimir Zapolskiy <vzapolskiy@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Evgeniy Polyakov <zbr@ioremap.net>
> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 1/2] MAINTAINERS: orphan FrameRelay DLCI
From: David Miller @ 2011-07-29 1:25 UTC (permalink / raw)
To: akpm; +Cc: netdev, joe, shemminger
In-Reply-To: <201107282054.p6SKsOik007975@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 28 Jul 2011 13:54:23 -0700
> From: Joe Perches <joe@perches.com>
>
> Mike McLagan hasn't contributed in many years and his email bounces.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Cc: David Miller <davem@davemloft.net>
> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: Oops when insmod rtl8192ce
From: Hubert Liao @ 2011-07-29 1:21 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, wlanfae, Chaoming Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <4E31788F.7000307@lwfinger.net>
2011/7/28 Larry Finger <Larry.Finger@lwfinger.net>:
> On 07/28/2011 02:06 AM, hubert Liao wrote:
>>
>> 2011/7/27 John W. Linville<linville@tuxdriver.com>:
>>>
>>> On Wed, Jul 27, 2011 at 05:20:15PM +0800, hubert Liao wrote:
>>>>
>>>> Hi,
>>>>
>>>> We got an oops when insmod rtl8192ce module (the board is an ARM soc),
>>>> accroding the oops message, find it's because in rtl_pci_probe() called
>>>> _rtl_pci_find_adapter(),
>>>> in this funcation, the pdev->bus->self is a NULL pointer .
>>>>
>>>> static boot _rtl_pci_find_adapter(strcut pci_dev *dev,
>>>> struct ieee80211_hw *hw)
>>>> {
>>>>
>>>> struct pci_dev *bridge_pdev = pdev->bus->self; //line 1601
>>>> ...
>>>>
>>>> pcipriv->ndis_adapter.pcibridge_vendorid = bridge_pdev->vendor;<-- [oops
>>>> here] line 1700
>>>>
>>>> ...
>>>> }
>>>>
>>>> here, I just want to know why the bus->self is NULL?
>>>
>>> pdev is coming straight from what is passed to the PCI probe routine.
>>> It seems like pdev->bus->self should already be set before that
>>> happens.
>>>
>> Yes, I think it should be initialized when added the pci bus bridge,
>> I have checked the mach-kirkwood(my board is arch/arm/mach-kirkwood)
>> pcie related code, and I think when system initialized should call
>> kirkwood_pcie_init() ->
>> kirkwood_pcie_scan_bus() ->
>> pci_scan_bus() ->
>> pci_bus_add_devices()
>> if the pci_bus->self was initialized in pci_bus_add_devices()?
>> Maybe the code is too complex for me , I really can not find where
>> set the “->self" member?
>
> I added a request to the bugzilla entry to post the full dmesg output there.
> Perhaps there is some clue in the bus setup.
>
I have added the full dmesg output on bugzilla.
thanks.
> Larry
>
>
^ permalink raw reply
* Re: [PATCH] net: fix new sunrpc kernel-doc warning
From: David Miller @ 2011-07-29 1:20 UTC (permalink / raw)
To: rdunlap; +Cc: netdev
In-Reply-To: <20110728095436.6fdb3eb4.rdunlap@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Thu, 28 Jul 2011 09:54:36 -0700
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix new kernel-doc warning in sunrpc:
>
> Warning(net/sunrpc/xprt.c:196): No description found for parameter 'xprt'
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Applied.
^ permalink raw reply
* Re: [PATCH] sis190: Rx filter init is needed for MAC address change.
From: David Miller @ 2011-07-29 1:18 UTC (permalink / raw)
To: romieu; +Cc: netdev, klement2
In-Reply-To: <20110728160322.GA11480@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 28 Jul 2011 18:03:22 +0200
> From: Klement Fish <klement2@azet.sk>
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=34552
>
> Signed-off-by: Klement Fish <klement2@azet.sk>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied.
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: Simon Horman @ 2011-07-29 0:12 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, Dave Jones, Randy Dunlap, Huajun Li,
David S. Miller
In-Reply-To: <1311293920-1983-1-git-send-email-horms@verge.net.au>
On Fri, Jul 22, 2011 at 09:18:39AM +0900, Simon Horman wrote:
> Hi Pablo, Hi Patrick,
>
> please consider pulling
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-2.6.git master
>
> to get the following crash on module removal fix for IPVS.
>
> Sorry for sending this so very, very late in the release cycle.
> I had sent it earlier but it seems to have slipped through the cracks
> somehow.
>
> Simon Horman (1):
> IPVS: Free resources on module removal
>
> net/netfilter/ipvs/ip_vs_ctl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Ping.
What is the best way forward to get this both in 3.1 and 3.0 -stable?
^ permalink raw reply
* Re: [PATCH] xfrm: Fix key lengths for rfc3686(ctr(aes))
From: Herbert Xu @ 2011-07-29 0:05 UTC (permalink / raw)
To: Tushar Gohad; +Cc: Joy Latten, netdev
In-Reply-To: <alpine.LFD.1.10.1107281246381.11308@net-test1.az.mvista.com>
On Thu, Jul 28, 2011 at 01:36:20PM -0700, Tushar Gohad wrote:
>
> Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
> The number of bits in key spec is the key length (128/256)
> plus 32 bits of nonce.
>
> This change takes care of the "Invalid key length" errors
> reported by setkey when specifying 288 bit keys for aes-ctr.
>
> Signed-off-by: Tushar Gohad <tgohad@mvista.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 05/14] userns: clamp down users of cap_raised
From: Serge E. Hallyn @ 2011-07-28 23:51 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Serge Hallyn, dhowells, netdev, containers, linux-kernel,
ebiederm
In-Reply-To: <20110728232337.GA9186@albatros>
Quoting Vasiliy Kulikov (segooon@gmail.com):
> On Tue, Jul 26, 2011 at 18:58 +0000, Serge Hallyn wrote:
> > From: Serge E. Hallyn <serge.hallyn@canonical.com>
> >
> > A few modules are using cap_raised(current_cap(), cap) to authorize
> > actions, but the privilege should be applicable against the initial
> > user namespace. Refuse privilege if the caller is not in init_user_ns.
> >
> > Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > ---
> > drivers/block/drbd/drbd_nl.c | 5 +++++
> > drivers/md/dm-log-userspace-transfer.c | 3 +++
> > drivers/staging/pohmelfs/config.c | 3 +++
> > drivers/video/uvesafb.c | 3 +++
> > 4 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
> > index 515bcd9..7717f8a 100644
> > --- a/drivers/block/drbd/drbd_nl.c
> > +++ b/drivers/block/drbd/drbd_nl.c
> > @@ -2297,6 +2297,11 @@ static void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms
> > return;
> > }
> >
> > + if (current_user_ns() != &init_user_ns) {
> [...]
> > if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
> [...]
>
> Looks like it is an often pattern. Maybe move both checks to a
> function?
This pattern is used 4 times (IIRC). The reason I didn't break it out is
that it's very close to just 'capable(CAP_SYS_ADMIN)', which also checks
for CAP_SYS_ADMIN to the init_user_ns. But the above, rightly or wrongly,
does not set the PF_SUPERPRIV task flag. I don't want to advocate usage
of the above, and creating a helper for the above would both further
pollute the capability-related function namespace, and make the above
look more legitimate than I think it is.
Imo 'cap-raised(current_cap(), X)' should not be used at all. But I
didn't want to deal with that here, just make it user-ns safe.
-serge
^ 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