* [PATCH take2] [AX25] circular locking with AX25 connection timeout
From: Jarek Poplawski @ 2007-12-15 10:18 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: David Miller, Ralf Baechle DL5RB, Linux Netdev List
In-Reply-To: <476303C8.2060507@ccr.jussieu.fr>
On Fri, Dec 14, 2007 at 11:29:28PM +0100, Bernard Pidoux wrote:
> Hi,
>
> This patch cancels a circular locking conflict that appeared with a timeout
> of an AX25 connection.
>
> signed off by Jarek Poplawski
One spurious space less here, and maybe a few more words to the changelog.
Regards,
Jarek P.
---------------->
Subject: [PATCH] [NET] AX25: locking dependencies fix in ax25_disconnect
Bernard Pidoux reported these lockdep warnings:
[ INFO: possible irq lock inversion dependency detected ]
2.6.23.1 #1
---------------------------------------------------------
fpac/4933 just changed the state of lock:
(slock-AF_AX25){--..}, at: [<d8be3312>] ax25_disconnect+0x46/0xaf
[ax25]
but this lock was taken by another, soft-irq-safe lock in the past:
(ax25_list_lock){-+..}
and interrupts could create inverse lock ordering between them.
[...]
[ INFO: inconsistent lock state ]
2.6.23.1 #1
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
ax25_call/4005 [HC0[0]:SC0[0]:HE1:SE1] takes:
(slock-AF_AX25){-+..}, at: [<d8b79312>] ax25_disconnect+0x46/0xaf [ax25]
[...]
This means slock-AF_AX25 could be taken both from softirq and process
context with softirqs enabled, so it's endangered itself, but also makes
ax25_list_lock vulnerable. It was not 100% verified if the real lockup
can happen, but this fix isn't very costly and looks safe anyway.
(It was tested by Bernard with 2.6.23.9 and 2.6.24-rc5 kernels.)
Reported_by: Bernard Pidoux <pidoux@ccr.jussieu.fr>
Tested_by: Bernard Pidoux <pidoux@ccr.jussieu.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff -Nurp linux-2.6.24-rc2-/net/ax25/ax25_subr.c linux-2.6.24-rc2+/net/ax25/ax25_subr.c
--- linux-2.6.24-rc2-/net/ax25/ax25_subr.c 2007-10-09 22:31:38.000000000 +0200
+++ linux-2.6.24-rc2+/net/ax25/ax25_subr.c 2007-11-28 11:51:12.000000000 +0100
@@ -279,6 +279,7 @@ void ax25_disconnect(ax25_cb *ax25, int
ax25_link_failed(ax25, reason);
if (ax25->sk != NULL) {
+ local_bh_disable();
bh_lock_sock(ax25->sk);
ax25->sk->sk_state = TCP_CLOSE;
ax25->sk->sk_err = reason;
@@ -288,5 +289,6 @@ void ax25_disconnect(ax25_cb *ax25, int
sock_set_flag(ax25->sk, SOCK_DEAD);
}
bh_unlock_sock(ax25->sk);
+ local_bh_enable();
}
}
^ permalink raw reply
* Re: [PATCH 03/29] mm: slb: add knowledge of reserve pages
From: Daniel Phillips @ 2007-12-15 10:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, Andrew Morton, linux-kernel, linux-mm, netdev,
trond.myklebust
In-Reply-To: <200712141451.09500.phillips@phunq.net>
On Friday 14 December 2007 14:51, I wrote:
> On Friday 14 December 2007 07:39, Peter Zijlstra wrote:
> Note that false sharing of slab pages is still possible between two
> unrelated writeout processes, both of which obey rules for their own
> writeout path, but the pinned combination does not. This still
> leaves a hole through which a deadlock may slip.
Actually, no it doesn't. It in fact does not matter how many unrelated
writeout processes, block devices, whatevers share a slab cache.
Sufficient reserve pages must have been made available (in a perfect
work, by adding extra pages to the memalloc reserve on driver
initialization, in the real world just by having a big memalloc
reserve) to populate the slab up to the sum of the required objects for
all memalloc users sharing the cache.
So I think this slab technique of yours is fundamentally sound, that is
to say, adding a new per-slab flag to keep unbounded numbers of slab
objects with unbounded lifetimes from mixing with the bounded number of
slab objects with bounded lifetimes.
Ponder. OK, here is another issue. Suppose a driver expands the
memalloc reserve by the X number of pages it needs on initialization,
and shrinks it by the same amount on removal, as is right and proper.
The problem is, less than the number of slab pages that got pulled into
slab on behalf of the removed driver may be freed (or made freeable)
back to the global reserve, due to page sharing with an unrelated user.
In theory, the global reserve could be completely depleted by this slab
fragmentation.
OK, that is like the case that I mistakenly raised in the previous mail,
though far less likely to occur, because driver removals are relatively
rare and so would be a fragmentation case so severe as to cause global
reserve depletion.
Even so, if this possibility bothers anybody, it is fairly easy to plug
the hole: associate each slab with a given memalloc user instead of
just having one bit to classify users. So unrelated memalloc users
would never share a slab, no false sharing, everybody happy. The cost:
a new pointer field per slab and a few additional lines of code.
Regards,
Daniel
^ permalink raw reply
* SACK scoreboard (Was: Re: [RFC PATCH net-2.6.25 uncompilable] [TCP]: Avoid breaking GSOed skbs when SACKed one-by-one)
From: Ilpo Järvinen @ 2007-12-15 9:51 UTC (permalink / raw)
To: David Miller; +Cc: lachlan.andrew, Netdev, quetchen
In-Reply-To: <20071211.043239.224938181.davem@davemloft.net>
On Tue, 11 Dec 2007, David Miller wrote:
> Interesting approach, but I think there is limited value to this
> (arguably) complex form.
>
> The core issue is that the data and the SACK state are maintained in
> the same datastructure. The complexity in all the state management
> and fixups in your patch is purely because of this.
Yeah, had just too much time while waiting for person who never
arrived... :-) It would have covered the typical case quite well
tough, for sure it was very intrusive.
> If we maintain SACK scoreboard information seperately, outside of
> the SKB, then there are only two changes to make:
>
> 1) Every access to TCP_SKB_CB() SACK scoreboard is adjusted to
> new data structure.
Not sure if it is going to all that straightforward because you seem to
ignore in this simple description all details of performing the linking
between the structures, which becomes tricky when we add those
retransmission adjustments.
> 2) Retransmit is adjusted so that it can retransmit an SKB
> constructed as a portion of an existing SKB. Since TSO
> implies SG, this can be handled with simple offset and
> length arguments and suitable creation of a clone referencing
> the pages in the SG vector that contain the desired data.
...I.e., how to count retrans_out origins in such case because the
presented sack_ref knows nothing about them nor do we have anything but
one bit in ->sacked per skb. We need the origins when retransmission get
sacked/acked to reduce retrans_out correctly. To solve this, I think the
sack_ref must have ->sacked as well and the structure should store the
R-bits there as well, and may L-bits too though their defination is
more obvious because it's mostly a complement of sacked (except for small
part near fackets_out and timedout marking that probably makes bookkeeping
of L still necessary).
The pcount boundaries are no longer that well defined after we break skb
boundaries during retransmitting, so doing this makes fackets_out
calculation even more trickier to track, unless whole pcount is replaced
by byte based fackets_out :-/, which is very trivial to determine from
seqnos only (TCP_NODELAYers might get unhappy though if we do that in a
straightforward way...).
This would clearly be a good step from one perspective. Nowadays GSO'ed
skbs may get fragmented when mss_now changes, for two or more consecutive
non-SACKed skbs that means one or more extra (small) packets when
retransmitting.
> I would envision this SACK state thing to reference into the
> retransmit queue SKB's somehow. Each SACK block could perhaps
> look something like:
>
> struct sack_ref {
> struct sk_buff *start_skb;
> struct sk_buff *end_skb;
> unsigned int start_off;
> unsigned int len;
> };
...I assume that these are fast searchable? And skbs as well (because the
linking of start/end_skb at minimum is a costly operation otherwise)?
--
i.
^ permalink raw reply
* Re: Regression: Wireshark sees no packets in 2.6.24-rc3
From: Ray Lee @ 2007-12-15 8:16 UTC (permalink / raw)
To: Gabriel C; +Cc: Rafael J. Wysocki, netdev, LKML
In-Reply-To: <2c0942db0712142309v15f79068m8c033180d41b9be@mail.gmail.com>
On Dec 14, 2007 11:09 PM, Ray Lee <ray@madrabbit.org> wrote:
> On Dec 14, 2007 6:41 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
> Correct, absolutely no traffic. So if it works for you, then either
> it's something that got fixed between -rc3 and -rc5, or something odd
> when I did a make oldconfig, I suppose. (Or because I'm on an x86-64
> kernel?) Regardless, -rc5 is currently building, and I'll try it in
> the morning.
-rc5 works great. Really don't know what's different between my -rc3
and -rc5 builds. The diff of .config between the two doesn't show
anything obvious, so perhaps it was something fixed in the interim.
I've gone ahead and closed the bugzilla entry, btw. Thanks, and sorry
for the false (or tardy) alarm.
Ray
^ permalink raw reply
* Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
From: Herbert Xu @ 2007-12-15 7:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: miles.lane, linux-kernel, netdev, mingo, a.p.zijlstra
In-Reply-To: <20071214153633.5d8f609a.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I'd say you hit a networking locking bug and then when trying to report
> that bug, lockdep crashed.
>
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
>
> diff -puN net/core/sock.c~a net/core/sock.c
> --- a/net/core/sock.c~a
> +++ a/net/core/sock.c
> @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> {
> int uid;
>
> - read_lock(&sk->sk_callback_lock);
> + read_lock_bh(&sk->sk_callback_lock);
> uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> - read_unlock(&sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
The callback lock is never taken for writing in BH context so
this shouldn't be needed.
Let's fix the lockdep checker first and then decide what's broken
in networking, OK?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Regression: Wireshark sees no packets in 2.6.24-rc3
From: Ray Lee @ 2007-12-15 7:09 UTC (permalink / raw)
To: Gabriel C; +Cc: Rafael J. Wysocki, netdev, LKML
In-Reply-To: <47633ECC.3020804@googlemail.com>
On Dec 14, 2007 6:41 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Ray Lee wrote:
> >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
> >> fine. A quick scan of the log between 2.6.24-rc3 and current tip
> >> (-rc5) doesn't show any obvious fixes, but then again, what do I know.
> >> I'll check current tip on the weekend when I'll have the luxury to
> >> have my main system down long enough for a test. Right now I'm kinda
> >> up against a deadline, but didn't want to leave it unreported. Should
> >> be easy for someone else to confirm or deny whether current tip has
> >> the problem.
> >
> > FYI, I have created a bugzilla entry for this issue at:
> > http://bugzilla.kernel.org/show_bug.cgi?id=9568
>
> Hmm what do you mean by empty ? it does not capturing anything on that interface ?
Correct, absolutely no traffic. So if it works for you, then either
it's something that got fixed between -rc3 and -rc5, or something odd
when I did a make oldconfig, I suppose. (Or because I'm on an x86-64
kernel?) Regardless, -rc5 is currently building, and I'll try it in
the morning.
> I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here.
Excellent. Thank you for checking!
Rafael: I'll update the bugzilla as warranted after testing.
Ray
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Herbert Xu @ 2007-12-15 6:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev
In-Reply-To: <20071214214418.0ecd5e67.akpm@linux-foundation.org>
On Fri, Dec 14, 2007 at 09:44:18PM -0800, Andrew Morton wrote:
>
> That sounds like a bug in mutex_trylock() to me.
I was relying on
http://kerneltrap.org/mailarchive/linux-netdev/2007/9/28/325129
which seems to be a bogus claim now that I actually look at the
source code. So in that case I'm OK with your patch as long as
it warns about hard IRQ usage.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
From: Andrew Morton @ 2007-12-15 5:58 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, netdev, Ingo Molnar, Peter Zijlstra
In-Reply-To: <a44ae5cd0712141958o10d9a320h3b8173019ac6b0eb@mail.gmail.com>
On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> On Dec 14, 2007 6:36 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Fri, 14 Dec 2007 17:13:21 -0500
> > "Miles Lane" <miles.lane@gmail.com> wrote:
> >
> >
> > > Sorry Andrew, I don't know who to forward this problem to.
> > >
> > > I tried running: find /proc | xargs cat
> > > and got this:
> > >
> > > =================================
> > > [ INFO: inconsistent lock state ]
> > > 2.6.24-rc5-mm1 #26
> > > ---------------------------------
> > > inconsistent {in-softirq-W} -> {softirq-on-R} usage.
> > > cat/6944 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > > BUG: unable to handle kernel paging request at virtual address 0f1eff0b
> > > printing ip: c01fe64d *pde = 00000000
> > > Oops: 0000 [#1] PREEMPT SMP
> > > last sysfs file: /sys/block/sda/sda3/stat
> > > Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> > > cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> > > dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> > > cryptomgr crypto_algapi tifm_7xx1 tifm_core yenta_socket
> > > rsrc_nonstatic pcmcia_core iwl3945 iTCO_wdt iTCO_vendor_support
> > > watchdog_core watchdog_dev snd_hda_intel mac80211 snd_pcm_oss
> > > snd_mixer_oss cfg80211 snd_pcm sky2 snd_seq_dummy snd_seq_oss
> > > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> > > snd_seq_device snd soundcore snd_page_alloc shpchp pci_hotplug
> > > firewire_ohci firewire_core crc_itu_t ata_generic piix ide_core
> > >
> > > Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26)
> > > EIP: 0060:[<c01fe64d>] EFLAGS: 00210097 CPU: 0
> > > EIP is at strnlen+0x9/0x1c
> > > EAX: 0f1eff0b EBX: 0f1eff0b ECX: 0f1eff0b EDX: fffffffe
> > > ESI: c05b74f6 EDI: d6267d94 EBP: d6267cc8 ESP: d6267cc8
> > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > Process cat (pid: 6944, ti=d6267000 task=d5a09000 task.ti=d6267000)
> > > Stack: d6267cfc c01fdd22 00000400 c05b74f4 00000001 c05b78f4 00000000 ffffffff
> > > ffffffff c048f503 00000400 d5a09000 00000002 d6267d0c c01fdf41 d6267d94
> > > db68c04a d6267d74 c012ae81 d6267d94 00000028 c05b89f7 00200046 00000000
> > > Call Trace:
> > > [<c0108eb2>] show_trace_log_lvl+0x12/0x25
> > > [<c0108f4f>] show_stack_log_lvl+0x8a/0x95
> > > [<c0108fe4>] show_registers+0x8a/0x1bd
> > > [<c010922f>] die+0x118/0x1dc
> > > [<c03cf706>] do_page_fault+0x5a4/0x681
> > > [<c03cdd72>] error_code+0x72/0x78
> > > [<c01fdd22>] vsnprintf+0x277/0x40e
> > > [<c01fdf41>] vscnprintf+0xe/0x1d
> > > [<c012ae81>] vprintk+0xcb/0x2f3
> > > [<c012b0be>] printk+0x15/0x17
> > > [<c0145e55>] print_lock_name+0x4e/0xa2
> > > [<c0146099>] print_lock+0xe/0x3a
> > > [<c01464cf>] print_usage_bug+0xbc/0x117
> > > [<c0146fb6>] mark_lock+0x2e7/0x3fe
> > > [<c0147b9a>] __lock_acquire+0x498/0xbf4
> > > [<c014836c>] lock_acquire+0x76/0x9d
> > > [<c03cd6d2>] _read_lock+0x23/0x32
> > > [<c03491ae>] sock_i_ino+0x14/0x30
> > > [<c03c88ed>] packet_seq_show+0x22/0x75
> > > [<c019b41a>] seq_read+0x19d/0x26f
> > > [<c01b0ded>] proc_reg_read+0x60/0x74
> > > [<c01854aa>] vfs_read+0x8a/0x106
> > > [<c01858a8>] sys_read+0x3b/0x60
> > > [<c0107cea>] sysenter_past_esp+0x6b/0xc1
> > > =======================
> > > Code: 01 00 00 00 4f 89 fa 5f 89 d0 5d c3 55 85 c9 89 e5 57 89 c7 89
> > > d0 74 05 f2 ae 75 01 4f 89 f8 5f 5d c3 55 89 c1 89 e5 89 c8 eb 06 <80>
> > > 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 83
> > > EIP: [<c01fe64d>] strnlen+0x9/0x1c SS:ESP 0068:d6267cc8
> > > note: cat[6944] exited with preempt_count 4
> >
> > I'd say you hit a networking locking bug and then when trying to report
> > that bug, lockdep crashed.
> >
> > The networking bug looks to be around sock_i_ino()'s taking of
> > sk_callback_lock with softirq's enabled. Perhaps this will fix it.
> >
> > diff -puN net/core/sock.c~a net/core/sock.c
> > --- a/net/core/sock.c~a
> > +++ a/net/core/sock.c
> > @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> > {
> > int uid;
> >
> > - read_lock(&sk->sk_callback_lock);
> > + read_lock_bh(&sk->sk_callback_lock);
> > uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> > - read_unlock(&sk->sk_callback_lock);
> > + read_unlock_bh(&sk->sk_callback_lock);
> > return uid;
> > }
> >
> > @@ -1125,9 +1125,9 @@ unsigned long sock_i_ino(struct sock *sk
> > {
> > unsigned long ino;
> >
> > - read_lock(&sk->sk_callback_lock);
> > + read_lock_bh(&sk->sk_callback_lock);
> > ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0;
> > - read_unlock(&sk->sk_callback_lock);
> > + read_unlock_bh(&sk->sk_callback_lock);
> > return ino;
> > }
> >
> > _
> >
> >
>
> I applied the patch and then tried my test again. This time my system
> locked up.
> Perhaps I should open a new thread for this, since the problem looks
> pretty different.
>
> Dec 14 21:32:55 feargod kernel: process `cat' is using deprecated
> sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
> net.ipv6.neigh.default.retran
> s_time_ms instead.
> Dec 14 21:32:55 feargod kernel:
> Dec 14 21:32:55 feargod kernel: =====================================
> Dec 14 21:32:55 feargod kernel: [ BUG: bad unlock balance detected! ]
> Dec 14 21:32:55 feargod kernel: -------------------------------------
> Dec 14 21:32:55 feargod kernel: cat/6180 is trying to release lock
> (kkkkkkk�����H3��) at:
> Dec 14 21:32:55 feargod kernel: [packet_seq_stop+0xe/0x10]
> packet_seq_stop+0xe/0x10
> Dec 14 21:32:55 feargod kernel: but there are no more locks to release!
> Dec 14 21:32:55 feargod kernel:
> Dec 14 21:32:55 feargod kernel: other info that might help us debug this:
> Dec 14 21:32:55 feargod kernel: 2 locks held by cat/6180:
> Dec 14 21:32:55 feargod kernel: #0: (&p->lock){--..}, at:
> [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
> Dec 14 21:32:55 feargod kernel: #1:
> (&net->packet.sklist_lock){-.--}, at: [packet_seq_start+0x14/0x4d]
> packet_seq_start+0x14/0x4d
> Dec 14 21:32:55 feargod kernel:
> Dec 14 21:32:55 feargod kernel: stack backtrace:
> Dec 14 21:32:55 feargod kernel: Pid: 6180, comm: cat Not tainted
> 2.6.24-rc5-mm1 #27
> Dec 14 21:32:55 feargod kernel: [show_trace_log_lvl+0x12/0x25]
> show_trace_log_lvl+0x12/0x25
> Dec 14 21:32:55 feargod kernel: [show_trace+0xd/0x10] show_trace+0xd/0x10
> Dec 14 21:32:55 feargod kernel: [sbp2:dump_stack+0x57/0x17a1]
> dump_stack+0x57/0x5f
> Dec 14 21:32:55 feargod kernel:
> [print_unlock_inbalance_bug+0xce/0xd8]
> print_unlock_inbalance_bug+0xce/0xd8
> Dec 14 21:32:55 feargod kernel: [lock_release_non_nested+0x89/0x13b]
> lock_release_non_nested+0x89/0x13b
> Dec 14 21:32:55 feargod kernel: [mac80211:lock_release+0x186/0x5065]
> lock_release+0x186/0x1b6
> Dec 14 21:32:55 feargod kernel: [snd_seq:_read_unlock+0x16/0x3d]
> _read_unlock+0x16/0x3d
> Dec 14 21:32:55 feargod kernel: [packet_seq_stop+0xe/0x10]
> packet_seq_stop+0xe/0x10
> Dec 14 21:32:55 feargod kernel:
> [crypto_algapi:seq_read+0x1d4/0x191c1] seq_read+0x1d4/0x26f
> Dec 14 21:32:55 feargod kernel: [proc_reg_read+0x60/0x74]
> proc_reg_read+0x60/0x74
> Dec 14 21:32:55 feargod kernel: [vfs_read+0x8a/0x106] vfs_read+0x8a/0x106
> Dec 14 21:32:55 feargod kernel: [sys_read+0x3b/0x60] sys_read+0x3b/0x60
> Dec 14 21:32:55 feargod kernel: [sysenter_past_esp+0x6b/0xc1]
ugly. At a guess I'd say the code in there has got a hold of some
corrupted/garbage memory when it thinks it has a struct sock*.
Do you have a recipe which others might use to reproduce this?
<waves vigorously at net developers>
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Andrew Morton @ 2007-12-15 5:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
In-Reply-To: <20071215041827.GC25324@gondor.apana.org.au>
On Sat, 15 Dec 2007 12:18:27 +0800 Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Dec 14, 2007 at 03:11:36PM -0800, Andrew Morton wrote:
> >
> > I don't believe that ASSERT_RTNL() presently warns when called from atomic
> > contexts. If it does then I missed it.
>
> It does when mutex debugging is enabled.
>
That sounds like a bug in mutex_trylock() to me.
Where in the tangled forest of the mutex implementation is the code
which does this?
^ permalink raw reply
* [PATCH 4/4] [UDP]: memory accounting in IPv4
From: Hideo AOKI @ 2007-12-15 5:15 UTC (permalink / raw)
To: David Miller, Herbert Xu, netdev
Cc: Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, billfink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita, haoki
In-Reply-To: <47636120.4050701@redhat.com>
This patch adds UDP memory usage accounting in IPv4.
Send buffer accounting is performed by IP layer, because skbuff is
allocated in the layer.
Receive buffer is charged, when the buffer successfully received.
Destructor of the buffer does un charging and reclaiming, when the
buffer is freed. To set destructor at proper place, we introduce
udp_set_owner_r().
In addition, to make sure that sk_forward_alloc is totally uncharged
in socket destruction, a reclaiming is added to inet_sock_destruct().
Cc: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Takahiro Yasui <tyasui@redhat.com>
signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---
af_inet.c | 2 ++
ip_output.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
udp.c | 16 +++++++++++++++-
3 files changed, 61 insertions(+), 3 deletions(-)
diff -pruN net-2.6-udp-take10a4-p3/net/ipv4/af_inet.c net-2.6-udp-take10a4-p4/net/ipv4/af_inet.c
--- net-2.6-udp-take10a4-p3/net/ipv4/af_inet.c 2007-12-14 20:27:54.000000000 -0500
+++ net-2.6-udp-take10a4-p4/net/ipv4/af_inet.c 2007-12-14 21:06:54.000000000 -0500
@@ -144,6 +144,8 @@ void inet_sock_destruct(struct sock *sk)
printk("Attempt to release alive inet socket %p\n", sk);
return;
}
+ if (sk->sk_type == SOCK_DGRAM)
+ sk_datagram_mem_reclaim(sk);
BUG_TRAP(!atomic_read(&sk->sk_rmem_alloc));
BUG_TRAP(!atomic_read(&sk->sk_wmem_alloc));
diff -pruN net-2.6-udp-take10a4-p3/net/ipv4/ip_output.c net-2.6-udp-take10a4-p4/net/ipv4/ip_output.c
--- net-2.6-udp-take10a4-p3/net/ipv4/ip_output.c 2007-12-14 16:42:04.000000000 -0500
+++ net-2.6-udp-take10a4-p4/net/ipv4/ip_output.c 2007-12-14 21:06:54.000000000 -0500
@@ -707,6 +707,7 @@ static inline int ip_ufo_append_data(str
{
struct sk_buff *skb;
int err;
+ int first_size, second_size;
/* There is support for UDP fragmentation offload by network
* device, so create one single skb packet containing complete
@@ -720,6 +721,11 @@ static inline int ip_ufo_append_data(str
if (skb == NULL)
return err;
+ if (!sk_account_wmem_charge(sk, skb->truesize)) {
+ err = -ENOBUFS;
+ goto fail;
+ }
+
/* reserve space for Hardware header */
skb_reserve(skb, hh_len);
@@ -736,6 +742,7 @@ static inline int ip_ufo_append_data(str
skb->csum = 0;
sk->sk_sndmsg_off = 0;
}
+ first_size = skb->truesize;
err = skb_append_datato_frags(sk,skb, getfrag, from,
(length - transhdrlen));
@@ -743,6 +750,15 @@ static inline int ip_ufo_append_data(str
/* specify the length of each IP datagram fragment*/
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+
+ second_size = skb->truesize - first_size;
+ if (!sk_account_wmem_charge(sk, second_size)) {
+ sk_account_uncharge(sk, first_size);
+ sk_mem_reclaim(sk);
+ err = -ENOBUFS;
+ goto fail;
+ }
+
__skb_queue_tail(&sk->sk_write_queue, skb);
return 0;
@@ -750,6 +766,7 @@ static inline int ip_ufo_append_data(str
/* There is not enough support do UFO ,
* so follow normal path
*/
+fail:
kfree_skb(skb);
return err;
}
@@ -924,6 +941,11 @@ alloc_new_skb:
}
if (skb == NULL)
goto error;
+ if (!sk_account_wmem_charge(sk, skb->truesize)) {
+ err = -ENOBUFS;
+ kfree_skb(skb);
+ goto error;
+ }
/*
* Fill in the control structures
@@ -954,6 +976,8 @@ alloc_new_skb:
copy = datalen - transhdrlen - fraggap;
if (copy > 0 && getfrag(from, data + transhdrlen, offset, copy, fraggap, skb) < 0) {
err = -EFAULT;
+ sk_account_uncharge(sk, skb->truesize);
+ sk_mem_reclaim(sk);
kfree_skb(skb);
goto error;
}
@@ -1023,6 +1047,10 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
skb->truesize += PAGE_SIZE;
atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc);
+ if (!sk_account_wmem_charge(sk, PAGE_SIZE)) {
+ err = -ENOBUFS;
+ goto error;
+ }
} else {
err = -EMSGSIZE;
goto error;
@@ -1124,6 +1152,11 @@ ssize_t ip_append_page(struct sock *sk,
err = -ENOBUFS;
goto error;
}
+ if (!sk_account_wmem_charge(sk, skb->truesize)) {
+ kfree_skb(skb);
+ err = -ENOBUFS;
+ goto error;
+ }
/*
* Fill in the control structures
@@ -1213,13 +1246,14 @@ int ip_push_pending_frames(struct sock *
struct iphdr *iph;
__be16 df = 0;
__u8 ttl;
- int err = 0;
+ int err = 0, send_size;
if ((skb = __skb_dequeue(&sk->sk_write_queue)) == NULL)
goto out;
tail_skb = &(skb_shinfo(skb)->frag_list);
/* move skb->data to ip header from ext header */
+ send_size = skb->truesize;
if (skb->data < skb_network_header(skb))
__skb_pull(skb, skb_network_offset(skb));
while ((tmp_skb = __skb_dequeue(&sk->sk_write_queue)) != NULL) {
@@ -1229,6 +1263,7 @@ int ip_push_pending_frames(struct sock *
skb->len += tmp_skb->len;
skb->data_len += tmp_skb->len;
skb->truesize += tmp_skb->truesize;
+ send_size += tmp_skb->truesize;
__sock_put(tmp_skb->sk);
tmp_skb->destructor = NULL;
tmp_skb->sk = NULL;
@@ -1284,6 +1319,8 @@ int ip_push_pending_frames(struct sock *
/* Netfilter gets whole the not fragmented skb. */
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
skb->dst->dev, dst_output);
+ sk_account_uncharge(sk, send_size);
+ sk_mem_reclaim(sk);
if (err) {
if (err > 0)
err = inet->recverr ? net_xmit_errno(err) : 0;
@@ -1306,10 +1343,15 @@ error:
void ip_flush_pending_frames(struct sock *sk)
{
struct sk_buff *skb;
+ int truesize = 0;
- while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL)
+ while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) {
+ truesize += skb->truesize;
kfree_skb(skb);
+ }
+ sk_account_uncharge(sk, truesize);
+ sk_mem_reclaim(sk);
ip_cork_release(inet_sk(sk));
}
diff -pruN net-2.6-udp-take10a4-p3/net/ipv4/udp.c net-2.6-udp-take10a4-p4/net/ipv4/udp.c
--- net-2.6-udp-take10a4-p3/net/ipv4/udp.c 2007-12-14 20:27:54.000000000 -0500
+++ net-2.6-udp-take10a4-p4/net/ipv4/udp.c 2007-12-14 21:06:54.000000000 -0500
@@ -934,6 +934,13 @@ int udp_disconnect(struct sock *sk, int
return 0;
}
+void udp_set_owner_r(struct sk_buff *skb, struct sock *sk)
+{
+ skb->sk = sk;
+ skb->destructor = sk_datagram_rfree;
+ atomic_add(skb->truesize, &sk->sk_rmem_alloc);
+}
+
/* returns:
* -1: error
* 0: success
@@ -1022,10 +1029,17 @@ int udp_queue_rcv_skb(struct sock * sk,
goto drop;
}
- if ((rc = sock_queue_rcv_skb(sk,skb)) < 0) {
+ if (!sk_account_rmem_charge(sk, skb->truesize)) {
+ UDP_INC_STATS_BH(UDP_MIB_RCVBUFERRORS, up->pcflag);
+ goto drop;
+ }
+
+ if ((rc = sock_queue_rcv_skb_with_owner(sk, skb, udp_set_owner_r)) < 0) {
/* Note that an ENOMEM error is charged twice */
if (rc == -ENOMEM)
UDP_INC_STATS_BH(UDP_MIB_RCVBUFERRORS, up->pcflag);
+ sk_account_uncharge(sk, skb->truesize);
+ sk_datagram_mem_reclaim(sk);
goto drop;
}
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* [PATCH 3/4] [UDP]: add udp_mem, udp_rmem_min and udp_wmem_min
From: Hideo AOKI @ 2007-12-15 5:15 UTC (permalink / raw)
To: David Miller, Herbert Xu, netdev
Cc: Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, billfink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita, haoki
In-Reply-To: <47636120.4050701@redhat.com>
This patch adds sysctl parameters for customizing UDP memory accounting:
/proc/sys/net/ipv4/udp_mem
/proc/sys/net/ipv4/udp_rmem_min
/proc/sys/net/ipv4/udp_wmem_min
Udp_mem indicates number of pages which can be used for all UDP sockets.
Each UDP packet is dropped, when the number of pages for socket buffer is
beyond udp_mem and the socket already consumes minimum buffer.
This patch is also introduced memory_allocated variable for UDP protocol.
Cc: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---
Documentation/networking/ip-sysctl.txt | 18 ++++++++++++++++++
include/net/udp.h | 9 +++++++++
net/ipv4/af_inet.c | 3 +++
net/ipv4/proc.c | 3 ++-
net/ipv4/sysctl_net_ipv4.c | 31 +++++++++++++++++++++++++++++++
net/ipv4/udp.c | 27 +++++++++++++++++++++++++++
6 files changed, 90 insertions(+), 1 deletion(-)
diff -pruN net-2.6-udp-take10a4-p2/Documentation/networking/ip-sysctl.txt net-2.6-udp-take10a4-p3/Documentation/networking/ip-sysctl.txt
--- net-2.6-udp-take10a4-p2/Documentation/networking/ip-sysctl.txt 2007-12-11 10:54:41.000000000 -0500
+++ net-2.6-udp-take10a4-p3/Documentation/networking/ip-sysctl.txt 2007-12-14 20:27:54.000000000 -0500
@@ -446,6 +446,24 @@ tcp_dma_copybreak - INTEGER
and CONFIG_NET_DMA is enabled.
Default: 4096
+UDP variables:
+
+udp_mem - INTEGER
+ Number of pages allowed for queueing by all UDP sockets.
+ Default is calculated at boot time from amount of available memory.
+
+udp_rmem_min - INTEGER
+ Minimal size of receive buffer used by UDP sockets. Each UDP socket
+ is able to use the size for receiving data, even if total pages of UDP
+ sockets exceed udp_mem. The unit is byte.
+ Default: 4096
+
+udp_wmem_min - INTEGER
+ Minimal size of send buffer used by UDP sockets. Each UDP socket is
+ able to use the size for sending data, even if total pages of UDP
+ sockets exceed udp_mem. The unit is byte.
+ Default: 4096
+
CIPSOv4 Variables:
cipso_cache_enable - BOOLEAN
diff -pruN net-2.6-udp-take10a4-p2/include/net/udp.h net-2.6-udp-take10a4-p3/include/net/udp.h
--- net-2.6-udp-take10a4-p2/include/net/udp.h 2007-12-11 10:54:53.000000000 -0500
+++ net-2.6-udp-take10a4-p3/include/net/udp.h 2007-12-14 20:27:54.000000000 -0500
@@ -65,6 +65,13 @@ extern rwlock_t udp_hash_lock;
extern struct proto udp_prot;
+extern atomic_t udp_memory_allocated;
+
+/* sysctl variables for udp */
+extern int sysctl_udp_mem;
+extern int sysctl_udp_rmem_min;
+extern int sysctl_udp_wmem_min;
+
struct sk_buff;
/*
@@ -173,4 +180,6 @@ extern void udp_proc_unregister(struct u
extern int udp4_proc_init(void);
extern void udp4_proc_exit(void);
#endif
+
+extern void udp_init(void);
#endif /* _UDP_H */
diff -pruN net-2.6-udp-take10a4-p2/net/ipv4/af_inet.c net-2.6-udp-take10a4-p3/net/ipv4/af_inet.c
--- net-2.6-udp-take10a4-p2/net/ipv4/af_inet.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p3/net/ipv4/af_inet.c 2007-12-14 20:27:54.000000000 -0500
@@ -1418,6 +1418,9 @@ static int __init inet_init(void)
/* Setup TCP slab cache for open requests. */
tcp_init();
+ /* Setup UDP memory threshold */
+ udp_init();
+
/* Add UDP-Lite (RFC 3828) */
udplite4_register();
diff -pruN net-2.6-udp-take10a4-p2/net/ipv4/proc.c net-2.6-udp-take10a4-p3/net/ipv4/proc.c
--- net-2.6-udp-take10a4-p2/net/ipv4/proc.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p3/net/ipv4/proc.c 2007-12-14 20:27:54.000000000 -0500
@@ -56,7 +56,8 @@ static int sockstat_seq_show(struct seq_
sock_prot_inuse(&tcp_prot), atomic_read(&tcp_orphan_count),
tcp_death_row.tw_count, atomic_read(&tcp_sockets_allocated),
atomic_read(&tcp_memory_allocated));
- seq_printf(seq, "UDP: inuse %d\n", sock_prot_inuse(&udp_prot));
+ seq_printf(seq, "UDP: inuse %d mem %d\n", sock_prot_inuse(&udp_prot),
+ atomic_read(&udp_memory_allocated));
seq_printf(seq, "UDPLITE: inuse %d\n", sock_prot_inuse(&udplite_prot));
seq_printf(seq, "RAW: inuse %d\n", sock_prot_inuse(&raw_prot));
seq_printf(seq, "FRAG: inuse %d memory %d\n",
diff -pruN net-2.6-udp-take10a4-p2/net/ipv4/sysctl_net_ipv4.c net-2.6-udp-take10a4-p3/net/ipv4/sysctl_net_ipv4.c
--- net-2.6-udp-take10a4-p2/net/ipv4/sysctl_net_ipv4.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p3/net/ipv4/sysctl_net_ipv4.c 2007-12-14 20:27:54.000000000 -0500
@@ -18,6 +18,7 @@
#include <net/ip.h>
#include <net/route.h>
#include <net/tcp.h>
+#include <net/udp.h>
#include <net/cipso_ipv4.h>
#include <net/inet_frag.h>
@@ -885,6 +886,36 @@ ctl_table ipv4_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "udp_mem",
+ .data = &sysctl_udp_mem,
+ .maxlen = sizeof(sysctl_udp_mem),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero
+ },
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "udp_rmem_min",
+ .data = &sysctl_udp_rmem_min,
+ .maxlen = sizeof(sysctl_udp_rmem_min),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero
+ },
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "udp_wmem_min",
+ .data = &sysctl_udp_wmem_min,
+ .maxlen = sizeof(sysctl_udp_wmem_min),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero
+ },
{ .ctl_name = 0 }
};
diff -pruN net-2.6-udp-take10a4-p2/net/ipv4/udp.c net-2.6-udp-take10a4-p3/net/ipv4/udp.c
--- net-2.6-udp-take10a4-p2/net/ipv4/udp.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p3/net/ipv4/udp.c 2007-12-14 20:27:54.000000000 -0500
@@ -82,6 +82,7 @@
#include <asm/system.h>
#include <asm/uaccess.h>
#include <asm/ioctls.h>
+#include <linux/bootmem.h>
#include <linux/types.h>
#include <linux/fcntl.h>
#include <linux/module.h>
@@ -114,6 +115,11 @@ DEFINE_SNMP_STAT(struct udp_mib, udp_sta
struct hlist_head udp_hash[UDP_HTABLE_SIZE];
DEFINE_RWLOCK(udp_hash_lock);
+atomic_t udp_memory_allocated;
+int sysctl_udp_mem __read_mostly;
+int sysctl_udp_rmem_min __read_mostly;
+int sysctl_udp_wmem_min __read_mostly;
+
static inline int __udp_lib_lport_inuse(__u16 num,
const struct hlist_head udptable[])
{
@@ -1449,6 +1455,10 @@ struct proto udp_prot = {
.hash = udp_lib_hash,
.unhash = udp_lib_unhash,
.get_port = udp_v4_get_port,
+ .memory_allocated = &udp_memory_allocated,
+ .sysctl_mem = &sysctl_udp_mem,
+ .sysctl_wmem = &sysctl_udp_wmem_min,
+ .sysctl_rmem = &sysctl_udp_rmem_min,
.obj_size = sizeof(struct udp_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_udp_setsockopt,
@@ -1644,6 +1654,23 @@ void udp4_proc_exit(void)
}
#endif /* CONFIG_PROC_FS */
+void __init udp_init(void)
+{
+ unsigned long limit;
+
+ /* Set the pressure threshold up by the same strategy of TCP. It is a
+ * fraction of global memory that is up to 1/2 at 256 MB, decreasing
+ * toward zero with the amount of memory, with a floor of 128 pages.
+ */
+ limit = min(nr_all_pages, 1UL<<(28-PAGE_SHIFT)) >> (20-PAGE_SHIFT);
+ limit = (limit * (nr_all_pages >> (20-PAGE_SHIFT))) >> (PAGE_SHIFT-11);
+ limit = max(limit, 128UL);
+ sysctl_udp_mem = limit / 4 * 3;
+
+ sysctl_udp_rmem_min = SK_DATAGRAM_MEM_QUANTUM;
+ sysctl_udp_wmem_min = SK_DATAGRAM_MEM_QUANTUM;
+}
+
EXPORT_SYMBOL(udp_disconnect);
EXPORT_SYMBOL(udp_hash);
EXPORT_SYMBOL(udp_hash_lock);
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* [PATCH 2/4] [CORE]: datagram: mem_scheudle functions
From: Hideo AOKI @ 2007-12-15 5:15 UTC (permalink / raw)
To: David Miller, Herbert Xu, netdev
Cc: Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, billfink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita, haoki
In-Reply-To: <47636120.4050701@redhat.com>
This patch includes changes in network core sub system for memory
accounting.
Memory scheduling, charging, uncharging and reclaiming functions are
added. These functions use sk_forward_alloc to store socket local
accounting. They also need to use lock to keep consistency of
sk_forward_alloc and memory_allocated. They currently support only
datagram protocols.
sk_datagram_rfree() is a receive buffer detractor for datagram
protocols which are capable of protocol specific memory accounting.
To enable memory accounting in releasing receive buffer,
sock_queue_rcv_skb() is modified although the interface isn't changed.
The body of the function is implemented in
sock_queue_rcv_skb_with_owner(). Additionally, skb_set_owner_r() is
moved to sock.h to core/datagram.c because we want to use it as a
call back function.
Cc: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Takahiro Yasui <tyasui@redhat.com>
signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---
include/net/sock.h | 117 +++++++++++++++++++++++++++++++++++++++++++++++++---
net/core/datagram.c | 72 ++++++++++++++++++++++++++++++++
net/core/sock.c | 13 ++++-
3 files changed, 193 insertions(+), 9 deletions(-)
diff -pruN net-2.6-udp-take10a4-p1/include/net/sock.h net-2.6-udp-take10a4-p2/include/net/sock.h
--- net-2.6-udp-take10a4-p1/include/net/sock.h 2007-12-11 10:54:53.000000000 -0500
+++ net-2.6-udp-take10a4-p2/include/net/sock.h 2007-12-14 20:27:40.000000000 -0500
@@ -750,6 +750,9 @@ static inline struct inode *SOCK_INODE(s
return &container_of(socket, struct socket_alloc, socket)->vfs_inode;
}
+/*
+ * Functions for memory accounting
+ */
extern void __sk_stream_mem_reclaim(struct sock *sk);
extern int sk_stream_mem_schedule(struct sock *sk, int size, int kind);
@@ -778,6 +781,107 @@ static inline int sk_stream_wmem_schedul
sk_stream_mem_schedule(sk, size, 0);
}
+extern void __sk_datagram_mem_reclaim(struct sock *sk);
+extern int sk_stream_mem_schedule(struct sock *sk, int size, int kind);
+
+#define SK_DATAGRAM_MEM_QUANTUM ((unsigned int)PAGE_SIZE)
+
+static inline int sk_datagram_pages(int amt)
+{
+ /* Cast to unsigned as an optimization, since amt is always positive. */
+ return DIV_ROUND_UP((unsigned int)amt, SK_DATAGRAM_MEM_QUANTUM);
+}
+
+extern void __sk_datagram_mem_reclaim(struct sock *sk);
+extern int sk_datagram_mem_schedule(struct sock *sk, int size, int kind);
+
+static inline void sk_datagram_mem_reclaim(struct sock *sk)
+{
+ unsigned long flags;
+
+ if (!sk->sk_prot->memory_allocated)
+ return;
+
+ spin_lock_irqsave(&sk->sk_lock.slock, flags);
+ __sk_datagram_mem_reclaim(sk);
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+}
+
+static inline int sk_datagram_rmem_schedule(struct sock *sk, int size)
+{
+ return size <= sk->sk_forward_alloc ||
+ sk_datagram_mem_schedule(sk, size, 1);
+}
+
+static inline int sk_datagram_wmem_schedule(struct sock *sk, int size)
+{
+ return size <= sk->sk_forward_alloc ||
+ sk_datagram_mem_schedule(sk, size, 0);
+}
+
+static inline void sk_mem_reclaim(struct sock *sk)
+{
+ if (sk->sk_type == SOCK_DGRAM)
+ sk_datagram_mem_reclaim(sk);
+}
+
+static inline int sk_wmem_schedule(struct sock *sk, int size)
+{
+ if (sk->sk_type == SOCK_DGRAM)
+ return sk_datagram_wmem_schedule(sk, size);
+ else
+ return 1;
+}
+
+static inline int sk_account_wmem_charge(struct sock *sk, int size)
+{
+ unsigned long flags;
+
+ /* account if protocol supports memory accounting. */
+ if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+ return 1;
+
+ spin_lock_irqsave(&sk->sk_lock.slock, flags);
+ if (sk_datagram_wmem_schedule(sk, size)) {
+ sk->sk_forward_alloc -= size;
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+ return 1;
+ }
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+ return 0;
+}
+
+static inline int sk_account_rmem_charge(struct sock *sk, int size)
+{
+ unsigned long flags;
+
+ /* account if protocol supports memory accounting. */
+ if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+ return 1;
+
+ spin_lock_irqsave(&sk->sk_lock.slock, flags);
+ if (sk_datagram_rmem_schedule(sk, size)) {
+ sk->sk_forward_alloc -= size;
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+ return 1;
+ }
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+ return 0;
+}
+
+static inline void sk_account_uncharge(struct sock *sk, int size)
+{
+ unsigned long flags;
+
+ /* account if protocol supports memory accounting. */
+ if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+ return;
+
+ spin_lock_irqsave(&sk->sk_lock.slock, flags);
+ sk->sk_forward_alloc += size;
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
+}
+
/* Used by processes to "lock" a socket state, so that
* interrupts and bottom half handlers won't change it
* from under us. It essentially blocks any incoming
@@ -1159,18 +1263,19 @@ static inline void skb_set_owner_w(struc
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
}
-static inline void skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
-{
- skb->sk = sk;
- skb->destructor = sock_rfree;
- atomic_add(skb->truesize, &sk->sk_rmem_alloc);
-}
+extern void skb_set_owner_r(struct sk_buff *skb, struct sock *sk);
+
+void sk_datagram_rfree(struct sk_buff *skb);
extern void sk_reset_timer(struct sock *sk, struct timer_list* timer,
unsigned long expires);
extern void sk_stop_timer(struct sock *sk, struct timer_list* timer);
+extern int sock_queue_rcv_skb_with_owner(struct sock *sk, struct sk_buff *skb,
+ void set_owner_r(struct sk_buff *nskb,
+ struct sock* nsk));
+
extern int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
diff -pruN net-2.6-udp-take10a4-p1/net/core/datagram.c net-2.6-udp-take10a4-p2/net/core/datagram.c
--- net-2.6-udp-take10a4-p1/net/core/datagram.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p2/net/core/datagram.c 2007-12-14 20:26:18.000000000 -0500
@@ -200,6 +200,14 @@ void skb_free_datagram(struct sock *sk,
kfree_skb(skb);
}
+void skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
+{
+ skb->sk = sk;
+ skb->destructor = sock_rfree;
+ atomic_add(skb->truesize, &sk->sk_rmem_alloc);
+}
+EXPORT_SYMBOL(skb_set_owner_r);
+
/**
* skb_kill_datagram - Free a datagram skbuff forcibly
* @sk: socket
@@ -484,6 +492,70 @@ fault:
}
/**
+ * sk_datagram_rfree - receive buffer detractor for datagram protocls
+ * @skb: skbuff
+ */
+void sk_datagram_rfree(struct sk_buff *skb)
+{
+ struct sock *sk = skb->sk;
+
+ skb_truesize_check(skb);
+ atomic_sub(skb->truesize, &sk->sk_rmem_alloc);
+ sk_account_uncharge(sk, skb->truesize);
+ sk_datagram_mem_reclaim(sk);
+}
+EXPORT_SYMBOL(sk_datagram_rfree);
+
+/**
+ * __sk_datagram_mem_reclaim - send buffer for datagram protocls
+ * @sk: socket
+ */
+void __sk_datagram_mem_reclaim(struct sock *sk)
+{
+ if (sk->sk_forward_alloc < SK_DATAGRAM_MEM_QUANTUM)
+ return;
+
+ atomic_sub(sk->sk_forward_alloc / SK_DATAGRAM_MEM_QUANTUM,
+ sk->sk_prot->memory_allocated);
+ sk->sk_forward_alloc &= SK_DATAGRAM_MEM_QUANTUM - 1;
+}
+EXPORT_SYMBOL(__sk_datagram_mem_reclaim);
+
+/**
+ * sk_datagram_mem_schedule - memory accounting for datagram protocls
+ * @sk: socket
+ * @size: memory size to allocate
+ * @kind: allocation type
+ *
+ * If kind is 0, it means wmem allocation. Otherwise it means rmem
+ * allocation.
+ */
+int sk_datagram_mem_schedule(struct sock *sk, int size, int kind)
+{
+ int amt;
+ struct proto *prot = sk->sk_prot;
+
+ /* Don't account and limit memory if protocol doesn't support. */
+ if (!prot->memory_allocated)
+ return 1;
+
+ amt = sk_datagram_pages(size);
+ if (atomic_add_return(amt, prot->memory_allocated) >
+ prot->sysctl_mem[0])
+ if ((kind && atomic_read(&sk->sk_rmem_alloc) + size >=
+ prot->sysctl_rmem[0]) ||
+ (!kind && atomic_read(&sk->sk_wmem_alloc) + size >=
+ prot->sysctl_wmem[0])) {
+ /* Undo changes. */
+ atomic_sub(amt, prot->memory_allocated);
+ return 0;
+ }
+ sk->sk_forward_alloc += amt * SK_DATAGRAM_MEM_QUANTUM;
+ return 1;
+}
+EXPORT_SYMBOL(sk_datagram_mem_schedule);
+
+/**
* datagram_poll - generic datagram poll
* @file: file struct
* @sock: socket
diff -pruN net-2.6-udp-take10a4-p1/net/core/sock.c net-2.6-udp-take10a4-p2/net/core/sock.c
--- net-2.6-udp-take10a4-p1/net/core/sock.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p2/net/core/sock.c 2007-12-14 16:42:06.000000000 -0500
@@ -263,8 +263,9 @@ static void sock_disable_timestamp(struc
}
}
-
-int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+int sock_queue_rcv_skb_with_owner(struct sock *sk, struct sk_buff *skb,
+ void set_owner_r(struct sk_buff *nskb,
+ struct sock* nsk))
{
int err = 0;
int skb_len;
@@ -283,7 +284,7 @@ int sock_queue_rcv_skb(struct sock *sk,
goto out;
skb->dev = NULL;
- skb_set_owner_r(skb, sk);
+ set_owner_r(skb, sk);
/* Cache the SKB length before we tack it onto the receive
* queue. Once it is added it no longer belongs to us and
@@ -299,6 +300,12 @@ int sock_queue_rcv_skb(struct sock *sk,
out:
return err;
}
+EXPORT_SYMBOL(sock_queue_rcv_skb_with_owner);
+
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+{
+ return sock_queue_rcv_skb_with_owner(sk, skb, skb_set_owner_r);
+}
EXPORT_SYMBOL(sock_queue_rcv_skb);
int sk_receive_skb(struct sock *sk, struct sk_buff *skb, const int nested)
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* [PATCH 1/4] [UDP]: fix send buffer check
From: Hideo AOKI @ 2007-12-15 5:14 UTC (permalink / raw)
To: David Miller, Herbert Xu, netdev
Cc: Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, billfink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita, haoki
In-Reply-To: <47636120.4050701@redhat.com>
This patch introduces sndbuf size check before memory allocation for
send buffer.
signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---
ip_output.c | 5 +++++
1 file changed, 5 insertions(+)
diff -pruN net-2.6/net/ipv4/ip_output.c net-2.6-udp-take10a4-p1/net/ipv4/ip_output.c
--- net-2.6/net/ipv4/ip_output.c 2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take10a4-p1/net/ipv4/ip_output.c 2007-12-14 16:42:04.000000000 -0500
@@ -1004,6 +1004,11 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
}
} else if (i < MAX_SKB_FRAGS) {
+ if (atomic_read(&sk->sk_wmem_alloc) + PAGE_SIZE
+ > 2 * sk->sk_sndbuf) {
+ err = -ENOBUFS;
+ goto error;
+ }
if (copy > PAGE_SIZE)
copy = PAGE_SIZE;
page = alloc_pages(sk->sk_allocation, 0);
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* [PATCH 0/4] [UDP]: memory accounting and limitation (take 10)
From: Hideo AOKI @ 2007-12-15 5:07 UTC (permalink / raw)
To: David Miller, Herbert Xu, netdev
Cc: haoki, Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, billfink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita
Hello,
This is the latest patch set of UDP memory accounting and limitation.
To reduce number of atomic access to global variable, the patch set
supports per socket accounting using sk_forward_alloc like stream
protocols.
My colleagues and I tested the patch set on net-2.6 tree.
Please consider applying.
Changelog take 9 -> take 10:
* supported using sk_forward_alloc
* introduced several memory accounting functions with spin lock
* changed detagram receive functions to be able to customize
destructor
* fixed accounting bugs in previous takes
Changelog take 8 -> take 9:
* introduced mem_schdeule functions for datargram protocols
* removed protocol check function, from patch set
* restructured patch set
Changelog take 7 -> take 8:
* sk_datagram_pages(): avoided using divide instruction
* udp_recvmsg(): fixed referring released truesize in accounting
Best regards,
Hideo Aoki
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
From: Bill Fink @ 2007-12-15 4:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeff Garzik, netdev, randy.dunlap, auke-jan.h.kok, linux-kernel
In-Reply-To: <20071214152215.55ef46e8.akpm@linux-foundation.org>
On Fri, 14 Dec 2007, Andrew Morton wrote:
> On Fri, 14 Dec 2007 15:39:26 -0500
> Jeff Garzik <jeff@garzik.org> wrote:
>
> > akpm@linux-foundation.org wrote:
> > > From: Randy Dunlap <randy.dunlap@oracle.com>
> > >
> > > Make E1000E default to the same kconfig setting as E1000. So people's
> > > machiens don't stop working when they use oldconfig.
> > >
> > I am not inclined to apply this one. This practice, applied over time,
> > will tend to accumulate weird 'default' and 'select' statements.
> >
> > So I think the breakage that occurs is mitigated by two factors:
> > 1) kernel hackers that do their own configs are expected to be able to
> > figure this stuff.
> > 2) kernel builders (read: distros, mainly) are expected to have put
> > thought into the Kconfig selection and driver migration strategies.
> >
> > PCI IDs move across drivers from time, and we don't want to apply these
> > sorts changes: Viewed in the long term, the suggested patch is merely a
> > temporary change to allow kernel experts to more easily deal with the
> > PCI ID migration across drivers.
> >
> > I would prefer simply to communicate to kernel experts and builders
> > about a Kconfig issue that could potentially their booting/networking...
> > because this patch is only needed if the kernel experts do not already
> > know about a necessary config update.
>
> You can take it out again later on - most people's .configs will then have
> E1000E set. People who still do `cp ancientconfig .config ; make oldconfig'
> remain screwed.
I was thinking the same thing. Leave it in for 2 or 3 major versions
and then remove it (something analogous to the timeframe for a feature
removal).
And during the interim period, add something like the following
to the Kconfig help text:
Note some hardware that was previously supported by the
e1000 driver is now only handled by the e1000e driver.
If unsure and you previously used the e1000 driver,
say Y or M here.
> I dunno. I guess I'm not into causing people pain in an attempt to train
> them to do what we want. This is a popular driver and a *lot* of people
> are going to:
>
> - build new kernel
>
> - install new kernel
>
> - find it doesn't work, go through quite large amounts of hassle trying
> to work out why it stopped working. Eventually work out that e1000
> stopped working. Eventually work out that it stopped working because we
> forcibly switched them to a new driver which they didn't know about.
>
> - reconfigure kernel
>
> - rebuild, reinstall
Having been there, done that, it's definitely a pain. It's especially
painful when you're doing it remotely, and since the network no longer
works, you can't get into the system anymore.
> Multiply that by 100s of people (at least). All because Jeff wouldn't
> apply a one-liner?
-Bill
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Herbert Xu @ 2007-12-15 4:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev
In-Reply-To: <20071214151136.ae0f969b.akpm@linux-foundation.org>
On Fri, Dec 14, 2007 at 03:11:36PM -0800, Andrew Morton wrote:
>
> I don't believe that ASSERT_RTNL() presently warns when called from atomic
> contexts. If it does then I missed it.
It does when mutex debugging is enabled.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
From: Herbert Xu @ 2007-12-15 4:10 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Krzysztof Oledzki, Jay Vosburgh, Andrew Morton, bugme-daemon,
shemminger, davem, netdev
In-Reply-To: <20071214224722.GA8728@gospo.usersys.redhat.com>
On Fri, Dec 14, 2007 at 05:47:22PM -0500, Andy Gospodarek wrote:
>
> I'm guessing if we go back to using a write-lock for bond->lock this
> will go back to working again, but I'm not totally convinced since there
> are plenty of places where we used a read-lock with it.
Sorry I forgot to cc you earlier Andy.
But to fix this you need make sure that all read locks on bond->lock
in process context disable BH. This is because at least one write
lock can be taken from BH context.
You don't need to turn the read locks into write locks however.
This is also something that we can undo once the set_multicast
interface has been fixed to not take the tx lock.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] [IPV4]: Make tcp_input_metrics() get minimum RTO via tcp_rto_min()
From: Satoru SATOH @ 2007-12-15 2:44 UTC (permalink / raw)
To: netdev
tcp_input_metrics() refers to the built-time constant TCP_RTO_MIN
regardless of configured minimum RTO with iproute2.
The following fixes that.
Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
net/ipv4/tcp_input.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b9e429d..889c893 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -923,7 +923,7 @@ static void tcp_init_metrics(struct sock *sk)
}
if (dst_metric(dst, RTAX_RTTVAR) > tp->mdev) {
tp->mdev = dst_metric(dst, RTAX_RTTVAR);
- tp->mdev_max = tp->rttvar = max(tp->mdev, TCP_RTO_MIN);
+ tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk));
}
tcp_set_rto(sk);
tcp_bound_rto(sk);
^ permalink raw reply related
* Re: Regression: Wireshark sees no packets in 2.6.24-rc3
From: Gabriel C @ 2007-12-15 2:41 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Ray Lee, netdev, LKML
In-Reply-To: <200712150305.02589.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Ray Lee wrote:
>> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
>> fine. A quick scan of the log between 2.6.24-rc3 and current tip
>> (-rc5) doesn't show any obvious fixes, but then again, what do I know.
>> I'll check current tip on the weekend when I'll have the luxury to
>> have my main system down long enough for a test. Right now I'm kinda
>> up against a deadline, but didn't want to leave it unreported. Should
>> be easy for someone else to confirm or deny whether current tip has
>> the problem.
>
> FYI, I have created a bugzilla entry for this issue at:
> http://bugzilla.kernel.org/show_bug.cgi?id=9568
Hmm what do you mean by empty ? it does not capturing anything on that interface ?
I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here.
snip
...
-- sudo tshark -i eth0
Capturing on eth0
1197685732.785920 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1
1197685732.790126 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1
1197685732.793613 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1
1197685732.797656 192.168.0.1 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1
...
1197685738.680962 77.37.20.73 -> 192.168.0.2 TCP 44544 > 44625 [PSH, ACK] Seq=0 Ack=20 Win=88 Len=27 TSV=914082460 TSER=145333592
1197685738.681007 192.168.0.2 -> 77.37.20.73 TCP 44625 > 44544 [ACK] Seq=20 Ack=27 Win=1002 Len=0 TSV=145333645 TSER=914082460
1197685745.994576 192.168.0.2 -> 81.169.185.129 NTP NTP client
1197685746.058523 81.169.185.129 -> 192.168.0.2 NTP NTP server
1197685749.058576 192.168.0.2 -> 85.214.68.60 NTP NTP client
1197685749.121771 85.214.68.60 -> 192.168.0.2 NTP NTP server
1197685751.391157 77.37.20.73 -> 192.168.0.2 TCP 44544 > 44625 [PSH, ACK] Seq=27 Ack=20 Win=88 Len=55 TSV=914085637 TSER=145333645
1197685751.391201 192.168.0.2 -> 77.37.20.73 TCP 44625 > 44544 [ACK] Seq=20 Ack=82 Win=1002 Len=0 TSV=145346355 TSER=914085637
....
-- sudo tshark -i lo
Capturing on lo
1197686288.330222 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [SYN] Seq=0 Len=0 MSS=16396 TSV=145883294 TSER=0 WS=6
1197686288.330225 192.168.0.2 -> 192.168.0.2 TCP http > 53122 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=145883294 TSER=145883294 WS=6
1197686288.330251 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=145883294 TSER=145883294
1197686288.330327 192.168.0.2 -> 192.168.0.2 HTTP GET /.KDE/kdegames-3.97.1_747147.tar.bz2 HTTP/1.0
1197686288.330357 192.168.0.2 -> 192.168.0.2 TCP http > 53122 [ACK] Seq=1 Ack=132 Win=33856 Len=0 TSV=145883294 TSER=145883294
1197686288.474624 192.168.0.2 -> 192.168.0.2 HTTP HTTP/1.1 200 OK (application/x-bzip2)
1197686288.474684 192.168.0.2 -> 192.168.0.2 TCP 53122 > http [ACK] Seq=132 Ack=16385 Win=49344 Len=0 TSV=145883439 TSER=145883439
....
snip
Regards,
Gabriel
^ permalink raw reply
* Re: Regression: Wireshark sees no packets in 2.6.24-rc3
From: Rafael J. Wysocki @ 2007-12-15 2:05 UTC (permalink / raw)
To: Ray Lee; +Cc: netdev, LKML
In-Reply-To: <2c0942db0712131746s7da91f2bkf45b3e1ddf16d1f3@mail.gmail.com>
On Friday, 14 of December 2007, Ray Lee wrote:
> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
> fine. A quick scan of the log between 2.6.24-rc3 and current tip
> (-rc5) doesn't show any obvious fixes, but then again, what do I know.
> I'll check current tip on the weekend when I'll have the luxury to
> have my main system down long enough for a test. Right now I'm kinda
> up against a deadline, but didn't want to leave it unreported. Should
> be easy for someone else to confirm or deny whether current tip has
> the problem.
FYI, I have created a bugzilla entry for this issue at:
http://bugzilla.kernel.org/show_bug.cgi?id=9568
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PS3: gelic: Add wireless support for PS3
From: Jouni Malinen @ 2007-12-15 1:42 UTC (permalink / raw)
To: Dan Williams
Cc: Masakazu Mokuno, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ, Geert Uytterhoeven
In-Reply-To: <1197637127.16724.1.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Fri, Dec 14, 2007 at 07:58:47AM -0500, Dan Williams wrote:
> On Fri, 2007-12-14 at 14:03 +0900, Masakazu Mokuno wrote:
> > The PS3 wireless device does the association and 4way handshake in its
> > firmware/hypervisor. No interventions between them are allowed to the guest
> > OSes.
> That sort of sucks; but I guess there's not too much you can do about
> it. That probably means that using wpa_supplicant + WPA is completely
> out of the picture, which unfortunately makes the PS3 wireless unlike
> any other card, which would require special-casing the PS3 in userspace
> tools.
The current wpa_supplicant development branch (0.6.x) supports drivers
that want to do 4-way handshake in the driver/firmware (e.g., OSX,
iPhone, this PS3 driver). In case of WPA-PSK, this doesn't really mean
more than just passing through the passphrase/PSK to the association
routine, but still, this allows the driver to be configured through
wpa_supplicant, if desired.
However, there is a part that you are not going to like.. This is likely
using a private ioctl for some parts of the association requests, i.e.,
no -Dwext.. I would assume that this could be cleaned up, though, if
WEXT would be extended a bit to allow one more enc_capa to notify
whether the driver wants to take care of 4-way handshake and to allow
the PSK to be configured with a new key type.
PS.
It would be interesting to see whether the driver/firmware/hypervisor
could be convinced to allow EAPOL frames to go through between
association and 4-way handshake (which would be completed by
driver/firmware). This is the way I can support WPA/WPA2-Enterprise with
OSX..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] e1000: Dump the eeprom when a user encounters a bad checksum
From: Joe Perches @ 2007-12-15 1:31 UTC (permalink / raw)
To: Auke Kok; +Cc: jeff, netdev, davem, john.ronciak, jesse.brandeburg
In-Reply-To: <20071214233530.27189.89810.stgit@localhost.localdomain>
On Fri, 2007-12-14 at 15:35 -0800, Auke Kok wrote:
> + printk(KERN_ERR "/*********************/\n");
> + printk(KERN_ERR "Current EEPROM: 0x%04x\nCalculated : 0x%04x\n",
> + csum_old, csum_new);
Multiline printks need a KERN_<level> after every newline. Perhaps:
printk(KERN_ERR "Current EEPROM: 0x%04x\n"
KERN_ERR "Calculated : 0x%04x\n",
csum_old, csum_new);
> + printk(KERN_ERR "Offset Values\n");
> + printk(KERN_ERR "====== ======\n");
> + for (i = 0; i < eeprom.len; i += 16)
> + printk(KERN_ERR "0x%04x "
> + "%02x %02x %02x %02x %02x %02x %02x %02x "
> + "%02x %02x %02x %02x %02x %02x %02x %02x\n",
> + i, data[i], data[i + 1], data[i + 2], data[i + 3],
> + data[i + 4], data[i + 5], data[i + 6], data[i + 7],
> + data[i + 8], data[i + 9], data[i + 10], data[i + 11],
> + data[i + 12], data[i + 13], data[i + 14], data[i + 15]);
print_hex_dump(KERN_ERR, "", DUMP_PREFIX_OFFSET, 16, 1, data,
eeprom.len, true);
> + printk(KERN_ERR "Include this output when contacting your support "
> + "provider.\n\nThis is not a software error! Something bad "
> + "happened to your hardware or\nEEPROM image. Ignoring this "
> + "problem could result in further problems,\npossibly loss "
> + "of data, corruption or system hangs!\n\n");
> + printk(KERN_ERR "The MAC Address will be reset to 00:00:00:00:00:00, "
> + "which is invalid\nand requires you to set the proper MAC "
> + "address manually before continuing\nto enable this network "
> + "device.\n\n");
> + printk(KERN_ERR "Please inspect the EEPROM dump and report the issue "
> + "to your hardware vendor\nor Intel Customer Support: "
> + "linux-nics@intel.com\n");
multiline printks...
cheers, Joe
^ permalink raw reply
* Re: [PATCH] e1000: Dump the eeprom when a user encounters a bad checksum
From: Randy Dunlap @ 2007-12-15 1:08 UTC (permalink / raw)
To: Auke Kok; +Cc: jeff, netdev, davem, john.ronciak, jesse.brandeburg
In-Reply-To: <20071214233530.27189.89810.stgit@localhost.localdomain>
On Fri, 14 Dec 2007 15:35:30 -0800 Auke Kok wrote:
> To help supporting users with a bad eeprom checksum, dump the
> eeprom info when such a situation is encountered by a user.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_main.c | 90 +++++++++++++++++++++++++++++++++++-----
> 1 files changed, 79 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index efd8c2d..2dab1a6 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -817,6 +817,69 @@ e1000_reset(struct e1000_adapter *adapter)
> }
>
> /**
> + * Dump the eeprom for users having checksum issues
> + **/
> +void e1000_dump_eeprom(struct e1000_adapter *adapter)
> +{
> + struct net_device *netdev = adapter->netdev;
> + struct ethtool_eeprom eeprom;
> + const struct ethtool_ops *ops = netdev->ethtool_ops;
> + u8 *data;
> + int i;
> + u16 csum_old, csum_new = 0;
> +
> + eeprom.len = ops->get_eeprom_len(netdev);
> + eeprom.offset = 0;
> +
> + data = kmalloc(eeprom.len, GFP_KERNEL);
> + if (!data) {
> + printk(KERN_ERR "Unable to allocate memory to dump EEPROM"
> + " data\n");
> + return;
> + }
> +
> + ops->get_eeprom(netdev, &eeprom, data);
> +
> + csum_old = (data[EEPROM_CHECKSUM_REG * 2]) +
> + (data[EEPROM_CHECKSUM_REG * 2 + 1] << 8);
> + for (i = 0; i < EEPROM_CHECKSUM_REG * 2; i += 2)
> + csum_new += data[i] + (data[i + 1] << 8);
> + csum_new = EEPROM_SUM - csum_new;
> +
> + printk(KERN_ERR "/*********************/\n");
> + printk(KERN_ERR "Current EEPROM: 0x%04x\nCalculated : 0x%04x\n",
> + csum_old, csum_new);
add the word "checksum" in that line somewhere?
> + printk(KERN_ERR "Offset Values\n");
> + printk(KERN_ERR "====== ======\n");
> + for (i = 0; i < eeprom.len; i += 16)
> + printk(KERN_ERR "0x%04x "
> + "%02x %02x %02x %02x %02x %02x %02x %02x "
> + "%02x %02x %02x %02x %02x %02x %02x %02x\n",
> + i, data[i], data[i + 1], data[i + 2], data[i + 3],
> + data[i + 4], data[i + 5], data[i + 6], data[i + 7],
> + data[i + 8], data[i + 9], data[i + 10], data[i + 11],
> + data[i + 12], data[i + 13], data[i + 14], data[i + 15]);
how about:
for (i = 0; i < eeprom.len; i += 16)
print_hex_dump(KERN_ERR, "data:", DUMP_PREFIX_OFFSET,
16, 1, data + i, 16, 0);
> + printk(KERN_ERR "Include this output when contacting your support "
> + "provider.\n\nThis is not a software error! Something bad "
> + "happened to your hardware or\nEEPROM image. Ignoring this "
> + "problem could result in further problems,\npossibly loss "
> + "of data, corruption or system hangs!\n\n");
> + printk(KERN_ERR "The MAC Address will be reset to 00:00:00:00:00:00, "
> + "which is invalid\nand requires you to set the proper MAC "
> + "address manually before continuing\nto enable this network "
> + "device.\n\n");
> + printk(KERN_ERR "Please inspect the EEPROM dump and report the issue "
> + "to your hardware vendor\nor Intel Customer Support: "
> + "linux-nics@intel.com\n");
> +
> + printk(KERN_ERR "/*********************/\n");
> +
> + kfree(data);
> +}
---
~Randy
^ permalink raw reply
* Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
From: Adrian Bunk @ 2007-12-15 0:02 UTC (permalink / raw)
To: Jeff Garzik
Cc: akpm, netdev, randy.dunlap, auke-jan.h.kok,
Linux Kernel Mailing List
In-Reply-To: <47630F23.5060403@garzik.org>
On Fri, Dec 14, 2007 at 06:17:55PM -0500, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> On Fri, Dec 14, 2007 at 03:39:26PM -0500, Jeff Garzik wrote:
>>> akpm@linux-foundation.org wrote:
>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>> ...
>>> So I think the breakage that occurs is mitigated by two factors:
>>> 1) kernel hackers that do their own configs are expected to be able to
>>> figure this stuff.
>>> 2) kernel builders (read: distros, mainly) are expected to have put
>>> thought into the Kconfig selection and driver migration strategies.
>>> ...
>>> I would prefer simply to communicate to kernel experts and builders about
>>> a Kconfig issue that could potentially their booting/networking...
>>> because this patch is only needed if the kernel experts do not already
>>> know about a necessary config update.
>>
>> You miss the vast majority of kconfig users:
>>
>> 3) system administrators etc. who for different reasons compile their own
>> kernels but neither are nor want to be kernel developers
>>
>> There's a reason why e.g. LPI requires you to be able to compile your own
>> kernel even for getting a "Junior Level Linux Professional" certificate.
>
> Great!
>
>
>> Or that one of the authors of "Linux Device drivers" has written a book
>> covering only how to build and run your own kernel.
>
> Nonetheless, it will always be true that configuring your own kernel
> requires knowledge of the options you are setting.
We are not talking about Aunt Tillie, "system administrator" is the use
case that might cover this (quite diverse) group of users best.
We can expect kconfig users to know what filesystems their data is on
and to have some knowledge of their hardware, but every other knowledge
we must give through kconfig.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
From: Stephen Hemminger @ 2007-12-14 23:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeff Garzik, netdev, randy.dunlap, auke-jan.h.kok, linux-kernel
In-Reply-To: <20071214152215.55ef46e8.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Fri, 14 Dec 2007 15:39:26 -0500
> Jeff Garzik <jeff@garzik.org> wrote:
>
>
>> akpm@linux-foundation.org wrote:
>>
>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>>
>>> Make E1000E default to the same kconfig setting as E1000. So people's
>>> machiens don't stop working when they use oldconfig.
>>>
>>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>>> Cc: Jeff Garzik <jeff@garzik.org>
>>> Cc: Auke Kok <auke-jan.h.kok@intel.com>
>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>> ---
>>>
>>> drivers/net/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff -puN drivers/net/Kconfig~e1000e-make-e1000e-default-to-the-same-kconfig-setting-as-e1000 drivers/net/Kconfig
>>> --- a/drivers/net/Kconfig~e1000e-make-e1000e-default-to-the-same-kconfig-setting-as-e1000
>>> +++ a/drivers/net/Kconfig
>>> @@ -1986,6 +1986,7 @@ config E1000_DISABLE_PACKET_SPLIT
>>> config E1000E
>>> tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
>>> depends on PCI
>>> + default E1000
>>>
>> I am not inclined to apply this one. This practice, applied over time,
>> will tend to accumulate weird 'default' and 'select' statements.
>>
>> So I think the breakage that occurs is mitigated by two factors:
>> 1) kernel hackers that do their own configs are expected to be able to
>> figure this stuff.
>> 2) kernel builders (read: distros, mainly) are expected to have put
>> thought into the Kconfig selection and driver migration strategies.
>>
>> PCI IDs move across drivers from time, and we don't want to apply these
>> sorts changes: Viewed in the long term, the suggested patch is merely a
>> temporary change to allow kernel experts to more easily deal with the
>> PCI ID migration across drivers.
>>
>> I would prefer simply to communicate to kernel experts and builders
>> about a Kconfig issue that could potentially their booting/networking...
>> because this patch is only needed if the kernel experts do not already
>> know about a necessary config update.
>>
>
> You can take it out again later on - most people's .configs will then have
> E1000E set. People who still do `cp ancientconfig .config ; make oldconfig'
> remain screwed.
>
Sounds like something build system should help with. Some more user
friendly syntax for dealing
with issues of driver conversion.
^ 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