From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbcEIN5K (ORCPT ); Mon, 9 May 2016 09:57:10 -0400 Received: from icp-osb-irony-out4.external.iinet.net.au ([203.59.1.220]:33586 "EHLO icp-osb-irony-out4.external.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751072AbcEIN5I (ORCPT ); Mon, 9 May 2016 09:57:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BPAQDNljBX/+93qnwNUBoBAQGDcH2kZgEGlhIKFwuFbgKBaBEBAQEBAQEBhU0BAQEBAgEBAiAVQAEQCw0BCgICBRYLAgIJAwIBAgEWLwYBDAgBAYgfFq1nZ5AoAQEBAQEBAQEBAQEBAQEBAQEZfIRchRSHP4JZBZMshHaFfYUxhSWHH4VBjzs2gjEbgV1cAYkFAQEB X-IPAS-Result: A2BPAQDNljBX/+93qnwNUBoBAQGDcH2kZgEGlhIKFwuFbgKBaBEBAQEBAQEBhU0BAQEBAgEBAiAVQAEQCw0BCgICBRYLAgIJAwIBAgEWLwYBDAgBAYgfFq1nZ5AoAQEBAQEBAQEBAQEBAQEBAQEZfIRchRSHP4JZBZMshHaFfYUxhSWHH4VBjzs2gjEbgV1cAYkFAQEB X-IronPort-AV: E=Sophos;i="5.24,600,1454947200"; d="scan'208";a="86166482" Subject: Re: qemu m68k/mcf5208: problem with signal handler To: Waldemar Brodkorb , Waldemar Brodkorb References: <20160509063902.GL26720@waldemar-brodkorb.de> <20160509085815.GB13502@waldemar-brodkorb.de> Cc: linux-kernel@vger.kernel.org, Denys Vlasenko , Thomas Petazzoni , Gustavo Zacarias From: Greg Ungerer Message-ID: <5730972D.8050409@uclinux.org> Date: Mon, 9 May 2016 23:57:01 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160509085815.GB13502@waldemar-brodkorb.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Waldemar, On 09/05/16 18:58, Waldemar Brodkorb wrote: > Hi, > > forgot to add Greg in CC. > And sorry for the whitespace fuckup in the example code. > > Waldemar Brodkorb wrote, > >> Dear kernel hackers, >> >> I have a problem with the signal handling under qemu-system-m68k >> emulating coldfire mcf5208 evalboard. Following example code >> provided by Busybox maintainer Denys Vlasenko >> shows the problem when running on qemu: > > [ .. ] > >> You can generate a bootable image with latest buildroot, which shows the issue: >> $ git clone git://git.buildroot.net/buildroot >> $ cd buildroot; make qemu_m68k_mcf5208_defconfig; make >> $ qemu-system-m68k -M mcf5208evb -cpu m5208 -kernel output/images/vmlinux -nographic >> >> Every command forked from busybox hush shell will lead into a segmentation fault. >> >> I added following printk to start investigating the problem: >> diff -Nur linux-4.5.3.orig/arch/m68k/kernel/signal.c linux-4.5.3/arch/m68k/kernel/signal.c >> --- linux-4.5.3.orig/arch/m68k/kernel/signal.c 2016-05-04 23:50:38.000000000 +0200 >> +++ linux-4.5.3/arch/m68k/kernel/signal.c 2016-05-09 04:24:53.885199544 +0200 >> @@ -595,6 +595,7 @@ >> void __user *fp) >> { >> int fsize = frame_extra_sizes(formatvec >> 12); >> + printk("avoid broken signal handler...\n"); >> if (fsize < 0) { >> /* >> * user process trying to return with weird frame format >> >> But now the problem disappeared. :/ >> >> What do you think? Is it a Kernel bug or a C library problem? What version of linux kernel? What version of gcc? This sounds a lot like the problem I fixed in linux commit a9551799 ("m68k: Use conventional function parameters for do_sigreturn"). Definitely try that first. Regards Greg >> Busybox hush otherwise works fine for other noMMU targets as stm32 >> evalboard with cortex-m4. It also works in Qemu M68k emulating Q800 >> full MMU system. >> >> Thanks for any ideas, >> Waldemar >> >> http://lists.busybox.net/pipermail/busybox/2014-September/081659.html >> >