* Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
From: Jason Gunthorpe @ 2012-03-22 22:44 UTC (permalink / raw)
To: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA
Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA,
roland-BHEL68pLQRGGvPXPguhicg, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3ae9829d-f8dd-4268-918a-94616eff0915-nbYkmrCdWxmgMrCBcu8zE0EOCMrvLtNR@public.gmane.org>
On Thu, Mar 22, 2012 at 02:20:28PM -0700, Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org wrote:
> I got a question here lately.
>
> aligned directive will ensure that it will fall on boundary. Say
> aligned(4) ensures that structure is aligned to 4 byte boundary.
> Compiler can (at least theoretically) still have 4 byte structure
> aligned to 8 byte boundary on 64-bit platform (which is 4 byte
> aligned too).
There are very specific rules defined in the platform's ABI for how C
structures are layed out in memory, each ABI (ie CPU) has its own
specific quirks, but broadly in Linux land you can boil it down to:
1) The alignment of a structure is the greatest alignment of all the
members
2) Each member is aligned to its alignment.
The alignment of the structure drives the total size of the structure,
and specifically the padding added at the end to reach that alignment.
So, no, a compiler that increased the alignment of a struct with one
u32 to 8 would violate the various ABIs and not be usuable for
Linux. It is important to bear in mind that Linux targets a particular
set of ABI conventions, and it is not 'anything goes'.
> struct {
> u32 field;
> };
So in this case: the u32 is aligned to 4, the structure is aligned to
4 and the total size of the structure is 4 on everything linux
supports.
> struct {
> u64 fielda
> u32 field;
> };
In this case: On 64 bit: the u64 is aligned to 8 and the u32 is aligned to 4. So
the structure is aligned to 8. A pad is inserted at the end of the
struct to bring it out. On 32 bit, the u64 is aligned to 4, so the
struct is aligned to 4, so no pad is added.
> struct {
> __float128 fielda
> u32 field;
> };
In this case the float128 is aligned to 16 and thus the structure is
aligned to 16 and 12 pad bytes are added.
> However requirement is to have this structure only 4 byte size(
> because adapter excepts it to be 4B sise) and therefor packed is
> used. I don't know the way to ensure size of 4 byte and alignment
> too. Or I am misunderstanding?
Yes, you are mis-understanding the rules for padding.. Structures are
only padded out to their alignment, which depends on their constituent
types. This is so arrays of structures have each array element
starting on its natural alignment.
The aligned attribute overrides the automatic determination of the
alignment based on the contents and just forces it.
So, as an example, if you have this hardware layout:
struct {
u32 fielda;
u64 fieldb;
} attribute ((aligned(4));
David is saying you will get a 12 byte struct and fieldb will be
unaligned. Since 12 is aligned to 4 no padding is added.
For hardware facing structures I'd combine this with a static assert
to verify structure size at compile time.
So..
1) Avoid using attributes unless the structure has unaligned members.
2) Avoid creating structures with unaligned members (eg for userspace
communication)
3) Frown at hardware/firmware developers who make communication
structures with unaligned members :)
4) Be explicit about padding in your layout for 64/32
compatibility.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* السلام عليكم
From: hana muammar gaddafi. @ 2012-03-22 22:06 UTC (permalink / raw)
السلام عليكم ورحمة الله , اسمى هانا معمر القذافى
من تريبولى ,ليبيا رقم 19 باب العزايزة, بمنطقة مارى فيتزجيرالد , تريبولى ,
ليبيا .
خدمت كدكتورة بوزارة الصحة الليبية.
وقت الولايات المتحدة ضربت منطقة سكنا الخاص باسم القذافى بباب العزايزة فى
14 ابريل 1986 انتقاما لما حدث بتفجير الملهى الليلى لابيلا بمدينة برلين عن
يد ليبيين متل ماقالوا . وانجرحت انا بهدا الحادث ومشان هاك ابويا حفظ هويتى
سريا , وقبل وفاة والدى وقبل ان تتجمد حساباته بالبنوك قبل بداية الثورة
الليبية قد حول 32.4 مليون يورو من بنك بسويسرا من خلال شركة تامين خاضعة
لمكتب الامم المتحدة بليبيا لعقد لمشاريع انابيب الغاز والزيت ...
الوضع بليبيا كان مهين وكان مهزلة كبيرة وقت حدث كل ماحصل, وكان وضعنا خطير
جدا ومعرضين للاذى باى وقت وخاصة وقت تحول الوضع الى حرب اهلية بين المدن
بليبيا , وغرضى من تواصلى معك وارسال هدى الرسالة لك وشرح الوضع كله هو انى
اريد مساعدتك بوضعى , اريد مساعدتك فى استثمار هده الاموال وتكون شريكى بكل
شىء وتكون ايضا مدير لاستثماراتى وكل شىء , وتساعدنى بشراء بيت فى بلدك
وتحريرى مما اعانيه هنا , محتاجة الخروج من هنا باقرب فرصة ,انا موجودة توى
بالكامب الكاريبى فى ميامى بامريكا , ومابودى العيشة هنا , ساعدنى بالخروج من
هنا والعيشة بامان وسلام .. انا محتاجة فقط رجل اعمال عربى يساعدنى بهدا
الموضوع , فارجوك اذا بتقدر تساعدنى ارجوك رد على رسالتى وارسلى اسمك كاملا
ورقم جوالك وان شاء الله انا بتواصل معك بالايميل وبتصل بك ايضا وبشرحلك كل
شىء بدك تعرفه باذن الله ...
برعاية الله وبانتظار ردك
^ permalink raw reply
* Re: [PATCH] sky2: override for PCI legacy power management
From: Knut Petersen @ 2012-03-22 22:36 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Stephen Hemminger, David S. Miller, Linus Torvalds, arekm, Jared,
dilieto, linux-kernel, netdev
In-Reply-To: <CAErSpo67PEaZ6JuMUntWLfR8SUpQgZERD_cKV6rWd=FF0tZ6DQ@mail.gmail.com>
Am 21.03.2012 21:22, schrieb Bjorn Helgaas:
> It looks like this requires a user to figure out that he might be suffering from this problem, then use this module parameter to work around it. How would a user figure that out? Can we do it automatically to save him the trouble?
It´s easy to dmi_match() known broken systems - I have dmidecode outputs of four systems that definitely need the patch.
Two ASUSTek P5* mainboards with AMI BIOSes, two AOpen i915G* mainboards with Award/Phoenix BIOSes.
cu,
Knut
^ permalink raw reply
* Re: long-lived tcp connection question
From: Eric Dumazet @ 2012-03-22 22:29 UTC (permalink / raw)
To: Josh Hunt; +Cc: Hagen Paul Pfeifer, netdev
In-Reply-To: <CAKA=qzZ7K6gGJ88NR83nm1vNnRWiuwN-MbEVzeSRpuok7j2vTQ@mail.gmail.com>
On Thu, 2012-03-22 at 17:27 -0500, Josh Hunt wrote:
> On Thu, Mar 22, 2012 at 4:51 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> > * Josh Hunt | 2012-03-22 11:56:19 [-0500]:
> >
> >>Given things like web sockets with presumably long-lived persistent
> >>tcp connections and a sparse amount of data, I was wondering if there
> >>are currently any mechanisms in the kernel or out of tree projects
> >>which work on reducing the overhead these connections require?
> >>Possibly storing their state after a certain period of inactivity and
> >>then reviving them when work needs to be done? I'm thinking something
> >>along the lines of the state info stored for time-wait sockets and
> >>then the ability to resurrect it on an incoming packet. Keeping
> >>resources around for such connections seems inefficient although
> >>possibly unavoidable.
> >
> > Do you referring to something like this:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/
> >
> > The Linux code is not released yet, but I know that the required storage
> > overhead is small. Search the IETF email archive for more background
> > information about the topic.
> >
> > Hagen
> >
>
> No, this deals more with the overhead of establishing a connection.
> I'm asking more about the overhead associated with holding on to
> long-lived connections which may not be doing much.
>
So what are the actual numbers for this overhead per socket ?
^ permalink raw reply
* Re: long-lived tcp connection question
From: Josh Hunt @ 2012-03-22 22:27 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev
In-Reply-To: <20120322215150.GB3093@nuttenaction>
On Thu, Mar 22, 2012 at 4:51 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * Josh Hunt | 2012-03-22 11:56:19 [-0500]:
>
>>Given things like web sockets with presumably long-lived persistent
>>tcp connections and a sparse amount of data, I was wondering if there
>>are currently any mechanisms in the kernel or out of tree projects
>>which work on reducing the overhead these connections require?
>>Possibly storing their state after a certain period of inactivity and
>>then reviving them when work needs to be done? I'm thinking something
>>along the lines of the state info stored for time-wait sockets and
>>then the ability to resurrect it on an incoming packet. Keeping
>>resources around for such connections seems inefficient although
>>possibly unavoidable.
>
> Do you referring to something like this:
>
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/
>
> The Linux code is not released yet, but I know that the required storage
> overhead is small. Search the IETF email archive for more background
> information about the topic.
>
> Hagen
>
No, this deals more with the overhead of establishing a connection.
I'm asking more about the overhead associated with holding on to
long-lived connections which may not be doing much.
--
Josh
^ permalink raw reply
* [PATCH] netfilter: remove forward module param confusion.
From: Rusty Russell @ 2012-03-22 22:27 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, netfilter-devel
In-Reply-To: <8762dw9to2.fsf@rustcorp.com.au>
It used to be an int, and it got changed to a bool parameter at least
7 years ago. It happens that NF_ACCEPT and NF_DROP are 0 and 1, so
this works, but it's unclear, and the check that it's in range is not
required.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
net/ipv4/netfilter/iptable_filter.c | 9 ++-------
net/ipv6/netfilter/ip6table_filter.c | 9 ++-------
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/net/ipv4/netfilter/iptable_filter.c b/net/ipv4/netfilter/iptable_filter.c
--- a/net/ipv4/netfilter/iptable_filter.c
+++ b/net/ipv4/netfilter/iptable_filter.c
@@ -52,7 +52,7 @@ iptable_filter_hook(unsigned int hook, s
static struct nf_hook_ops *filter_ops __read_mostly;
/* Default to forward because I got too much mail already. */
-static bool forward = NF_ACCEPT;
+static bool forward = true;
module_param(forward, bool, 0000);
static int __net_init iptable_filter_net_init(struct net *net)
@@ -64,7 +64,7 @@ static int __net_init iptable_filter_net
return -ENOMEM;
/* Entry 1 is the FORWARD hook */
((struct ipt_standard *)repl->entries)[1].target.verdict =
- -forward - 1;
+ forward ? -NF_ACCEPT - 1 : -NF_DROP - 1;
net->ipv4.iptable_filter =
ipt_register_table(net, &packet_filter, repl);
@@ -88,11 +88,6 @@ static int __init iptable_filter_init(vo
{
int ret;
- if (forward < 0 || forward > NF_MAX_VERDICT) {
- pr_err("iptables forward must be 0 or 1\n");
- return -EINVAL;
- }
-
ret = register_pernet_subsys(&iptable_filter_net_ops);
if (ret < 0)
return ret;
diff --git a/net/ipv6/netfilter/ip6table_filter.c b/net/ipv6/netfilter/ip6table_filter.c
--- a/net/ipv6/netfilter/ip6table_filter.c
+++ b/net/ipv6/netfilter/ip6table_filter.c
@@ -44,7 +44,7 @@ ip6table_filter_hook(unsigned int hook,
static struct nf_hook_ops *filter_ops __read_mostly;
/* Default to forward because I got too much mail already. */
-static bool forward = NF_ACCEPT;
+static bool forward = true;
module_param(forward, bool, 0000);
static int __net_init ip6table_filter_net_init(struct net *net)
@@ -56,7 +56,7 @@ static int __net_init ip6table_filter_ne
return -ENOMEM;
/* Entry 1 is the FORWARD hook */
((struct ip6t_standard *)repl->entries)[1].target.verdict =
- -forward - 1;
+ forward ? -NF_ACCEPT - 1 : -NF_DROP - 1;
net->ipv6.ip6table_filter =
ip6t_register_table(net, &packet_filter, repl);
@@ -80,11 +80,6 @@ static int __init ip6table_filter_init(v
{
int ret;
- if (forward < 0 || forward > NF_MAX_VERDICT) {
- pr_err("iptables forward must be 0 or 1\n");
- return -EINVAL;
- }
-
ret = register_pernet_subsys(&ip6table_filter_net_ops);
if (ret < 0)
return ret;
--
How could I marry someone with more hair than me? http://baldalex.org
^ permalink raw reply
* [PATCH] net: NETDEV_ALIGN should match L1_CACHE_BYTES
From: Eric Dumazet @ 2012-03-22 22:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
32 bytes alignment had a meaning 10 years ago, it is not anymore the
case.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netdevice.h | 2 +-
net/802/fc.c | 2 +-
net/802/fddi.c | 2 +-
net/802/hippi.c | 2 +-
net/802/tr.c | 2 +-
net/appletalk/dev.c | 2 +-
net/core/dev.c | 4 ++--
net/ethernet/eth.c | 2 +-
net/mac80211/main.c | 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8debe29..bbd1906 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1302,7 +1302,7 @@ struct net_device {
};
#define to_net_dev(d) container_of(d, struct net_device, dev)
-#define NETDEV_ALIGN 32
+#define NETDEV_ALIGN L1_CACHE_BYTES
static inline
int netdev_get_prio_tc_map(const struct net_device *dev, u32 prio)
diff --git a/net/802/fc.c b/net/802/fc.c
index bd345f3..a7e0b87 100644
--- a/net/802/fc.c
+++ b/net/802/fc.c
@@ -122,7 +122,7 @@ static void fc_setup(struct net_device *dev)
* Fill in the fields of the device structure with fibre channel-generic values.
*
* Constructs a new net device, complete with a private data area of
- * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * size @sizeof_priv. A cache line alignment is enforced for
* this private data area.
*/
struct net_device *alloc_fcdev(int sizeof_priv)
diff --git a/net/802/fddi.c b/net/802/fddi.c
index 94b3ad0..16cd2c3 100644
--- a/net/802/fddi.c
+++ b/net/802/fddi.c
@@ -203,7 +203,7 @@ static void fddi_setup(struct net_device *dev)
* Fill in the fields of the device structure with FDDI-generic values.
*
* Constructs a new net device, complete with a private data area of
- * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * size @sizeof_priv. A cache line alignment is enforced for
* this private data area.
*/
struct net_device *alloc_fddidev(int sizeof_priv)
diff --git a/net/802/hippi.c b/net/802/hippi.c
index 91aca87..cdae3ed 100644
--- a/net/802/hippi.c
+++ b/net/802/hippi.c
@@ -223,7 +223,7 @@ static void hippi_setup(struct net_device *dev)
* Fill in the fields of the device structure with HIPPI-generic values.
*
* Constructs a new net device, complete with a private data area of
- * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * size @sizeof_priv. A cache line alignment is enforced for
* this private data area.
*/
diff --git a/net/802/tr.c b/net/802/tr.c
index 5e20cf8..ce6e6c9 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -625,7 +625,7 @@ static void tr_setup(struct net_device *dev)
* Fill in the fields of the device structure with token ring-generic values.
*
* Constructs a new net device, complete with a private data area of
- * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * size @sizeof_priv. A cache line alignment is enforced for
* this private data area.
*/
struct net_device *alloc_trdev(int sizeof_priv)
diff --git a/net/appletalk/dev.c b/net/appletalk/dev.c
index 6c8016f..2b71a45 100644
--- a/net/appletalk/dev.c
+++ b/net/appletalk/dev.c
@@ -33,7 +33,7 @@ static void ltalk_setup(struct net_device *dev)
* values. Basically does everything except registering the device.
*
* Constructs a new net device, complete with a private data area of
- * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * size @sizeof_priv. A cache line alignment is enforced for
* this private data area.
*/
diff --git a/net/core/dev.c b/net/core/dev.c
index 0f3eb7d..2e283fa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5935,11 +5935,11 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
alloc_size = sizeof(struct net_device);
if (sizeof_priv) {
- /* ensure 32-byte alignment of private area */
+ /* ensure cache line alignment of private area */
alloc_size = ALIGN(alloc_size, NETDEV_ALIGN);
alloc_size += sizeof_priv;
}
- /* ensure 32-byte alignment of whole construct */
+ /* ensure cache line alignment of whole construct */
alloc_size += NETDEV_ALIGN - 1;
p = kzalloc(alloc_size, GFP_KERNEL);
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index a93af86..4d4ec12 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -360,7 +360,7 @@ EXPORT_SYMBOL(ether_setup);
* values. Basically does everything except registering the device.
*
* Constructs a new net device, complete with a private data area of
- * size (sizeof_priv). A 32-byte (not bit) alignment is enforced for
+ * size (sizeof_priv). A cache line alignment is enforced for
* this private data area.
*/
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b581a24..29c5b29 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -530,7 +530,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
if (WARN_ON(ops->sta_state && (ops->sta_add || ops->sta_remove)))
return NULL;
- /* Ensure 32-byte alignment of our private data and hw private data.
+ /* Ensure cache line alignment of our private data and hw private data.
* We use the wiphy priv data for both our ieee80211_local and for
* the driver's private data
*
^ permalink raw reply related
* Re: [PULL] vhost-net/virtio: fixes for 3.4
From: Michael S. Tsirkin @ 2012-03-22 22:12 UTC (permalink / raw)
To: David Miller
Cc: kvm, virtualization, netdev, linux-kernel, levinsasha928, nyh,
nyh
In-Reply-To: <20120322.165649.32205268396882350.davem@davemloft.net>
On Thu, Mar 22, 2012 at 04:56:49PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Thu, 22 Mar 2012 10:27:19 +0200
>
> > On Tue, Mar 20, 2012 at 04:50:41PM +0200, Michael S. Tsirkin wrote:
> >> The following changes since commit 5ffca28a4ac7abb8a254fafe6bd03b2f83667df7:
> >>
> >> Merge git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs (2012-02-27 07:59:33 -0800)
> >>
> >> are available in the git repository at:
> >>
> >> ra.kernel.org:/pub/scm/linux/kernel/git/mst/vhost.git for_davem
> >>
> >> (ssh url as git.kernel.org seems down at the moment, when it comes up
> >> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for_davem
> >> should be the equivalent).
>
> Neither of these URL's work for me:
>
> [davem@drr net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for_davem
> fatal: Couldn't find remote ref for_davem
> [davem@drr net]$ git pull ra.kernel.org:/pub/scm/linux/kernel/git/mst/vhost.git for_davem
> Enter passphrase for key '/home/davem/.ssh/davem':
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
> [davem@drr net]$
>
> If you're sending me signed pull requests that thus require a newer
> version of GIT, please don't.
OK, sorry about that. Can't fix right now as I'm not at
the box that has the key but this works for me with an old git:
/usr/bin/git fetch git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git refs/tags/for_davem
You just don't get the signature checked.
--
MST
^ permalink raw reply
* re: module_param: make bool parameters really bool (net & drivers/net)
From: Rusty Russell @ 2012-03-22 22:07 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, netfilter-devel
In-Reply-To: <20120322182623.GA29859@elgon.mountain>
On Thu, 22 Mar 2012 21:26:23 +0300, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Hi Rusty,
>
> The patch eb93992207da: "module_param: make bool parameters really
> bool (net & drivers/net)" from Dec 19, 2011, leads to the following
> warning:
> net/ipv4/netfilter/iptable_filter.c:90 iptable_filter_init()
> warn: 5 is more than 1 (max 'forward' can be) so this is
> always the same.
>
> It's declared like this:
>
> 54 /* Default to forward because I got too much mail already. */
> 55 static bool forward = NF_ACCEPT;
> 56 module_param(forward, bool, 0000);
>
>
> It's used like this:
> 66 ((struct ipt_standard *)repl->entries)[1].target.verdict = -forward - 1;
>
> Smatch complains when check that it's larger than 5.
>
> 90 if (forward < 0 || forward > NF_MAX_VERDICT) {
> 91 pr_err("iptables forward must be 0 or 1\n");
> 92 return -EINVAL;
> 93 }
Thanks Dan!
This was obviously initially an arbitrary value, but someone
made it a bool module parameter (me?). It works for accept and drop, so
let's make it official. Patch coming.
Thanks,
Rusty.
--
How could I marry someone with more hair than me? http://baldalex.org
^ permalink raw reply
* Re: long-lived tcp connection question
From: Hagen Paul Pfeifer @ 2012-03-22 21:51 UTC (permalink / raw)
To: Josh Hunt; +Cc: netdev
In-Reply-To: <CAKA=qzaPwx53ExK7VhNC_sbv3tVZrnWXv-5Fh8akcZ6DEaqd9Q@mail.gmail.com>
* Josh Hunt | 2012-03-22 11:56:19 [-0500]:
>Given things like web sockets with presumably long-lived persistent
>tcp connections and a sparse amount of data, I was wondering if there
>are currently any mechanisms in the kernel or out of tree projects
>which work on reducing the overhead these connections require?
>Possibly storing their state after a certain period of inactivity and
>then reviving them when work needs to be done? I'm thinking something
>along the lines of the state info stored for time-wait sockets and
>then the ability to resurrect it on an incoming packet. Keeping
>resources around for such connections seems inefficient although
>possibly unavoidable.
Do you referring to something like this:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/
The Linux code is not released yet, but I know that the required storage
overhead is small. Search the IETF email archive for more background
information about the topic.
Hagen
^ permalink raw reply
* RE: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: Keller, Jacob E @ 2012-03-22 21:59 UTC (permalink / raw)
To: Richard Cochran
Cc: chetan loke, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Kirsher, Jeffrey T,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <20120322070900.GD2182@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Thursday, March 22, 2012 12:09 AM
> To: Keller, Jacob E
> Cc: chetan loke; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
> Kirsher, Jeffrey T; Ronciak, John; john.stultz@linaro.org; tglx@linutronix.de
> Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
> timecompare method
>
> On Wed, Mar 21, 2012 at 05:06:09PM +0000, Keller, Jacob E wrote:
> >
> > I agree with Chetan. I think it would be best to make sure the correct
> > form of locking is done, as we are providing an interface to the user.
> > Using a seqlock would allow for preventing the ioctls from blocking
> > the hardware timestamp code.
>
> Okay, you can improve the time stamping path in the driver to avoid contending
> with callers to clock_gettime. But that will not help the hundreds of
> clock_gettime callers from contending with each other.
>
Seqlocks don't block when reading. The way they work is with a sequence number. When a reader wants to perform a read, it atomically records the sequence number. Then it performs the operation it wants (which can't have *any* side effects. It needs to be read only on the data). After finishing, it checks to see if the sequence number has increased. If so, it repeats the process until the sequence number stays the same.
Writers work like normal spin locks but increase a sequence number whenever they start work.
This means that readers don't block at all, and as long as the readers don't conflict with each other, there is no contention or writer starvation. It is possible for readers to 'live' lock, due to a large number of write operations. However, the lock is designed for few-writers, many readers. Which is what we have.
> > It's a fairly simple change for the gettime function (the most likely
> > culprit to be hammered) by changing it to use timecounter_cyc2time
> > function instead of timecounter_read. (as long as timecounter_read is
> > called at least every 1/2 the system time overflow, which it should be
> > due to the work task.)
> >
> > With that change, then the section use a seqlock (along with the
> > section for checking hardware timestamps). Other places would do the
> > full write lock.
>
> So, you think that clock_gettime should not read the card's time registers?
>
You can have it read the register value directly and use timecounter_cyc2time to convert that value into ns since the epoch. This works because you are already using timecounter_read during the worktask which should be running at least as often as half the counter wraparound time. Timecounter_read has a side effect of updating the last-read value in the timecounter structure. Timecounter_cyc2time does not. The MAC timestamps will be correct as long as the timecounter_read is updated at most half a wrap-around time before the systime is calculated.
This means that gettime, and tx/rx hwtstamp functions would be read operations, while settime, adjtime, cyclecounter_update and (if igb needs it?) the function which adjusts for link speed would be writes. Since these operations only occur occasionally (relative to tx/rx hwtstamp and gettime) we have a many readers/few writers scenario.
I can show you the changes on the ixgbe driver.
> Richard
>
^ permalink raw reply
* RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
From: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA @ 2012-03-22 21:20 UTC (permalink / raw)
To: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA,
roland-BHEL68pLQRGGvPXPguhicg, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <88B766C272F2C64B944B21AD078333151C964A670B-/SwythR3zqxVRK6PHKByhFaTQe2KTcn/@public.gmane.org>
I got a question here lately.
aligned directive will ensure that it will fall on boundary.
Say aligned(4) ensures that structure is aligned to 4 byte boundary.
Compiler can (at least theoretically) still have 4 byte structure aligned to 8 byte boundary on 64-bit platform (which is 4 byte aligned too).
struct {
u32 field;
} attribute ((aligned(4));
However requirement is to have this structure only 4 byte size( because adapter excepts it to be 4B sise) and therefor packed is used.
I don't know the way to ensure size of 4 byte and alignment too.
Or I am misunderstanding?
Parav
> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org
> Sent: Friday, March 23, 2012 2:41 AM
> To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
> Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org; roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org; linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> adapter
>
>
>
> > -----Original Message-----
> > From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> > Sent: Friday, March 23, 2012 2:28 AM
> > To: Pandit, Parav
> > Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org; roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org; linux-
> > rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> > adapter
> >
> > On Thu, Mar 22, 2012 at 01:52:30PM -0700, Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org
> > wrote:
> >
> > > > This can be used to force 32bit alignment in amd64 code in order
> > > > to match definitions in 32bit userspace.
> > > > For new things it would make sense to force 64bit alignment of
> > > > 64bit fields for 32bit code.
> > >
> > > o.k. so I'll use aligned attribute to align user-kernel interface
> > > data structure to 8 byte boundary. That should work for 32-bit and
> > > 64-bit user and kernel space and does't hurt performance either?
> >
> > If the structure is only for user/kernel interfacing then it is much
> > better to add explicit padding fields to naturally place 64 bit
> > quantities on an 8 byte alignment than to mess with gcc specific
> > attributes (user space has a much wide choice of compilers).
> >
> > This was David's second suggestion. Better to do this now before the
> > driver is accepted :)
> >
> o.k. I'll align them to naturally 8 byte boundary.
>
> > Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
> body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
From: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA @ 2012-03-22 21:10 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA,
roland-BHEL68pLQRGGvPXPguhicg, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120322205824.GC9614-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> Sent: Friday, March 23, 2012 2:28 AM
> To: Pandit, Parav
> Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org; roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org; linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> adapter
>
> On Thu, Mar 22, 2012 at 01:52:30PM -0700, Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org
> wrote:
>
> > > This can be used to force 32bit alignment in amd64 code in order to
> > > match definitions in 32bit userspace.
> > > For new things it would make sense to force 64bit alignment of 64bit
> > > fields for 32bit code.
> >
> > o.k. so I'll use aligned attribute to align user-kernel interface data
> > structure to 8 byte boundary. That should work for 32-bit and 64-bit
> > user and kernel space and does't hurt performance either?
>
> If the structure is only for user/kernel interfacing then it is much better to
> add explicit padding fields to naturally place 64 bit quantities on an 8 byte
> alignment than to mess with gcc specific attributes (user space has a much
> wide choice of compilers).
>
> This was David's second suggestion. Better to do this now before the driver is
> accepted :)
>
o.k. I'll align them to naturally 8 byte boundary.
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [STRAW MAN PATCH] sch_teql doesn't load-balance ppp(oatm) slaves
From: David Woodhouse @ 2012-03-22 21:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
ppp_xmit_process() loops, calling skb_dequeue() until it can no longer
push a frame to the channel. In the case of PPPoATM, it's only ever
going to fail to push a frame to the channel when sk->sk_sndbuf is
exceeded on the atm_vcc. We have a *huge* hidden queue there. (Reducing
the send buffer size to 4KiB with a hack in pppoatm_assign_vcc() didn't
fix the teql problem either.)
teql_dequeue() will *always* give up a skb when it's called, if there is
one. If there's *not*, and the tx queue becomes empty, then the device
for which teql_dequeue() was called is 'promoted' to the front of the
line (master->slaves). That device will receive the next packet that
comes in, even if there are other devices which are *also* idle and
waiting for packets. Whenever a new packet comes in, the *last* device
to call teql_dequeue() gets it.
I have a system with two ADSL lines, using PPPoATM and teql. Because of
the behaviour of teql described above, it only seems to use *one* of the
uplinks at a time. One link will be idle for seconds at a time, before
the ATM socket send buffer fills or we get lucky with timing and it
flips to the other device.
My simple 'fix' for this is as follows: if *another* device is already
waiting with its tx queue empty, then teql_dequeue() should *not* return
a new packet to its caller. It may not be the best fix — it may not even
be correct, but it's working and I finally get the full upload bandwidth
of both lines, rather than using only one at a time. The ISP lets me do
a 10-second dump of the traffic on my bonded lines, and I now see it
being properly interleaved between the two lines, making optimal use of
the two uplinks.
Anyone got better ideas?
--- net/sched/sch_teql.c~ 2012-03-22 15:21:41.000000000 +0000
+++ net/sched/sch_teql.c 2012-03-22 16:42:28.684436315 +0000
@@ -100,6 +100,10 @@ teql_dequeue(struct Qdisc *sch)
struct netdev_queue *dat_queue;
struct sk_buff *skb;
+ if (dat->m->slaves && dat->m->slaves != sch &&
+ !qdisc_peek_head(dat->m->slaves)) {
+ return NULL;
+ }
skb = __skb_dequeue(&dat->q);
dat_queue = netdev_get_tx_queue(dat->m->dev, 0);
if (skb == NULL) {
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
From: Jason Gunthorpe @ 2012-03-22 20:58 UTC (permalink / raw)
To: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA
Cc: David.Laight-ZS65k/vG3HxXrIkS9f7CXA,
roland-BHEL68pLQRGGvPXPguhicg, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <88B766C272F2C64B944B21AD078333151C964A66EF-/SwythR3zqxVRK6PHKByhFaTQe2KTcn/@public.gmane.org>
On Thu, Mar 22, 2012 at 01:52:30PM -0700, Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA@public.gmane.org wrote:
> > This can be used to force 32bit alignment in amd64 code in order to match
> > definitions in 32bit userspace.
> > For new things it would make sense to force 64bit alignment of 64bit fields
> > for 32bit code.
>
> o.k. so I'll use aligned attribute to align user-kernel interface
> data structure to 8 byte boundary. That should work for 32-bit and
> 64-bit user and kernel space and does't hurt performance either?
If the structure is only for user/kernel interfacing then it is much
better to add explicit padding fields to naturally place 64 bit
quantities on an 8 byte alignment than to mess with gcc specific
attributes (user space has a much wide choice of compilers).
This was David's second suggestion. Better to do this now before the
driver is accepted :)
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PULL] vhost-net/virtio: fixes for 3.4
From: David Miller @ 2012-03-22 20:56 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel, levinsasha928, nyh,
nyh
In-Reply-To: <20120322082718.GA11258@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 22 Mar 2012 10:27:19 +0200
> On Tue, Mar 20, 2012 at 04:50:41PM +0200, Michael S. Tsirkin wrote:
>> The following changes since commit 5ffca28a4ac7abb8a254fafe6bd03b2f83667df7:
>>
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs (2012-02-27 07:59:33 -0800)
>>
>> are available in the git repository at:
>>
>> ra.kernel.org:/pub/scm/linux/kernel/git/mst/vhost.git for_davem
>>
>> (ssh url as git.kernel.org seems down at the moment, when it comes up
>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for_davem
>> should be the equivalent).
Neither of these URL's work for me:
[davem@drr net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for_davem
fatal: Couldn't find remote ref for_davem
[davem@drr net]$ git pull ra.kernel.org:/pub/scm/linux/kernel/git/mst/vhost.git for_davem
Enter passphrase for key '/home/davem/.ssh/davem':
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
[davem@drr net]$
If you're sending me signed pull requests that thus require a newer
version of GIT, please don't.
^ permalink raw reply
* RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
From: Parav.Pandit-iH1Dq9VlAzfQT0dZR+AlfA @ 2012-03-22 20:52 UTC (permalink / raw)
To: David.Laight-ZS65k/vG3HxXrIkS9f7CXA,
roland-BHEL68pLQRGGvPXPguhicg
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6EB4-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
> -----Original Message-----
> From: David Laight [mailto:David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org]
> Sent: Wednesday, March 21, 2012 10:02 PM
> To: Roland Dreier; Pandit, Parav
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> adapter
>
>
> > > - Header file for userspace library and kernel driver interface.
> >
> > > +struct ocrdma_alloc_ucontext_resp {
> > > + u32 dev_id;
> > > + u32 wqe_size;
> > > + u32 max_inline_data;
> > > + u32 dpp_wqe_size;
> > > + u64 ah_tbl_page;
> > > + u32 ah_tbl_len;
> > > + u32 rsvd;
> > > + u8 fw_ver[32];
> > > + u32 rqe_size;
> > > + u64 rsvd1;
> > > +} __packed;
> >
> > If I'm reading this correctly, you have the 8-byte rsvd1 member at an
> > offset only aligned to 4 bytes, because of the __packed directive. It
> > would be much better to have these structures laid out so they are
> > naturally the same on both 32-bit and 64-bit ABIs, and get rid of the
> > __packed directive, which wrecks gcc code generation in some cases.
> >
>
> gcc also supports defining types that have non-standard alignment
> constraints that can be used to force the same alignment for 64bit fields
> between i386 and amd64.
> Probably __attribute__((aligned,n)) or similar.
>
> This can be used to force 32bit alignment in amd64 code in order to match
> definitions in 32bit userspace.
> For new things it would make sense to force 64bit alignment of 64bit fields
> for 32bit code.
o.k. so I'll use aligned attribute to align user-kernel interface data structure to 8 byte boundary.
That should work for 32-bit and 64-bit user and kernel space and does't hurt performance either?
Driver-adapter structures will be aligned to 4 byte boundary using aligned attribute instead of packed.
>
> Adding __packed (rather than 32bit alignment) forces the compiler to
> generate byte by byte accesses for all the fields on systems that can't do
> misaligned accesses in hardware (eg sparc).
>
> David
>
>
> David
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] usbnet: consider device busy at each recieved packet
From: Oliver Neukum @ 2012-03-22 20:35 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Tony Hill
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA
>From dd427382b6d3326acd6886041e8bbb432dfd4263 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Sat, 3 Mar 2012 18:45:07 +0100
Subject: [PATCH] usbnet: consider device busy at each recieved packet
usbnet should centrally handle busy reporting in the rx path
so subdrivers need not worry. This hurts use cases which do
rx only or predominantly.
Signed-off-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
---
drivers/net/usb/usbnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index fae0fbd..a51ab46 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -493,6 +493,7 @@ block:
if (netif_running (dev->net) &&
!test_bit (EVENT_RX_HALT, &dev->flags)) {
rx_submit (dev, urb, GFP_ATOMIC);
+ usb_mark_last_busy(dev->udev);
return;
}
usb_free_urb (urb);
--
1.7.1
--
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 related
* Re: [PATCH net-next] [v2] bonding: remove entries for master_ip and vlan_ip and query devices instead
From: Andy Gospodarek @ 2012-03-22 20:22 UTC (permalink / raw)
To: David Miller; +Cc: andy, netdev, ralf.zeidler
In-Reply-To: <20120321.223411.1471023630379810739.davem@davemloft.net>
On Wed, Mar 21, 2012 at 10:34:11PM -0400, David Miller wrote:
> From: Andy Gospodarek <andy@greyhouse.net>
> Date: Wed, 21 Mar 2012 17:36:42 -0400
>
> > As the Subject indicates this patch drops the master_ip and vlan_ip
> > elements from the 'bonding' and 'vlan_entry' structs, respectively.
> > This can be done because a device's address-list is now traversed to
> > determine the optimal source IP address for ARP requests and for checks
> > to see if the bonding device has a particular IP address. This code
> > could have all be contained inside the bonding driver, but it made more
> > sense to me to EXPORT and call inet_confirm_addr since it did exactly
> > what was needed.
>
> I like this patch a lot but you have one little bug that needs to be
> fixed:
>
> > + rcu_read_lock();
> > + in_dev = __in_dev_get_rcu(dev);
> > + rcu_read_unlock();
> > +
> > + if (in_dev)
> > + addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
>
> If you're going to do an RCU ref-less lookup of in_dev and then use
> it, you have to include the "use" inside of the RCU protected section
> as well.
>
> Otherwise as soon as you rcu_read_unlock() the in_dev could be freed
> up on you.
>
> The only exception would be if you know that all callers of
> bond_confirm_addr() ran in an RCU protected section, but I do not
> think that is universally the case here.
>
> If you think it might be the case that we are RCU protected in all of
> these code paths already, you can remove the RCU locking altogether
> from bond_confirm_addr() and run with lockdep enabled while exercising
> all of the relevant code paths.
Thanks for catching that, Dave. I'm pretty sure there is at least one
path where rcu_read_lock has not already been called so the protection
is needed. I know that rcu_read_lock/unlock is called in
inet_confirm_addr, but since rcu locks can be nested, so I'll go ahead
and make that change.
There are 2 more places in the bonding driver where this is also done
incorrectly in some vlan code, so I'll fix those with a subsequent patch.
^ permalink raw reply
* Re: tun oops dereferencing garbage nsproxy-> address.
From: Maciej Rutecki @ 2012-03-22 19:29 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Dave Jones, netdev, Linux Kernel, serue
In-Reply-To: <m1obrp2sn1.fsf@fess.ebiederm.org>
On czwartek, 22 marca 2012 o 04:58:58 Eric W. Biederman wrote:
> Maciej Rutecki <maciej.rutecki@gmail.com> writes:
> > On wtorek, 13 marca 2012 o 04:42:02 Dave Jones wrote:
> >> BUG: unable to handle kernel paging request at 0000000100000029
> >> IP: [<ffffffffa06ec54f>] tun_chr_open+0x4f/0x80 [tun]
> >> PGD 5ae4f067 PUD 0
> >> Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >> CPU 1
> >> Modules linked in: tun binfmt_misc can_bcm cmtp kernelcapi nfnetlink
> >> bnep can_raw af_802154 phonet bluetooth can pppoe pppox ppp_generic
> >> slhc irda crc_ccitt rds af_key rose ax25 appletalk atm ipx p8022 psnap
> >> llc p8023 tcp_lp iwlwifi mac80211 cfg80211 nfs fscache auth_rpcgss
> >> nfs_acl fuse lockd ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> >> ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
> >> nf_conntrack xts gf128mul dm_crypt dm_mirror dm_region_hash dm_log arc4
> >> snd_hda_codec_hdmi uvcvideo snd_hda_codec_idt videobuf2_core
> >> snd_usb_audio snd_hda_intel videodev snd_hda_codec dell_wmi
> >> sparse_keymap media snd_usbmidi_lib snd_hwdep v4l2_compat_ioctl32
> >> snd_rawmidi cdc_ether videobuf2_vmalloc videobuf2_memops snd_seq usbnet
> >> cdc_wdm mii cdc_acm snd_seq_device snd_pcm dell_laptop dcdbas joydev
> >> microcode snd_timer tg3 snd pcspkr i2c_i801 iTCO_wdt
> >> iTCO_vendor_support soundcore snd_page_alloc rfkill wmi sunrpc i915
> >> drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded:
> >> cfg80211]
> >>
> >> Pid: 15413, comm: trinity Not tainted 3.3.0-rc7+ #54 Dell Inc. Adamo 13
> >> /0N70T0 RIP: 0010:[<ffffffffa06ec54f>] [<ffffffffa06ec54f>]
> >> tun_chr_open+0x4f/0x80 [tun] RSP: 0018:ffff8800a5e29bc8 EFLAGS:
> >> 00010286 RAX: ffff88012036fd88 RBX: ffff8801084c4dc0 RCX:
> >> 0000000000000006 RDX: 0000000100000001 RSI: ffff88000fd9abc8 RDI:
> >> 0000000000000292 RBP: ffff8800a5e29bd8 R08: 0000000000000000 R09:
> >> 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12:
> >> ffff8801084c4dc0 R13: ffff88012eb10d20 R14: ffffffffa06f0000 R15:
> >> ffffffff81856ae0 FS: 00007f3ebcb1a700(0000) GS:ffff88013b400000(0000)
> >> knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 0000000100000029 CR3: 00000000032bb000 CR4: 00000000000406e0
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process trinity (pid: 15413, threadinfo ffff8800a5e28000, task
> >>
> >> ffff88000fd9a4a0) Stack:
> >> 00000000000000c8 0000000000000000 ffff8800a5e29c38 ffffffff813fcf38
> >> ffffffff81c54838 0000000000000001 ffff8800a5e29c18 ffffffff816a1afd
> >> ffff8801084c4dc0 ffff8801396bbab8 ffff88012eb10d20 0000000000000000
> >>
> >> Call Trace:
> >> [<ffffffff813fcf38>] misc_open+0x1d8/0x670
> >> [<ffffffff816a1afd>] ? sub_preempt_count+0x9d/0xd0
> >> [<ffffffff811c2978>] chrdev_open+0x258/0x350
> >> [<ffffffff811baa04>] __dentry_open+0x384/0x550
> >> [<ffffffff816a1afd>] ? sub_preempt_count+0x9d/0xd0
> >> [<ffffffff811c2720>] ? cdev_put+0x30/0x30
> >> [<ffffffff811bc224>] nameidata_to_filp+0x74/0x80
> >> [<ffffffff811ce59c>] do_last+0x26c/0x930
> >> [<ffffffff811ced76>] path_openat+0xd6/0x3e0
> >> [<ffffffff810a6298>] ? sched_clock_cpu+0xb8/0x130
> >> [<ffffffff811cf1a2>] do_filp_open+0x42/0xa0
> >> [<ffffffff8169d845>] ? _raw_spin_unlock+0x35/0x60
> >> [<ffffffff811dd7cd>] ? alloc_fd+0x18d/0x210
> >> [<ffffffff811bc328>] do_sys_open+0xf8/0x1d0
> >> [<ffffffff810faadc>] ? __audit_syscall_entry+0xcc/0x310
> >> [<ffffffff811bc421>] sys_open+0x21/0x30
> >> [<ffffffff816a5a69>] system_call_fastpath+0x16/0x1b
> >>
> >> Code: 00 00 00 e8 64 8d ab e0 48 85 c0 74 46 c7 00 00 00 00 00 48 c7 40
> >> 08 00 00 00 00 65 48 8b 14 25 00 c9 00 00 48 8b 92 50 05 00 00 <48> 8b
> >> 52 28 f0 ff 42 04 48 89 50 10 48 89 83 28 01 00 00 31 c0 RIP
> >> [<ffffffffa06ec54f>] tun_chr_open+0x4f/0x80 [tun]
> >>
> >> RSP <ffff8800a5e29bc8>
> >>
> >> CR2: 0000000100000029
> >> Disabling lock debugging due to kernel taint
> >> ---[ end trace 9e00e91b0629ad80 ]---
> >>
> >>
> >> oops happened here..
> >>
> >> tfile->net = get_net(current->nsproxy->net_ns);
> >>
> >> 548: 48 8b 92 50 05 00 00 mov 0x550(%rdx),%rdx
> >> 54f: 48 8b 52 28 mov 0x28(%rdx),%rdx
> >>
> >> My guess is the fuzzer called some syscall that set current->nsproxy
> >> to garbage (0x0000000100000001), which later got dereferenced when it
> >> subsequently randomly did an open() on tun.
> >>
> >> Any thoughts ?
> >>
> >> Dave
> >
> > I created a Bugzilla entry at
> > https://bugzilla.kernel.org/show_bug.cgi?id=42960
> > for your bug/regression report, please add your address to the CC list in
> > there, thanks!
>
> There is not enough information here to track this as any kind of bug to
> be fixed. This problem can be neither reproduced nor is it a
> direct consequence of anything obvious in the code. The bug should
> simply be closed with "can not reproduce". There is no evidence
> that this is any kind of regression.
>
> If there is a system to track weird failures and note strange
> occurrences and to start looking for patterns this might be interesting,
> but I don't believe that system is the kernel bugzilla system.
>
> This was all covered in the discussion of this issue before you put it
> in the kernel bugzilla so I don't understand why you bothered. There is
> simply too little information to do anything interesting with this
> failure. Most likely this is the result of a kernel memory stomp
> triggered by an unprivileged process.
>
> I think such memory stomps suck but there is not enough information in
> this thread to really even start looking and there is a lot of kernel
> code to look through. You don't seem to be interested in digging into
> this yourself so adding this to bugzilla simply appears to be a waste
> of time.
>
> Eric
Ok. Closed
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply
* Your Account Exceed Limit
From: Revista Medica de la Universidad Veracruzana @ 2012-03-22 19:18 UTC (permalink / raw)
Your mailbox has exceeded one or more size limits set by the
administrator. You can not send or receive new mail until size of your
mail box is reduced. For more space, Please click the link below and fill
in the details of correct account. http://accountupgrad.webs.com/contact.htm
================>
^ permalink raw reply
* Re: module_param: make bool parameters really bool (net & drivers/net)
From: Dan Carpenter @ 2012-03-22 18:30 UTC (permalink / raw)
To: rusty; +Cc: netdev
In-Reply-To: <20120322182623.GA29859@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 97 bytes --]
The same thing happens in net/ipv6/netfilter/ip6table_filter.c
as well.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* re: module_param: make bool parameters really bool (net & drivers/net)
From: Dan Carpenter @ 2012-03-22 18:26 UTC (permalink / raw)
To: rusty; +Cc: netdev
Hi Rusty,
The patch eb93992207da: "module_param: make bool parameters really
bool (net & drivers/net)" from Dec 19, 2011, leads to the following
warning:
net/ipv4/netfilter/iptable_filter.c:90 iptable_filter_init()
warn: 5 is more than 1 (max 'forward' can be) so this is
always the same.
It's declared like this:
54 /* Default to forward because I got too much mail already. */
55 static bool forward = NF_ACCEPT;
56 module_param(forward, bool, 0000);
It's used like this:
66 ((struct ipt_standard *)repl->entries)[1].target.verdict = -forward - 1;
Smatch complains when check that it's larger than 5.
90 if (forward < 0 || forward > NF_MAX_VERDICT) {
91 pr_err("iptables forward must be 0 or 1\n");
92 return -EINVAL;
93 }
regards,
dan carpenter
^ permalink raw reply
* new version of netmap for linux (20120322)
From: Luigi Rizzo @ 2012-03-22 18:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <20120312230809.GA45615@onelab2.iet.unipi.it>
I have updated the linux version of the netmap code,
specifically fixing the 'igb' driver which was not working earlier.
The code and tinycore images for today's version 20120322
are available in the same location
http://info.iet.unipi.it/~luigi/netmap/
cheers
luigi
On Tue, Mar 13, 2012 at 12:08:09AM +0100, Luigi Rizzo wrote:
> just in case you might be interested...
>
> i have recently completed a linux port of the netmap framework.
> Code, documentation and PicoBSD/Tinycore bootable images are at
>
> http://info.iet.unipi.it/~luigi/netmap/
>
> Netmap is a device-independent framework for packet generation and
> capture from user space; it can do line rate at 10Gbit/s (14.88Mpps)
> with just one core at about 1GHz.
>
> Netmap relies on a kernel module (netmap_lin.ko) and slightly
> modified device drivers (about 4-500 lines per driver). It requires
> no kernel patches apart from device drivers (and abusing the ax25
> field in struct netdevice).
> Userspace programs can use the native API (documented in netmap.4)
> or a libpcap emulation library. It has been integrated in FreeBSD
> last fall, and the linux version uses mostly the same code plus a bit
> of glue to adapt the BSD<->linux kernel ABI.
>
> The current version supporting the ixgbe and e1000/e1000e driver.
> Patches for other devices (igb, r8169, forcedeth) are avaiable but
> untested.
>
> cheers
> luigi
^ permalink raw reply
* Re: [PATCH v2] ethernet driver for the WIZnet W5300 chip
From: Ben Hutchings @ 2012-03-22 16:57 UTC (permalink / raw)
To: Mike Sinkovsky; +Cc: netdev
In-Reply-To: <4F69734B.7040105@permonline.ru>
On Wed, 2012-03-21 at 12:20 +0600, Mike Sinkovsky wrote:
> 21.03.2012 0:08, Ben Hutchings написал:
> > +static void w5300_get_drvinfo(struct net_device *ndev,
> > + struct ethtool_drvinfo *info)
> > +{
> > + strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
> > + strlcpy(info->version, DRV_VERSION, sizeof(info->version));
> > + strlcpy(info->fw_version, "N/A", sizeof(info->fw_version));
> > [...]
> >
> > Nitpick: if you don't have firmware, don't set fw_version at all.
> >
> > Ben.
>
> Then ethtool prints empty string as firmware version, I think "N/A" is
> more intuitive.
Well, we can replace it with "N/A" in ethtool if that's what people want
to see. But it should not be necessary for every driver that can't
report a firmware version to write this special string.
> Can will remove, if it is preferred way.
It is, and the various other drivers that used this string have recently
been changed.
> But I have a question to networking guru's:
>
> This chip have FRAME_SIZE limited to 1514, including eth header.
> So, for 802.1Q vlan packets mtu must be set to 1496.
>
> For now we handle this from userspace, but I think this is wrong in general
> - handling hardware bugs and limitations is kernels job.
>
> Can driver somehow limit mtu for slave vlan devices to 1496, but still
> use 1500
> for plain ethernet?
> ->ndo_change_mtu is called for master device only, not for it's slaves.
I don't think it's possible to do this at the moment. You can only set
NETIF_F_VLAN_CHALLENGED, which unfortunately disables VLAN sub-devices
entirely.
> (and sorry for my russian english, just in case)
Not to worry - your writing is quite clear.
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
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