* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:12 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, apw, Greg KH, Jan-Bernd Themann, linux-kernel,
linuxppc-dev, netdev, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <OF64B9886B.CE795DED-ONC12573EF.002FFA8B-C12573EF.00301683@de.ibm.com>
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > Constraints imposed by HW / FW:
> > > - eHEA has own MMU
> > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> virtual
> > > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > > - The number of MRs is limited (not enough to have one MR per packet)
> >
> > Are there enough to have one per 16MB section?
>
> Unfortunately this won't work. This was one of our first ideas we tossed
> out,
> but the number of MRs will not be sufficient.
Can you give a ballpark of how many there are to work with? 10? 100?
1000?
> We understand that the add/remove area is not as
> settled in the kernel like for example f_ops ;-)
> Are there already base working assumptions which are very unlikely to
> change?
If you use good interfaces, and someone changes them, they'll likely
also fix your driver.
If you use bad interfaces, people may not even notice when they break.
As I showed you with those compile failures, you're using bad interfaces
that don't even compile on some .configs.
> I'm a little confused here....
> ...the existing add/remove code depends on sparse mem.
> Other pieces on the POWER6 version of the architecture do as well.
> So we could either chose to disable add/remove if sparsemem is not there,
> or disable the driver by Kconfig in this case.
Technically, you can do this. But, it's not a sign of a professionally
written driver that is going to get its patches accepted into mainline.
Technically, you can also use lots of magic numbers and not obey
CodingStyle. But, you'll probably get review comments asking you to
change it.
> > > - a way to iterate over all kernel pages and a way to detect holes in
> the
> > > kernel memory layout in order to build up our own ehea_bmap.
> >
> > Look at kernel/resource.c
> >
> > But, I'm really not convinced that you can actually keep this map
> > yourselves. It's not as simple as you think. What happens if you get
> > on an LPAR with two sections, one 256MB@0x0 and another
> > 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> > array will eat all of memory.
> I'm glad you mention this part. There are many algorithms out there to
> handle this problem,
> hashes/trees/... all of these trade speed for smaller memory footprint.
> We based the table decission on the existing implementations of the
> architecture.
> Do you see such a case coming along for the next generation POWER systems?
Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
memory to it. Then, remove all of the sections of memory in the middle.
You'll be left with a very sparse memory configuration that we *DO*
handle today in the core VM. We handle it quite well, actually.
The hypervisor does not shrink memory from the top down. It pulls
things out of the middle and shuffles things around. In fact, a NUMA
node's memory isn't even contiguous.
Your code will OOM the machine in this case. I consider the ehea driver
buggy in this regard.
> I would guess these drastic changes would also require changes in base
> kernel.
No, we actually solved those a couple years ago.
> Will you provide a generic mapping system with a contiguous virtual address
> space
> like the ehea_bmap we can query? This would need to be a "stable" part of
> the implementation,
> including translation functions from kernel to nextgen_ehea_generic_bmap
> like virt_to_abs.
Yes, that's a real possibility, especially if some other users for it
come forward. We could definitely add something like that to the
generic code. But, you'll have to be convincing that what we have now
is insufficient.
Does this requirement:
"- MRs cover a contiguous virtual memory block (no holes)"
come from the hardware?
Is that *EACH* MR? OR all MRs?
Where does EHEA_BUSMAP_START come from? Is that defined in the
hardware? Have you checked to ensure that no other users might want a
chunk of memory in that area?
Can you query the existing MRs? Not change them in place, but can you
query their contents?
> > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> > in the core, so that we can deal with these kinds of problems, once and
> > *NOT* in every single little driver out there.
> >
> > > Functions to use while building ehea_bmap + MRs:
> > > - Use either the functions that are used by the memory hotplug system
> as
> > > well, that means using the section defines + functions
> (section_nr_to_pfn,
> > > pfn_valid)
> >
> > Basically, you can't use anything related to sections outside of the
> > core code. You can use things like pfn_valid(), or you can create new
> > interfaces that are properly abstracted.
>
> We picked sections instead of PFNs because this keeps the ehea_bmap in a
> reasonable range
> on the existing systems.
> But if you provide a abstract method handling exactly the problem we
> mention
> we'll be happy to use that and dump our private implementation.
One thing you can guarantee today is that things are contiguous up to
MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
much more appropriate than using sparsemem. We could also give you a
nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
that's what you really want.
> > > - Use currently other not exported functions in kernel/resource.c, like
> > > walk_memory_resource (where we would still need the maximum
> > possible number
> > > of pages NR_MEM_SECTIONS)
> >
> > It isn't the act of exporting that's the problem. It's making sure that
> > the exports won't be prone to abuse and that people are using them
> > properly. You should assume that you can export and use
> > walk_memory_resource().
>
> So this seems to come down to a basic question:
> New hardware seems to have a tendency to get "private MMUs",
> which need private mappings from the kernel address space into a
> "HW defined address space with potentially unique characteristics"
> RDMA in Openfabrics with global MR is the most prominent example heading
> there
That's not a question. ;)
Please explain to me why walk_memory_resource() is insufficient for your
needs. I've now pointed it out to you at least 3 times.
> > Do you know what other operating systems do with this hardware?
>
> We're not aware of another open source Operating system trying to address
> this topic.
What about AIX? Do you know who wrote its driver? Perhaps you should
go ask them.
-- Dave
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Paul E. McKenney @ 2008-02-14 17:08 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: linux-kernel, shemminger, davem, netdev, dipankar, herbert, akpm
In-Reply-To: <20080214033209.GA7266@in.ibm.com>
On Thu, Feb 14, 2008 at 09:02:09AM +0530, Gautham R Shenoy wrote:
> On Wed, Feb 13, 2008 at 02:05:15PM -0800, Paul E. McKenney wrote:
> > Hello again!
> >
> > This is a speculative patch that as far as I can tell is not yet required.
> > If anyone applies RCU to a data structure allocated out of an array, using
> > array indexes in place of pointers to link the array elements together,
> > then the rcu_assign_index() function in this patch will be needed to
> > assign a given element's array index to the RCU-traversed index. The
> > implementation is exactly that of the old rcu_assign_pointer(), so is
> > extremely well tested.
> >
> > The existing rcu_assign_pointer() will emit a compiler warning in cases
> > where rcu_assign_index() is required.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> >
> > rcupdate.h | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff -urpNa -X dontdiff linux-2.6.24-rap/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> > --- linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:47.000000000 -0800
> > +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-13 10:55:40.000000000 -0800
> > @@ -286,6 +286,24 @@ extern struct lockdep_map rcu_lock_map;
> > })
> >
> > /**
> > + * rcu_assign_index - assign (publicize) a index of a newly
> > + * initialized array elementg that will be dereferenced by RCU
> ^^^^^^^^
>
> I hope Andrew got that one while porting against the latest -mm :)
>
> Looks good otherwise.
Good catch!!!
Thanx, Paul
^ permalink raw reply
* Re: [PATCH][RFC] race in generic address resolution
From: Benjamin Thery @ 2008-02-14 16:59 UTC (permalink / raw)
To: David Miller; +Cc: blaschka, netdev
In-Reply-To: <939d53060802140856v5168a4a2md8c8ed3fad6798e4@mail.gmail.com>
I ran some additional tests and these traces may also be usefull.
They appears before the soft-lockup are detected.
fermi:~# ping6 -c 500 -f 2007::1
PING 2007::1(2007::1) 56 data bytes
.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.25-rc1-00113-g69cc64d-dirty #34
-------------------------------------------------------
ping6/1058 is trying to acquire lock:
(&tbl->lock){-+-+}, at: [<c02691ac>] neigh_lookup+0x43/0xa2
but task is already holding lock:
(&n->lock){-+..}, at: [<c026b620>] neigh_timer_handler+0x16/0x252
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&n->lock){-+..}:
[<c01330b8>] __lock_acquire+0x947/0xafc
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c01332d0>] lock_acquire+0x63/0x80
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c02eba61>] _write_lock+0x19/0x28
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c0269793>] neigh_periodic_timer+0x0/0x142
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c010d680>] smp_apic_timer_interrupt+0x71/0x81
[<c0103747>] apic_timer_interrupt+0x33/0x38
[<c014e0ce>] mmap_region+0xe1/0x376
[<c014e680>] arch_get_unmapped_area_topdown+0x0/0x12e
[<c014e625>] do_mmap_pgoff+0x1e2/0x23d
[<c0181895>] elf_map+0xd8/0x104
[<c0182072>] load_elf_binary+0x5b4/0x11cd
[<c015ed73>] search_binary_handler+0x74/0x164
[<c0181abe>] load_elf_binary+0x0/0x11cd
[<c015ed7a>] search_binary_handler+0x7b/0x164
[<c015ff2e>] do_execve+0x121/0x16a
[<c01012e3>] sys_execve+0x29/0x52
[<c0102c56>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #0 (&tbl->lock){-+-+}:
[<c0132fdf>] __lock_acquire+0x86e/0xafc
[<c01332d0>] lock_acquire+0x63/0x80
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02ebae9>] _read_lock_bh+0x1e/0x2d
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02af858>] ndisc_dst_alloc+0xb5/0x155
[<c02b240d>] __ndisc_send+0x72/0x3f5
[<c02a573b>] ip6_output+0x0/0xaad
[<c0133225>] __lock_acquire+0xab4/0xafc
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02eb92c>] _read_unlock_bh+0x25/0x28
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c02ebd3a>] _spin_unlock_irqrestore+0x38/0x3c
[<c02188fb>] tty_ldisc_deref+0x5c/0x63
[<c021a5bd>] tty_write+0x1a8/0x1b9
[<c021c5e1>] write_chan+0x0/0x2a9
[<c021a633>] redirected_tty_write+0x65/0x72
[<c021a5ce>] redirected_tty_write+0x0/0x72
[<c015be18>] vfs_write+0x8c/0x108
[<c015c3a2>] sys_write+0x3b/0x60
[<c0102c56>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by ping6/1058:
#0: (&n->lock){-+..}, at: [<c026b620>] neigh_timer_handler+0x16/0x252
stack backtrace:
Pid: 1058, comm: ping6 Not tainted 2.6.25-rc1-netns-00113-g69cc64d-dirty #34
[<c013176b>] print_circular_bug_tail+0x5b/0x66
[<c0132fdf>] __lock_acquire+0x86e/0xafc
[<c01332d0>] lock_acquire+0x63/0x80
[<c02691ac>] ? neigh_lookup+0x43/0xa2
[<c02ebae9>] _read_lock_bh+0x1e/0x2d
[<c02691ac>] ? neigh_lookup+0x43/0xa2
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02af858>] ndisc_dst_alloc+0xb5/0x155
[<c02b240d>] __ndisc_send+0x72/0x3f5
[<c02a573b>] ? ip6_output+0x0/0xaad
[<c0133225>] ? __lock_acquire+0xab4/0xafc
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02eb92c>] ? _read_unlock_bh+0x25/0x28
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c02ebd3a>] ? _spin_unlock_irqrestore+0x38/0x3c
[<c02188fb>] tty_ldisc_deref+0x5c/0x63
[<c021a5bd>] tty_write+0x1a8/0x1b9
[<c021c5e1>] ? write_chan+0x0/0x2a9
[<c021a633>] redirected_tty_write+0x65/0x72
[<c021a5ce>] ? redirected_tty_write+0x0/0x72
[<c015be18>] vfs_write+0x8c/0x108
[<c015c3a2>] sys_write+0x3b/0x60
[<c0102c56>] syscall_call+0x7/0xb
=======================
On Thu, Feb 14, 2008 at 5:56 PM, Benjamin Thery <ben.thery@gmail.com> wrote:
> Hi,
>
> It seems this patch hangs my machine very quickly when there are some
> ICMPv6 traffic.
>
> I'm using net-2.6, pulled today (14th Feb).
>
> I had some unexpected hangs on my SMP test machines and I bisected the
> problem to 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> "[NDISC]: Fix race in generic address resolution".
>
> Looks like a deadlock:
> "BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]"
>
> Here are some traces printed on the console:
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
> ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba95>] _write_lock_bh+0x25/0x2d
> [<c026b107>] ? neigh_resolve_output+0x93/0x238
> [<c026b107>] neigh_resolve_output+0x93/0x238
> [<c02a5635>] ip6_output2+0x241/0x289
> [<c02a61cd>] ip6_output+0xa92/0xaad
> [<c025ff11>] ? __alloc_skb+0x4f/0xfb
> [<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
> [<c02b26a0>] __ndisc_send+0x305/0x3f5
> [<c02b2fb5>] ndisc_send_ns+0x63/0x6e
> [<c02b3f3e>] ndisc_solicit+0x183/0x18d
> [<c0121071>] ? __mod_timer+0x96/0xa1
> [<c026b81e>] neigh_timer_handler+0x214/0x252
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c026b60a>] ? neigh_timer_handler+0x0/0x252
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c0105273>] do_IRQ+0x5a/0x73
> [<c0103666>] common_interrupt+0x2e/0x34
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> [<c02e6135>] rest_init+0x49/0x4b
> =======================
> BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 1
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: 00000000
> ESI: c03bb9c0 EDI: c7b3fab4 EBP: c7841eb0 ESP: c7841eb0
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: 08560008 CR3: 07b04000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba68>] _write_lock+0x20/0x28
> [<c026982c>] ? neigh_periodic_timer+0x99/0x142
> [<c026982c>] neigh_periodic_timer+0x99/0x142
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c0269793>] ? neigh_periodic_timer+0x0/0x142
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c010d680>] smp_apic_timer_interrupt+0x71/0x81
> [<c0103747>] apic_timer_interrupt+0x33/0x38
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> =======================
> BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
> ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba95>] _write_lock_bh+0x25/0x2d
> [<c026b107>] ? neigh_resolve_output+0x93/0x238
> [<c026b107>] neigh_resolve_output+0x93/0x238
> [<c02a5635>] ip6_output2+0x241/0x289
> [<c02a61cd>] ip6_output+0xa92/0xaad
> [<c025ff11>] ? __alloc_skb+0x4f/0xfb
> [<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
> [<c02b26a0>] __ndisc_send+0x305/0x3f5
> [<c02b2fb5>] ndisc_send_ns+0x63/0x6e
> [<c02b3f3e>] ndisc_solicit+0x183/0x18d
> [<c0121071>] ? __mod_timer+0x96/0xa1
> [<c026b81e>] neigh_timer_handler+0x214/0x252
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c026b60a>] ? neigh_timer_handler+0x0/0x252
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c0105273>] do_IRQ+0x5a/0x73
> [<c0103666>] common_interrupt+0x2e/0x34
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> [<c02e6135>] rest_init+0x49/0x4b
> =======================
> BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
> ...
>
>
> Benjamin
>
>
>
> On Tue, Feb 12, 2008 at 6:47 AM, David Miller <davem@davemloft.net> wrote:
> > From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
> > Date: Mon, 11 Feb 2008 10:01:20 +0100
> >
> >
> > > we run your patch during the weekend on single CPU and SMP
> > > machines. We do not see any problems. Thanks for providing the fix.
> >
> > Thanks for testing Frank, I can now push this fix upstream.
> >
> >
> > --
> > 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
* broken link-local multicast?
From: Marco d'Itri @ 2008-02-14 16:28 UTC (permalink / raw)
To: netdev
Link-local multicast appears to be broken on some interfaces of some of
my firewalls. I think that this started after I configured quagga's
ospf6d (which does not work because of this), but I am not totally sure.
Does anybody have any idea about how to debug this?
root@frwl-5a:~# ping6 -c 1 -I eth1 ff02::1
connect: Network is unreachable
root@frwl-5a:~# ping6 -c 1 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::204:23ff:fed8:7dc eth0: 56 data bytes
64 bytes from fe80::204:23ff:fed8:7dc: icmp_seq=1 ttl=64 time=0.032 ms
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.032/0.032/0.032/0.000 ms
root@frwl-5a:~# ip -6 ro | egrep '^fe80:.* eth[01] '
fe80::/64 dev eth0 metric 256 expires 18788161sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1 metric 256 expires 18788161sec mtu 1500 advmss 1440 hoplimit 4294967295
root@frwl-5a:~# uname -a
Linux frwl-5a 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH][RFC] race in generic address resolution
From: Benjamin Thery @ 2008-02-14 16:56 UTC (permalink / raw)
To: David Miller; +Cc: blaschka, netdev
In-Reply-To: <20080211.214711.134366517.davem@davemloft.net>
Hi,
It seems this patch hangs my machine very quickly when there are some
ICMPv6 traffic.
I'm using net-2.6, pulled today (14th Feb).
I had some unexpected hangs on my SMP test machines and I bisected the
problem to 69cc64d8d92bf852f933e90c888dfff083bd4fc9
"[NDISC]: Fix race in generic address resolution".
Looks like a deadlock:
"BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]"
Here are some traces printed on the console:
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba95>] _write_lock_bh+0x25/0x2d
[<c026b107>] ? neigh_resolve_output+0x93/0x238
[<c026b107>] neigh_resolve_output+0x93/0x238
[<c02a5635>] ip6_output2+0x241/0x289
[<c02a61cd>] ip6_output+0xa92/0xaad
[<c025ff11>] ? __alloc_skb+0x4f/0xfb
[<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
[<c02b26a0>] __ndisc_send+0x305/0x3f5
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
[<c02e6135>] rest_init+0x49/0x4b
=======================
BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 1
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: 00000000
ESI: c03bb9c0 EDI: c7b3fab4 EBP: c7841eb0 ESP: c7841eb0
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: 08560008 CR3: 07b04000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba68>] _write_lock+0x20/0x28
[<c026982c>] ? neigh_periodic_timer+0x99/0x142
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c0269793>] ? neigh_periodic_timer+0x0/0x142
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c010d680>] smp_apic_timer_interrupt+0x71/0x81
[<c0103747>] apic_timer_interrupt+0x33/0x38
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
=======================
BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba95>] _write_lock_bh+0x25/0x2d
[<c026b107>] ? neigh_resolve_output+0x93/0x238
[<c026b107>] neigh_resolve_output+0x93/0x238
[<c02a5635>] ip6_output2+0x241/0x289
[<c02a61cd>] ip6_output+0xa92/0xaad
[<c025ff11>] ? __alloc_skb+0x4f/0xfb
[<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
[<c02b26a0>] __ndisc_send+0x305/0x3f5
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
[<c02e6135>] rest_init+0x49/0x4b
=======================
BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
...
Benjamin
On Tue, Feb 12, 2008 at 6:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
> Date: Mon, 11 Feb 2008 10:01:20 +0100
>
>
> > we run your patch during the weekend on single CPU and SMP
> > machines. We do not see any problems. Thanks for providing the fix.
>
> Thanks for testing Frank, I can now push this fix upstream.
>
>
> --
> 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
* [PATCH 10/14] drivers/net/tokenring/3c359.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/tokenring/3c359.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index 44a06f8..88fe955 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -42,6 +42,7 @@
#define XL_DEBUG 0
+#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -408,7 +409,7 @@ static int xl_hw_reset(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL card not responding to global reset.\n", dev->name);
return -ENODEV;
}
@@ -519,7 +520,7 @@ static int xl_hw_reset(struct net_device *dev)
t=jiffies;
while ( !(readw(xl_mmio + MMIO_INTSTATUS_AUTO) & INTSTAT_SRB) ) {
schedule();
- if(jiffies-t > 15*HZ) {
+ if(time_after(jiffies, t + 15 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
return -ENODEV;
}
@@ -790,7 +791,7 @@ static int xl_open_hw(struct net_device *dev)
t=jiffies;
while (! (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_SRB)) {
schedule();
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
break ;
}
@@ -1003,7 +1004,7 @@ static void xl_reset(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
break ;
}
@@ -1270,7 +1271,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNSTALL not responding.\n", dev->name);
break ;
}
@@ -1279,7 +1280,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNDISABLE not responding.\n", dev->name);
break ;
}
@@ -1288,7 +1289,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-UPSTALL not responding.\n", dev->name);
break ;
}
@@ -1305,7 +1306,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (!(readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_SRB)) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-CLOSENIC not responding.\n", dev->name);
break ;
}
@@ -1334,7 +1335,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-UPRESET not responding.\n", dev->name);
break ;
}
@@ -1343,7 +1344,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNRESET not responding.\n", dev->name);
break ;
}
--
1.5.3.7
^ permalink raw reply related
* [PATCH 07/14] drivers/net/ax88796.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/ax88796.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
index 194949a..0f823d7 100644
--- a/drivers/net/ax88796.c
+++ b/drivers/net/ax88796.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -151,7 +152,7 @@ static void ax_reset_8390(struct net_device *dev)
/* This check _should_not_ be necessary, omit eventually. */
while ((ei_inb(addr + EN0_ISR) & ENISR_RESET) == 0) {
- if (jiffies - reset_start_time > 2*HZ/100) {
+ if (time_after(jiffies, reset_start_time + 2 * HZ/100)) {
dev_warn(&ax->dev->dev, "%s: %s did not complete.\n",
__FUNCTION__, dev->name);
break;
@@ -287,7 +288,7 @@ static void ax_block_output(struct net_device *dev, int count,
dma_start = jiffies;
while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
- if (jiffies - dma_start > 2*HZ/100) { /* 20ms */
+ if (time_after(jiffies, dma_start + 2 * HZ/100)) { /* 20ms */
dev_warn(&ax->dev->dev,
"%s: timeout waiting for Tx RDC.\n", dev->name);
ax_reset_8390(dev);
--
1.5.3.7
^ permalink raw reply related
* [PATCH 06/14] drivers/net/arcnet/arcnet.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/arcnet/arcnet.c | 4 ++--
include/linux/arcdevice.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index c59c806..c298615 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -940,7 +940,7 @@ irqreturn_t arcnet_interrupt(int irq, void *dev_id)
/* is the RECON info empty or old? */
if (!lp->first_recon || !lp->last_recon ||
- jiffies - lp->last_recon > HZ * 10) {
+ time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "reconfiguration detected: cabling restored?\n");
lp->first_recon = lp->last_recon = jiffies;
@@ -974,7 +974,7 @@ irqreturn_t arcnet_interrupt(int irq, void *dev_id)
lp->num_recons = 1;
}
}
- } else if (lp->network_down && jiffies - lp->last_recon > HZ * 10) {
+ } else if (lp->network_down && time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "cabling restored?\n");
lp->first_recon = lp->last_recon = 0;
diff --git a/include/linux/arcdevice.h b/include/linux/arcdevice.h
index fde6758..537d661 100644
--- a/include/linux/arcdevice.h
+++ b/include/linux/arcdevice.h
@@ -283,7 +284,7 @@ struct arcnet_local {
int next_buf, first_free_buf;
/* network "reconfiguration" handling */
- time_t first_recon, /* time of "first" RECON message to count */
+ unsigned long first_recon, /* time of "first" RECON message to count */
last_recon; /* time of most recent RECON */
int num_recons; /* number of RECONs between first and last. */
bool network_down; /* do we think the network is down? */
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH][KEY] fix bug in spdadd
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-02-14 14:54 UTC (permalink / raw)
To: kazunori, davem; +Cc: netdev
In-Reply-To: <47B42C3C.5090104@miyazawa.org>
In article <47B42C3C.5090104@miyazawa.org> (at Thu, 14 Feb 2008 20:55:40 +0900), Kazunori MIYAZAWA <kazunori@miyazawa.org> says:
> This patch fix a BUG when adding spds which have
> same selector.
>
> Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>
I think we need to fix xfrm_user side as well.
---
[PATCH] [XFRM]: Avoid bogus BUG() when throwing new policy away.
When we destory a new policy entry, we need to tell
xfrm_policy_destroy() explicitly that the entry is not
alive yet.
---
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 7833807..f971ca5 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1105,6 +1105,7 @@ static struct xfrm_policy *xfrm_policy_construct(struct xfrm_userpolicy_info *p,
return xp;
error:
*errp = err;
+ xp->dead = 1;
xfrm_policy_destroy(xp);
return NULL;
}
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* [PATCH 1/5] [DCCP]: Extend CCID packet dequeueing interface
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-1-git-send-email-gerrit@erg.abdn.ac.uk>
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The interface can also be used to support other CCIDs.
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
If the tasklet finds that the socket is locked, it re-schedules the tasklet
function (not the tasklet) after one jiffy.
Changed DCCP_BUG to DCCP_WARN when transmit_skb returns an error (e.g. when a
local qdisc is used, NET_XMIT_DROP=1 can be returned for many packets).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
include/linux/dccp.h | 4 +-
net/dccp/ccid.h | 37 ++++++++++++++++-
net/dccp/ccids/ccid3.c | 4 +-
net/dccp/output.c | 103 +++++++++++++++++++++++++++++++----------------
net/dccp/timer.c | 25 ++++++-----
5 files changed, 122 insertions(+), 51 deletions(-)
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -476,7 +476,8 @@ struct dccp_ackvec;
* @dccps_hc_tx_insert_options - sender wants to add options when sending
* @dccps_server_timewait - server holds timewait state on close (RFC 4340, 8.3)
* @dccps_sync_scheduled - flag which signals "send out-of-band message soon"
- * @dccps_xmit_timer - timer for when CCID is not ready to send
+ * @dccps_xmitlet - tasklet scheduled by the TX CCID to dequeue data packets
+ * @dccps_xmit_timer - used by the TX CCID to delay sending (rate-based pacing)
* @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
*/
struct dccp_sock {
@@ -517,6 +518,7 @@ struct dccp_sock {
__u8 dccps_hc_tx_insert_options:1;
__u8 dccps_server_timewait:1;
__u8 dccps_sync_scheduled:1;
+ struct tasklet_struct dccps_xmitlet;
struct timer_list dccps_xmit_timer;
};
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -124,13 +124,44 @@ static inline int ccid_get_current_id(struct dccp_sock *dp, bool rx)
extern void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk);
extern void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk);
+/*
+ * Congestion control of queued data packets via CCID decision.
+ *
+ * The TX CCID performs its congestion-control by indicating whether and when a
+ * queued packet may be sent, using the return code of ccid_hc_tx_send_packet().
+ * The following modes are supported:
+ * - autonomous dequeueing (CCID internally schedules dccps_xmitlet);
+ * - timer-based pacing (CCID returns a delay value in milliseconds).
+ * Modes and error handling are identified using the symbolic constants below.
+ */
+enum ccid_dequeueing_decision {
+ CCID_PACKET_SEND_AT_ONCE = 0x00000,
+ CCID_PACKET_DELAY = 0x10000,
+ CCID_PACKET_WILL_DEQUEUE_LATER = 0x20000,
+ CCID_PACKET_ERR = 0xF0000,
+};
+
+/* maximum possible number of milliseconds to delay a packet (65.535 seconds) */
+#define CCID_PACKET_DELAY_MAX 0xFFFF
+#define CCID_PACKET_DELAY_MAX_USEC (CCID_PACKET_DELAY_MAX * USEC_PER_MSEC)
+
+static inline int ccid_packet_dequeue_eval(int return_code)
+{
+ if (return_code < 0)
+ return CCID_PACKET_ERR;
+ if (return_code == 0)
+ return CCID_PACKET_SEND_AT_ONCE;
+ if (return_code <= CCID_PACKET_DELAY_MAX)
+ return CCID_PACKET_DELAY;
+ return return_code;
+}
+
static inline int ccid_hc_tx_send_packet(struct ccid *ccid, struct sock *sk,
struct sk_buff *skb)
{
- int rc = 0;
if (ccid->ccid_ops->ccid_hc_tx_send_packet != NULL)
- rc = ccid->ccid_ops->ccid_hc_tx_send_packet(sk, skb);
- return rc;
+ return ccid->ccid_ops->ccid_hc_tx_send_packet(sk, skb);
+ return CCID_PACKET_SEND_AT_ONCE;
}
static inline void ccid_hc_tx_packet_sent(struct ccid *ccid, struct sock *sk,
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -346,6 +346,8 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
case TFRC_SSTATE_FBACK:
delay = ktime_us_delta(hctx->ccid3hctx_t_nom, now);
ccid3_pr_debug("delay=%ld\n", (long)delay);
+ if (delay > CCID_PACKET_DELAY_MAX_USEC)
+ delay = CCID_PACKET_DELAY_MAX_USEC;
/*
* Scheduling of packet transmissions [RFC 3448, 4.6]
*
@@ -371,7 +373,7 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
/* set the nominal send time for the next following packet */
hctx->ccid3hctx_t_nom = ktime_add_us(hctx->ccid3hctx_t_nom,
hctx->ccid3hctx_t_ipi);
- return 0;
+ return CCID_PACKET_SEND_AT_ONCE;
}
static void ccid3_hc_tx_packet_sent(struct sock *sk, int more,
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -249,52 +249,85 @@ do_interrupted:
goto out;
}
+/**
+ * dccp_xmit_packet - Send data packet under control of CCID
+ * Transmits next-queued payload and informs CCID to account for the packet.
+ */
+static void dccp_xmit_packet(struct sock *sk)
+{
+ int err, len;
+ struct dccp_sock *dp = dccp_sk(sk);
+ struct sk_buff *skb = skb_dequeue(&sk->sk_write_queue);
+
+ if (unlikely(skb == NULL))
+ return;
+ len = skb->len;
+
+ if (sk->sk_state == DCCP_PARTOPEN) {
+ /* See 8.1.5. Handshake Completion */
+ inet_csk_schedule_ack(sk);
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
+ inet_csk(sk)->icsk_rto,
+ DCCP_RTO_MAX);
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
+ } else if (dccp_ack_pending(sk)) {
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
+ } else {
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATA;
+ }
+
+ err = dccp_transmit_skb(sk, skb);
+ if (err)
+ DCCP_WARN("transmit_skb() returned err=%d\n", err);
+ /*
+ * Register this one as sent even if an error occurred. To the remote
+ * end this error is indistinguishable from loss, so that finally (if
+ * the peer has no bugs) the drop is reported via receiver feedback.
+ */
+ ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
+
+ /*
+ * If the CCID needs to transfer additional header options out-of-band
+ * (e.g. Ack Vectors or feature-negotiation options), it activates the
+ * flag to schedule a Sync. The Sync will automatically incorporate all
+ * currently valid header options so that this backlog is now cleared.
+ */
+ if (dp->dccps_sync_scheduled)
+ dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
+}
+
void dccp_write_xmit(struct sock *sk, int block)
{
struct dccp_sock *dp = dccp_sk(sk);
struct sk_buff *skb;
while ((skb = skb_peek(&sk->sk_write_queue))) {
- int err = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
+ int rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
- if (err > 0) {
+ switch (ccid_packet_dequeue_eval(rc)) {
+ case CCID_PACKET_WILL_DEQUEUE_LATER:
+ return;
+ case CCID_PACKET_DELAY:
if (!block) {
sk_reset_timer(sk, &dp->dccps_xmit_timer,
- msecs_to_jiffies(err)+jiffies);
+ msecs_to_jiffies(rc)+jiffies);
+ return;
+ }
+ rc = dccp_wait_for_ccid(sk, skb, rc);
+ if (rc && rc != -EINTR) {
+ DCCP_BUG("err=%d after dccp_wait_for_ccid", rc);
+ skb_dequeue(&sk->sk_write_queue);
+ kfree_skb(skb);
break;
- } else
- err = dccp_wait_for_ccid(sk, skb, err);
- if (err && err != -EINTR)
- DCCP_BUG("err=%d after dccp_wait_for_ccid", err);
- }
-
- skb_dequeue(&sk->sk_write_queue);
- if (err == 0) {
- struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
- const int len = skb->len;
-
- if (sk->sk_state == DCCP_PARTOPEN) {
- /* See 8.1.5. Handshake Completion */
- inet_csk_schedule_ack(sk);
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
- inet_csk(sk)->icsk_rto,
- DCCP_RTO_MAX);
- dcb->dccpd_type = DCCP_PKT_DATAACK;
- } else if (dccp_ack_pending(sk))
- dcb->dccpd_type = DCCP_PKT_DATAACK;
- else
- dcb->dccpd_type = DCCP_PKT_DATA;
-
- err = dccp_transmit_skb(sk, skb);
- ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
- if (err)
- DCCP_BUG("err=%d after ccid_hc_tx_packet_sent",
- err);
- if (dp->dccps_sync_scheduled)
- dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
- } else {
- dccp_pr_debug("packet discarded due to err=%d\n", err);
+ }
+ /* fall through */
+ case CCID_PACKET_SEND_AT_ONCE:
+ dccp_xmit_packet(sk);
+ break;
+ case CCID_PACKET_ERR:
+ skb_dequeue(&sk->sk_write_queue);
kfree_skb(skb);
+ dccp_pr_debug("packet discarded due to err=%d\n", rc);
}
}
}
--- a/net/dccp/timer.c
+++ b/net/dccp/timer.c
@@ -249,32 +249,35 @@ out:
sock_put(sk);
}
-/* Transmit-delay timer: used by the CCIDs to delay actual send time */
-static void dccp_write_xmit_timer(unsigned long data)
+/**
+ * dccp_write_xmitlet - Workhorse for CCID packet dequeueing interface
+ * See the comments above %ccid_dequeueing_decision for supported modes.
+ */
+static void dccp_write_xmitlet(unsigned long data)
{
struct sock *sk = (struct sock *)data;
- struct dccp_sock *dp = dccp_sk(sk);
bh_lock_sock(sk);
if (sock_owned_by_user(sk))
- sk_reset_timer(sk, &dp->dccps_xmit_timer, jiffies+1);
+ sk_reset_timer(sk, &dccp_sk(sk)->dccps_xmit_timer, jiffies + 1);
else
dccp_write_xmit(sk, 0);
bh_unlock_sock(sk);
- sock_put(sk);
}
-static void dccp_init_write_xmit_timer(struct sock *sk)
+static void dccp_write_xmit_timer(unsigned long data)
{
- struct dccp_sock *dp = dccp_sk(sk);
-
- setup_timer(&dp->dccps_xmit_timer, dccp_write_xmit_timer,
- (unsigned long)sk);
+ dccp_write_xmitlet(data);
+ sock_put((struct sock *)data);
}
void dccp_init_xmit_timers(struct sock *sk)
{
- dccp_init_write_xmit_timer(sk);
+ struct dccp_sock *dp = dccp_sk(sk);
+
+ tasklet_init(&dp->dccps_xmitlet, dccp_write_xmitlet, (unsigned long)sk);
+ setup_timer(&dp->dccps_xmit_timer, dccp_write_xmit_timer,
+ (unsigned long)sk);
inet_csk_init_xmit_timers(sk, &dccp_write_timer, &dccp_delack_timer,
&dccp_keepalive_timer);
}
^ permalink raw reply
* [PATCH 2/5] [CCID]: Refine the wait-for-ccid mechanism
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-2-git-send-email-gerrit@erg.abdn.ac.uk>
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID. It further addresses the problems listed below.
The code looks if the write queue is non-empty and grants the TX CCID up to
`timeout' jiffies to drain the queue. It will instead purge that queue if
* the delay suggested by the CCID exceeds the time budget;
* a socket error occurred while waiting for the CCID;
* there is a signal pending (eg. annoyed user pressed Control-C);
* the CCID does not support delays (we don't know how long it will take).
D e t a i l s [can be removed]
-------------------------------
DCCP's sending mechanism functions a bit like non-blocking I/O: dccp_sendmsg()
will enqueue up to net.dccp.default.tx_qlen packets (default=5), without waiting
for them to be released to the network.
Rate-based CCIDs, such as CCID3/4, can impose sending delays of up to maximally
64 seconds (t_mbi in RFC 3448). Hence the write queue may still contain packets
when the application closes. Since the write queue is congestion-controlled by
the CCID, draining the queue is also under control of the CCID.
There are several problems that needed to be addressed:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID2 to become unblocked could
lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case by calling __skb_queue_purge() after
waiting for the CCID. This is necessary since the write queue may still have
data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/dccp.h | 3 +-
net/dccp/output.c | 122 ++++++++++++++++++++++++++++++-----------------------
net/dccp/proto.c | 15 ++++++-
net/dccp/timer.c | 2 +-
4 files changed, 86 insertions(+), 56 deletions(-)
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -215,8 +215,9 @@ extern void dccp_reqsk_send_ack(struct sk_buff *sk, struct request_sock *rsk);
extern void dccp_send_sync(struct sock *sk, const u64 seq,
const enum dccp_pkt_type pkt_type);
-extern void dccp_write_xmit(struct sock *sk, int block);
+extern void dccp_write_xmit(struct sock *sk);
extern void dccp_write_space(struct sock *sk);
+extern void dccp_flush_write_queue(struct sock *sk, long *time_budget);
extern void dccp_init_xmit_timers(struct sock *sk);
static inline void dccp_clear_xmit_timers(struct sock *sk)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -204,49 +204,29 @@ void dccp_write_space(struct sock *sk)
}
/**
- * dccp_wait_for_ccid - Wait for ccid to tell us we can send a packet
+ * dccp_wait_for_ccid - Await CCID send permission
* @sk: socket to wait for
- * @skb: current skb to pass on for waiting
- * @delay: sleep timeout in milliseconds (> 0)
- * This function is called by default when the socket is closed, and
- * when a non-zero linger time is set on the socket. For consistency
+ * @delay: timeout in jiffies
+ * This is used by CCIDs which need to delay the send time in process context.
*/
-static int dccp_wait_for_ccid(struct sock *sk, struct sk_buff *skb, int delay)
+static int dccp_wait_for_ccid(struct sock *sk, unsigned long delay)
{
- struct dccp_sock *dp = dccp_sk(sk);
DEFINE_WAIT(wait);
- unsigned long jiffdelay;
- int rc;
-
- do {
- dccp_pr_debug("delayed send by %d msec\n", delay);
- jiffdelay = msecs_to_jiffies(delay);
-
- prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ long remaining;
- sk->sk_write_pending++;
- release_sock(sk);
- schedule_timeout(jiffdelay);
- lock_sock(sk);
- sk->sk_write_pending--;
+ prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ sk->sk_write_pending++;
+ release_sock(sk);
- if (sk->sk_err)
- goto do_error;
- if (signal_pending(current))
- goto do_interrupted;
+ remaining = schedule_timeout(delay);
- rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
- } while ((delay = rc) > 0);
-out:
+ lock_sock(sk);
+ sk->sk_write_pending--;
finish_wait(sk->sk_sleep, &wait);
- return rc;
-
-do_error:
- rc = -EPIPE;
- goto out;
-do_interrupted:
- rc = -EINTR;
- goto out;
+
+ if (signal_pending(current) || sk->sk_err)
+ return -1;
+ return remaining;
}
/**
@@ -296,7 +276,53 @@ static void dccp_xmit_packet(struct sock *sk)
dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
}
-void dccp_write_xmit(struct sock *sk, int block)
+/**
+ * dccp_flush_write_queue - Drain queue at end of connection
+ * Since dccp_sendmsg queues packets without waiting for them to be sent, it may
+ * happen that the TX queue is not empty at the end of a connection. We give the
+ * HC-sender CCID a grace period of up to @time_budget jiffies. If this function
+ * returns with a non-empty write queue, it will be purged later.
+ */
+void dccp_flush_write_queue(struct sock *sk, long *time_budget)
+{
+ struct dccp_sock *dp = dccp_sk(sk);
+ struct sk_buff *skb;
+ long delay, rc;
+
+ while (*time_budget > 0 && (skb = skb_peek(&sk->sk_write_queue))) {
+ rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
+
+ switch (ccid_packet_dequeue_eval(rc)) {
+ case CCID_PACKET_WILL_DEQUEUE_LATER:
+ /*
+ * If the CCID determines when to send, the next sending
+ * time is unknown or the CCID may not even send again
+ * (e.g. remote host crashes or lost Ack packets).
+ */
+ DCCP_WARN("CCID did not manage to send all packets");
+ return;
+ case CCID_PACKET_DELAY:
+ delay = msecs_to_jiffies(rc);
+ if (delay > *time_budget)
+ return;
+ rc = dccp_wait_for_ccid(sk, delay);
+ if (rc < 0)
+ return;
+ *time_budget -= (delay - rc);
+ /* check again if we can send now */
+ break;
+ case CCID_PACKET_SEND_AT_ONCE:
+ dccp_xmit_packet(sk);
+ break;
+ case CCID_PACKET_ERR:
+ skb_dequeue(&sk->sk_write_queue);
+ kfree_skb(skb);
+ dccp_pr_debug("packet discarded due to err=%ld\n", rc);
+ }
+ }
+}
+
+void dccp_write_xmit(struct sock *sk)
{
struct dccp_sock *dp = dccp_sk(sk);
struct sk_buff *skb;
@@ -308,19 +334,9 @@ void dccp_write_xmit(struct sock *sk, int block)
case CCID_PACKET_WILL_DEQUEUE_LATER:
return;
case CCID_PACKET_DELAY:
- if (!block) {
- sk_reset_timer(sk, &dp->dccps_xmit_timer,
- msecs_to_jiffies(rc)+jiffies);
- return;
- }
- rc = dccp_wait_for_ccid(sk, skb, rc);
- if (rc && rc != -EINTR) {
- DCCP_BUG("err=%d after dccp_wait_for_ccid", rc);
- skb_dequeue(&sk->sk_write_queue);
- kfree_skb(skb);
- break;
- }
- /* fall through */
+ sk_reset_timer(sk, &dp->dccps_xmit_timer, (jiffies +
+ msecs_to_jiffies(rc)));
+ return;
case CCID_PACKET_SEND_AT_ONCE:
dccp_xmit_packet(sk);
break;
@@ -631,9 +647,8 @@ void dccp_send_close(struct sock *sk, const int active)
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_CLOSE;
if (active) {
- dccp_write_xmit(sk, 1);
dccp_skb_entail(sk, skb);
- dccp_transmit_skb(sk, skb_clone(skb, prio));
+ skb = skb_clone(skb, prio);
/*
* Retransmission timer for active-close: RFC 4340, 8.3 requires
* to retransmit the Close/CloseReq until the CLOSING/CLOSEREQ
@@ -646,6 +661,7 @@ void dccp_send_close(struct sock *sk, const int active)
*/
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
DCCP_TIMEOUT_INIT, DCCP_RTO_MAX);
- } else
- dccp_transmit_skb(sk, skb);
+ }
+
+ dccp_transmit_skb(sk, skb);
}
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -756,7 +756,7 @@ int dccp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto out_discard;
skb_queue_tail(&sk->sk_write_queue, skb);
- dccp_write_xmit(sk,0);
+ dccp_write_xmit(sk);
out_release:
release_sock(sk);
return rc ? : len;
@@ -979,9 +979,22 @@ void dccp_close(struct sock *sk, long timeout)
/* Check zero linger _after_ checking for unread data. */
sk->sk_prot->disconnect(sk, 0);
} else if (sk->sk_state != DCCP_CLOSED) {
+ /*
+ * Normal connection termination. May need to wait if there are
+ * still packets in the TX queue that are delayed by the CCID.
+ */
+ dccp_flush_write_queue(sk, &timeout);
dccp_terminate_connection(sk);
}
+ /*
+ * Flush write queue. This may be necessary in several cases:
+ * - we have been closed by the peer but still have application data;
+ * - abortive termination (unread data or zero linger time),
+ * - normal termination but queue could not be flushed within time limit
+ */
+ __skb_queue_purge(&sk->sk_write_queue);
+
sk_stream_wait_close(sk, timeout);
adjudge_to_death:
--- a/net/dccp/timer.c
+++ b/net/dccp/timer.c
@@ -261,7 +261,7 @@ static void dccp_write_xmitlet(unsigned long data)
if (sock_owned_by_user(sk))
sk_reset_timer(sk, &dccp_sk(sk)->dccps_xmit_timer, jiffies + 1);
else
- dccp_write_xmit(sk, 0);
+ dccp_write_xmit(sk);
bh_unlock_sock(sk);
}
^ permalink raw reply
* [PATCH 5/5] [CCID]: Unused argument
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-5-git-send-email-gerrit@erg.abdn.ac.uk>
This removes the argument `more' from ccid_hc_tx_packet_sent, since it was
nowhere used in the entire code.
(Anecdotally, this argument was not even used in the original KAME code where
the function originally came from; compare the variable moreToSend in the
freebsd61-dccp-kame-28.08.2006.patch now maintained by Emmanuel Lochin.)
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccid.h | 6 +++---
net/dccp/ccids/ccid2.c | 2 +-
net/dccp/ccids/ccid3.c | 3 +--
net/dccp/output.c | 2 +-
4 files changed, 6 insertions(+), 7 deletions(-)
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -75,7 +75,7 @@ struct ccid_operations {
int (*ccid_hc_tx_send_packet)(struct sock *sk,
struct sk_buff *skb);
void (*ccid_hc_tx_packet_sent)(struct sock *sk,
- int more, unsigned int len);
+ unsigned int len);
void (*ccid_hc_rx_get_info)(struct sock *sk,
struct tcp_info *info);
void (*ccid_hc_tx_get_info)(struct sock *sk,
@@ -165,10 +165,10 @@ static inline int ccid_hc_tx_send_packet(struct ccid *ccid, struct sock *sk,
}
static inline void ccid_hc_tx_packet_sent(struct ccid *ccid, struct sock *sk,
- int more, unsigned int len)
+ unsigned int len)
{
if (ccid->ccid_ops->ccid_hc_tx_packet_sent != NULL)
- ccid->ccid_ops->ccid_hc_tx_packet_sent(sk, more, len);
+ ccid->ccid_ops->ccid_hc_tx_packet_sent(sk, len);
}
static inline void ccid_hc_rx_packet_recv(struct ccid *ccid, struct sock *sk,
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -224,7 +224,7 @@ static void ccid2_start_rto_timer(struct sock *sk)
jiffies + hctx->ccid2hctx_rto);
}
-static void ccid2_hc_tx_packet_sent(struct sock *sk, int more, unsigned int len)
+static void ccid2_hc_tx_packet_sent(struct sock *sk, unsigned int len)
{
struct dccp_sock *dp = dccp_sk(sk);
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -376,8 +376,7 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
return CCID_PACKET_SEND_AT_ONCE;
}
-static void ccid3_hc_tx_packet_sent(struct sock *sk, int more,
- unsigned int len)
+static void ccid3_hc_tx_packet_sent(struct sock *sk, unsigned int len)
{
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -264,7 +264,7 @@ static void dccp_xmit_packet(struct sock *sk)
* end this error is indistinguishable from loss, so that finally (if
* the peer has no bugs) the drop is reported via receiver feedback.
*/
- ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
+ ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, len);
/*
* If the CCID needs to transfer additional header options out-of-band
^ permalink raw reply
* [PATCH 4/5] [CCID2]: Stop polling
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-4-git-send-email-gerrit@erg.abdn.ac.uk>
This updates CCID2 to use the CCID dequeuing mechanism, converting from
previous constant-polling to a now event-driven mechanism.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/ccid2.c | 21 +++++++++++++--------
net/dccp/ccids/ccid2.h | 5 +++++
2 files changed, 18 insertions(+), 8 deletions(-)
--- a/net/dccp/ccids/ccid2.h
+++ b/net/dccp/ccids/ccid2.h
@@ -70,6 +70,11 @@ struct ccid2_hc_tx_sock {
struct list_head ccid2hctx_parsed_ackvecs;
};
+static inline bool ccid2_cwnd_network_limited(struct ccid2_hc_tx_sock *hctx)
+{
+ return (hctx->ccid2hctx_pipe >= hctx->ccid2hctx_cwnd);
+}
+
struct ccid2_hc_rx_sock {
int ccid2hcrx_data;
};
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -124,12 +124,9 @@ static int ccid2_hc_tx_alloc_seq(struct ccid2_hc_tx_sock *hctx)
static int ccid2_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
{
- struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
-
- if (hctx->ccid2hctx_pipe < hctx->ccid2hctx_cwnd)
- return 0;
-
- return 1; /* XXX CCID should dequeue when ready instead of polling */
+ if (ccid2_cwnd_network_limited(ccid2_hc_tx_sk(sk)))
+ return CCID_PACKET_WILL_DEQUEUE_LATER;
+ return CCID_PACKET_SEND_AT_ONCE;
}
static void ccid2_change_l_ack_ratio(struct sock *sk, u32 val)
@@ -169,6 +166,7 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
{
struct sock *sk = (struct sock *)data;
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
+ const bool sender_was_blocked = ccid2_cwnd_network_limited(hctx);
long s;
bh_lock_sock(sk);
@@ -189,8 +187,6 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
if (s > 60)
hctx->ccid2hctx_rto = 60 * HZ;
- ccid2_start_rto_timer(sk);
-
/* adjust pipe, cwnd etc */
hctx->ccid2hctx_ssthresh = hctx->ccid2hctx_cwnd / 2;
if (hctx->ccid2hctx_ssthresh < 2)
@@ -207,6 +203,11 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
hctx->ccid2hctx_rpdupack = -1;
ccid2_change_l_ack_ratio(sk, 1);
ccid2_hc_tx_check_sanity(hctx);
+
+ /* if we were blocked before, we may now send cwnd=1 packet */
+ if (sender_was_blocked)
+ tasklet_schedule(&dccp_sk(sk)->dccps_xmitlet);
+ ccid2_start_rto_timer(sk);
out:
bh_unlock_sock(sk);
sock_put(sk);
@@ -461,6 +462,7 @@ static void ccid2_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
{
struct dccp_sock *dp = dccp_sk(sk);
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
+ const bool sender_was_blocked = ccid2_cwnd_network_limited(hctx);
struct dccp_ackvec_parsed *avp;
u64 ackno, seqno;
struct ccid2_seq *seqp;
@@ -646,6 +648,9 @@ static void ccid2_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
ccid2_hc_tx_check_sanity(hctx);
done:
+ /* check if incoming Acks allow pending packets to be sent */
+ if (sender_was_blocked && !ccid2_cwnd_network_limited(hctx))
+ tasklet_schedule(&dccp_sk(sk)->dccps_xmitlet);
dccp_ackvec_parsed_cleanup(&hctx->ccid2hctx_parsed_ackvecs);
}
^ permalink raw reply
* [PATCH 3/5] [DCCP]: Empty the write queue when disconnecting
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-3-git-send-email-gerrit@erg.abdn.ac.uk>
dccp_disconnect() can be called due to several reasons:
1. when the connection setup failed (inet_stream_connect());
2. when shutting down (inet_shutdown(), inet_csk_listen_stop());
3. when aborting the connection (dccp_close() with 0 linger time).
In case (1) the write queue is empty. This patch empties the write queue,
if in case (2) or (3) it was not yet empty.
This avoids triggering the write-queue BUG_TRAP in sk_stream_kill_queues()
later on.
It also seems natural to do: when breaking an association, to delete all
packets that were originally intended for the soon-disconnected end (compare
with call to tcp_write_queue_purge in tcp_disconnect()).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/proto.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -277,7 +277,9 @@ int dccp_disconnect(struct sock *sk, int flags)
sk->sk_err = ECONNRESET;
dccp_clear_xmit_timers(sk);
+
__skb_queue_purge(&sk->sk_receive_queue);
+ __skb_queue_purge(&sk->sk_write_queue);
if (sk->sk_send_head != NULL) {
__kfree_skb(sk->sk_send_head);
sk->sk_send_head = NULL;
^ permalink raw reply
* [DCCP] [PATCH 0/5]: Extend CCID interface so that CCID-2 stops polling
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev
This set of patches extends the packet sending/dequeuing interface, which is
currently restricted to using time intervals only. This forces CCID-2 into
a constant polling mode, which is removed in patch #4.
Patch #1: Extends the CCID packet dequeuing interface to allow CCIDs to
autonomously schedule sending. Previously it was timer-only,
so that CCID-2 polls uninterruptedly.
Patch #2: Adds a similar extension to the routine which drains the packet queue
at the end of a connection (still under congestion control).
Patch #3: Please clean up your queue when disconnecting.
Patch #4: With the previous changes, CCID-2 is taken out of its polling mode.
Patch #5: Removes the `more' argument from tx_packet_sent.
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-14 13:00 UTC (permalink / raw)
To: James Chapman; +Cc: David Miller, netdev
In-Reply-To: <47B17BCD.2070903@katalix.com>
Hi,
It seems, this nice report is still uncomplete: could you check if
there could have been something more yet?
Thanks,
Jarek P.
On Tue, Feb 12, 2008 at 10:58:21AM +0000, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
>
> Feb 5 16:26:32 ======================================================
> Feb 5 16:26:32 [ INFO: soft-safe -> soft-unsafe lock order detected ]
> Feb 5 16:26:32 2.6.24-core2 #1
> Feb 5 16:26:32 ------------------------------------------------------
> Feb 5 16:26:32 pppd/3224 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
...
> Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
> Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
> Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
> Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
> Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
> Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
> Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
> Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
> Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
> Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
> Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
> Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
> Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
>
> --
> James Chapman
> Katalix Systems Ltd
> http://www.katalix.com
> Catalysts for your Embedded Linux software development
>
^ permalink raw reply
* [PATCH][KEY] fix bug in spdadd
From: Kazunori MIYAZAWA @ 2008-02-14 11:55 UTC (permalink / raw)
To: David S. Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 146 bytes --]
This patch fix a BUG when adding spds which have
same selector.
Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>
--
Kazunori Miyazawa
[-- Attachment #2: af_key.diff --]
[-- Type: text/x-patch, Size: 308 bytes --]
diff --git a/net/key/af_key.c b/net/key/af_key.c
index b3ac85e..1c85392 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2291,6 +2291,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *h
return 0;
out:
+ xp->dead = 1;
xfrm_policy_destroy(xp);
return err;
}
^ permalink raw reply related
* Re: [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: Claudio Lanconelli @ 2008-02-14 10:28 UTC (permalink / raw)
To: David Brownell; +Cc: netdev
In-Reply-To: <200802111223.49823.david-b@pacbell.net>
David Brownell wrote:
> On Monday 11 February 2008, Claudio Lanconelli wrote:
>
>> I have tried your latest patch. Only after the following change it
>> works fine (no more rx errors during ifconfig up).
>>
>
> Hmm, what chip rev do you have? Different errata and all.
> ISTR mine is rev4; so, not the most current, but not the
> oldest version either.
>
I use the same revision.
>> I added enc28j60_lowpower(false) just before enc28j60_hw_init()
>>
>
> Hmm, I'd have expected it would go best *before* that, but
> what you include below shows it going *after* ...
>
> If there's some problem where reset doesn't work correctly
> in low power mode, who knows what else would need manual
> resetting.
>
>
I don't know why it needs low power resume before reset.
I read in the errata tath clkready bit after reset doesn't work reliably.
May be something related to this, but undocumented.
> Better yet, since I can't reproduce the problem, why don't
> you just update my latest patch with the relevant version
> of this tweak, and then forward it as "From: " me and with
> both our signoffs. That's the usual way to cope with this
> type of tweaking. (Not all updates to your driver should
> need your signoff, but then most patches shouldn't need
> very many iterations either.)
>
Done
^ permalink raw reply
* [PATCH] net/enc28j60: low power mode
From: Claudio Lanconelli @ 2008-02-14 10:20 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik, David Brownell
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Keep enc28j60 chips in low-power mode when they're not in use.
At typically 120 mA, these chips run hot even when idle; this
low power mode cuts that power usage by a factor of around 100.
This version provides a generic routine to poll a register until
its masked value equals some value ... e.g. bit set or cleared.
It's basically what the previous wait_phy_ready() did, but this
version is generalized to support the handshaking needed to
enter and exit low power mode.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Claudio Lanconelli <lanconelli.claudio@eptar.com>
[-- Attachment #2: enc28j60_lowpower.patch --]
[-- Type: text/x-patch, Size: 4622 bytes --]
--- a/drivers/net/enc28j60.c
+++ b/drivers/net/enc28j60.c
@@ -400,26 +400,31 @@ enc28j60_packet_write(struct enc28j60_ne
mutex_unlock(&priv->lock);
}
-/*
- * Wait until the PHY operation is complete.
- */
-static int wait_phy_ready(struct enc28j60_net *priv)
+static unsigned long msec20_to_jiffies;
+
+static int poll_ready(struct enc28j60_net *priv, u8 reg, u8 mask, u8 val)
{
- unsigned long timeout = jiffies + 20 * HZ / 1000;
- int ret = 1;
+ unsigned long timeout = jiffies + msec20_to_jiffies;
/* 20 msec timeout read */
- while (nolock_regb_read(priv, MISTAT) & MISTAT_BUSY) {
+ while ((nolock_regb_read(priv, reg) & mask) != val) {
if (time_after(jiffies, timeout)) {
if (netif_msg_drv(priv))
- printk(KERN_DEBUG DRV_NAME
- ": PHY ready timeout!\n");
- ret = 0;
- break;
+ dev_dbg(&priv->spi->dev,
+ "reg %02x ready timeout!\n", reg);
+ return -ETIMEDOUT;
}
cpu_relax();
}
- return ret;
+ return 0;
+}
+
+/*
+ * Wait until the PHY operation is complete.
+ */
+static int wait_phy_ready(struct enc28j60_net *priv)
+{
+ return poll_ready(priv, MISTAT, MISTAT_BUSY, 0) ? 0 : 1;
}
/*
@@ -594,6 +599,32 @@ static void nolock_txfifo_init(struct en
nolock_regw_write(priv, ETXNDL, end);
}
+/*
+ * Low power mode shrinks power consumption about 100x, so we'd like
+ * the chip to be in that mode whenever it's inactive. (However, we
+ * can't stay in lowpower mode during suspend with WOL active.)
+ */
+static void enc28j60_lowpower(struct enc28j60_net *priv, bool is_low)
+{
+ if (netif_msg_drv(priv))
+ dev_dbg(&priv->spi->dev, "%s power...\n",
+ is_low ? "low" : "high");
+
+ mutex_lock(&priv->lock);
+ if (is_low) {
+ nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
+ poll_ready(priv, ESTAT, ESTAT_RXBUSY, 0);
+ poll_ready(priv, ECON1, ECON1_TXRTS, 0);
+ /* ECON2_VRPS was set during initialization */
+ nolock_reg_bfset(priv, ECON2, ECON2_PWRSV);
+ } else {
+ nolock_reg_bfclr(priv, ECON2, ECON2_PWRSV);
+ poll_ready(priv, ESTAT, ESTAT_CLKRDY, ESTAT_CLKRDY);
+ /* caller sets ECON1_RXEN */
+ }
+ mutex_unlock(&priv->lock);
+}
+
static int enc28j60_hw_init(struct enc28j60_net *priv)
{
u8 reg;
@@ -612,8 +643,8 @@ static int enc28j60_hw_init(struct enc28
priv->tx_retry_count = 0;
priv->max_pk_counter = 0;
priv->rxfilter = RXFILTER_NORMAL;
- /* enable address auto increment */
- nolock_regb_write(priv, ECON2, ECON2_AUTOINC);
+ /* enable address auto increment and voltage regulator powersave */
+ nolock_regb_write(priv, ECON2, ECON2_AUTOINC | ECON2_VRPS);
nolock_rxfifo_init(priv, RXSTART_INIT, RXEND_INIT);
nolock_txfifo_init(priv, TXSTART_INIT, TXEND_INIT);
@@ -690,7 +721,7 @@ static int enc28j60_hw_init(struct enc28
static void enc28j60_hw_enable(struct enc28j60_net *priv)
{
- /* enable interrutps */
+ /* enable interrupts */
if (netif_msg_hw(priv))
printk(KERN_DEBUG DRV_NAME ": %s() enabling interrupts.\n",
__FUNCTION__);
@@ -726,15 +757,12 @@ enc28j60_setlink(struct net_device *ndev
int ret = 0;
if (!priv->hw_enable) {
- if (autoneg == AUTONEG_DISABLE && speed == SPEED_10) {
+ /* link is in low power mode now; duplex setting
+ * will take effect on next enc28j60_hw_init().
+ */
+ if (autoneg == AUTONEG_DISABLE && speed == SPEED_10)
priv->full_duplex = (duplex == DUPLEX_FULL);
- if (!enc28j60_hw_init(priv)) {
- if (netif_msg_drv(priv))
- dev_err(&ndev->dev,
- "hw_reset() failed\n");
- ret = -EINVAL;
- }
- } else {
+ else {
if (netif_msg_link(priv))
dev_warn(&ndev->dev,
"unsupported link setting\n");
@@ -1307,8 +1335,9 @@ static int enc28j60_net_open(struct net_
}
return -EADDRNOTAVAIL;
}
- /* Reset the hardware here */
+ /* Take it out of low power mode and reset the hardware here */
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, false);
if (!enc28j60_hw_init(priv)) {
if (netif_msg_ifup(priv))
dev_err(&dev->dev, "hw_reset() failed\n");
@@ -1337,6 +1365,7 @@ static int enc28j60_net_close(struct net
printk(KERN_DEBUG DRV_NAME ": %s() enter\n", __FUNCTION__);
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, true);
netif_stop_queue(dev);
return 0;
@@ -1537,6 +1566,8 @@ static int __devinit enc28j60_probe(stru
dev->watchdog_timeo = TX_TIMEOUT;
SET_ETHTOOL_OPS(dev, &enc28j60_ethtool_ops);
+ enc28j60_lowpower(priv, true);
+
ret = register_netdev(dev);
if (ret) {
if (netif_msg_probe(priv))
@@ -1582,6 +1613,8 @@ static struct spi_driver enc28j60_driver
static int __init enc28j60_init(void)
{
+ msec20_to_jiffies = msecs_to_jiffies(20);
+
return spi_register_driver(&enc28j60_driver);
}
^ permalink raw reply
* [PATCH][IPROUTE2]Add missing prefix bit length for addrlabel
From: Varun Chandramohan @ 2008-02-14 9:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev, yoshfuji
The prefix bit lenght value was not updated, resulting in incorrect addrlabel
entry. This patch fixes that issue.
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
ip/ipaddrlabel.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ip/ipaddrlabel.c b/ip/ipaddrlabel.c
index 1c873e9..a4cdece 100644
--- a/ip/ipaddrlabel.c
+++ b/ip/ipaddrlabel.c
@@ -173,6 +173,7 @@ static int ipaddrlabel_modify(int cmd, int argc, char **argv)
addattr32(&req.n, sizeof(req), IFAL_LABEL, label);
addattr_l(&req.n, sizeof(req), IFAL_ADDRESS, &prefix.data, prefix.bytelen);
+ req.ifal.ifal_prefixlen = prefix.bitlen;
if (req.ifal.ifal_family == AF_UNSPEC)
req.ifal.ifal_family = AF_INET6;
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Christoph Raisch @ 2008-02-14 8:46 UTC (permalink / raw)
To: ossthema
Cc: apw, Greg KH, Dave Hansen, Jan-Bernd Themann, linux-kernel,
linuxppc-dev, netdev, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <200802131617.58646.ossthema@de.ibm.com>
Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > Constraints imposed by HW / FW:
> > - eHEA has own MMU
> > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
virtual
> > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > - The number of MRs is limited (not enough to have one MR per packet)
>
> Are there enough to have one per 16MB section?
Unfortunately this won't work. This was one of our first ideas we tossed
out,
but the number of MRs will not be sufficient.
>
> > Our current understanding about the current Memory Hotplug System are
> > (please correct me if I'm wrong):
> >
> > - depends on sparse mem
>
> You're wrong ;). In mainline, this is true. There was a version of the
> SUSE kernel that did otherwise. But you can not and should not depend
> on this never changing. But, someone is perfectly free to go out an
> implement something better than sparsemem for memory hotplug. If they
> go and do this, your driver may get left behind.
We understand that the add/remove area is not as
settled in the kernel like for example f_ops ;-)
Are there already base working assumptions which are very unlikely to
change?
>
> > - only whole memory sections are added / removed
> > - for each section a memory resource is registered
>
> True, and true. (There might be exceptions to the whole sections one,
> but that's blatant abuse and should be fixed. :)
>
> > From the driver side we need:
> > - some kind of memory notification mechanism.
> > For memory add we can live without any external memory notification
> > event. For memory remove we do need an external trigger (see
explanation
> > above).
>
> You can export and use (un)register_memory_notifier. You just need to
> do it in a reasonable way that compiles for randconfig on your
> architecture. Believe me, we don't want to start teaching drivers about
> sparsemem.
I'm a little confused here....
...the existing add/remove code depends on sparse mem.
Other pieces on the POWER6 version of the architecture do as well.
So we could either chose to disable add/remove if sparsemem is not there,
or disable the driver by Kconfig in this case.
> > - a way to iterate over all kernel pages and a way to detect holes in
the
> > kernel memory layout in order to build up our own ehea_bmap.
>
> Look at kernel/resource.c
>
> But, I'm really not convinced that you can actually keep this map
> yourselves. It's not as simple as you think. What happens if you get
> on an LPAR with two sections, one 256MB@0x0 and another
> 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> array will eat all of memory.
I'm glad you mention this part. There are many algorithms out there to
handle this problem,
hashes/trees/... all of these trade speed for smaller memory footprint.
We based the table decission on the existing implementations of the
architecture.
Do you see such a case coming along for the next generation POWER systems?
I would guess these drastic changes would also require changes in base
kernel.
Will you provide a generic mapping system with a contiguous virtual address
space
like the ehea_bmap we can query? This would need to be a "stable" part of
the implementation,
including translation functions from kernel to nextgen_ehea_generic_bmap
like virt_to_abs.
>
> That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> in the core, so that we can deal with these kinds of problems, once and
> *NOT* in every single little driver out there.
>
> > Functions to use while building ehea_bmap + MRs:
> > - Use either the functions that are used by the memory hotplug system
as
> > well, that means using the section defines + functions
(section_nr_to_pfn,
> > pfn_valid)
>
> Basically, you can't use anything related to sections outside of the
> core code. You can use things like pfn_valid(), or you can create new
> interfaces that are properly abstracted.
We picked sections instead of PFNs because this keeps the ehea_bmap in a
reasonable range
on the existing systems.
But if you provide a abstract method handling exactly the problem we
mention
we'll be happy to use that and dump our private implementation.
>
> > - Use currently other not exported functions in kernel/resource.c, like
> > walk_memory_resource (where we would still need the maximum
> possible number
> > of pages NR_MEM_SECTIONS)
>
> It isn't the act of exporting that's the problem. It's making sure that
> the exports won't be prone to abuse and that people are using them
> properly. You should assume that you can export and use
> walk_memory_resource().
So this seems to come down to a basic question:
New hardware seems to have a tendency to get "private MMUs",
which need private mappings from the kernel address space into a
"HW defined address space with potentially unique characteristics"
RDMA in Openfabrics with global MR is the most prominent example heading
there
>
> Do you know what other operating systems do with this hardware?
We're not aware of another open source Operating system trying to address
this topic.
>
> In the future, please make an effort to get review from knowledgeable
> people about these kinds of things before using them in your driver.
> Your company has many, many resources available, and all you need to do
> is ask. All that you have to do is look to the tops of the files of the
> functions you are calling.
>
So we're glad we finally found the right person who takes responsibility
for this topic!
> -- Dave
>
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
^ permalink raw reply
* Re: Network namespace and tc?
From: Daniel Lezcano @ 2008-02-14 8:37 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: Stephen Hemminger, netdev, Linux Containers
In-Reply-To: <1202976470.7894.8.camel@iris.sw.ru>
Denis V. Lunev wrote:
> Hello, Stephen!
>
> Namespaces are not fully implemented yet :) Right now we we have only
> basic infrastructure in the mainstream and, currently, we can't even run
> TCP in different namespace :( We hope this will be changed very soon.
>
> These marks (net != &init_net) are used to
> - mark places we need to modify
> - ensure that we do not break initial namespace.
>
> Regards,
> Den
>
> On Wed, 2008-02-13 at 15:59 -0800, Stephen Hemminger wrote:
>> It looks like tc filter won't work on alternate namespaces:
>> /* Add/change/delete/get a filter node */
>>
>> static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
>> {
>> ...
>>
>> if (net != &init_net)
>> return -EINVAL;
>>
>>
>> Haven't played with namespace virtualization yet, but what else is
>> not supported? Where is this documented?
I wrote some documentation here:
http://lxc.sourceforge.net/network.php
That talk about configuration, bench, etc ...
Your question make me feel I should add a matrix with the current state
of the network namespace, what is in, what is done but not merged yet,
what is planned and what is not planned.
Thanks for paying attention at this.
-- Daniel
Sauf indication contraire ci-dessus:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 ?
SIREN/SIRET : 552 118 465 02430
^ permalink raw reply
* Re: Network namespace and tc?
From: Denis V. Lunev @ 2008-02-14 8:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080213155903.4ab6e454@extreme>
Hello, Stephen!
Namespaces are not fully implemented yet :) Right now we we have only
basic infrastructure in the mainstream and, currently, we can't even run
TCP in different namespace :( We hope this will be changed very soon.
These marks (net != &init_net) are used to
- mark places we need to modify
- ensure that we do not break initial namespace.
Regards,
Den
On Wed, 2008-02-13 at 15:59 -0800, Stephen Hemminger wrote:
> It looks like tc filter won't work on alternate namespaces:
> /* Add/change/delete/get a filter node */
>
> static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
> {
> ...
>
> if (net != &init_net)
> return -EINVAL;
>
>
> Haven't played with namespace virtualization yet, but what else is
> not supported? Where is this documented?
> --
> 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 to latest iproute to get it to compile on FC5
From: Ben Greear @ 2008-02-14 6:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: NetDev
In-Reply-To: <20080213123402.43cdbd45@extreme>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Here's another try at the patch to make the __constant_htonl methods
be included, but without changing any of the .h files. I tested this on
an FC2 system, and it compiles fine.
Interesting to me, it seems you are not supposed to #include
<asm/byteorder.h> directly,
but when I tried the suggested <endian.h>, it didn't actually fix the
problem.
Signed-off-by: Ben Greear <greearb@candelatech.com>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
[-- Attachment #2: iproute.patch --]
[-- Type: text/x-patch, Size: 285 bytes --]
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 3b466bf..2b2b78e 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -34,6 +34,7 @@
#include "ip_common.h"
#include "tunnel.h"
+#include <asm/byteorder.h>
static void usage(void) __attribute__((noreturn));
static void usage(void)
^ permalink raw reply related
* Re: [RFC] sky2: don't request unused i/o region
From: Jeff Garzik @ 2008-02-14 4:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080213190237.7cd49d60@extreme>
Stephen Hemminger wrote:
> The sky2 driver only uses the PCI memory region (0) not the
> available I/O region. Some users want to use lots of boards, and the
> I/O space gets exhausted.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/drivers/net/sky2.c 2008-02-13 18:58:21.000000000 -0800
> +++ b/drivers/net/sky2.c 2008-02-13 18:58:55.000000000 -0800
> @@ -4135,9 +4135,9 @@ static int __devinit sky2_probe(struct p
> goto err_out;
> }
>
> - err = pci_request_regions(pdev, DRV_NAME);
> + err = pci_request_region(pdev, 0, DRV_NAME);
> if (err) {
> - dev_err(&pdev->dev, "cannot obtain PCI resources\n");
> + dev_err(&pdev->dev, "cannot obtain PCI resource\n");
Your description of the problem does not match the fix.
PCI resources are already allocated to the device (or not) by this point
in the code. pci_request_region/regions is purely internal kernel
software resource reservation -- protecting drivers from themselves, and
arguably not really needed anymore on modern buses.
Thus, I cannot see how this patch can possibly "exhaust I/O space" --
the relevant PCI resources are allocated to the device, or not,
regardless of these function calls.
As long as there is no resource conflict, you can have 1 million boards
and still use pci_request_regions().
Jeff
^ 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