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/
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: im
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
0d19 ("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 ce9de
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
> 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
/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
nel/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
+++
> 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
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
> @@ -
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
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:
> > > &g
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&quo
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 i
erture_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
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:
> > >
> >
> >
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
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 o
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
> >
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 fo
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 *c
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: Heik
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 atomi
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 conten
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 al
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 t
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
&
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
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/uacces
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
> +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) {
> +
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
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, sinc
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: illega
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
> > 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 w
> > 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 lo
> > 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
ivers-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 mak
> 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_i
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/Make
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,
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 PROTECTE
43 matches
Mail list logo
