* Re[3]: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Naoto MATSUMOTO @ 2012-08-15 9:10 UTC (permalink / raw)
To: Eric W. Biederman, Ali Ayoub, David Miller, ogerlitz, roland,
netdev, sean.hefty, erezsh, dledford
Cc: Naoto MATSUMOTO
In-Reply-To: <20120807102129.5C95.C42C3789@sakura.ad.jp>
Hi All.
Our lab's additional infomation(result) for all.
Ethernet over L2TPv3 over IPoIB Pseudo-wire Multiplexing (RFC4719)
using "ip l2tp" command on linux. http://twitpic.com/ajn2nx
On Tue, 07 Aug 2012 10:21:33 +0900
Naoto MATSUMOTO <n-matsumoto@sakura.ad.jp> wrote:
> -----------------------------------------------------------------------
> Ethernet over EoIB using gretap with "Raid STP" performance result.
> http://twitpic.com/agd1pp
>
> How to use EoIB with gretap.
> http://twitpic.com/agd4io
regards,
--
SAKURA Internet Inc. / Senior Researcher
Naoto MATSUMOTO <n-matsumoto@sakura.ad.jp>
SAKURA Research Center <http://research.sakura.ad.jp/>
^ permalink raw reply
* CONGRATULATIONS! YAHOO ANNIVERSARY AWARD NOTIFICATION NEWS 2012
From: YAHOO ANNIVERSARY AWARD NOTIFICATION NEWS 2012 @ 2012-08-15 8:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: YAHOO ANNIVERSARY AWARD NOTIFICATION NEWS 2012.doc --]
[-- Type: application/msword, Size: 305664 bytes --]
^ permalink raw reply
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: David Laight @ 2012-08-15 8:46 UTC (permalink / raw)
To: Eric W. Biederman, Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <87obmchmpu.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Yes hash_32 seems reasonable for the uid hash. With those long hash
> chains I wouldn't like to be on a machine with 10,000 processes with
> each with a different uid, and a processes calling setuid in the fast
> path.
>
> The uid hash that we are playing with is one that I sort of wish that
> the hash table could grow in size, so that we could scale up better.
Since uids are likely to be allocated in dense blocks, maybe an
unhashed multi-level lookup scheme might be appropriate.
Index an array with the low 8 (say) bits of the uid.
Each item can be either:
1) NULL => free entry.
2) a pointer to a uid structure (check uid value).
3) a pointer to an array to index with the next 8 bits.
(2) and (3) can be differentiated by the low address bit.
I think that is updateable with cmpxchg.
Clearly this is a bad algorithm if uids are all multiples of 2^24
but that is true or any hash function.
David
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: clarify SOB tag usage when evolving submissions
From: Dan Carpenter @ 2012-08-15 8:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: torvalds, rdunlap, tytso, alan, davem, netdev, linux-kernel
In-Reply-To: <1344545493-6820-1-git-send-email-mcgrof@do-not-panic.com>
I think it would be nice to have another tag for people who fix bugs
in the original patch. The Reviewed-by tag implies approval of the
whole patch and anyway reviewers don't normally comment unless they
see a bug. Maybe something like:
Contributor: Your Name <email@address.com>
So the tags for developers would be:
Signed-off-by: The patch went through you. Legal responsibility.
Acked-by: You know what you are talking about and approve.
Reviewed-by: You reviewed the patch and approve.
Contributor: You noticed or fixed a bug in the patch.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 15/21] net sched: Pass the skb into change so it can access NETLINK_CB
From: Jamal Hadi Salim @ 2012-08-15 8:11 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1344889115-21610-15-git-send-email-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Mon, 2012-08-13 at 13:18 -0700, Eric W. Biederman wrote:
> From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>
> cls_flow.c plays with uids and gids. Unless I misread that
> code it is possible for classifiers to depend on the specific uid and
> gid values. Therefore I need to know the user namespace of the
> netlink socket that is installing the packet classifiers. Pass
> in the rtnetlink skb so I can access the NETLINK_CB of the passed
> packet. In particular I want access to sk_user_ns(NETLINK_CB(in_skb).ssk).
>
> Pass in not the user namespace but the incomming rtnetlink skb into
> the the classifier change routines as that is generally the more useful
> parameter.
>
> Cc: Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
> Acked-by: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Acked-by: Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 0/3] qmi_wwan: simplify device matching and add a few new devices
From: Bjørn Mork @ 2012-08-15 8:08 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120814.144653.606253082821782776.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> Ok I changed my mind and applied this to 'net'.
Thanks.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] SubmittingPatches: clarify SOB tag usage when evolving submissions
From: Luis R. Rodriguez @ 2012-08-15 7:52 UTC (permalink / raw)
To: Rob Landley
Cc: Randy Dunlap, torvalds, tytso, alan, davem, netdev, linux-kernel
In-Reply-To: <50284101.4020905@landley.net>
On Sun, Aug 12, 2012 at 4:49 PM, Rob Landley <rob@landley.net> wrote:
> The analogy I made was with a magazine editor, fighting off sturgeon's
> law in the slush pile, cherry-picking a few submissions to polish up and
> include in the next issue of the magazine. In this context, a
> personalized rejection letter to a new author is actually encouragement,
> and the editor's only authority is veto power with bounceback
> negotiation. "I won't accept this, but if you change it like so then
> maybe..."
Neat analogy!
>>> Developers wishing to contribute changes to the evolution
>>> of a second patch submission must supply their own Siged-off-by
>>> tag to the original authors and must submit their changes
>>> on a public mailing list or ensure that these submission
>>> are recorded somewhere publicly.
>
> Should != must.
Agreed. I believe must is good here.
>>> To date a few of these type of contributors have expressed
>>> different preferences for whether or not their own SOB tag
>>> should be used for a second code submission. Lets keep things
>>> simple and only require the contributor's SOB tag if so desired
>>> explicitly. It is not technically required if there already
>>> is a public record of their contribution somewhere.
>
> Heh. "technically required". As if there's a process separate from the
> people implementing it.
It depends on the web of trust. Its all subjective but if we want to
be safe we air on the side of caution, all in fluffy theory. In
practice obviously it does not matter -- unless someone ends up
fighting for something they really care about.
> Speaking of which, did anybody ever explicitly document the four level
> developer -> maintainer -> lieutenant -> architect thing, and how each
> level owes you a _response_?
No, and in fact I actually think our Signed-off-by language could be
strengthened if we had a bit more meaning for how valuable a
Signed-off-by tag is for each of these. Right now, its pooo.
>>> ---
>>>
>>> This v2 has Singed/Signed typo fixes.
>>>
>>> Documentation/SubmittingPatches | 15 +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>
> You realize this is a political document as much as technical, right?
No. I did not think about that actually. All I wanted to do when I
wrote this patch is end a common type of disagreement I have seen over
the years with different developers taking different positions on
whether or not their Singed-off-by should be used if they sent a small
patch to a not-yet-upstream driver. Its really quite simple so best is
to document the simplest way for us to evolve IMHO. I really do not
give a rats ass about the political nature of this. I just want us to
get work done faster and more efficiently without spending energy on
stupid questions like this one.
> Making those longer and more specific is seldom a good idea.
I agree. Whoever decides the worthiness of this will decide whether or
not this merits integration. I don't give a shit, if not merged at
least the patch is out there and we've talked about it. In this case
though I think it would help us evolve faster.
>>> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
>>> index c379a2a..3154565 100644
>>> --- a/Documentation/SubmittingPatches
>>> +++ b/Documentation/SubmittingPatches
>>> @@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that under no circumstances
>>> can you change the author's identity (the From header), as it is the one
>>> which appears in the changelog.
>>>
>>> +If you are submitting a large change (for example a new driver) at times
>>> +you may be asked to make quite a lot of modifications prior to getting
>>> +your change accepted. At times you may even receive patches from developers
>>> +who not only wish to tell you what you should change to get your changes
>>> +upstream but actually send you patches. If those patches were made publicly
>>> +and they do contain a Signed-off-by tag you are not expected to provide
>>
>> I would add a comma: tag,
>>
>> but for a patch that attempts to clarify, I don't find it very helpful.
>>
>>> +their own Signed-off-by tag on the second iteration of the patch so long
>>> +as there is a public record somewhere that can be used to show the
>>> +contributor had sent their changes with their own Signed-off-by tag.
>
> Are you expecting another SCO, or is this just the standard bueaucratic
> "once a procedure is in place we must continue to elaborate it until it
> describes approved methods of breathing"?
We should not have a document which claims a correct way kernel
developers should wipe their asses. No. But if we throw feces at each
others, perhaps a document would help explain what is fair play.
> The signed-off-by was a way of saying "I claim to be authorized to
> submit this code, so if you find out later it's plaguraized you can
> blame me". Having someone to blame makes lawyers happy, and we were
> being sued by a troll at the time.
True.
> As long as the mechanism's there, additional whatevered-by lines provide
> an easy "who do I cc if I bisect a bug to this patch and want answers".
> It also provides an email address for the original author if they
> weren't using git.
Sure, the practical stuff -- I use one tag for helping cherry pick
patches that fall under the stable - non-stable hazy area. I take them
all in backported releases while still respecting and prioritizing
upstream development.
> Getting your thingied-by: on there can also be a way of saying "I use
> this darn feature and want to see the patch go in already, sheesh" but
> the politics are actually more complicated than that. (The big questions
> Linus wants an answer to are "is doing this a good idea in the first
> place", "is this the best way to do it", and "will this thing be
> _maintained_ if an unrelated change breaks it five years from now".
> Interest from unrelated third parties doesn't necessarily answer any of
> those questions.)
I think we should not throw feces at each other for whether or not
someone added your SOB to a 2nd full patch submission if someone sent
you a SOB'd patch to you to help you evolve your first submission.
That is all.
>>> +If you receive patches privately during development you may want to
>>> +ask for these patches to be re-posted publicly or you can also decide
>>> +to merge the patches as part of a separate historical git tree that
>>> +will remain online for historical archiving.
>>
>> I don't think it's a good idea to require a historical git archive for
>> (private) patches.
>
> I think it's actively detrimental to try to require that.
Agreed.
> For a patch that was developed privately in-house at at some large
> corporation and had to go through the legal clearance dance of "Let's
> pretend that Qualcomm Innovation Center is a different entity than
> Qualcomm, and while you're at it let's pretend the Code Aurora
> Foundation is more than a partnership between Qualcomm and Qualcomm with
> Intel's name stamped on it to act as a condom over our sock puppet to
> keep the Icky GPL from affecting our patent licensing revenue"...
This is awesome :)
> And you then ask for the full development history of that patch? Not
> likely.
Um, this is not coming from anyone wearing a company hat. This is
coming from me from seeing poo being thrown around over the SOB usage.
I'm happy to ignore it if no one cares, but then next time please put
the poo down if this questions comes up again.
> Sometimes the only way the poor engineers can get serious
> external review of that sort of stuff before submitting a frozen copy to
> a legal gauntlet is to hire a consultant and have them review it under NDA.
For companies that are full of poo, yes.
> It's useful to encourage people to release early/often when they can, so
> we can critque their design before they've put a lot of effort into
> going down the wrong path (ala OpenVZ spending a dozen years getting
> containers to work right in a persistent out-of-tree fork and then
> having Linus veto the buckets-of-new-syscalls API so they had to chip
> each bit off and port it to a new API to get containers upstream). That
> winds up saving people real work in the long run.
I could not agree any more with this statement.
> But implying "submitting working code and giving us your word can be
> used under GPLv2" is not enough? Not so much.
Yup, agreed.
>> If I send a patch privately and it contains an SOB:
>> line, then the maintainer should be able to apply the patch and
>> use the SOB: from the patch (IMO). Are you addressing some concern
>> about fraudulent emails/patches?
>>
>>> +
>>> Special note to back-porters: It seems to be a common and useful practise
>>> to insert an indication of the origin of a patch at the top of the commit
>>> message (just after the subject line) to facilitate tracking. For instance,
>
> The purpose of signed-off-by is to let people figure out where code came
> from and why. If you don't do that the reviewers will ding you.
Sure.
> I'd rather communicate that than the rest of this message combined.
I've tried this before and have seen others throw poo at each other
for it. If you're fast and good -- you never have to deal with
secondary SOBs, but if you are learning -- think of small companies or
new BUs doing kernel work, then yes -- you will have poo thrown at
you, and for many things. I think the issues you pointed out are
worthy of poo throwing, the usage of the SOB tag though -- no, it
should be trivial.
Luis
^ permalink raw reply
* Re: [patch net-next v2 01/15] net: introduce upper device lists
From: Jiri Pirko @ 2012-08-15 7:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, davem, edumazet, faisal.latif, roland, sean.hefty,
hal.rosenstock, fubar, andy, divy, jitendra.kalsaria, sony.chacko,
linux-driver, kaber, ursula.braun, blaschka, linux390, shemminger,
therbert, xiyou.wangcong, joe, gregory.v.rose, john.r.fastabend,
linux-rdma, linux-kernel, linux-s390, bridge, fbl
In-Reply-To: <1344983624.2690.77.camel@bwh-desktop.uk.solarflarecom.com>
Wed, Aug 15, 2012 at 12:33:44AM CEST, bhutchings@solarflare.com wrote:
>On Tue, 2012-08-14 at 17:05 +0200, Jiri Pirko wrote:
>> This lists are supposed to serve for storing pointers to all upper devices.
>> Eventually it will replace dev->master pointer which is used for
>> bonding, bridge, team but it cannot be used for vlan, macvlan where
>> there might be multiple upper present. In case the upper link is
>> replacement for dev->master, it is marked with "master" flag.
>
>Something I found interesting is that the dev->master pointer and now
>netdev_master_upper_dev_get{,_rcu}() are hardly used by the stackled
>drivers that set the master. They also have to set an rx_handler on the
>lower device (which is itself mutually exclusive) which gets its own
>context pointer (rx_handler_data).
>
>Instead, the master pointer is mostly used by device drivers to find out
>about a bridge or bonding device above *their* devices. And that seems
>to work only for those specific device drivers, not e.g. openvswitch or
>team. I wonder if we could find a better way to encapsulate the things
>they want do do, in a later step (not holding up this change!).
Yes. I was thinking about this as well. I believe that we should follow up
with this.
>
>[...]
>> +static int __netdev_upper_dev_link(struct net_device *dev,
>> + struct net_device *upper_dev, bool master)
>> +{
>> + struct netdev_upper *upper;
>> +
>> + ASSERT_RTNL();
>> +
>> + if (dev == upper_dev)
>> + return -EBUSY;
>> + /*
>> + * To prevent loops, check if dev is not upper device to upper_dev.
>> + */
>> + if (__netdev_has_upper_dev(upper_dev, dev, true))
>> + return -EBUSY;
>[...]
>
>I think we will also need to limit the depth of the device stack so we
>don't run out of stack space here. __netif_receive() implements a kind
>of tail recursion whenever a packet is passed up, but
>__netdev_has_upper_dev() can't avoid doing real recursion (without the
>addition of a flag to net_device so it can mark its progress).
>
You are probably right. I'm not sure how to handle this correctly
though. Adding some hard limit number might not be correct.
The problem could be also resolved by adding another struct list_head
into struct upper and use this inside __netdev_has_upper_dev(). But that
does not seem right to me as well (Considering the fact that walking
through the tree could be in future done under _rcu).
>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
* Re: [patch net-next v2 00/15] net: introduce upper device lists and remove dev->master
From: Jiri Pirko @ 2012-08-15 7:30 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andy Gospodarek, netdev, davem, edumazet, faisal.latif, roland,
sean.hefty, hal.rosenstock, fubar, andy, divy, jitendra.kalsaria,
sony.chacko, linux-driver, kaber, ursula.braun, blaschka,
linux390, shemminger, therbert, xiyou.wangcong, joe,
gregory.v.rose, john.r.fastabend, linux-rdma, linux-kernel,
linux-s390, bridge, fbl
In-Reply-To: <1344976373.2690.41.camel@bwh-desktop.uk.solarflarecom.com>
Tue, Aug 14, 2012 at 10:32:53PM CEST, bhutchings@solarflare.com wrote:
>On Tue, 2012-08-14 at 16:19 -0400, Andy Gospodarek wrote:
>> On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
>> > Hi all.
>> >
>> > Recent discussion around
>> > "[net-next] bonding: don't allow the master to become its slave"
>> > forced me to think about upper<->lower device connections.
>> >
>> > This patchset adds a possibility to record upper device linkage.
>> > All upper<->lower devices are converted to use this mechanism right after.
>> > That leads to dev->master removal because this info becomes redundant since
>> > "unique links" have the same value.
>> >
>> > After all changes, there is no longer possible to do:
>> > "bond->someotherdevice->samebond"
>> >
>> > Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
>> > in future by being able to get more appropriate info about l3 addresses.
>> >
>> > v1->v2:
>> > - s/unique/master/ better naming + stays closer to the history
>> > - fixed vlan err goto
>> > - original patch 15 (WARN_ON change) is squashed into the first patch
>> > - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
>> I just started to review v1 when v2 came out, but luckily the changes
>> were not too significant that I need to start all over.
>>
>> The first note is that I didn't like the use of the term 'upper' -- it
>> seems like 'stacked' might be a better alternative as these are stacked
>> devices.
>
>When linking any two devices in a stack, one will be upper and the other
>lower. The lower device might itself be stacked on top of a further
>device, so 'stacked' is not a useful distinguishing adjective in
>variable names. It might be a useful term in the commit messages and
>kernel-doc, though.
>
>> One thing to note is that I don't see any clear changelog that states
>> the current goals for this. You have stated in several places that it
>> will no longer be possible to create bonds of bonds, but there are
>> probably a few more things it might be wise to intentionally outlaw.
>>
>> What about teams of teams? Or teams of bonds? Or bonds of teams?
>> Bonds of vlans?
>[...]
>
>It doesn't disallow bonds of bonds (unless I'm missing something). It
>disallows loops that involve any or all of those types of stacked
>devices.
Exactly. It's every "upper driver" responsibility to check which device
it allows to be added as lower.
>
>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
* Re: [REVIEW][PATCH 0/21] User namespace changes to the networking stack.
From: Eric W. Biederman @ 2012-08-15 6:37 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20120814.171203.1784557890475348401.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
> Date: Mon, 13 Aug 2012 13:07:10 -0700
>
>>
>> This is a modest set of changes against the current networking stack to
>> enable basic user namespace support. Allowing the code to compile with
>> user namespaces enabled and removing the assumption that there is only
>> the initial user namespace.
>>
>> Work to relax the privilege checks in the networking stack from
>> "capable(CAP_NET_ADMIN)" or "capable(CAP_NET_RAW)" to
>> "ns_capable(net->user_ns, CAP_NET_ADMIN)" or
>> "ns_capable(net->user_ns, CAP_NET_RAW)" allowing root in a user
>> namespace to control a network namespace will come later.
>>
>> David there are just enough interdependencies between the user namespace
>> bits that I intend to merge them all through my user namespace tree.
>> After the review is complete I will add these patches to my for-next
>> branch of my user-namespace.git tree where I do not intend to rebase.
>> If it make sense to pull these into net-next to avoid or reduce
>> conflicts that should not be a problem.
>
> Looks fine to me, you can add:
>
> Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>
> to all of this stuff. Let me know when something is stable in your
> tree, and I can therefore pull from it into net-next.
All of these patches + 2 others trivial userns bug fixes are now
in my for-next branch at:
git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next
I won't be rebasing that branch so feel free to merge it into net-next
if you are so inclined. It will be a day or two before I get my next
chunk of patches posted, reviewed and ready to join my for-next branch.
Eric
^ permalink raw reply
* [PATCH] net: sh_eth: Add eth support for R8A7779 device
From: Phil Edworthy @ 2012-08-15 6:33 UTC (permalink / raw)
To: netdev; +Cc: linux-sh, Kuninori Morimoto, Yoshihiro Shimoda, Phil Edworthy
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
---
drivers/net/ethernet/renesas/Kconfig | 4 ++--
drivers/net/ethernet/renesas/sh_eth.c | 11 ++++++++---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/Kconfig b/drivers/net/ethernet/renesas/Kconfig
index 46df3a0..24c2305 100644
--- a/drivers/net/ethernet/renesas/Kconfig
+++ b/drivers/net/ethernet/renesas/Kconfig
@@ -8,7 +8,7 @@ config SH_ETH
(CPU_SUBTYPE_SH7710 || CPU_SUBTYPE_SH7712 || \
CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7619 || \
CPU_SUBTYPE_SH7724 || CPU_SUBTYPE_SH7734 || \
- CPU_SUBTYPE_SH7757 || ARCH_R8A7740)
+ CPU_SUBTYPE_SH7757 || ARCH_R8A7740 || ARCH_R8A7779)
select CRC32
select NET_CORE
select MII
@@ -18,4 +18,4 @@ config SH_ETH
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
- and R8A7740.
+ R8A7740 and R8A7779.
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index af0b867..bad8f2e 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -78,7 +78,7 @@ static void sh_eth_select_mii(struct net_device *ndev)
#endif
/* There is CPU dependent code */
-#if defined(CONFIG_CPU_SUBTYPE_SH7724)
+#if defined(CONFIG_CPU_SUBTYPE_SH7724) || defined(CONFIG_ARCH_R8A7779)
#define SH_ETH_RESET_DEFAULT 1
static void sh_eth_set_duplex(struct net_device *ndev)
{
@@ -93,13 +93,18 @@ static void sh_eth_set_duplex(struct net_device *ndev)
static void sh_eth_set_rate(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned int bits = ECMR_RTM;
+
+#if defined(CONFIG_ARCH_R8A7779)
+ bits |= ECMR_ELB;
+#endif
switch (mdp->speed) {
case 10: /* 10BASE */
- sh_eth_write(ndev, sh_eth_read(ndev, ECMR) & ~ECMR_RTM, ECMR);
+ sh_eth_write(ndev, sh_eth_read(ndev, ECMR) & ~bits, ECMR);
break;
case 100:/* 100BASE */
- sh_eth_write(ndev, sh_eth_read(ndev, ECMR) | ECMR_RTM, ECMR);
+ sh_eth_write(ndev, sh_eth_read(ndev, ECMR) | bits, ECMR);
break;
default:
break;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next 0/7] sctp: network namespace support Part 2: per net tunables
From: David Miller @ 2012-08-15 6:10 UTC (permalink / raw)
To: ebiederm
Cc: vyasevich, linux-sctp, netdev, linux-kernel, jan.ariyasu,
jan.ariyasu, nhorman, tgraf, xi.wang
In-Reply-To: <87ipcud3ld.fsf_-_@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 07 Aug 2012 10:17:02 -0700
>
> Since I am motivated to get things done, and since there has been much
> grumbling about my patches not implementing tunables, I have added
> tunable support on top of my last patchset.
>
> I have performed basic testing on the these patches and nothing
> appears amis.
>
> The sm statemachine is a major tease as it has all of these association
> and endpoint pointers in the common set of function parameters that turn
> out to be NULL at the most inconvinient times. So I added to the common
> parameter list a struct net pointer, that is never NULL.
Now that I have the ACKs from Vlad, I'm applying all of your work,
thanks Eric.
^ permalink raw reply
* [PATCH net-next] igb: Change how we check for pre-existing and assigned VFs
From: Stefan Assmann @ 2012-08-15 5:51 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, carolyn.wyborny, gregory.v.rose, sassmann
Adapt the pre-existing and assigned VFs code to the ixgbe way introduced
in commit 9297127b9cdd8d30c829ef5fd28b7cc0323a7bcd.
Instead of searching the enabled VFs we use pci_num_vf to determine enabled VFs.
By comparing to which PF an assigned VF is owned it's possible to decide
whether to leave it enabled or not.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/igb/igb.h | 1 -
drivers/net/ethernet/intel/igb/igb_main.c | 104 ++++++-----------------------
2 files changed, 22 insertions(+), 83 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 9e572dd..d15576a 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -99,7 +99,6 @@ struct vf_data_storage {
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
- struct pci_dev *vfdev;
};
#define IGB_VF_FLAG_CTS 0x00000001 /* VF is clear to send data */
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index b7c2d50..9e312da 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -172,8 +172,7 @@ static void igb_check_vf_rate_limit(struct igb_adapter *);
#ifdef CONFIG_PCI_IOV
static int igb_vf_configure(struct igb_adapter *adapter, int vf);
-static int igb_find_enabled_vfs(struct igb_adapter *adapter);
-static int igb_check_vf_assignment(struct igb_adapter *adapter);
+static bool igb_vfs_are_assigned(struct igb_adapter *adapter);
#endif
#ifdef CONFIG_PM
@@ -2295,11 +2294,11 @@ static void __devexit igb_remove(struct pci_dev *pdev)
/* reclaim resources allocated to VFs */
if (adapter->vf_data) {
/* disable iov and allow time for transactions to clear */
- if (!igb_check_vf_assignment(adapter)) {
+ if (igb_vfs_are_assigned(adapter)) {
+ dev_info(&pdev->dev, "Unloading driver while VFs are assigned - VFs will not be deallocated\n");
+ } else {
pci_disable_sriov(pdev);
msleep(500);
- } else {
- dev_info(&pdev->dev, "VF(s) assigned to guests!\n");
}
kfree(adapter->vf_data);
@@ -2339,7 +2338,7 @@ static void __devinit igb_probe_vfs(struct igb_adapter * adapter)
#ifdef CONFIG_PCI_IOV
struct pci_dev *pdev = adapter->pdev;
struct e1000_hw *hw = &adapter->hw;
- int old_vfs = igb_find_enabled_vfs(adapter);
+ int old_vfs = pci_num_vf(adapter->pdev);
int i;
/* Virtualization features not supported on i210 family. */
@@ -5003,102 +5002,43 @@ static int igb_notify_dca(struct notifier_block *nb, unsigned long event,
static int igb_vf_configure(struct igb_adapter *adapter, int vf)
{
unsigned char mac_addr[ETH_ALEN];
- struct pci_dev *pdev = adapter->pdev;
- struct e1000_hw *hw = &adapter->hw;
- struct pci_dev *pvfdev;
- unsigned int device_id;
- u16 thisvf_devfn;
eth_random_addr(mac_addr);
igb_set_vf_mac(adapter, vf, mac_addr);
- switch (adapter->hw.mac.type) {
- case e1000_82576:
- device_id = IGB_82576_VF_DEV_ID;
- /* VF Stride for 82576 is 2 */
- thisvf_devfn = (pdev->devfn + 0x80 + (vf << 1)) |
- (pdev->devfn & 1);
- break;
- case e1000_i350:
- device_id = IGB_I350_VF_DEV_ID;
- /* VF Stride for I350 is 4 */
- thisvf_devfn = (pdev->devfn + 0x80 + (vf << 2)) |
- (pdev->devfn & 3);
- break;
- default:
- device_id = 0;
- thisvf_devfn = 0;
- break;
- }
-
- pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
- while (pvfdev) {
- if (pvfdev->devfn == thisvf_devfn)
- break;
- pvfdev = pci_get_device(hw->vendor_id,
- device_id, pvfdev);
- }
-
- if (pvfdev)
- adapter->vf_data[vf].vfdev = pvfdev;
- else
- dev_err(&pdev->dev,
- "Couldn't find pci dev ptr for VF %4.4x\n",
- thisvf_devfn);
- return pvfdev != NULL;
+ return 0;
}
-static int igb_find_enabled_vfs(struct igb_adapter *adapter)
+static bool igb_vfs_are_assigned(struct igb_adapter *adapter)
{
- struct e1000_hw *hw = &adapter->hw;
struct pci_dev *pdev = adapter->pdev;
- struct pci_dev *pvfdev;
- u16 vf_devfn = 0;
- u16 vf_stride;
- unsigned int device_id;
- int vfs_found = 0;
+ struct pci_dev *vfdev;
+ int dev_id;
switch (adapter->hw.mac.type) {
case e1000_82576:
- device_id = IGB_82576_VF_DEV_ID;
- /* VF Stride for 82576 is 2 */
- vf_stride = 2;
+ dev_id = IGB_82576_VF_DEV_ID;
break;
case e1000_i350:
- device_id = IGB_I350_VF_DEV_ID;
- /* VF Stride for I350 is 4 */
- vf_stride = 4;
+ dev_id = IGB_I350_VF_DEV_ID;
break;
default:
- device_id = 0;
- vf_stride = 0;
- break;
- }
-
- vf_devfn = pdev->devfn + 0x80;
- pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
- while (pvfdev) {
- if (pvfdev->devfn == vf_devfn &&
- (pvfdev->bus->number >= pdev->bus->number))
- vfs_found++;
- vf_devfn += vf_stride;
- pvfdev = pci_get_device(hw->vendor_id,
- device_id, pvfdev);
+ return false;
}
- return vfs_found;
-}
-
-static int igb_check_vf_assignment(struct igb_adapter *adapter)
-{
- int i;
- for (i = 0; i < adapter->vfs_allocated_count; i++) {
- if (adapter->vf_data[i].vfdev) {
- if (adapter->vf_data[i].vfdev->dev_flags &
- PCI_DEV_FLAGS_ASSIGNED)
+ /* loop through all the VFs to see if we own any that are assigned */
+ vfdev = pci_get_device(PCI_VENDOR_ID_INTEL, dev_id, NULL);
+ while (vfdev) {
+ /* if we don't own it we don't care */
+ if (vfdev->is_virtfn && vfdev->physfn == pdev) {
+ /* if it is assigned we cannot release it */
+ if (vfdev->dev_flags & PCI_DEV_FLAGS_ASSIGNED)
return true;
}
+
+ vfdev = pci_get_device(PCI_VENDOR_ID_INTEL, dev_id, vfdev);
}
+
return false;
}
--
1.7.4.4
^ permalink raw reply related
* RE: [PATCH] net: add new QCA alx ethernet driver
From: Ren, Cloud @ 2012-08-15 5:39 UTC (permalink / raw)
To: David Miller
Cc: shemminger@vyatta.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qca-linux-team, nic-devel,
Huang, Xiong, hao-ran.liu@canonical.com, joe@perches.com,
Rodriguez, Luis
In-Reply-To: <20120814.223258.1180104882398843954.davem@davemloft.net>
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, August 15, 2012 1:33 PM
>From: "Ren, Cloud" <cjren@qca.qualcomm.com>
>Date: Wed, 15 Aug 2012 03:29:26 +0000
>
>>>> + strncpy(netdev->name, pci_name(pdev), sizeof(netdev->name) - 1);
>>>> ...
>>>> + strcpy(netdev->name, "eth%d");
>>>> + retval = register_netdev(netdev);
>>>
>>>The strcpy is unnecessary, alloc_etherdev already sets that.
>>
>> The strcpy is useful. netdev->name is set as pci_name in front. So the strcpy
>restores it.
>
>Are you doing this just to influence the initial driver log messages?
Yes.
>
>Don't do that, it's gross.
Ok, I will remove it.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-08-15 5:39 UTC (permalink / raw)
To: billfink; +Cc: brutus, edumazet, netdev
In-Reply-To: <20120815012428.c747fa9d.billfink@mindspring.com>
From: Bill Fink <billfink@mindspring.com>
Date: Wed, 15 Aug 2012 01:24:28 -0400
> I see no reason to make it obtuse rather than something more
> descriptive of its function (as opposed to how it's implemented).
I want to live in a world where things are allowed to have some
character, and some slightly amusing names. And that's why we'll
call it TCP friends, thank you very much.
> I do have some concern that since the loopback path through the
> TCP stack won't be heavily exercised anymore, it may be more likely
> for bugs or performance degradations to creep into that code.
Are you kidding me? Most people do not use loopback TCP, they use
TCP to a real external entity. TCP friends only kicks in for
loopback connections.
So, like all of your other concerns, this one is meritless.
^ permalink raw reply
* Re: [PATCH] net: add new QCA alx ethernet driver
From: David Miller @ 2012-08-15 5:32 UTC (permalink / raw)
To: cjren
Cc: shemminger, netdev, linux-kernel, qca-linux-team, nic-devel,
xiong, hao-ran.liu, joe, rodrigue
In-Reply-To: <6349D7A510622448B1BA0967850A84380136A1EF@NASANEXD02D.na.qualcomm.com>
From: "Ren, Cloud" <cjren@qca.qualcomm.com>
Date: Wed, 15 Aug 2012 03:29:26 +0000
>>> + strncpy(netdev->name, pci_name(pdev), sizeof(netdev->name) - 1);
>>> ...
>>> + strcpy(netdev->name, "eth%d");
>>> + retval = register_netdev(netdev);
>>
>>The strcpy is unnecessary, alloc_etherdev already sets that.
>
> The strcpy is useful. netdev->name is set as pci_name in front. So the strcpy restores it.
Are you doing this just to influence the initial driver log messages?
Don't do that, it's gross.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: Bill Fink @ 2012-08-15 5:24 UTC (permalink / raw)
To: Bruce Curtis; +Cc: David S. Miller, Eric Dumazet, netdev
In-Reply-To: <CAEkNxbFgr1Qws_Fp3igDhir-81R-XWr52inmuXb1MNS9NigU0Q@mail.gmail.com>
On Tue, 14 Aug, Bruce Curtis wrote:
> On Mon, Aug 13, 2012 at 11:31 PM, Bill Fink <billfink@mindspring.com> wrote:
> >
> > On Thu, 9 Aug 2012, Bruce "Brutus" Curtis wrote:
> >
> > > From: "Bruce \"Brutus\" Curtis" <brutus@google.com>
> > >
> > > TCP/IP loopback socket pair stack bypass, based on an idea by, and
> > > rough upstream patch from, David Miller <davem@davemloft.net> called
> > > "friends", the data structure modifcations and connection scheme are
> > > reused with extensive data-path changes.
> > >
> > > A new sysctl, net.ipv4.tcp_friends, is added:
> > > 0: disable friends and use the stock data path.
> > > 1: enable friends and bypass the stack data path, the default.
> >
> > The following is from a user perspective, since I am not
> > intimately familiar with the internals of the TCP stack.
> >
> > I think tcp_friends is a poor name from a user POV.
> > Something like tcp_bypass would be much better.
> >
> > I also believe it should be disabled by default, as that is
> > the current behavior, and those who would gain an advantage
> > from using it can easily enable it.
> >
> > Changing the behavior would violate the principle of least
> > surprise. Loopback TCP testing of an application or system
> > is often a useful first step in evaluating its behavior and
> > performance. If the TCP stack is bypassed, it will give a
> > very false impression when such tests are performed.
> >
> > Does it preserve all TCP semantics for applications, including
> > things like urgent data, ancillary data, and TCP socket options
> > and ioctls. If it doesn't, it shouldn't be the default, and it
> > should be documented what features do and don't work when
> > tcp_bypass is enabled. If all TCP semantics are unchanged,
> > that would also be good to know and document.
> >
> > And there's the already mentioned issue of breaking tcpdump
> > and related tools.
> >
> > While this could be a very useful feature in some environments,
> > it seems to me it would be safest to have it disabled by default.
> >
> > -Bill
> >
> 1) tcp_friends vs tcp_bypass, the average user will not need to know
> about this tunable so if there's consensus that it needs to be
> changed, change it?
I see no reason to make it obtuse rather than something more
descriptive of its function (as opposed to how it's implemented).
> 2) this is a throughput/latency advantage for most (all?) so it
> benefits most (all?) production environments
I grant that given that (4) below is true.
> 3) as for breaking tcpdump and ... Again, it does maintain the
> connection establishment and finish packet flow so for most TCP
> connection related interpose uses this should work and be documented
> but if your trying to debug TCP's protocol state-machine, network
> emulation, ... then Yes a user would need to disable but IMHO this is
> the exception
>
> 4) all TCP socket semantics are maintained and if not it's a bug and
> needs to be fixed
This was my biggest concern if it wasn't true. Since you have now
verified that all TCP semantics are preserved, I now don't have a
major issue with it being enabled by default, since it's easy to
disable for more specialized situations.
I do have some concern that since the loopback path through the
TCP stack won't be heavily exercised anymore, it may be more likely
for bugs or performance degradations to creep into that code.
-Thanks
-Bill
^ permalink raw reply
* Re: [PATCH 06/21] userns: Print out socket uids in a user namespace aware fashion.
From: Eric W. Biederman @ 2012-08-15 4:47 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201208132326.35045.remi-AzDNUFsAnHasTnJN9+BGXg@public.gmane.org>
"Rémi Denis-Courmont" <remi@remlab.net> writes:
> Le lundi 13 août 2012 23:18:20, vous avez écrit :
>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> Cc: David Miller <davem@davemloft.net>
>> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>> Cc: Sridhar Samudrala <sri@us.ibm.com>
>> Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> FWIW, ...
Well I will take every bit of review I can get. It can be terribly
embarrassing to discover you messed up uid/gid handling and no one
noticed the security hole for 3 kernel releases...
> Acked-By: Rémi Denis-Courmont <remi@remlab.net>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH net 2/3] llc2: Call llc_station_exit() on llc2_init() failure path
From: Ben Hutchings @ 2012-08-15 4:06 UTC (permalink / raw)
To: David Miller; +Cc: acme, netdev
In-Reply-To: <20120814.165223.953955272458502981.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Tue, 2012-08-14 at 16:52 -0700, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Mon, 13 Aug 2012 13:50:43 +0100
>
> > Otherwise the station packet handler will remain registered even though
> > the module is unloaded.
> >
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>
> This will cause section mismatch errors, you'll need to remove
> the __exit tag from llc_station_exit() if you want to start
> invoking it from llc2_init() which is __init.
>
> I took care of this when applying this patch to 'net'.
Thanks, David.
llc_station.c turns out to be mostly dead code, and I have some more
radical changes to remove that which I'll send after you next merge net
into net-next.
Ben.
--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 02/16] user_ns: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-08-15 3:31 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Sasha Levin, torvalds, tj, akpm, linux-kernel, linux-mm,
paul.gortmaker, davem, rostedt, mingo, aarcange, ericvh, netdev,
josh, eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie,
teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <87obmchmpu.fsf@xmission.com>
* Eric W. Biederman (ebiederm@xmission.com) wrote:
> Sasha Levin <levinsasha928@gmail.com> writes:
>
> > On 08/15/2012 03:08 AM, Eric W. Biederman wrote:
> >>> I can offer the following: I'll write a small module that will hash 1...10000
> >>> > into a hashtable which uses 7 bits (just like user_ns) and post the distribution
> >>> > we'll get.
> >> That won't hurt. I think 1-100 then 1000-1100 may actually be more
> >> representative. Not that I would mind seeing the larger range.
> >> Especially since I am in the process of encouraging the use of more
> >> uids.
> >>
> >
> > Alrighty, the results are in (numbers are objects in bucket):
> >
> > For the 0...10000 range:
> >
> > Average: 78.125
> > Std dev: 1.4197704151
> > Min: 75
> > Max: 80
> >
> >
> > For the 1...100 range:
> >
> > Average: 0.78125
> > Std dev: 0.5164613088
> > Min: 0
> > Max: 2
> >
> >
> > For the 1000...1100 range:
> >
> > Average: 0.7890625
> > Std dev: 0.4964812206
> > Min: 0
> > Max: 2
> >
> >
> > Looks like hash_32 is pretty good with small numbers.
>
> Yes hash_32 seems reasonable for the uid hash. With those long hash
> chains I wouldn't like to be on a machine with 10,000 processes with
> each with a different uid, and a processes calling setuid in the fast
> path.
>
> The uid hash that we are playing with is one that I sort of wish that
> the hash table could grow in size, so that we could scale up better.
Hi Eric,
If you want to try out something that has more features than a basic
hash table, already exists and is available for you to play with, you
might want to have a look at the RCU lock-free resizable hash table.
It's initially done in userspace, but shares the same RCU semantic as
the kernel, and has chunk-based kernel-friendly index backends (thanks
to Lai Jiangshan), very useful to integrate with the kernel page
allocator.
It has the following properties that might make this container a good
fit for uid hashing:
- Real-time friendly lookups: Lookups are RCU and wait-free.
- Fast and real-time friendly updates: Use cmpxchg for update, and RCU
to deal with ABA.
- Resize (expand/shrink) for each power of two size, performed
concurrently with ongoing updates and lookups.
- Has add_unique (uniquify), add_replace, and also duplicate semantics.
- Provide uniqueness guarantees for RCU traversals of the hash table
with respect to add_unique and add_replace.
So if you are looking for a fast, RT-friendly, resizable hash table to
play with, you might want to have a look at the userspace RCU
implementation, which now features this hash table:
https://lttng.org/urcu
See urcu/rculfhash.h for the API.
Best regards,
Mathieu
>
> Aw well. Most of the time we only have a very small number of uids
> in play, so it doesn't matter at this point.
>
> Eric
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: [PATCH] net: add new QCA alx ethernet driver
From: Ren, Cloud @ 2012-08-15 3:29 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qca-linux-team, nic-devel,
Huang, Xiong, Hao-Ran Liu(Joseph Liu), Joe Perches,
Rodriguez, Luis
In-Reply-To: <20120811135044.529a7081@nehalam.linuxnetplumber.net>
>> + strncpy(netdev->name, pci_name(pdev), sizeof(netdev->name) - 1);
>> ...
>> + strcpy(netdev->name, "eth%d");
>> + retval = register_netdev(netdev);
>
>The strcpy is unnecessary, alloc_etherdev already sets that.
The strcpy is useful. netdev->name is set as pci_name in front. So the strcpy restores it.
Thanks
cloud
^ permalink raw reply
* Re: [PATCH 00/13] SCTP: Enable netns
From: Vlad Yasevich @ 2012-08-15 3:23 UTC (permalink / raw)
To: Jan Ariyasu
Cc: David S. Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu
In-Reply-To: <1344115837-6150-1-git-send-email-jan.ariyasu@hp.com>
On 08/04/2012 05:30 PM, Jan Ariyasu wrote:
> The following set of patches enable network-namespaces for the SCTP protocol.
>
> The multitude of global parameters are stored in a net_generic
> structure, and the bulk of the patches enable the protocol to access
> the parameters on a per-namespace basis. The first five patches
> enable netns handling of the protocol, procfs and sysfs.
>
> Signed-off-by: Jan Ariyasu <jan.ariyasu@hp.com>
> ---
>
NACK. Sorry Jan, but Eric's patches are much cleaner and do everything
that's needed.
-vlad
^ permalink raw reply
* Re: [PATCH 06/21] userns: Print out socket uids in a user namespace aware fashion.
From: Vlad Yasevich @ 2012-08-15 3:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Patrick McHardy, Hideaki YOSHIFUJI, netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnaldo Carvalho de Melo,
Remi Denis-Courmont, Alexey Kuznetsov, Sridhar Samudrala,
David Miller
In-Reply-To: <1344889115-21610-6-git-send-email-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 08/13/2012 04:18 PM, Eric W. Biederman wrote:
> From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>
> Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Alexey Kuznetsov <kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org>
> Cc: James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji-VfPWfsRibaP+Ru+s062T9g@public.gmane.org>
> Cc: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
> Cc: Remi Denis-Courmont <courmisch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Arnaldo Carvalho de Melo <acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> Cc: Vlad Yasevich <vyasevich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Sridhar Samudrala <sri-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> Acked-by: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
ACK sctp parts
Acked-by: Vlad Yasevich <vyasevich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> include/net/tcp.h | 3 ++-
> init/Kconfig | 6 ------
> net/appletalk/atalk_proc.c | 3 ++-
> net/ipv4/ping.c | 4 +++-
> net/ipv4/raw.c | 4 +++-
> net/ipv4/tcp_ipv4.c | 6 +++---
> net/ipv4/udp.c | 4 +++-
> net/ipv6/raw.c | 3 ++-
> net/ipv6/tcp_ipv6.c | 6 +++---
> net/ipv6/udp.c | 3 ++-
> net/ipx/ipx_proc.c | 3 ++-
> net/key/af_key.c | 2 +-
> net/llc/llc_proc.c | 2 +-
> net/packet/af_packet.c | 2 +-
> net/phonet/socket.c | 6 ++++--
> net/sctp/proc.c | 6 ++++--
> 16 files changed, 36 insertions(+), 27 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e19124b..91e7467 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1509,7 +1509,8 @@ struct tcp_iter_state {
> sa_family_t family;
> enum tcp_seq_states state;
> struct sock *syn_wait_sk;
> - int bucket, offset, sbucket, num, uid;
> + int bucket, offset, sbucket, num;
> + kuid_t uid;
> loff_t last_pos;
> };
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 80fae19..25a6ebb 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -942,10 +942,7 @@ config UIDGID_CONVERTED
> depends on PROC_EVENTS = n
>
> # Networking
> - depends on PACKET = n
> depends on NET_9P = n
> - depends on IPX = n
> - depends on PHONET = n
> depends on NET_CLS_FLOW = n
> depends on NETFILTER_XT_MATCH_OWNER = n
> depends on NETFILTER_XT_MATCH_RECENT = n
> @@ -953,14 +950,11 @@ config UIDGID_CONVERTED
> depends on NETFILTER_NETLINK_LOG = n
> depends on INET = n
> depends on IPV6 = n
> - depends on IP_SCTP = n
> depends on AF_RXRPC = n
> - depends on LLC2 = n
> depends on NET_KEY = n
> depends on INET_DIAG = n
> depends on DNS_RESOLVER = n
> depends on AX25 = n
> - depends on ATALK = n
>
> # Filesystems
> depends on USB_GADGETFS = n
> diff --git a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c
> index b5b1a22..c30f3a0 100644
> --- a/net/appletalk/atalk_proc.c
> +++ b/net/appletalk/atalk_proc.c
> @@ -183,7 +183,8 @@ static int atalk_seq_socket_show(struct seq_file *seq, void *v)
> ntohs(at->dest_net), at->dest_node, at->dest_port,
> sk_wmem_alloc_get(s),
> sk_rmem_alloc_get(s),
> - s->sk_state, SOCK_INODE(s->sk_socket)->i_uid);
> + s->sk_state,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(s)));
> out:
> return 0;
> }
> diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
> index 6232d47..bee5eeb 100644
> --- a/net/ipv4/ping.c
> +++ b/net/ipv4/ping.c
> @@ -845,7 +845,9 @@ static void ping_format_sock(struct sock *sp, struct seq_file *f,
> bucket, src, srcp, dest, destp, sp->sk_state,
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> - 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
> + 0, 0L, 0,
> + from_kuid_munged(seq_user_ns(f), sock_i_uid(sp)),
> + 0, sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp,
> atomic_read(&sp->sk_drops), len);
> }
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index ff0f071..f242578 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -992,7 +992,9 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> i, src, srcp, dest, destp, sp->sk_state,
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> - 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
> + 0, 0L, 0,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
> + 0, sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
> }
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 42b2a6a..642be8a 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -2382,7 +2382,7 @@ void tcp_proc_unregister(struct net *net, struct tcp_seq_afinfo *afinfo)
> EXPORT_SYMBOL(tcp_proc_unregister);
>
> static void get_openreq4(const struct sock *sk, const struct request_sock *req,
> - struct seq_file *f, int i, int uid, int *len)
> + struct seq_file *f, int i, kuid_t uid, int *len)
> {
> const struct inet_request_sock *ireq = inet_rsk(req);
> int ttd = req->expires - jiffies;
> @@ -2399,7 +2399,7 @@ static void get_openreq4(const struct sock *sk, const struct request_sock *req,
> 1, /* timers active (only the expire timer) */
> jiffies_to_clock_t(ttd),
> req->retrans,
> - uid,
> + from_kuid_munged(seq_user_ns(f), uid),
> 0, /* non standard timer */
> 0, /* open_requests have no inode */
> atomic_read(&sk->sk_refcnt),
> @@ -2450,7 +2450,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
> timer_active,
> jiffies_to_clock_t(timer_expires - jiffies),
> icsk->icsk_retransmits,
> - sock_i_uid(sk),
> + from_kuid_munged(seq_user_ns(f), sock_i_uid(sk)),
> icsk->icsk_probes_out,
> sock_i_ino(sk),
> atomic_read(&sk->sk_refcnt), sk,
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b4c3582..53b8981 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -2110,7 +2110,9 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
> bucket, src, srcp, dest, destp, sp->sk_state,
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> - 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
> + 0, 0L, 0,
> + from_kuid_munged(seq_user_ns(f), sock_i_uid(sp)),
> + 0, sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp,
> atomic_read(&sp->sk_drops), len);
> }
> diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
> index ef0579d..7af88ef 100644
> --- a/net/ipv6/raw.c
> +++ b/net/ipv6/raw.c
> @@ -1251,7 +1251,8 @@ static void raw6_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> 0, 0L, 0,
> - sock_i_uid(sp), 0,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
> + 0,
> sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
> }
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index c66b90f..4b5b335 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1803,7 +1803,7 @@ static void tcp_v6_destroy_sock(struct sock *sk)
> #ifdef CONFIG_PROC_FS
> /* Proc filesystem TCPv6 sock list dumping. */
> static void get_openreq6(struct seq_file *seq,
> - const struct sock *sk, struct request_sock *req, int i, int uid)
> + const struct sock *sk, struct request_sock *req, int i, kuid_t uid)
> {
> int ttd = req->expires - jiffies;
> const struct in6_addr *src = &inet6_rsk(req)->loc_addr;
> @@ -1827,7 +1827,7 @@ static void get_openreq6(struct seq_file *seq,
> 1, /* timers active (only the expire timer) */
> jiffies_to_clock_t(ttd),
> req->retrans,
> - uid,
> + from_kuid_munged(seq_user_ns(seq), uid),
> 0, /* non standard timer */
> 0, /* open_requests have no inode */
> 0, req);
> @@ -1877,7 +1877,7 @@ static void get_tcp6_sock(struct seq_file *seq, struct sock *sp, int i)
> timer_active,
> jiffies_to_clock_t(timer_expires - jiffies),
> icsk->icsk_retransmits,
> - sock_i_uid(sp),
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
> icsk->icsk_probes_out,
> sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp,
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 99d0077..bbdff07 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1458,7 +1458,8 @@ static void udp6_sock_seq_show(struct seq_file *seq, struct sock *sp, int bucket
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> 0, 0L, 0,
> - sock_i_uid(sp), 0,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
> + 0,
> sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp,
> atomic_read(&sp->sk_drops));
> diff --git a/net/ipx/ipx_proc.c b/net/ipx/ipx_proc.c
> index f8ba30d..02ff7f2 100644
> --- a/net/ipx/ipx_proc.c
> +++ b/net/ipx/ipx_proc.c
> @@ -217,7 +217,8 @@ static int ipx_seq_socket_show(struct seq_file *seq, void *v)
> seq_printf(seq, "%08X %08X %02X %03d\n",
> sk_wmem_alloc_get(s),
> sk_rmem_alloc_get(s),
> - s->sk_state, SOCK_INODE(s->sk_socket)->i_uid);
> + s->sk_state,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(s)));
> out:
> return 0;
> }
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index 34e4185..0481d4b 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3661,7 +3661,7 @@ static int pfkey_seq_show(struct seq_file *f, void *v)
> atomic_read(&s->sk_refcnt),
> sk_rmem_alloc_get(s),
> sk_wmem_alloc_get(s),
> - sock_i_uid(s),
> + from_kuid_munged(seq_user_ns(f), sock_i_uid(s)),
> sock_i_ino(s)
> );
> return 0;
> diff --git a/net/llc/llc_proc.c b/net/llc/llc_proc.c
> index a1839c0..7b4799c 100644
> --- a/net/llc/llc_proc.c
> +++ b/net/llc/llc_proc.c
> @@ -151,7 +151,7 @@ static int llc_seq_socket_show(struct seq_file *seq, void *v)
> sk_wmem_alloc_get(sk),
> sk_rmem_alloc_get(sk) - llc->copied_seq,
> sk->sk_state,
> - sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : -1,
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
> llc->link);
> out:
> return 0;
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index ceaca7c..d147317 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -3846,7 +3846,7 @@ static int packet_seq_show(struct seq_file *seq, void *v)
> po->ifindex,
> po->running,
> atomic_read(&s->sk_rmem_alloc),
> - sock_i_uid(s),
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(s)),
> sock_i_ino(s));
> }
>
> diff --git a/net/phonet/socket.c b/net/phonet/socket.c
> index 0acc943..b7e9827 100644
> --- a/net/phonet/socket.c
> +++ b/net/phonet/socket.c
> @@ -612,7 +612,8 @@ static int pn_sock_seq_show(struct seq_file *seq, void *v)
> sk->sk_protocol, pn->sobject, pn->dobject,
> pn->resource, sk->sk_state,
> sk_wmem_alloc_get(sk), sk_rmem_alloc_get(sk),
> - sock_i_uid(sk), sock_i_ino(sk),
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
> + sock_i_ino(sk),
> atomic_read(&sk->sk_refcnt), sk,
> atomic_read(&sk->sk_drops), &len);
> }
> @@ -796,7 +797,8 @@ static int pn_res_seq_show(struct seq_file *seq, void *v)
> struct sock *sk = *psk;
>
> seq_printf(seq, "%02X %5d %lu%n",
> - (int) (psk - pnres.sk), sock_i_uid(sk),
> + (int) (psk - pnres.sk),
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
> sock_i_ino(sk), &len);
> }
> seq_printf(seq, "%*s\n", 63 - len, "");
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 1e2eee8..dc12feb 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -216,7 +216,8 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
> seq_printf(seq, "%8pK %8pK %-3d %-3d %-4d %-5d %5d %5lu ", ep, sk,
> sctp_sk(sk)->type, sk->sk_state, hash,
> epb->bind_addr.port,
> - sock_i_uid(sk), sock_i_ino(sk));
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
> + sock_i_ino(sk));
>
> sctp_seq_dump_local_addrs(seq, epb);
> seq_printf(seq, "\n");
> @@ -324,7 +325,8 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
> assoc->assoc_id,
> assoc->sndbuf_used,
> atomic_read(&assoc->rmem_alloc),
> - sock_i_uid(sk), sock_i_ino(sk),
> + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)),
> + sock_i_ino(sk),
> epb->bind_addr.port,
> assoc->peer.port);
> seq_printf(seq, " ");
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] sctp: network namespace support Part 2: per net tunables
From: Vlad Yasevich @ 2012-08-15 3:21 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu,
Jan Ariyasu, Neil Horman, Thomas Graf, Xi Wang
In-Reply-To: <87ipcud3ld.fsf_-_@xmission.com>
On 08/07/2012 01:17 PM, Eric W. Biederman wrote:
>
> Since I am motivated to get things done, and since there has been much
> grumbling about my patches not implementing tunables, I have added
> tunable support on top of my last patchset.
>
> I have performed basic testing on the these patches and nothing
> appears amis.
>
> The sm statemachine is a major tease as it has all of these association
> and endpoint pointers in the common set of function parameters that turn
> out to be NULL at the most inconvinient times. So I added to the common
> parameter list a struct net pointer, that is never NULL.
>
> include/net/netns/sctp.h | 96 +++++++-
> include/net/sctp/sctp.h | 16 +-
> include/net/sctp/sm.h | 8 +-
> include/net/sctp/structs.h | 126 +---------
> net/sctp/associola.c | 18 +-
> net/sctp/auth.c | 20 ++-
> net/sctp/bind_addr.c | 6 +-
> net/sctp/endpointola.c | 13 +-
> net/sctp/input.c | 6 +-
> net/sctp/primitive.c | 4 +-
> net/sctp/protocol.c | 137 +++++-----
> net/sctp/sm_make_chunk.c | 61 +++--
> net/sctp/sm_sideeffect.c | 26 ++-
> net/sctp/sm_statefuns.c | 631 ++++++++++++++++++++++++--------------------
> net/sctp/sm_statetable.c | 17 +-
> net/sctp/socket.c | 92 ++++---
> net/sctp/sysctl.c | 200 ++++++++------
> net/sctp/transport.c | 23 +-
> 18 files changed, 817 insertions(+), 683 deletions(-)
>
> Eric W. Biederman (7):
> sctp: Add infrastructure for per net sysctls
> sctp: Push struct net down to sctp_chunk_event_lookup
> sctp: Push struct net down into sctp_transport_init
> sctp: Push struct net down into sctp_in_scope
> sctp: Push struct net down into all of the state machine functions
> sctp: Push struct net down into sctp_verify_ext_param
> sctp: Making sysctl tunables per net
>
> Eric
>
>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
To this entire follow-on series. This is much better.
^ permalink raw reply
* Re: [PATCH net-next 1/7] sctp: Add infrastructure for per net sysctls
From: Vlad Yasevich @ 2012-08-15 3:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, linux-sctp, netdev, linux-kernel, Jan Ariyasu,
Jan Ariyasu, Neil Horman, Thomas Graf, Xi Wang
In-Reply-To: <87d332d39s.fsf_-_@xmission.com>
On 08/07/2012 01:23 PM, Eric W. Biederman wrote:
>
> Start with an empty sctp_net_table that will be populated as the various
> tunable sysctls are made per net.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> include/net/netns/sctp.h | 6 +++++-
> include/net/sctp/sctp.h | 4 ++++
> net/sctp/protocol.c | 7 +++++++
> net/sctp/sysctl.c | 21 +++++++++++++++++++++
> 4 files changed, 37 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/netns/sctp.h b/include/net/netns/sctp.h
> index 06ccddf..9576b60 100644
> --- a/include/net/netns/sctp.h
> +++ b/include/net/netns/sctp.h
> @@ -4,6 +4,7 @@
> struct sock;
> struct proc_dir_entry;
> struct sctp_mib;
> +struct ctl_table_header;
>
> struct netns_sctp {
> DEFINE_SNMP_STAT(struct sctp_mib, sctp_statistics);
> @@ -11,7 +12,9 @@ struct netns_sctp {
> #ifdef CONFIG_PROC_FS
> struct proc_dir_entry *proc_net_sctp;
> #endif
> -
> +#ifdef CONFIG_SYSCTL
> + struct ctl_table_header *sysctl_header;
> +#endif
> /* This is the global socket data structure used for responding to
> * the Out-of-the-blue (OOTB) packets. A control sock will be created
> * for this socket at the initialization time.
> @@ -32,6 +35,7 @@ struct netns_sctp {
>
> /* Lock that protects the local_addr_list writers */
> spinlock_t local_addr_lock;
> +
> };
>
> #endif /* __NETNS_SCTP_H__ */
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index b0e6fe5..15037e7 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -375,9 +375,13 @@ static inline void sctp_dbg_objcnt_exit(void) { return; }
> #if defined CONFIG_SYSCTL
> void sctp_sysctl_register(void);
> void sctp_sysctl_unregister(void);
> +int sctp_sysctl_net_register(struct net *net);
> +void sctp_sysctl_net_unregister(struct net *net);
> #else
> static inline void sctp_sysctl_register(void) { return; }
> static inline void sctp_sysctl_unregister(void) { return; }
> +static inline int sctp_sysctl_net_register(struct net *net) { return 0; }
> +static inline void sctp_sysctl_net_unregister(struct net *net) { return; }
> #endif
>
> /* Size of Supported Address Parameter for 'x' address types. */
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 69bdc72..de25d9c 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1169,6 +1169,10 @@ static int sctp_net_init(struct net *net)
> {
> int status;
>
> + status = sctp_sysctl_net_register(net);
> + if (status)
> + goto err_sysctl_register;
> +
> /* Allocate and initialise sctp mibs. */
> status = init_sctp_mibs(net);
> if (status)
> @@ -1205,6 +1209,8 @@ err_ctl_sock_init:
> err_init_proc:
> cleanup_sctp_mibs(net);
> err_init_mibs:
> + sctp_sysctl_net_unregister(net);
> +err_sysctl_register:
> return status;
> }
>
> @@ -1219,6 +1225,7 @@ static void sctp_net_exit(struct net *net)
>
> sctp_proc_exit(net);
> cleanup_sctp_mibs(net);
> + sctp_sysctl_net_unregister(net);
> }
>
> static struct pernet_operations sctp_net_ops = {
> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> index 2b2bfe9..7528d59 100644
> --- a/net/sctp/sysctl.c
> +++ b/net/sctp/sysctl.c
> @@ -284,6 +284,27 @@ static ctl_table sctp_table[] = {
> { /* sentinel */ }
> };
>
> +static ctl_table sctp_net_table[] = {
> + { /* sentinel */ }
> +};
> +
> +int sctp_sysctl_net_register(struct net *net)
> +{
> + struct ctl_table *table;
> +
> + table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
> + if (!table)
> + return -ENOMEM;
> +
> + net->sctp.sysctl_header = register_net_sysctl(net, "net/sctp", table);
> + return 0;
> +}
> +
> +void sctp_sysctl_net_unregister(struct net *net)
> +{
> + unregister_net_sysctl_table(net->sctp.sysctl_header);
> +}
> +
> static struct ctl_table_header * sctp_sysctl_header;
>
> /* Sysctl registration. */
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox