* Re: pskb_copy() in tcp_transmit_skb()
From: Gao feng @ 2011-09-13 12:00 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev
In-Reply-To: <201109131355.55588.christoph.paasch@uclouvain.be>
于 11-9-13 下午6:55, Christoph Paasch 写道:
> Hi,
>
> On Tuesday 13 September 2011 wrote Gaofeng:
>>> I'm trying to understand the reason for the possible call to pskb_copy()
>>> in tcp_transmit_skb().
>>> I don't find, where we may have a cloned skb entering tcp_transmit_skb().
>>>
>>> The original pskb_copy() came from tcp_retransmit_skb() (commit
>>> dfb4b9dceb35c567a595ae5e9d035cfda044a103).
>>> But from that point, the git-history does not show where the pskb_copy()
>>> is coming from.
>>>
>>>
>>> Does somebody has an idea, how a cloned skb can be passed to
>>> tcp_transmit_skb() and thus trigger this call to pskb_copy().
>>
>> maybe nat,nat can change the tcp packet header
>
> although NAT may change the TCP header, it is not doing an skb_clone() - (at
> least I don't find it).
> Thus, we will not call pskb_copy() in tcp_transmit_skb() due to NAT.
>
> Christoph
>
> --
> Christoph Paasch
> PhD Student
>
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
> Université Catholique de Louvain
>
> www.rollerbulls.be
> --
> --
> 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
>
maybe this.
if the nic driver has not transmit the cloned skb to the network yet.
then tcp_retransmit_skb is called by some logical.
if dont use pskb_copy here,it will make the nat or some header operation
error.
^ permalink raw reply
* Re: pskb_copy() in tcp_transmit_skb()
From: Christoph Paasch @ 2011-09-13 12:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Gaofeng, netdev
In-Reply-To: <CAL4Wiio=2MO2u53dvU1fqjeKqgQuVBmgDpZeVROMaZYcPPDpzA@mail.gmail.com>
Eric,
On Tuesday 13 September 2011 wrote Eric Dumazet:
> I suggest you read dev_queue_xmit_nit() : Every xmit packet can be
> cloned right here.
>
> By the time tcp_retransmit_skb() is called, cloned skb might still be
> in a AF_PACKET queue (or even a device TX queue)
Thanks for the clear answer.
So, basically every call to tcp_retransmit_skb on an skb that is also still
hold in an AF_PACKET queue will end up in pskb_copy, because:
1. it has been cloned previously in tcp_transmit_skb()
2. The data_ref > 1 because it's clone is still in an AF_PACKET queue.
Please correct me, if I'm wrong.
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Jeff Layton @ 2011-09-13 12:51 UTC (permalink / raw)
To: Trond Myklebust
Cc: Stanislav Kinsbursky, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <1315596308.17611.46.camel@lade.trondhjem.org>
On Fri, 09 Sep 2011 15:25:08 -0400
Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> On Fri, 2011-09-09 at 15:01 -0400, Jeff Layton wrote:
> > On Fri, 09 Sep 2011 14:44:34 -0400
> > Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> >
> > > On Fri, 2011-09-09 at 20:41 +0400, Stanislav Kinsbursky wrote:
> > > > 09.09.2011 18:07, Jeff Layton пишет:
> > > > > On Fri, 09 Sep 2011 16:08:44 +0400
> > > > > Stanislav Kinsbursky<skinsbursky@parallels.com> wrote:
> > > > >
> > > > >> Create rcbind clients or increase rpcbind users counter during RPC service
> > > > >> creation and decrease this counter (and possibly destroy those clients) on RPC
> > > > >> service destruction.
> > > > >>
> > > > >> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
> > > > >>
> > > > >> ---
> > > > >> include/linux/sunrpc/clnt.h | 2 ++
> > > > >> net/sunrpc/rpcb_clnt.c | 2 +-
> > > > >> net/sunrpc/svc.c | 13 +++++++++++--
> > > > >> 3 files changed, 14 insertions(+), 3 deletions(-)
> > > > >>
> > > > >> diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
> > > > >> index db7bcaf..65a8115 100644
> > > > >> --- a/include/linux/sunrpc/clnt.h
> > > > >> +++ b/include/linux/sunrpc/clnt.h
> > > > >> @@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
> > > > >> void rpc_release_client(struct rpc_clnt *);
> > > > >> void rpc_task_release_client(struct rpc_task *);
> > > > >>
> > > > >> +int rpcb_create_local(void);
> > > > >> int rpcb_register(u32, u32, int, unsigned short);
> > > > >> int rpcb_v4_register(const u32 program, const u32 version,
> > > > >> const struct sockaddr *address,
> > > > >> const char *netid);
> > > > >> +void rpcb_put_local(void);
> > > > >> void rpcb_getport_async(struct rpc_task *);
> > > > >>
> > > > >> void rpc_call_start(struct rpc_task *);
> > > > >> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> > > > >> index b4cc0f1..437ec60 100644
> > > > >> --- a/net/sunrpc/rpcb_clnt.c
> > > > >> +++ b/net/sunrpc/rpcb_clnt.c
> > > > >> @@ -318,7 +318,7 @@ out:
> > > > >> * Returns zero on success, otherwise a negative errno value
> > > > >> * is returned.
> > > > >> */
> > > > >> -static int rpcb_create_local(void)
> > > > >> +int rpcb_create_local(void)
> > > > >> {
> > > > >> static DEFINE_MUTEX(rpcb_create_local_mutex);
> > > > >> int result = 0;
> > > > >> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> > > > >> index 6a69a11..9095c0e 100644
> > > > >> --- a/net/sunrpc/svc.c
> > > > >> +++ b/net/sunrpc/svc.c
> > > > >> @@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> > > > >> unsigned int xdrsize;
> > > > >> unsigned int i;
> > > > >>
> > > > >> - if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
> > > > >> + if (rpcb_create_local()< 0)
> > > > >> return NULL;
> > > > >> +
> > > > >> + if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
> > > > >> + goto out_err;
> > > > >> serv->sv_name = prog->pg_name;
> > > > >> serv->sv_program = prog;
> > > > >> serv->sv_nrthreads = 1;
> > > > >> @@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> > > > >> GFP_KERNEL);
> > > > >> if (!serv->sv_pools) {
> > > > >> kfree(serv);
> > > > >> - return NULL;
> > > > >> + goto out_err;
> > > > >> }
> > > > >>
> > > > >> for (i = 0; i< serv->sv_nrpools; i++) {
> > > > >> @@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> > > > >> svc_unregister(serv);
> > > > >>
> > > > >> return serv;
> > > > >> +
> > > > >> +out_err:
> > > > >> + rpcb_put_local();
> > > > >> + return NULL;
> > > > >> }
> > > > >>
> > > > >> struct svc_serv *
> > > > >> @@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
> > > > >> svc_unregister(serv);
> > > > >> kfree(serv->sv_pools);
> > > > >> kfree(serv);
> > > > >> +
> > > > >> + rpcb_put_local();
> > > > >> }
> > > > >> EXPORT_SYMBOL_GPL(svc_destroy);
> > > > >>
> > > > >>
> > > > >
> > > > > I don't get it -- what's the advantage of creating rpcbind clients in
> > > > > __svc_create vs. the old way of creating them just before we plan to
> > > > > use them?
> > > > >
> > > >
> > > > The main problem here is not in creation, but in destroying those clients.
> > > > Now rpcbind clients are created during rpcb_register(). I.e. once per every family, program version and so on.
> > > > But can be unregistered for all protocol families by one call. So it's impossible to put reference counting for those clients in the place, where they are created now.
> > >
> > > Could we perhaps set up a 'struct pernet_operations' to create a
> > > destructor for them?
> > >
> >
> > An even easier idea might be to just not take a reference to the
> > rpcbind client for svc_programs that have vs_hidden set on every
> > version.
>
> Isn't the problem that Stanislav is trying to solve that we need to be
> able to register and unregister RPC services to the correct rpcbind
> server, depending on which net namespace we are in?
>
> My understanding is that the current code will register everything to
> whatever rpcbind server is running in the init net namespace because
> that's what rpcb_create_local() uses.
>
My assumption in reading this set (maybe wrong) was that this was a
preliminary set for now that just plops in function calls in the places
that do this sort of thing now. I figured that eventually he'd convert
rpcb_create_local, et. al. to do the same thing but within the correct
namespace for the calling task.
> My suggestion is to use a struct pernet_operations to detect when a net
> namespace is being created or destroyed, so that the rpcbind client code
> knows when to create or destroy a connection to the server that is
> running in that namespace.
>
I'm not sure that solves anything. I'd also ass|u|me that something
here (the xprt?) will hold a reference to its netns. If we try to do
this with pernet ops, then I think we'd end up with a chicken-and-egg
problem...
I think the simplest solution would be to basically call these
functions closer to where the rpcbind calls happen today, and just
don't do them when the svc_program has vs_hidden set or if the xprt is
being created with SVC_SOCK_ANONYMOUS set.
In fact, a rethink of the vs_hidden/SVC_SOCK_ANONYMOUS scheme would
probably be a good preliminary patch here. There's a lot of overlap
between those two flags, and somehow consolidating them would probably
be a good thing.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* Re: pskb_copy() in tcp_transmit_skb()
From: Eric Dumazet @ 2011-09-13 12:51 UTC (permalink / raw)
To: christoph.paasch; +Cc: Gaofeng, netdev
In-Reply-To: <201109131541.08542.christoph.paasch@uclouvain.be>
Le 13 septembre 2011 14:41, Christoph Paasch
<christoph.paasch@uclouvain.be> a écrit :
> Eric,
>
> On Tuesday 13 September 2011 wrote Eric Dumazet:
>> I suggest you read dev_queue_xmit_nit() : Every xmit packet can be
>> cloned right here.
>>
>> By the time tcp_retransmit_skb() is called, cloned skb might still be
>> in a AF_PACKET queue (or even a device TX queue)
>
> Thanks for the clear answer.
>
> So, basically every call to tcp_retransmit_skb on an skb that is also still
> hold in an AF_PACKET queue will end up in pskb_copy, because:
> 1. it has been cloned previously in tcp_transmit_skb()
> 2. The data_ref > 1 because it's clone is still in an AF_PACKET queue.
>
> Please correct me, if I'm wrong.
Thats correct.
^ permalink raw reply
* Re: Temporary(?) relocation of wireless git trees...
From: John W. Linville @ 2011-09-13 13:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, David Woodhouse,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110913105858.eedd5ac594679aa36111c9d4-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
On Tue, Sep 13, 2011 at 10:58:58AM +1000, Stephen Rothwell wrote:
> Hi John,
>
> On Mon, 12 Sep 2011 14:13:52 -0400 "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> >
> > With no news on when the kernel.org trees will be accessible again
> > (which could be 10 minutes from now for all I know), I have pushed
> > my local copies to Infradead. This should be equivalent to what was
> > last pushed to kernel.org almost two weeks ago.
> >
> > The "current" wireless tree is here:
> >
> > git://git.infradead.org/users/linville/wireless.git
> >
> > The "next" wireless tree is here:
> >
> > git://git.infradead.org/users/linville/wireless-next.git
>
> OK, I have switched to these using their "master" branches. There is
> nothing new in them, correct?
Yes, correct. Hopefully more new stuff today...
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Stanislav Kinsbursky @ 2011-09-13 13:39 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond Myklebust, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <20110913085139.00f112e2@corrin.poochiereds.net>
13.09.2011 16:51, Jeff Layton пишет:
> My assumption in reading this set (maybe wrong) was that this was a
> preliminary set for now that just plops in function calls in the places
> that do this sort of thing now. I figured that eventually he'd convert
> rpcb_create_local, et. al. to do the same thing but within the correct
> namespace for the calling task.
>
You have a right assumption. This is exactly what I'm going to do next.
>
> I think the simplest solution would be to basically call these
> functions closer to where the rpcbind calls happen today, and just
> don't do them when the svc_program has vs_hidden set or if the xprt is
> being created with SVC_SOCK_ANONYMOUS set.
>
This solution is not the simplest one since we call svc_register() for every svc
socket if it's not anonymous. But svc_unregister() is called only once for all
inet families and protocols.
Also I've noticed, that we call svc_unregister in __svc_create(). I.e. we call
it for nfs callbacks as well (in spite of that we don't need this). Thus, for
now, nfs callbacks service creation depends on rpcbind clients presence.
So, for my pow, we need something like startup() callback, passed to
svc_create(_pooled)() to clean up this mess.
This callback will be defined only for lockd and nfsd and will create rpcbind
clients and remove any stale portmap registrations.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Jeff Layton @ 2011-09-13 13:52 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond Myklebust,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pavel Emelianov, neilb-l3A5Bk7waGM@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <4E6F5D2F.4050100-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Tue, 13 Sep 2011 17:39:59 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> 13.09.2011 16:51, Jeff Layton пишет:
> > My assumption in reading this set (maybe wrong) was that this was a
> > preliminary set for now that just plops in function calls in the places
> > that do this sort of thing now. I figured that eventually he'd convert
> > rpcb_create_local, et. al. to do the same thing but within the correct
> > namespace for the calling task.
> >
>
> You have a right assumption. This is exactly what I'm going to do next.
>
> >
> > I think the simplest solution would be to basically call these
> > functions closer to where the rpcbind calls happen today, and just
> > don't do them when the svc_program has vs_hidden set or if the xprt is
> > being created with SVC_SOCK_ANONYMOUS set.
> >
>
> This solution is not the simplest one since we call svc_register() for every svc
> socket if it's not anonymous. But svc_unregister() is called only once for all
> inet families and protocols.
>
Ahh ok, good point.
> Also I've noticed, that we call svc_unregister in __svc_create(). I.e. we call
> it for nfs callbacks as well (in spite of that we don't need this). Thus, for
> now, nfs callbacks service creation depends on rpcbind clients presence.
>
Yeah, that's just to remove the any existing registration before we set
up the new one. In the case of a "hidden" service that can probably be
skipped if it makes things easier.
> So, for my pow, we need something like startup() callback, passed to
> svc_create(_pooled)() to clean up this mess.
> This callback will be defined only for lockd and nfsd and will create rpcbind
> clients and remove any stale portmap registrations.
>
That sounds like a reasonable scheme. I'll wait to see the patches.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
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: user namespaces v3: continue targetting capabilities
From: Serge E. Hallyn @ 2011-09-13 14:43 UTC (permalink / raw)
To: akpm, segooon, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap
In-Reply-To: <1314993400-6910-1-git-send-email-serge@hallyn.com>
I did a bit of basic performance testing - just running unixbench
and doing a kernel compile (without profiling) with and without
this patchset, with USER_NS enabled for both. I could find no
meaningful impact.
473.01user 32.48system 9:05.44elapsed 92%CPU (0avgtext+0avgdata 430752maxresident)k
112736inputs+576936outputs (8major+22057422minor)pagefaults 0swaps
473.78user 33.12system 9:06.14elapsed 92%CPU (0avgtext+0avgdata 430752maxresident)k
116656inputs+576936outputs (12major+22056621minor)pagefaults 0swaps
and with:
474.09user 31.62system 9:05.70elapsed 92%CPU (0avgtext+0avgdata 430752maxresident)k
112648inputs+576936outputs (7major+22056909minor)pagefaults 0swaps
472.54user 33.26system 9:05.43elapsed 92%CPU (0avgtext+0avgdata 430608maxresident)k
116656inputs+576936outputs (12major+22058358minor)pagefaults 0swaps
I'll append the full unixbench outputs below, but index score without
the patchset was 1594.3, and with the patchset was 1597.4.
thanks,
-serge
=====================================================================
unixbench without patchset:
=====================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: marula: GNU/Linux
OS: GNU/Linux -- 3.0.0-11-server -- #17-Ubuntu SMP Fri Sep 9 19:31:36 UTC 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5530 @ 2.40GHz (4800.3 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
02:43:44 up 3:00, 1 user, load average: 0.05, 0.03, 0.03; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Mon Sep 12 2011 02:43:44 - 03:11:55
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 28147322.1 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3289.7 MWIPS (10.0 s, 7 samples)
Execl Throughput 4557.5 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1145450.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 312941.7 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1969030.8 KBps (30.0 s, 2 samples)
Pipe Throughput 2080076.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 331910.6 lps (10.0 s, 7 samples)
Process Creation 14921.7 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6989.7 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 913.9 lpm (60.0 s, 2 samples)
System Call Overhead 3453367.4 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 28147322.1 2411.9
Double-Precision Whetstone 55.0 3289.7 598.1
Execl Throughput 43.0 4557.5 1059.9
File Copy 1024 bufsize 2000 maxblocks 3960.0 1145450.6 2892.6
File Copy 256 bufsize 500 maxblocks 1655.0 312941.7 1890.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 1969030.8 3394.9
Pipe Throughput 12440.0 2080076.5 1672.1
Pipe-based Context Switching 4000.0 331910.6 829.8
Process Creation 126.0 14921.7 1184.3
Shell Scripts (1 concurrent) 42.4 6989.7 1648.5
Shell Scripts (8 concurrent) 6.0 913.9 1523.2
System Call Overhead 15000.0 3453367.4 2302.2
========
System Benchmarks Index Score 1594.3
=====================================================================
unixbench with patchset:
=====================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: marula: GNU/Linux
OS: GNU/Linux -- 3.0.0-11-server -- #17userns1 SMP Mon Sep 12 13:42:40 UTC 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5530 @ 2.40GHz (4799.6 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
12:42:07 up 8 min, 1 user, load average: 0.00, 0.01, 0.02; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Mon Sep 12 2011 12:42:07 - 13:10:19
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 28232156.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3290.0 MWIPS (10.0 s, 7 samples)
Execl Throughput 4553.7 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1142317.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 317068.8 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1956611.4 KBps (30.0 s, 2 samples)
Pipe Throughput 2086728.8 lps (10.0 s, 7 samples)
Pipe-based Context Switching 343275.1 lps (10.0 s, 7 samples)
Process Creation 14718.6 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6989.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 913.6 lpm (60.0 s, 2 samples)
System Call Overhead 3434956.0 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 28232156.4 2419.2
Double-Precision Whetstone 55.0 3290.0 598.2
Execl Throughput 43.0 4553.7 1059.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 1142317.5 2884.6
File Copy 256 bufsize 500 maxblocks 1655.0 317068.8 1915.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 1956611.4 3373.5
Pipe Throughput 12440.0 2086728.8 1677.4
Pipe-based Context Switching 4000.0 343275.1 858.2
Process Creation 126.0 14718.6 1168.1
Shell Scripts (1 concurrent) 42.4 6989.0 1648.3
Shell Scripts (8 concurrent) 6.0 913.6 1522.6
System Call Overhead 15000.0 3434956.0 2290.0
========
System Benchmarks Index Score 1597.4
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Justin Piszcz @ 2011-09-13 14:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs, linux-kernel
In-Reply-To: <1315886706.2556.11.camel@edumazet-laptop>
On Tue, 13 Sep 2011, Eric Dumazet wrote:
> Please Justin make sure you pulled commit
>
> commit ed2888e906b56769b4ffabb9c577190438aa68b8
> Author: Jon Mason <mason@myri.com>
> Date: Thu Sep 8 16:41:18 2011 -0500
>
> PCI: Remove MRRS modification from MPS setting code
>
> Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
> massive negative ramifications on some devices. Without knowing which
> devices have this issue, do not modify from the default value when
> walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
> the default procedure.
>
> Tested-by: Sven Schnelle <svens@stackframe.org>
> Tested-by: Simon Kirby <sim@hostway.ca>
> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.
> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
> Signed-off-by: Jon Mason <mason@myri.com>
> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Hello,
I found this commit here:
http://permalink.gmane.org/gmane.linux.kernel.pci/11700
Applied:
# patch -p1 < ../ed2888e906b56769b4ffabb9c577190438aa68b8.txt
patching file drivers/pci/probe.c
I will update this thread if the problem recurs, can someone also please advise
which DEBUG options I should have enabled to catch further SLAB/RCU issues?
So far, I have the following enabled:
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_PER_CPU_MAPS=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_RODATA=y
Thanks,
Justin.
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Eric Dumazet @ 2011-09-13 14:58 UTC (permalink / raw)
To: Justin Piszcz
Cc: Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs, linux-kernel
In-Reply-To: <alpine.DEB.2.02.1109130722210.21380@p34.internal.lan>
2011/9/13 Justin Piszcz <jpiszcz@lucidpixels.com>:
>
> I found this commit here:
> http://permalink.gmane.org/gmane.linux.kernel.pci/11700
>
> Applied:
> # patch -p1 < ../ed2888e906b56769b4ffabb9c577190438aa68b8.txt patching file
> drivers/pci/probe.c
>
>
Oh, I should have sent the git anchor you can use instead of searching the web ;
git pull https://github.com/torvalds/linux.git
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Balazs Scheidler @ 2011-09-13 15:27 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Maciej Żenczykowski, netdev
In-Reply-To: <1314990654-32252-1-git-send-email-zenczykowski@gmail.com>
On Fri, 2011-09-02 at 12:10 -0700, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
> the same bit in the socket struct) have required CAP_NET_ADMIN
> privileges to set or clear the option.
>
> - we make clearing the bit not require any privileges.
> - we deprecate using CAP_NET_ADMIN for this purpose.
> - we introduce a new capability CAP_NET_TRANSPARENT,
> which is tailored to allow setting just this bit.
> - we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
> to set this bit, because raw sockets already effectively
> allow you to emulate socket transparency, and make the
> transition easier for apps not desiring to use a brand
> new capability (because of header file or glibc support)
> - we print a warning (but allow it) if you try to set
> the socket option with CAP_NET_ADMIN privs, but without
> either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.
>
> The reason for introducing a new capability is that while
> transparent sockets are potentially dangerous (and can let you
> spoof your source IP on traffic), they don't normally give you
> the full 'freedom' of eavesdropping and/or spoofing that raw sockets
> give you.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> CC: Balazs Scheidler <bazsi@balabit.hu>
This is ok for me, as long as the security maintainers allow the
introduction of this new cap.
Thanks for doing this and sorry for the late reply.
Acked-by: Balazs Scheidler <bazsi@balabit.hu>
--
Bazsi
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Jon Mason @ 2011-09-13 15:35 UTC (permalink / raw)
To: Justin Piszcz
Cc: Eric Dumazet, Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs,
linux-kernel
In-Reply-To: <alpine.DEB.2.02.1109130722210.21380@p34.internal.lan>
On Tue, Sep 13, 2011 at 9:54 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
>
> On Tue, 13 Sep 2011, Eric Dumazet wrote:
>
>> Please Justin make sure you pulled commit
>> commit ed2888e906b56769b4ffabb9c577190438aa68b8
>> Author: Jon Mason <mason@myri.com>
>> Date: Thu Sep 8 16:41:18 2011 -0500
>>
>> PCI: Remove MRRS modification from MPS setting code
>>
>> Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
>> massive negative ramifications on some devices. Without knowing which
>> devices have this issue, do not modify from the default value when
>> walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
>> the default procedure.
>>
>> Tested-by: Sven Schnelle <svens@stackframe.org>
>> Tested-by: Simon Kirby <sim@hostway.ca>
>> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Reported-and-tested-by: Niels Ole Salscheider
>> <niels_ole@salscheider-online.
>> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
>> Signed-off-by: Jon Mason <mason@myri.com>
>> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> Hello,
>
> I found this commit here:
> http://permalink.gmane.org/gmane.linux.kernel.pci/11700
This is an early version of the patch. This is the patch that you want:
https://github.com/torvalds/linux/commit/ed2888e906b56769b4ffabb9c577190438aa68b8
It appears that this patch didn't make it to lkml or linux-pci list
due to kernel.org DNS being down when it was sent.
Thanks,
Jon
>
> Applied:
> # patch -p1 < ../ed2888e906b56769b4ffabb9c577190438aa68b8.txt patching file
> drivers/pci/probe.c
>
> I will update this thread if the problem recurs, can someone also please
> advise
> which DEBUG options I should have enabled to catch further SLAB/RCU issues?
>
> So far, I have the following enabled:
>
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_X86_DEBUGCTLMSR=y
> CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_SLAB=y
> CONFIG_DEBUG_SLAB_LEAK=y
> CONFIG_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_STACK_USAGE=y
> CONFIG_DEBUG_BUGVERBOSE=y
> CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_VM=y
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_DEBUG_PER_CPU_MAPS=y
> CONFIG_DEBUG_PAGEALLOC=y
> CONFIG_DEBUG_STACKOVERFLOW=y
> CONFIG_DEBUG_RODATA=y
>
> Thanks,
>
> Justin.
>
> --
> 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
>
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Justin Piszcz @ 2011-09-13 15:42 UTC (permalink / raw)
To: Jon Mason
Cc: Eric Dumazet, Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs,
linux-kernel
In-Reply-To: <CAMaF-rN-qeXBDoc9=7kwu40Wj8=G8YuPKWXPRhOuhdYX_VO34w@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1906 bytes --]
On Tue, 13 Sep 2011, Jon Mason wrote:
> On Tue, Sep 13, 2011 at 9:54 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>
>>
>> On Tue, 13 Sep 2011, Eric Dumazet wrote:
>>
>>> Please Justin make sure you pulled commit
>>> commit ed2888e906b56769b4ffabb9c577190438aa68b8
>>> Author: Jon Mason <mason@myri.com>
>>> Date: Thu Sep 8 16:41:18 2011 -0500
>>>
>>> PCI: Remove MRRS modification from MPS setting code
>>>
>>> Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
>>> massive negative ramifications on some devices. Without knowing which
>>> devices have this issue, do not modify from the default value when
>>> walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
>>> the default procedure.
>>>
>>> Tested-by: Sven Schnelle <svens@stackframe.org>
>>> Tested-by: Simon Kirby <sim@hostway.ca>
>>> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>>> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
>>> Reported-and-tested-by: Niels Ole Salscheider
>>> <niels_ole@salscheider-online.
>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
>>> Signed-off-by: Jon Mason <mason@myri.com>
>>> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>
>> Hello,
>>
>> I found this commit here:
>> http://permalink.gmane.org/gmane.linux.kernel.pci/11700
>
> This is an early version of the patch. This is the patch that you want:
> https://github.com/torvalds/linux/commit/ed2888e906b56769b4ffabb9c577190438aa68b8
>
> It appears that this patch didn't make it to lkml or linux-pci list
> due to kernel.org DNS being down when it was sent.
>
> Thanks,
> Jon
I need to learn how to use git at some point, can you please provide plain
text patches so I can apply them and reboot?
Justin.
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Jon Mason @ 2011-09-13 15:51 UTC (permalink / raw)
To: Justin Piszcz
Cc: Eric Dumazet, Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs,
linux-kernel
In-Reply-To: <alpine.DEB.2.02.1109131142010.7113@p34.internal.lan>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
On Tue, Sep 13, 2011 at 10:42 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
>
> On Tue, 13 Sep 2011, Jon Mason wrote:
>
>> On Tue, Sep 13, 2011 at 9:54 AM, Justin Piszcz <jpiszcz@lucidpixels.com>
>> wrote:
>>>
>>>
>>> On Tue, 13 Sep 2011, Eric Dumazet wrote:
>>>
>>>> Please Justin make sure you pulled commit
>>>> commit ed2888e906b56769b4ffabb9c577190438aa68b8
>>>> Author: Jon Mason <mason@myri.com>
>>>> Date: Thu Sep 8 16:41:18 2011 -0500
>>>>
>>>> PCI: Remove MRRS modification from MPS setting code
>>>>
>>>> Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
>>>> massive negative ramifications on some devices. Without knowing which
>>>> devices have this issue, do not modify from the default value when
>>>> walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
>>>> the default procedure.
>>>>
>>>> Tested-by: Sven Schnelle <svens@stackframe.org>
>>>> Tested-by: Simon Kirby <sim@hostway.ca>
>>>> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>>>> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>> Reported-and-tested-by: Niels Ole Salscheider
>>>> <niels_ole@salscheider-online.
>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
>>>> Signed-off-by: Jon Mason <mason@myri.com>
>>>> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>>>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>
>>> Hello,
>>>
>>> I found this commit here:
>>> http://permalink.gmane.org/gmane.linux.kernel.pci/11700
>>
>> This is an early version of the patch. This is the patch that you want:
>>
>> https://github.com/torvalds/linux/commit/ed2888e906b56769b4ffabb9c577190438aa68b8
>>
>> It appears that this patch didn't make it to lkml or linux-pci list
>> due to kernel.org DNS being down when it was sent.
>>
>> Thanks,
>> Jon
>
> I need to learn how to use git at some point, can you please provide plain
> text patches so I can apply them and reboot?
>
> Justin.
I've attached the 2 patches I asked Linus to include into 3.1-rc6.
Let me know if there are any issues.
Thanks,
Jon
[-- Attachment #2: 0001-Fix-pointer-dereference-before-call-to-pcie_bus_conf.patch --]
[-- Type: text/x-patch, Size: 2344 bytes --]
From cf822aed99fd8851d82ae5f2df11c29b79e316c8 Mon Sep 17 00:00:00 2001
From: Shyam Iyer <shyam.iyer.t@gmail.com>
Date: Wed, 31 Aug 2011 12:21:42 -0400
Subject: [PATCH 1/2] Fix pointer dereference before call to
pcie_bus_configure_settings
There is a potential NULL pointer dereference in calls to
pcie_bus_configure_settings due to attempts to access pci_bus self
variables when the self pointer is NULL. To correct this, verify that
the self pointer in pci_bus is non-NULL before dereferencing it.
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
Signed-off-by: Jon Mason <mason@myri.com>
---
arch/x86/pci/acpi.c | 9 +++++++--
drivers/pci/hotplug/pcihp_slot.c | 4 +++-
drivers/pci/probe.c | 3 ---
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index c953302..039d913 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -365,8 +365,13 @@ struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_pci_root *root)
*/
if (bus) {
struct pci_bus *child;
- list_for_each_entry(child, &bus->children, node)
- pcie_bus_configure_settings(child, child->self->pcie_mpss);
+ list_for_each_entry(child, &bus->children, node) {
+ struct pci_dev *self = child->self;
+ if (!self)
+ continue;
+
+ pcie_bus_configure_settings(child, self->pcie_mpss);
+ }
}
if (!bus)
diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
index 753b21a..3ffd9c1 100644
--- a/drivers/pci/hotplug/pcihp_slot.c
+++ b/drivers/pci/hotplug/pcihp_slot.c
@@ -169,7 +169,9 @@ void pci_configure_slot(struct pci_dev *dev)
(dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
return;
- pcie_bus_configure_settings(dev->bus, dev->bus->self->pcie_mpss);
+ if (dev->bus && dev->bus->self)
+ pcie_bus_configure_settings(dev->bus,
+ dev->bus->self->pcie_mpss);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8473727..0820fc1 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1456,9 +1456,6 @@ void pcie_bus_configure_settings(struct pci_bus *bus, u8 mpss)
{
u8 smpss = mpss;
- if (!bus->self)
- return;
-
if (!pci_is_pcie(bus->self))
return;
--
1.7.6
[-- Attachment #3: 0002-PCI-Remove-MRRS-modification-from-MPS-setting-code.patch --]
[-- Type: text/x-patch, Size: 4404 bytes --]
From 74d81235f8e4bd60859d539a27e51d3a09d183cf Mon Sep 17 00:00:00 2001
From: Jon Mason <mason@myri.com>
Date: Thu, 8 Sep 2011 12:59:00 -0500
Subject: [PATCH 2/2] PCI: Remove MRRS modification from MPS setting code
Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
massive negative ramifications on some devices. Without knowing which
devices have this issue, do not modify from the default value when
walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
the default procedure.
Tested-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Simon Kirby <sim@hostway.ca>
Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/pci/pci.c | 2 +-
drivers/pci/probe.c | 41 ++++++++++++++++++++++-------------------
2 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0ce6742..4e84fd4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -77,7 +77,7 @@ unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
unsigned long pci_hotplug_io_size = DEFAULT_HOTPLUG_IO_SIZE;
unsigned long pci_hotplug_mem_size = DEFAULT_HOTPLUG_MEM_SIZE;
-enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_PERFORMANCE;
+enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_SAFE;
/*
* The default CLS is used if arch didn't set CLS explicitly and not
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 0820fc1..b1187ff 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1396,34 +1396,37 @@ static void pcie_write_mps(struct pci_dev *dev, int mps)
static void pcie_write_mrrs(struct pci_dev *dev, int mps)
{
- int rc, mrrs;
+ int rc, mrrs, dev_mpss;
- if (pcie_bus_config == PCIE_BUS_PERFORMANCE) {
- int dev_mpss = 128 << dev->pcie_mpss;
+ /* In the "safe" case, do not configure the MRRS. There appear to be
+ * issues with setting MRRS to 0 on a number of devices.
+ */
- /* For Max performance, the MRRS must be set to the largest
- * supported value. However, it cannot be configured larger
- * than the MPS the device or the bus can support. This assumes
- * that the largest MRRS available on the device cannot be
- * smaller than the device MPSS.
- */
- mrrs = mps < dev_mpss ? mps : dev_mpss;
- } else
- /* In the "safe" case, configure the MRRS for fairness on the
- * bus by making all devices have the same size
- */
- mrrs = mps;
+ if (pcie_bus_config != PCIE_BUS_PERFORMANCE)
+ return;
+
+ dev_mpss = 128 << dev->pcie_mpss;
+ /* For Max performance, the MRRS must be set to the largest supported
+ * value. However, it cannot be configured larger than the MPS the
+ * device or the bus can support. This assumes that the largest MRRS
+ * available on the device cannot be smaller than the device MPSS.
+ */
+ mrrs = min(mps, dev_mpss);
/* MRRS is a R/W register. Invalid values can be written, but a
- * subsiquent read will verify if the value is acceptable or not.
+ * subsequent read will verify if the value is acceptable or not.
* If the MRRS value provided is not acceptable (e.g., too large),
* shrink the value until it is acceptable to the HW.
*/
while (mrrs != pcie_get_readrq(dev) && mrrs >= 128) {
+ dev_warn(&dev->dev, "Attempting to modify the PCI-E MRRS value"
+ " to %d. If any issues are encountered, please try "
+ "running with pci=pcie_bus_safe\n", mrrs);
rc = pcie_set_readrq(dev, mrrs);
if (rc)
- dev_err(&dev->dev, "Failed attempting to set the MRRS\n");
+ dev_err(&dev->dev,
+ "Failed attempting to set the MRRS\n");
mrrs /= 2;
}
@@ -1436,13 +1439,13 @@ static int pcie_bus_configure_set(struct pci_dev *dev, void *data)
if (!pci_is_pcie(dev))
return 0;
- dev_info(&dev->dev, "Dev MPS %d MPSS %d MRRS %d\n",
+ dev_dbg(&dev->dev, "Dev MPS %d MPSS %d MRRS %d\n",
pcie_get_mps(dev), 128<<dev->pcie_mpss, pcie_get_readrq(dev));
pcie_write_mps(dev, mps);
pcie_write_mrrs(dev, mps);
- dev_info(&dev->dev, "Dev MPS %d MPSS %d MRRS %d\n",
+ dev_dbg(&dev->dev, "Dev MPS %d MPSS %d MRRS %d\n",
pcie_get_mps(dev), 128<<dev->pcie_mpss, pcie_get_readrq(dev));
return 0;
--
1.7.6
^ permalink raw reply related
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Justin Piszcz @ 2011-09-13 16:32 UTC (permalink / raw)
To: Jon Mason
Cc: Eric Dumazet, Jesse Brandeburg, Alan Piszcz, NetDEV list, xfs,
linux-kernel
In-Reply-To: <CAMaF-rMxTWRAO7WRdYoEM57k66MC6Vuwk1mcfgCgMO6Z+KBvzQ@mail.gmail.com>
On Tue, 13 Sep 2011, Jon Mason wrote:
> On Tue, Sep 13, 2011 at 10:42 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>
>>
>> On Tue, 13 Sep 2011, Jon Mason wrote:
>>
>>> On Tue, Sep 13, 2011 at 9:54 AM, Justin Piszcz <jpiszcz@lucidpixels.com>
>>> wrote:
>>>>
>>>>
>>>> On Tue, 13 Sep 2011, Eric Dumazet wrote:
>>>>
Thanks,
# patch -p1 < ../0001-Fix-pointer-dereference-before-call-to-pcie_bus_conf.patch
patching file arch/x86/pci/acpi.c
patching file drivers/pci/hotplug/pcihp_slot.c
patching file drivers/pci/probe.c
# patch -p1 < ../0002-PCI-Remove-MRRS-modification-from-MPS-setting-code.patch
patching file drivers/pci/pci.c
patching file drivers/pci/probe.c
#
Rebooted & running with new patches for 3.1-rc4.
Will let you know if any further issues, I wonder if this will fix
the RCU/SLAB issues too, thanks.
Justin.
^ permalink raw reply
* Re: pskb_copy() in tcp_transmit_skb()
From: David Miller @ 2011-09-13 16:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: christoph.paasch, gaofeng, netdev
In-Reply-To: <CAL4Wiio=2MO2u53dvU1fqjeKqgQuVBmgDpZeVROMaZYcPPDpzA@mail.gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 13 Sep 2011 14:02:17 +0200
> I suggest you read dev_queue_xmit_nit() : Every xmit packet can be
> cloned right here.
Right, any packet that has been sent in the past might now be
cloned.
^ permalink raw reply
* [PATCH] macmace, macsonic: cleanup
From: Finn Thain @ 2011-09-13 17:30 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
We check ether_type before registering the platform device in
arch/m68k/mac/config.c. Doing the same test again in the driver is
redundant so remove it.
Multiple probes should not happen since the conversion to platform devices,
so lose that test too.
Then macmace.c need not include macintosh.h, so remove that and irq.h and
include linux/interrupt.h explicitly.
Tested on PowerBook 520, Quadra 660av, LC 630.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Index: linux-m68k/drivers/net/macmace.c
===================================================================
--- linux-m68k.orig/drivers/net/macmace.c 2011-09-14 02:37:26.000000000 +1000
+++ linux-m68k/drivers/net/macmace.c 2011-09-14 02:39:08.000000000 +1000
@@ -31,9 +31,8 @@
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
#include <linux/gfp.h>
+#include <linux/interrupt.h>
#include <asm/io.h>
-#include <asm/irq.h>
-#include <asm/macintosh.h>
#include <asm/macints.h>
#include <asm/mac_psc.h>
#include <asm/page.h>
@@ -203,14 +202,8 @@ static int __devinit mace_probe(struct p
unsigned char *addr;
struct net_device *dev;
unsigned char checksum = 0;
- static int found = 0;
int err;
- if (found || macintosh_config->ether_type != MAC_ETHER_MACE)
- return -ENODEV;
-
- found = 1; /* prevent 'finding' one on every device probe */
-
dev = alloc_etherdev(PRIV_BYTES);
if (!dev)
return -ENOMEM;
Index: linux-m68k/drivers/net/macsonic.c
===================================================================
--- linux-m68k.orig/drivers/net/macsonic.c 2011-09-14 02:38:53.000000000 +1000
+++ linux-m68k/drivers/net/macsonic.c 2011-09-14 02:39:08.000000000 +1000
@@ -312,22 +312,13 @@ static void __devinit mac_onboard_sonic_
static int __devinit mac_onboard_sonic_probe(struct net_device *dev)
{
- /* Bwahahaha */
- static int once_is_more_than_enough;
struct sonic_local* lp = netdev_priv(dev);
int sr;
int commslot = 0;
- if (once_is_more_than_enough)
- return -ENODEV;
- once_is_more_than_enough = 1;
-
if (!MACH_IS_MAC)
return -ENODEV;
- if (macintosh_config->ether_type != MAC_ETHER_SONIC)
- return -ENODEV;
-
printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
/* Bogus probing, on the models which may or may not have
^ permalink raw reply
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Paul Menage @ 2011-09-13 18:09 UTC (permalink / raw)
To: Glauber Costa
Cc: Greg Thelen, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal, Lennart Poettering
In-Reply-To: <4E6E39DD.2040102@parallels.com>
On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa <glommer@parallels.com> wrote:
>
> I think at this point there is at least consensus that this could very well
> live in memcg, right ?
Yes, it looks that way.
>> This is definitely an improvement, but I'd say it's not enough. I
>> think we should consider something like:
>
> One step at a time =)
Yes, as far as design and initial implementation goes - but the full
plan has to be figured out before anything gets committed to mainline,
given the stability guarantees that implies.
>> - the 'active' control determines whether (all) child cgroups will
>> have memory.{limit,usage}_in_bytes files, or
>> memory.{kernel,user}_{limit,usage}_in_bytes files
>> - kernel memory will be charged either against 'kernel' or 'total'
>> depending on the value of unified
>
> You mean for display/pressure purposes, right? Internally, I think once we
> have kernel memory, we always charge it to kernel memory, regardless of
> anything else. The value in unified field will only take place when we need
> to grab this value.
>
> I don't personally see a reason for not having all files present at all
> times.
There's pretty much only one reason - avoiding the overhead of
maintaining multiple counters.
Each set of counters (user, kernel, total) will have its own locks,
contention and other overheads to keep up to date. If userspace
doesn't care about one or two of the three, then that's mostly wasted.
Now it might be that the accounting of all three can be done with
little more overhead than that required to update just a split view or
just a unified view, in which case there's much less argument against
simplifying and tracking/charging/limiting all three.
>
> It is overly flexible if we're exposing these counters and expecting the
> user to do anything with them. It is perfectly fine if a single file, when
> read, displays this information as statistics.
>
When I proposed this, I guess I was envisioning that most of the
counters (e.g. things like TCP buffers or general network buffers)
would be primarily for stats, since the admin probably only cares
about total memory usage.
The main point of this was to allow people who want to do something
like tracking/limiting TCP buffer usage specifically per-cgroup to do
so, without having any performance impact on the regular users.
Paul
--
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
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Glauber Costa @ 2011-09-13 18:11 UTC (permalink / raw)
To: Paul Menage
Cc: Greg Thelen, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal, Lennart Poettering
In-Reply-To: <CALdu-PC7ESSUHuF4vfVoRFFfkaBt1V28rGW3-O5pT3WtegAh4g@mail.gmail.com>
On 09/13/2011 03:09 PM, Paul Menage wrote:
> Each set of counters (user, kernel, total) will have its own locks,
> contention and other overheads to keep up to date. If userspace
> doesn't care about one or two of the three, then that's mostly wasted.
>
> Now it might be that the accounting of all three can be done with
> little more overhead than that required to update just a split view or
> just a unified view, in which case there's much less argument against
> simplifying and tracking/charging/limiting all three.
What if they are all updated under the same lock ?
The lock argument is very well valid for accounting vs not accounting
kernel memory. But once it is accounted, which counter we account to, I
think, is less of a problem.
--
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
* [PATCH v3 00/11] SUNRPC: make rpcbind clients allocated and destroyed dynamically
From: Stanislav Kinsbursky @ 2011-09-13 18:13 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
v3:
1) rebased to v3.1-rc6 (against branch
git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git)
2) creation and destruction on rpcbind clients now depends on service type
This patch is required for further RPC layer virtualization, because rpcbind
clients have to be per network namespace.
To achive this, we have to untie network namespace from rpcbind clients sockets.
The idea of this patch set is to make rpcbind clients non-static. I.e. rpcbind
clients will be created during first RPC service creation, and destroyed when
last RPC service is stopped.
With this patch set rpcbind clients can be virtualized easely.
The following series consists of:
---
Stanislav Kinsbursky (11):
SUNRPC: introduce helpers for reference counted rpcbind clients
SUNRPC: use rpcbind reference counting helpers
SUNRPC: introduce svc helpers for prepairing rpcbind infrastructure
SUNRPC: parametrize svc creation calls with portmapper flag
SUNRPC: cleanup service destruction
Lockd: force creation of rpcbind clients during service creation
NFS: avoid rpcbind clients creation during service creation
NFSd: force creation of rpcbind clients during service creation
NFSd: call svc rpcbind cleanup explicitly
SUNRPC: remove rpcbind clients creation during service registering
SUNRPC: remove rpcbind clients destruction on module cleanup
fs/lockd/svc.c | 2 +
fs/nfs/callback.c | 2 +
fs/nfsd/nfssvc.c | 4 ++
include/linux/sunrpc/clnt.h | 2 +
include/linux/sunrpc/svc.h | 3 ++
net/sunrpc/rpcb_clnt.c | 85 ++++++++++++++++++++++++++++---------------
net/sunrpc/sunrpc_syms.c | 3 --
net/sunrpc/svc.c | 41 +++++++++++++++++----
8 files changed, 98 insertions(+), 44 deletions(-)
--
Signature
^ permalink raw reply
* [PATCH v3 01/11] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-09-13 18:13 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110913180953.3961.69217.stgit@localhost6.localdomain6>
This helpers will be used for dynamical creation and destruction of rpcbind
clients.
Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
clients has been created already, then we just increase rpcb_users.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index e45d2fb..3f2bb8a 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
static struct rpc_clnt * rpcb_local_clnt;
static struct rpc_clnt * rpcb_local_clnt4;
+DEFINE_SPINLOCK(rpcb_clnt_lock);
+unsigned int rpcb_users;
+
struct rpcbind_args {
struct rpc_xprt * r_xprt;
@@ -161,6 +164,53 @@ static void rpcb_map_release(void *data)
kfree(map);
}
+static int rpcb_get_local(void)
+{
+ spin_lock(&rpcb_clnt_lock);
+ if (rpcb_users)
+ rpcb_users++;
+ spin_unlock(&rpcb_clnt_lock);
+
+ return rpcb_users;
+}
+
+void rpcb_put_local(void)
+{
+ struct rpc_clnt *clnt = rpcb_local_clnt;
+ struct rpc_clnt *clnt4 = rpcb_local_clnt4;
+ int shutdown;
+
+ spin_lock(&rpcb_clnt_lock);
+ if (--rpcb_users == 0) {
+ rpcb_local_clnt = NULL;
+ rpcb_local_clnt4 = NULL;
+ }
+ shutdown = !rpcb_users;
+ spin_unlock(&rpcb_clnt_lock);
+
+ if (shutdown) {
+ /*
+ * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
+ */
+ if (clnt4)
+ rpc_shutdown_client(clnt4);
+ if (clnt)
+ rpc_shutdown_client(clnt);
+ }
+ return;
+}
+
+static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
+{
+ /* Protected by rpcb_create_local_mutex */
+ rpcb_local_clnt = clnt;
+ rpcb_local_clnt4 = clnt4;
+ rpcb_users++;
+ dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
+ "0x%p, rpcb_local_clnt4: 0x%p)\n", rpcb_local_clnt,
+ rpcb_local_clnt4);
+}
+
/*
* Returns zero on success, otherwise a negative errno value
* is returned.
^ permalink raw reply related
* [PATCH v3 02/11] SUNRPC: use rpcbind reference counting helpers
From: Stanislav Kinsbursky @ 2011-09-13 18:13 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110913180953.3961.69217.stgit@localhost6.localdomain6>
All is simple: we just increase users counter if rpcbind clients has been
created already. Otherwise we create them and set users counter to 1.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 3f2bb8a..b3ac194 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -255,9 +255,7 @@ static int rpcb_create_local_unix(void)
clnt4 = NULL;
}
- /* Protected by rpcb_create_local_mutex */
- rpcb_local_clnt = clnt;
- rpcb_local_clnt4 = clnt4;
+ rpcb_set_local(clnt, clnt4);
out:
return result;
@@ -309,9 +307,7 @@ static int rpcb_create_local_net(void)
clnt4 = NULL;
}
- /* Protected by rpcb_create_local_mutex */
- rpcb_local_clnt = clnt;
- rpcb_local_clnt4 = clnt4;
+ rpcb_set_local(clnt, clnt4);
out:
return result;
@@ -326,11 +322,11 @@ static int rpcb_create_local(void)
static DEFINE_MUTEX(rpcb_create_local_mutex);
int result = 0;
- if (rpcb_local_clnt)
+ if (rpcb_get_local())
return result;
mutex_lock(&rpcb_create_local_mutex);
- if (rpcb_local_clnt)
+ if (rpcb_get_local())
goto out;
if (rpcb_create_local_unix() != 0)
^ permalink raw reply related
* [PATCH v3 03/11] SUNRPC: introduce svc helpers for prepairing rpcbind infrastructure
From: Stanislav Kinsbursky @ 2011-09-13 18:13 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110913180953.3961.69217.stgit@localhost6.localdomain6>
This helpers will be used only for those services, that will send portmapper
registration calls.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/clnt.h | 2 ++
net/sunrpc/rpcb_clnt.c | 2 +-
net/sunrpc/svc.c | 18 ++++++++++++++++++
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index db7bcaf..1eb437d 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -135,6 +135,8 @@ void rpc_shutdown_client(struct rpc_clnt *);
void rpc_release_client(struct rpc_clnt *);
void rpc_task_release_client(struct rpc_task *);
+int rpcb_create_local(void);
+void rpcb_put_local(void);
int rpcb_register(u32, u32, int, unsigned short);
int rpcb_v4_register(const u32 program, const u32 version,
const struct sockaddr *address,
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index b3ac194..d42b642 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -317,7 +317,7 @@ out:
* Returns zero on success, otherwise a negative errno value
* is returned.
*/
-static int rpcb_create_local(void)
+int rpcb_create_local(void)
{
static DEFINE_MUTEX(rpcb_create_local_mutex);
int result = 0;
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index 6a69a11..f31e5cc 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -354,6 +354,24 @@ svc_pool_for_cpu(struct svc_serv *serv, int cpu)
return &serv->sv_pools[pidx % serv->sv_nrpools];
}
+static int svc_rpcb_setup(struct svc_serv *serv)
+{
+ int err;
+
+ err = rpcb_create_local();
+ if (err)
+ return err;
+
+ /* Remove any stale portmap registrations */
+ svc_unregister(serv);
+ return 0;
+}
+
+static void svc_rpcb_cleanup(struct svc_serv *serv)
+{
+ svc_unregister(serv);
+ rpcb_put_local();
+}
/*
* Create an RPC service
^ permalink raw reply related
* [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Stanislav Kinsbursky @ 2011-09-13 18:13 UTC (permalink / raw)
To: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20110913180953.3961.69217.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
This new flag ("setup_rpcbind) will be used to detect, that new service will
send portmapper register calls. For such services we will create rpcbind
clients and remove all stale portmap registrations.
Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
in case of this field wasn't initialized earlier. This will allow to destroy
rpcbind clients when no other users of them left.
Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
---
include/linux/sunrpc/svc.h | 2 ++
net/sunrpc/svc.c | 21 ++++++++++++++-------
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 223588a..528952a 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -402,11 +402,13 @@ struct svc_procedure {
* Function prototypes.
*/
struct svc_serv *svc_create(struct svc_program *, unsigned int,
+ int setup_rpcbind,
void (*shutdown)(struct svc_serv *));
struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
struct svc_pool *pool);
void svc_exit_thread(struct svc_rqst *);
struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
+ int setup_rpcbind,
void (*shutdown)(struct svc_serv *),
svc_thread_fn, struct module *);
int svc_set_num_threads(struct svc_serv *, struct svc_pool *, int);
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index f31e5cc..03231d5 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -378,7 +378,7 @@ static void svc_rpcb_cleanup(struct svc_serv *serv)
*/
static struct svc_serv *
__svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
- void (*shutdown)(struct svc_serv *serv))
+ int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
{
struct svc_serv *serv;
unsigned int vers;
@@ -437,29 +437,36 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
spin_lock_init(&pool->sp_lock);
}
- /* Remove any stale portmap registrations */
- svc_unregister(serv);
+ if (setup_rpcbind) {
+ if (svc_rpcb_setup(serv) < 0) {
+ kfree(serv->sv_pools);
+ kfree(serv);
+ return NULL;
+ }
+ if (!serv->sv_shutdown)
+ serv->sv_shutdown = svc_rpcb_cleanup;
+ }
return serv;
}
struct svc_serv *
svc_create(struct svc_program *prog, unsigned int bufsize,
- void (*shutdown)(struct svc_serv *serv))
+ int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
{
- return __svc_create(prog, bufsize, /*npools*/1, shutdown);
+ return __svc_create(prog, bufsize, /*npools*/1, setup_rpcbind, shutdown);
}
EXPORT_SYMBOL_GPL(svc_create);
struct svc_serv *
svc_create_pooled(struct svc_program *prog, unsigned int bufsize,
- void (*shutdown)(struct svc_serv *serv),
+ int setup_rpcbind, void (*shutdown)(struct svc_serv *serv),
svc_thread_fn func, struct module *mod)
{
struct svc_serv *serv;
unsigned int npools = svc_pool_map_get();
- serv = __svc_create(prog, bufsize, npools, shutdown);
+ serv = __svc_create(prog, bufsize, npools, setup_rpcbind, shutdown);
if (serv != NULL) {
serv->sv_function = func;
--
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 related
* [PATCH v3 06/11] Lockd: force creation of rpcbind clients during service creation
From: Stanislav Kinsbursky @ 2011-09-13 18:14 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110913180953.3961.69217.stgit@localhost6.localdomain6>
Lockd sends requests to portmapper and thus requires rpcbind clients.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/lockd/svc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index abfff9d..bdf79dc 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -269,7 +269,7 @@ int lockd_up(void)
"lockd_up: no pid, %d users??\n", nlmsvc_users);
error = -ENOMEM;
- serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE, NULL);
+ serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE, 1, NULL);
if (!serv) {
printk(KERN_WARNING "lockd_up: create service failed\n");
goto out;
^ permalink raw reply related
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