* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Kirill A. Shutemov @ 2014-12-08 16:46 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, linux-kernel, linux-fsdevel, netdev
In-Reply-To: <20141204202011.GO29748@ZenIV.linux.org.uk>
On Thu, Dec 04, 2014 at 08:20:11PM +0000, Al Viro wrote:
> First of all, I want to apologize for the nastiness of preprocessor
> use in this series. Seeing that the whole "macros that look like new kinds
> of C statements" thing (including list_for_each_...(), etc) is very much not
> to my liking, I really don't trust my taste on finer details and I'd very
> much like some feedback.
>
> The reason for doing that kind of tricks is that iov_iter.c keeps
> growing more and more boilerplate code. For iov_iter-net series we need
> * csum_and_copy_from_iter()
> * csum_and_copy_to_iter()
> * copy_from_iter_nocache()
> That's 3 new primitives, each in 2 variants (iovec and bvec).
> * ITER_KVEC handled without going through uaccess.h stuff (and
> independent of set_fs() state).
> And *that* means 3 variants intstead of 2 for most of the existing primitives.
> That's far too much, and the amount of copies of the same logics would pretty
> much guarantee that it will be a breeding ground for hard-to-kill bugs.
>
> The following series (also in vfs.git#iov_iter) actually manages to
> do all of the above *and* shrink the damn thing quite a bit. The generated
> code appears to be no worse than before. The price is a couple of iterator
> macros - iterate_all_kinds() and iterate_and_advance(). They are given an
> iov_iter, size (i.e. the amount of data in iov_iter beginning we want to go
> through), name of the loop variable and 3 variants of loop body - for iovec,
> bvec and kvec resp. Loop variable is declared *inside* the expansion of those
> suckers according to the kind of iov_iter - it's struct iovec, struct bio_vec
> or struct kvec, covering the current range to deal with.
> The difference between those two is that iterate_and_advance() will
> advance the iov_iter by the amount it has handled and iterate_all_kinds()
> will leave iov_iter unchanged.
>
> Unless I hear anybody yelling, it goes into vfs.git#for-next today,
> so if you have objections, suggestions, etc., give those *now*.
>
> Al Viro (13):
> iov_iter.c: macros for iterating over iov_iter
> iov_iter.c: iterate_and_advance
> iov_iter.c: convert iov_iter_npages() to iterate_all_kinds
> iov_iter.c: convert iov_iter_get_pages() to iterate_all_kinds
> iov_iter.c: convert iov_iter_get_pages_alloc() to iterate_all_kinds
> iov_iter.c: convert iov_iter_zero() to iterate_and_advance
> iov_iter.c: get rid of bvec_copy_page_{to,from}_iter()
> iov_iter.c: convert copy_from_iter() to iterate_and_advance
> iov_iter.c: convert copy_to_iter() to iterate_and_advance
> iov_iter.c: handle ITER_KVEC directly
> csum_and_copy_..._iter()
> new helper: iov_iter_kvec()
> copy_from_iter_nocache()
I guess this crash is related to the patchset.
[ 102.337742] ------------[ cut here ]------------
[ 102.338270] kernel BUG at /home/kas/git/public/linux-next/arch/x86/mm/physaddr.c:26!
[ 102.339043] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 102.339622] Modules linked in:
[ 102.339951] CPU: 2 PID: 6029 Comm: trinity-c23 Not tainted 3.18.0-next-20141208-00036-gc7edb4791544-dirty #269
[ 102.340011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 102.340011] task: ffff880041c51510 ti: ffff880049c70000 task.ti: ffff880049c70000
[ 102.340011] RIP: 0010:[<ffffffff8104d8c0>] [<ffffffff8104d8c0>] __phys_addr+0x40/0x60
[ 102.340011] RSP: 0018:ffff880049c73838 EFLAGS: 00010206
[ 102.340011] RAX: 00004100174b4000 RBX: ffff880049c73b08 RCX: 0000000000000028
[ 102.340011] RDX: 0000000000000041 RSI: ffff88015dc980a8 RDI: ffffc900174b4000
[ 102.340011] RBP: ffff880049c73838 R08: ffffc900174b4000 R09: 000000000000000c
[ 102.340011] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88015dc980a8
[ 102.340011] R13: ffffc900174f4000 R14: ffffea0000000000 R15: ffffc900174b4000
[ 102.340011] FS: 00007fcdd37fb700(0000) GS:ffff88017aa00000(0000) knlGS:0000000000000000
[ 102.340011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 102.340011] CR2: 00000000006246a8 CR3: 0000000068dbb000 CR4: 00000000001406e0
[ 102.340011] Stack:
[ 102.340011] ffff880049c73888 ffffffff8117a96b 0000000000000002 0000000000040000
[ 102.340011] ffffffff81204b3f ffff88015dc98028 0000000000000000 ffff880049c73a78
[ 102.340011] ffff88015dc98000 ffff880049c73a10 ffff880049c73978 ffffffff81203ec9
[ 102.340011] Call Trace:
[ 102.340011] [<ffffffff8117a96b>] iov_iter_get_pages+0x17b/0x390
[ 102.340011] [<ffffffff81204b3f>] ? __blockdev_direct_IO+0x15f/0x16a0
[ 102.340011] [<ffffffff81203ec9>] do_direct_IO+0x10a9/0x1bc0
[ 102.340011] [<ffffffff810a92d8>] ? lockdep_init_map+0x68/0x5c0
[ 102.340011] [<ffffffff81204d6c>] __blockdev_direct_IO+0x38c/0x16a0
[ 102.340011] [<ffffffff810a9d27>] ? __lock_acquire+0x4f7/0xd40
[ 102.340011] [<ffffffff810a73f9>] ? mark_held_locks+0x79/0xb0
[ 102.340011] [<ffffffff8133b510>] ? xfs_get_blocks+0x20/0x20
[ 102.340011] [<ffffffff81338ff0>] xfs_vm_direct_IO+0x120/0x140
[ 102.340011] [<ffffffff8133b510>] ? xfs_get_blocks+0x20/0x20
[ 102.340011] [<ffffffff810aa773>] ? lock_release_non_nested+0x203/0x3d0
[ 102.340011] [<ffffffff8135b9a7>] ? xfs_ilock+0x167/0x2e0
[ 102.340011] [<ffffffff8114d957>] generic_file_read_iter+0x517/0x6a0
[ 102.340011] [<ffffffff810a73f9>] ? mark_held_locks+0x79/0xb0
[ 102.340011] [<ffffffff8185e192>] ? __mutex_unlock_slowpath+0xb2/0x190
[ 102.340011] [<ffffffff8134bc2f>] xfs_file_read_iter+0x12f/0x460
[ 102.340011] [<ffffffff811c237e>] new_sync_read+0x7e/0xb0
[ 102.340011] [<ffffffff811c3528>] __vfs_read+0x18/0x50
[ 102.340011] [<ffffffff811c35ed>] vfs_read+0x8d/0x150
[ 102.340011] [<ffffffff811c89e8>] kernel_read+0x48/0x60
[ 102.340011] [<ffffffff810f4a92>] copy_module_from_fd.isra.51+0x112/0x170
[ 102.340011] [<ffffffff810f7646>] SyS_finit_module+0x56/0x80
[ 102.340011] [<ffffffff81861f92>] system_call_fastpath+0x12/0x17
[ 102.340011] Code: 00 00 00 00 00 78 00 00 48 01 f8 48 39 c2 72 1b 0f b6 0d 9d 7a ec 00 48 89 c2 48 d3 ea 48 85 d2 75 09 5d c3 0f 1f 80 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 48 89 d0 48 03 05 3e 87 dc 00 48 81 fa
[ 102.340011] RIP [<ffffffff8104d8c0>] __phys_addr+0x40/0x60
[ 102.340011] RSP <ffff880049c73838>
[ 102.371939] ---[ end trace e07368268cd6b49c ]---
--
Kirill A. Shutemov
^ permalink raw reply
* Re: Q: need effective backlog for listen()
From: Philippe Troin @ 2014-12-08 16:35 UTC (permalink / raw)
To: Ulrich Windl; +Cc: netdev
In-Reply-To: <5485ACC9020000A100018394@gwsmtp1.uni-regensburg.de>
On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
> (not subscribed to the list, plese keep me on CC:)
>
> I have a problem I could not find the answer. I suspect the problem
> arises from Linux derivating from standard functionality...
>
> I have written a server that should accept n TCP connections at most.
> I was expecting that the backlog parameter of listen will cause extra
> connection requests either
> 1) to be refused
> or
> 2) to time out eventually
>
> (The standard seems to say that extra connections are refused)
The argument to listen() specifies how many connections the system is
allow to keep waiting to be accept()ed.
As soon as you accept() the connection, the count is decremented.
So that won't help for your use case.
> However none of the above see ms true. Even if my server delays
> accept()ing new connections, no client ever sees a "connection
> refused" or "connection timed out". Is there any chance to signal the
> client that no more connections are accepted at the moment?
Close the listening socket. No new connections will be accepted.
When you reopen the socket for accepting new connections, you may have
to use SO_REUSEADDR before bind()ing to the port.
Phil.
^ permalink raw reply
* Re: [PATCH net-next 2/3] netlink: IFLA_PHYS_SWITCH_ID to IFLA_PHYS_PARENT_ID
From: Jiri Pirko @ 2014-12-08 16:41 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, sfeldma
In-Reply-To: <20141208153747.GG797@gospo.home.greyhouse.net>
Mon, Dec 08, 2014 at 04:37:47PM CET, gospo@cumulusnetworks.com wrote:
>On Mon, Dec 08, 2014 at 04:17:14PM +0100, Jiri Pirko wrote:
>> Fri, Dec 05, 2014 at 07:02:16PM CET, gospo@cumulusnetworks.com wrote:
>> >There has been much discussion about proper nomenclature to use for this
>> >and I would prefer parent rather than calling every forwarding element a
>> >switch.
>>
>> Andy, I must say I really do not like just plain "parent". It is really
>> not clear what it means as it can mean 1000 things.
>>
>> I know "switch" is not ideal but everytime anyone is talking about these
>> kind of forwarding devices, they use word "switch" even if it is not
>> accurate and everyone knows what they are talking about. Nobody uses
>> "parent".
>
>Well of course they are not going to use it until it's committed. ;-)
Do you seriously expect people talking about "parents" instead of
"switches". I doubt that...
>
>> For me this is nack for this patchset.
>
>Thanks for the review. I am not big marketing person, so it was not
>clear to me what was ideal. Due to parent already being in the code
>and having as a logical description of the relationship (parent
>switch/router device and sibling network interfaces -- like sibling CPU
>cores on the same socket).
>
>I do really want to collectively come up with something other than
>switch for everything. Those L3 ops with 'switch' in the name will
>feel really awkward....
I say it is not optimal, but I did not see any better proposal...
>
>>
>> Jiri
>>
>> >
>> >Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>> >---
>> > include/uapi/linux/if_link.h | 2 +-
>> > net/core/rtnetlink.c | 4 ++--
>> > 2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> >diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>> >index f7d0d2d..3d8edd8 100644
>> >--- a/include/uapi/linux/if_link.h
>> >+++ b/include/uapi/linux/if_link.h
>> >@@ -145,7 +145,7 @@ enum {
>> > IFLA_CARRIER,
>> > IFLA_PHYS_PORT_ID,
>> > IFLA_CARRIER_CHANGES,
>> >- IFLA_PHYS_SWITCH_ID,
>> >+ IFLA_PHYS_PARENT_ID,
>> > __IFLA_MAX
>> > };
>> >
>> >diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> >index 61cb7e7..1fe0a16 100644
>> >--- a/net/core/rtnetlink.c
>> >+++ b/net/core/rtnetlink.c
>> >@@ -982,7 +982,7 @@ static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
>> > return err;
>> > }
>> >
>> >- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
>> >+ if (nla_put(skb, IFLA_PHYS_PARENT_ID, psid.id_len, psid.id))
>> > return -EMSGSIZE;
>> >
>> > return 0;
>> >@@ -1222,7 +1222,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> > [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
>> > [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> > [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>> >- [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> >+ [IFLA_PHYS_PARENT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> > };
>> >
>> > static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>> >--
>> >1.9.3
>> >
>--
>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 net] netlink: use jhash as hashfn for rhashtable
From: Thomas Graf @ 2014-12-08 16:38 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Herbert Xu, Hannes Frederic Sowa
In-Reply-To: <1418056230-8700-1-git-send-email-dborkman@redhat.com>
On 12/08/14 at 05:30pm, Daniel Borkmann wrote:
> For netlink, we shouldn't be using arch_fast_hash() as a hashing
> discipline, but rather jhash() instead.
>
> Since netlink sockets can be opened by any user, a local attacker
> would be able to easily create collisions with the DPDK-derived
> arch_fast_hash(), which trades off performance for security by
> using crc32 CPU instructions on x86_64.
>
> While it might have a legimite use case in other places, it should
> be avoided in netlink context, though. As rhashtable's API is very
> flexible, we could later on still decide on other hashing disciplines,
> if legitimate.
>
> Reference: http://thread.gmane.org/gmane.linux.kernel/1844123
> Fixes: e341694e3eb5 ("netlink: Convert netlink_lookup() to use RCU protected hash table")
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-12-08 16:37 UTC (permalink / raw)
To: Ming Lei
Cc: Pali Rohár, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <CACVXFVPOLfDuqc0nLb-zM8vH618DLXy0xtZbUOn5_XvdxRZSDw@mail.gmail.com>
On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
> On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>
> >
> > /**
> > + * request_firmware_prefer_user: - prefer usermode helper for loading firmware
> > + * @firmware_p: pointer to firmware image
> > + * @name: name of firmware file
> > + * @device: device for which firmware is being loaded
> > + *
> > + * This function works pretty much like request_firmware(), but it prefer
> > + * usermode helper. If usermode helper fails then it fallback to direct access.
> > + * Usefull for dynamic or model specific firmware data.
> > + **/
> > +int request_firmware_prefer_user(const struct firmware **firmware_p,
> > + const char *name, struct device *device)
> > +{
> > + int ret;
> > + __module_get(THIS_MODULE);
> > + ret = _request_firmware(firmware_p, name, device,
> > + FW_OPT_UEVENT | FW_OPT_PREFER_USER);
> > + module_put(THIS_MODULE);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>
> I'd like to introduce request_firmware_user() which only requests
> firmware from user space, and this way is simpler and more flexible
> since we have request_firmware_direct() already.
Why would a driver care about what program provides the firmware? It
shouldn't at all, and we want to get rid of the userspace firmware
loader, not encourage drivers to use it "exclusively" at all.
So no, I don't want to see this, and I don't want drivers to worry about
this either.
greg k-h
^ permalink raw reply
* [PATCH net] netlink: use jhash as hashfn for rhashtable
From: Daniel Borkmann @ 2014-12-08 16:30 UTC (permalink / raw)
To: davem; +Cc: netdev, Herbert Xu, Thomas Graf, Hannes Frederic Sowa
For netlink, we shouldn't be using arch_fast_hash() as a hashing
discipline, but rather jhash() instead.
Since netlink sockets can be opened by any user, a local attacker
would be able to easily create collisions with the DPDK-derived
arch_fast_hash(), which trades off performance for security by
using crc32 CPU instructions on x86_64.
While it might have a legimite use case in other places, it should
be avoided in netlink context, though. As rhashtable's API is very
flexible, we could later on still decide on other hashing disciplines,
if legitimate.
Reference: http://thread.gmane.org/gmane.linux.kernel/1844123
Fixes: e341694e3eb5 ("netlink: Convert netlink_lookup() to use RCU protected hash table")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0007b81..b6bf8e8 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -3130,7 +3130,7 @@ static int __init netlink_proto_init(void)
.head_offset = offsetof(struct netlink_sock, node),
.key_offset = offsetof(struct netlink_sock, portid),
.key_len = sizeof(u32), /* portid */
- .hashfn = arch_fast_hash,
+ .hashfn = jhash,
.max_shift = 16, /* 64K */
.grow_decision = rht_grow_above_75,
.shrink_decision = rht_shrink_below_30,
--
1.7.11.7
^ permalink raw reply related
* Re: Where exactly will arch_fast_hash be used
From: Hannes Frederic Sowa @ 2014-12-08 16:32 UTC (permalink / raw)
To: George Spelvin
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <20141208161959.8852.qmail@ns.horizon.com>
On Mon, Dec 8, 2014, at 17:19, George Spelvin wrote:
> >>> In case of openvswitch it shows a performance improvment. The seed
> >>> parameter could be used as an initial biasing of the crc32 function, but
> >>> in case of openvswitch it is only set to 0.
>
> >> NACK. [...]
>
> > Sorry for being unclear, I understood that and didn't bother patching
> > that '0' with a random seed exactly because of this.
>
> And I'm sorry for delivering a long lecture on a subject you already
> understood perfectly well.
I learned something, so your time wasn't completely wasted. ;)
> I'd just been thinking about it because of Herbert's comments, so it was
> conveniently at hand. :-)
>
> Out of curiousity, what *were* you referring to when you talked
> about biasing the crc32 function? "Biasing" is a good term becuase
> it just applies an offset, but what do you gain from doing that?
Actually, I don't know why the seed parameter was added. I just wanted
to mention that there is a way to bias the crc32 function which fits
into the style of the other hashing functions, like jhash with its
initval parameter.
I just kept it around during the rewrite.
The only use case I can imagine would be if one would like to calculate
a crc32c over a non-contiguous array, thus feeding the result of one crc
operation into the next one.
> There are nifty things one can do with the CRC32 instruction, however.
> A lot of ciphers these days use an ARX (add, rotate, XOR) kernel.
> A crc32 instruction, although linear, does some very powerful rotate &
> xor operations, and could replace the XOR and rotate.
Yes, I have seen it being used in cityhash.
There is also a proposal by Intel, but the hash seems too weak, too:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/hash-method-performance-paper.pdf
Bye,
Hannes
^ permalink raw reply
* Antw: Re: Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-08 16:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1418051901.15618.46.camel@edumazet-glaptop2.roam.corp.google.com>
>>> Eric Dumazet <eric.dumazet@gmail.com> schrieb am 08.12.2014 um 16:18 in
Nachricht <1418051901.15618.46.camel@edumazet-glaptop2.roam.corp.google.com>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>>
>> Hi!
>>
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>>
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>>
>> (The standard seems to say that extra connections are refused)
>>
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
>
> This 'standard' makes no sense to me, in light of SYNFLOOD attacks.
>
> It actually makes SYNFLOOD attacks very effective.
>
> Have you tried to disable syncookies for a start ?
No, I tries to temporarily close the listening socket. My priority is not to overload the server with connections. At the sime time I _want_ that the clients see that the server resfuses connections. Before you wonder: The client will actually be a load balancer.
^ permalink raw reply
* Re: [PATCH] drivers:atm Remove two FIXMES in the function, top_off_fp for the file, firestream.c
From: chas williams - CONTRACTOR @ 2014-12-08 16:20 UTC (permalink / raw)
To: Nicholas Krause; +Cc: linux-atm-general, netdev, linux-kernel
In-Reply-To: <1417923348-13807-1-git-send-email-xerofoify@gmail.com>
I don't see any reason to promote qe_tmp to a u64. I think you can
just remove the comment. Anyone trying to build this into a 64-bit
kernel will see errors from the virt_to_bus()/bus_to_virt() usage.
fp->n seems to only be manipulated in interrupt context (after driving
initialization) so it doesn't need locking or to be atomic.
On Sat, 6 Dec 2014 22:35:48 -0500
Nicholas Krause <xerofoify@gmail.com> wrote:
> Removes two FIXMES in the function.top_off_fp. The first being that of needing the variable, qe_tmp needing to be a
> u64 type and not u32 as encoding will not work if using a 32 bit register rather then 64 bit as stated in the first
> fix me comment. In addition the second being a no longer needed comment due to not needing to atomically increment
> the variable, n as passed to the function by the pointer of fp, as part of a structure of type,freepool.
>
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
> drivers/atm/firestream.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
> index 82f2ae0..06c23f6 100644
> --- a/drivers/atm/firestream.c
> +++ b/drivers/atm/firestream.c
> @@ -1477,7 +1477,7 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> struct FS_BPENTRY *qe, *ne;
> struct sk_buff *skb;
> int n = 0;
> - u32 qe_tmp;
> + u64 qe_tmp;
>
> fs_dprintk (FS_DEBUG_QUEUE, "Topping off queue at %x (%d-%d/%d)\n",
> fp->offset, read_fs (dev, FP_CNT (fp->offset)), fp->n,
> @@ -1505,14 +1505,8 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> ne->skb = skb;
> ne->fp = fp;
>
> - /*
> - * FIXME: following code encodes and decodes
> - * machine pointers (could be 64-bit) into a
> - * 32-bit register.
> - */
> -
> qe_tmp = read_fs (dev, FP_EA(fp->offset));
> - fs_dprintk (FS_DEBUG_QUEUE, "link at %x\n", qe_tmp);
> + fs_dprintk(FS_DEBUG_QUEUE, "link at %llx\n", qe_tmp);
> if (qe_tmp) {
> qe = bus_to_virt ((long) qe_tmp);
> qe->next = virt_to_bus(ne);
> @@ -1521,7 +1515,7 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> write_fs (dev, FP_SA(fp->offset), virt_to_bus(ne));
>
> write_fs (dev, FP_EA(fp->offset), virt_to_bus (ne));
> - fp->n++; /* XXX Atomic_inc? */
> + fp->n++;
> write_fs (dev, FP_CTU(fp->offset), 1);
> }
>
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: George Spelvin @ 2014-12-08 16:19 UTC (permalink / raw)
To: hannes, linux
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <1418037908.190744.200156353.5DD668E8@webmail.messagingengine.com>
>>> In case of openvswitch it shows a performance improvment. The seed
>>> parameter could be used as an initial biasing of the crc32 function, but
>>> in case of openvswitch it is only set to 0.
>> NACK. [...]
> Sorry for being unclear, I understood that and didn't bother patching
> that '0' with a random seed exactly because of this.
And I'm sorry for delivering a long lecture on a subject you already
understood perfectly well.
I'd just been thinking about it because of Herbert's comments, so it was
conveniently at hand. :-)
Out of curiousity, what *were* you referring to when you talked
about biasing the crc32 function? "Biasing" is a good term becuase
it just applies an offset, but what do you gain from doing that?
There are nifty things one can do with the CRC32 instruction, however.
A lot of ciphers these days use an ARX (add, rotate, XOR) kernel.
A crc32 instruction, although linear, does some very powerful rotate &
xor operations, and could replace the XOR and rotate.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rocker: remove swdev mode
From: Thomas Graf @ 2014-12-08 16:18 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jiri Pirko, roopa, sfeldma, jhs, bcrl, john.fastabend, stephen,
linville, vyasevic, netdev, davem, shm, gospo
In-Reply-To: <54858E6E.7010707@redhat.com>
On 12/08/14 at 12:41pm, Daniel Borkmann wrote:
> On 12/08/2014 12:03 PM, Jiri Pirko wrote:
> >well, I see no problem in using u16. IFLA_BRIDGE_MODE attr is u16 so
> >mode should stay u16.
> >
> >But maybe better to add:
> >#define BRIDGE_MODE_UNDEF 0xFFFF
>
> Yep, something along these lines seems better.
Using u16 is fine but then all occurences should use it as opposed
to mixed s16/u16 usage as in v3.
^ permalink raw reply
* Re: [PATCH net-next 2/3] netlink: IFLA_PHYS_SWITCH_ID to IFLA_PHYS_PARENT_ID
From: Andy Gospodarek @ 2014-12-08 15:37 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, sfeldma
In-Reply-To: <20141208151714.GG1885@nanopsycho.brq.redhat.com>
On Mon, Dec 08, 2014 at 04:17:14PM +0100, Jiri Pirko wrote:
> Fri, Dec 05, 2014 at 07:02:16PM CET, gospo@cumulusnetworks.com wrote:
> >There has been much discussion about proper nomenclature to use for this
> >and I would prefer parent rather than calling every forwarding element a
> >switch.
>
> Andy, I must say I really do not like just plain "parent". It is really
> not clear what it means as it can mean 1000 things.
>
> I know "switch" is not ideal but everytime anyone is talking about these
> kind of forwarding devices, they use word "switch" even if it is not
> accurate and everyone knows what they are talking about. Nobody uses
> "parent".
Well of course they are not going to use it until it's committed. ;-)
> For me this is nack for this patchset.
Thanks for the review. I am not big marketing person, so it was not
clear to me what was ideal. Due to parent already being in the code
and having as a logical description of the relationship (parent
switch/router device and sibling network interfaces -- like sibling CPU
cores on the same socket).
I do really want to collectively come up with something other than
switch for everything. Those L3 ops with 'switch' in the name will
feel really awkward....
>
> Jiri
>
> >
> >Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
> >---
> > include/uapi/linux/if_link.h | 2 +-
> > net/core/rtnetlink.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> >index f7d0d2d..3d8edd8 100644
> >--- a/include/uapi/linux/if_link.h
> >+++ b/include/uapi/linux/if_link.h
> >@@ -145,7 +145,7 @@ enum {
> > IFLA_CARRIER,
> > IFLA_PHYS_PORT_ID,
> > IFLA_CARRIER_CHANGES,
> >- IFLA_PHYS_SWITCH_ID,
> >+ IFLA_PHYS_PARENT_ID,
> > __IFLA_MAX
> > };
> >
> >diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> >index 61cb7e7..1fe0a16 100644
> >--- a/net/core/rtnetlink.c
> >+++ b/net/core/rtnetlink.c
> >@@ -982,7 +982,7 @@ static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
> > return err;
> > }
> >
> >- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
> >+ if (nla_put(skb, IFLA_PHYS_PARENT_ID, psid.id_len, psid.id))
> > return -EMSGSIZE;
> >
> > return 0;
> >@@ -1222,7 +1222,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
> > [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
> > [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> > [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
> >- [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> >+ [IFLA_PHYS_PARENT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> > };
> >
> > static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
> >--
> >1.9.3
> >
^ permalink raw reply
* [PATCH nf-next 2/2] netfilter: use conntrack rtcache if available
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer, Florian Westphal
In-Reply-To: <1418052964-4632-1-git-send-email-fw@strlen.de>
skip the reverse lookup if the iif matches the cached one.
In this case we know that a previous rpfilter check did not result
in packet drop.
This shortcut only works if rtcache is available and rule is placed
in mangle table (raw table is too early; skb->nfct will not be set).
While it would be possible to enforce rtcache, it would a)
force a dependency on conntrack and b) break backwards compatibility
since we'd have to restrict it to mangle table.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/net/netfilter/nf_conntrack_rtcache.h | 12 +++++++++++
net/ipv4/netfilter/ipt_rpfilter.c | 4 +++-
net/ipv6/netfilter/ip6t_rpfilter.c | 4 +++-
net/netfilter/core.c | 30 ++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_rtcache.h b/include/net/netfilter/nf_conntrack_rtcache.h
index e2fb302..19265ad 100644
--- a/include/net/netfilter/nf_conntrack_rtcache.h
+++ b/include/net/netfilter/nf_conntrack_rtcache.h
@@ -27,6 +27,18 @@ struct nf_conn_rtcache *nf_ct_rtcache_find(const struct nf_conn *ct)
#endif
}
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+bool nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev);
+#else
+static inline bool
+nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ return false;
+}
+#endif
+
static inline int nf_conn_rtcache_iif_get(const struct nf_conn_rtcache *rtc,
enum ip_conntrack_dir dir)
{
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index 4bfaedf..f39e934 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -19,6 +19,8 @@
#include <linux/netfilter/xt_rpfilter.h>
#include <linux/netfilter/x_tables.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
MODULE_DESCRIPTION("iptables: ipv4 reverse path filter match");
@@ -82,7 +84,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
info = par->matchinfo;
invert = info->flags & XT_RPFILTER_INVERT;
- if (rpfilter_is_local(skb))
+ if (rpfilter_is_local(skb) || nf_conn_rtcache_match_dev(skb, par->in))
return true ^ invert;
iph = ip_hdr(skb);
diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c b/net/ipv6/netfilter/ip6t_rpfilter.c
index 790e0c6..8db9fe7 100644
--- a/net/ipv6/netfilter/ip6t_rpfilter.c
+++ b/net/ipv6/netfilter/ip6t_rpfilter.c
@@ -16,6 +16,8 @@
#include <linux/netfilter/xt_rpfilter.h>
#include <linux/netfilter/x_tables.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
MODULE_DESCRIPTION("Xtables: IPv6 reverse path filter match");
@@ -85,7 +87,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
struct ipv6hdr *iph;
bool invert = info->flags & XT_RPFILTER_INVERT;
- if (rpfilter_is_local(skb))
+ if (rpfilter_is_local(skb) || nf_conn_rtcache_match_dev(skb, par->in))
return true ^ invert;
iph = ipv6_hdr(skb);
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index fea9ef5..651b4c6 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -25,6 +25,8 @@
#include <net/net_namespace.h>
#include <net/sock.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
#include "nf_internals.h"
static DEFINE_MUTEX(afinfo_mutex);
@@ -267,6 +269,34 @@ EXPORT_SYMBOL_GPL(nfq_ct_hook);
struct nfq_ct_nat_hook __rcu *nfq_ct_nat_hook __read_mostly;
EXPORT_SYMBOL_GPL(nfq_ct_nat_hook);
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+/* returns true if dev matches the last recorded
+ * input interface of the conntrack attached to skb.
+ *
+ * This is not in conntrack to avoid module dependency.
+ */
+bool nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct nf_conn *ct;
+ int iif;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ rtc = nf_ct_rtcache_find(ct);
+ if (!rtc)
+ return false;
+
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+
+ return iif == dev->ifindex;
+}
+EXPORT_SYMBOL_GPL(nf_conn_rtcache_match_dev);
+#endif
+
#endif /* CONFIG_NF_CONNTRACK */
#ifdef CONFIG_NF_NAT_NEEDED
--
2.0.4
^ permalink raw reply related
* [PATCH nf-next 0/2] netfilter: conntrack: route cache for forwarded connections
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer
[ Pablo, in case you deem this too late for -next just let me know
and I will resend once its open again ]
This adds an optional forward routing cache extension for netfilter
connection tracking.
The memory cost is an additional 32 bytes per conntrack entry
on x86_64.
Unlike any other currently implemented connection tracking
extension the rtcache has no run-time tunables, it is always active.
Also, unlike other conntrack extensions, it can be built as a module,
in this case modprobe/rmmod are used to enable/disable the cache.
Forward test using netperf UDP_STREAM between two network namespaces
(connected via veth devices), tput:
With conntrack + reverse path filtering (rp_filter sysctl=1):
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.12.2 () port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 64 120.00 26333996 0 112.36
212992 120.00 26279399 112.13
same, but with rtcache (this patch series):
212992 64 120.00 34508693 0 147.24
212992 120.00 34507838 147.23
same but with rp_filter=0 and no conntrack modules active:
212992 64 120.00 42288748 0 180.43
212992 120.00 42283439 180.41
IOW, this is only useful if conntrack is used anyway.
^ permalink raw reply
* [PATCH nf-next 1/2] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer, Florian Westphal
In-Reply-To: <1418052964-4632-1-git-send-email-fw@strlen.de>
... to avoid per-packet FIB lookup if possible.
The cached dst is re-used provided the input interface
is the same as that of the previous packet in the same direction.
If not, the cached dst is invalidated.
For ipv6 we also need to store sernum, else dst_check doesn't work,
pointed out by Eric Dumazet.
This should speed up forwarding when conntrack is already in use
anyway, especially when using reverse path filtering -- active RPF
enforces two FIB lookups for each packet.
Before the routing cache removal this didn't matter since RPF was performed
only when route cache didn't yield a result; but without route cache it
comes at higher price.
Julian Anastasov suggested to add NETDEV_UNREGISTER handler to
avoid holding on to dsts of 'frozen' conntracks.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
Changes since RFC:
- add NETDEV_UNREGISTER, suggested by Julian
- cache fib sernum to make ipv6 work, pointed out by Eric
- make module unload work
- remove ASSURED test, in case of -j DROP in prerouting or forward
cache forward hook won't be reached anyway
include/net/netfilter/nf_conntrack_extend.h | 4 +
include/net/netfilter/nf_conntrack_rtcache.h | 34 +++
net/netfilter/Kconfig | 12 +
net/netfilter/Makefile | 3 +
net/netfilter/nf_conntrack_rtcache.c | 387 +++++++++++++++++++++++++++
5 files changed, 440 insertions(+)
create mode 100644 include/net/netfilter/nf_conntrack_rtcache.h
create mode 100644 net/netfilter/nf_conntrack_rtcache.c
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 55d1504..1b00d57 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -30,6 +30,9 @@ enum nf_ct_ext_id {
#if IS_ENABLED(CONFIG_NETFILTER_SYNPROXY)
NF_CT_EXT_SYNPROXY,
#endif
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+ NF_CT_EXT_RTCACHE,
+#endif
NF_CT_EXT_NUM,
};
@@ -43,6 +46,7 @@ enum nf_ct_ext_id {
#define NF_CT_EXT_TIMEOUT_TYPE struct nf_conn_timeout
#define NF_CT_EXT_LABELS_TYPE struct nf_conn_labels
#define NF_CT_EXT_SYNPROXY_TYPE struct nf_conn_synproxy
+#define NF_CT_EXT_RTCACHE_TYPE struct nf_conn_rtcache
/* Extensions: optional stuff which isn't permanently in struct. */
struct nf_ct_ext {
diff --git a/include/net/netfilter/nf_conntrack_rtcache.h b/include/net/netfilter/nf_conntrack_rtcache.h
new file mode 100644
index 0000000..e2fb302
--- /dev/null
+++ b/include/net/netfilter/nf_conntrack_rtcache.h
@@ -0,0 +1,34 @@
+#include <linux/gfp.h>
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+
+struct dst_entry;
+
+struct nf_conn_dst_cache {
+ struct dst_entry *dst;
+ int iif;
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ u32 cookie;
+#endif
+
+};
+
+struct nf_conn_rtcache {
+ struct nf_conn_dst_cache cached_dst[IP_CT_DIR_MAX];
+};
+
+static inline
+struct nf_conn_rtcache *nf_ct_rtcache_find(const struct nf_conn *ct)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+ return nf_ct_ext_find(ct, NF_CT_EXT_RTCACHE);
+#else
+ return NULL;
+#endif
+}
+
+static inline int nf_conn_rtcache_iif_get(const struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ return rtc->cached_dst[dir].iif;
+}
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index b02660f..c213a61 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -106,6 +106,18 @@ config NF_CONNTRACK_EVENTS
If unsure, say `N'.
+config NF_CONNTRACK_RTCACHE
+ tristate "Cache route entries in conntrack objects"
+ depends on NETFILTER_ADVANCED
+ depends on NF_CONNTRACK
+ help
+ If this option is enabled, the connection tracking code will
+ cache routing information for each connection that is being
+ forwarded, at a cost of 32 bytes per conntrack object.
+
+ To compile it as a module, choose M here. If unsure, say N.
+ The module will be called nf_conntrack_rtcache.
+
config NF_CONNTRACK_TIMEOUT
bool 'Connection tracking timeout'
depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 89f73a9..c174ab2 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -18,6 +18,9 @@ obj-$(CONFIG_NETFILTER_NETLINK_LOG) += nfnetlink_log.o
# connection tracking
obj-$(CONFIG_NF_CONNTRACK) += nf_conntrack.o
+# optional conntrack route cache extension
+obj-$(CONFIG_NF_CONNTRACK_RTCACHE) += nf_conntrack_rtcache.o
+
# SCTP protocol connection tracking
obj-$(CONFIG_NF_CT_PROTO_DCCP) += nf_conntrack_proto_dccp.o
obj-$(CONFIG_NF_CT_PROTO_GRE) += nf_conntrack_proto_gre.o
diff --git a/net/netfilter/nf_conntrack_rtcache.c b/net/netfilter/nf_conntrack_rtcache.c
new file mode 100644
index 0000000..65fef44
--- /dev/null
+++ b/net/netfilter/nf_conntrack_rtcache.c
@@ -0,0 +1,387 @@
+/* route cache for netfilter.
+ *
+ * (C) 2014 Red Hat GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/types.h>
+#include <linux/netfilter.h>
+#include <linux/skbuff.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/export.h>
+#include <linux/module.h>
+
+#include <net/dst.h>
+
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_core.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+#include <net/ip6_fib.h>
+#endif
+
+static void __nf_conn_rtcache_destroy(struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ struct dst_entry *dst = rtc->cached_dst[dir].dst;
+
+ dst_release(dst);
+}
+
+static void nf_conn_rtcache_destroy(struct nf_conn *ct)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+
+ if (!rtc)
+ return;
+
+ __nf_conn_rtcache_destroy(rtc, IP_CT_DIR_ORIGINAL);
+ __nf_conn_rtcache_destroy(rtc, IP_CT_DIR_REPLY);
+}
+
+static void nf_ct_rtcache_ext_add(struct nf_conn *ct)
+{
+ struct nf_conn_rtcache *rtc;
+
+ rtc = nf_ct_ext_add(ct, NF_CT_EXT_RTCACHE, GFP_ATOMIC);
+ if (rtc) {
+ rtc->cached_dst[IP_CT_DIR_ORIGINAL].iif = -1;
+ rtc->cached_dst[IP_CT_DIR_ORIGINAL].dst = NULL;
+ rtc->cached_dst[IP_CT_DIR_REPLY].iif = -1;
+ rtc->cached_dst[IP_CT_DIR_REPLY].dst = NULL;
+ }
+}
+
+static struct nf_conn_rtcache *nf_ct_rtcache_find_usable(struct nf_conn *ct)
+{
+ if (nf_ct_is_untracked(ct))
+ return NULL;
+ return nf_ct_rtcache_find(ct);
+}
+
+static struct dst_entry *
+nf_conn_rtcache_dst_get(const struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ return rtc->cached_dst[dir].dst;
+}
+
+static u32 nf_rtcache_get_cookie(int pf, const struct dst_entry *dst)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ if (pf == NFPROTO_IPV6) {
+ const struct rt6_info *rt = (const struct rt6_info *)dst;
+
+ if (rt->rt6i_node)
+ return (u32)rt->rt6i_node->fn_sernum;
+ }
+#endif
+ return 0;
+}
+
+static void nf_conn_rtcache_dst_set(int pf,
+ struct nf_conn_rtcache *rtc,
+ struct dst_entry *dst,
+ enum ip_conntrack_dir dir, int iif)
+{
+ if (rtc->cached_dst[dir].iif != iif)
+ rtc->cached_dst[dir].iif = iif;
+
+ if (rtc->cached_dst[dir].dst != dst) {
+ struct dst_entry *old;
+
+ dst_hold(dst);
+
+ old = xchg(&rtc->cached_dst[dir].dst, dst);
+ dst_release(old);
+
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ if (pf == NFPROTO_IPV6)
+ rtc->cached_dst[dir].cookie =
+ nf_rtcache_get_cookie(pf, dst);
+#endif
+ }
+}
+
+static void nf_conn_rtcache_dst_obsolete(struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ struct dst_entry *old;
+
+ pr_debug("Invalidate iif %d for dir %d on cache %p\n",
+ rtc->cached_dst[dir].iif, dir, rtc);
+
+ old = xchg(&rtc->cached_dst[dir].dst, NULL);
+ dst_release(old);
+ rtc->cached_dst[dir].iif = -1;
+}
+
+static unsigned int nf_rtcache_in(const struct nf_hook_ops *ops,
+ struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct dst_entry *dst;
+ struct nf_conn *ct;
+ int iif;
+ u32 cookie;
+
+ if (skb_dst(skb) || skb->sk)
+ return NF_ACCEPT;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct)
+ return NF_ACCEPT;
+
+ rtc = nf_ct_rtcache_find_usable(ct);
+ if (!rtc)
+ return NF_ACCEPT;
+
+ /* if iif changes, don't use cache and let ip stack
+ * do route lookup.
+ *
+ * If rp_filter is enabled it might toss skb, so
+ * we don't want to avoid these checks.
+ */
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+ if (in->ifindex != iif) {
+ pr_debug("ct %p, iif %d, cached iif %d, skip cached entry\n",
+ ct, iif, in->ifindex);
+ return NF_ACCEPT;
+ }
+ dst = nf_conn_rtcache_dst_get(rtc, dir);
+ if (dst == NULL)
+ return NF_ACCEPT;
+
+ cookie = nf_rtcache_get_cookie(ops->pf, dst);
+
+ dst = dst_check(dst, cookie);
+ pr_debug("obtained dst %p for skb %p, cookie %d\n", dst, skb, cookie);
+ if (likely(dst))
+ skb_dst_set_noref_force(skb, dst);
+ else
+ nf_conn_rtcache_dst_obsolete(rtc, dir);
+
+ return NF_ACCEPT;
+}
+
+static unsigned int nf_rtcache_forward(const struct nf_hook_ops *ops,
+ struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct nf_conn *ct;
+ int iif;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct)
+ return NF_ACCEPT;
+
+ if (!nf_ct_is_confirmed(ct)) {
+ if (WARN_ON(nf_ct_rtcache_find(ct)))
+ return NF_ACCEPT;
+ nf_ct_rtcache_ext_add(ct);
+ return NF_ACCEPT;
+ }
+
+ rtc = nf_ct_rtcache_find_usable(ct);
+ if (!rtc)
+ return NF_ACCEPT;
+
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+ pr_debug("ct %p, skb %p, dir %d, iif %d, cached iif %d\n",
+ ct, skb, dir, iif, in->ifindex);
+ if (likely(in->ifindex == iif))
+ return NF_ACCEPT;
+
+ nf_conn_rtcache_dst_set(ops->pf, rtc, skb_dst(skb), dir, in->ifindex);
+ return NF_ACCEPT;
+}
+
+static int nf_rtcache_dst_remove(struct nf_conn *ct, void *data)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+ struct net_device *dev = data;
+
+ if (!rtc)
+ return 0;
+
+ if (dev->ifindex == rtc->cached_dst[IP_CT_DIR_ORIGINAL].iif ||
+ dev->ifindex == rtc->cached_dst[IP_CT_DIR_REPLY].iif) {
+ nf_conn_rtcache_dst_obsolete(rtc, IP_CT_DIR_ORIGINAL);
+ nf_conn_rtcache_dst_obsolete(rtc, IP_CT_DIR_REPLY);
+ }
+
+ return 0;
+}
+
+static int nf_rtcache_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+ struct net *net = dev_net(dev);
+
+ if (event == NETDEV_DOWN)
+ nf_ct_iterate_cleanup(net, nf_rtcache_dst_remove, dev, 0, 0);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block nf_rtcache_notifier = {
+ .notifier_call = nf_rtcache_netdev_event,
+};
+
+static struct nf_hook_ops rtcache_ops[] = {
+ {
+ .hook = nf_rtcache_in,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV4,
+ .hooknum = NF_INET_PRE_ROUTING,
+ .priority = NF_IP_PRI_LAST,
+ },
+ {
+ .hook = nf_rtcache_forward,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV4,
+ .hooknum = NF_INET_FORWARD,
+ .priority = NF_IP_PRI_LAST,
+ },
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ {
+ .hook = nf_rtcache_in,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV6,
+ .hooknum = NF_INET_PRE_ROUTING,
+ .priority = NF_IP_PRI_LAST,
+ },
+ {
+ .hook = nf_rtcache_forward,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV6,
+ .hooknum = NF_INET_FORWARD,
+ .priority = NF_IP_PRI_LAST,
+ },
+#endif
+};
+
+static struct nf_ct_ext_type rtcache_extend __read_mostly = {
+ .len = sizeof(struct nf_conn_rtcache),
+ .align = __alignof__(struct nf_conn_rtcache),
+ .id = NF_CT_EXT_RTCACHE,
+ .destroy = nf_conn_rtcache_destroy,
+};
+
+static int __init nf_conntrack_rtcache_init(void)
+{
+ int ret = nf_ct_extend_register(&rtcache_extend);
+
+ if (ret < 0) {
+ pr_err("nf_conntrack_rtcache: Unable to register extension\n");
+ return ret;
+ }
+
+ ret = nf_register_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+ if (ret < 0) {
+ nf_ct_extend_unregister(&rtcache_extend);
+ return ret;
+ }
+
+ ret = register_netdevice_notifier(&nf_rtcache_notifier);
+ if (ret) {
+ nf_unregister_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+ nf_ct_extend_unregister(&rtcache_extend);
+ }
+
+ return ret;
+}
+
+static int nf_rtcache_ext_remove(struct nf_conn *ct, void *data)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+
+ return rtc != NULL;
+}
+
+static bool __exit nf_conntrack_rtcache_wait_for_dying(struct net *net)
+{
+ bool wait = false;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ struct nf_conntrack_tuple_hash *h;
+ struct hlist_nulls_node *n;
+ struct nf_conn *ct;
+ struct ct_pcpu *pcpu = per_cpu_ptr(net->ct.pcpu_lists, cpu);
+
+ rcu_read_lock();
+ spin_lock_bh(&pcpu->lock);
+
+ hlist_nulls_for_each_entry(h, n, &pcpu->dying, hnnode) {
+ ct = nf_ct_tuplehash_to_ctrack(h);
+ if (nf_ct_rtcache_find(ct) != NULL) {
+ wait = true;
+ break;
+ }
+ }
+ spin_unlock_bh(&pcpu->lock);
+ rcu_read_unlock();
+ }
+
+ return wait;
+}
+
+static void __exit nf_conntrack_rtcache_fini(void)
+{
+ struct net *net;
+ int count = 0;
+
+ /* remove hooks so no new connections get rtcache extension */
+ nf_unregister_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+
+ synchronize_net();
+
+ unregister_netdevice_notifier(&nf_rtcache_notifier);
+
+ rtnl_lock();
+
+ /* zap all conntracks with rtcache extension */
+ for_each_net(net)
+ nf_ct_iterate_cleanup(net, nf_rtcache_ext_remove, NULL, 0, 0);
+
+ for_each_net(net) {
+ /* .. and make sure they're gone from dying list, too */
+ while (nf_conntrack_rtcache_wait_for_dying(net)) {
+ msleep(200);
+ WARN_ONCE(++count > 25, "Waiting for all rtcache conntracks to go away\n");
+ }
+ }
+
+ rtnl_unlock();
+ synchronize_net();
+ nf_ct_extend_unregister(&rtcache_extend);
+}
+module_init(nf_conntrack_rtcache_init);
+module_exit(nf_conntrack_rtcache_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
+MODULE_DESCRIPTION("Conntrack route cache extension");
--
2.0.4
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-08 15:35 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412081622.25541@pali>
On Mon, Dec 8, 2014 at 11:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 08 December 2014 16:18:18 Ming Lei wrote:
>> On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>> > /**
>> >
>> > + * request_firmware_prefer_user: - prefer usermode helper
>> > for loading firmware + * @firmware_p: pointer to firmware
>> > image
>> > + * @name: name of firmware file
>> > + * @device: device for which firmware is being loaded
>> > + *
>> > + * This function works pretty much like request_firmware(),
>> > but it prefer + * usermode helper. If usermode helper fails
>> > then it fallback to direct access. + * Usefull for dynamic
>> > or model specific firmware data. + **/
>> > +int request_firmware_prefer_user(const struct firmware
>> > **firmware_p, + const char *name,
>> > struct device *device) +{
>> > + int ret;
>> > + __module_get(THIS_MODULE);
>> > + ret = _request_firmware(firmware_p, name, device,
>> > + FW_OPT_UEVENT |
>> > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
>> > + return ret;
>> > +}
>> > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>>
>> I'd like to introduce request_firmware_user() which only
>> requests firmware from user space, and this way is simpler
>> and more flexible since we have request_firmware_direct()
>> already.
>>
>> Thanks,
>> Ming Lei
>
> Ming, for wl1251 NVS data we need to load use usermode helper and
> fallback to direct load. So I think it is better to handle this
> request in firmware code and not in driver.
Please do that in driver and don't mess firmware loader.
With introducing request_firmware_user(), it is even possible to
clean up firmware loader further.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH] bridge: Remove BR_PROXYARP flooding check code
From: Jouni Malinen @ 2014-12-08 15:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Kyeyoon Park, Jouni Malinen
From: Kyeyoon Park <kyeyoonp@codeaurora.org>
Because dropping broadcast packets for IEEE 802.11 Proxy ARP is more
selective than previously thought, it is better to remove the direct
dropping logic in the bridge code in favor of using the netfilter
infrastructure to provide more control on which frames get dropped. This
code was added in commit 958501163ddd ("bridge: Add support for IEEE
802.11 Proxy ARP").
Signed-off-by: Kyeyoon Park <kyeyoonp@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
---
net/bridge/br_forward.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index f96933a..8a025a7 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -185,10 +185,6 @@ static void br_flood(struct net_bridge *br, struct sk_buff *skb,
if (unicast && !(p->flags & BR_FLOOD))
continue;
- /* Do not flood to ports that enable proxy ARP */
- if (p->flags & BR_PROXYARP)
- continue;
-
prev = maybe_deliver(prev, p, skb, __packet_hook);
if (IS_ERR(prev))
goto out;
--
1.9.1
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 15:22 UTC (permalink / raw)
To: Ming Lei
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <CACVXFVPOLfDuqc0nLb-zM8vH618DLXy0xtZbUOn5_XvdxRZSDw@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1626 bytes --]
On Monday 08 December 2014 16:18:18 Ming Lei wrote:
> On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
<pali.rohar@gmail.com> wrote:
> > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> > /**
> >
> > + * request_firmware_prefer_user: - prefer usermode helper
> > for loading firmware + * @firmware_p: pointer to firmware
> > image
> > + * @name: name of firmware file
> > + * @device: device for which firmware is being loaded
> > + *
> > + * This function works pretty much like request_firmware(),
> > but it prefer + * usermode helper. If usermode helper fails
> > then it fallback to direct access. + * Usefull for dynamic
> > or model specific firmware data. + **/
> > +int request_firmware_prefer_user(const struct firmware
> > **firmware_p, + const char *name,
> > struct device *device) +{
> > + int ret;
> > + __module_get(THIS_MODULE);
> > + ret = _request_firmware(firmware_p, name, device,
> > + FW_OPT_UEVENT |
> > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>
> I'd like to introduce request_firmware_user() which only
> requests firmware from user space, and this way is simpler
> and more flexible since we have request_firmware_direct()
> already.
>
> Thanks,
> Ming Lei
Ming, for wl1251 NVS data we need to load use usermode helper and
fallback to direct load. So I think it is better to handle this
request in firmware code and not in driver.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Q: need effective backlog for listen()
From: Eric Dumazet @ 2014-12-08 15:18 UTC (permalink / raw)
To: Ulrich Windl; +Cc: netdev
In-Reply-To: <5485ACC9020000A100018394@gwsmtp1.uni-regensburg.de>
On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
> (not subscribed to the list, plese keep me on CC:)
>
> Hi!
>
> I have a problem I could not find the answer. I suspect the problem
> arises from Linux derivating from standard functionality...
>
> I have written a server that should accept n TCP connections at most.
> I was expecting that the backlog parameter of listen will cause extra
> connection requests either
> 1) to be refused
> or
> 2) to time out eventually
>
> (The standard seems to say that extra connections are refused)
>
> However none of the above see ms true. Even if my server delays
> accept()ing new connections, no client ever sees a "connection
> refused" or "connection timed out". Is there any chance to signal the
> client that no more connections are accepted at the moment?
This 'standard' makes no sense to me, in light of SYNFLOOD attacks.
It actually makes SYNFLOOD attacks very effective.
Have you tried to disable syncookies for a start ?
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-08 15:18 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412061402.21514@pali>
On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>
> /**
> + * request_firmware_prefer_user: - prefer usermode helper for loading firmware
> + * @firmware_p: pointer to firmware image
> + * @name: name of firmware file
> + * @device: device for which firmware is being loaded
> + *
> + * This function works pretty much like request_firmware(), but it prefer
> + * usermode helper. If usermode helper fails then it fallback to direct access.
> + * Usefull for dynamic or model specific firmware data.
> + **/
> +int request_firmware_prefer_user(const struct firmware **firmware_p,
> + const char *name, struct device *device)
> +{
> + int ret;
> + __module_get(THIS_MODULE);
> + ret = _request_firmware(firmware_p, name, device,
> + FW_OPT_UEVENT | FW_OPT_PREFER_USER);
> + module_put(THIS_MODULE);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
I'd like to introduce request_firmware_user() which only requests
firmware from user space, and this way is simpler and more flexible
since we have request_firmware_direct() already.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH net-next 2/3] netlink: IFLA_PHYS_SWITCH_ID to IFLA_PHYS_PARENT_ID
From: Jiri Pirko @ 2014-12-08 15:17 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, sfeldma, jpirko
In-Reply-To: <1417802537-20020-2-git-send-email-gospo@cumulusnetworks.com>
Fri, Dec 05, 2014 at 07:02:16PM CET, gospo@cumulusnetworks.com wrote:
>There has been much discussion about proper nomenclature to use for this
>and I would prefer parent rather than calling every forwarding element a
>switch.
Andy, I must say I really do not like just plain "parent". It is really
not clear what it means as it can mean 1000 things.
I know "switch" is not ideal but everytime anyone is talking about these
kind of forwarding devices, they use word "switch" even if it is not
accurate and everyone knows what they are talking about. Nobody uses
"parent".
For me this is nack for this patchset.
Jiri
>
>Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>---
> include/uapi/linux/if_link.h | 2 +-
> net/core/rtnetlink.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>index f7d0d2d..3d8edd8 100644
>--- a/include/uapi/linux/if_link.h
>+++ b/include/uapi/linux/if_link.h
>@@ -145,7 +145,7 @@ enum {
> IFLA_CARRIER,
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
>- IFLA_PHYS_SWITCH_ID,
>+ IFLA_PHYS_PARENT_ID,
> __IFLA_MAX
> };
>
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index 61cb7e7..1fe0a16 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -982,7 +982,7 @@ static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
> return err;
> }
>
>- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
>+ if (nla_put(skb, IFLA_PHYS_PARENT_ID, psid.id_len, psid.id))
> return -EMSGSIZE;
>
> return 0;
>@@ -1222,7 +1222,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
> [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
> [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>- [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>+ [IFLA_PHYS_PARENT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> };
>
> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>--
>1.9.3
>
^ permalink raw reply
* Re: [PATCH][net-next] net: avoid to call skb_queue_len again
From: Eric Dumazet @ 2014-12-08 15:10 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Li RongQing, netdev
In-Reply-To: <54858B56.1020607@cogentembedded.com>
On Mon, 2014-12-08 at 14:28 +0300, Sergei Shtylyov wrote:
>
> I expect you to also refine the description, so that it's meaningful,
> unlike now.
It seems obvious to me Li is not a native English speaker. I understood
the patch very well, and the changelog seemed fine to me.
What about you provide this description instead, since you seem to care
very much ?
Thanks !
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-12-08 14:42 UTC (permalink / raw)
To: David Laight
Cc: 'Eric Dumazet', David Miller, weiyang@linux.vnet.ibm.com,
netdev@vger.kernel.org, gideonn@mellanox.com, edumazet@google.com,
amirv@mellanox.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA04A51@AcuExch.aculab.com>
On Mon, Dec 08, 2014 at 10:00:19AM +0000, David Laight wrote:
>From: Eric Dumazet
>> On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
>>
>> > Guys, let's figure out what we are doing with this patch.
>> > --
>>
>> Oh well, patch is fine, please apply it, thanks !
>
>I'm not to sure that the patch doesn't generate a software byteswap
>followed by a byteswapping write on ppc - clearly not ideal.
>It might even generate back to back software byteswaps.
>
>If the write to the doorbell register includes a byteswap on BE (ppc)
>then there is no real value in keeping the value as BE.
>
>OTOH ppc ought to have ways of doing IO writes without the byteswap
>(and byteswapping accesses to non-io memory for that matter).
>
>What happens on a BE system with BE peripherals is another matter.
David
Thanks for your comment.
How about use __raw_writel() to replace the iowrite32()? Looks this is better,
if so, I will make up another version for this.
>
> David
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-08 12:51 UTC (permalink / raw)
To: netdev
(not subscribed to the list, plese keep me on CC:)
Hi!
I have a problem I could not find the answer. I suspect the problem arises from Linux derivating from standard functionality...
I have written a server that should accept n TCP connections at most. I was expecting that the backlog parameter of listen will cause extra connection requests either
1) to be refused
or
2) to time out eventually
(The standard seems to say that extra connections are refused)
However none of the above see ms true. Even if my server delays accept()ing new connections, no client ever sees a "connection refused" or "connection timed out". Is there any chance to signal the client that no more connections are accepted at the moment?
Regards,
Ulrich Windl
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Yoshihiro Kaneko @ 2014-12-08 12:16 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, David S. Miller, Simon Horman, Magnus Damm, Linux-sh list
In-Reply-To: <54858FCD.3080206@cogentembedded.com>
Hello Sergei,
2014-12-08 20:47 GMT+09:00 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Hello.
>
> On 12/8/2014 1:48 PM, Yoshihiro Kaneko wrote:
>
>> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
>
>> Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
>> the reception loop.
>> In order to cut down redundant processing, this patch changes excess
>> judgement.
>
>
>> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>
>
>> This patch is based on net-next tree.
>
>
>> v2 [Yoshihiro Kaneko]
>> * re-spin for net-next.
>> * remove unneeded check of "quota".
>
>
> This is not a complete list. :-/
Sorry, I'll update on the next time.
>
>> drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>> b/drivers/net/ethernet/renesas/sh_eth.c
>> index dbe8606..266c9b2 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>
> [...]
>>
>> @@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32
>> intr_status, int *quota)
>> sh_eth_write(ndev, EDRRR_R, EDRRR);
>> }
>>
>> + *quota -= limit - boguscnt + 1;
>> +
>
>
> Sorry for the wrong previous suggestion, it clearly should have been -1,
> not +1. :-<
Oh, I agree.
Thanks,
Kaneko
>
> [...]
>
> WBR, Sergei
>
^ 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