* 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 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: [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] 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 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: [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: 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: [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] 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
* [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: "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
* 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: 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
* 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: 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
* 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: 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: 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: 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: 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
* [PATCH] net: filter: Convert the BPF VM to threaded code
From: Rui Ueyama @ 2011-07-29 8:10 UTC (permalink / raw)
To: netdev
Convert the BPF VM to threaded code to improve performance.
The BPF VM is basically a big for loop containing a switch statement. That is
slow because for each instruction it checks the for loop condition and does the
conditional branch of the switch statement.
This patch eliminates the conditional branch, by replacing it with jump table
using GCC's labels-as-values feature. The for loop condition check can also be
removed, because the filter code always end with a RET instruction.
Signed-off-by: Rui Ueyama <rui314@gmail.com>
---
include/linux/filter.h | 60 +------
include/linux/filter_inst.h | 57 ++++++
net/core/filter.c | 457 +++++++++++++++++++++----------------------
3 files changed, 289 insertions(+), 285 deletions(-)
create mode 100644 include/linux/filter_inst.h
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 741956f..2f72166 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -172,62 +172,10 @@ static inline void bpf_jit_free(struct sk_filter *fp)
#endif
enum {
- BPF_S_RET_K = 1,
- BPF_S_RET_A,
- BPF_S_ALU_ADD_K,
- BPF_S_ALU_ADD_X,
- BPF_S_ALU_SUB_K,
- BPF_S_ALU_SUB_X,
- BPF_S_ALU_MUL_K,
- BPF_S_ALU_MUL_X,
- BPF_S_ALU_DIV_X,
- BPF_S_ALU_AND_K,
- BPF_S_ALU_AND_X,
- BPF_S_ALU_OR_K,
- BPF_S_ALU_OR_X,
- BPF_S_ALU_LSH_K,
- BPF_S_ALU_LSH_X,
- BPF_S_ALU_RSH_K,
- BPF_S_ALU_RSH_X,
- BPF_S_ALU_NEG,
- BPF_S_LD_W_ABS,
- BPF_S_LD_H_ABS,
- BPF_S_LD_B_ABS,
- BPF_S_LD_W_LEN,
- BPF_S_LD_W_IND,
- BPF_S_LD_H_IND,
- BPF_S_LD_B_IND,
- BPF_S_LD_IMM,
- BPF_S_LDX_W_LEN,
- BPF_S_LDX_B_MSH,
- BPF_S_LDX_IMM,
- BPF_S_MISC_TAX,
- BPF_S_MISC_TXA,
- BPF_S_ALU_DIV_K,
- BPF_S_LD_MEM,
- BPF_S_LDX_MEM,
- BPF_S_ST,
- BPF_S_STX,
- BPF_S_JMP_JA,
- BPF_S_JMP_JEQ_K,
- BPF_S_JMP_JEQ_X,
- BPF_S_JMP_JGE_K,
- BPF_S_JMP_JGE_X,
- BPF_S_JMP_JGT_K,
- BPF_S_JMP_JGT_X,
- BPF_S_JMP_JSET_K,
- BPF_S_JMP_JSET_X,
- /* Ancillary data */
- BPF_S_ANC_PROTOCOL,
- BPF_S_ANC_PKTTYPE,
- BPF_S_ANC_IFINDEX,
- BPF_S_ANC_NLATTR,
- BPF_S_ANC_NLATTR_NEST,
- BPF_S_ANC_MARK,
- BPF_S_ANC_QUEUE,
- BPF_S_ANC_HATYPE,
- BPF_S_ANC_RXHASH,
- BPF_S_ANC_CPU,
+ BPF_S_DUMMY = 0,
+#define BPF_INST(inst) inst,
+#include "filter_inst.h"
+#undef BPF_INST
};
#endif /* __KERNEL__ */
diff --git a/include/linux/filter_inst.h b/include/linux/filter_inst.h
new file mode 100644
index 0000000..235a797
--- /dev/null
+++ b/include/linux/filter_inst.h
@@ -0,0 +1,57 @@
+BPF_INST(BPF_S_RET_K)
+BPF_INST(BPF_S_RET_A)
+BPF_INST(BPF_S_ALU_ADD_K)
+BPF_INST(BPF_S_ALU_ADD_X)
+BPF_INST(BPF_S_ALU_SUB_K)
+BPF_INST(BPF_S_ALU_SUB_X)
+BPF_INST(BPF_S_ALU_MUL_K)
+BPF_INST(BPF_S_ALU_MUL_X)
+BPF_INST(BPF_S_ALU_DIV_X)
+BPF_INST(BPF_S_ALU_AND_K)
+BPF_INST(BPF_S_ALU_AND_X)
+BPF_INST(BPF_S_ALU_OR_K)
+BPF_INST(BPF_S_ALU_OR_X)
+BPF_INST(BPF_S_ALU_LSH_K)
+BPF_INST(BPF_S_ALU_LSH_X)
+BPF_INST(BPF_S_ALU_RSH_K)
+BPF_INST(BPF_S_ALU_RSH_X)
+BPF_INST(BPF_S_ALU_NEG)
+BPF_INST(BPF_S_LD_W_ABS)
+BPF_INST(BPF_S_LD_H_ABS)
+BPF_INST(BPF_S_LD_B_ABS)
+BPF_INST(BPF_S_LD_W_LEN)
+BPF_INST(BPF_S_LD_W_IND)
+BPF_INST(BPF_S_LD_H_IND)
+BPF_INST(BPF_S_LD_B_IND)
+BPF_INST(BPF_S_LD_IMM)
+BPF_INST(BPF_S_LDX_W_LEN)
+BPF_INST(BPF_S_LDX_B_MSH)
+BPF_INST(BPF_S_LDX_IMM)
+BPF_INST(BPF_S_MISC_TAX)
+BPF_INST(BPF_S_MISC_TXA)
+BPF_INST(BPF_S_ALU_DIV_K)
+BPF_INST(BPF_S_LD_MEM)
+BPF_INST(BPF_S_LDX_MEM)
+BPF_INST(BPF_S_ST)
+BPF_INST(BPF_S_STX)
+BPF_INST(BPF_S_JMP_JA)
+BPF_INST(BPF_S_JMP_JEQ_K)
+BPF_INST(BPF_S_JMP_JEQ_X)
+BPF_INST(BPF_S_JMP_JGE_K)
+BPF_INST(BPF_S_JMP_JGE_X)
+BPF_INST(BPF_S_JMP_JGT_K)
+BPF_INST(BPF_S_JMP_JGT_X)
+BPF_INST(BPF_S_JMP_JSET_K)
+BPF_INST(BPF_S_JMP_JSET_X)
+
+/* Ancillary data */
+BPF_INST(BPF_S_ANC_PROTOCOL)
+BPF_INST(BPF_S_ANC_PKTTYPE)
+BPF_INST(BPF_S_ANC_IFINDEX)
+BPF_INST(BPF_S_ANC_NLATTR)
+BPF_INST(BPF_S_ANC_NLATTR_NEST)
+BPF_INST(BPF_S_ANC_MARK)
+BPF_INST(BPF_S_ANC_QUEUE)
+BPF_INST(BPF_S_ANC_HATYPE)
+BPF_INST(BPF_S_ANC_RXHASH)
+BPF_INST(BPF_S_ANC_CPU)
diff --git a/net/core/filter.c b/net/core/filter.c
index 36f975f..e0c9d2c 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -119,245 +119,244 @@ unsigned int sk_run_filter(const struct sk_buff *skb,
u32 tmp;
int k;
- /*
- * Process array of filter instructions.
- */
- for (;; fentry++) {
-#if defined(CONFIG_X86_32)
+ static void *jump_table[] = {
+ NULL,
+#define BPF_INST(inst) &&inst,
+#include <linux/filter_inst.h>
+#undef BPF_INST
+ };
+
#define K (fentry->k)
-#else
- const u32 K = fentry->k;
-#endif
-
- switch (fentry->code) {
- case BPF_S_ALU_ADD_X:
- A += X;
- continue;
- case BPF_S_ALU_ADD_K:
- A += K;
- continue;
- case BPF_S_ALU_SUB_X:
- A -= X;
- continue;
- case BPF_S_ALU_SUB_K:
- A -= K;
- continue;
- case BPF_S_ALU_MUL_X:
- A *= X;
- continue;
- case BPF_S_ALU_MUL_K:
- A *= K;
- continue;
- case BPF_S_ALU_DIV_X:
- if (X == 0)
- return 0;
- A /= X;
- continue;
- case BPF_S_ALU_DIV_K:
- A = reciprocal_divide(A, K);
- continue;
- case BPF_S_ALU_AND_X:
- A &= X;
- continue;
- case BPF_S_ALU_AND_K:
- A &= K;
- continue;
- case BPF_S_ALU_OR_X:
- A |= X;
- continue;
- case BPF_S_ALU_OR_K:
- A |= K;
- continue;
- case BPF_S_ALU_LSH_X:
- A <<= X;
- continue;
- case BPF_S_ALU_LSH_K:
- A <<= K;
- continue;
- case BPF_S_ALU_RSH_X:
- A >>= X;
- continue;
- case BPF_S_ALU_RSH_K:
- A >>= K;
- continue;
- case BPF_S_ALU_NEG:
- A = -A;
- continue;
- case BPF_S_JMP_JA:
- fentry += K;
- continue;
- case BPF_S_JMP_JGT_K:
- fentry += (A > K) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JGE_K:
- fentry += (A >= K) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JEQ_K:
- fentry += (A == K) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JSET_K:
- fentry += (A & K) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JGT_X:
- fentry += (A > X) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JGE_X:
- fentry += (A >= X) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JEQ_X:
- fentry += (A == X) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_JMP_JSET_X:
- fentry += (A & X) ? fentry->jt : fentry->jf;
- continue;
- case BPF_S_LD_W_ABS:
- k = K;
-load_w:
- ptr = load_pointer(skb, k, 4, &tmp);
- if (ptr != NULL) {
- A = get_unaligned_be32(ptr);
- continue;
- }
+#define NEXT goto *jump_table[(++fentry)->code]
+
+ /* Dispatch the first instruction */
+ goto *jump_table[fentry->code];
+
+ BPF_S_ALU_ADD_X:
+ A += X;
+ NEXT;
+ BPF_S_ALU_ADD_K:
+ A += K;
+ NEXT;
+ BPF_S_ALU_SUB_X:
+ A -= X;
+ NEXT;
+ BPF_S_ALU_SUB_K:
+ A -= K;
+ NEXT;
+ BPF_S_ALU_MUL_X:
+ A *= X;
+ NEXT;
+ BPF_S_ALU_MUL_K:
+ A *= K;
+ NEXT;
+ BPF_S_ALU_DIV_X:
+ if (X == 0)
+ return 0;
+ A /= X;
+ NEXT;
+ BPF_S_ALU_DIV_K:
+ A = reciprocal_divide(A, K);
+ NEXT;
+ BPF_S_ALU_AND_X:
+ A &= X;
+ NEXT;
+ BPF_S_ALU_AND_K:
+ A &= K;
+ NEXT;
+ BPF_S_ALU_OR_X:
+ A |= X;
+ NEXT;
+ BPF_S_ALU_OR_K:
+ A |= K;
+ NEXT;
+ BPF_S_ALU_LSH_X:
+ A <<= X;
+ NEXT;
+ BPF_S_ALU_LSH_K:
+ A <<= K;
+ NEXT;
+ BPF_S_ALU_RSH_X:
+ A >>= X;
+ NEXT;
+ BPF_S_ALU_RSH_K:
+ A >>= K;
+ NEXT;
+ BPF_S_ALU_NEG:
+ A = -A;
+ NEXT;
+ BPF_S_JMP_JA:
+ fentry += K;
+ NEXT;
+ BPF_S_JMP_JGT_K:
+ fentry += (A > K) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JGE_K:
+ fentry += (A >= K) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JEQ_K:
+ fentry += (A == K) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JSET_K:
+ fentry += (A & K) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JGT_X:
+ fentry += (A > X) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JGE_X:
+ fentry += (A >= X) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JEQ_X:
+ fentry += (A == X) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_JMP_JSET_X:
+ fentry += (A & X) ? fentry->jt : fentry->jf;
+ NEXT;
+ BPF_S_LD_W_ABS:
+ k = K;
+ load_w:
+ ptr = load_pointer(skb, k, 4, &tmp);
+ if (ptr != NULL) {
+ A = get_unaligned_be32(ptr);
+ NEXT;
+ }
+ return 0;
+ BPF_S_LD_H_ABS:
+ k = K;
+ load_h:
+ ptr = load_pointer(skb, k, 2, &tmp);
+ if (ptr != NULL) {
+ A = get_unaligned_be16(ptr);
+ NEXT;
+ }
+ return 0;
+ BPF_S_LD_B_ABS:
+ k = K;
+ load_b:
+ ptr = load_pointer(skb, k, 1, &tmp);
+ if (ptr != NULL) {
+ A = *(u8 *)ptr;
+ NEXT;
+ }
+ return 0;
+ BPF_S_LD_W_LEN:
+ A = skb->len;
+ NEXT;
+ BPF_S_LDX_W_LEN:
+ X = skb->len;
+ NEXT;
+ BPF_S_LD_W_IND:
+ k = X + K;
+ goto load_w;
+ BPF_S_LD_H_IND:
+ k = X + K;
+ goto load_h;
+ BPF_S_LD_B_IND:
+ k = X + K;
+ goto load_b;
+ BPF_S_LDX_B_MSH:
+ ptr = load_pointer(skb, K, 1, &tmp);
+ if (ptr != NULL) {
+ X = (*(u8 *)ptr & 0xf) << 2;
+ NEXT;
+ }
+ return 0;
+ BPF_S_LD_IMM:
+ A = K;
+ NEXT;
+ BPF_S_LDX_IMM:
+ X = K;
+ NEXT;
+ BPF_S_LD_MEM:
+ A = mem[K];
+ NEXT;
+ BPF_S_LDX_MEM:
+ X = mem[K];
+ NEXT;
+ BPF_S_MISC_TAX:
+ X = A;
+ NEXT;
+ BPF_S_MISC_TXA:
+ A = X;
+ NEXT;
+ BPF_S_RET_K:
+ return K;
+ BPF_S_RET_A:
+ return A;
+ BPF_S_ST:
+ mem[K] = A;
+ NEXT;
+ BPF_S_STX:
+ mem[K] = X;
+ NEXT;
+ BPF_S_ANC_PROTOCOL:
+ A = ntohs(skb->protocol);
+ NEXT;
+ BPF_S_ANC_PKTTYPE:
+ A = skb->pkt_type;
+ NEXT;
+ BPF_S_ANC_IFINDEX:
+ if (!skb->dev)
+ return 0;
+ A = skb->dev->ifindex;
+ NEXT;
+ BPF_S_ANC_MARK:
+ A = skb->mark;
+ NEXT;
+ BPF_S_ANC_QUEUE:
+ A = skb->queue_mapping;
+ NEXT;
+ BPF_S_ANC_HATYPE:
+ if (!skb->dev)
+ return 0;
+ A = skb->dev->type;
+ NEXT;
+ BPF_S_ANC_RXHASH:
+ A = skb->rxhash;
+ NEXT;
+ BPF_S_ANC_CPU:
+ A = raw_smp_processor_id();
+ NEXT;
+ BPF_S_ANC_NLATTR:
+ {
+ struct nlattr *nla;
+
+ if (skb_is_nonlinear(skb))
return 0;
- case BPF_S_LD_H_ABS:
- k = K;
-load_h:
- ptr = load_pointer(skb, k, 2, &tmp);
- if (ptr != NULL) {
- A = get_unaligned_be16(ptr);
- continue;
- }
+ if (A > skb->len - sizeof(struct nlattr))
return 0;
- case BPF_S_LD_B_ABS:
- k = K;
-load_b:
- ptr = load_pointer(skb, k, 1, &tmp);
- if (ptr != NULL) {
- A = *(u8 *)ptr;
- continue;
- }
+
+ nla = nla_find((struct nlattr *)&skb->data[A],
+ skb->len - A, X);
+ if (nla)
+ A = (void *)nla - (void *)skb->data;
+ else
+ A = 0;
+ }
+ NEXT;
+ BPF_S_ANC_NLATTR_NEST:
+ {
+ struct nlattr *nla;
+
+ if (skb_is_nonlinear(skb))
return 0;
- case BPF_S_LD_W_LEN:
- A = skb->len;
- continue;
- case BPF_S_LDX_W_LEN:
- X = skb->len;
- continue;
- case BPF_S_LD_W_IND:
- k = X + K;
- goto load_w;
- case BPF_S_LD_H_IND:
- k = X + K;
- goto load_h;
- case BPF_S_LD_B_IND:
- k = X + K;
- goto load_b;
- case BPF_S_LDX_B_MSH:
- ptr = load_pointer(skb, K, 1, &tmp);
- if (ptr != NULL) {
- X = (*(u8 *)ptr & 0xf) << 2;
- continue;
- }
+ if (A > skb->len - sizeof(struct nlattr))
return 0;
- case BPF_S_LD_IMM:
- A = K;
- continue;
- case BPF_S_LDX_IMM:
- X = K;
- continue;
- case BPF_S_LD_MEM:
- A = mem[K];
- continue;
- case BPF_S_LDX_MEM:
- X = mem[K];
- continue;
- case BPF_S_MISC_TAX:
- X = A;
- continue;
- case BPF_S_MISC_TXA:
- A = X;
- continue;
- case BPF_S_RET_K:
- return K;
- case BPF_S_RET_A:
- return A;
- case BPF_S_ST:
- mem[K] = A;
- continue;
- case BPF_S_STX:
- mem[K] = X;
- continue;
- case BPF_S_ANC_PROTOCOL:
- A = ntohs(skb->protocol);
- continue;
- case BPF_S_ANC_PKTTYPE:
- A = skb->pkt_type;
- continue;
- case BPF_S_ANC_IFINDEX:
- if (!skb->dev)
- return 0;
- A = skb->dev->ifindex;
- continue;
- case BPF_S_ANC_MARK:
- A = skb->mark;
- continue;
- case BPF_S_ANC_QUEUE:
- A = skb->queue_mapping;
- continue;
- case BPF_S_ANC_HATYPE:
- if (!skb->dev)
- return 0;
- A = skb->dev->type;
- continue;
- case BPF_S_ANC_RXHASH:
- A = skb->rxhash;
- continue;
- case BPF_S_ANC_CPU:
- A = raw_smp_processor_id();
- continue;
- case BPF_S_ANC_NLATTR: {
- struct nlattr *nla;
-
- if (skb_is_nonlinear(skb))
- return 0;
- if (A > skb->len - sizeof(struct nlattr))
- return 0;
-
- nla = nla_find((struct nlattr *)&skb->data[A],
- skb->len - A, X);
- if (nla)
- A = (void *)nla - (void *)skb->data;
- else
- A = 0;
- continue;
- }
- case BPF_S_ANC_NLATTR_NEST: {
- struct nlattr *nla;
-
- if (skb_is_nonlinear(skb))
- return 0;
- if (A > skb->len - sizeof(struct nlattr))
- return 0;
-
- nla = (struct nlattr *)&skb->data[A];
- if (nla->nla_len > A - skb->len)
- return 0;
-
- nla = nla_find_nested(nla, X);
- if (nla)
- A = (void *)nla - (void *)skb->data;
- else
- A = 0;
- continue;
- }
- default:
- WARN_RATELIMIT(1, "Unknown code:%u jt:%u tf:%u k:%u\n",
- fentry->code, fentry->jt,
- fentry->jf, fentry->k);
+
+ nla = (struct nlattr *)&skb->data[A];
+ if (nla->nla_len > A - skb->len)
return 0;
- }
+
+ nla = nla_find_nested(nla, X);
+ if (nla)
+ A = (void *)nla - (void *)skb->data;
+ else
+ A = 0;
}
+ NEXT;
+#undef K
+#undef NEXT
return 0;
}
EXPORT_SYMBOL(sk_run_filter);
--
1.7.3.1
^ permalink raw reply related
* [PATCH v2] net/smsc911x: add device tree probe support
From: Shawn Guo @ 2011-07-29 8:43 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: patches-QSEj5FYQhm4dnm+yROfE0A,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Steve Glendinning,
David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1311587040-8988-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Steve Glendinning <steve.glendinning-sdUf+H5yV5I@public.gmane.org>
Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
---
Changes since v1:
* Instead of getting irq line from gpio number, it use irq domain
to keep platform_get_resource(IORESOURCE_IRQ) works for dt too.
* Use 'lan9115' the first model that smsc911x supports in the match
table
* Use reg-shift and reg-io-width which already used in of_serial for
shift and access size binding
Documentation/devicetree/bindings/net/smsc911x.txt | 38 +++++++++
drivers/net/smsc911x.c | 85 +++++++++++++++++---
2 files changed, 112 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
new file mode 100644
index 0000000..271c454
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -0,0 +1,38 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+Required properties:
+- compatible : Should be "smsc,lan<model>", "smsc,lan9115"
+- reg : Address and length of the io space for SMSC LAN
+- interrupts : Should contain SMSC LAN interrupt line
+- interrupt-parent : Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
+ "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+
+Optional properties:
+- reg-shift : Specify the quantity to shift the register offsets by
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,irq-active-high : Indicates the IRQ polarity is active-low
+- smsc,irq-push-pull : Indicates the IRQ type is push-pull
+- smsc,force-internal-phy : Forces SMSC LAN controller to use
+ internal PHY
+- smsc,force-external-phy : Forces SMSC LAN controller to use
+ external PHY
+- smsc,save-mac-address : Indicates that mac address needs to be saved
+ before resetting the controller
+- local-mac-address : 6 bytes, mac address
+
+Examples:
+
+lan9220@f4000000 {
+ compatible = "smsc,lan9220", "smsc,lan9115";
+ reg = <0xf4000000 0x2000000>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpio1>;
+ interrupts = <31>;
+ reg-io-width = <4>;
+ smsc,irq-push-pull;
+};
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index b9016a3..75c08a5 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -53,6 +53,10 @@
#include <linux/phy.h>
#include <linux/smsc911x.h>
#include <linux/device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/of_net.h>
#include "smsc911x.h"
#define SMSC_CHIPNAME "smsc911x"
@@ -2095,8 +2099,58 @@ static const struct smsc911x_ops shifted_smsc911x_ops = {
.tx_writefifo = smsc911x_tx_writefifo_shift,
};
+#ifdef CONFIG_OF
+static int __devinit smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ const char *mac;
+ u32 width = 0;
+
+ if (!np)
+ return -ENODEV;
+
+ config->phy_interface = of_get_phy_mode(np);
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ memcpy(config->mac, mac, ETH_ALEN);
+
+ of_property_read_u32(np, "reg-shift", &config->shift);
+
+ of_property_read_u32(np, "reg-io-width", &width);
+ if (width == 4)
+ config->flags |= SMSC911X_USE_32BIT;
+
+ if (of_get_property(np, "smsc,irq-active-high", NULL))
+ config->irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
+
+ if (of_get_property(np, "smsc,irq-push-pull", NULL))
+ config->irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
+
+ if (of_get_property(np, "smsc,force-internal-phy", NULL))
+ config->flags |= SMSC911X_FORCE_INTERNAL_PHY;
+
+ if (of_get_property(np, "smsc,force-external-phy", NULL))
+ config->flags |= SMSC911X_FORCE_EXTERNAL_PHY;
+
+ if (of_get_property(np, "smsc,save-mac-address", NULL))
+ config->flags |= SMSC911X_SAVE_MAC_ADDRESS;
+
+ return 0;
+}
+#else
+static inline int smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF */
+
static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
struct net_device *dev;
struct smsc911x_data *pdata;
struct smsc911x_platform_config *config = pdev->dev.platform_data;
@@ -2107,13 +2161,6 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
pr_info("Driver version %s\n", SMSC_DRV_VERSION);
- /* platform data specifies irq & dynamic bus configuration */
- if (!pdev->dev.platform_data) {
- pr_warn("platform_data not provided\n");
- retval = -ENODEV;
- goto out_0;
- }
-
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"smsc911x-memory");
if (!res)
@@ -2152,9 +2199,6 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
pdata->ioaddr = ioremap_nocache(res->start, res_size);
- /* copy config parameters across to pdata */
- memcpy(&pdata->config, config, sizeof(pdata->config));
-
pdata->dev = dev;
pdata->msg_enable = ((1 << debug) - 1);
@@ -2164,10 +2208,22 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
goto out_free_netdev_2;
}
+ retval = smsc911x_probe_config_dt(&pdata->config, np);
+ if (retval && config) {
+ /* copy config parameters across to pdata */
+ memcpy(&pdata->config, config, sizeof(pdata->config));
+ retval = 0;
+ }
+
+ if (retval) {
+ SMSC_WARN(pdata, probe, "Error smsc911x config not found");
+ goto out_unmap_io_3;
+ }
+
/* assume standard, non-shifted, access to HW registers */
pdata->ops = &standard_smsc911x_ops;
/* apply the right access if shifting is needed */
- if (config->shift)
+ if (pdata->config.shift)
pdata->ops = &shifted_smsc911x_ops;
retval = smsc911x_init(dev);
@@ -2314,6 +2370,12 @@ static const struct dev_pm_ops smsc911x_pm_ops = {
#define SMSC911X_PM_OPS NULL
#endif
+static const struct of_device_id smsc911x_dt_ids[] = {
+ { .compatible = "smsc,lan9115", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, smsc911x_dt_ids);
+
static struct platform_driver smsc911x_driver = {
.probe = smsc911x_drv_probe,
.remove = __devexit_p(smsc911x_drv_remove),
@@ -2321,6 +2383,7 @@ static struct platform_driver smsc911x_driver = {
.name = SMSC_CHIPNAME,
.owner = THIS_MODULE,
.pm = SMSC911X_PM_OPS,
+ .of_match_table = smsc911x_dt_ids,
},
};
--
1.7.4.1
^ permalink raw reply related
* [patch] cfg80211: off by one in nl80211_trigger_scan()
From: Dan Carpenter @ 2011-07-29 8:52 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, David S. Miller, open list:CFG80211 and NL80211,
open list:NETWORKING [GENERAL],
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
The test is off by one so we'd read past the end of the
wiphy->bands[] array on the next line.
Signed-off-by: Dan Carpenter <error27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 28d2aa1..e83e7fe 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3464,7 +3464,7 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
tmp) {
enum ieee80211_band band = nla_type(attr);
- if (band < 0 || band > IEEE80211_NUM_BANDS) {
+ if (band < 0 || band >= IEEE80211_NUM_BANDS) {
err = -EINVAL;
goto out_free;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 related
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Eric Dumazet @ 2011-07-29 9:30 UTC (permalink / raw)
To: Rui Ueyama; +Cc: netdev
In-Reply-To: <CACKH++ZfNTB7Y8YhvQnZPEXpwmpWXzxQgnWniamDrjRWUwxaNw@mail.gmail.com>
Le vendredi 29 juillet 2011 à 01:10 -0700, Rui Ueyama a écrit :
> Convert the BPF VM to threaded code to improve performance.
>
> The BPF VM is basically a big for loop containing a switch statement. That is
> slow because for each instruction it checks the for loop condition and does the
> conditional branch of the switch statement.
>
> This patch eliminates the conditional branch, by replacing it with jump table
> using GCC's labels-as-values feature. The for loop condition check can also be
> removed, because the filter code always end with a RET instruction.
>
Well...
> +#define NEXT goto *jump_table[(++fentry)->code]
> +
> + /* Dispatch the first instruction */
> + goto *jump_table[fentry->code];
This is the killer, as this cannot be predicted by the cpu.
Do you have benchmark results to provide ?
We now have BPF JIT on x86_64 and powerpc, and possibly on MIPS and ARM
on a near future.
^ permalink raw reply
* Re: Fw: [PATCH] sunrpc: use better NUMA affinities
From: Christoph Hellwig @ 2011-07-29 10:36 UTC (permalink / raw)
To: Greg Banks
Cc: Eric Dumazet, NeilBrown, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
David Miller, linux-kernel, netdev
In-Reply-To: <4E3258E1.6020000-97jfqw80gc6171pxa8y+qA@public.gmane.org>
On Fri, Jul 29, 2011 at 04:53:21PM +1000, Greg Banks wrote:
> >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 :(
kthread_create doesn't have a cpu argument - it has a printf-like format
string.
--
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
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