Re: [PATCH 3/3] param: convert some "on"/"off" users to strtobool
On Thu, Jan 28, 2016 at 06:17:07AM -0800, Kees Cook wrote: > This changes several users of manual "on"/"off" parsing to use strtobool. > > Signed-off-by: Kees Cook <keesc...@chromium.org> > Cc: x...@kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-s...@vger.kernel.org > --- > arch/powerpc/kernel/rtasd.c | 10 +++--- > arch/powerpc/platforms/pseries/hotplug-cpu.c | 11 +++ > arch/s390/kernel/time.c | 8 ++-- > arch/s390/kernel/topology.c | 8 +++- > arch/x86/kernel/aperture_64.c| 13 +++-- > include/linux/tick.h | 2 +- > kernel/time/hrtimer.c| 11 +++ > kernel/time/tick-sched.c | 11 +++ > 8 files changed, 21 insertions(+), 53 deletions(-) For the s390 bits: Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com>
Re: [PATCH] x86: Wire up 32-bit direct socket calls
On Mon, Sep 07, 2015 at 02:53:12PM +0200, Arnd Bergmann wrote: > On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote: > > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > > > Should all other architectures follow suit? > > > Or should we follow the s390 approach: > > > > > > > It is up to the maintainer(s), largely dependent on how likely you are > > going to want to support this in your libc, but in general, socketcall > > is an abomination which there is no reason not to bypass. > > > > So follow suit unless you have a strong reason not to. > > +1 > > In my y2038 syscall series, I'm adding a new recvmmsg64 call, and > we may decide to add new setsockopt/getsockopt variants as well. > This is probably not the last change to socketcall, and it would > be made much easier if all architectures had separate calls here. > > It seems that there are very few architectures that don't already have > the separate calls: > > $ git grep -l __NR_socketcall arch/*/include/uapi | xargs git grep -L > recvmsg > arch/cris/include/uapi/asm/unistd.h > arch/frv/include/uapi/asm/unistd.h > arch/m32r/include/uapi/asm/unistd.h > arch/m68k/include/uapi/asm/unistd.h > arch/mn10300/include/uapi/asm/unistd.h > arch/s390/include/uapi/asm/unistd.h > > These are of course all examples of architectures that originally followed > the i386 syscall scheme closely rather than trying to leave out obsolete > calls. FWIW, the s390 approach (ignoring the "new" system calls) is only temporarily. I'll enable the seperate calls later when I have time to test everything, especially the glibc stuff. The same is true for the ipc system call. (any reason why the seperate system calls haven't been enabled on x86 now as well?) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-git19 - S390x: Kernel panic while bringing up the network interface
On Wed, Oct 24, 2007 at 08:59:06AM +0530, Kamalesh Babulal wrote: Hi, Kernel panic's while bringing up the network interface with the 2.6.23-git19 Setting network parameters: Ý OK ¨ Bringing up loopback interface: Ý OK ¨ Bringing up interface eth0: Ý002e2f72¨ inet_ioctl+0xd6/0x110 Ý0027cae2¨ sock_ioctl+0x26e/0x2a0 Ý000b4c52¨ do_ioctl+0x4a/0xac Ý000b5076¨ vfs_ioctl+0x3c2/0x3d8 Ý000b50ec¨ sys_ioctl+0x60/0x88 Ý00021b7e¨ sysc_noemu+0x10/0x16 Ý021201ca¨ 0x21201ca 0Kernel panic - not syncing: Fatal exception in interrupt 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 01: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 000164DE That should be fixed with this one: commit f1ecfd5d3b69d98b814435758c485e6fd0e112de Author: Ursula Braun [EMAIL PROTECTED] Date: Mon Oct 22 16:16:14 2007 +0200 remove header_ops bug in qeth driver Remove qeth bug caused by commit: [NET]: Move hardware header operations out of netdevice. This is the second part of the qeth header_ops patch, since first patch sent 10/19 has been insufficient. Nevertheless first patch is still valid and should be kept. Signed-off-by: Ursula Braun [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Patch is in -rc1. Could you please pull and try again? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/1] remove header_ops bug in qeth driver
On Fri, Oct 19, 2007 at 11:55:38PM +0200, Ursula Braun wrote: -- Remove qeth driver bug introduced by this commit: commit 3b04ddde02cf1b6f14f2697da5c20eca5715017f Author: Stephen Hemminger [EMAIL PROTECTED] Date: Tue Oct 9 01:40:57 2007 -0700 [NET]: Move hardware header operations out of netdevice. Still broken: Kernel BUG at 0002 [verbose debug info unavailable] illegal operation: 0001 [#1] Modules linked in: CPU:1Not tainted Process ip (pid: 2170, task: 01f1d038, ksp: 02d87b30) Krnl PSW : 070420018000 0002 (0x2) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0038 027c2800 016d6000 86dd 029f8b78 029f8b00 029f8b40 027c2800 02d874c8 016d6000 003cb960 002c58d2 02d874c8 Krnl Code:0002: unknown 0004: unknown 0006: unknown 0008: unknown 000a: unknown 000c: unknown 000e: unknown 0010: unknown Call Trace: ([002c588e] neigh_connected_output+0x76/0x118) [00339e00] ip6_output2+0x22c/0x478 [0033a46c] ip6_output+0x250/0x10fc [0034d65e] __ndisc_send+0x416/0x768 [0034da1c] ndisc_send_rs+0x6c/0x7c [00340776] addrconf_dad_completed+0xb2/0x100 [0034269c] addrconf_dad_start+0xa4/0x134 [0034279e] addrconf_add_linklocal+0x72/0xa4 [003439d4] addrconf_notify+0x6ec/0x8bc [0039905a] notifier_call_chain+0x5e/0xa4 [00062832] __raw_notifier_call_chain+0x26/0x38 [00062872] raw_notifier_call_chain+0x2e/0x40 [002beaa8] call_netdevice_notifiers+0x34/0x48 [002c0288] dev_open+0xd4/0xe0 [002bed42] dev_change_flags+0x14e/0x1c4 [00316cb2] devinet_ioctl+0x5d2/0x724 [0031753c] inet_ioctl+0xf4/0x130 [002ac6fa] sock_ioctl+0x86/0x300 [000c8124] do_ioctl+0x50/0xe0 [000c8440] vfs_ioctl+0x28c/0x3e4 [000c85e8] sys_ioctl+0x50/0x8c [000ff744] dev_ifsioc+0xb8/0x4c8 [000fc15c] compat_sys_ioctl+0x11c/0x444 [000229d0] sysc_noemu+0x10/0x16 [77f3b9ca] 0x77f3b9ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/infiniband/mlx/mad.c misplaced ;
On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote: On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote: Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index 3330917..0ed02b7 100644 --- a/drivers/infiniband/hw/mlx4/mad.c +++ b/drivers/infiniband/hw/mlx4/mad.c @@ -109,7 +109,7 @@ int mlx4_MAD_IFC(struct mlx4_ib_dev *dev, int ignore_mkey, int ignore_bkey, in_modifier, op_modifier, MLX4_CMD_MAD_IFC, MLX4_CMD_TIME_CLASS_C); - if (!err); + if (!err) There's more than a few of these (not inspected). $ egrep -r --include=*.c \bif[[:space:]]*\([^\)]*\)[[:space:]]*\; * [...] drivers/s390/scsi/zfcp_erp.c: if (status == ZFCP_ERP_SUCCEEDED) ; /* no further action */ At least this one is not a bug. But I'm going to add a break there, so it doesn't look that strange anymore. Thanks! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote: Chris Snook [EMAIL PROTECTED] wrote: Because atomic operations are generally used for synchronization, which requires volatile behavior. Most such codepaths currently use an inefficient barrier(). Some forget to and we get bugs, because people assume that atomic_read() actually reads something, and atomic_write() actually writes something. Worse, these are architecture-specific, even compiler version-specific bugs that are often difficult to track down. I'm yet to see a single example from the current tree where this patch series is the correct solution. So far the only example has been a buggy piece of code which has since been fixed with a cpu_relax. Btw.: we still have include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert)); include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert)); Looks like they need to be fixed as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make atomic_t volatile on all architectures
On Thu, Aug 09, 2007 at 03:31:10AM -0400, Chris Snook wrote: Linus Torvalds wrote: I'd be *much* happier with atomic_read() doing the volatile instead. The fact is, volatile on data structures is a bug. It's a wart in the C language. It shouldn't be used. Volatile accesses in *code* can be ok, and if we have atomic_read() expand to a *(volatile int *)(x)-value, then I'd be ok with that. But marking data structures volatile just makes the compiler screw up totally, and makes code for initialization sequences etc much worse. Linus Fair enough. Casting to (volatile int *) will give us the behavior people expect when using atomic_t without needing to use inefficient barriers. While we have the hood up, should we convert all the atomic_t's to non-volatile and put volatile casts in all the atomic_reads? I don't know enough about the various arches to say with confidence that those changes alone will preserve existing behavior. We might need some arch-specific tweaking of the atomic operations. If you write that patch could you include the atomic64 variants as well, please? Besides that just post the patch to linux-arch and maintainers should speak up. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ipvs: force read of atomic_t in while loop
From: Heiko Carstens [EMAIL PROTECTED]
For architectures that don't have a volatile atomic_ts constructs like
while (atomic_read(something)); might result in endless loops since a
barrier() is missing which forces the compiler to generate code that
actually reads memory contents.
Fix this in ipvs by using the IP_VS_WAIT_WHILE macro which resolves to
while (expr) { cpu_relax(); }
(why isn't this open coded btw?)
Cc: Wensong Zhang [EMAIL PROTECTED]
Cc: Simon Horman [EMAIL PROTECTED]
Cc: David Miller [EMAIL PROTECTED]
Cc: Martin Schwidefsky [EMAIL PROTECTED]
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
Just saw this while grepping for atomic_reads in a while loops.
Maybe we should re-add the volatile to atomic_t. Not sure.
net/ipv4/ipvs/ip_vs_ctl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
@@ -909,7 +909,7 @@ ip_vs_edit_dest(struct ip_vs_service *sv
write_lock_bh(__ip_vs_svc_lock);
/* Wait until all other svc users go away */
- while (atomic_read(svc-usecnt) 1) {};
+ IP_VS_WAIT_WHILE(atomic_read(svc-usecnt) 1);
/* call the update_service, because server weight may be changed */
svc-scheduler-update_service(svc);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipvs: force read of atomic_t in while loop
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote: From: Heiko Carstens [EMAIL PROTECTED] Date: Wed, 8 Aug 2007 11:33:00 +0200 Just saw this while grepping for atomic_reads in a while loops. Maybe we should re-add the volatile to atomic_t. Not sure. I think whatever the choice, it should be done consistently on every architecture. It's just asking for trouble if your arch does it differently from every other. Well..currently it's i386/x86_64 and s390 which have no volatile in atomic_t. And yes, of course I agree it should be consistent across all architectures. But it isn't. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipvs: force read of atomic_t in while loop
On Wed, Aug 08, 2007 at 02:31:15PM -0700, Andrew Morton wrote:
On Wed, 08 Aug 2007 17:08:44 -0400
Chris Snook [EMAIL PROTECTED] wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed, 8 Aug 2007 11:33:00 +0200
Just saw this while grepping for atomic_reads in a while loops.
Maybe we should re-add the volatile to atomic_t. Not sure.
I think whatever the choice, it should be done consistently
on every architecture.
It's just asking for trouble if your arch does it differently from
every other.
Well..currently it's i386/x86_64 and s390 which have no volatile
in atomic_t. And yes, of course I agree it should be consistent
across all architectures. But it isn't.
Based on recent discussion, it's pretty clear that there's a lot of
confusion about this. A lot of people (myself included, until I thought
about it long and hard) will reasonably assume that calling
atomic_read() will actually read the value from memory. Leaving out the
volatile declaration seems like a pessimization to me. If you force
people to use barrier() everywhere they're working with atomic_t, it
will force re-reads of all the non-atomic data in use as well, which
will cause more memory fetches of things that generally don't need
barrier(). That and it's a bug waiting to happen.
Andi -- your thoughts on the matter?
I'm not Andi, but this not-Andi thinks that permitting the compiler to cache
the results of atomic_read() is dumb.
Ok, how about this:
Subject: [PATCH] Add 'volatile' to atomic_t again.
From: Heiko Carstens [EMAIL PROTECTED]
This basically reverts f9e9dcb38f5106fa8cdac04a9e967d5487f1cd20 which
removed 'volatile' from atomic_t for i386/x86_64. Reason for this
is to make sure that code like
while (atomic_read(whatever));
continues to work.
Otherwise the compiler might generate code that will loop forever.
Also this makes sure atomic_t is the same across all architectures.
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Martin Schwidefsky [EMAIL PROTECTED]
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
s390 patch will go in via Martin if this is accepted.
include/asm-i386/atomic.h |2 +-
include/asm-x86_64/atomic.h |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/include/asm-i386/atomic.h
===
--- linux-2.6.orig/include/asm-i386/atomic.h
+++ linux-2.6/include/asm-i386/atomic.h
@@ -15,7 +15,7 @@
* on us. We need to use _exactly_ the address the user gave us,
* not some alias that contains the same information.
*/
-typedef struct { int counter; } atomic_t;
+typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
Index: linux-2.6/include/asm-x86_64/atomic.h
===
--- linux-2.6.orig/include/asm-x86_64/atomic.h
+++ linux-2.6/include/asm-x86_64/atomic.h
@@ -22,7 +22,7 @@
* on us. We need to use _exactly_ the address the user gave us,
* not some alias that contains the same information.
*/
-typedef struct { int counter; } atomic_t;
+typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] prevent SSB compilation on s390 part 2
From: Heiko Carstens [EMAIL PROTECTED] drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should prevent SSB from being selected. But appearantly it looks like this doesn't matter at all if it gets selected from somewhere else. So add an explicit depends on HAS_IOMEM to the Broadcom driver to prevent selection on s390. Cc: John W. Linville [EMAIL PROTECTED] Cc: Michael Buesch [EMAIL PROTECTED] Cc: Martin Schwidefsky [EMAIL PROTECTED] Signed-off-by: Heiko Carstens [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertion(+) Index: linux-2.6.22/drivers/net/Kconfig === --- linux-2.6.22.orig/drivers/net/Kconfig +++ linux-2.6.22/drivers/net/Kconfig @@ -1434,6 +1434,7 @@ config APRICOT config B44 tristate Broadcom 440x/47xx ethernet support + depends on HAS_IOMEM select SSB select MII help - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prevent SSB compilation on s390 part 2
On Wed, Aug 01, 2007 at 11:34:04AM +0200, Heiko Carstens wrote: From: Heiko Carstens [EMAIL PROTECTED] drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should prevent SSB from being selected. But appearantly it looks like this doesn't matter at all if it gets selected from somewhere else. So add an explicit depends on HAS_IOMEM to the Broadcom driver to prevent selection on s390. Cc: John W. Linville [EMAIL PROTECTED] Cc: Michael Buesch [EMAIL PROTECTED] Cc: Martin Schwidefsky [EMAIL PROTECTED] Signed-off-by: Heiko Carstens [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertion(+) Index: linux-2.6.22/drivers/net/Kconfig === --- linux-2.6.22.orig/drivers/net/Kconfig +++ linux-2.6.22/drivers/net/Kconfig @@ -1434,6 +1434,7 @@ config APRICOT config B44 tristate Broadcom 440x/47xx ethernet support + depends on HAS_IOMEM select SSB select MII help By the way.. wouldn't something like depends on NET_PCI or something similar more correct for this driver? Just wondering... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [AF_IUCV/IUCV] : Add missing section annotations
On Fri, May 04, 2007 at 12:24:19PM -0700, David Miller wrote: From: Frank Pavlic [EMAIL PROTECTED] Date: Fri, 4 May 2007 11:52:38 +0200 From: Heiko Carstens [EMAIL PROTECTED] Add missing section annotations and found and fixed some Coding Style issues. Signed-off-by: Heiko Carstens [EMAIL PROTECTED] Signed-off-by: Frank Pavlic [EMAIL PROTECTED] Applied, although I find it amusing that the changelog header talks about section annotations (plural!) but that is one line of the patch, whereas %99 of the patch is coding style cleanups. Actually it contained the breathtaking number of 3 section annotations, so that only 95% of the patch is coding style cleanups ;) Apparantly Frank merged two patches and took the one line patch description of the first one. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 0/7] [S390]: Introduction of AF_IUCV sockets support
On Mon, Feb 05, 2007 at 03:00:50PM +0100, Frank Pavlic wrote: Hello, seems that Patch 1/7 is lost and did not make its way to the mailing list :-( That's the reason why I resend the whole patch set again. Here we go ... [...] [1/7] [S390]: Rewrite of the IUCV base code, part 1 Patch 1 has more than 100.000 characters. That's why it didn't reach any list. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] qeth: fix uaccess handling and get rid of unused variable
From: Heiko Carstens [EMAIL PROTECTED]
[patch] qeth: fix uaccess handling and get rid of unused variable
drivers/s390/net/qeth_main.c: In function `qeth_process_inbound_buffer':
drivers/s390/net/qeth_main.c:2563: warning: unused variable `vlan_addr'
include/asm/uaccess.h: In function `qeth_do_ioctl':
drivers/s390/net/qeth_main.c:4847: warning:
ignoring return value of `copy_to_user'
drivers/s390/net/qeth_main.c:4849: warning:
ignoring return value of `copy_to_user'
drivers/s390/net/qeth_main.c:4996: warning:
ignoring return value of `copy_to_user'
Cc: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
drivers/s390/net/qeth_main.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/s390/net/qeth_main.c
===
--- linux-2.6.orig/drivers/s390/net/qeth_main.c
+++ linux-2.6/drivers/s390/net/qeth_main.c
@@ -2560,7 +2560,6 @@ qeth_process_inbound_buffer(struct qeth_
int offset;
int rxrc;
__u16 vlan_tag = 0;
- __u16 *vlan_addr;
/* get first element of current buffer */
element = (struct qdio_buffer_element *)buf-buffer-element[0];
@@ -4844,9 +4843,11 @@ qeth_arp_query(struct qeth_card *card, c
(0x%x/%d)\n,
QETH_CARD_IFNAME(card),
qeth_arp_get_error_cause(rc),
tmp, tmp);
- copy_to_user(udata, qinfo.udata, 4);
+ if (copy_to_user(udata, qinfo.udata, 4))
+ rc = -EFAULT;
} else {
- copy_to_user(udata, qinfo.udata, qinfo.udata_len);
+ if (copy_to_user(udata, qinfo.udata, qinfo.udata_len))
+ rc = -EFAULT;
}
kfree(qinfo.udata);
return rc;
@@ -4992,8 +4993,10 @@ qeth_snmp_command(struct qeth_card *card
if (rc)
PRINT_WARN(SNMP command failed on %s: (0x%x)\n,
QETH_CARD_IFNAME(card), rc);
-else
- copy_to_user(udata, qinfo.udata, qinfo.udata_len);
+ else {
+ if (copy_to_user(udata, qinfo.udata, qinfo.udata_len))
+ rc = -EFAULT;
+ }
kfree(ureq);
kfree(qinfo.udata);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/5] net: fix uaccess handling
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
net/ipv4/raw.c | 17 +++--
net/ipv6/raw.c | 17 +++--
net/netlink/af_netlink.c |5 +++--
3 files changed, 25 insertions(+), 14 deletions(-)
Index: linux-2.6/net/ipv4/raw.c
===
--- linux-2.6.orig/net/ipv4/raw.c 2006-10-26 14:40:56.0 +0200
+++ linux-2.6/net/ipv4/raw.c2006-10-26 14:42:12.0 +0200
@@ -329,7 +329,7 @@
return err;
}
-static void raw_probe_proto_opt(struct flowi *fl, struct msghdr *msg)
+static int raw_probe_proto_opt(struct flowi *fl, struct msghdr *msg)
{
struct iovec *iov;
u8 __user *type = NULL;
@@ -338,7 +338,7 @@
unsigned int i;
if (!msg-msg_iov)
- return;
+ return 0;
for (i = 0; i msg-msg_iovlen; i++) {
iov = msg-msg_iov[i];
@@ -360,8 +360,9 @@
code = iov-iov_base;
if (type code) {
- get_user(fl-fl_icmp_type, type);
- get_user(fl-fl_icmp_code, code);
+ if (get_user(fl-fl_icmp_type, type) ||
+ get_user(fl-fl_icmp_code, code))
+ return -EFAULT;
probed = 1;
}
break;
@@ -372,6 +373,7 @@
if (probed)
break;
}
+ return 0;
}
static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
@@ -480,8 +482,11 @@
.proto = inet-hdrincl ? IPPROTO_RAW :
sk-sk_protocol,
};
- if (!inet-hdrincl)
- raw_probe_proto_opt(fl, msg);
+ if (!inet-hdrincl) {
+ err = raw_probe_proto_opt(fl, msg);
+ if (err)
+ goto done;
+ }
security_sk_classify_flow(sk, fl);
err = ip_route_output_flow(rt, fl, sk,
!(msg-msg_flagsMSG_DONTWAIT));
Index: linux-2.6/net/ipv6/raw.c
===
--- linux-2.6.orig/net/ipv6/raw.c 2006-10-26 14:40:56.0 +0200
+++ linux-2.6/net/ipv6/raw.c2006-10-26 14:42:12.0 +0200
@@ -604,7 +604,7 @@
return err;
}
-static void rawv6_probe_proto_opt(struct flowi *fl, struct msghdr *msg)
+static int rawv6_probe_proto_opt(struct flowi *fl, struct msghdr *msg)
{
struct iovec *iov;
u8 __user *type = NULL;
@@ -616,7 +616,7 @@
int i;
if (!msg-msg_iov)
- return;
+ return 0;
for (i = 0; i msg-msg_iovlen; i++) {
iov = msg-msg_iov[i];
@@ -638,8 +638,9 @@
code = iov-iov_base;
if (type code) {
- get_user(fl-fl_icmp_type, type);
- get_user(fl-fl_icmp_code, code);
+ if (get_user(fl-fl_icmp_type, type) ||
+ get_user(fl-fl_icmp_code, code))
+ return -EFAULT;
probed = 1;
}
break;
@@ -650,7 +651,8 @@
/* check if type field is readable or not. */
if (iov-iov_len 2 - len) {
u8 __user *p = iov-iov_base;
- get_user(fl-fl_mh_type, p[2 - len]);
+ if (get_user(fl-fl_mh_type, p[2 - len]))
+ return -EFAULT;
probed = 1;
} else
len += iov-iov_len;
@@ -664,6 +666,7 @@
if (probed)
break;
}
+ return 0;
}
static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
@@ -787,7 +790,9 @@
opt = ipv6_fixup_options(opt_space, opt);
fl.proto = proto;
- rawv6_probe_proto_opt(fl, msg);
+ err = rawv6_probe_proto_opt(fl, msg);
+ if (err)
+ goto out;
ipv6_addr_copy(fl.fl6_dst, daddr);
if (ipv6_addr_any(fl.fl6_src) !ipv6_addr_any(np-saddr))
Index: linux-2.6/net/netlink/af_netlink.c
===
--- linux-2.6.orig/net/netlink/af_netlink.c 2006-10-26 14:40:56.0
+0200
+++ linux-2.6/net/netlink/af_netlink.c 2006-10-26 14:42:12.0 +0200
@@ -1075,8 +1075,9 @@
return -EINVAL;
len = sizeof(int);
val = nlk-flags
Re: [PATCH 1/7] ehea: interface to network stack
+int __init ehea_module_init(void)
+{
+ int ret = -EINVAL;
+
+ EDEB_EN(7, );
+
+ printk(KERN_INFO IBM eHEA Ethernet Device Driver (Release %s)\n,
+DRV_VERSION);
+
+
+ ret = ibmebus_register_driver(ehea_driver);
+ if (ret) {
+ EDEB_ERR(4, Failed registering eHEA device driver on ebus);
+ return -EINVAL;
+ }
+
+ EDEB_EX(7, );
+ return 0;
+}
Function should be static and could be shortened to the single line
return ibmebus_register_driver(ehea_driver);
, I guess :)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] s390: fix arp_tbl lock usage in qeth
From: Heiko Carstens [EMAIL PROTECTED]
qeth: bhs must be disabled when accessing neighbour tables.
=
[ INFO: inconsistent lock state ]
-
inconsistent {in-softirq-W} - {softirq-on-W} usage.
modprobe/529 [HC0[0]:SC0[0]:HE1:SE1] takes:
(tbl-lock){-+..}, at: [40809384] qeth_init+0x384/0x4c4 [qeth]
{in-softirq-W} state was registered at:
[0005f356] lock_acquire+0x8a/0xb0
[0030ff06] _write_lock+0x52/0x6c
[0024e3ec] neigh_periodic_timer+0xa8/0x254
[00046888] run_timer_softirq+0x1e4/0x278
[0004072c] __do_softirq+0xb4/0x144
[0001f1b0] do_softirq+0xec/0xf0
[00040938] irq_exit+0x90/0xa8
[0001c1c0] do_extint+0x100/0x11c
[0001fbf0] ext_no_vtime+0x1c/0x26
[004df5ba] tcp_init+0x10e/0x3c4
irq event stamp: 15707
hardirqs last enabled at (15707): [0030e080]
__mutex_unlock_slowpath+0x104/0x1b4
hardirqs last disabled at (15706): [0030dfd8]
__mutex_unlock_slowpath+0x5c/0x1b4
softirqs last enabled at (13036): [000407a2] __do_softirq+0x12a/0x144
softirqs last disabled at (13029): [0001f1b0] do_softirq+0xec/0xf0
other info that might help us debug this:
no locks held by modprobe/529.
stack backtrace:
3e38b200 3e38fb30 0002
3e38fbd0 3e38fb48 3e38fb48 00016744
3e38fb30 000c 3e38fb30 3e38fba0
0031e9f8 00016744 3e38fb30 3e38fb80
Call Trace:
([000166d2] show_trace+0x166/0x16c)
[0001679e] show_stack+0xc6/0xf8
[000167fe] dump_stack+0x2e/0x3c
[0005cef2] print_usage_bug+0x26e/0x280
[0005dc50] mark_lock+0x620/0x6c4
[0005eb8c] __lock_acquire+0x750/0xe90
[0005f356] lock_acquire+0x8a/0xb0
[0030ff06] _write_lock+0x52/0x6c
[40809384] qeth_init+0x384/0x4c4 [qeth]
[00069fe2] sys_init_module+0xd6/0x2c8
[0001f4a4] sysc_noemu+0x10/0x16
[0210dc9e] 0x210dc9e
Cc: Arjan van de Ven [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
drivers/s390/net/qeth_main.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/net/qeth_main.c b/drivers/s390/net/qeth_main.c
index 5fff1f9..e1327b8 100644
--- a/drivers/s390/net/qeth_main.c
+++ b/drivers/s390/net/qeth_main.c
@@ -8510,9 +8510,9 @@ static int
qeth_ipv6_init(void)
{
qeth_old_arp_constructor = arp_tbl.constructor;
- write_lock(arp_tbl.lock);
+ write_lock_bh(arp_tbl.lock);
arp_tbl.constructor = qeth_arp_constructor;
- write_unlock(arp_tbl.lock);
+ write_unlock_bh(arp_tbl.lock);
arp_direct_ops = (struct neigh_ops*)
kmalloc(sizeof(struct neigh_ops), GFP_KERNEL);
@@ -8528,9 +8528,9 @@ qeth_ipv6_init(void)
static void
qeth_ipv6_uninit(void)
{
- write_lock(arp_tbl.lock);
+ write_lock_bh(arp_tbl.lock);
arp_tbl.constructor = qeth_old_arp_constructor;
- write_unlock(arp_tbl.lock);
+ write_unlock_bh(arp_tbl.lock);
kfree(arp_direct_ops);
}
#endif /* CONFIG_QETH_IPV6 */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: fix lock usage in udp_ioctl
On Thu, Jun 15, 2006 at 08:28:07AM +0200, Ingo Molnar wrote:
* Herbert Xu [EMAIL PROTECTED] wrote:
This is bogus. These two locks belong to two different queues and
they never intersect.
yeah - qeth does its own skb-queue management here, and it's done in an
irq-safe manner.
Heiko, in qeth_main.c, could you do something like:
+ static struct lockdep_type_key qdio_out_skb_queue_key;
...
skb_queue_head_init(card-qdio.out_qs[i]-bufs[j].
skb_list);
+ lockdep_reinit_key(card-qdio.out_qs[i]-bufs[j].skb_list,
qdio_out_skb_queue_key)
How about the patch below? The warning goes away and I assume tmp_list needs
lockdep_reinit_key too, since it should have the same locking rules as the
rest of qeth's skb-queue management.
From: Heiko Carstens [EMAIL PROTECTED]
Avoid false positive illegal lock usage message in qeth driver.
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
drivers/s390/net/qeth_main.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/s390/net/qeth_main.c 2006-06-15 08:46:26.0 +0200
+++ b/drivers/s390/net/qeth_main.c 2006-06-15 08:29:58.0 +0200
@@ -85,6 +85,8 @@ static debug_info_t *qeth_dbf_qerr = NUL
DEFINE_PER_CPU(char[256], qeth_dbf_txt_buf);
+static struct lockdep_type_key qdio_out_skb_queue_key;
+
/**
* some more definitions and declarations
*/
@@ -3230,6 +3232,9 @@ qeth_alloc_qdio_buffers(struct qeth_card
card-qdio.out_qs[i]-qdio_bufs[j];
skb_queue_head_init(card-qdio.out_qs[i]-bufs[j].
skb_list);
+ lockdep_reinit_key(
+ card-qdio.out_qs[i]-bufs[j].skb_list.lock,
+ qdio_out_skb_queue_key);
INIT_LIST_HEAD(card-qdio.out_qs[i]-bufs[j].ctx_list);
}
}
@@ -5273,6 +5278,7 @@ qeth_free_vlan_buffer(struct qeth_card *
struct sk_buff_head tmp_list;
skb_queue_head_init(tmp_list);
+ lockdep_reinit_key(tmp_list.lock, qdio_out_skb_queue_key);
for(i = 0; i QETH_MAX_BUFFER_ELEMENTS(card); ++i){
while ((skb = skb_dequeue(buf-skb_list))){
if (vlan_tx_tag_present(skb)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ipv4: fix lock usage in udp_ioctl
From: Heiko Carstens [EMAIL PROTECTED]
Fix lock usage in udp_ioctl().
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
udp_poll() seems to have the same problem, right?
As reported by the lock validator:
[ BUG: illegal lock usage! ]
illegal {in-hardirq-W} - {hardirq-on-W} usage.
syslogd/739 [HC0[0]:SC0[1]:HE1:SE0] takes:
(list-lock){++..}, at: [002e36d6] udp_ioctl+0x96/0x100
{in-hardirq-W} state was registered at:
[00062128] lock_acquire+0x9c/0xc0
[0036209e] _spin_lock_irqsave+0x66/0x84
[002912ce] skb_dequeue+0x32/0xb0
[00263160] qeth_qdio_output_handler+0x3e8/0xf8c
[00219fdc] tiqdio_thinint_handler+0xde0/0x2234
[0020448c] do_adapter_IO+0x5c/0xa8
[0020842c] do_IRQ+0x13c/0x18c
[000208a2] io_no_vtime+0x16/0x1c
[0001978c] cpu_idle+0x1d0/0x20c
irq event stamp: 1694
hardirqs last enabled at (1693): [003629c2] _spin_unlock_irqrestore+0x92/0xa8
hardirqs last disabled at (1692): [00362074] _spin_lock_irqsave+0x3c/0x84
softirqs last enabled at (1682): [0028c7c4] release_sock+0xe4/0xf4
softirqs last disabled at (1694): [00361f7e] _spin_lock_bh+0x2e/0x70
other info that might help us debug this:
no locks held by syslogd/739.
stack backtrace:
0fd6c148 0de2f960 0002
0de2fa00 0de2f978 0de2f978 0001737c
0de2f960 000c 0de2f960 0de2f9d0
0036fe70 0001737c 0de2f960 0de2f9b0
Call Trace:
([0001730a] show_trace+0x166/0x16c)
[000173d6] show_stack+0xc6/0xf8
[00017436] dump_stack+0x2e/0x3c
[0005f978] print_usage_bug+0x23c/0x250
[000607cc] mark_lock+0x594/0x714
[000613be] __lock_acquire+0x252/0xf20
[00062128] lock_acquire+0x9c/0xc0
[00361fa8] _spin_lock_bh+0x58/0x70
[002e36d6] udp_ioctl+0x96/0x100
[002eadd6] inet_ioctl+0x72/0x11c
[002893f2] sock_ioctl+0x1ca/0x2c0
[000c13ee] do_ioctl+0x56/0xe0
[000c14f2] vfs_ioctl+0x7a/0x384
[000c184e] sys_ioctl+0x52/0x84
[000e80a2] do_ioctl32_pointer+0x2a/0x3c
[000e55c8] compat_sys_ioctl+0x168/0x378
[00020338] sysc_noemu+0x10/0x16
diffstat:
net/ipv4/udp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 3f93292..b15a17b 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -740,7 +740,7 @@ int udp_ioctl(struct sock *sk, int cmd,
unsigned long amount;
amount = 0;
- spin_lock_bh(sk-sk_receive_queue.lock);
+ spin_lock_irq(sk-sk_receive_queue.lock);
skb = skb_peek(sk-sk_receive_queue);
if (skb != NULL) {
/*
@@ -750,7 +750,7 @@ int udp_ioctl(struct sock *sk, int cmd,
*/
amount = skb-len - sizeof(struct udphdr);
}
- spin_unlock_bh(sk-sk_receive_queue.lock);
+ spin_unlock_irq(sk-sk_receive_queue.lock);
return put_user(amount, (int __user *)arg);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
Tried to figure out what is causing the delays I experienced when I replaced module_init() in af_inet.c with fs_initcall(). After all it turned out that synchronize_net() which is basicically nothing else than synchronize_rcu() sometimes takes several seconds to complete?! No idea why that is... callchain: inet_init() - inet_register_protosw() - synchronize_net() The problem can't be rcu_init(), that gets done very early in init/main.c Maybe it's some timer or something else specific to s390? It could also be that there's perhaps nothing to context switch to, thus the RCU takes forever to happen. Yes, it's more or less s390 specific. What happens is the following: synchronize_rcu() enqueues an RCU callback on cpu 0. Later on cpu 0 handles a bunch of RCU batches, but without handling this specific request (it's in rdp-curlist). Since this cpu has nothing else to do it enters cpu_idle() (it's a nohz idle, therefore it might be quite a long time in idle state). While cpu 0 is in idle state cpu 2 calls cpu_quiet() which in turn will call rcu_start_batch(). If cpu 0 would run now, it would notice rdp-curlist moved to rdp-donelist and that there is something to do. Unfortunately it doesn't get notified from rcu_start_batch(). That's why I ended up waiting several seconds until finally some interrupt arrived at cpu 0 which made things go on finally. Avoiding this could be done if we look at rdp-curlist before going into a nohz idle wait, or we could send an interprocessor interrupt to idle cpus. Sending an interrupt while looking only on nohz_cpu_mask seems to be a bit racy, since other cpus might have entered cpu idle after nohz_cpu_mask has been read... At least the initcall change for inet_init() can go in, since it just revealed a problem that we have anyway. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ipv4: inet_init() - fs_initcall
From: Heiko Carstens [EMAIL PROTECTED] Convert inet_init to an fs_initcall to make sure its called before any device driver's initcall. Signed-off-by: Heiko Carstens [EMAIL PROTECTED] --- net/ipv4/af_inet.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index dc206f1..0a27745 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -1257,7 +1257,7 @@ out_unregister_udp_proto: goto out; } -module_init(inet_init); +fs_initcall(inet_init); /* */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
As spinlock debugging still does not work with the qeth driver I want to pick up the discussion. Does something like the patch below work? But this all begs the question, what happens if you want to dig into the internals of a protocol which is built modular and hasn't been loaded yet? diff --git a/include/linux/init.h b/include/linux/init.h index 93dcbe1..8169f25 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -95,8 +95,9 @@ #define postcore_initcall(fn) __define_ #define arch_initcall(fn)__define_initcall(3,fn) #define subsys_initcall(fn) __define_initcall(4,fn) #define fs_initcall(fn) __define_initcall(5,fn) -#define device_initcall(fn) __define_initcall(6,fn) -#define late_initcall(fn)__define_initcall(7,fn) +#define net_initcall(fn) __define_initcall(6,fn) +#define device_initcall(fn) __define_initcall(7,fn) +#define late_initcall(fn)__define_initcall(8,fn) #define __initcall(fn) device_initcall(fn) diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index dc206f1..9803a57 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -1257,7 +1257,7 @@ out_unregister_udp_proto: goto out; } -module_init(inet_init); +net_initcall(inet_init); That's exactly the same thing that I tried to. It didn't work for me since I saw sometimes the described rcu_update latencies. Today I was able to boot the machine 30 times and just saw it once... Not very helpful for debugging this :( Btw.: I guess the linker scripts need an update too, so that the new .initcall8.init section doesn't get discarded. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
Ok, so the problem seems to be that inet_init gets called after qeth_init. Looking at the top level Makefile this seems to be true for all network drivers in drivers/net/ and drivers/s390/net/ since we have vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) The patch below works for me... I guess there must be a better way to make sure that any networking driver's initcall is made before inet_init? Signed-off-by: Heiko Carstens [EMAIL PROTECTED] We could make inet_init() a subsystem init but I vaguely recall that we were doing that at one point and it broke things for some reason. Perhaps fs_initcall() would work better. Or if that causes problems we could create a net_initcall() that sits between fs_initcall() and device_initcall(). Or any other ideas? Tried to figure out what is causing the delays I experienced when I replaced module_init() in af_inet.c with fs_initcall(). After all it turned out that synchronize_net() which is basicically nothing else than synchronize_rcu() sometimes takes several seconds to complete?! No idea why that is... callchain: inet_init() - inet_register_protosw() - synchronize_net() - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
callchain: inet_init() - inet_register_protosw() - synchronize_net() The problem can't be rcu_init(), that gets done very early in init/main.c Maybe it's some timer or something else specific to s390? It could also be that there's perhaps nothing to context switch to, thus the RCU takes forever to happen. Changing inet_init to fs_initcall() moves it way up the chain... There are quite a few __initcall()s (way is this mapped to device_initcall()?) and module_init()s in places where I would never have expected them (e.g. kernel/). After all the dependencies are anything but obvious to me. The only obvious solution which fixes my problem would be to convert qeth's module_init() to late_initcall(). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK detects that this lock is not initialized as it is supposed to be. This is a initialization order problem then, because: arp_init neigh_table_init rwlock_init does the initialization already. So fix the initialization sequence of the qeth driver or you will have other problems. My impression was the -rt folks wanted all lock initializations t be done at runtime not compile time. Ok, so the problem seems to be that inet_init gets called after qeth_init. Looking at the top level Makefile this seems to be true for all network drivers in drivers/net/ and drivers/s390/net/ since we have vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) The patch below works for me... I guess there must be a better way to make sure that any networking driver's initcall is made before inet_init? Signed-off-by: Heiko Carstens [EMAIL PROTECTED] --- Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index b401942..c5cea07 100644 --- a/Makefile +++ b/Makefile @@ -567,7 +567,7 @@ # # System.map is generated to document addresses of all kernel symbols vmlinux-init := $(head-y) $(init-y) -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) +vmlinux-main := $(core-y) $(libs-y) $(net-y) $(drivers-y) vmlinux-all := $(vmlinux-init) $(vmlinux-main) vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
We could make inet_init() a subsystem init but I vaguely recall that we were doing that at one point and it broke things for some reason. Perhaps fs_initcall() would work better. Or if that causes problems we could create a net_initcall() that sits between fs_initcall() and device_initcall(). Or any other ideas? Just tried fs_initcall() and net_initcall(). Both seem to have some side effects: Symptom is that console output sometimes hangs for several seconds at: NET: Registered protocol family 2 while all cpus are in cpu_idle(). Heiko - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens [EMAIL PROTECTED]
The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK
detects that this lock is not initialized as it is supposed to be.
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
---
net/ipv4/arp.c |1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 041dadd..ea54216 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -202,6 +202,7 @@ struct neigh_table arp_tbl = {
.gc_thresh1 = 128,
.gc_thresh2 = 512,
.gc_thresh3 = 1024,
+ .lock = RW_LOCK_UNLOCKED,
};
int arp_mc_map(u32 addr, u8 *haddr, struct net_device *dev, int dir)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] s390: Remove CVS generated information.
From: Heiko Carstens [EMAIL PROTECTED] - Remove all CVS generated information like e.g. revision IDs from drivers/s390 and include/asm-s390 (none present in arch/s390). - Add newline at end of arch/s390/lib/Makefile to avoid diff message. Acked-by: Andreas Herrmann [EMAIL PROTECTED] Acked-by: Frank Pavlic [EMAIL PROTECTED] Signed-off-by: Heiko Carstens [EMAIL PROTECTED] --- arch/s390/lib/Makefile |2 +- drivers/s390/block/dasd.c |1 - drivers/s390/block/dasd_3370_erp.c |1 - drivers/s390/block/dasd_3990_erp.c |1 - drivers/s390/block/dasd_9336_erp.c |1 - drivers/s390/block/dasd_9343_erp.c |1 - drivers/s390/block/dasd_cmb.c |2 -- drivers/s390/block/dasd_devmap.c |1 - drivers/s390/block/dasd_diag.c |1 - drivers/s390/block/dasd_diag.h |1 - drivers/s390/block/dasd_eckd.c |1 - drivers/s390/block/dasd_eckd.h |1 - drivers/s390/block/dasd_erp.c |1 - drivers/s390/block/dasd_fba.c |1 - drivers/s390/block/dasd_fba.h |1 - drivers/s390/block/dasd_genhd.c|1 - drivers/s390/block/dasd_int.h |1 - drivers/s390/block/dasd_ioctl.c|2 -- drivers/s390/block/dasd_proc.c |1 - drivers/s390/char/tape_34xx.c |5 ++--- drivers/s390/char/tape_class.c |4 ++-- drivers/s390/char/tape_class.h |2 +- drivers/s390/char/tape_core.c |5 ++--- drivers/s390/cio/airq.c|2 -- drivers/s390/cio/blacklist.c |1 - drivers/s390/cio/ccwgroup.c|1 - drivers/s390/cio/chsc.c|1 - drivers/s390/cio/cio.c |1 - drivers/s390/cio/cmf.c |2 +- drivers/s390/cio/css.c |1 - drivers/s390/cio/device.c |1 - drivers/s390/cio/device_ops.c |2 -- drivers/s390/cio/qdio.c|5 + drivers/s390/cio/qdio.h|2 -- drivers/s390/crypto/z90common.h|2 -- drivers/s390/crypto/z90crypt.h |2 -- drivers/s390/crypto/z90hardware.c |6 -- drivers/s390/crypto/z90main.c | 10 -- drivers/s390/net/claw.c| 11 +-- drivers/s390/net/claw.h|2 +- drivers/s390/net/ctcdbug.c |5 + drivers/s390/net/ctcdbug.h |4 +--- drivers/s390/net/ctcmain.c | 19 ++- drivers/s390/net/ctcmain.h |4 drivers/s390/net/ctctty.c |2 -- drivers/s390/net/ctctty.h |2 -- drivers/s390/net/cu3088.c |2 -- drivers/s390/net/fsm.c |2 -- drivers/s390/net/fsm.h |2 -- drivers/s390/net/iucv.c| 16 +--- drivers/s390/net/lcs.c |5 + drivers/s390/net/lcs.h |2 -- drivers/s390/net/netiucv.c | 15 +-- drivers/s390/net/qeth.h|2 -- drivers/s390/net/qeth_eddp.c |5 + drivers/s390/net/qeth_eddp.h |6 ++ drivers/s390/net/qeth_fs.h |5 - drivers/s390/net/qeth_main.c | 13 ++--- drivers/s390/net/qeth_mpc.c|2 -- drivers/s390/net/qeth_mpc.h|4 drivers/s390/net/qeth_proc.c |4 +--- drivers/s390/net/qeth_sys.c|4 +--- drivers/s390/net/qeth_tso.h|4 +--- drivers/s390/s390_rdev.c |1 - drivers/s390/scsi/zfcp_aux.c |2 -- drivers/s390/scsi/zfcp_ccw.c |2 -- drivers/s390/scsi/zfcp_dbf.c |2 -- drivers/s390/scsi/zfcp_def.h |2 -- drivers/s390/scsi/zfcp_erp.c |2 -- drivers/s390/scsi/zfcp_ext.h |2 -- drivers/s390/scsi/zfcp_fsf.c |2 -- drivers/s390/scsi/zfcp_qdio.c |2 -- drivers/s390/scsi/zfcp_scsi.c |2 -- drivers/s390/scsi/zfcp_sysfs_adapter.c |2 -- drivers/s390/scsi/zfcp_sysfs_driver.c |2 -- drivers/s390/scsi/zfcp_sysfs_port.c|2 -- drivers/s390/scsi/zfcp_sysfs_unit.c|2 -- include/asm-s390/dasd.h|2 -- include/asm-s390/qdio.h|2 -- 79 files changed, 27 insertions(+), 223 deletions(-) diff -urpN linux-2.6/arch/s390/lib/Makefile linux-2.6-patched/arch/s390/lib/Makefile --- linux-2.6/arch/s390/lib/Makefile2006-01-18 17:25:20.0 +0100 +++ linux-2.6-patched/arch/s390/lib/Makefile2006-01-18 17:25:47.0 +0100 @@ -6,4 +6,4 @@ EXTRA_AFLAGS := -traditional lib-y += delay.o string.o lib-y += $(if $(CONFIG_64BIT),uaccess64.o,uaccess.o) -lib-$(CONFIG_SMP) += spinlock.o \ No newline at end of file +lib-$(CONFIG_SMP) += spinlock.o diff -urpN linux-2.6/drivers/s390/block
