Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Stanislav Kinsbursky @ 2011-09-19 14:51 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Trond.Myklebust@netapp.com, 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: <20110919100811.0eaa39fe@tlielax.poochiereds.net>

19.09.2011 18:08, Jeff Layton пишет:
> On Tue, 13 Sep 2011 22:13:51 +0400
> Stanislav Kinsbursky<skinsbursky@parallels.com>  wrote:
>
>> 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@parallels.com>
>>
>> ---
>>   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,
> 				^^^
> 			Instead of adding this parameter, why not
> 			base this on the vs_hidden flag in the
> 			svc_version? IOW, have a function that looks at
> 			all the svc_versions for a particular
> 			svc_program, and returns "true" if any of them
> 			have vs_hidden unset? The mechanism you're
> 			proposing here has the potential to be out of
> 			sync with the vs_hidden flag.
>

Could you, please, clarify me this vs_hidden flag?
I understand, that it's used to avoid portmap registration.
But as I see, it's set only for nfs_callback_version1. But this svc_version is a 
part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
Does this flag is missed here? If not, how we can return "true" from your 
proposed function if any of them have vs_hidden unset?

Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we 
will not register any of this program versions with portmapper.
Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only 
nfs_callback_version1. This looks really strange.

I.e. if we use this flag only for passing through this versions during 
svc_(un)register, and we actually also want to pass through 
nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then 
with current patch-set we can move this flag from (vs_hidden) svc_version to 
svc_program and check it during svc_create instead of my home-brew 
"setup_rpcbind" variable.

> 			Also, if you're adding an argument to a
> 			function like this, you you really ought to
> 			change the callers in the same patch. Otherwise
> 			you'll cause a build break if someone tries to
> 			bisect and ends up between the patch that
> 			changes the function and the one that changes
> 			the callers.
>
>>   			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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply

* Re: [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Eric Dumazet @ 2011-09-19 15:02 UTC (permalink / raw)
  To: David Miller
  Cc: tim.c.chen, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
	sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316406528.2521.15.camel@edumazet-laptop>

Le lundi 19 septembre 2011 à 06:28 +0200, Eric Dumazet a écrit :
> Le dimanche 18 septembre 2011 à 21:07 -0400, David Miller a écrit :
> > Eric, please respin your patches against current net-next, thanks!
> 
> Sure, here it is :
> 
> Its a bit different, so I didnt add Tim 'Acked-by'
> 
> [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
> 
> Since commit 7361c36c5224 (af_unix: Allow credentials to work across
> user and pid namespaces) af_unix performance dropped a lot.
> 
> This is because we now take a reference on pid and cred in each write(),
> and release them in read(), usually done from another process,
> eventually from another cpu. This triggers false sharing.

> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
> 
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call.


I appears udevd is such an application.

I am trying testing SOCK_PASSCRED flag and include SCM_CREDENTIALS if
set.

^ permalink raw reply

* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Jeff Layton @ 2011-09-19 15:07 UTC (permalink / raw)
  To: Stanislav Kinsbursky
  Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
	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: <4E7756F3.4080601-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

On Mon, 19 Sep 2011 18:51:31 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:

> 19.09.2011 18:08, Jeff Layton пишет:
> > On Tue, 13 Sep 2011 22:13:51 +0400
> > Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  wrote:
> >
> >> 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,
> > 				^^^
> > 			Instead of adding this parameter, why not
> > 			base this on the vs_hidden flag in the
> > 			svc_version? IOW, have a function that looks at
> > 			all the svc_versions for a particular
> > 			svc_program, and returns "true" if any of them
> > 			have vs_hidden unset? The mechanism you're
> > 			proposing here has the potential to be out of
> > 			sync with the vs_hidden flag.
> >
> 
> Could you, please, clarify me this vs_hidden flag?
> I understand, that it's used to avoid portmap registration.
> But as I see, it's set only for nfs_callback_version1. But this svc_version is a 
> part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
> Does this flag is missed here? If not, how we can return "true" from your 
> proposed function if any of them have vs_hidden unset?
> 
> Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we 
> will not register any of this program versions with portmapper.
> Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only 
> nfs_callback_version1. This looks really strange.
> 
> I.e. if we use this flag only for passing through this versions during 
> svc_(un)register, and we actually also want to pass through 
> nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then 
> with current patch-set we can move this flag from (vs_hidden) svc_version to 
> svc_program and check it during svc_create instead of my home-brew 
> "setup_rpcbind" variable.
> 

Agreed. The current situation is a mess, which is why I suggested a
cleanup and overhaul before you do this...

The vs_hidden flag is intended to show that a particular program
version should not be registered with (or unregistered from) the
portmapper. Unfortunately, nothing looks at vs_hidden during
registration time, only when unregistering (as you mention).

It's quite possible that several svc_versions declared in the kernel do
not have this set correctly. One thing that would be good is to audit
each of those.

We currently rely on SVC_SOCK_ANONYMOUS for registration, but that
wasn't its original intent. It's was just convenient to use it there
too.

SVC_SOCK_ANONYMOUS was (as best I can tell) originally intended for use
on temporary sockets that we establish on receive. So for
instance...when a client connects to nfsd, we need to create a new
socket for nfsd, but obviously we don't want to register that socket
with the portmapper (since nfsd should already be registered there).
SVC_SOCK_ANONYMOUS ensures that that socket is not registered.

The whole scheme could probably use a fundamental re-think. I'm not
sure I have a great idea to propose in lieu of it, but I think adding
yet another flag here is probably not the best way to go.

> > 			Also, if you're adding an argument to a
> > 			function like this, you you really ought to
> > 			change the callers in the same patch. Otherwise
> > 			you'll cause a build break if someone tries to
> > 			bisect and ends up between the patch that
> > 			changes the function and the one that changes
> > 			the callers.
> >
> >>   			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
> >
> >
> 
> 


-- 
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: RFS issue: no HW filter for paused stream
From: Tom Herbert @ 2011-09-19 15:13 UTC (permalink / raw)
  To: Amir Vadai; +Cc: oren, liranl, netdev, amirv, Ben Hutchings
In-Reply-To: <CAP7N4Kes9=VdRV8NHvk03SBg5GbohgdbGqKPABCfYbVyzZ+1ng@mail.gmail.com>

Ben:  Once a accel RFS flow expires (because flow is idle?), how
should it get re-instantiated if thread's CPU doesn't change?

Tom

On Sun, Sep 18, 2011 at 11:05 PM, Amir Vadai <amirv@dev.mellanox.co.il> wrote:
> (Resending in plain text)
>
> Tom Hi,
> When a stream is paused, and its rule is expired while it is paused,
> no new rule will be configured to the HW when traffic resume.
>
> Scenario:
> 1. Start iperf.
> 2. Pause it using Ctrl-Z
> 3. Start another iperf (to make sure first stream rule is expired)
> 4. Stop the second stream.
> 5. Resume first stream. Traffic is not steered to the right rx-queue.
>
> From looking at the code:
> - When first stream started, RSS steered traffic to rx-queue 'x'.
> Because iperf server was running on a different CPU, a new rule was
> added and current-cpu was set to desired-cpu.
> - After paused, rule was expired and removed from HW by net driver.
> But current-cpu wasn't cleared and still is equal to desired-cpu.
> - When stream was resumed, traffic was steered again by RSS, and
> because current-cpu was equal to desired-cpu,  ndo_rx_flow_steer
> wasn't called and no rule was configured to the HW.
>
> Why isn't current-cpu cleared when expiring a rule?
> - Amir
>

^ permalink raw reply

* [PATCH] iproute2: fix changing of ip6ip6 tunnel parameters
From: Jiri Benc @ 2011-09-19 15:14 UTC (permalink / raw)
  To: netdev; +Cc: Stephen Hemminger

When changing ip6ip6 parameters (ip -6 tun change), ip passes zeroed
struct ip6_tnl_parm to the kernel. The kernel then tries to change all of
the tunnel parameters to the passed values, including zeroing of local and
remote address. This fails (-EEXIST in net/ipv6/ip6_tunnel.c:ip6_tnl_ioctl).

For other tunnel types, ip fetches the current parameters first and applies
the required changes on top of them. This patch applies the same code as in
ip/iptunnel.c to ip/ip6tunnel.c.

See http://bugzilla.redhat.com/730627 for the original bug report.

Signed-off-by: Jiri Benc <jbenc@redhat.com>

--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -106,8 +106,9 @@ static void print_tunnel(struct ip6_tnl_
 		printf(" dscp inherit");
 }
 
-static int parse_args(int argc, char **argv, struct ip6_tnl_parm *p)
+static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm *p)
 {
+	int count = 0;
 	char medium[IFNAMSIZ];
 
 	memset(medium, 0, sizeof(medium));
@@ -207,7 +208,15 @@ static int parse_args(int argc, char **a
 			if (p->name[0])
 				duparg2("name", *argv);
 			strncpy(p->name, *argv, IFNAMSIZ - 1);
+			if (cmd == SIOCCHGTUNNEL && count == 0) {
+				struct ip6_tnl_parm old_p;
+				memset(&old_p, 0, sizeof(old_p));
+				if (tnl_get_ioctl(*argv, &old_p))
+					return -1;
+				*p = old_p;
+			}
 		}
+		count++;
 		argc--; argv++;
 	}
 	if (medium[0]) {
@@ -340,7 +349,7 @@ static int do_show(int argc, char **argv
 	ip6_tnl_parm_init(&p, 0);
 	p.proto = 0;  /* default to any */
 
-        if (parse_args(argc, argv, &p) < 0)
+        if (parse_args(argc, argv, SIOCGETTUNNEL, &p) < 0)
                 return -1;
 
 	if (!p.name[0] || show_stats)
@@ -361,7 +370,7 @@ static int do_add(int cmd, int argc, cha
 
 	ip6_tnl_parm_init(&p, 1);
 
-	if (parse_args(argc, argv, &p) < 0)
+	if (parse_args(argc, argv, cmd, &p) < 0)
 		return -1;
 
 	return tnl_add_ioctl(cmd,
@@ -375,7 +384,7 @@ static int do_del(int argc, char **argv)
 
 	ip6_tnl_parm_init(&p, 1);
 
-	if (parse_args(argc, argv, &p) < 0)
+	if (parse_args(argc, argv, SIOCDELTUNNEL, &p) < 0)
 		return -1;
 
 	return tnl_del_ioctl(p.name[0] ? p.name : "ip6tnl0", p.name, &p);

-- 
Jiri Benc

^ permalink raw reply

* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Stanislav Kinsbursky @ 2011-09-19 15:42 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Trond.Myklebust@netapp.com, 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: <20110919110729.33a876ca@tlielax.poochiereds.net>

19.09.2011 19:07, Jeff Layton пишет:
> On Mon, 19 Sep 2011 18:51:31 +0400
> Stanislav Kinsbursky<skinsbursky@parallels.com>  wrote:
>
>> 19.09.2011 18:08, Jeff Layton пишет:
>>> On Tue, 13 Sep 2011 22:13:51 +0400
>>> Stanislav Kinsbursky<skinsbursky@parallels.com>   wrote:
>>>
>>>> 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@parallels.com>
>>>>
>>>> ---
>>>>    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,
>>> 				^^^
>>> 			Instead of adding this parameter, why not
>>> 			base this on the vs_hidden flag in the
>>> 			svc_version? IOW, have a function that looks at
>>> 			all the svc_versions for a particular
>>> 			svc_program, and returns "true" if any of them
>>> 			have vs_hidden unset? The mechanism you're
>>> 			proposing here has the potential to be out of
>>> 			sync with the vs_hidden flag.
>>>
>>
>> Could you, please, clarify me this vs_hidden flag?
>> I understand, that it's used to avoid portmap registration.
>> But as I see, it's set only for nfs_callback_version1. But this svc_version is a
>> part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
>> Does this flag is missed here? If not, how we can return "true" from your
>> proposed function if any of them have vs_hidden unset?
>>
>> Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we
>> will not register any of this program versions with portmapper.
>> Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only
>> nfs_callback_version1. This looks really strange.
>>
>> I.e. if we use this flag only for passing through this versions during
>> svc_(un)register, and we actually also want to pass through
>> nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then
>> with current patch-set we can move this flag from (vs_hidden) svc_version to
>> svc_program and check it during svc_create instead of my home-brew
>> "setup_rpcbind" variable.
>>
>
> Agreed. The current situation is a mess, which is why I suggested a
> cleanup and overhaul before you do this...
>
> The vs_hidden flag is intended to show that a particular program
> version should not be registered with (or unregistered from) the
> portmapper. Unfortunately, nothing looks at vs_hidden during
> registration time, only when unregistering (as you mention).
>
> It's quite possible that several svc_versions declared in the kernel do
> not have this set correctly. One thing that would be good is to audit
> each of those.
>
> We currently rely on SVC_SOCK_ANONYMOUS for registration, but that
> wasn't its original intent. It's was just convenient to use it there
> too.
>
> SVC_SOCK_ANONYMOUS was (as best I can tell) originally intended for use
> on temporary sockets that we establish on receive. So for
> instance...when a client connects to nfsd, we need to create a new
> socket for nfsd, but obviously we don't want to register that socket
> with the portmapper (since nfsd should already be registered there).
> SVC_SOCK_ANONYMOUS ensures that that socket is not registered.
>
> The whole scheme could probably use a fundamental re-think. I'm not
> sure I have a great idea to propose in lieu of it, but I think adding
> yet another flag here is probably not the best way to go.
>

Ok, thank you, Jeff.
It looks like no mentions about portmapper are present in RFC's for NFS versions 
4.* after a brief look.
This SVC_SOCK_ANONYMOUS is understandable and can't be removed with this 
patch-set from my pow.
But now I strongly believe, that we can move this vs_hidden flag from 
svc_version to svc_program structure and set it for both NFSv4.* programs.
Hope, someone else will confirm of refute this statement.




-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply

* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Alexander Duyck @ 2011-09-19 15:48 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <1316279044.14749.179.camel@deadeye>

On 09/17/2011 10:04 AM, Ben Hutchings wrote:
> On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>>
>> This change is meant to make the NAPI budget limits for transmit
>> adjustable.  By doing this it is possible to tune the value for optimal
>> performance with applications such as routing.
> [...]
>> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
>> @@ -1989,6 +1989,9 @@ static int igb_set_coalesce(struct net_device *netdev,
>>   	if ((adapter->flags&  IGB_FLAG_QUEUE_PAIRS)&&  ec->tx_coalesce_usecs)
>>   		return -EINVAL;
>>
>> +	if (ec->tx_max_coalesced_frames_irq)
>> +		adapter->tx_work_limit = ec->tx_max_coalesced_frames_irq;
>> +
> [...]
>
> I don't think it really makes sense to conflate NAPI and interrupt
> moderation parameters.  This really ought to be added to NAPI itself.
>
> (NAPI contexts really ought to be exposed through sysfs somehow.  I
> think we've discussed this before, and it's tricky due to the lack of a
> consistent mapping between those contexts and net devices.)
>
> Ben.

All NAPI does is move things from a hard interrupt to a soft interrupt 
in the case of TX cleanup.  If it wasn't for NAPI we would be calling 
ixgbe_clean_tx_irq directly from the interrupt handler and would still 
be using the same limiting value.  This is why placing it here makes sense.

Thanks,

Alex

^ permalink raw reply

* [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Eric Dumazet @ 2011-09-19 15:52 UTC (permalink / raw)
  To: David Miller
  Cc: tim.c.chen, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
	sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316444524.2539.26.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

Since commit 7361c36c5224 (af_unix: Allow credentials to work across
user and pid namespaces) af_unix performance dropped a lot.

This is because we now take a reference on pid and cred in each write(),
and release them in read(), usually done from another process,
eventually from another cpu. This triggers false sharing.

# Events: 154K cycles
#
# Overhead  Command       Shared Object        Symbol
# ........  .......  ..................  .........................
#
    10.40%  hackbench  [kernel.kallsyms]   [k] put_pid
     8.60%  hackbench  [kernel.kallsyms]   [k] unix_stream_recvmsg
     7.87%  hackbench  [kernel.kallsyms]   [k] unix_stream_sendmsg
     6.11%  hackbench  [kernel.kallsyms]   [k] do_raw_spin_lock
     4.95%  hackbench  [kernel.kallsyms]   [k] unix_scm_to_skb
     4.87%  hackbench  [kernel.kallsyms]   [k] pid_nr_ns
     4.34%  hackbench  [kernel.kallsyms]   [k] cred_to_ucred
     2.39%  hackbench  [kernel.kallsyms]   [k] unix_destruct_scm
     2.24%  hackbench  [kernel.kallsyms]   [k] sub_preempt_count
     1.75%  hackbench  [kernel.kallsyms]   [k] fget_light
     1.51%  hackbench  [kernel.kallsyms]   [k]
__mutex_lock_interruptible_slowpath
     1.42%  hackbench  [kernel.kallsyms]   [k] sock_alloc_send_pskb


This patch includes SCM_CREDENTIALS information in a af_unix message/skb
only if requested by the sender, [man 7 unix for details how to include
ancillary data using sendmsg() system call]

Note: This might break buggy applications that expected SCM_CREDENTIAL
from an unaware write() system call, and receiver not using SO_PASSCRED
socket option.

If SOCK_PASSCRED is set on source or destination socket, we still
include credentials for mere write() syscalls.

Performance boost in hackbench : more than 50% gain on a 16 thread
machine (2 quad-core cpus, 2 threads per core)

hackbench 20 thread 2000

4.228 sec instead of 9.102 sec

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/netlink/af_netlink.c net/unix/af_unix.c|diffstat -p1 -w70
 include/net/scm.h        |    5 ++---
 net/core/scm.c           |   10 ++++++----
 net/netlink/af_netlink.c |    5 ++---
 net/unix/af_unix.c       |   24 +++++++++++++++++++++++--
 4 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/include/net/scm.h b/include/net/scm.h
index 745460f..d456f4c 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -49,7 +49,7 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
 				    struct pid *pid, const struct cred *cred)
 {
 	scm->pid  = get_pid(pid);
-	scm->cred = get_cred(cred);
+	scm->cred = cred ? get_cred(cred) : NULL;
 	cred_to_ucred(pid, cred, &scm->creds);
 }
 
@@ -73,8 +73,7 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
 static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
 			       struct scm_cookie *scm)
 {
-	scm_set_cred(scm, task_tgid(current), current_cred());
-	scm->fp = NULL;
+	memset(scm, 0, sizeof(*scm));
 	unix_get_peersec_dgram(sock, scm);
 	if (msg->msg_controllen <= 0)
 		return 0;
diff --git a/net/core/scm.c b/net/core/scm.c
index 811b53f..ff52ad0 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -173,7 +173,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
 			if (err)
 				goto error;
 
-			if (pid_vnr(p->pid) != p->creds.pid) {
+			if (!p->pid || pid_vnr(p->pid) != p->creds.pid) {
 				struct pid *pid;
 				err = -ESRCH;
 				pid = find_get_pid(p->creds.pid);
@@ -183,8 +183,9 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
 				p->pid = pid;
 			}
 
-			if ((p->cred->euid != p->creds.uid) ||
-				(p->cred->egid != p->creds.gid)) {
+			if (!p->cred ||
+			    (p->cred->euid != p->creds.uid) ||
+			    (p->cred->egid != p->creds.gid)) {
 				struct cred *cred;
 				err = -ENOMEM;
 				cred = prepare_creds();
@@ -193,7 +194,8 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
 
 				cred->uid = cred->euid = p->creds.uid;
 				cred->gid = cred->egid = p->creds.gid;
-				put_cred(p->cred);
+				if (p->cred)
+					put_cred(p->cred);
 				p->cred = cred;
 			}
 			break;
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4330db9..1201b6d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1324,10 +1324,9 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
 	if (msg->msg_flags&MSG_OOB)
 		return -EOPNOTSUPP;
 
-	if (NULL == siocb->scm) {
+	if (NULL == siocb->scm)
 		siocb->scm = &scm;
-		memset(&scm, 0, sizeof(scm));
-	}
+
 	err = scm_send(sock, msg, siocb->scm);
 	if (err < 0)
 		return err;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..466fbcc 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1381,8 +1381,10 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
 static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
 {
 	int err = 0;
+
 	UNIXCB(skb).pid  = get_pid(scm->pid);
-	UNIXCB(skb).cred = get_cred(scm->cred);
+	if (scm->cred)
+		UNIXCB(skb).cred = get_cred(scm->cred);
 	UNIXCB(skb).fp = NULL;
 	if (scm->fp && send_fds)
 		err = unix_attach_fds(scm, skb);
@@ -1392,6 +1394,24 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
 }
 
 /*
+ * Some apps rely on write() giving SCM_CREDENTIALS
+ * We include credentials if source or destination socket
+ * asserted SOCK_PASSCRED.
+ */
+static void maybe_add_creds(struct sk_buff *skb, const struct socket *sock,
+			    const struct sock *other)
+{
+	if (UNIXCB(skb).cred)
+		return;
+	if (test_bit(SOCK_PASSCRED, &sock->flags) ||
+	    !other->sk_socket ||
+	    test_bit(SOCK_PASSCRED, &other->sk_socket->flags)) {
+		UNIXCB(skb).pid  = get_pid(task_tgid(current));
+		UNIXCB(skb).cred = get_current_cred();
+	}
+}
+
+/*
  *	Send AF_UNIX data.
  */
 
@@ -1538,6 +1558,7 @@ restart:
 
 	if (sock_flag(other, SOCK_RCVTSTAMP))
 		__net_timestamp(skb);
+	maybe_add_creds(skb, sock, other);
 	skb_queue_tail(&other->sk_receive_queue, skb);
 	if (max_level > unix_sk(other)->recursion_level)
 		unix_sk(other)->recursion_level = max_level;
@@ -1652,6 +1673,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
 		    (other->sk_shutdown & RCV_SHUTDOWN))
 			goto pipe_err_free;
 
+		maybe_add_creds(skb, sock, other);
 		skb_queue_tail(&other->sk_receive_queue, skb);
 		if (max_level > unix_sk(other)->recursion_level)
 			unix_sk(other)->recursion_level = max_level;

^ permalink raw reply related

* Re: RFS issue: no HW filter for paused stream
From: Ben Hutchings @ 2011-09-19 15:52 UTC (permalink / raw)
  To: Tom Herbert, Amir Vadai; +Cc: oren, liranl, netdev, amirv
In-Reply-To: <CA+mtBx9K8MY+WcFZpQp_85rcf316jrPpNgzqSzgMLzy7TC6eXQ@mail.gmail.com>

On Mon, 2011-09-19 at 08:13 -0700, Tom Herbert wrote:
> Ben:  Once a accel RFS flow expires (because flow is idle?), how
> should it get re-instantiated if thread's CPU doesn't change?

Good question.

> Tom
> 
> On Sun, Sep 18, 2011 at 11:05 PM, Amir Vadai <amirv@dev.mellanox.co.il> wrote:
> > (Resending in plain text)
> >
> > Tom Hi,
> > When a stream is paused, and its rule is expired while it is paused,
> > no new rule will be configured to the HW when traffic resume.
> >
> > Scenario:
> > 1. Start iperf.
> > 2. Pause it using Ctrl-Z
> > 3. Start another iperf (to make sure first stream rule is expired)
> > 4. Stop the second stream.
> > 5. Resume first stream. Traffic is not steered to the right rx-queue.
> >
> > From looking at the code:
> > - When first stream started, RSS steered traffic to rx-queue 'x'.
> > Because iperf server was running on a different CPU, a new rule was
> > added and current-cpu was set to desired-cpu.
> > - After paused, rule was expired and removed from HW by net driver.
> > But current-cpu wasn't cleared and still is equal to desired-cpu.
> > - When stream was resumed, traffic was steered again by RSS, and
> > because current-cpu was equal to desired-cpu,  ndo_rx_flow_steer
> > wasn't called and no rule was configured to the HW.
> >
> > Why isn't current-cpu cleared when expiring a rule?

Because I wrongly assumed that rules could be independently expired by
the driver and the RPS/RFS core code.

Try this (I haven't tested it myself yet):

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 19 Sep 2011 16:44:13 +0100
Subject: [PATCH net-next] RPS: When a hardware filter is expired, ensure it
 can be re-added later

Amir Vadai wrote:
> When a stream is paused, and its rule is expired while it is paused,
> no new rule will be configured to the HW when traffic resume.
[...]
> - When stream was resumed, traffic was steered again by RSS, and
> because current-cpu was equal to desired-cpu,  ndo_rx_flow_steer
> wasn't called and no rule was configured to the HW.
>
> Why isn't current-cpu cleared when expiring a rule?

When rps_may_expire_flow() matches a filter to a flow that is found to
be idle, unset the current CPU for that flow.

Reported-by: Amir Vadai <amirv@dev.mellanox.co.il>
---
 net/core/dev.c |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index b2e262e..3caf65a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2817,11 +2817,22 @@ bool rps_may_expire_flow(struct net_device *dev, u16 rxq_index,
 	if (flow_table && flow_id <= flow_table->mask) {
 		rflow = &flow_table->flows[flow_id];
 		cpu = ACCESS_ONCE(rflow->cpu);
-		if (rflow->filter == filter_id && cpu != RPS_NO_CPU &&
-		    ((int)(per_cpu(softnet_data, cpu).input_queue_head -
-			   rflow->last_qtail) <
-		     (int)(10 * flow_table->mask)))
-			expire = false;
+		if (rflow->filter == filter_id && cpu != RPS_NO_CPU) {
+			if ((int)(per_cpu(softnet_data, cpu).input_queue_head -
+				  rflow->last_qtail) <
+			    (int)(10 * flow_table->mask)) {
+				expire = false;
+			} else {
+				/* If this flow (or a flow with the
+				 * same hash value) becomes active
+				 * on the CPU as before, we want to
+				 * restore the hardware filter.  Unset
+				 * the current CPU to ensure that
+				 * set_rps_cpu() will be called then.
+				 */
+				rflow->cpu = RPS_NO_CPU;
+			}
+		}
 	}
 	rcu_read_unlock();
 	return expire;
-- 
1.7.4.4

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply related

* Re: linux-next: manual merge of the net tree with Linus' tree
From: Joe Perches @ 2011-09-19 15:54 UTC (permalink / raw)
  To: dmitry
  Cc: Stephen Rothwell, David Miller, netdev@vger.kernel.org,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yaniv Rosner, Eilon Greenstein
In-Reply-To: <1316415318.26848.4.camel@lb-tlvb-dmitry>

On Mon, 2011-09-19 at 09:55 +0300, Dmitry Kravkov wrote:
> On Sun, 2011-09-18 at 21:51 -0700, Stephen Rothwell wrote:
> > Today's linux-next merge of the net tree got a conflict in
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c between commit
> > c482e6c06461 ("bnx2x: Fix ETS bandwidth") from Linus' tree and commit
> > 94f05b0f60de ("bnx2x: Coalesce pr_cont uses and fix DP typos") from the
> > net tree.
[]
> Can you use this one instead?
> Contains spell fixes and some formatting.

Hey Dmitry.

The toatl/total spelling fix is good,
but I think this isn't better and is
in fact worse.

> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
> index 8e9b87b..733ace0 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
> @@ -850,32 +850,24 @@ static int bnx2x_ets_e3b0_get_total_bw(
[]
> -			DP(NETIF_MSG_LINK,
> -			   "bnx2x_ets_E3B0_config toatl BW shouldn't be 0\n");
> +			DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config total BW"
> +					   "shouldn't be 0\n");

Multiple line format strings lines are bad style and error prone.
You introduce broken spacing after string coalescing.

> -		DP(NETIF_MSG_LINK,
> -		   "bnx2x_ets_E3B0_config toatl BW should be 100\n");
> -		/**
> -		*   We can handle a case whre the BW isn't 100 this can happen
> -		*   if the TC are joined.
> -		*/
> +		DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config total BW should be"
> +				   "100\n");

Here too.

^ permalink raw reply

* Re: linux-next: manual merge of the net tree with Linus' tree
From: Dmitry Kravkov @ 2011-09-19 16:04 UTC (permalink / raw)
  To: Joe Perches
  Cc: Stephen Rothwell, David Miller, netdev@vger.kernel.org,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yaniv Rosner, Eilon Greenstein
In-Reply-To: <1316447682.6276.5.camel@Joe-Laptop>

On Mon, 2011-09-19 at 08:54 -0700, Joe Perches wrote:
> On Mon, 2011-09-19 at 09:55 +0300, Dmitry Kravkov wrote:
> > On Sun, 2011-09-18 at 21:51 -0700, Stephen Rothwell wrote:
> > > Today's linux-next merge of the net tree got a conflict in
> > > drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c between commit
> > > c482e6c06461 ("bnx2x: Fix ETS bandwidth") from Linus' tree and commit
> > > 94f05b0f60de ("bnx2x: Coalesce pr_cont uses and fix DP typos") from the
> > > net tree.
> []
> > Can you use this one instead?
> > Contains spell fixes and some formatting.
> 
> Multiple line format strings lines are bad style and error prone.
> You introduce broken spacing after string coalescing.
> 

Contains spell fixes and some formatting

v2: fix broken spacing

Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
---
Joe, Thanks for noticing that
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c |   30 ++++++++--------------
 1 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 8e9b87b..5a9444a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -850,32 +850,24 @@ static int bnx2x_ets_e3b0_get_total_bw(
 
 	*total_bw = 0 ;
 	/* Calculate total BW requested */
-	for (cos_idx = 0; cos_idx < ets_params->num_of_cos; cos_idx++) {
-		if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state) {
+	for (cos_idx = 0; cos_idx < ets_params->num_of_cos; cos_idx++)
+		if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state)
+			*total_bw +=
+				ets_params->cos[cos_idx].params.bw_params.bw;
 
-			if (0 == ets_params->cos[cos_idx].params.bw_params.bw) {
-				DP(NETIF_MSG_LINK,
-				   "bnx2x_ets_E3B0_config BW was set to 0\n");
-			return -EINVAL;
-		}
-		*total_bw +=
-		    ets_params->cos[cos_idx].params.bw_params.bw;
-	    }
-	}
-
-	/*Check taotl BW is valid */
+	/* Check total BW is valid */
 	if ((100 != *total_bw) || (0 == *total_bw)) {
 		if (0 == *total_bw) {
 			DP(NETIF_MSG_LINK,
-			   "bnx2x_ets_E3B0_config toatl BW shouldn't be 0\n");
+			  "bnx2x_ets_E3B0_config total BW shouldn't be 0\n");
 			return -EINVAL;
 		}
 		DP(NETIF_MSG_LINK,
-		   "bnx2x_ets_E3B0_config toatl BW should be 100\n");
-		/**
-		*   We can handle a case whre the BW isn't 100 this can happen
-		*   if the TC are joined.
-		*/
+		   "bnx2x_ets_E3B0_config total BW should be 100\n");
+		/*
+		 * We can handle a case where the BW isn't 100 this can happen
+		 * if the TC are joined.
+		 */
 	}
 	return 0;
 }
-- 
1.7.2.2

^ permalink raw reply related

* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Ben Hutchings @ 2011-09-19 16:05 UTC (permalink / raw)
  To: Alexander Duyck; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <4E776441.9090602@intel.com>

On Mon, 2011-09-19 at 08:48 -0700, Alexander Duyck wrote:
> On 09/17/2011 10:04 AM, Ben Hutchings wrote:
> > On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
> >> From: Alexander Duyck<alexander.h.duyck@intel.com>
> >>
> >> This change is meant to make the NAPI budget limits for transmit
> >> adjustable.  By doing this it is possible to tune the value for optimal
> >> performance with applications such as routing.
> > [...]
> >> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> >> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> >> @@ -1989,6 +1989,9 @@ static int igb_set_coalesce(struct net_device *netdev,
> >>   	if ((adapter->flags&  IGB_FLAG_QUEUE_PAIRS)&&  ec->tx_coalesce_usecs)
> >>   		return -EINVAL;
> >>
> >> +	if (ec->tx_max_coalesced_frames_irq)
> >> +		adapter->tx_work_limit = ec->tx_max_coalesced_frames_irq;
> >> +
> > [...]
> >
> > I don't think it really makes sense to conflate NAPI and interrupt
> > moderation parameters.  This really ought to be added to NAPI itself.
> >
> > (NAPI contexts really ought to be exposed through sysfs somehow.  I
> > think we've discussed this before, and it's tricky due to the lack of a
> > consistent mapping between those contexts and net devices.)
> >
> > Ben.
> 
> All NAPI does is move things from a hard interrupt to a soft interrupt 
> in the case of TX cleanup.  If it wasn't for NAPI we would be calling 
> ixgbe_clean_tx_irq directly from the interrupt handler and would still 
> be using the same limiting value.  This is why placing it here makes sense.

But tx_max_coalesced_frames_irq is not supposed to be a work limit (and
such a work limit doesn't seem useful in the absence of NAPI).  As I
understand it, it is supposed to be an alternate moderation value for
the hardware to use if a frame is sent while the IRQ handler is running.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* [PATCH net-next] ip6_tunnel: add optional fwmark inherit
From: Eric Dumazet @ 2011-09-19 16:27 UTC (permalink / raw)
  To: Hans Schillström; +Cc: netdev@vger.kernel.org, Anders Franzen
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D903109@ESESSCMS0356.eemea.ericsson.se>

Le lundi 19 septembre 2011 à 10:47 +0200, Hans Schillström a écrit :
> Hello Eric,
> For a year ago you send an untested patch to Anders Franzen 
> I think the subject was "not possible to do policy routing for next hop on tunnels."
> 
> The patch have been used since that and it works perfectly,
> I made some minor changes to reflect the flowi changes.
> 
> Would it be possible for you to submit that patch, since (I guess) you are the author 
> I can prepare it if you want.
> The included patch is for  linux-3.0.4

Here is an official patch submisssion, for net-next :

Its slightly different than linux-3.0 kernel because of recent changes
on ip6_tunnel.c file.

[PATCH net-next] ip6_tunnel: add optional fwmark inherit

Add IP6_TNL_F_USE_ORIG_FWMARK to ip6_tunnel, so that ip6_tnl_xmit2()
makes a route lookup taking into account skb->fwmark and doesnt cache
lookup result.

This permits more flexibility in policies and firewall setups.

To setup such a tunnel, "fwmark inherit" option should be added to "ip
-f inet6 tunnel" command.

Reported-by: Anders Franzen <Anders.Franzen@ericsson.com>
CC: Hans Schillström <hans.schillstrom@ericsson.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 include/linux/ip6_tunnel.h |    2 ++
 net/ipv6/ip6_tunnel.c      |   23 +++++++++++++++++-------
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/include/linux/ip6_tunnel.h b/include/linux/ip6_tunnel.h
index acb9ad6..bf22b03 100644
--- a/include/linux/ip6_tunnel.h
+++ b/include/linux/ip6_tunnel.h
@@ -16,6 +16,8 @@
 #define IP6_TNL_F_MIP6_DEV 0x8
 /* copy DSCP from the outer packet */
 #define IP6_TNL_F_RCV_DSCP_COPY 0x10
+/* copy fwmark from inner packet */
+#define IP6_TNL_F_USE_ORIG_FWMARK 0x20
 
 struct ip6_tnl_parm {
 	char name[IFNAMSIZ];	/* name of tunnel device */
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 694d70a..bdc15c9 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -889,7 +889,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
 	struct net_device_stats *stats = &t->dev->stats;
 	struct ipv6hdr *ipv6h = ipv6_hdr(skb);
 	struct ipv6_tel_txoption opt;
-	struct dst_entry *dst, *ndst = NULL;
+	struct dst_entry *dst = NULL, *ndst = NULL;
 	struct net_device *tdev;
 	int mtu;
 	unsigned int max_headroom = sizeof(struct ipv6hdr);
@@ -897,7 +897,8 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
 	int err = -1;
 	int pkt_len;
 
-	dst = ip6_tnl_dst_check(t);
+	if (!fl6->flowi6_mark)
+		dst = ip6_tnl_dst_check(t);
 	if (!dst) {
 		ndst = ip6_route_output(net, NULL, fl6);
 
@@ -955,8 +956,12 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
 		skb = new_skb;
 	}
 	skb_dst_drop(skb);
-	skb_dst_set_noref(skb, dst);
-
+	if (fl6->flowi6_mark) {
+		skb_dst_set(skb, dst);
+		ndst = NULL;
+	} else {
+		skb_dst_set_noref(skb, dst);
+	}
 	skb->transport_header = skb->network_header;
 
 	proto = fl6->flowi6_proto;
@@ -1021,9 +1026,11 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	dsfield = ipv4_get_dsfield(iph);
 
-	if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS))
+	if (t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS)
 		fl6.flowlabel |= htonl((__u32)iph->tos << IPV6_TCLASS_SHIFT)
 					  & IPV6_TCLASS_MASK;
+	if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK)
+		fl6.flowi6_mark = skb->mark;
 
 	err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
 	if (err != 0) {
@@ -1070,10 +1077,12 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
 	fl6.flowi6_proto = IPPROTO_IPV6;
 
 	dsfield = ipv6_get_dsfield(ipv6h);
-	if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS))
+	if (t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS)
 		fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_TCLASS_MASK);
-	if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL))
+	if (t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL)
 		fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_FLOWLABEL_MASK);
+	if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK)
+		fl6.flowi6_mark = skb->mark;
 
 	err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
 	if (err != 0) {

^ permalink raw reply related

* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Alexander Duyck @ 2011-09-19 16:32 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <1316448352.2764.27.camel@bwh-desktop>

On 09/19/2011 09:05 AM, Ben Hutchings wrote:
> On Mon, 2011-09-19 at 08:48 -0700, Alexander Duyck wrote:
>> On 09/17/2011 10:04 AM, Ben Hutchings wrote:
>>> On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
>>>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>>>>
>>>> This change is meant to make the NAPI budget limits for transmit
>>>> adjustable.  By doing this it is possible to tune the value for optimal
>>>> performance with applications such as routing.
>>> [...]
>>>> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>>> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
>>>> @@ -1989,6 +1989,9 @@ static int igb_set_coalesce(struct net_device *netdev,
>>>>    	if ((adapter->flags&   IGB_FLAG_QUEUE_PAIRS)&&   ec->tx_coalesce_usecs)
>>>>    		return -EINVAL;
>>>>
>>>> +	if (ec->tx_max_coalesced_frames_irq)
>>>> +		adapter->tx_work_limit = ec->tx_max_coalesced_frames_irq;
>>>> +
>>> [...]
>>>
>>> I don't think it really makes sense to conflate NAPI and interrupt
>>> moderation parameters.  This really ought to be added to NAPI itself.
>>>
>>> (NAPI contexts really ought to be exposed through sysfs somehow.  I
>>> think we've discussed this before, and it's tricky due to the lack of a
>>> consistent mapping between those contexts and net devices.)
>>>
>>> Ben.
>> All NAPI does is move things from a hard interrupt to a soft interrupt
>> in the case of TX cleanup.  If it wasn't for NAPI we would be calling
>> ixgbe_clean_tx_irq directly from the interrupt handler and would still
>> be using the same limiting value.  This is why placing it here makes sense.
> But tx_max_coalesced_frames_irq is not supposed to be a work limit (and
> such a work limit doesn't seem useful in the absence of NAPI).  As I
> understand it, it is supposed to be an alternate moderation value for
> the hardware to use if a frame is sent while the IRQ handler is running.
>
> Ben.
The fact is ixgbe has been using this parameter this way for over 2 
years now and the main goal of this patch was just to synchronize how 
things work on igb and ixgbe.

Our hardware doesn't have a mechanism for firing an interrupt after X 
number of frames so instead we simply have modified things so that we 
will only process X number of frames and then fire another 
interrupt/poll if needed.  As such we aren't that far out of compliance 
with the meaning of how this parameter is supposed to be used.

Thanks,

Alex

^ permalink raw reply

* Re: [PATCH ] dynamic_debug: call __netdev_printk only for CONFIG_NET
From: Randy Dunlap @ 2011-09-19 16:49 UTC (permalink / raw)
  To: Jason Baron
  Cc: Greg KH, Arnd Bergmann, gregkh, joe, jim.cromie, bvanassche,
	linux-kernel, davem, aloisio.almeida, netdev, akpm
In-Reply-To: <20110919134814.GA2658@redhat.com>

On 09/19/2011 06:48 AM, Jason Baron wrote:
> On Sun, Sep 18, 2011 at 01:27:36AM -0700, Greg KH wrote:
>> On Thu, Sep 01, 2011 at 11:18:18AM -0400, Jason Baron wrote:
>>> On Thu, Sep 01, 2011 at 04:57:02PM +0200, Arnd Bergmann wrote:
>>>> __netdev_printk is only defined when CONFIG_NET is set. Since we only need
>>>> __dynamic_netdev_dbg for network drivers, we can make it conditional on the
>>>> same Kconfig symbol.
>>>>
>>>
>>> Hi,
>>>
>>> Yes, I've posted a fix for this:
>>>
>>> https://lkml.org/lkml/2011/8/30/297
>>>
>>> Hopefully, it will be pulled in soon.
>>
>> As that thread again spun off into confusion, can you please resend the
>> end result?
>>
>> thanks,
>>
>> greg k-h
> 
> Hi,
> 
> Andrew Morton has pulled these into his -mm tree...so I think the series
> should be all set.

Good.  The build fix is still needed in today's linux-next (20110919).


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply

* Your Email Id has won
From: Coca'Cola Inc @ 2011-09-19 16:47 UTC (permalink / raw)


Your Email Id has won 1,000,000.00GBP in the COCA'COLA PROMO 2011 send your
Names.
Address.
Sex.
Age.
Tel.
*City/State:
Country.

Email: ccpdept_2011@msn.com

^ permalink raw reply

* RE: URGENT WITH DETAILS
From: DR. ABEL GREG @ 2011-09-19 16:06 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 37 bytes --]

READ CAREFULLY THE ATTACHED FILE....

[-- Attachment #2: UNITED NATION.txt --]
[-- Type: application/octet-stream, Size: 3100 bytes --]

United Nation Fraud and Money Laundering Oversight Dept 
Investigation/ Monitoring/ Resolve and Consult Unit 
  
Attn: Beneficiary, 

I am Abel Greg (Fsc, Mni) United Nation representative for African Economic Crimes, Scam and Money Laundering. 
  
I write to address you on the account of petitions addressed to the United Nation Security Council by both the government of United State of America, France, Britain re-enacting an expose to the colossal magnitude of scam, deceit and money laundering cartel ring prevalent with countries such as Gambia, Nigeria, Ghana, Benin Republic, England, Spain and United State of America. It was on account of this that United Nation deployed its African Commission on Economic Crimes to wade into this ugly trend. 
  
Our Investigation revealed that this scam has been for a very long time but assumed global dimension in the last fifteen years. In response to these petitions to the UN, we have been engaged with the Nigeria government in the last five months, discussing the implication of this ugly payment scam in Nigeria. The high powered delegation from the UN has achieved remarkable progress in our discussion with the Federal government of Nigeria. 
  
We are first in Nigeria because our investigation revealed that this payment scam fraud originated from Nigeria. Need not be reminded that this same scam issue formed the fulcon of the discussion between President Goodluck Jonathan of Nigeria and his United State counterpart Barrack Obama during the visit of the former between April and June 2010 as President Jonathan visited twice. He openly asked the American government to assist Nigeria in calming this ugly vice. 
  
In the last five months our team have worked assiduously with the cooperation of the Nigeria government to reach a compromise considering that this well documented payment claim scam is a systemic method through which the highly placed Nigeria officials use in fleeing money using their proxies to make contact to you.  In our candid resolution with the government of the Federal Republic of Nigeria, it was well noted that most of the victims spent enormous amount of money in this scam, therefore should be adequately compensated. Presently we have started the payment of the compensation for victims as agreed between the UN and the government of Nigeria. This commission is paying out the sum of $5.2M to all the victimized beneficiaries.
  
But this payment will be release to you via an ATM Visa Card which has to go through American Bankers Association Banking Network registration that will enable you access the Visa Card in your country. This registration has to be done before the Visa Card will be dispatch to your address. Contact this office with the bellow particulars urgently.

1). Your Names....... 
2). Your Address.....
3). Your Direct Phone Number for accurate vetting. 
4). Your ID Card / Occupation


Contact us immediately. 

Dr. Abel Greg (Fsc, Mni) 
United Nation representative 
African Economic Crimes, Scam and Money Laundering 
Email: unitednationsrep@live.com  

^ permalink raw reply

* Re: [PATCH] tcp: fix validation of D-SACK
From: Jan Ceuleers @ 2011-09-19 17:29 UTC (permalink / raw)
  To: David Miller; +Cc: zheng.z.yan, netdev, eric.dumazet
In-Reply-To: <20110918.223744.2195272571175354579.davem@davemloft.net>

On 09/19/2011 04:37 AM, David Miller wrote:
>> D-SACK is allowed to reside below snd_una. But the corresponding check
>> in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.
>>
>> Signed-off-by: Zheng Yan<zheng.z.yan@intel.com>
>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
> Applied, thanks.

Dave,

Have you also queued it up for stable as per Eric's remark that this was 
introduced in 2.6.24?

Sorry if this is implied in your workflow.

Thanks, Jan

^ permalink raw reply

* Mutual Benefit
From: Ma Guang Lu @ 2011-09-19 17:09 UTC (permalink / raw)


I am Ma Guang Lu,I have a business of $17.3M for you.Reply with personal
details for info.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

^ permalink raw reply

* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Jeff Layton @ 2011-09-19 18:11 UTC (permalink / raw)
  To: Stanislav Kinsbursky
  Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
	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: <4E7762D4.7090404-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

On Mon, 19 Sep 2011 19:42:12 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:

> 19.09.2011 19:07, Jeff Layton пишет:
> > On Mon, 19 Sep 2011 18:51:31 +0400
> > Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  wrote:
> >
> >> 19.09.2011 18:08, Jeff Layton пишет:
> >>> On Tue, 13 Sep 2011 22:13:51 +0400
> >>> Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>   wrote:
> >>>
> >>>> 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,
> >>> 				^^^
> >>> 			Instead of adding this parameter, why not
> >>> 			base this on the vs_hidden flag in the
> >>> 			svc_version? IOW, have a function that looks at
> >>> 			all the svc_versions for a particular
> >>> 			svc_program, and returns "true" if any of them
> >>> 			have vs_hidden unset? The mechanism you're
> >>> 			proposing here has the potential to be out of
> >>> 			sync with the vs_hidden flag.
> >>>
> >>
> >> Could you, please, clarify me this vs_hidden flag?
> >> I understand, that it's used to avoid portmap registration.
> >> But as I see, it's set only for nfs_callback_version1. But this svc_version is a
> >> part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
> >> Does this flag is missed here? If not, how we can return "true" from your
> >> proposed function if any of them have vs_hidden unset?
> >>
> >> Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we
> >> will not register any of this program versions with portmapper.
> >> Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only
> >> nfs_callback_version1. This looks really strange.
> >>
> >> I.e. if we use this flag only for passing through this versions during
> >> svc_(un)register, and we actually also want to pass through
> >> nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then
> >> with current patch-set we can move this flag from (vs_hidden) svc_version to
> >> svc_program and check it during svc_create instead of my home-brew
> >> "setup_rpcbind" variable.
> >>
> >
> > Agreed. The current situation is a mess, which is why I suggested a
> > cleanup and overhaul before you do this...
> >
> > The vs_hidden flag is intended to show that a particular program
> > version should not be registered with (or unregistered from) the
> > portmapper. Unfortunately, nothing looks at vs_hidden during
> > registration time, only when unregistering (as you mention).
> >
> > It's quite possible that several svc_versions declared in the kernel do
> > not have this set correctly. One thing that would be good is to audit
> > each of those.
> >
> > We currently rely on SVC_SOCK_ANONYMOUS for registration, but that
> > wasn't its original intent. It's was just convenient to use it there
> > too.
> >
> > SVC_SOCK_ANONYMOUS was (as best I can tell) originally intended for use
> > on temporary sockets that we establish on receive. So for
> > instance...when a client connects to nfsd, we need to create a new
> > socket for nfsd, but obviously we don't want to register that socket
> > with the portmapper (since nfsd should already be registered there).
> > SVC_SOCK_ANONYMOUS ensures that that socket is not registered.
> >
> > The whole scheme could probably use a fundamental re-think. I'm not
> > sure I have a great idea to propose in lieu of it, but I think adding
> > yet another flag here is probably not the best way to go.
> >
> 
> Ok, thank you, Jeff.
> It looks like no mentions about portmapper are present in RFC's for NFS versions 
> 4.* after a brief look.
> This SVC_SOCK_ANONYMOUS is understandable and can't be removed with this 
> patch-set from my pow.
> But now I strongly believe, that we can move this vs_hidden flag from 
> svc_version to svc_program structure and set it for both NFSv4.* programs.
> Hope, someone else will confirm of refute this statement.
> 

The problem is nfsd. In principle, there's no real reason we have to
register NFSv4 with the portmapper at all. One could envision a
setup where a v4-only server doesn't need to run rpcbind at all. Making
it per-program may hamstring you from doing that later.

It think it would be a good thing to keep it per-version, and it's
trivial to write a routine to do what I've described. svc_creates only
happen rarely.

Just walk the pg_vers array for the program and look at each vs_hidden
value. Return true when you hit one that has vs_hidden unset. Return
false if none do. Then use that return value to replace your new flag
in this patch.

-- 
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

* GET BACK TO ME
From: Ma Guang Lu @ 2011-09-19 17:14 UTC (permalink / raw)


I am Ma Guang Lu,I have a business of $17.3M for you.Reply with personal
details for info.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

^ permalink raw reply

* [PATCH net-next 1/2] netxen: Fix vhdr_len in case of non vlan packets.
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko
In-Reply-To: <1316458192-8691-1-git-send-email-rajesh.borundia@qlogic.com>

o Set vlan header length to zero.

Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
 .../net/ethernet/qlogic/netxen/netxen_nic_init.c   |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index d6c6357..a8259cc 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1620,7 +1620,7 @@ netxen_process_lro(struct netxen_adapter *adapter,
 	int index;
 	u16 lro_length, length, data_offset;
 	u32 seq_number;
-	u8 vhdr_len;
+	u8 vhdr_len = 0;
 
 	if (unlikely(ring > adapter->max_rds_rings))
 		return NULL;
-- 
1.6.3.3

^ permalink raw reply related

* [PATCH net-next 2/2] netxen: Add pcie workaround
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko
In-Reply-To: <1316458192-8691-1-git-send-email-rajesh.borundia@qlogic.com>

o A performance drop was seen with firmware loaded
from flash. This workaround fixes it.
o Updated driver version to 4.0.77

Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic.h    |    4 +-
 .../net/ethernet/qlogic/netxen/netxen_nic_main.c   |   63 +++++++++++++++++++-
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
index 196b660..a876dff 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
@@ -53,8 +53,8 @@
 
 #define _NETXEN_NIC_LINUX_MAJOR 4
 #define _NETXEN_NIC_LINUX_MINOR 0
-#define _NETXEN_NIC_LINUX_SUBVERSION 76
-#define NETXEN_NIC_LINUX_VERSIONID  "4.0.76"
+#define _NETXEN_NIC_LINUX_SUBVERSION 77
+#define NETXEN_NIC_LINUX_VERSIONID  "4.0.77"
 
 #define NETXEN_VERSION_CODE(a, b, c)	(((a) << 24) + ((b) << 16) + (c))
 #define _major(v)	(((v) >> 24) & 0xff)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index de18e47..82626d6 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -400,6 +400,63 @@ static void netxen_set_port_mode(struct netxen_adapter *adapter)
 	}
 }
 
+#define PCI_CAP_ID_GEN  0x10
+
+static void netxen_pcie_strap_init(struct netxen_adapter *adapter)
+{
+	u32 pdevfuncsave;
+	u32 c8c9value = 0;
+	u32 chicken = 0;
+	u32 control = 0;
+	int i, pos;
+	struct pci_dev *pdev;
+
+	pdev = adapter->pdev;
+
+	chicken = NXRD32(adapter, NETXEN_PCIE_REG(PCIE_CHICKEN3));
+	/* clear chicken3.25:24 */
+	chicken &= 0xFCFFFFFF;
+	/*
+	 * if gen1 and B0, set F1020 - if gen 2, do nothing
+	 * if gen2 set to F1000
+	 */
+	pos = pci_find_capability(pdev, PCI_CAP_ID_GEN);
+	if (pos == 0xC0) {
+		pci_read_config_dword(pdev, pos + 0x10, &control);
+		if ((control & 0x000F0000) != 0x00020000) {
+			/*  set chicken3.24 if gen1 */
+			chicken |= 0x01000000;
+		}
+		dev_info(&adapter->pdev->dev, "Gen2 strapping detected\n");
+		c8c9value = 0xF1000;
+	} else {
+		/* set chicken3.24 if gen1 */
+		chicken |= 0x01000000;
+		dev_info(&adapter->pdev->dev, "Gen1 strapping detected\n");
+		if (adapter->ahw.revision_id == NX_P3_B0)
+			c8c9value = 0xF1020;
+		else
+			c8c9value = 0;
+	}
+
+	NXWR32(adapter, NETXEN_PCIE_REG(PCIE_CHICKEN3), chicken);
+
+	if (!c8c9value)
+		return;
+
+	pdevfuncsave = pdev->devfn;
+	if (pdevfuncsave & 0x07)
+		return;
+
+	for (i = 0; i < 8; i++) {
+		pci_read_config_dword(pdev, pos + 8, &control);
+		pci_read_config_dword(pdev, pos + 8, &control);
+		pci_write_config_dword(pdev, pos + 8, c8c9value);
+		pdev->devfn++;
+	}
+	pdev->devfn = pdevfuncsave;
+}
+
 static void netxen_set_msix_bit(struct pci_dev *pdev, int enable)
 {
 	u32 control;
@@ -867,7 +924,7 @@ netxen_start_firmware(struct netxen_adapter *adapter)
 	if (err < 0)
 		goto err_out;
 	if (err == 0)
-		goto wait_init;
+		goto pcie_strap_init;
 
 	if (first_boot != 0x55555555) {
 		NXWR32(adapter, CRB_CMDPEG_STATE, 0);
@@ -910,6 +967,10 @@ netxen_start_firmware(struct netxen_adapter *adapter)
 		| (_NETXEN_NIC_LINUX_SUBVERSION);
 	NXWR32(adapter, CRB_DRIVER_VERSION, val);
 
+pcie_strap_init:
+	if (NX_IS_REVISION_P3(adapter->ahw.revision_id))
+		netxen_pcie_strap_init(adapter);
+
 wait_init:
 	/* Handshake with the card before we register the devices. */
 	err = netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
-- 
1.6.3.3

^ permalink raw reply related

* [PATCH 0/2] netxen: Fixes
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko

Please Apply it to net-next tree.

Thanks
Rajesh

^ permalink raw reply

* [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-19 19:12 UTC (permalink / raw)
  To: Maciej Żenczykowski, David S. Miller
  Cc: netdev, Maciej Żenczykowski, MuraliRaja Muniraju

From: Maciej Żenczykowski <maze@google.com>

skb's should be freed once neigh->lock is no longer held.

Google-Bug-Id: 4561441
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: MuraliRaja Muniraju <muralira@google.com>
---
 net/core/neighbour.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 4002261..53d034a 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -949,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
 {
 	int rc;
 	bool immediate_probe = false;
+	struct sk_buff *buff_to_free = NULL;
 
 	write_lock_bh(&neigh->lock);
 
@@ -969,10 +970,10 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
 		} else {
 			neigh->nud_state = NUD_FAILED;
 			neigh->updated = jiffies;
-			write_unlock_bh(&neigh->lock);
 
-			kfree_skb(skb);
-			return 1;
+			buff_to_free = skb;
+			rc = 1;
+			goto out_unlock_bh;
 		}
 	} else if (neigh->nud_state & NUD_STALE) {
 		NEIGH_PRINTK2("neigh %p is delayed.\n", neigh);
@@ -986,9 +987,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
 		if (skb) {
 			if (skb_queue_len(&neigh->arp_queue) >=
 			    neigh->parms->queue_len) {
-				struct sk_buff *buff;
-				buff = __skb_dequeue(&neigh->arp_queue);
-				kfree_skb(buff);
+				buff_to_free = __skb_dequeue(&neigh->arp_queue);
 				NEIGH_CACHE_STAT_INC(neigh->tbl, unres_discards);
 			}
 			skb_dst_force(skb);
@@ -1002,6 +1001,7 @@ out_unlock_bh:
 	else
 		write_unlock(&neigh->lock);
 	local_bh_enable();
+	kfree_skb(buff_to_free);
 	return rc;
 }
 EXPORT_SYMBOL(__neigh_event_send);
-- 
1.7.3.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox