* Re: nonlocal_bind and IPv6
From: YOSHIFUJI Hideaki @ 2011-12-16 6:46 UTC (permalink / raw)
To: Vincent Bernat; +Cc: netdev, davem, YOSHIFUJI Hideaki
In-Reply-To: <1323879648-419-1-git-send-email-bernat@luffy.cx>
Have you tried to send packets from the application on node with
local_bind enabled (without the address the application binds)?
Vincent Bernat wrote:
> This is a second tentative to port ip_nonlocal_bind to IPv6. The two
> patches are independant. The first patch enables
> net.ipv6.ip_nonlocal_bind and is "namespace aware". The second patch
> modifies net.ipv4.ip_nonlocal_bind to also be "namespace aware". I
> don't know if this is something important.
>
> I did not test the SCTP part of the second patch (but it compiles).
>
> Documentation/networking/ip-sysctl.txt | 5 +++++
> include/net/netns/ipv4.h | 1 +
> include/net/netns/ipv6.h | 1 +
> net/ipv4/af_inet.c | 6 +-----
> net/ipv4/ping.c | 2 +-
> net/ipv4/sysctl_net_ipv4.c | 16 +++++++++-------
> net/ipv6/af_inet6.c | 6 ++++--
> net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
> net/sctp/protocol.c | 2 +-
> 9 files changed, 31 insertions(+), 16 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Takuya Yoshikawa @ 2011-12-16 7:05 UTC (permalink / raw)
To: zanghongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang, levinsasha928
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
(2011/12/16 14:32), zanghongyong@huawei.com wrote:
> From: Hongyong Zang<zanghongyong@huawei.com>
>
> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> address relationship in its member *kvm_memslots*, these patches use kernel's
> kvm_memslots directly without the need of initialization and maintenance of
> vhost_memory.
Isn't vhost independent from KVM?
Takuya
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 7:05 UTC (permalink / raw)
To: zanghongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
> From: Hongyong Zang <zanghongyong@huawei.com>
>
> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> address relationship in its member *kvm_memslots*, these patches use kernel's
> kvm_memslots directly without the need of initialization and maintenance of
> vhost_memory.
Conceptually, vhost isn't aware of KVM - it's just a driver which moves
data from vq to a tap device and back. You can't simply add KVM specific
code into vhost.
Whats the performance benefit?
--
Sasha.
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: David Miller @ 2011-12-16 7:06 UTC (permalink / raw)
To: bernat; +Cc: zenczykowski, netdev, yoshfuji
In-Reply-To: <m3zket9gqj.fsf@neo.luffy.cx>
From: Vincent Bernat <bernat@luffy.cx>
Date: Fri, 16 Dec 2011 07:24:04 +0100
> OoO En ce milieu de nuit étoilée du vendredi 16 décembre 2011, vers
> 04:58, Maciej Żenczykowski <zenczykowski@gmail.com> disait :
>
>> why not simply use the IP_TRANSPARENT or IP_FREEBIND socket options?
>
> Because this requires modifying each affected software. This can be
> difficult if you don't have the source code available.
But it means that it would work on every single kernel verion out
there.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2011-12-16 7:34 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel
In-Reply-To: <20111216120758.60f967a88c934890e77fa7bd@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Dec 2011 12:07:58 +1100
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv6/route.c between commit bb3c36863e80 ("ipv6: Check dest prefix
> length on original route not copied one in rt6_alloc_cow()") from the net
> tree and commit 3830847396fa ("ipv6: Various cleanups in route.c") from
> the net-next tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Yep, thanks, I just resolved this by merging net into net-next.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Zang Hongyong @ 2011-12-16 7:40 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, mst, kvm, virtualization, netdev, xiaowei.yang,
hanweidong, wusongwei
In-Reply-To: <1324019151.4496.9.camel@lappy>
于 2011/12/16,星期五 15:05, Sasha Levin 写道:
> On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
>> From: Hongyong Zang<zanghongyong@huawei.com>
>>
>> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
>> to translate GPA to HVA. Since kernel's kvm structure already maintains the
>> address relationship in its member *kvm_memslots*, these patches use kernel's
>> kvm_memslots directly without the need of initialization and maintenance of
>> vhost_memory.
> Conceptually, vhost isn't aware of KVM - it's just a driver which moves
> data from vq to a tap device and back. You can't simply add KVM specific
> code into vhost.
>
> Whats the performance benefit?
>
But vhost-net is only used in virtualization situation. vhost_memory is
maintained
by user space qemu.
In this way, the memory relationship can be accquired from kernel
without the
need of maintainence of vhost_memory from qemu.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 7:59 UTC (permalink / raw)
To: Zang Hongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <4EEAF5D1.2080805@huawei.com>
On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote:
> 于 2011/12/16,星期五 15:05, Sasha Levin 写道:
> > On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
> >> From: Hongyong Zang<zanghongyong@huawei.com>
> >>
> >> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> >> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> >> address relationship in its member *kvm_memslots*, these patches use kernel's
> >> kvm_memslots directly without the need of initialization and maintenance of
> >> vhost_memory.
> > Conceptually, vhost isn't aware of KVM - it's just a driver which moves
> > data from vq to a tap device and back. You can't simply add KVM specific
> > code into vhost.
> >
> > Whats the performance benefit?
> >
> But vhost-net is only used in virtualization situation. vhost_memory is
> maintained
> by user space qemu.
> In this way, the memory relationship can be accquired from kernel
> without the
> need of maintainence of vhost_memory from qemu.
You can't assume that vhost-* is used only along with qemu/kvm. Just as
virtio has more uses than just virtualization (heres one:
https://lkml.org/lkml/2011/10/25/139 ), there are more uses for vhost as
well.
There has been a great deal of effort to keep vhost and kvm untangled.
One example is the memory translation it has to do, another one is the
eventfd/irqfd thing it does just so it could signal an IRQ in the guest
instead of accessing the guest directly.
If you do see a great performance increase when tying vhost and KVM
together, it may be worth it to create some sort of an in-kernel
vhost-kvm bridging thing, but if the performance isn't noticeable we're
better off just leaving it as is and keeping the vhost code general.
--
Sasha.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 8:07 UTC (permalink / raw)
To: Zang Hongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324022358.4496.25.camel@lappy>
On Fri, 2011-12-16 at 09:59 +0200, Sasha Levin wrote:
> There has been a great deal of effort to keep vhost and kvm untangled.
> One example is the memory translation it has to do, another one is the
> eventfd/irqfd thing it does just so it could signal an IRQ in the guest
> instead of accessing the guest directly.
Actually, CONFIG_VHOST_NET doesn't even depend on CONFIG_KVM, so your
patch will break build when (CONFIG_VHOST_NET=y && CONFIG_KVM=n).
--
Sasha.
^ permalink raw reply
* Mr. Abdul Rahim Coulibay Assalamu Alaikum
From: Abdul Rahim Coulibaly @ 2011-12-16 8:08 UTC (permalink / raw)
Mr. Abdul Rahim Coulibay Assalamu Alaikum
My Dear Good Friend.
How are you and your family? Hope All is well. I am Mr. Abdul Rahim Coulibay
, the Regional Branch Manager with Islamic Development Bank Burkina
(ISDB-BF) Ouagadougou Burkina Faso. I got your contact from the
Burkina Faso chambers of commerce have some fund to claim in my bank
Which will be of benefit to both of us.
I want you to be an inheritor of this fund, the said fund is in a
Doormat account and with your bank information and my Documentation
certifies you as the inheritor/beneficiary Since I am an insider and
working in the same bank, the Transfer will be processed legally and
successfully and I will Be coming down to your country for
disbursement.
The amount of money involved is ($4.5m) which I want you to Claim for
further transfer out of the Country to your bank Account, all to our
financial benefit. This is very great opportunity as it will take a
maximum of 14 banking Working days to be concluded. I as an insider
will do my duties perfectly well concerning this transaction for
security reasons.
This is confidential for successful conclusion and hitch-free
transaction. Contact me immediately for further details and mutual
Relationship and we will decide together on how to disburse the funds
Yours truly.
Mr. Abdul Rahim Coulibay
Regional Branch Manager
Islamic Development Bank (ISDB)
Burkina Faso
^ permalink raw reply
* [PATCH net-next] sch_gred: prefer GFP_KERNEL allocations
From: Eric Dumazet @ 2011-12-16 8:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In control path, its better to use GFP_KERNEL allocations where
possible.
Before taking qdisc spinlock, we preallocate memory just in case we'll
need it in gred_change_vq()
This is a followup to commit 3f1e6d3fd37b (sch_gred: should not use
GFP_KERNEL while holding a spinlock)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_gred.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index 1b5e631..c9391ab 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -380,18 +380,19 @@ static inline int gred_change_table_def(struct Qdisc *sch, struct nlattr *dps)
static inline int gred_change_vq(struct Qdisc *sch, int dp,
struct tc_gred_qopt *ctl, int prio,
- u8 *stab, u32 max_P)
+ u8 *stab, u32 max_P,
+ struct gred_sched_data **prealloc)
{
struct gred_sched *table = qdisc_priv(sch);
- struct gred_sched_data *q;
+ struct gred_sched_data *q = table->tab[dp];
- if (table->tab[dp] == NULL) {
- table->tab[dp] = kzalloc(sizeof(*q), GFP_ATOMIC);
- if (table->tab[dp] == NULL)
+ if (!q) {
+ table->tab[dp] = q = *prealloc;
+ *prealloc = NULL;
+ if (!q)
return -ENOMEM;
}
- q = table->tab[dp];
q->DP = dp;
q->prio = prio;
q->limit = ctl->limit;
@@ -421,6 +422,7 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
int err, prio = GRED_DEF_PRIO;
u8 *stab;
u32 max_P;
+ struct gred_sched_data *prealloc;
if (opt == NULL)
return -EINVAL;
@@ -460,9 +462,10 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
prio = ctl->prio;
}
+ prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
sch_tree_lock(sch);
- err = gred_change_vq(sch, ctl->DP, ctl, prio, stab, max_P);
+ err = gred_change_vq(sch, ctl->DP, ctl, prio, stab, max_P, &prealloc);
if (err < 0)
goto errout_locked;
@@ -476,6 +479,7 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
errout_locked:
sch_tree_unlock(sch);
+ kfree(prealloc);
errout:
return err;
}
^ permalink raw reply related
* Re: v6: faster tree-based sysctl implementation
From: Eric W. Biederman @ 2011-12-16 8:15 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: linux-kernel, netdev, Octavian Purdila, David S . Miller,
Alexey Dobriyan, Damien Millescamps, Anca Emanuel,
Damien Millescamps, Benjamin LaHaise
In-Reply-To: <CAPLs8y9omncDbLE_KNoKOLLbfwHjWYUJX_i7cC4bLiJsyPbtZQ@mail.gmail.com>
Bringing this back on list because my reply is a design discussion and
that has every reason to be public.
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> writes:
> On Thu, Dec 8, 2011 at 2:19 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Which is my cue to say that I am behind the power curve in reviewing
> > this. I will see if I can get to this before the end of the week.
>
>
> Did you had time to take a look over the code?
Not as much time as I would have liked. However I have looked at it
some and I have brought back some of the state from my head so I
can remember where we last at in the conversation.
> I'm inclined to do a bit of redesign: currently files are kept in
> lists of files and sub-directories in a rbtree; I'd like to put
> everything in a rbtree and make things simpler.
I like the idea of putting everything in an rbtree. And
I like the idea of making things simpler.
> But I'd first like some sort of feedback from you. I wouldn't like to
> spend time working on something only to be told that the base idea of
> the reworking is unacceptable and everything needs to be rewritten.
As things stand I don't think your changes really solve the problem.
At least not if your change log can be believed.
> = New algorithm =
>
> == Time complexity ==
>
> - registration of N headers. Registration means adding new directories
> at each level or incrementing an existing directory's refcount.
>
> - O(N * lnN) - if the paths to the headers are evenly distributed
>
> - O(N^2) - if most of the headers registered are children of the
> same parent directory (searching the list of subdirs takes O(N)).
> There are cases where this happens (e.g. registering sysctl
> entries for net devices under /proc/sys/net/ipv4|6/conf/device).
This worries me because this is the case that we really care about.
> A few later patches will add an optimisation, to fix locations
> that might trigger the O(N^2) issue.
Is it your rb directory tree patch that addresses this?
....
My big concerns.
- I don't want to inflict churn on the users of sysctl unless we are
certain it will gain us something.
- I really would like to see the core become simple enough that
non-sysctl experts can look at the code and understand what is going
on.
It doesn't look like your design has achieved sufficient simplicity yet
so that a non sysctl expert can look the code and understand what is
going on and why.
....
There are two very worthwhile things I see us doing with this patchset.
- Moving the users of sysctl to full directory semantics.
- Improving the data structures so that the data structures are
efficient.
....
*** Moving the users of sysctl to full directory semantics. ***
As I have been watching the code sysctl has been moving from
a custom union filesystem (where each ctl_table was unioned
together) to normal filesystem semantics. The last hold out
for union semantics are directories.
The truly weird case in this is "/proc/sys/fs/binfmt_misc/" an empty
directory for mounting the "binfmt_misc" filesystem on.
Which means that fundamentally we need a way to create, remove and
represent empty directories. So while it is attractive to be lazy
and handle directories with some variant of lazy semantics creating
them when needed and deleting them when there is nothing left in the
directory I don't believe that will work.
Currently sysctl directories live under a relaxed version of the normal
fs rules:
- A directory must be created we can create children in it.
- A directory may not be deleted before we can remove children from it.
Since we in theory already have this strong property I don't see a
benefit of killing the sysctl .child table entry in the beginning of
the patchset. It means a lot of churn and a lot more code to review
without giving us more useful properties. Furthermore it retains the
clumsy ctl_path structure, which now that we don't need to add ctl_names
is a very clumsy structure to use. A normal pathname would be better.
So initially I think at most we want to enhance sysctl_check to verify
that we retain normal directory create and remove discipline with the
current sysctl users.
....
*** Improving the internal sysctl data structures ***
With that the simplest way I can see of dealing with the sysctl data
structures is simply replace our current internal kernel data structures
with something that we want to use, with a compatibility layer from
the current users of sysctl to what we want to see.
My guess is that we would like to have a data structure like:
struct proc_sysctl_dirent {
struct ctl_table *table; /* Point to the original ctl_table */
struct rb_node rb_node;
struct rb_root children;
atomic_t count;
};
That is not perfect but I think building a data structure like that
without changing the userspace interface might actually reduce the
line count of sysctl, and drastically reduce the challenge of
understanding the code.
In a perfect world we might even want to use proc_dir_entry for the
new data structure but that is probably more complication than it is
worth right now.
My biggest concern is how do we handle the duplication of directories
that comes with the network namespace? There are some weird things
in there.
....
Lucian is that anything like what you were thinking?
Does just improving the sysctl data structures and treating ctl_table
and it's kin as just a weird interface the callers use sound like it
might be a feasible path to you?
Eric
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Zang Hongyong @ 2011-12-16 8:18 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, mst, kvm, virtualization, netdev, xiaowei.yang,
hanweidong, wusongwei
In-Reply-To: <1324022358.4496.25.camel@lappy>
于 2011/12/16,星期五 15:59, Sasha Levin 写道:
> On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote:
>> 于 2011/12/16,星期五 15:05, Sasha Levin 写道:
>>> On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
>>>> From: Hongyong Zang<zanghongyong@huawei.com>
>>>>
>>>> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
>>>> to translate GPA to HVA. Since kernel's kvm structure already maintains the
>>>> address relationship in its member *kvm_memslots*, these patches use kernel's
>>>> kvm_memslots directly without the need of initialization and maintenance of
>>>> vhost_memory.
>>> Conceptually, vhost isn't aware of KVM - it's just a driver which moves
>>> data from vq to a tap device and back. You can't simply add KVM specific
>>> code into vhost.
>>>
>>> Whats the performance benefit?
>>>
>> But vhost-net is only used in virtualization situation. vhost_memory is
>> maintained
>> by user space qemu.
>> In this way, the memory relationship can be accquired from kernel
>> without the
>> need of maintainence of vhost_memory from qemu.
> You can't assume that vhost-* is used only along with qemu/kvm. Just as
> virtio has more uses than just virtualization (heres one:
> https://lkml.org/lkml/2011/10/25/139 ), there are more uses for vhost as
> well.
>
> There has been a great deal of effort to keep vhost and kvm untangled.
> One example is the memory translation it has to do, another one is the
> eventfd/irqfd thing it does just so it could signal an IRQ in the guest
> instead of accessing the guest directly.
>
> If you do see a great performance increase when tying vhost and KVM
> together, it may be worth it to create some sort of an in-kernel
> vhost-kvm bridging thing, but if the performance isn't noticeable we're
> better off just leaving it as is and keeping the vhost code general.
>
Thanks for your explanation.
Since memory layout is seldom changed after guest boots, the situation
manily occurs during initialization. There's no need for vhost-kvm
bridge now.
^ permalink raw reply
* Payment Update
From: Western Union Company @ 2011-12-16 7:44 UTC (permalink / raw)
Dear Beneficiary,
We are here to notify you that the sum of $250,000 U.S.Dollars was
generated and awarded to you by the Western Union Foundation in
conjunction with the African Union Foundation.This award was been selected
through the internet, where your e-mail address was indicated and
notified.The Western Union Foundation, All the email addresses of the
people that are active online,among the millions of our customers who use
Western Union in their business transactions.Four people are selected
Every year to benefit from this promotion and you are one of the Selected
Winners.
To avoid misappropriation of funds, proper verifications must be carried
out before the fund is transferred. We require the details below for
verification so that the transfer can be carried out.
1. Receiver's Full Name:
2. Receiver's Address:
3. Receiver's Country:
4. Receiver's Telephone Number:
5. Receiver's Occupation:
Send the above details to us via the email addresses stated below:
Western Union District Manager (Mr.Peter Parker)
Website: www.westernunion.com
E-mail: western-money@hotmail.com
Tel: +2347031908911
Note: You were selected as a winner on this promotion and I personally
advise that you use the funds wisely. However, we need your information as
stated above to commence the transaction due process:
Copyright © 2001-2011 The Western Union Company , All Rights Reserved.
^ permalink raw reply
* skb->priority usage in wireless frame classification
From: Helmut Schaa @ 2011-12-16 8:45 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-wireless, Johannes Berg
[Adding netdev]
Maybe someone from the netdev people can shed some light on this.
We've got the following code in net/wireless/util.c for frame classification
(cfg80211_classify8021d):
/* skb->priority values from 256->263 are magic values to
* directly indicate a specific 802.1d priority. This is used
* to allow 802.1d priority to be passed directly in from VLAN
* tags, etc.
*/
if (skb->priority >= 256 && skb->priority <= 263)
return skb->priority - 256;
I was just thinking about making use of this for some internal mac80211
QoS handling. But is this code still valid? At least I haven't found anything
in the 802.1q code :(
Thanks,
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] llc_cmsg_rcv was getting called after sk_eat_skb.
From: Alexandru Juncu @ 2011-12-16 9:01 UTC (permalink / raw)
To: acme, davem, netdev; +Cc: alex.juncu, Alexandru Juncu, Kunjan Naik
Received non stream protocol packets were calling llc_cmsg_rcv that used a
skb after that skb was released by sk_eat_skb. This caused received STP
packets to generate kernel panics.
Signed-off-by: Alexandru Juncu <ajuncu@ixiacom.com>
Signed-off-by: Kunjan Naik <knaik@ixiacom.com>
---
net/llc/af_llc.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index dfd3a64..a18e6c3 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -833,15 +833,15 @@ static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock,
copied += used;
len -= used;
+ /* For non stream protcols we get one packet per recvmsg call */
+ if (sk->sk_type != SOCK_STREAM)
+ goto copy_uaddr;
+
if (!(flags & MSG_PEEK)) {
sk_eat_skb(sk, skb, 0);
*seq = 0;
}
- /* For non stream protcols we get one packet per recvmsg call */
- if (sk->sk_type != SOCK_STREAM)
- goto copy_uaddr;
-
/* Partial read */
if (used + offset < skb->len)
continue;
@@ -857,6 +857,12 @@ copy_uaddr:
}
if (llc_sk(sk)->cmsg_flags)
llc_cmsg_rcv(msg, skb);
+
+ if (!(flags & MSG_PEEK)) {
+ sk_eat_skb(sk, skb, 0);
+ *seq = 0;
+ }
+
goto out;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2] net: fix sleeping while atomic problem in sock mem_cgroup.
From: Glauber Costa @ 2011-12-16 9:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, Glauber Costa, Stephen Rothwell,
Randy Dunlap
Since we can't scan the proto_list to initialize sock cgroups, as it
holds a rwlock, and we also want to keep the code generic enough to
avoid calling the initialization functions of protocols directly,
I propose we keep the interested parties in a separate list. This list
is protected by a mutex so we can sleep and do the necessary allocations.
Also fixes a reference problem found by Randy Dunlap's randconfig.
Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
CC: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
CC: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
---
include/linux/memcontrol.h | 11 ++++++-
include/net/sock.h | 5 +---
include/net/tcp_memcontrol.h | 2 +
mm/memcontrol.c | 58 ++++++++++++++++++++++++++++++++++++++++++
net/core/sock.c | 42 +++--------------------------
5 files changed, 75 insertions(+), 43 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 9b296ea..e61fabb 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -390,11 +390,13 @@ enum {
OVER_LIMIT,
};
-#ifdef CONFIG_INET
+struct proto;
struct sock;
#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
void sock_update_memcg(struct sock *sk);
void sock_release_memcg(struct sock *sk);
+void register_sock_cgroup(struct proto *prot);
+void unregister_sock_cgroup(struct proto *prot);
#else
static inline void sock_update_memcg(struct sock *sk)
{
@@ -402,7 +404,12 @@ static inline void sock_update_memcg(struct sock *sk)
static inline void sock_release_memcg(struct sock *sk)
{
}
+static inline void register_sock_cgroup(struct proto *prot)
+{
+}
+static inline void unregister_sock_cgroup(struct proto *prot)
+{
+}
#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
-#endif /* CONFIG_INET */
#endif /* _LINUX_MEMCONTROL_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 6fe0dae..f8237a3 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -64,10 +64,6 @@
#include <net/dst.h>
#include <net/checksum.h>
-struct cgroup;
-struct cgroup_subsys;
-int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss);
-void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss);
/*
* This structure really needs to be cleaned up.
* Most of it is for TCP, and not used by any of
@@ -858,6 +854,7 @@ struct proto {
void (*destroy_cgroup)(struct cgroup *cgrp,
struct cgroup_subsys *ss);
struct cg_proto *(*proto_cgroup)(struct mem_cgroup *memcg);
+ struct list_head cgroup_node;
#endif
};
diff --git a/include/net/tcp_memcontrol.h b/include/net/tcp_memcontrol.h
index 3512082..5aa7c4b 100644
--- a/include/net/tcp_memcontrol.h
+++ b/include/net/tcp_memcontrol.h
@@ -11,6 +11,8 @@ struct tcp_memcontrol {
int tcp_memory_pressure;
};
+struct cgroup;
+struct cgroup_subsys;
struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg);
int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
void tcp_destroy_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7266202..1098afe 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4742,6 +4742,64 @@ static struct cftype kmem_cgroup_files[] = {
},
};
+static DEFINE_MUTEX(cgroup_proto_list_lock);
+static LIST_HEAD(cgroup_proto_list);
+
+static int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
+{
+ struct proto *proto;
+ int ret = 0;
+
+ mutex_lock(&cgroup_proto_list_lock);
+ list_for_each_entry(proto, &cgroup_proto_list, cgroup_node) {
+ if (proto->init_cgroup) {
+ ret = proto->init_cgroup(cgrp, ss);
+ if (ret)
+ goto out;
+ }
+ }
+
+ mutex_unlock(&cgroup_proto_list_lock);
+ return ret;
+out:
+ list_for_each_entry_continue_reverse(proto, &cgroup_proto_list, cgroup_node)
+ if (proto->destroy_cgroup)
+ proto->destroy_cgroup(cgrp, ss);
+ mutex_unlock(&cgroup_proto_list_lock);
+ return ret;
+}
+
+static void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss)
+{
+ struct proto *proto;
+
+ mutex_lock(&cgroup_proto_list_lock);
+ list_for_each_entry_reverse(proto, &cgroup_proto_list, cgroup_node)
+ if (proto->destroy_cgroup)
+ proto->destroy_cgroup(cgrp, ss);
+ mutex_unlock(&cgroup_proto_list_lock);
+}
+
+void register_sock_cgroup(struct proto *prot)
+{
+ if (!prot->proto_cgroup)
+ return;
+
+ mutex_lock(&cgroup_proto_list_lock);
+ list_add(&prot->cgroup_node, &cgroup_proto_list);
+ mutex_unlock(&cgroup_proto_list_lock);
+}
+
+void unregister_sock_cgroup(struct proto *prot)
+{
+ if (!prot->proto_cgroup)
+ return;
+
+ mutex_lock(&cgroup_proto_list_lock);
+ list_del(&prot->cgroup_node);
+ mutex_unlock(&cgroup_proto_list_lock);
+}
+
static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
{
int ret = 0;
diff --git a/net/core/sock.c b/net/core/sock.c
index 5a6a906..5a56a55 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -139,43 +139,6 @@
static DEFINE_RWLOCK(proto_list_lock);
static LIST_HEAD(proto_list);
-#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
-int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
-{
- struct proto *proto;
- int ret = 0;
-
- read_lock(&proto_list_lock);
- list_for_each_entry(proto, &proto_list, node) {
- if (proto->init_cgroup) {
- ret = proto->init_cgroup(cgrp, ss);
- if (ret)
- goto out;
- }
- }
-
- read_unlock(&proto_list_lock);
- return ret;
-out:
- list_for_each_entry_continue_reverse(proto, &proto_list, node)
- if (proto->destroy_cgroup)
- proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
- return ret;
-}
-
-void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss)
-{
- struct proto *proto;
-
- read_lock(&proto_list_lock);
- list_for_each_entry_reverse(proto, &proto_list, node)
- if (proto->destroy_cgroup)
- proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
-}
-#endif
-
/*
* Each address family might have different locking rules, so we have
* one slock key per address family:
@@ -2483,6 +2446,9 @@ int proto_register(struct proto *prot, int alloc_slab)
list_add(&prot->node, &proto_list);
assign_proto_idx(prot);
write_unlock(&proto_list_lock);
+
+ register_sock_cgroup(prot);
+
return 0;
out_free_timewait_sock_slab_name:
@@ -2510,6 +2476,8 @@ void proto_unregister(struct proto *prot)
list_del(&prot->node);
write_unlock(&proto_list_lock);
+ unregister_sock_cgroup(prot);
+
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
prot->slab = NULL;
--
1.7.6.4
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] net: fix sleeping while atomic problem in sock mem_cgroup.
From: Eric Dumazet @ 2011-12-16 9:31 UTC (permalink / raw)
To: Glauber Costa
Cc: davem, linux-kernel, kamezawa.hiroyu, netdev, cgroups,
Stephen Rothwell, Randy Dunlap
In-Reply-To: <1324026582-5214-1-git-send-email-glommer@parallels.com>
Le vendredi 16 décembre 2011 à 13:09 +0400, Glauber Costa a écrit :
> Since we can't scan the proto_list to initialize sock cgroups, as it
> holds a rwlock, and we also want to keep the code generic enough to
> avoid calling the initialization functions of protocols directly,
> I propose we keep the interested parties in a separate list. This list
> is protected by a mutex so we can sleep and do the necessary allocations.
>
> Also fixes a reference problem found by Randy Dunlap's randconfig.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Randy Dunlap <rdunlap@xenotime.net>
> ---
Sorry to come late, but why dont we convert proto_list_lock to a mutex ?
net/core/sock.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5a6a906..0c67fac 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -136,7 +136,7 @@
#include <net/tcp.h>
#endif
-static DEFINE_RWLOCK(proto_list_lock);
+static DEFINE_MUTEX(proto_list_mutex);
static LIST_HEAD(proto_list);
#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
@@ -145,7 +145,7 @@ int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
struct proto *proto;
int ret = 0;
- read_lock(&proto_list_lock);
+ mutex_lock(&proto_list_mutex);
list_for_each_entry(proto, &proto_list, node) {
if (proto->init_cgroup) {
ret = proto->init_cgroup(cgrp, ss);
@@ -154,13 +154,13 @@ int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
}
}
- read_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
return ret;
out:
list_for_each_entry_continue_reverse(proto, &proto_list, node)
if (proto->destroy_cgroup)
proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
return ret;
}
@@ -168,11 +168,11 @@ void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss)
{
struct proto *proto;
- read_lock(&proto_list_lock);
+ mutex_lock(&proto_list_mutex);
list_for_each_entry_reverse(proto, &proto_list, node)
if (proto->destroy_cgroup)
proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
}
#endif
@@ -2479,10 +2479,10 @@ int proto_register(struct proto *prot, int alloc_slab)
}
}
- write_lock(&proto_list_lock);
+ mutex_lock(&proto_list_mutex);
list_add(&prot->node, &proto_list);
assign_proto_idx(prot);
- write_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
return 0;
out_free_timewait_sock_slab_name:
@@ -2505,10 +2505,10 @@ EXPORT_SYMBOL(proto_register);
void proto_unregister(struct proto *prot)
{
- write_lock(&proto_list_lock);
+ mutex_lock(&proto_list_mutex);
release_proto_idx(prot);
list_del(&prot->node);
- write_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
@@ -2531,9 +2531,9 @@ EXPORT_SYMBOL(proto_unregister);
#ifdef CONFIG_PROC_FS
static void *proto_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(proto_list_lock)
+ __acquires(proto_list_mutex)
{
- read_lock(&proto_list_lock);
+ mutex_lock(&proto_list_mutex);
return seq_list_start_head(&proto_list, *pos);
}
@@ -2543,9 +2543,9 @@ static void *proto_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void proto_seq_stop(struct seq_file *seq, void *v)
- __releases(proto_list_lock)
+ __releases(proto_list_mutex)
{
- read_unlock(&proto_list_lock);
+ mutex_unlock(&proto_list_mutex);
}
static char proto_method_implemented(const void *method)
^ permalink raw reply related
* Re: skb->priority usage in wireless frame classification
From: Dave Taht @ 2011-12-16 9:35 UTC (permalink / raw)
To: Helmut Schaa; +Cc: netdev, linux-wireless, Johannes Berg
In-Reply-To: <CAGXE3d_ouo4KzQA0-ysLz_RwcqoTc5Sg4V6BZZJP0TJewzNOxw@mail.gmail.com>
On Fri, Dec 16, 2011 at 9:45 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> [Adding netdev]
>
> Maybe someone from the netdev people can shed some light on this.
> We've got the following code in net/wireless/util.c for frame classification
> (cfg80211_classify8021d):
>
> /* skb->priority values from 256->263 are magic values to
> * directly indicate a specific 802.1d priority. This is used
> * to allow 802.1d priority to be passed directly in from VLAN
> * tags, etc.
> */
> if (skb->priority >= 256 && skb->priority <= 263)
> return skb->priority - 256;
>
> I was just thinking about making use of this for some internal mac80211
> QoS handling. But is this code still valid? At least I haven't found anything
> in the 802.1q code :(
I made use of the above 'feature' while prototyping some Diffserv work
with iptables. I have no idea if there are users of this obscure
overloading of priority in userspace....
The vlan code at least used to do something like this:
net/8021q/vlan.h: * @vlan_qos: vlan priority: (skb->priority << 13) & 0xE000
But I don't see that at first glance in the current code... this part
is functionally the same...
vlan_netlink.c: m.to = (pm->vlan_qos >> 13) & 0x7;
vlanproc.c: mp->priority, ((mp->vlan_qos >> 13) & 0x7));
Assuming that somewhere else was an assignment from priority to this...
> Thanks,
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: skb->priority usage in wireless frame classification
From: Helmut Schaa @ 2011-12-16 9:42 UTC (permalink / raw)
To: Dave Taht; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless, Johannes Berg
In-Reply-To: <CAA93jw4-OEbiSpQM+SJn7R0uAe0o-nw0kwgvjVkL4w4AeWQtjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 16, 2011 at 10:35 AM, Dave Taht <dave.taht-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Dec 16, 2011 at 9:45 AM, Helmut Schaa
> <helmut.schaa-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> [Adding netdev]
>>
>> Maybe someone from the netdev people can shed some light on this.
>> We've got the following code in net/wireless/util.c for frame classification
>> (cfg80211_classify8021d):
>>
>> /* skb->priority values from 256->263 are magic values to
>> * directly indicate a specific 802.1d priority. This is used
>> * to allow 802.1d priority to be passed directly in from VLAN
>> * tags, etc.
>> */
>> if (skb->priority >= 256 && skb->priority <= 263)
>> return skb->priority - 256;
>>
>> I was just thinking about making use of this for some internal mac80211
>> QoS handling. But is this code still valid? At least I haven't found anything
>> in the 802.1q code :(
>
> I made use of the above 'feature' while prototyping some Diffserv work
> with iptables. I have no idea if there are users of this obscure
> overloading of priority in userspace....
>
> The vlan code at least used to do something like this:
>
> net/8021q/vlan.h: * @vlan_qos: vlan priority: (skb->priority << 13) & 0xE000
Yeah, I saw that too but +256 would be << 8 and not << 13.
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: Vincent Bernat @ 2011-12-16 9:46 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, davem
In-Reply-To: <4EEAE94A.5050400@linux-ipv6.org>
On Fri, 16 Dec 2011 15:46:34 +0900, YOSHIFUJI Hideaki wrote:
> Have you tried to send packets from the application on node with
> local_bind enabled (without the address the application binds)?
No, I did not see any logic to handle this with IPv4. I will test it
and come back.
^ permalink raw reply
* Re: [PATCH v2] net: fix sleeping while atomic problem in sock mem_cgroup.
From: Glauber Costa @ 2011-12-16 9:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Stephen Rothwell, Randy Dunlap
In-Reply-To: <1324027869.2273.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 12/16/2011 01:31 PM, Eric Dumazet wrote:
> Le vendredi 16 décembre 2011 à 13:09 +0400, Glauber Costa a écrit :
>> Since we can't scan the proto_list to initialize sock cgroups, as it
>> holds a rwlock, and we also want to keep the code generic enough to
>> avoid calling the initialization functions of protocols directly,
>> I propose we keep the interested parties in a separate list. This list
>> is protected by a mutex so we can sleep and do the necessary allocations.
>>
>> Also fixes a reference problem found by Randy Dunlap's randconfig.
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>> CC: David S. Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> CC: Eric Dumazet<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> CC: Stephen Rothwell<sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
>> CC: Randy Dunlap<rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
>> ---
>
> Sorry to come late, but why dont we convert proto_list_lock to a mutex ?
I didn't suggest this, as I imagined there could be some performance
implications to be drawn from it that may not be obvious to me.
But if it is okay with you net guys, it is certainly okay with me as well.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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: skb->priority usage in wireless frame classification
From: Dave Taht @ 2011-12-16 9:53 UTC (permalink / raw)
To: Helmut Schaa; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless, Johannes Berg
In-Reply-To: <CAGXE3d_=OA+EvX8Q=gELDHSESAQpgt_EavTWGTNLYMnjURLJWw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 16, 2011 at 10:42 AM, Helmut Schaa
<helmut.schaa-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Fri, Dec 16, 2011 at 10:35 AM, Dave Taht <dave.taht-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Dec 16, 2011 at 9:45 AM, Helmut Schaa
>> <helmut.schaa-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>>> [Adding netdev]
>>>
>>> Maybe someone from the netdev people can shed some light on this.
>>> We've got the following code in net/wireless/util.c for frame classification
>>> (cfg80211_classify8021d):
>>>
>>> /* skb->priority values from 256->263 are magic values to
>>> * directly indicate a specific 802.1d priority. This is used
>>> * to allow 802.1d priority to be passed directly in from VLAN
>>> * tags, etc.
>>> */
>>> if (skb->priority >= 256 && skb->priority <= 263)
>>> return skb->priority - 256;
>>>
>>> I was just thinking about making use of this for some internal mac80211
>>> QoS handling. But is this code still valid? At least I haven't found anything
>>> in the 802.1q code :(
>>
>> I made use of the above 'feature' while prototyping some Diffserv work
>> with iptables. I have no idea if there are users of this obscure
>> overloading of priority in userspace....
>>
>> The vlan code at least used to do something like this:
>>
>> net/8021q/vlan.h: * @vlan_qos: vlan priority: (skb->priority << 13) & 0xE000
>
> Yeah, I saw that too but +256 would be << 8 and not << 13.
Exactly. It's why I used the word 'overload'. Someone in the distant
past saw >> 8 was 'reserved', and figured >> 13 was a safe place to
stick some valuable bits...
or vice versa.
> Helmut
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: Vincent Bernat @ 2011-12-16 9:53 UTC (permalink / raw)
To: David Miller; +Cc: zenczykowski, netdev, yoshfuji
In-Reply-To: <20111216.020600.1695776769736304587.davem@davemloft.net>
On Fri, 16 Dec 2011 02:06:00 -0500 (EST), David Miller wrote:
>> OoO En ce milieu de nuit étoilée du vendredi 16 décembre 2011,
>> vers
>> 04:58, Maciej Żenczykowski <zenczykowski@gmail.com> disait :
>>
>>> why not simply use the IP_TRANSPARENT or IP_FREEBIND socket
>>> options?
>>
>> Because this requires modifying each affected software. This
>> can be
>> difficult if you don't have the source code available.
>
> But it means that it would work on every single kernel verion out
> there.
Sure. But... The typical scenario for this setting is when you are
using something like VRRP. You have your web server running on several
nodes and only one of them has the appropriate IP address at the given
moment. Moreover, you have to bind to specific IP and not 0.0.0.0 for
other reasons (for example, when using several SSL virtualhosts).
Starting the web server only when a node gets the appropriate IP is not
possible because it increases downtime. Since this VRRP stuff is related
to system configuration, it seems sensible to have a system setting
equivalent to IP_FREEBIND socket options. This is ip_nonlocal_bind.
Moreover, I am just adding the IPv6 version of this setting. The IPv4
version already exists.
^ permalink raw reply
* Re: [PATCH v2] net: fix sleeping while atomic problem in sock mem_cgroup.
From: Eric Dumazet @ 2011-12-16 10:04 UTC (permalink / raw)
To: Glauber Costa
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Stephen Rothwell, Randy Dunlap
In-Reply-To: <4EEB1508.3080405-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Le vendredi 16 décembre 2011 à 13:53 +0400, Glauber Costa a écrit :
> On 12/16/2011 01:31 PM, Eric Dumazet wrote:
> > Le vendredi 16 décembre 2011 à 13:09 +0400, Glauber Costa a écrit :
> >> Since we can't scan the proto_list to initialize sock cgroups, as it
> >> holds a rwlock, and we also want to keep the code generic enough to
> >> avoid calling the initialization functions of protocols directly,
> >> I propose we keep the interested parties in a separate list. This list
> >> is protected by a mutex so we can sleep and do the necessary allocations.
> >>
> >> Also fixes a reference problem found by Randy Dunlap's randconfig.
> >>
> >> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> >> CC: Hiroyouki Kamezawa<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> >> CC: David S. Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> >> CC: Eric Dumazet<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> CC: Stephen Rothwell<sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> >> CC: Randy Dunlap<rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
> >> ---
> >
> > Sorry to come late, but why dont we convert proto_list_lock to a mutex ?
>
> I didn't suggest this, as I imagined there could be some performance
> implications to be drawn from it that may not be obvious to me.
>
> But if it is okay with you net guys, it is certainly okay with me as well.
This 'lock' is not performance sensitive, its very seldom taken.
If we really wanted to be fast, it would not be a rwlock anymore ;)
"cat /proc/net/protocols" could eventually use RCU locking if we want
parallelism. (I dont think its needed)
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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] net: fix sleeping while atomic problem in sock mem_cgroup.
From: Glauber Costa @ 2011-12-16 10:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Stephen Rothwell, Randy Dunlap
In-Reply-To: <1324029886.2273.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 12/16/2011 02:04 PM, Eric Dumazet wrote:
> Le vendredi 16 décembre 2011 à 13:53 +0400, Glauber Costa a écrit :
>> On 12/16/2011 01:31 PM, Eric Dumazet wrote:
>>> Le vendredi 16 décembre 2011 à 13:09 +0400, Glauber Costa a écrit :
>>>> Since we can't scan the proto_list to initialize sock cgroups, as it
>>>> holds a rwlock, and we also want to keep the code generic enough to
>>>> avoid calling the initialization functions of protocols directly,
>>>> I propose we keep the interested parties in a separate list. This list
>>>> is protected by a mutex so we can sleep and do the necessary allocations.
>>>>
>>>> Also fixes a reference problem found by Randy Dunlap's randconfig.
>>>>
>>>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>>>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>> CC: David S. Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>>>> CC: Eric Dumazet<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> CC: Stephen Rothwell<sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
>>>> CC: Randy Dunlap<rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
>>>> ---
>>>
>>> Sorry to come late, but why dont we convert proto_list_lock to a mutex ?
>>
>> I didn't suggest this, as I imagined there could be some performance
>> implications to be drawn from it that may not be obvious to me.
>>
>> But if it is okay with you net guys, it is certainly okay with me as well.
>
> This 'lock' is not performance sensitive, its very seldom taken.
>
> If we really wanted to be fast, it would not be a rwlock anymore ;)
>
> "cat /proc/net/protocols" could eventually use RCU locking if we want
> parallelism. (I dont think its needed)
>
Well, in this case, I myself think this is a better solution. Do you
want to push the patch yourself, or should I do it ?
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox