* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-03 21:41 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803213017.GK15477@google.com>
On 08/03/2012 11:30 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
>>> Is this supposed to be embedded in struct definition? If so, the name
>>> is rather misleading as DEFINE_* is supposed to define and initialize
>>> stand-alone constructs. Also, for struct members, simply putting hash
>>> entries after struct hash_table should work.
>>
>> It would work, but I didn't want to just put them in the union since
>> I feel it's safer to keep them in a separate struct so they won't be
>> used by mistake,
>
> Just use ugly enough pre/postfixes. If the user still accesses that,
> it's the user's fault.
I forgot to comment on that one, sorry.
If we put hash entries after struct hash_table we don't take the bits field size into account, or did I miss something?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-03 21:44 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <501C4471.4090706@gmail.com>
Hello, Sasha.
On Fri, Aug 03, 2012 at 11:36:49PM +0200, Sasha Levin wrote:
> On 08/03/2012 11:30 PM, Tejun Heo wrote:
> The function definition itself is just a macro, for example:
>
> #define MM_SLOTS_HASH_CMP(mm_slot, obj) ((mm_slot)->mm == (obj))
It seems like it would make things more difficult to follow and
error-prone. I'd definitely prefer just using functions.
> As an alternative, what do you think about simplifying that to be
> just a 'cond' instead of a function? Something like:
>
> hash_get(&mm_slots_hash, mm, struct mm_slot, hash, mm);
>
> In that case, the last param ("mm") will get unrolled to a condition like this:
>
> if ((obj)->mm == key)
>
> Which will be simple and easy for the user.
It seems a bit too magical(tm) to me. ;)
> The only reason I want to keep this interface is that most cases
> I've stumbled so far were easy short comparisons of a struct member
> with the key, and I don't want to make them more complex than they
> need to be. I probably will switch hash_get() to use
> hash_for_each_possible() as well, which will cut down on how
> hash_get() is a separate case.
I can understand that but I think the benefit we're talking about is a
bit too miniscule to matter and to have two different interfaces.
What do others think?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-03 21:48 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <501C458E.7050000@gmail.com>
Hello,
On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> I forgot to comment on that one, sorry.
>
> If we put hash entries after struct hash_table we don't take the
> bits field size into account, or did I miss something?
So, if you do the following,
struct {
struct {
int i;
long ar[];
} B;
long __ar_storage[32];
} A;
It should always be safe to dereference A.B.ar[31]. I'm not sure
whether this is something guaranteed by C tho. Maybe compilers are
allowed to put members in reverse order but I think we already depend
on the above.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-03 22:20 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803214806.GM15477@google.com>
On 08/03/2012 11:48 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
>> I forgot to comment on that one, sorry.
>>
>> If we put hash entries after struct hash_table we don't take the
>> bits field size into account, or did I miss something?
>
> So, if you do the following,
>
> struct {
> struct {
> int i;
> long ar[];
> } B;
> long __ar_storage[32];
> } A;
struct A should have been an union, right?
> It should always be safe to dereference A.B.ar[31]. I'm not sure
> whether this is something guaranteed by C tho. Maybe compilers are
> allowed to put members in reverse order but I think we already depend
> on the above.
why is accessing A.B.ar[31] safe?
__ar_storage is only 32*sizeof(long) bytes long, while struct B would need to be 32*sizeof(long) + sizeof(int) bytes long so that A.B.ar[31] access would be safe.
> Thanks.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-03 22:23 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <501C4E92.1070801@gmail.com>
Hello,
On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
> On 08/03/2012 11:48 PM, Tejun Heo wrote:
> > On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> >> I forgot to comment on that one, sorry.
> >>
> >> If we put hash entries after struct hash_table we don't take the
> >> bits field size into account, or did I miss something?
> >
> > So, if you do the following,
> >
> > struct {
> > struct {
> > int i;
> > long ar[];
> > } B;
> > long __ar_storage[32];
> > } A;
>
> struct A should have been an union, right?
I actually meant an enclosing struct. When you're defining a struct
member, simply putting the storage after a struct with var array
should be good enough. If that doesn't work, quite a few things in
the kernel will break.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-03 22:26 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803222339.GN15477@google.com>
On 08/04/2012 12:23 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
>> On 08/03/2012 11:48 PM, Tejun Heo wrote:
>>> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
>>>> I forgot to comment on that one, sorry.
>>>>
>>>> If we put hash entries after struct hash_table we don't take the
>>>> bits field size into account, or did I miss something?
>>>
>>> So, if you do the following,
>>>
>>> struct {
>>> struct {
>>> int i;
>>> long ar[];
>>> } B;
>>> long __ar_storage[32];
>>> } A;
>>
>> struct A should have been an union, right?
>
> I actually meant an enclosing struct. When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough. If that doesn't work, quite a few things in
> the kernel will break.
Ah, I see, I've missed that part.
Thanks!
> Thanks.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-08-03 22:29 UTC (permalink / raw)
To: Tejun Heo
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803222339.GN15477@google.com>
On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo <tj@kernel.org> wrote:
>
> I actually meant an enclosing struct. When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough. If that doesn't work, quite a few things in
> the kernel will break.
The unsigned member of a struct has to be the last one, so your struct
won't work.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-03 22:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFyOst4c3WHbPVbYkSBdBmLJUui5OvoVOh5AuPMnigwnEA@mail.gmail.com>
On Fri, Aug 03, 2012 at 03:29:10PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo <tj@kernel.org> wrote:
> >
> > I actually meant an enclosing struct. When you're defining a struct
> > member, simply putting the storage after a struct with var array
> > should be good enough. If that doesn't work, quite a few things in
> > the kernel will break.
>
> The unsigned member of a struct has to be the last one, so your struct
> won't work.
I suppose you mean unsized. I remember this working. Maybe I'm
confusing it with zero-sized array. Hmm... gcc doesn't complain about
the following. --std=c99 seems happy too.
#include <stdio.h>
struct A {
int i;
long ar[];
};
struct B {
struct A a;
long ar_storage[32];
};
int main(void)
{
printf("sizeof(A)=%zd sizeof(B)=%zd\n", sizeof(struct A), sizeof(struct B));
return 0;
}
$ ./a.out
sizeof(A)=8 sizeof(B)=264
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Ali Ayoub @ 2012-08-03 22:39 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <20120803.143315.151094375569109262.davem@davemloft.net>
On 8/3/2012 2:33 PM, David Miller wrote:
> From: Ali Ayoub <ali@mellanox.com>
> Date: Fri, 03 Aug 2012 13:31:35 -0700
>
>> With eIPoIB architecture, the VM sees standard Ethernet emulator,
>> allowing the administrator to enslave eIPoIB PIF to the vSwitch/vBridge
>> as if it was standard Ethernet. Other approaches that exposes IB QP to
>> the VM (with w/o bypassing the kernel) won't be possible with the
>> current emulators and management tools.
>
> So then fix the emulators and management tools to handle IB instead
> of adding this bogus new protocol?
>
> This new protocol seems to exist only because you don't want to have
> to enhance the emulators and tools, and I'm sorry that isn't a valid
> reason to do something like this.
This driver exists to allow the user to have an Ethernet interface on
top of a high-speed InfiniBand (IB) interconnect.
Users would like to use sockets API from the VM without re-writing their
applications on top of IB verbs, this driver meant to allow such a user
to do so.
Exposing IB emulators and having IB support in the management tools for
the VM/Hypervisor won't address the usecases that this driver meant for.
With this driver, existing VMs, and their existing IP applications, can
run as-is on InfiniBand network.
^ permalink raw reply
* LONDON OLYMPIC NOTIFICATION
From: RINKU PATEL @ 2012-08-03 23:04 UTC (permalink / raw)
Congratulations!!! For more informations communicate to the below contact;
CONTACT PERSON Larry Williams Contact Number:+447035972724
E-mail Adress: larrywilliamslawchamber@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: David Miller @ 2012-08-03 23:36 UTC (permalink / raw)
To: ali; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C5328.4060301@mellanox.com>
From: Ali Ayoub <ali@mellanox.com>
Date: Fri, 03 Aug 2012 15:39:36 -0700
> Users would like to use sockets API from the VM without re-writing their
> applications on top of IB verbs, this driver meant to allow such a user
> to do so.
That's what IPoIB was for, the application writers who don't want to have
to be knowledgable about IB verbs.
You're messing with the link layer here, and that's what is upsetting me.
It's a complete cop-out to changing the VM tools and emulators properly to
handle a new link layer.
The applications writers already have a way to use IB whilst using
something familiar, like IPv4, via IPoIB. You're doing something
completely different here, and it stinks.
^ permalink raw reply
* Re: pull request: wireless 2012-08-03
From: David Miller @ 2012-08-03 23:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120803145604.GA6372@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 3 Aug 2012 10:56:04 -0400
> This request covers a batch of fixes intended for the 3.6 stream.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] emulex: benet: Add a missing CR in the end of message
From: David Miller @ 2012-08-03 23:43 UTC (permalink / raw)
To: standby24x7
Cc: linux-kernel, netdev, sathya.perla, subbu.seetharaman,
ajit.khaparde
In-Reply-To: <1343997411-10465-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Fri, 3 Aug 2012 21:36:51 +0900
> Missing a CR in printk causes 2 messages printed in one line.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-08-03 23:47 UTC (permalink / raw)
To: Tejun Heo
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <20120803223634.GO15477@google.com>
On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo <tj@kernel.org> wrote:
>
> I suppose you mean unsized. I remember this working. Maybe I'm
> confusing it with zero-sized array. Hmm... gcc doesn't complain about
> the following. --std=c99 seems happy too.
Ok, I'm surprised, but maybe it's supposed to work if you do it inside
another struct like that, exactly so that you can preallocate things..
Or maybe it's just a gcc bug. I do think this all is way hackier than
Sasha's original simple code that didn't need these kinds of games,
and didn't need a size member at all.
I really think all the extra complexity and overhead is just *bad*.
The first simple version was much nicer and likely generated better
code too.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net] net_sched: gact: Fix potential panic in tcf_gact().
From: David Miller @ 2012-08-03 23:47 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: netdev
In-Reply-To: <20120803195752.32410768d3d806cd241ac7a4@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Fri, 3 Aug 2012 19:57:52 +0900
> gact_rand array is accessed by gact->tcfg_ptype whose value
> is assumed to less than MAX_RAND, but any range checks are
> not performed.
>
> So add a check in tcf_gact_init(). And in tcf_gact(), we can
> reduce a branch.
>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH V1 1/3] net/mlx4_en: loopbacked packets are dropped when SMAC=DMAC
From: David Miller @ 2012-08-03 23:49 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev, amirv
In-Reply-To: <1343990318-10744-2-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:36 +0300
> From: Amir Vadai <amirv@mellanox.com>
>
> Should NOT check SMAC=DMAC when:
> 1. loopback is turned on
> 2. validate_loopback is true.
>
> Fixed it accordingly.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH V1 2/3] net/mlx4_en: Fixing TX queue stop/wake flow
From: David Miller @ 2012-08-03 23:49 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343990318-10744-3-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:37 +0300
> Removing the ring->blocked flag, it is redundant and leads to a race:
>
> We close the TX queue and then set the "blocked" flag.
> Between those 2 operations the completion function can check the "blocked"
> flag, sees that it is 0, and wouldn't open the TX queue.
>
> Using netif_tx_queue_stopped to check the state of the queue to avoid this race.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH V1 3/3] net/mlx4_core: Remove port type restrictions
From: David Miller @ 2012-08-03 23:50 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343990318-10744-4-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Fri, 3 Aug 2012 13:38:38 +0300
> Port1=Eth, Port2=IB restriction is no longer required.
> Having RoCE, there will always rdma port initialized over ConnectX
> physical port, no matter whether the link layer is IB or Ethernet.
> So we always have dual port IB device.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,1/1] hyperv: Move wait completion msg code into rndis_filter_halt_device()
From: David Miller @ 2012-08-03 23:52 UTC (permalink / raw)
To: haiyangz; +Cc: netdev, kys, olaf, jasowang, linux-kernel, devel
In-Reply-To: <1344022338-3010-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 3 Aug 2012 12:32:18 -0700
> We need to wait for send_completion msg before put_rndis_request() at
> the end of rndis_filter_halt_device(). Otherwise, netvsc_send_completion()
> may reference freed memory which is overwritten, and cause panic.
>
> Reported-by: Long Li <longli@microsoft.com>
> Reported-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
This is a bug fix, so applied to 'net'. Please target your patches
properly.
Don't just be afraid that I'll reject the patch if you target it
at 'net', and therefore just target everything at 'net-next'. That
is certainly worse.
^ permalink raw reply
* Re: [PATCH] ipv4: remove parentheses in return statement
From: David Miller @ 2012-08-03 23:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: sakiwit, netdev
In-Reply-To: <1343987638.9299.912.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 03 Aug 2012 11:53:58 +0200
> We already have such thing in fact : net_hash_mix() which returns 0 if
> NS are not configured.
>
> (hash_ptr(net,8) is really overkill on 64bit arches)
>
> High order bits on "struct net *" have absolutely no entropy, unless you
> have a monster machine (more than 256 GB of ram)
>
> This is the patch I prepared :
Looks good to me.
^ permalink raw reply
* Re: [PATCH v3] isdnloop: fix and simplify isdnloop_init()
From: David Miller @ 2012-08-03 23:53 UTC (permalink / raw)
To: fengguang.wu
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120803091001.GA15772@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Fri, 3 Aug 2012 17:10:01 +0800
> Fix a buffer overflow bug by removing the revision and printk.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-03 23:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343972729.9299.596.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 03 Aug 2012 07:45:29 +0200
> @@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> if (ipv4_is_zeronet(daddr))
> goto martian_destination;
>
> - if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
> - if (ipv4_is_loopback(daddr))
> - goto martian_destination;
> + if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> + goto martian_destination;
>
> - if (ipv4_is_loopback(saddr))
> - goto martian_source;
> - }
> + if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> + goto martian_source;
Maybe clearer as:
if ((ipv4_is_loopback(daddr) || ipv4_is_loopback(saddr)) &&
!IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
goto martian_source;
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Ali Ayoub @ 2012-08-04 0:02 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C5328.4060301@mellanox.com>
On 8/3/2012 3:39 PM, Ali Ayoub wrote:
> On 8/3/2012 2:33 PM, David Miller wrote:
>> From: Ali Ayoub <ali@mellanox.com>
>> Date: Fri, 03 Aug 2012 13:31:35 -0700
>>
>>> With eIPoIB architecture, the VM sees standard Ethernet emulator,
>>> allowing the administrator to enslave eIPoIB PIF to the vSwitch/vBridge
>>> as if it was standard Ethernet. Other approaches that exposes IB QP to
>>> the VM (with w/o bypassing the kernel) won't be possible with the
>>> current emulators and management tools.
>>
>> So then fix the emulators and management tools to handle IB instead
>> of adding this bogus new protocol?
>>
>> This new protocol seems to exist only because you don't want to have
>> to enhance the emulators and tools, and I'm sorry that isn't a valid
>> reason to do something like this.
>
> This driver exists to allow the user to have an Ethernet interface on
> top of a high-speed InfiniBand (IB) interconnect.
> Users would like to use sockets API from the VM without re-writing their
> applications on top of IB verbs, this driver meant to allow such a user
> to do so.
>
> Exposing IB emulators and having IB support in the management tools for
> the VM/Hypervisor won't address the usecases that this driver meant for.
>
> With this driver, existing VMs, and their existing IP applications, can
> run as-is on InfiniBand network.
This driver exists to allow the user to have an Ethernet interface on
top of a high-speed InfiniBand (IB) interconnect.
Users would like to use sockets API from the VM without re-writing their
applications on top of IB verbs, this driver meant to allow such a user
to do so.
Exposing IB emulators and having IB support in the management tools for
the VM/Hypervisor won't address the usecases that this driver meant for.
With this driver, existing VMs, and their existing IP applications, can
run as-is on InfiniBand network.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-04 0:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFwTa_kYgmFwoWa6hwAAM6=2xTgQQf-vEx_gCzpEMnxodQ@mail.gmail.com>
Hi Linus,
On 08/04/2012 01:47 AM, Linus Torvalds wrote:
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.
The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
The alternative to going down this path, is going back to the old code and saying that it only works for the simple case, and if you're interested in something more complex it should have it's own different implementation.
Does it make sense? We'll keep the simple & common case simple, and let anyone who needs something more complex than this write it as an extension?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-04 0:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFwTa_kYgmFwoWa6hwAAM6=2xTgQQf-vEx_gCzpEMnxodQ@mail.gmail.com>
Hello,
On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo <tj@kernel.org> wrote:
> >
> > I suppose you mean unsized. I remember this working. Maybe I'm
> > confusing it with zero-sized array. Hmm... gcc doesn't complain about
> > the following. --std=c99 seems happy too.
>
> Ok, I'm surprised, but maybe it's supposed to work if you do it inside
> another struct like that, exactly so that you can preallocate things..
Yeah, I think the rule is var array should be the last member of any
given struct definition. Once a struct is defined, its alignment and
size are fixed and it behaves like any other struct.
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.
The size member could have performance impact in extreme cases. If
we're looking for something simple & fast, maybe just pass in @size as
argument and be done with it?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
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