Re: [patch 12/30] s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt()
On Thu, Dec 10, 2020 at 08:25:48PM +0100, Thomas Gleixner wrote: > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Christian Borntraeger > Cc: Heiko Carstens > Cc: linux-s...@vger.kernel.org > --- > arch/s390/kernel/irq.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Carstens
Re: linux-next: build failure after merge of the net-next tree
On Wed, Aug 05, 2020 at 03:06:27PM +0200, Stefano Brivio wrote:
> On Wed, 5 Aug 2020 22:31:21 +1000
> Stephen Rothwell wrote:
>
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (s390 defconfig)
> > failed like this:
> >
> > net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function
> > 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
> >
> > Caused by commit
> >
> > 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP
> > packets")
>
> Ouch, sorry for that.
>
> I'm getting a few of them by the way:
>
> ---
> net/core/skbuff.o: In function `skb_checksum_setup_ipv6':
> /home/sbrivio/net-next/net/core/skbuff.c:4980: undefined reference to
> `csum_ipv6_magic'
> net/core/netpoll.o: In function `netpoll_send_udp':
> /home/sbrivio/net-next/net/core/netpoll.c:419: undefined reference to
> `csum_ipv6_magic'
> net/netfilter/utils.o: In function `nf_ip6_checksum':
> /home/sbrivio/net-next/net/netfilter/utils.c:74: undefined reference to
> `csum_ipv6_magic'
> /home/sbrivio/net-next/net/netfilter/utils.c:84: undefined reference to
> `csum_ipv6_magic'
> net/netfilter/utils.o: In function `nf_ip6_checksum_partial':
> /home/sbrivio/net-next/net/netfilter/utils.c:112: undefined reference to
> `csum_ipv6_magic'
> net/ipv4/ip_tunnel_core.o:/home/sbrivio/net-next/net/ipv4/ip_tunnel_core.c:335:
> more undefined references to `csum_ipv6_magic' follow
> ---
>
> ...checking how it should be fixed now.
>
> Heiko, by the way, do we want to provide a s390 version similar to the
> existing csum_partial() implementation in
> arch/s390/include/asm/checksum.h right away? Otherwise, I'll just take
> care of the ifdeffery.
You probably only need to include include/net/ip6_checksum.h which
contains the default implementation.
And yes, I put it on my todo list that we need to provide an s390
variant as well.
Re: [PATCH v6 bpf-next 13/17] s390: bpf: eliminate zero extension code-gen
On Fri, May 03, 2019 at 11:42:40AM +0100, Jiong Wang wrote: > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Signed-off-by: Jiong Wang > --- > arch/s390/net/bpf_jit_comp.c | 20 +--- > 1 file changed, 17 insertions(+), 3 deletions(-) When sending patches which affect s390, could you please add Martin and me on cc to _all_ patches? We now received only the cover-letter plus one patch. It's always hard in such cirumstances to figure out if the code is doing the right thing. Usually I end up looking up the missing patches within other mailing lists, however I haven't subscribed the bpf and netdev mailing lists. The extra e-mail volume because of being added to CC really doesn't matter at all.
[PATCH] s390: bpf: fix JMP32 code-gen
Commit 626a5f66da0d19 ("s390: bpf: implement jitting of JMP32") added
JMP32 code-gen support for s390. However it triggers the warning below
due to some unusual gotos in the original s390 bpf jit code.
Add a couple of additional "is_jmp32" initializations to fix this.
Also fix the wrong opcode for the "llilf" instruction that was
introduced with the same commit.
arch/s390/net/bpf_jit_comp.c: In function 'bpf_jit_insn':
arch/s390/net/bpf_jit_comp.c:248:55: warning: 'is_jmp32' may be used
uninitialized in this function [-Wmaybe-uninitialized]
_EMIT6(op1 | reg(b1, b2) << 16 | (rel & 0x), op2 | mask); \
^
arch/s390/net/bpf_jit_comp.c:1211:8: note: 'is_jmp32' was declared here
bool is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
Fixes: 626a5f66da0d19 ("s390: bpf: implement jitting of JMP32")
Cc: Jiong Wang
Cc: Martin Schwidefsky
Signed-off-by: Heiko Carstens
---
arch/s390/net/bpf_jit_comp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index ce9defdff62a..51dd0267d014 100644
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -1154,7 +1154,7 @@ static noinline int bpf_jit_insn(struct bpf_jit *jit,
struct bpf_prog *fp, int i
mask = 0x7000; /* jnz */
if (BPF_CLASS(insn->code) == BPF_JMP32) {
/* llilf %w1,imm (load zero extend imm) */
- EMIT6_IMM(0xc001, REG_W1, imm);
+ EMIT6_IMM(0xc00f, REG_W1, imm);
/* nr %w1,%dst */
EMIT2(0x1400, REG_W1, dst_reg);
} else {
@@ -1216,6 +1216,7 @@ static noinline int bpf_jit_insn(struct bpf_jit *jit,
struct bpf_prog *fp, int i
REG_W1, dst_reg, src_reg);
goto branch_oc;
branch_ks:
+ is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
/* lgfi %w1,imm (load sign extend imm) */
EMIT6_IMM(0xc001, REG_W1, imm);
/* crj or cgrj %dst,%w1,mask,off */
@@ -1223,6 +1224,7 @@ static noinline int bpf_jit_insn(struct bpf_jit *jit,
struct bpf_prog *fp, int i
dst_reg, REG_W1, i, off, mask);
break;
branch_ku:
+ is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
/* lgfi %w1,imm (load sign extend imm) */
EMIT6_IMM(0xc001, REG_W1, imm);
/* clrj or clgrj %dst,%w1,mask,off */
@@ -1230,11 +1232,13 @@ static noinline int bpf_jit_insn(struct bpf_jit *jit,
struct bpf_prog *fp, int i
dst_reg, REG_W1, i, off, mask);
break;
branch_xs:
+ is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
/* crj or cgrj %dst,%src,mask,off */
EMIT6_PCREL(0xec00, (is_jmp32 ? 0x0076 : 0x0064),
dst_reg, src_reg, i, off, mask);
break;
branch_xu:
+ is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
/* clrj or clgrj %dst,%src,mask,off */
EMIT6_PCREL(0xec00, (is_jmp32 ? 0x0077 : 0x0065),
dst_reg, src_reg, i, off, mask);
--
2.16.4
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote: > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann > --- > arch/s390/kernel/syscalls/syscall.tbl | 20 + For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 28/29] y2038: rename old time and utime syscalls
On Fri, Jan 18, 2019 at 05:18:34PM +0100, Arnd Bergmann wrote: > The time, stime, utime, utimes, and futimesat system calls are only > used on older architectures, and we do not provide y2038 safe variants > of them, as they are replaced by clock_gettime64, clock_settime64, > and utimensat_time64. > > However, for consistency it seems better to have the 32-bit architectures > that still use them call the "time32" entry points (leaving the > traditional handlers for the 64-bit architectures), like we do for system > calls that now require two versions. > > Note: We used to always define __ARCH_WANT_SYS_TIME and > __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and > __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is > reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while > we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat > mode. The resulting asm/unistd.h changes look a bit counterintuitive. > > This is only a cleanup patch and it should not change any behavior. > > Signed-off-by: Arnd Bergmann ... > arch/s390/include/asm/unistd.h | 2 +- For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 17/29] syscalls: remove obsolete __IGNORE_ macros
On Fri, Jan 18, 2019 at 05:18:23PM +0100, Arnd Bergmann wrote: > These are all for ignoring the lack of obsolete system calls, > which have been marked the same way in scripts/checksyscall.sh, > so these can be removed. > > Signed-off-by: Arnd Bergmann > --- > arch/mips/include/asm/unistd.h | 16 > arch/parisc/include/asm/unistd.h | 3 --- > arch/s390/include/asm/unistd.h | 2 -- > arch/xtensa/include/asm/unistd.h | 12 > 4 files changed, 33 deletions(-) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 14/29] arch: add pkey and rseq syscall numbers everywhere
On Fri, Jan 18, 2019 at 05:18:20PM +0100, Arnd Bergmann wrote: > Most architectures define system call numbers for the rseq and pkey system > calls, even when they don't support the features, and perhaps never will. > > Only a few architectures are missing these, so just define them anyway > for consistency. If we decide to add them later to one of these, the > system call numbers won't get out of sync then. > > Signed-off-by: Arnd Bergmann > --- > arch/alpha/include/asm/unistd.h | 4 > arch/alpha/kernel/syscalls/syscall.tbl | 4 > arch/ia64/kernel/syscalls/syscall.tbl | 4 > arch/m68k/kernel/syscalls/syscall.tbl | 4 > arch/parisc/include/asm/unistd.h| 3 --- > arch/parisc/kernel/syscalls/syscall.tbl | 4 > arch/s390/include/asm/unistd.h | 3 --- > arch/s390/kernel/syscalls/syscall.tbl | 3 +++ > arch/sh/kernel/syscalls/syscall.tbl | 4 > arch/sparc/include/asm/unistd.h | 5 - > arch/sparc/kernel/syscalls/syscall.tbl | 4 > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + > 12 files changed, 28 insertions(+), 15 deletions(-) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 13/29] arch: add split IPC system calls where needed
On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that set it implicitly. > > For the additon of a y2083 safe semtimedop() system call, I chose to only > support the separate entry points, but that requires first supporting > the regular ones with their own syscall numbers. > > The IPC_64 is now implied by the new semctl/shmctl/msgctl system > calls even on the architectures that require passing it with the ipc() > multiplexer. > > I'm not adding the new semtimedop() or semop() on 32-bit architectures, > those will get implemented using the new semtimedop_time64() version > that gets added along with the other time64 calls. > Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). > > Signed-off-by: Arnd Bergmann > --- > One aspect here that might be a bit controversial is the use of > the same system call numbers across all architectures, synchronizing > all of them with the x86-32 numbers. With the new syscall.tbl > files, I hope we can just keep doing that in the future, and no > longer require the architecture maintainers to assign a number. > > This is mainly useful for implementers of the C libraries: if > we can add future system calls everywhere at the same time, using > a particular version of the kernel headers also guarantees that > the system call number macro is visible. > --- > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++ > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++ > arch/powerpc/kernel/syscalls/syscall.tbl | 13 + > arch/s390/kernel/syscalls/syscall.tbl | 12 > arch/sh/kernel/syscalls/syscall.tbl | 11 +++ > arch/sparc/kernel/syscalls/syscall.tbl| 12 > arch/x86/entry/syscalls/syscall_32.tbl| 11 +++ > 7 files changed, 81 insertions(+) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH 07/11] y2038: syscalls: rename y2038 compat syscalls
On Thu, Jan 10, 2019 at 06:22:12PM +0100, Arnd Bergmann wrote: > diff --git a/arch/s390/kernel/syscalls/syscall.tbl > b/arch/s390/kernel/syscalls/syscall.tbl > index f84ea364a302..b3199a744731 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -20,7 +20,7 @@ > 10 common unlink sys_unlink > compat_sys_unlink > 11 common execve sys_execve > compat_sys_execve > 12 common chdir sys_chdir > compat_sys_chdir > -13 32 time- > compat_sys_time > +13 32 time- > sys_time32 > 14 common mknod sys_mknod > compat_sys_mknod > 15 common chmod sys_chmod > compat_sys_chmod > 16 32 lchown - > compat_sys_s390_lchown16 > @@ -30,11 +30,11 @@ > 22 common umount sys_oldumount > compat_sys_oldumount > 23 32 setuid - > compat_sys_s390_setuid16 > 24 32 getuid - > compat_sys_s390_getuid16 > -25 32 stime - > compat_sys_stime > +25 32 stime - > sys_stime32 > 26 common ptrace sys_ptrace > compat_sys_ptrace > 27 common alarm sys_alarm > sys_alarm > 29 common pause sys_pause > sys_pause > -30 common utime sys_utime > compat_sys_utime > +30 common utime sys_utime > sys_utime32 ...(and more)... All of them need compat wrappers to clear the uppermost 33 bits of user space pointers. I assume there is no new *32 system call which takes u64/s64 arguments; so the pointers should be the only problem.
Re: [PATCH v3 1/8] arch: Use asm-generic/socket.h when possible
On Mon, Jan 07, 2019 at 07:26:50PM -0800, Deepa Dinamani wrote: > Many architectures maintain an arch specific copy of the > file even though there are no differences with the asm-generic > one. Allow these architectures to use the generic one instead. > > Signed-off-by: Deepa Dinamani > --- > arch/s390/include/uapi/asm/Kbuild | 1 + > arch/s390/include/uapi/asm/socket.h | 117 For the s390 bits: Acked-by: Heiko Carstens
Re: "bpf: Improve the info.func_info and info.func_info_rec_size behavior" breaks strace self tests
On Thu, Jan 03, 2019 at 11:52:51PM +, Martin Lau wrote:
> On Thu, Jan 03, 2019 at 11:41:18PM +0100, Heiko Carstens wrote:
> > On Thu, Jan 03, 2019 at 07:12:05PM +, Martin Lau wrote:
> > > On Thu, Jan 03, 2019 at 12:46:13PM +0100, Heiko Carstens wrote:
> > > > Hello,
> > > >
> > > > the kernel commit 7337224fc150 ("bpf: Improve the info.func_info and
> > > > info.func_info_rec_size behavior") breaks one of strace's self tests:
> > > >
> > > > FAIL: bpf-obj_get_info_by_fd-prog-v.gen
...
> I am running against linux-next. I don't see how root and non-root affect
> thing here. I guess the test has been running without jit so far?
Yes, it was disabled. Enabling jit and adding your memset fix leads to
what you report with 2) below.
> 1) root or not, if jit is enabled,
>without the memset() fix in the bpf-obj_get_info_by_fd.c in my last email,
>they all failed:
>[root@arch-fb-vm1 tests]# ./bpf-obj_get_info_by_fd-prog-v.gen.test
>BPF_OBJ_GET_INFO_BY_FD prog 2 failed: Bad address
>bpf-obj_get_info_by_fd-prog-v.gen.test: skipped test:
> ../bpf-obj_get_info_by_fd-prog-v exited with code 77
>
>Please fix this first.
>
> 2) After having the memset fix:
>Root or not, for jited program, if I run
>./bpf-obj_get_info_by_fd-prog-v.gen.test, they failed. If I read the
>init.sh correclty, it fails because there is a diff between the
>./bpf-obj_get_info_by_fd-prog-v stdout and the "strace -o log". I think
>"strace -o log" only has the /* bytes 104..151 */ part if some bytes
>are non-zero?
>
>Regardless, the test program "bpf-obj_get_info_by_fd.c" is telling
>the kernel that the userspace "info" is in size 168 bytes.
>The kernel then tells as much details as possible about
>a bpf prog in "info". I don't see a ABI breakage here.
>
>I believe the test just happens to work so far because it has been running
>without jit?
>
>If I run it with jit enabled:
> -bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
> info_len=168, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=35,
> tag="\xda\xbf\x02\x07\xd1\x99\x24\x86", jited_prog_len=0 => 110,
> jited_prog_insns=NULL, xlated_prog_len=0 => 120, xlated_prog_insns=[],
> load_time=2476906063975, created_by_uid=0, nr_map_ids=0 => 1, map_ids=[],
> name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0}}}, 16) = 0
> -bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
> info_len=168, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=35,
> tag="\xda\xbf\x02\x07\xd1\x99\x24\x86", jited_prog_len=0 => 110,
> jited_prog_insns=NULL, xlated_prog_len=0 => 120, xlated_prog_insns=[],
> load_time=2476906063975, created_by_uid=0, nr_map_ids=2 => 1, map_ids=[36],
> name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0}}}, 16) = 0
> +bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
> info_len=168, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=35,
> tag="\xda\xbf\x02\x07\xd1\x99\x24\x86", jited_prog_len=0 => 110,
> jited_prog_insns=NULL, xlated_prog_len=0 => 120, xlated_prog_insns=[],
> load_time=2476906063975, created_by_uid=0, nr_map_ids=0 => 1, map_ids=[],
> name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0, /* bytes
> 104..167 */
> "\x01\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"}}},
> 16) = 0
> +bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
> info_len=168, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=35,
> tag="\xda\xbf\x02\x07\xd1\x99\x24\x86", jited_prog_len=0 => 110,
> jited_prog_insns=NULL, xlated_prog_len=0 => 120, xlated_prog_insns=[],
> load_time=2476906063975, created_by_uid=0, nr_map_ids=2 => 1, map_ids=[36],
> name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0, /* bytes
> 104..167 */
> "\x01\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"}}},
> 16) = 0
>
> The diff comes in as early as byte 104-th which is the nr_jited_ksyms == 1.
>
> Please fix the test program. A protential fix is in
> bpf-obj_get_info_by_fd.c
> to printf the non-zero "/* bytes 104..1xx */..." the same way as the
> "strace -o log" does.
Thanks a lot for looking into this!
Eugene, Dmitry will you take care of fixing this?
Re: "bpf: Improve the info.func_info and info.func_info_rec_size behavior" breaks strace self tests
On Thu, Jan 03, 2019 at 07:12:05PM +, Martin Lau wrote:
> On Thu, Jan 03, 2019 at 12:46:13PM +0100, Heiko Carstens wrote:
> > Hello,
> >
> > the kernel commit 7337224fc150 ("bpf: Improve the info.func_info and
> > info.func_info_rec_size behavior") breaks one of strace's self tests:
> >
> > FAIL: bpf-obj_get_info_by_fd-prog-v.gen
> The strace's bpf-obj_get_info_by_fd-prog-v test did fail. However,
> I failed to see how 7337224fc150 broke it. How do you trace down to
> commit 7337224fc150 and can you share your test output?
>
> The failure I can reproduce is EFAULT. It should have been failing
> as early as "nr_jited_ksyms" is added to "struct bpf_prog_info"
> in linux/bpf.h.
Ah, sorry(!), I forgot to mention an important detail: the test
failure happens only if executed as normal (non-root) user.
With 7337224fc150 ("bpf: Improve the info.func_info and
info.func_info_rec_size behavior") the failure happens. With commit
30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe")
it passes; which is one commit earlier.
FAIL: bpf-obj_get_info_by_fd-prog-v.gen
===
--- exp 2019-01-03 23:31:49.576949303 +0100
+++ log 2019-01-03 23:31:49.576949303 +0100
@@ -1,8 +1,8 @@
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8,
max_entries=1, map_flags=0, inner_map_fd=0, map_name="test_map",
map_ifindex=0}, 48) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_SOCKET_FILTER, insn_cnt=9,
insns=[{code=BPF_ALU64|BPF_K|BPF_MOV, dst_reg=BPF_REG_1, src_reg=BPF_REG_0,
off=0, imm=0}, {code=BPF_STX|BPF_W|BPF_MEM, dst_reg=BPF_REG_10,
src_reg=BPF_REG_1, off=-4, imm=0}, {code=BPF_ALU64|BPF_X|BPF_MOV,
dst_reg=BPF_REG_2, src_reg=BPF_REG_10, off=0, imm=0},
{code=BPF_ALU64|BPF_K|BPF_ADD, dst_reg=BPF_REG_2, src_reg=BPF_REG_0, off=0,
imm=0xfffc}, {code=BPF_LD|BPF_DW|BPF_IMM, dst_reg=BPF_REG_1,
src_reg=BPF_REG_1, off=0, imm=0x3}, {code=BPF_LD|BPF_W|BPF_IMM,
dst_reg=BPF_REG_0, src_reg=BPF_REG_0, off=0, imm=0},
{code=BPF_JMP|BPF_K|BPF_CALL, dst_reg=BPF_REG_0, src_reg=BPF_REG_0, off=0,
imm=0x1}, {code=BPF_ALU64|BPF_K|BPF_MOV, dst_reg=BPF_REG_0, src_reg=BPF_REG_0,
off=0, imm=0}, {code=BPF_JMP|BPF_K|BPF_EXIT, dst_reg=BPF_REG_0,
src_reg=BPF_REG_0, off=0, imm=0}], license="BSD", log_level=42, log_size=4096,
log_buf="", kern_version=KERNEL_VERSION(57005, 192, 222), prog_flags=0,
prog_name="test_prog", prog_ifindex=0,
expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 4
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=128
=> 80, info={type=BPF_MAP_TYPE_ARRAY, id=15, key_size=4, value_size=8,
max_entries=1, map_flags=0, name="test_map", ifindex=0, netns_dev=makedev(0,
0), netns_ino=0}}}, 16) = 0
-bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4, info_len=168
=> 152, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=8,
tag="\xde\x90\x83\x18\xfb\x16\xd8\x9c", jited_prog_len=0,
jited_prog_insns=NULL, xlated_prog_len=0, xlated_prog_insns=NULL,
load_time=28281352029, created_by_uid=1000, nr_map_ids=0 => 1, map_ids=NULL,
name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0}}}, 16) = 0
-bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
info_len=152, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=8,
tag="\xde\x90\x83\x18\xfb\x16\xd8\x9c", jited_prog_len=0,
jited_prog_insns=NULL, xlated_prog_len=336, xlated_prog_insns=0x3ff8d6f7000,
load_time=28281352029, created_by_uid=1000, nr_map_ids=2,
map_ids=0x3ff8d6f1000, name="test_prog", ifindex=0, netns_dev=makedev(0, 0),
netns_ino=0}}}, 16) = -1 EFAULT (Bad address)
-bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
info_len=152, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=8,
tag="\xde\x90\x83\x18\xfb\x16\xd8\x9c", jited_prog_len=0,
jited_prog_insns=NULL, xlated_prog_len=0, xlated_prog_insns=[],
load_time=28281352029, created_by_uid=1000, nr_map_ids=0 => 1, map_ids=[],
name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0}}}, 16) = 0
-bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4,
info_len=152, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=8,
tag="\xde\x90\x83\x18\xfb\x16\xd8\x9c", jited_prog_len=0,
jited_prog_insns=NULL, xlated_prog_len=0, xlated_prog_insns=[],
load_time=28281352029, created_by_uid=1000, nr_map_ids=2 => 1, map_ids=[15],
name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0}}}, 16) = 0
+bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=4, info_len=168
=> 152, info={type=BPF_PROG_TYPE_SOCKET_FILTER, id=8,
tag="\xde\x90\x83\x18\xfb\x16\xd8\x9c", jited_prog_len=0,
jited_prog_insns=NULL, xlated_prog_len=0, xlated_prog_insns=NULL,
load_time=28281352029, created_by_uid=1000, nr_map_ids=0 => 1, map_ids=NULL,
name="test_prog", ifindex=0, netns_dev=makedev(0, 0), netns_ino=0, /* by
"bpf: Improve the info.func_info and info.func_info_rec_size behavior" breaks strace self tests
Hello,
the kernel commit 7337224fc150 ("bpf: Improve the info.func_info and
info.func_info_rec_size behavior") breaks one of strace's self tests:
FAIL: bpf-obj_get_info_by_fd-prog-v.gen
Looking into the kernel commit, it seems that the user space visible
uapi change is intentional; even though it might break existing user
space.
To reproduce:
git clone https://gitlab.com/strace/strace.git
cd strace
./bootstrap
./configure
make -j $(nproc)
cd tests
make -j $(nproc) check
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 > 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
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 > > <0>Kernel 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
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
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
[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] 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
[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 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_flags&MSG_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_net
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
[<00000210dc9e>] 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
[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
> > 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
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
> > 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
> > 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
> 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
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
[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 linu
