* Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
From: Andreas Färber @ 2011-10-22 9:22 UTC (permalink / raw)
To: Andrzej Zaborowski, Peter Maydell; +Cc: qemu-devel
In-Reply-To: <1317637971-19296-1-git-send-email-andreas.faerber@web.de>
Am 03.10.2011 12:32, schrieb Andreas Färber:
> -cpu arm1136-r2 is commented to in fact be ARM1136 r0p2, whereas
> -cpu arm1136 seems to be ARM1136 r1p3 according to the MIDR value.
>
> The CPUID values contain major and minor revision numbers (rnpn) and
> are never used with a mask, so are specific to the chosen revision.
> Rename the CPUID preprocessor defines to reflect this, but leave the
> CPU model names unchanged for command line compatibility.
>
> Cc: Andrzej Zaborowski <andrew@openedhand.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
Ping?
Andreas
> target-arm/cpu.h | 4 ++--
> target-arm/helper.c | 12 ++++++------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 6ab780d..783989f 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -419,8 +419,8 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
> #define ARM_CPUID_PXA270_B1 0x69054113
> #define ARM_CPUID_PXA270_C0 0x69054114
> #define ARM_CPUID_PXA270_C5 0x69054117
> -#define ARM_CPUID_ARM1136 0x4117b363
> -#define ARM_CPUID_ARM1136_R2 0x4107b362
> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
> #define ARM_CPUID_ARM1176 0x410fb767
> #define ARM_CPUID_ARM11MPCORE 0x410fb022
> #define ARM_CPUID_CORTEXA8 0x410fc080
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index e2428eb..0d342ba 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -76,11 +76,11 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> env->cp15.c0_cachetype = 0x1dd20d2;
> env->cp15.c1_sys = 0x00090078;
> break;
> - case ARM_CPUID_ARM1136:
> + case ARM_CPUID_ARM1136_R1P3:
> /* This is the 1136 r1, which is a v6K core */
> set_feature(env, ARM_FEATURE_V6K);
> /* Fall through */
> - case ARM_CPUID_ARM1136_R2:
> + case ARM_CPUID_ARM1136_R0P2:
> /* What qemu calls "arm1136_r2" is actually the 1136 r0p2, ie an
> * older core than plain "arm1136". In particular this does not
> * have the v6K features.
> @@ -417,8 +417,8 @@ static const struct arm_cpu_t arm_cpu_names[] = {
> { ARM_CPUID_ARM926, "arm926"},
> { ARM_CPUID_ARM946, "arm946"},
> { ARM_CPUID_ARM1026, "arm1026"},
> - { ARM_CPUID_ARM1136, "arm1136"},
> - { ARM_CPUID_ARM1136_R2, "arm1136-r2"},
> + { ARM_CPUID_ARM1136_R1P3, "arm1136" },
> + { ARM_CPUID_ARM1136_R0P2, "arm1136-r2" },
> { ARM_CPUID_ARM1176, "arm1176"},
> { ARM_CPUID_ARM11MPCORE, "arm11mpcore"},
> { ARM_CPUID_CORTEXM3, "cortex-m3"},
> @@ -1886,8 +1886,8 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
> switch (ARM_CPUID(env)) {
> case ARM_CPUID_ARM1026:
> return 1;
> - case ARM_CPUID_ARM1136:
> - case ARM_CPUID_ARM1136_R2:
> + case ARM_CPUID_ARM1136_R1P3:
> + case ARM_CPUID_ARM1136_R0P2:
> case ARM_CPUID_ARM1176:
> return 7;
> case ARM_CPUID_ARM11MPCORE:
^ permalink raw reply
* Re: [BUG] bonding : LOCKDEP warning
From: Eric Dumazet @ 2011-10-22 9:19 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, netdev
In-Reply-To: <20111022.050914.551507702374659667.davem@davemloft.net>
Le samedi 22 octobre 2011 à 05:09 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 22 Oct 2011 11:05:49 +0200
>
> > Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Patchwork says "parse error"
>
> I'll fix it up this time, but please do not use free form
> tags like this in the future. Thanks.
Strange, it seems quite usual these days, you're the first one to
complain. Maybe compain to Patchwork ?
Reported-and-tested-by: Shlomo Pongratz <shlomop@mellanox.com>
Reported-and-tested-by: Simon Kirby <sim@hostway.ca>
Reported-and-tested-by: Amir Vadai <amirv@dev.mellanox.co.il>
Reported-and-tested-by: Alexandre Oliva <aoliva@redhat.com>
Reported-and-tested-by: Rocko Requin <rockorequin@hotmail.com>
Reported-and-tested-by: Richard Cochran <richardcochran@gmail.com>
Reported-and-tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reported-and-tested-by: Hor Jiun Shyong <jiunshyong@gmail.com>
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Reported-and-tested-by: Jan Teichmann <jan.teichmann@gmail.com>
Reported-and-tested-by: Arnaud Lacombe <lacombar@gmail.com>
Reported-and-tested-by: Jim Bray <jimsantelmo@gmail.com>
Reported-and-tested-by: Muhammad Khurram Khan
Reported-and-tested-by: Matej Laitl <matej@laitl.cz>
Reported-and-tested-by: Thomas Seilund <tps@netmaster.dk>
Reported-and-tested-by: René Fritz <rene@colorcube.de>
Reported-and-tested-by: Randy Dunlap <rdunlap@xenotime.net>
Reported-and-tested-by: William Light <wrl@illest.net>
Reported-and-tested-by: Xiaotian Feng <xtfeng@gmail.com>
Reported-and-tested-by: Dave Jones <davej@redhat.com>
Reported-and-tested-by: Xiaotian Feng <xtfeng@gmail.com>
Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
Reported-and-tested-by: Pavel Roskin <proski@gnu.org>
Reported-and-tested-by: Christian Casteyde <casteyde.christian@free.fr>
Reported-and-tested-by: Sebastian Siewior <sebastian@breakpoint.cc>
...
^ permalink raw reply
* Congratulations
From: BBC NATIONAL PROMO @ 2011-10-22 5:01 UTC (permalink / raw)
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND,
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,£1.000,000 (one
million pounds) in the British Broadcasting corporation (BBC) Online Promo
Held on this month of 21st October 2011,and you are to acknowledge the
receipt of this mail with the details below to.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Congratulations
From: BBC NATIONAL PROMO @ 2011-10-22 5:01 UTC (permalink / raw)
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND,
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,£1.000,000 (one
million pounds) in the British Broadcasting corporation (BBC) Online Promo
Held on this month of 21st October 2011,and you are to acknowledge the
receipt of this mail with the details below to.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: [BUG] bonding : LOCKDEP warning
From: David Miller @ 2011-10-22 9:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, netdev
In-Reply-To: <1319274349.6180.23.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 22 Oct 2011 11:05:49 +0200
> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Patchwork says "parse error"
I'll fix it up this time, but please do not use free form
tags like this in the future. Thanks.
^ permalink raw reply
* Re: [PATCH] x86-64: Set siginfo and context on vsyscall emulation faults
From: Andy Lutomirski @ 2011-10-22 9:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: x86, Ingo Molnar, richard -rw- weinberger, Adrian Bunk,
H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel
In-Reply-To: <CA+55aFxqG0S+ZS0RHgyFLzgg-c_zu+095OhFresCGAuv8MfQ6A@mail.gmail.com>
On Fri, Oct 21, 2011 at 9:46 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, Oct 22, 2011 at 12:01 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> +static bool write_ok_or_segv(unsigned long ptr, size_t size)
>> +{
>> + if (ptr == 0)
>> + return true;
>
> Why is ptr==0 special? That makes no sense.
>
Pure laziness. Null pointers to the vsyscalls are valid and mean that
userspace doesn't care about the result. I could have put the check
in the caller just as easily.
> Also, this whole function makes the notion of setting the "sigsegv on
> fault" flag much less interesting. It would be much better if
> access_ok() (including the cases embedded in get_user/put_user/etc)
> just did it right automatically for everything, rather than
> special-casing it for just this.
>
Agreed. If I add an option to let userspace opt in to the
signal-sending behavior, I'd want to convince myself that all callers
of access_ok should be affected.
> I wonder if we could just make access_ok() use a trap instead of just
> the regular compares (and then in the trap handler do the same logic
> as in the page fault handler)? Sadly, the 'bounds' instruction doesn't
> work for this (in 32-bit mode it does a *signed* compare, and in
> 64-bit mode it no longer exists), but something like that might.
>
I suspect that bounds is considerably slower than a comparison anyway.
FWIW, there's a different optimization that could make a lot of this
code much nicer: using asm goto for the failure path in get_user, etc.
The failure path is already a branch, and if gcc could be convinced
to generate sensible code for:
if (put_user(...)) goto out;
if (put_user(...)) goto out;
if (put_user(...)) goto out;
if (put_user(...)) goto out;
then the uaccess_err mechanism and a whole lot of bitwise ors could go away.
Sadly, gcc (at least 4.5 and 4.6) has weird limitations on the kind of
constraints allowed on asm goto that, IIRC, make get_user impossible
and put_user a little dicey. (I could have that backwards.)
> That said, I think that your patch looks acceptable as a "let's fix
> vsyscalls without doing the bigger change". But I really don't see why
> ptr==0 would be special.
>
> So I think your write_ok_or_segv() function should just be
>
> static bool write_ok_or_segv(unsigned long ptr, size_t size)
> {
> if (access_ok(ptr, size))
> return true;
>
> .. send signal ...
>
> return false;
> }
>
> instead of that odd thing you have now.
Or a comment to clarify it. Alternatively I could ignore the issue
because access to 0 is okay in the access_ok sense anyway.
--Andy
^ permalink raw reply
* Re: [BUG] bonding : LOCKDEP warning
From: Eric Dumazet @ 2011-10-22 9:05 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller
In-Reply-To: <m14nz1l8mc.fsf@fess.ebiederm.org>
Le samedi 22 octobre 2011 à 01:43 -0700, Eric W. Biederman a écrit :
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
> > On latest net-next I got following splat
>
> Eric it is going to be a little bit before I can test this but I believe
> we just need the one fix in the patch below. Can you verify this fixes
> your lockdep issue.
>
> Thanks,
>
> Eric
>
>
> From 60aeafd8976a1117e118574ada44a79b69c75e70 Mon Sep 17 00:00:00 2001
> From: Eric W. Biederman <ebiederm@xmission.com>
> Date: Sat, 22 Oct 2011 01:36:18 -0700
> Subject: [PATCH] bonding: Add a forgetten sysfs_attr_init on class_attr_bonding_masters
>
> When I made class_attr_bonding_matters per network namespace and dynamically
> allocated I overlooked the need for calling sysfs_attr_init. Oops.
>
> This fixes the following lockdep splat:
>
> [ 5.749651] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> [ 5.749655] bonding: MII link monitoring set to 100 ms
> [ 5.749676] BUG: key f49a831c not in .data!
> [ 5.749677] ------------[ cut here ]------------
> [ 5.749752] WARNING: at kernel/lockdep.c:2897 lockdep_init_map+0x1c3/0x460()
> [ 5.749809] Hardware name: ProLiant BL460c G1
> [ 5.749862] Modules linked in: bonding(+)
> [ 5.749978] Pid: 3177, comm: modprobe Not tainted 3.1.0-rc9-02177-gf2d1a4e-dirty #1157
> [ 5.750066] Call Trace:
> [ 5.750120] [<c1352c2f>] ? printk+0x18/0x21
> [ 5.750176] [<c103112d>] warn_slowpath_common+0x6d/0xa0
> [ 5.750231] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
> [ 5.750287] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
> [ 5.750342] [<c103117d>] warn_slowpath_null+0x1d/0x20
> [ 5.750398] [<c1060133>] lockdep_init_map+0x1c3/0x460
> [ 5.750453] [<c1355ddd>] ? _raw_spin_unlock+0x1d/0x20
> [ 5.750510] [<c11255c8>] ? sysfs_new_dirent+0x68/0x110
> [ 5.750565] [<c1124d4b>] sysfs_add_file_mode+0x8b/0xe0
> [ 5.750621] [<c1124db3>] sysfs_add_file+0x13/0x20
> [ 5.750675] [<c1124e7c>] sysfs_create_file+0x1c/0x20
> [ 5.750737] [<c1208f09>] class_create_file+0x19/0x20
> [ 5.750794] [<c12c186f>] netdev_class_create_file+0xf/0x20
> [ 5.750853] [<f85deaf4>] bond_create_sysfs+0x44/0x90 [bonding]
> [ 5.750911] [<f8410947>] ? bond_create_proc_dir+0x1e/0x3e [bonding]
> [ 5.750970] [<f841007e>] bond_net_init+0x7e/0x87 [bonding]
> [ 5.751026] [<f8410000>] ? 0xf840ffff
> [ 5.751080] [<c12abc7a>] ops_init.clone.4+0xba/0x100
> [ 5.751135] [<c12abdb2>] ? register_pernet_subsys+0x12/0x30
> [ 5.751191] [<c12abd03>] register_pernet_operations.clone.3+0x43/0x80
> [ 5.751249] [<c12abdb9>] register_pernet_subsys+0x19/0x30
> [ 5.751306] [<f84108b9>] bonding_init+0x832/0x8a2 [bonding]
> [ 5.751363] [<c10011f0>] do_one_initcall+0x30/0x160
> [ 5.751420] [<f8410087>] ? bond_net_init+0x87/0x87 [bonding]
> [ 5.751477] [<c106d5cf>] sys_init_module+0xef/0x1890
> [ 5.751533] [<c1356490>] sysenter_do_call+0x12/0x36
> [ 5.751588] ---[ end trace 89f492d83a7f5006 ]---
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
> drivers/net/bonding/bond_sysfs.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> index 6044ff8..5a20804 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -1675,6 +1675,7 @@ int bond_create_sysfs(struct bond_net *bn)
> int ret;
>
> bn->class_attr_bonding_masters = class_attr_bonding_masters;
> + sysfs_attr_init(&bn->class_attr_bonding_masters.attr);
>
> ret = netdev_class_create_file(&bn->class_attr_bonding_masters);
> /*
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks a lot Eric !
^ permalink raw reply
* Re: longjmp question
From: David Miller @ 2011-10-22 9:05 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20111007232209.GA11892@wooyd.org>
From: Jurij Smakov <jurij@wooyd.org>
Date: Sat, 22 Oct 2011 10:00:24 +0100
> Is something conceptually wrong with just doing this:
>
> asm volatile ("save; flush; restore");
>
> It fixes the problem for freebsd (will test on linux later today), and
> does not rely on compiler doing (or not doing) the "right"
> optimization.
I would not do a "naked" save here, please just use the construct
I showed you with the %o7 register clobber.
If you don't allocate space for the new register window, you will
be writing the local registers to the parent's register window.
Maybe you get lucky and this works, but after spending multiple weeks
on this bug why take any chances at all at this point?
^ permalink raw reply
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: David Yang @ 2011-10-22 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALQsFOKjH+k6e6tS4HoNrBvB9BdNYfz3F8P-veZtgk6fyOk-Zw@mail.gmail.com>
hi,all
when I config the Preemptible Kernel .
These is the futext_wake crash every booting.
Best Regards,
David
On 10/22/11, David Yang <david.yangshuai@gmail.com> wrote:
> hi,all
>
> Does anyone know the issue?
>
> Thanks!
>
>
>
> Best Regards,
> David
>
>
> On 10/20/11, David Yang <david.yangshuai@gmail.com> wrote:
>> hi,Afzal
>>
>> It's not zero.
>>
>>
>>
>> Best Regards,
>> Shuai
>>
>> On 10/20/11, Mohammed, Afzal <afzal@ti.com> wrote:
>>> Hi David,
>>>
>>> On Thu, Oct 20, 2011 at 17:32:25, David Yang wrote:
>>>> another log when booting ubuntu10.10:
>>>>
>>>>
>>>> the PC stopped at futex_wake() again!
>>>>
>>>
>>> Please pass "printk.time=1" from commandline, and check the
>>> Kernel logs whether timing shown are zero.
>>>
>>> Regards
>>> Afzal
>>>
>>
>
^ permalink raw reply
* NFS4 client blocked (kernel 3.0.4)
From: David Flynn @ 2011-10-22 8:28 UTC (permalink / raw)
To: linux-nfs
Dear all,
When mounting a solaris NFS4 export on a v3.0.4 client, we've experienced
processes becoming blocked. Any further attempt to access the mountpoint
from another process also blocks. Other mountpoints are unaffected.
I have not identified a test case to reproduce the behaviour.
Any thoughts on the matter would be most welcome,
Kind regards,
..david
from /proc/mounts:
home:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.29.190.20,minorversion=0,local_lock=none,addr=172.29.120.140 0 0
[105121.204200] INFO: task bash:4457 blocked for more than 120 seconds.
[105121.247424] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[105121.299955] bash D ffffffff818050a0 0 4457 1 0x00000000
[105121.347840] ffff8802954b5c28 0000000000000082 ffff8802954b5db8 0000000000012a40
[105121.397793] ffff8802954b5fd8 0000000000012a40 ffff8802954b4000 0000000000012a40
[105121.441724] 0000000000012a40 0000000000012a40 ffff8802954b5fd8 0000000000012a40
[105121.441728] Call Trace:
[105121.441740] [<ffffffff81110030>] ? __lock_page+0x70/0x70
[105121.441744] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
[105121.441746] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
[105121.441749] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
[105121.441751] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
[105121.441756] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
[105121.441759] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
[105121.441761] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
[105121.441786] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
[105121.441789] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
[105121.441791] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
[105121.441793] [<ffffffff8111050b>] filemap_fdatawait+0x2b/0x30
[105121.441795] [<ffffffff81112124>] filemap_write_and_wait+0x44/0x60
[105121.441803] [<ffffffffa0232805>] nfs_getattr+0x105/0x120 [nfs]
[105121.441806] [<ffffffff81605e88>] ? do_page_fault+0x258/0x550
[105121.441810] [<ffffffff81175b31>] vfs_getattr+0x51/0x120
[105121.441812] [<ffffffff81175c70>] vfs_fstatat+0x70/0x90
[105121.441814] [<ffffffff81175ccb>] vfs_stat+0x1b/0x20
[105121.441816] [<ffffffff81175f14>] sys_newstat+0x24/0x40
[105121.441820] [<ffffffff8101449a>] ? init_fpu+0x4a/0x150
[105121.441822] [<ffffffff81602955>] ? page_fault+0x25/0x30
[105121.441825] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
[105121.441837] INFO: task bash:5612 blocked for more than 120 seconds.
[105121.441838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[105121.441840] bash D 0000000000000005 0 5612 1 0x00000000
[105121.441843] ffff8801f25d5ca8 0000000000000086 ffff8800163e9b08 0000000000012a40
[105121.441845] ffff8801f25d5fd8 0000000000012a40 ffff8801f25d4000 0000000000012a40
[105121.441848] 0000000000012a40 0000000000012a40 ffff8801f25d5fd8 0000000000012a40
[105121.441850] Call Trace:
[105121.441853] [<ffffffff81110030>] ? __lock_page+0x70/0x70
[105121.441855] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
[105121.441857] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
[105121.441859] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
[105121.441861] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
[105121.441863] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
[105121.441866] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
[105121.441868] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
[105121.441876] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
[105121.441878] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
[105121.441880] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
[105121.441882] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
[105121.441886] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
[105121.441888] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
[105121.441894] [<ffffffffa022ec74>] nfs_file_flush+0x54/0x80 [nfs]
[105121.441898] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
[105121.441900] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
[105121.441902] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: David Täht @ 2011-10-22 9:01 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David Miller, netdev
In-Reply-To: <CAHo-OoyVSbsxb8U3Y5WCNRsxjr00g1O3HJcT1fmu5cmP5i-JsA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6481 bytes --]
On 10/22/2011 10:27 AM, Maciej Żenczykowski wrote:
>> I also don't see why we'd want to allow disabling this either.
I have been watching this and the other capability patches go by with
interest. My use case is that I would like to be running "named" as a
non-root user, but would like it to vary the dscp (tos) field on a per
connection basis.
tcp zone transfers = bulk
tcp/udp queries = something like interactive | CS5 (this moves dns
queries into the VI queue on wireless - which can also be done with
SO_PRIORITY)
Having TOS modification as a grant-able capability and otherwise
restricting it makes some sense in a world of otherwise unrestricted
user programs in the clouds, however I note that setting CS1, reducing
something from best effort to background, should also be allowed
universally.
I note that another way to hammer down someone elses (guest machine,
external router, etc) TOS settings would be to do it in iptables, but to
do it on a fine grained basis at present would take up to 63 iptables
rules...
lastly...
The skb->priority field needs some re-thought. In the case of wireless,
it selects a different tx queue based on magic (see net/wireless/utils.c)
/* skb->priority values from 256->263 are magic values to
* directly indicate a specific 802.1d priority. This is used
* to allow 802.1d priority to be passed directly in from VLAN
* tags, etc.
*/
if (skb->priority >= 256 && skb->priority <= 263)
return skb->priority - 256;
classification is an aristotelian rathole!
>> I really hate these patches that offer ways to disable things
>> that normally work, and thus break apps when the non-default
>> is selected.
> Well... the purpose of settings like this is precisely to break functionality
> when the default is not set ;-)
>
>> I kind of have a feeling the kind of situation you're trying to
>> account for, you have some cloud where people run random stuff
>> that you don't control.
> Yes, I have control of the kernel, I have control of root, I have control of
> some daemons that are running on the machine, but I don't really have
> control of the entirety of userspace, some of it I have source code for
> and could audit to guarantee correctness (but I can't really enforce
> that on the users, ultimately they can run any binary),
> and for some of it I don't even have that. Either way, it's much
> easier to delegate setting policy to
> userspace management daemon(s), and leave enforcing it to the kernel.
> This is just one more such knob.
>
>> But you didn't specify this, and we just have to guess. Why don't you
>> describe the specific situation where you want to modify this setting?
>> Please do this instead of just talking about what the side effects are
>> inside of the kernel. That's much less interesting when it comes to
>> patches like this.
> Very well, that's a good point.
>
> Here's an attempt to provide some insight.
>
> I am attempting to allow not-fully-code-audited nor fully trusted apps to run
> in a cgroup containerized environment, with many apps in many
> containers (not 1:1, has hierarchies) on a single kernel.
> The apps are in the believed to not be actively malicious class, but
> very likely to be buggy, or written by ill-advised programmers based
> on wrong/outdated or otherwise incorrect documentation. I cannot rely
> on unprivileged userspace getting things right.
> I have to have some mechanism to grant these apps permissions to
> utilize specific levels of network fabric priority. For this I have
> the aforementioned per-cgroup allowed TOS settings. VLANs are not appropriate
> because a client with high priority net privs is allowed to send a
> request to a server with no special priority permissions.
> (there are further patches to support tcp tos reflection so the server
> can automatically respond with the client's priority)
>
> Multiqueue networking combined with hardware priority queues and xps
> desires to use skb->priority + active cpu for tx queue selection.
> In this particular case TX queue selection should happen based on the
> TOS priority.
> Setting TOS automatically sets sk_priority (and hence skb->priority).
> So all's good, so long as userspace doesn't go and change the
> sk_priority field via SO_PRIORITY and break the mapping.
>
> As a further note:
>
> Some of these apps may be a little more special, a little more
> audited, and a little more trusted.
> Enough so that they might be granted CAP_NET_RAW, but not enough so
> that they can get CAP_NET_ADMIN.
> Hence the general desire for CAP_NET_ADMIN to control general
> machine-global networking state, but not have it control
> per-socket or per-packet settings. ie. bringing up or down an
> interface affects everyone (hence must be CAP_NET_ADMIN, and much more
> tightly controlled), while spoofing a packet doesn't really negatively
> affect anyone (you can't assume the network is trusted, so there can
> be
> external sources of spoofing or eavesdropping anyway).
>
> ---
>
> I could attempt to publish the vast majority of our internal
> networking code base (there isn't really anything secret in there),
> but it's based on 2.6.34 and even after two years of attempting to
> clean it up and refactor it (along with a rebase from 2.6.26, and all
> while actively continuing development) I'm still not at the point were
> I would consider this to be a particular useful course of action
> (there's a lot of bugfixes of bugfixes of crappy patches in there,
> plus hacks, plus tons of backports from upstream, and tons of code
> which is upstream but slightly differently then we have it internally,
> because we had it first, and pushed v2 upstream, etc...). Instead I'm
> trying to get the easy hanging fruit out of the way, rebase our
> patches onto probably 3.2 or 3.3, likely sending some more your way
> during the process, and see where that leaves us. Basically trying to
> reduce the delta. We will always have internal only patches, but the
> fewer, the less burden for us, hence I'm trying to get the ones I
> believe to be potentially useful externally upstreamed. Obviously
> whatever patches you don't accept, we'll still keep around locally.
>
> Maciej
> --
> 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
--
Dave Täht
[-- Attachment #2: dave_taht.vcf --]
[-- Type: text/x-vcard, Size: 214 bytes --]
begin:vcard
fn;quoted-printable:Dave T=C3=A4ht
n;quoted-printable:T=C3=A4ht;Dave
email;internet:dave.taht@gmail.com
tel;home:1-239-829-5608
tel;cell:0638645374
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: longjmp question
From: Jurij Smakov @ 2011-10-22 9:00 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20111007232209.GA11892@wooyd.org>
On Tue, Oct 18, 2011 at 04:53:53PM -0400, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Tue, 18 Oct 2011 21:46:20 +0100
>
> > Finally, the "failing" memcpy is also easy to explain now: when we
> > invoke the memcpy, we do it with the correct arguments, but we really
> > do have incorrect memory contents in the source buffer, which end up
> > in the destination. However, as soon as gdb breaks, it flushes *all*
> > register windows of the interrupted process, including the current
> > one, altering the memory contents of the source buffer, and making it
> > appear like memcpy failed to synchronize the source and the
> > destination.
>
> Now this makes a lot of sense, thanks for working to get to the bottom
> of this.
>
> I would suggest fixing this in Ruby by one or two possible methods:
>
> 1) Always do "ta 0x03", this is the simplest but most expensive fix.
It turns out that freebsd/sparc64 is also suffering from this bug,
and, as far as I can tell, there is no equivalent of 'ta 0x03' there.
So, to fix it in a more generic way we probably should push for the
second option.
> 2) Force the "flushw" into a helper function and force GCC to allocate
> a register window by clobbering the return address register, something
> like:
>
> void flushw_helper(void)
> {
> /* Clobber %o7 so that the compiler is forced to allocate
> a register window for this function. */
> __asm__ __volatile__("flushw" : : : "o7");
> }
>
> That results (on 32-bit) in something like:
>
> save %sp, -96, %sp
> flushw
> return %i7 + 8
> nop
>
> which gives us exactly what we need.
Is something conceptually wrong with just doing this:
asm volatile ("save; flush; restore");
It fixes the problem for freebsd (will test on linux later today), and
does not rely on compiler doing (or not doing) the "right"
optimization.
Best regards,
--
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
^ permalink raw reply
* Re: How do I clear the append-only flag on symlinks?
From: Andrew Lutomirski @ 2011-10-22 8:57 UTC (permalink / raw)
To: Ted Ts'o; +Cc: linux-ext4
In-Reply-To: <20111022051644.GD4196@thunk.org>
On Fri, Oct 21, 2011 at 10:16 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Fri, Oct 21, 2011 at 11:07:51AM -0700, Andrew Lutomirski wrote:
>> By means that are best not admitted to, I managed to mark a large
>> chunk of my filesystem append-only, including symlinks. I cleared the
>> flag from all the normal files and directories, but chattr and lsattr
>> don't want to operate on symlinks.
>
> Yes. So how did you set a whole chunk of your file system
> append-only?
I want to be able to write to shared, locked, writable mappings
without sleeping. Updating file timestamps and stable pages get in
the way. I was trying out an approach to fixing the file_update_call
in do_wp_page using a new inode flag. Sadly, I figured out the hard
way that 8196 is not actually a power of two. (My patch is also
garbage for other reasons, but I'll email out a different approach as
an RFC sometime soon.)
If you have any ideas for how to handle stable pages other than
carrying a patch to disable them, I'd love to hear it. The obvious
approach of making a new writable copy of the page will involve
pagecache internals that I'm not at all familiar with.
>
>> Any ideas on how to clear the append-only flags? debug2fs is a little
>> scary, and hacking e2fsprogs to allow operation on symlinks seems to
>> affect symlink targets and not the symlinks themselves.
>
> I'd probably hack it into e2fsck, and let it offer to clear the
> append-only flag on things that aren't regular files, on the theory
> that they should have never been allowed to be set to begin with.
>
I'll take a look on Monday.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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: [v3 PATCH 0/6] Implement byte-range lock caching
From: Pavel Shilovsky @ 2011-10-22 8:56 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111021141412.54bae877-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2011/10/21 Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> On Fri, 7 Oct 2011 23:34:13 +0400
> Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org> wrote:
>
>> This patchset is going to simplify brlocking code and add the caching support for exclusive oplock cases. I splitted it into several independent parts - so, each can be applied separately once it's reviewed.
>>
>> This version of the patchset includes some code style improvements in patch #3.
>>
>> Any comments and testing are welcome!
>>
>> Pavel Shilovsky (6):
>> CIFS: Simplify byte range locking code
>> CIFS: Move byte range lock list from fd to inode
>> CIFS: Implement caching mechanism for mandatory brlocks
>> CIFS: Implement caching mechanism for posix brlocks
>> CIFS: Send as many mandatory unlock ranges at once as possible
>> CIFS: Make cifs_push_locks send as many locks at once as possible
>>
>> fs/cifs/cifsfs.c | 3 +-
>> fs/cifs/cifsglob.h | 10 +-
>> fs/cifs/cifsproto.h | 9 +-
>> fs/cifs/cifssmb.c | 52 +++-
>> fs/cifs/file.c | 767 ++++++++++++++++++++++++++++++++++++++++-----------
>> 5 files changed, 661 insertions(+), 180 deletions(-)
>>
>
> I decided to test this out today. With posix extensions enabled, it
> works fine. When I test with posix extensions disabled though,
> connectathon lock test 7 is hanging after step 7.2.
>
> The regression is fortunately in the portion that hasn't been merged
> yet. Pavel, let me know if you need info on how to test that. I don't
> think we can merge the rest of these until that regression is fixed.
>
Thanks for testing this! The regression is caused by patch #3. It's
big enough but it is the one logical change and should be split, I
think. I caught the bug, solved it and now I am giving it more
testing.
--
Best regards,
Pavel Shilovsky.
^ permalink raw reply
* Re: Advice on build a RAID6
From: Mikael Abrahamsson @ 2011-10-22 8:54 UTC (permalink / raw)
To: Krzysztof Adamski; +Cc: linux-raid
In-Reply-To: <1319231862.3649.19262.camel@oxygen.netxsys.com>
On Fri, 21 Oct 2011, Krzysztof Adamski wrote:
> One requirement is to partition the drives at 99% for the RAID.
Why? What problem are you solving by using partitions?
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: David Yang @ 2011-10-22 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALQsFOKjH+k6e6tS4HoNrBvB9BdNYfz3F8P-veZtgk6fyOk-Zw@mail.gmail.com>
hi,all
when I config the Preemptible Kernel .
These is the futext_wake crash every booting.
Best Regards,
David
On 10/22/11, David Yang <david.yangshuai@gmail.com> wrote:
> hi,all
>
> Does anyone know the issue?
>
> Thanks!
>
>
>
> Best Regards,
> David
>
>
> On 10/20/11, David Yang <david.yangshuai@gmail.com> wrote:
>> hi,Afzal
>>
>> It's not zero.
>>
>>
>>
>> Best Regards,
>> Shuai
>>
>> On 10/20/11, Mohammed, Afzal <afzal@ti.com> wrote:
>>> Hi David,
>>>
>>> On Thu, Oct 20, 2011 at 17:32:25, David Yang wrote:
>>>> another log when booting ubuntu10.10:
>>>>
>>>>
>>>> the PC stopped at futex_wake() again!
>>>>
>>>
>>> Please pass "printk.time=1" from commandline, and check the
>>> Kernel logs whether timing shown are zero.
>>>
>>> Regards
>>> Afzal
>>>
>>
>
^ permalink raw reply
* Re: SCSI HA problems
From: Emmanuel Florac @ 2011-10-22 8:50 UTC (permalink / raw)
To: Michael Robbert; +Cc: linux-scsi@vger.kernel.org
In-Reply-To: <3915A3F8-ECF9-469B-869F-EA4C8421476E@mines.edu>
Le Fri, 21 Oct 2011 18:08:37 -0600 vous écriviez:
>
> So, my question is this, is this setup technically possible or are
> the 2 HBAs going to conflict with each other when talking over the
> same SAS bus to the SATA drives?
Your explanation lacks important information, like the hardware in use
(controllers, jbods, drives, cabling, etc), kernel version, RAID ( is it
linux software RAID you're using?) etc. However:
First, you shouldn't be using desktop drives because it's extremely
dangerous (search the web and you'll find countless horror stories of
catastrophic failures, particularly with WD desktop drives).
Second, normally for SAS HA configuration, you must use SAS drives; the
main difference being that SAS drives have dual attachment, and can
manage commands coming from dual sources (controllers). SATA drives
lack the second path and can't be reliably driven from 2 different
controllers at once, unless you added a SAS to SATA adapter to them.
Third, your SAS controller must be able to work in multi-host
configuration. Most PCIe SAS controllers (3Ware, Adaptec, Areca,
HighPoint) can't do that at all. AFAIK only some LSI controllers are
multi-host aware, and this is a software option you must buy in
addition to the controller.
Fourth, for a dual attachment you need to use both SAS data path to
both hosts, which would quickly make clear you can't use SATA drives
(because they'll simply won't show up at all on the second path).
Fifth, if you're actually using linux md raid driver, I don't think
it to be in any manner multi-host capable. So that would be a
definitive dead end.
My advice : the only reliable way to achieve HA using SATA drives and
common SAS controllers is to use DRDB or some similar replication
mechanism. Yes, that means you'll need a second JBOD and twice the
number of drives. But it will _just_ _work_, both with hardware or
software RAID.
If necessary, you may need a pair of 10 Ge or IB cards for data
synchronisation between hosts to perform well enough. Modern hardware
can easily replicate over DRBD at several hundred MB per second.
Don't forget : "cheap, good, fast: choose two." In the case of large,
important, valuable data, "good" isn't really an option you may go
without anyway.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 0/3] ARM 4Kstacks: introduction
From: Ming Lei @ 2011-10-22 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Tim Bird, Joe Perches, linux kernel, Andi Kleen,
Russell King, Thomas Gleixner
In-Reply-To: <1500345.YeXPhIIHc5@wuerfel>
On Wed, Oct 19, 2011 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 18 October 2011 17:26:44 Tim Bird wrote:
>> Even inside Sony, usage of 4K stacks is limited
>> to some very special cases, where memory is exceedingly
>> tight (we have one system with 4M of RAM). And we
>> don't mind lopping off features or coding around
>> problem areas to support our special case.
>
> I would imagine that in those cases, you can gain more by reducing the
> number of threads in the system. What is the highest number of
> concurrent threads that you expect in a limited use case with no
> networking or block devices?
If system run for some time, sometimes it may be difficult for
memory allocator to allocate 2 continuous page frames even there are
many spare page frames in system because of
fragment issue, so the patch does make sense. Anyway,
it provides one option for user to apply 4k stack to avoid
such kind of process creation failure.
thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH 0/3] ARM 4Kstacks: introduction
From: Ming Lei @ 2011-10-22 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1500345.YeXPhIIHc5@wuerfel>
On Wed, Oct 19, 2011 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 18 October 2011 17:26:44 Tim Bird wrote:
>> Even inside Sony, usage of 4K stacks is limited
>> to some very special cases, where memory is exceedingly
>> tight (we have one system with 4M of RAM). ?And we
>> don't mind lopping off features or coding around
>> problem areas to support our special case.
>
> I would imagine that in those cases, you can gain more by reducing the
> number of threads in the system. What is the highest number of
> concurrent threads that you expect in a limited use case with no
> networking or block devices?
If system run for some time, sometimes it may be difficult for
memory allocator to allocate 2 continuous page frames even there are
many spare page frames in system because of
fragment issue, so the patch does make sense. Anyway,
it provides one option for user to apply 4k stack to avoid
such kind of process creation failure.
thanks,
--
Ming Lei
^ permalink raw reply
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Arend van Spriel @ 2011-10-22 8:44 UTC (permalink / raw)
To: Greg KH
Cc: Nico Schottelius, Eric Dumazet, LKML,
linux-wireless@vger.kernel.org
In-Reply-To: <20111022083005.GA6032@suse.de>
On 10/22/2011 10:30 AM, Greg KH wrote:
> On Sat, Oct 22, 2011 at 01:13:34AM -0700, Arend Van Spriel wrote:
>>> From: Nico Schottelius [mailto:nico-linux-20111017@schottelius.org]
>>> Sent: zaterdag 22 oktober 2011 4:00
>>>
>>> Hey Arend,
>>>
>>> it seems that your patch really solves this problem.
>>
>> Great. This fix is in linux-next tree.
>>
>> Greg,
>>
>> This problem causes packets to get dropped on 5GHz. Should I
>> sent a patch for 3.1 (staging-linus) for this? It is already
>> fixed in wireless-next.
>
> No, just wait for it to get into Linus's tree for 3.2-rc1, and then
> email the git commit id to stable@vger.kernel.org so it will be added to
> the 3.1-stable releases.
>
> greg k-h
>
Thanks, Greg
Saw you email regarding staging-next so I was not sure about
staging-linus. Will be patient ;-)
Gr. AvS
^ permalink raw reply
* [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
From: Albert ARIBAUD @ 2011-10-22 8:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3Bz3-ROogDDvJijac8d9_1bqX5pBp6HXvf_ZWQzWtVeQ@mail.gmail.com>
Le 17/10/2011 18:40, Simon Glass a ?crit :
>> So essentially you are saying: hey, we now have multi-line input,
>> but it works only a bit. It will fail sooner or later, without
>> error messages, and I cannot even tell you what the limits for your
>> system are. And it depends on which input you send.
>>
>> This does not exactly sound promising.
>
> That all sounds reasonable.
>
> I think it is good enough, but not perfect. Due to the fundamental
> design decision you mention at the top, we cannot squirrel away serial
> input in the background. The best we can do is squirrel it away in the
> foreground, as we output new serial data (I suppose we could squirrel
> it away in net loops and other places but I don't want to go there!).
> This turns out to be mostly good enough, because it is rare for people
> to want to paste 'sleep 10' and the like into their terminal (your
> other message).
I think you're not seeing the point that while your patch is good enough
for 'making multiline input less impractical in some cases', it is not
good enough for 'making multiline input reliable': it adds marginal
benefits and we have clear evidence that it will never guarantee a
correct result however you tweak it, because the only way it could would
be by multi-tasking in some way; otherwise, there can always be some
U-Boot activity in between input readings that will be long enough to
cause character loss.
> I would like to spit out a warning when serial input is lost - as I
> mentioned that could be combined with a serial overhaul at some point.
I don't think the warning would make the functionality better.
>> On the other hand, we also have the rule that things that are useful
>> to some and that don't hurt others should be allowed to go in.
>>
>> What makes me hesitate are two things:
>>
>> - The patch promises a feature (multi-line input), but fails to
>> provide a reliably working implementation.
>
> I *think* it does the best possible within the fundamental design
> decision constraint. If there is more it can do, please let me have
> your ideas. I don't believe buffering conflicts with the constraint -
> they are separate things. But yes in systems with interrupts normally
> the input buffer is filled in the background and drained in the
> foreground.
There *is* a much better solution within the fundamental single tasking
design constraint, and it is the one that was invented precisely for
this: flow control. Granted, hardware flow control may be impractical,
and that's why software flow control was conceived as early as 1963 and
is still widely used today and supported by any serial software or
driver worth its salt.
>> - As it turns out, the patch increases code size even for boards that
>> do not activate this feature.
>
> Yes, I will take a look at this problem.
>
>>
>>
>> I have to admit that I'm at a loss with a decision here.
>
> Well it's not easy being a maintainer :-)
Well, FWIW, were I the serial code maintainer, I'd NAK this and ask for
a XON/XOFF implementation.
> In any case this patch is
> not the end of the story as serial needs some work - another objection
> you didn't mention above is that this function lives in only one
> driver. Is that a good thing (hide it away) or a bad thing (all
> drivers should support it and the implementation should move up a
> level)?
Software flow control, whatever way it is implemented, is pure SW and
hardware independent, so it should be a generic thing. If XON/XOFF input
flow control gets implemented (and I believe it should), then it should
be done above hardware serial drivers.
> Regards,
> Simon
Amicalement,
--
Albert.
^ permalink raw reply
* Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Azerty Ytreza @ 2011-10-22 8:43 UTC (permalink / raw)
To: netfilter
Hello,
I have a two littles problem with iptables :
First :
*******
My logs are corrupted. Seem to be corrupted since I have installed LXC
but not 100% sure.
But working while a moment and I doesn't have made big change in my rules.
This an exemple of my logs :
***************************************
Oct 16 09:15:52 Linux kernel: 4234990]it:I=t1OT A=05:ad:d0:02:b7:ed:80
R=8..53 S=11.3.1 E=8TS00 RC00 T=1 D52 FPOOTPST22 P=03 IDW89 E=x0SNUG=
<4>[120376.277507] iptables: IN=eth1 OUT=
MAC=00:50:da:de:3d:02:00:23:eb:78:2e:da:08:00 SRC=182.55.136.87
DST=78.15.238.214 LEN=95 TOS=0x00 PREC=0x00 TTL=116 ID=27543 PROTO=UDP
SPT=443 DPT=50135 LEN=75
Oct 16 10:47:53 Linux kernel: [125896.982195] iptables: IN= OUT=eth1
SRC=78.15.238.214 DST=91.204.81.10 LEN=40 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=TCP SPT=60875 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Oct 16 10:55:06 Linux kernel: [126269.328174] iptables: IN= OUT=eh1
SR=11.3.1 S=1248.0LN4 O=x0PE=x0TL6 D0D RT=C P=36 P=0WNO= E=x0RTUG=
=66.2LN41TS00 RC00 T=4I= FPOOUPST577DT467LN41
Oct 16 11:06:19 Linux kernel: [127003.128125] iptables: IN=eth1 OUT=
MAC=00:50:da:de:3d:02:00:23:eb:78:2e:da:08:00 SRC=193.247.250.19
DST=78.15.238.214LEN=56 O=x0PE=x0TL4 D0D RT=D P=79 P=06 E=6
Oct 16 11:06:19 Linux kernel: [127003.364436] iptables: IN=eth1 OUT=
MAC=00:50:da:de:3d:02:00:23:eb:78:2e:da:08:00 SRC=193.247.250.19
DST=78.15.238.214 LEN=56 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=UDP
SPT=17390 DPT=50368 LEN=36
Oct 16 11:06:20 Linux kernel: [127004.587493] iptables: IN=eth1 OUT=
MAC=00:50:da:de:3d:02:00:23:eb:78:2e:da:08:00 SRC=193.247.250.19
DST=78.15.238.214 LEN=56 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=UDP
SPT=17390 DPT=50368 LEN=36
***************************************
So time of time the logs is 100% correct but a lot of times the log is
totally corrupted and almost unreadable :(
Someone have and idea ?
I load these modules at startup :
***************************************
modprobe iptable_nat
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_tables
modprobe ipt_LOG
modprobe ipt_MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
***************************************
I use Debian Squeeze x86-64 and the kernel version is 2.6.32-5-amd64.
lxc version: 0.7.2
/var/log/message (corrupted)
/var/log/kernel.log (corrupted)
Second :
***********
I use these rules by the past for limit number of connections during
some seconds and block connections if they are too many attempt.
Old rules which work very well :
***************************************
iptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state NEW -m
recent --set
iptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state NEW -m
recent --update --seconds 60 --hitcount 10 -j DROP
#ptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state
NEW,ESTABLISHED -j ACCEPT
***************************************
I have adapted this rules for a FORWARD rules and doesn't work :
***************************************
iptables -A INPUT -i eth1 -p udp -m udp --dport 443 -m state --state
NEW -m recent --set
iptables -A INPUT -i eth1 -p udp -m udp --dport 443 -m recent --update
--seconds 60 --hitcount 10 -j DROP
iptables -A FORWARD -i eth1 -p udp -m udp --dport 443 -m state --state
NEW,ESTABLISHED -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p udp -m udp --dport 443 -j
DNAT --to-destination 192.168.1.2:443
***************************************
Someone can explain me why these rules doesn't block request when
hitcount is reached ?
I have try other method and put "hitcount" on the FORWARD rules
directly but it's not work, I have an error from iptables which
doesn't accept "--set" on a FORWARD request. I doesn't remember error
but it's probably not the good method.
I have made a lot of research, I have found an article with LXC bug
because log are centralized and not separated by container. There is a
little patch for that but it's really that ? Because I have separate
iptables log with a comment and log from my host is corrupted too not
only logs from container :(
Thank you in advance for your help !
Best Regards,
David
^ permalink raw reply
* Re: [BUG] bonding : LOCKDEP warning
From: Eric W. Biederman @ 2011-10-22 8:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller
In-Reply-To: <1319268987.6180.21.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On latest net-next I got following splat
Eric it is going to be a little bit before I can test this but I believe
we just need the one fix in the patch below. Can you verify this fixes
your lockdep issue.
Thanks,
Eric
>From 60aeafd8976a1117e118574ada44a79b69c75e70 Mon Sep 17 00:00:00 2001
From: Eric W. Biederman <ebiederm@xmission.com>
Date: Sat, 22 Oct 2011 01:36:18 -0700
Subject: [PATCH] bonding: Add a forgetten sysfs_attr_init on class_attr_bonding_masters
When I made class_attr_bonding_matters per network namespace and dynamically
allocated I overlooked the need for calling sysfs_attr_init. Oops.
This fixes the following lockdep splat:
[ 5.749651] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 5.749655] bonding: MII link monitoring set to 100 ms
[ 5.749676] BUG: key f49a831c not in .data!
[ 5.749677] ------------[ cut here ]------------
[ 5.749752] WARNING: at kernel/lockdep.c:2897 lockdep_init_map+0x1c3/0x460()
[ 5.749809] Hardware name: ProLiant BL460c G1
[ 5.749862] Modules linked in: bonding(+)
[ 5.749978] Pid: 3177, comm: modprobe Not tainted 3.1.0-rc9-02177-gf2d1a4e-dirty #1157
[ 5.750066] Call Trace:
[ 5.750120] [<c1352c2f>] ? printk+0x18/0x21
[ 5.750176] [<c103112d>] warn_slowpath_common+0x6d/0xa0
[ 5.750231] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
[ 5.750287] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
[ 5.750342] [<c103117d>] warn_slowpath_null+0x1d/0x20
[ 5.750398] [<c1060133>] lockdep_init_map+0x1c3/0x460
[ 5.750453] [<c1355ddd>] ? _raw_spin_unlock+0x1d/0x20
[ 5.750510] [<c11255c8>] ? sysfs_new_dirent+0x68/0x110
[ 5.750565] [<c1124d4b>] sysfs_add_file_mode+0x8b/0xe0
[ 5.750621] [<c1124db3>] sysfs_add_file+0x13/0x20
[ 5.750675] [<c1124e7c>] sysfs_create_file+0x1c/0x20
[ 5.750737] [<c1208f09>] class_create_file+0x19/0x20
[ 5.750794] [<c12c186f>] netdev_class_create_file+0xf/0x20
[ 5.750853] [<f85deaf4>] bond_create_sysfs+0x44/0x90 [bonding]
[ 5.750911] [<f8410947>] ? bond_create_proc_dir+0x1e/0x3e [bonding]
[ 5.750970] [<f841007e>] bond_net_init+0x7e/0x87 [bonding]
[ 5.751026] [<f8410000>] ? 0xf840ffff
[ 5.751080] [<c12abc7a>] ops_init.clone.4+0xba/0x100
[ 5.751135] [<c12abdb2>] ? register_pernet_subsys+0x12/0x30
[ 5.751191] [<c12abd03>] register_pernet_operations.clone.3+0x43/0x80
[ 5.751249] [<c12abdb9>] register_pernet_subsys+0x19/0x30
[ 5.751306] [<f84108b9>] bonding_init+0x832/0x8a2 [bonding]
[ 5.751363] [<c10011f0>] do_one_initcall+0x30/0x160
[ 5.751420] [<f8410087>] ? bond_net_init+0x87/0x87 [bonding]
[ 5.751477] [<c106d5cf>] sys_init_module+0xef/0x1890
[ 5.751533] [<c1356490>] sysenter_do_call+0x12/0x36
[ 5.751588] ---[ end trace 89f492d83a7f5006 ]---
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/net/bonding/bond_sysfs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 6044ff8..5a20804 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1675,6 +1675,7 @@ int bond_create_sysfs(struct bond_net *bn)
int ret;
bn->class_attr_bonding_masters = class_attr_bonding_masters;
+ sysfs_attr_init(&bn->class_attr_bonding_masters.attr);
ret = netdev_class_create_file(&bn->class_attr_bonding_masters);
/*
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next] w5300: add WIZnet W5300 Ethernet driver
From: Taehun Kim @ 2011-10-22 8:41 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, netdev, romieu, suhwan, bongbong
hello, guys.
I have rewritten W5300 driver by applying the Francois Romieu's feedback
(http://marc.info/?l=linux-netdev&m=131714561419786&w=2).
This driver has been tested in the ARM board.
Please review this driver and apply it if do not have any problems.
Thank you.
T.K.
Signed-off-by: Taehun Kim <kth3321@gmail.com>
---
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/wiznet/Kconfig | 32 ++
drivers/net/ethernet/wiznet/Makefile | 5 +
drivers/net/ethernet/wiznet/w5300.c | 706 ++++++++++++++++++++++++++++++++++
drivers/net/ethernet/wiznet/w5300.h | 121 ++++++
6 files changed, 866 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ethernet/wiznet/Kconfig
create mode 100644 drivers/net/ethernet/wiznet/Makefile
create mode 100644 drivers/net/ethernet/wiznet/w5300.c
create mode 100644 drivers/net/ethernet/wiznet/w5300.h
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 6dff5a0..6325d85 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -173,5 +173,6 @@ source "drivers/net/ethernet/tundra/Kconfig"
source "drivers/net/ethernet/via/Kconfig"
source "drivers/net/ethernet/xilinx/Kconfig"
source "drivers/net/ethernet/xircom/Kconfig"
+source "drivers/net/ethernet/wiznet/Kconfig"
endif # ETHERNET
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index c53ad3a..7bd5211 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -72,3 +72,4 @@ obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/
obj-$(CONFIG_NET_VENDOR_VIA) += via/
obj-$(CONFIG_NET_VENDOR_XILINX) += xilinx/
obj-$(CONFIG_NET_VENDOR_XIRCOM) += xircom/
+obj-$(CONFIG_NET_VENDOR_WIZNET) += wiznet/
diff --git a/drivers/net/ethernet/wiznet/Kconfig b/drivers/net/ethernet/wiznet/Kconfig
new file mode 100644
index 0000000..b5925bd
--- /dev/null
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -0,0 +1,32 @@
+#
+# WIZnet device configuration
+#
+
+config NET_VENDOR_WIZNET
+ bool "WIZnet devices"
+ default y
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about WIZnet devices. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if NET_VENDOR_WIZNET
+
+config W5300
+ tristate "WIZnet W5300 Ethernet support"
+ depends on ARM
+ ---help---
+ This driver supports the Ethernet in the WIZnet W5300 chips.
+ W5300 supports hardwired TCP/IP stack. But this driver is limited to
+ the Ethernet function. To use hardwired TCP/IP stack, need to modify
+ the TCP/IP stack in linux kerenl.
+
+ To compile this driver as a module, choose M here: the module
+ will be called w5300.
+
+endif # NET_VENDOR_WIZNET
diff --git a/drivers/net/ethernet/wiznet/Makefile b/drivers/net/ethernet/wiznet/Makefile
new file mode 100644
index 0000000..53120bc
--- /dev/null
+++ b/drivers/net/ethernet/wiznet/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the WIZnet device drivers.
+#
+
+obj-$(CONFIG_W5300) += w5300.o
diff --git a/drivers/net/ethernet/wiznet/w5300.c b/drivers/net/ethernet/wiznet/w5300.c
new file mode 100644
index 0000000..14bbfee
--- /dev/null
+++ b/drivers/net/ethernet/wiznet/w5300.c
@@ -0,0 +1,706 @@
+/* w5300.c: A Linux Ethernet driver for the WIZnet W5300 chip. */
+/*
+ Copyright (C) 2011 Taehun Kim <kth3321@gmail.com>
+
+ This software may be used and distributed according to the terms of
+ the GNU General Public License (GPL), incorporated herein by reference.
+ Drivers based on or derived from this code fall under the GPL and must
+ retain the authorship, copyright and license notice. This file is not
+ a complete program and may only be used when the entire operating
+ system is licensed under the GPL.
+*/
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/errno.h>
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/ioport.h>
+#include <linux/io.h>
+
+#include "w5300.h"
+
+#define DEV_NAME "w5300"
+#define DRV_VERSION "1.0"
+#define DRV_RELDATE "Oct 22, 2011"
+
+#define W5300_DEF_MSG_ENABLE \
+ (NETIF_MSG_DRV | \
+ NETIF_MSG_TIMER | \
+ NETIF_MSG_IFUP | \
+ NETIF_MSG_RX_ERR | \
+ NETIF_MSG_INTR | \
+ NETIF_MSG_TX_DONE)
+
+static const char driver_info[] =
+ KERN_INFO DEV_NAME ": Ethernet driver v" DRV_VERSION "("
+ DRV_RELDATE ")\n";
+
+MODULE_AUTHOR("Taehun Kim <kth3321@gmail.com>");
+MODULE_DESCRIPTION("WIZnet W5300 Ethernet driver");
+MODULE_VERSION(DRV_VERSION);
+MODULE_LICENSE("GPL");
+
+/* Transmit timeout, default 5 seconds. */
+static int watchdog = 5000;
+module_param(watchdog, int, 0400);
+MODULE_PARM_DESC(watchdog, "transmit timeout in milliseconds");
+
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "W5300: bitmapped message enable number");
+
+/*
+ * This is W5300 information structure.
+ * Additional information is included in struct net_device.
+ */
+struct wiz_private {
+ void __iomem *base;
+ struct net_device *dev;
+ u8 rxbuf_conf[MAX_SOCK_NUM];
+ u8 txbuf_conf[MAX_SOCK_NUM];
+ struct net_device_stats stats;
+ struct napi_struct napi;
+ spinlock_t lock;
+ u32 msg_enable;
+};
+
+/* Default MAC address. */
+static __initdata u8 w5300_defmac[6] = {0x00, 0x08, 0xDC, 0xA0, 0x00, 0x01};
+
+/* Default RX/TX buffer size(KByte). */
+static u8 w5300_rxbuf_conf[MAX_SOCK_NUM] __initdata = {
+ 64, 0, 0, 0, 0, 0, 0, 0
+};
+
+static u8 w5300_txbuf_conf[MAX_SOCK_NUM] __initdata = {
+ 64, 0, 0, 0, 0, 0, 0, 0
+};
+
+/* Notifying packet size in the RX FIFO */
+static int w5300_get_rxsize(struct wiz_private *wp, int s)
+{
+ u32 val;
+
+ val = w5300_read(wp, Sn_RX_RSR(s));
+ val = (val << 16) + w5300_read(wp, Sn_RX_RSR(s) + 2);
+ return val;
+}
+
+/* Packet Receive Function. It reads received packet from the Rx FIFO. */
+static void w5300_recv_data(struct wiz_private *wp, int s, u8 *buf,
+ ssize_t len)
+{
+ int i;
+ u16 recv_data;
+
+ /* read from RX FIFO */
+ for (i = 0; i < len; i += 2) {
+ recv_data = w5300_read(wp, Sn_RX_FIFO(s));
+ buf[i] = (u8) ((recv_data & 0xFF00) >> 8);
+ buf[i + 1] = (u8) (recv_data & 0x00FF);
+ }
+}
+
+/* Setting MAC address of W5300 */
+static void w5300_set_macaddr(struct wiz_private *wp, u8 * addr)
+{
+ int i;
+
+ for (i = 0; i < 3; ++i) {
+ u16 mac_addr = (addr[2*i] << 8) | addr[2*i+1];
+
+ w5300_write(wp, SHAR + 2*i, mac_addr);
+ }
+}
+
+/* Opening channels of W5300 */
+static int w5300_channel_open(struct wiz_private *wp, u32 type)
+{
+ int timeout = 1000;
+
+ /* Which type will be used for open? */
+ switch (type) {
+ case Sn_MR_MACRAW:
+ case Sn_MR_MACRAW_MF:
+ w5300_write(wp, Sn_MR(0), type);
+ break;
+ default:
+ netif_err(wp, ifup, wp->dev,
+ "Unknown socket type (%d)\n", type);
+
+ return -EFAULT;
+ }
+
+ w5300_write(wp, Sn_CR(0), Sn_CR_OPEN);
+
+ while (timeout--) {
+ if (!w5300_read(wp, Sn_CR(0)))
+ return 0;
+ udelay(1);
+ }
+
+ return -EBUSY;
+}
+
+/* Activating the interrupt of related channel */
+static void w5300_interrupt_enable(struct wiz_private *wp)
+{
+ u16 mask;
+
+ mask = w5300_read(wp, IMR) | 0x1;
+ w5300_write(wp, IMR, mask);
+}
+
+/* De-activating the interrupt of related channel */
+static void w5300_interrupt_disable(struct wiz_private *wp)
+{
+ u16 mask;
+
+ mask = w5300_read(wp, IMR) & ~0x1;
+ w5300_write(wp, IMR, mask);
+}
+
+/* W5300 initialization function */
+static int w5300_reset(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ u32 txbuf_total = 0, i;
+ u16 mem_cfg = 0;
+ u16 rx_size, tx_size;
+
+ netif_dbg(wp, drv, wp->dev, "w5300 chip reset\n");
+
+ /* W5300 is initialized by sending RESET command. */
+ w5300_write(wp, MR, MR_RST);
+ mdelay(5);
+
+ /* Mode Register Setting
+ * Ping uses S/W stack of the Linux kernel. Set the Ping Block.*/
+ w5300_write(wp, MR, MR_WDF(1) | MR_PB);
+
+ /* Setting MAC address */
+ w5300_set_macaddr(wp, dev->dev_addr);
+
+ /* Setting the size of Rx/Tx FIFO */
+ for (i = 0; i < MAX_SOCK_NUM; ++i) {
+ if (wp->rxbuf_conf[i] > 64) {
+ netif_err(wp, drv, wp->dev,
+ "Illegal Channel(%d) RX memory size.\n", i);
+
+ return -EINVAL;
+ }
+ if (wp->txbuf_conf[i] > 64) {
+ netif_err(wp, drv, wp->dev,
+ "Illegal Channel(%d) TX memory size.\n", i);
+
+ return -EINVAL;
+ }
+ txbuf_total += wp->txbuf_conf[i];
+ }
+
+ if (txbuf_total % 8) {
+ netif_err(wp, drv, wp->dev,
+ "Illegal memory size register setting.\n");
+
+ return -EINVAL;
+ }
+
+ for (i = 0; i < 4; ++i) {
+ rx_size = (wp->rxbuf_conf[2*i] << 8) | wp->rxbuf_conf[2*i+1];
+ tx_size = (wp->txbuf_conf[2*i] << 8) | wp->txbuf_conf[2*i+1];
+
+ w5300_write(wp, RMSR + 2*i, rx_size);
+ w5300_write(wp, TMSR + 2*i, tx_size);
+ }
+
+ /* Setting FIFO Memory Type (TX&RX) */
+ for (i = 0; i < txbuf_total / 8; ++i) {
+ mem_cfg <<= 1;
+ mem_cfg |= 1;
+ }
+ w5300_write(wp, MTYPER, mem_cfg);
+
+ /* Masking all interrupts */
+ w5300_write(wp, IMR, 0x0000);
+
+ return 0;
+}
+
+/* Interrupt Handler(ISR) */
+static irqreturn_t wiz_interrupt(int irq, void *dev_instance)
+{
+ struct net_device *dev = dev_instance;
+ struct wiz_private *wp = netdev_priv(dev);
+ int timeout = 100;
+ u16 isr, ssr;
+ int s;
+
+ isr = w5300_read(wp, IR);
+
+ /* Completing all interrupts at a time. */
+ while (isr && timeout--) {
+ w5300_write(wp, IR, isr);
+
+ /* Finding the channel to create the interrupt */
+ s = find_first_bit((ulong *)&isr, sizeof(u16));
+ ssr = w5300_read(wp, Sn_IR(s));
+ /* socket interrupt is cleared. */
+ w5300_write(wp, Sn_IR(s), ssr);
+
+ netif_dbg(wp, intr, wp->dev,
+ "ISR = %X, SSR = %X, s = %X\n",
+ isr, ssr, s);
+
+ if (likely(!s)) {
+ if (ssr & Sn_IR_RECV) {
+ /* Interrupt disable. */
+ w5300_interrupt_disable(wp);
+ /* Receiving by polling method */
+ napi_schedule(&wp->napi);
+ }
+ }
+
+ /* Is there any interrupt to be processed? */
+ isr = w5300_read(wp, IR);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int wiz_open(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ int ret;
+
+ napi_enable(&wp->napi);
+
+ ret = request_irq(dev->irq, wiz_interrupt, IRQF_SHARED,
+ dev->name, dev);
+ if (ret < 0) {
+ netif_err(wp, ifup, wp->dev, "request_irq() error!\n");
+ return ret;
+ }
+
+ w5300_interrupt_enable(wp);
+
+ /* Sending OPEN command to use channel 0 as MACRAW mode. */
+ ret = w5300_channel_open(wp, Sn_MR_MACRAW_MF);
+ if (ret < 0) {
+ netif_err(wp, ifup, wp->dev, "w5300 channel open fail!\n");
+ return ret;
+ }
+
+ netif_carrier_on(dev);
+ netif_start_queue(dev);
+
+ return 0;
+}
+
+static int wiz_close(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ int timeout = 1000;
+
+ napi_disable(&wp->napi);
+ netif_carrier_off(dev);
+
+ /* Interrupt masking of all channels */
+ w5300_write(wp, IMR, 0x0000);
+ w5300_write(wp, Sn_CR(0), Sn_CR_CLOSE);
+
+ while (timeout--) {
+ if (!w5300_read(wp, Sn_CR(0)))
+ break;
+ udelay(1);
+ }
+
+ free_irq(dev->irq, dev);
+
+ return 0;
+}
+
+static int w5300_send_data(struct wiz_private *wp, u8 *buf, ssize_t len)
+{
+ int i;
+ u16 send_data;
+ int timeout = 1000;
+
+ /* Writing packets in to Tx FIFO */
+ for (i = 0; i < len; i += 2) {
+ send_data = (buf[i] << 8) | buf[i+1];
+ w5300_write(wp, Sn_TX_FIFO(0), send_data);
+ }
+
+ w5300_write(wp, Sn_TX_WRSR(0), (u16)(len >> 16));
+ w5300_write(wp, Sn_TX_WRSR(0) + 2, (u16)len);
+ w5300_write(wp, Sn_CR(0), Sn_CR_SEND);
+
+ while (timeout--) {
+ if (!w5300_read(wp, Sn_CR(0)))
+ return len;
+ udelay(1);
+ }
+
+ return -EBUSY;
+}
+
+/* Function to transmit data at the MACRAW mode */
+static int wiz_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ int ret;
+
+ ret = w5300_send_data(wp, skb->data, skb->len);
+
+ /* Statistical Process */
+ if (ret < 0) {
+ wp->stats.tx_dropped++;
+ } else {
+ wp->stats.tx_bytes += skb->len;
+ wp->stats.tx_packets++;
+ dev->trans_start = jiffies;
+ netif_dbg(wp, tx_done, wp->dev,
+ "tx done, packet size = %d\n", skb->len);
+ }
+ dev_kfree_skb(skb);
+
+ return NETDEV_TX_OK;
+}
+
+static struct net_device_stats *wiz_get_stats(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+
+ return &wp->stats;
+}
+
+/* It is called when multi-cast list or flag is changed. */
+static void wiz_set_multicast(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ int ret;
+ u32 type = dev->flags & IFF_PROMISC ? Sn_MR_MACRAW : Sn_MR_MACRAW_MF;
+
+ ret = w5300_channel_open(wp, type);
+ if (ret < 0) {
+ netif_err(wp, ifup, wp->dev,
+ "w5300 channel open fail!\n");
+ }
+}
+
+static int wiz_set_mac_address(struct net_device *dev, void *addr)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ struct sockaddr *sock_addr = addr;
+
+ netif_dbg(wp, drv, wp->dev, "set mac address");
+
+ spin_lock(&wp->lock);
+ w5300_set_macaddr(wp, sock_addr->sa_data);
+ memcpy(dev->dev_addr, sock_addr->sa_data, dev->addr_len);
+ spin_unlock(&wp->lock);
+
+ return 0;
+}
+
+static void wiz_tx_timeout(struct net_device *dev)
+{
+ struct wiz_private *wp = netdev_priv(dev);
+ unsigned long flags;
+
+ netif_dbg(wp, timer, wp->dev, "Transmit timeout");
+
+ spin_lock_irqsave(&wp->lock, flags);
+
+ /* Initializing W5300 chip. */
+ if (w5300_reset(dev) < 0) {
+ netif_err(wp, timer, wp->dev, "w5300 reset fail!\n");
+ return;
+ }
+
+ /* Waking up network interface */
+ netif_wake_queue(dev);
+ spin_unlock_irqrestore(&wp->lock, flags);
+}
+
+/*
+ * Polling Function to process only receiving at the MACRAW mode.
+ * De-activating the interrupt when recv interrupt occurs,
+ * and processing the RECEIVE with this Function
+ * Activating the interrupt after completing RECEIVE process
+ * As recv interrupt often occurs at short intervals,
+ * there will system load in case that interrupt handler process the RECEIVE.
+ */
+static int wiz_rx_poll(struct napi_struct *napi, int budget)
+{
+ struct wiz_private *wp = container_of(napi, struct wiz_private, napi);
+ struct net_device *dev = wp->dev;
+ int npackets = 0;
+
+ /* Processing the RECEIVE during Rx FIFO is containing any packet */
+ while (w5300_get_rxsize(wp, 0) > 0) {
+ struct sk_buff *skb;
+ u16 rxbuf_len, pktlen;
+ u32 crc;
+
+ /* The first 2byte is the information about packet lenth. */
+ w5300_recv_data(wp, 0, (u8 *)&pktlen, 2);
+ pktlen = be16_to_cpu(pktlen);
+
+ netif_dbg(wp, rx_err, wp->dev, "pktlen = %d\n", pktlen);
+
+ /*
+ * Allotting the socket buffer in which packet will be contained
+ * Ethernet packet is of 14byte.
+ * In order to make it multiplied by 2, the buffer allocation
+ * should be 2bytes bigger than the packet.
+ */
+ skb = netdev_alloc_skb_ip_align(dev, pktlen);
+ if (!skb) {
+ u8 temp[pktlen + 4];
+ wp->stats.rx_dropped++;
+ w5300_recv_data(wp, 0, temp, pktlen + 4);
+ continue;
+ }
+
+ /* Initializing the socket buffer */
+ skb->dev = dev;
+ skb_reserve(skb, 2);
+ skb_put(skb, pktlen);
+
+ /* Reading packets from W5300 Rx FIFO into socket buffer. */
+ w5300_recv_data(wp, 0, (u8 *)skb->data, pktlen);
+
+ /* Reading and discarding 4byte CRC. */
+ w5300_recv_data(wp, 0, (u8 *)&crc, 4);
+ crc = be32_to_cpu(crc);
+
+ /* The packet type is Ethernet. */
+ skb->protocol = eth_type_trans(skb, dev);
+
+ /* Passing packets to uppder stack (kernel). */
+ netif_receive_skb(skb);
+
+ /* Processing statistical information */
+ wp->stats.rx_packets++;
+ wp->stats.rx_bytes += pktlen;
+ wp->dev->last_rx = jiffies;
+ rxbuf_len -= pktlen;
+ npackets++;
+
+ if (npackets >= budget)
+ break;
+ }
+
+ /* If packet number is smaller than budget when getting out of loopback,
+ * the RECEIVE process is completed. */
+ if (npackets < budget) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&wp->lock, flags);
+ w5300_interrupt_enable(wp);
+ __napi_complete(napi);
+ spin_unlock_irqrestore(&wp->lock, flags);
+ }
+ return npackets;
+}
+
+static const struct net_device_ops wiz_netdev_ops = {
+ .ndo_open = wiz_open,
+ .ndo_stop = wiz_close,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = wiz_set_mac_address,
+ .ndo_set_rx_mode = wiz_set_multicast,
+ .ndo_get_stats = wiz_get_stats,
+ .ndo_start_xmit = wiz_start_xmit,
+ .ndo_tx_timeout = wiz_tx_timeout,
+};
+
+/* Initialize W5300 driver. */
+static int __devinit w5300_drv_probe(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct wiz_private *wp;
+ struct resource *res;
+ void __iomem *addr;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ /* Request the chip register regions. */
+ if (!request_mem_region(res->start, resource_size(res), DEV_NAME)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ /* Allocatting struct net_device structure which is managing W5300 */
+ dev = alloc_etherdev(sizeof(struct wiz_private));
+ if (!dev) {
+ ret = -ENOMEM;
+ goto release_region;
+ }
+
+ dev->dma = (unsigned char)-1;
+ dev->irq = platform_get_irq(pdev, 0);
+ wp = netdev_priv(dev);
+ wp->dev = dev;
+ wp->msg_enable = (debug < 0 ? W5300_DEF_MSG_ENABLE : debug);
+ addr = ioremap(res->start, SZ_1M);
+ if (!addr) {
+ ret = -ENOMEM;
+ goto release_both;
+ }
+
+ platform_set_drvdata(pdev, dev);
+ wp->base = addr;
+
+ spin_lock_init(&wp->lock);
+
+ /* Initialization of Rx/Tx FIFO size */
+ memcpy(wp->rxbuf_conf, w5300_rxbuf_conf, MAX_SOCK_NUM);
+ memcpy(wp->txbuf_conf, w5300_txbuf_conf, MAX_SOCK_NUM);
+
+ dev->base_addr = res->start;
+
+ memcpy(dev->dev_addr, w5300_defmac, dev->addr_len);
+ dev->netdev_ops = &wiz_netdev_ops;
+
+ /* Setting napi. Enabling to process max 16 packets at a time. */
+ netif_napi_add(dev, &wp->napi, wiz_rx_poll, 16);
+
+ dev->watchdog_timeo = msecs_to_jiffies(watchdog);
+
+ ret = w5300_reset(dev);
+ if (ret < 0)
+ goto release_both;
+
+ ret = register_netdev(dev);
+ if (ret != 0) {
+ platform_set_drvdata(pdev, NULL);
+ iounmap(addr);
+release_both:
+ free_netdev(dev);
+release_region:
+ release_mem_region(res->start, resource_size(res));
+ }
+out:
+ return ret;
+}
+
+static int __devexit w5300_drv_remove(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct wiz_private *wp = netdev_priv(dev);
+ struct resource *res;
+
+ platform_set_drvdata(pdev, NULL);
+ unregister_netdev(dev);
+
+ iounmap(wp->base);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res != NULL)
+ release_mem_region(res->start, resource_size(res));
+
+ free_netdev(dev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int w5300_drv_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+
+ if (dev) {
+ struct wiz_private *wp = netdev_priv(dev);
+
+ if (netif_running(dev)) {
+ int timeout = 1000;
+
+ netif_carrier_off(dev);
+ netif_device_detach(dev);
+ w5300_write(wp, IMR, 0x0000);
+ w5300_write(wp, Sn_CR(0), Sn_CR_CLOSE);
+
+ while (timeout--) {
+ if (!w5300_read(wp, Sn_CR(0)))
+ return 0;
+ udelay(1);
+ }
+ return -EBUSY;
+ }
+ }
+ return 0;
+}
+
+static int w5300_drv_resume(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ if (dev) {
+ struct wiz_private *wp = netdev_priv(dev);
+
+ if (netif_running(dev)) {
+ ret = w5300_reset(dev);
+ if (ret < 0)
+ goto out;
+
+ w5300_interrupt_enable(wp);
+
+ ret = w5300_channel_open(wp, Sn_MR_MACRAW_MF);
+ if (ret < 0)
+ goto out;
+
+ netif_carrier_on(dev);
+ netif_device_attach(dev);
+ }
+ }
+
+out:
+ return ret;
+}
+#endif /* CONFIG_PM */
+
+static struct platform_driver w5300_driver = {
+ .driver = {
+ .name = DEV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = w5300_drv_probe,
+ .remove = __devexit_p(w5300_drv_remove),
+#ifdef CONFIG_PM
+ .suspend = w5300_drv_suspend,
+ .resume = w5300_drv_resume,
+#endif
+};
+
+static int __init wiz_module_init(void)
+{
+ return platform_driver_register(&w5300_driver);
+}
+
+static void __exit wiz_module_exit(void)
+{
+ platform_driver_unregister(&w5300_driver);
+}
+
+module_init(wiz_module_init);
+module_exit(wiz_module_exit);
diff --git a/drivers/net/ethernet/wiznet/w5300.h b/drivers/net/ethernet/wiznet/w5300.h
new file mode 100644
index 0000000..bb6e181
--- /dev/null
+++ b/drivers/net/ethernet/wiznet/w5300.h
@@ -0,1 +1,121 @@
+#ifndef _W5300_H_
+#define _W5300_H_
+
+/* Maximum socket number. W5300 supports max 8 channels. */
+#define MAX_SOCK_NUM 8
+
+/* socket register */
+#define CH_BASE (0x200)
+
+/* size of each channel register map */
+#define CH_SIZE 0x40
+
+#define MR (0) /**< Mode register */
+#define IR (0x02) /**< Interrupt register */
+#define IMR (0x04) /**< Interrupt mask register */
+#define SHAR (0x08) /**< Source MAC register address */
+#define TMSR (0x20) /**< Transmit memory size register */
+#define RMSR (0x28) /**< Receive memory size register */
+
+/*
+ * Memory Type Register
+ * '1' - TX memory
+ * '0' - RX memory
+ */
+#define MTYPER (0x30)
+
+/* Chip ID register(=0x5300) */
+#define IDR (0xFE)
+#define IDR1 (IDR + 1)
+
+/* socket Mode register */
+#define Sn_MR(ch) (CH_BASE + ch * CH_SIZE + 0x00)
+#define Sn_MR1(ch) (Sn_MR(ch)+1)
+
+/* socket command register */
+#define Sn_CR(ch) (CH_BASE + ch * CH_SIZE + 0x02)
+#define Sn_CR1(ch) (Sn_CR(ch)+1);
+
+/* socket interrupt register */
+#define Sn_IR(ch) (CH_BASE + ch * CH_SIZE + 0x06)
+
+/* Transmit Size Register (Byte count) */
+#define Sn_TX_WRSR(ch) (CH_BASE + ch * CH_SIZE + 0x20)
+
+/* Transmit free memory size register (Byte count) */
+#define Sn_TX_FSR(ch) (CH_BASE + ch * CH_SIZE + 0x24)
+
+/* Received data size register (Byte count) */
+#define Sn_RX_RSR(ch) (CH_BASE + ch * CH_SIZE + 0x28)
+
+/* FIFO register for Transmit */
+#define Sn_TX_FIFO(ch) (CH_BASE + ch * CH_SIZE + 0x2E)
+
+/* FIFO register for Receive */
+#define Sn_RX_FIFO(ch) (CH_BASE + ch * CH_SIZE + 0x30)
+
+/* MODE register values */
+#define MR_DBW (1 << 15) /**< Data bus width bit of MR. */
+#define MR_MPF (1 << 14) /**< Mac layer pause frame bit of MR. */
+#define MR_WDF(x) ((x & 0x07) << 11) /**< Write data fetch time bit of MR. */
+#define MR_RDH (1 << 10) /**< Read data hold time bit of MR. */
+#define MR_FS (1 << 8) /**< FIFO swap bit of MR. */
+#define MR_RST (1 << 7) /**< S/W reset bit of MR. */
+#define MR_MT (1 << 5) /**< Memory test bit of MR. */
+#define MR_PB (1 << 4) /**< Ping block bit of MR. */
+#define MR_PPPoE (1 << 3) /**< PPPoE bit of MR. */
+#define MR_DBS (1 << 2) /**< Data bus swap of MR. */
+#define MR_IND (1 << 0) /**< Indirect mode bit of MR. */
+
+/* IR register values */
+#define IR_IPCF (1 << 7) /**< IP conflict bit of IR. */
+#define IR_DPUR (1 << 6) /**< Destination port unreachable bit of IR. */
+#define IR_PPPT (1 << 5) /**< PPPoE terminate bit of IR. */
+#define IR_FMTU (1 << 4) /**< Fragment MTU bit of IR. */
+#define IR_SnINT(n) (0x01 << n) /**< SOCKETn interrupt occurrence bit of IR. */
+
+/* Sn_MR values */
+#define Sn_MR_ALIGN (1 << 8) /**< Alignment bit of Sn_MR. */
+#define Sn_MR_MULTI (1 << 7) /**< Multicasting bit of Sn_MR. */
+#define Sn_MR_MF (1 << 6) /**< MAC filter bit of Sn_MR. */
+#define Sn_MR_IGMPv (1 << 5) /**< IGMP version bit of Sn_MR. */
+#define Sn_MR_ND (1 << 5) /**< No delayed ack bit of Sn_MR. */
+#define Sn_MR_CLOSE 0x00 /**< Protocol bits of Sn_MR. */
+#define Sn_MR_TCP 0x01 /**< Protocol bits of Sn_MR. */
+#define Sn_MR_UDP 0x02 /**< Protocol bits of Sn_MR. */
+#define Sn_MR_IPRAW 0x03 /**< Protocol bits of Sn_MR. */
+#define Sn_MR_MACRAW 0x04 /**< Protocol bits of Sn_MR. */
+#define Sn_MR_MACRAW_MF 0x44 /**< Protocol bits of Sn_MR */
+#define Sn_MR_PPPoE 0x05 /**< Protocol bits of Sn_MR. */
+
+/* Sn_CR values */
+#define Sn_CR_OPEN 0x01 /**< OPEN command value of Sn_CR. */
+#define Sn_CR_LISTEN 0x02 /**< LISTEN command value of Sn_CR. */
+#define Sn_CR_CONNECT 0x04 /**< CONNECT command value of Sn_CR. */
+#define Sn_CR_DISCON 0x08 /**< DISCONNECT command value of Sn_CR. */
+#define Sn_CR_CLOSE 0x10 /**< CLOSE command value of Sn_CR. */
+#define Sn_CR_SEND 0x20 /**< SEND command value of Sn_CR. */
+#define Sn_CR_SEND_MAC 0x21 /**< SEND_MAC command value of Sn_CR. */
+#define Sn_CR_SEND_KEEP 0x22 /**< SEND_KEEP command value of Sn_CR */
+#define Sn_CR_RECV 0x40 /**< RECV command value of Sn_CR */
+#define Sn_CR_PCON 0x23 /**< PCON command value of Sn_CR */
+#define Sn_CR_PDISCON 0x24 /**< PDISCON command value of Sn_CR */
+#define Sn_CR_PCR 0x25 /**< PCR command value of Sn_CR */
+#define Sn_CR_PCN 0x26 /**< PCN command value of Sn_CR */
+#define Sn_CR_PCJ 0x27 /**< PCJ command value of Sn_CR */
+
+/* Sn_IR values */
+#define Sn_IR_PRECV 0x80 /**< PPP receive bit of Sn_IR */
+#define Sn_IR_PFAIL 0x40 /**< PPP fail bit of Sn_IR */
+#define Sn_IR_PNEXT 0x20 /**< PPP next phase bit of Sn_IR */
+#define Sn_IR_SENDOK 0x10 /**< Send OK bit of Sn_IR */
+#define Sn_IR_TIMEOUT 0x08 /**< Timout bit of Sn_IR */
+#define Sn_IR_RECV 0x04 /**< Receive bit of Sn_IR */
+#define Sn_IR_DISCON 0x02 /**< Disconnect bit of Sn_IR */
+#define Sn_IR_CON 0x01 /**< Connect bit of Sn_IR */
+
+/* W5300 Register READ/WRITE funtions(Just 16 bit interface). */
+#define w5300_write(wp, addr, val) writew(val, (wp->base + addr))
+#define w5300_read(wp, addr) readw((wp->base + addr))
+
+#endif /* _W5300_H_ */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: David Miller @ 2011-10-22 8:40 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev
In-Reply-To: <CAHo-OoyVSbsxb8U3Y5WCNRsxjr00g1O3HJcT1fmu5cmP5i-JsA@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Sat, 22 Oct 2011 01:27:03 -0700
> I am attempting to allow not-fully-code-audited nor fully trusted apps to run
> in a cgroup containerized environment, with many apps in many
> containers (not 1:1, has hierarchies) on a single kernel.
Extend, if necessary, the cgroup classifier so you can use it to clip
off the socket inherited priority in the SKB for this cgroup.
Really, this control has no business in the socket API layer.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.