Signal patchset (was: Re: aranym bug, manifests as "ida_remove called for id=13" on recent kernels)

Signal patchset (was: Re: aranym bug, manifests as "ida_remove called for id=13" on recent kernels)

[Geert Uytterhoeven]

On Tue, Nov 2, 2010 at 16:30, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Oct 11, 2010 at 16:24, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> BTW, any comments on signal patchset?  Seems to work here, including the
>> stack expansion fixes, but that's on aranym.  I'll try to resurrect the
>> real hardware, but that may take a while.  If somebody could give it a beating
>> in the meanwhile...
>
> I tried it on my Amiga 4000/040.
> Without your patches, gdb gets stuck in state D+ when reaching a breakpoint:
>
> | cassandra:~# gdb /tmp/hello
> | GNU gdb 6.4.90-debian
> | Copyright (C) 2006 Free Software Foundation, Inc.
> | GDB is free software, covered by the GNU General Public License, and you are
> | welcome to change it and/or distribute copies of it under certain conditions.
> | Type "show copying" to see the conditions.
> | There is absolutely no warranty for GDB.  Type "show warranty" for details.
> | This GDB was configured as "m68k-linux-gnu"...Using host
> libthread_db library "/lib/libthread_db.so.1".
> |
> | (gdb) break main
> | Breakpoint 1 at 0x800003fc: file /home/geert/hello.c, line 6.
> | (gdb) run
> | Starting program: /tmp/hello
> |
> | Breakpoint 1, main (argc=1, argv=0xefbeedb4) at /home/geert/hello.c:6
>
> With your patches, it works a bit better:
>
> | cassandra:~# gdb /tmp/hello
> | GNU gdb 6.4.90-debian
> | Copyright (C) 2006 Free Software Foundation, Inc.
> | GDB is free software, covered by the GNU General Public License, and you are
> | welcome to change it and/or distribute copies of it under certain conditions.
> | Type "show copying" to see the conditions.
> | There is absolutely no warranty for GDB.  Type "show warranty" for details.
> | This GDB was configured as "m68k-linux-gnu"...Using host
> libthread_db library "/lib/libthread_db.so.1".
> |
> | (gdb) break main
> | Breakpoint 1 at 0x800003fc: file /home/geert/hello.c, line 6.
> | (gdb) run
> | Starting program: /tmp/hello
> |
> | Breakpoint 1, main (argc=1, argv=0xefcc5db4) at /home/geert/hello.c:6
> | 6         printf("Hello, world! [C]\n");
> | (gdb) cont
> | Continuing.
> | Hello, world! [C]
> |
> | Program exited normally.
> | (gdb) run
> | Starting program: /tmp/hello
> |
> | Breakpoint 1, main (argc=1, argv=0xef85bdb4) at /home/geert/hello.c:6
> | 6         printf("Hello, world! [C]\n");
> | (gdb) next
> | Hello, world! [C]
>
> After which gdb is stuck in S+, and /tmp/hello in t.

Unless someone objects, I'm inclined to apply Al's patchset, as it improves the
situation anyway.

OK?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Signal patchset (was: Re: aranym bug, manifests as "ida_remove called for id=13" on recent kernels)

[Al Viro]

On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:

> Unless someone objects, I'm inclined to apply Al's patchset, as it improves the
> situation anyway.
> 
> OK?

FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
and m68knommu sets.  I don't know how you guys would prefer it done, since
there's a trivial dependency between m68k and m68knommu parts of series -
the former has
+#ifndef __uClinux__
+#define __ARCH_WANT_SYS_RT_SIGSUSPEND
+#endif
in unistd.h and the latter does
-#ifndef __uClinux__
 #define __ARCH_WANT_SYS_RT_SIGSUSPEND
-#endif
Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
is done.  Other than that they are independent.

Re: Signal patchset

[Greg Ungerer]

On 15/12/10 20:10, Al Viro wrote:
> On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
>
>> Unless someone objects, I'm inclined to apply Al's patchset, as it improves the
>> situation anyway.
>>
>> OK?
>
> FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
> entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
> and m68knommu sets.  I don't know how you guys would prefer it done, since
> there's a trivial dependency between m68k and m68knommu parts of series -
> the former has
> +#ifndef __uClinux__
> +#define __ARCH_WANT_SYS_RT_SIGSUSPEND
> +#endif
> in unistd.h and the latter does
> -#ifndef __uClinux__
>   #define __ARCH_WANT_SYS_RT_SIGSUSPEND
> -#endif
> Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
> so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
> is done.  Other than that they are independent.

I can make sure to send to Linus after Geert. Unless Geert you
want to take and send both the m68k and m68knommu changes?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: Signal patchset

[Geert Uytterhoeven]

On Thu, Dec 16, 2010 at 14:23, Greg Ungerer <gerg@snapgear.com> wrote:
> On 15/12/10 20:10, Al Viro wrote:
>> On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
>>
>>> Unless someone objects, I'm inclined to apply Al's patchset, as it
>>> improves the
>>> situation anyway.
>>>
>>> OK?
>>
>> FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
>> entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
>> and m68knommu sets.  I don't know how you guys would prefer it done, since

Thx, good the know the nommu part is there, as I don't seem to have it
in my mailbox.

>> there's a trivial dependency between m68k and m68knommu parts of series -
>> the former has
>> +#ifndef __uClinux__
>> +#define __ARCH_WANT_SYS_RT_SIGSUSPEND
>> +#endif
>> in unistd.h and the latter does
>> -#ifndef __uClinux__
>>  #define __ARCH_WANT_SYS_RT_SIGSUSPEND
>> -#endif
>> Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
>> so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
>> is done.  Other than that they are independent.
>
> I can make sure to send to Linus after Geert. Unless Geert you
> want to take and send both the m68k and m68knommu changes?

I can take the m68knommu changes with your ack, too.
I'll try to take a look at it tomorrow...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Signal patchset

[Greg Ungerer]

Hi Geert,

On 07/01/11 06:42, Geert Uytterhoeven wrote:
> On Thu, Dec 16, 2010 at 14:23, Greg Ungerer<gerg@snapgear.com>  wrote:
>> On 15/12/10 20:10, Al Viro wrote:
>>> On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
>>>
>>>> Unless someone objects, I'm inclined to apply Al's patchset, as it
>>>> improves the
>>>> situation anyway.
>>>>
>>>> OK?
>>>
>>> FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
>>> entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
>>> and m68knommu sets.  I don't know how you guys would prefer it done, since
>
> Thx, good the know the nommu part is there, as I don't seem to have it
> in my mailbox.
>
>>> there's a trivial dependency between m68k and m68knommu parts of series -
>>> the former has
>>> +#ifndef __uClinux__
>>> +#define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>> +#endif
>>> in unistd.h and the latter does
>>> -#ifndef __uClinux__
>>>   #define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>> -#endif
>>> Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
>>> so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
>>> is done.  Other than that they are independent.
>>
>> I can make sure to send to Linus after Geert. Unless Geert you
>> want to take and send both the m68k and m68knommu changes?
>
> I can take the m68knommu changes with your ack, too.
> I'll try to take a look at it tomorrow...

Acked-by: Greg Ungerer <gerg@uclinux.org>

:-)

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: Signal patchset

[Geert Uytterhoeven]

On Thu, Jan 6, 2011 at 21:42, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Dec 16, 2010 at 14:23, Greg Ungerer <gerg@snapgear.com> wrote:
>> On 15/12/10 20:10, Al Viro wrote:
>>> On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
>>>
>>>> Unless someone objects, I'm inclined to apply Al's patchset, as it
>>>> improves the
>>>> situation anyway.
>>>>
>>>> OK?
>>>
>>> FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
>>> entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
>>> and m68knommu sets.  I don't know how you guys would prefer it done, since
>
> Thx, good the know the nommu part is there, as I don't seem to have it
> in my mailbox.
>
>>> there's a trivial dependency between m68k and m68knommu parts of series -
>>> the former has
>>> +#ifndef __uClinux__
>>> +#define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>> +#endif
>>> in unistd.h and the latter does
>>> -#ifndef __uClinux__
>>>  #define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>> -#endif
>>> Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
>>> so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
>>> is done.  Other than that they are independent.
>>
>> I can make sure to send to Linus after Geert. Unless Geert you
>> want to take and send both the m68k and m68knommu changes?
>
> I can take the m68knommu changes with your ack, too.
> I'll try to take a look at it tomorrow...

I applied the m68k part to master and for-2.6.38/for-linus.
In addition, I applied the m68knommu part with Greg's acks added to for-next.

Greg, please let me know if this is OK, so I can send a pull request to Linus
after it's been cooking one night in linux-next.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Signal patchset

[Greg Ungerer]

On 07/01/11 23:17, Geert Uytterhoeven wrote:
> On Thu, Jan 6, 2011 at 21:42, Geert Uytterhoeven<geert@linux-m68k.org>  wrote:
>> On Thu, Dec 16, 2010 at 14:23, Greg Ungerer<gerg@snapgear.com>  wrote:
>>> On 15/12/10 20:10, Al Viro wrote:
>>>> On Sun, Dec 05, 2010 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
>>>>
>>>>> Unless someone objects, I'm inclined to apply Al's patchset, as it
>>>>> improves the
>>>>> situation anyway.
>>>>>
>>>>> OK?
>>>>
>>>> FWIW, there's an m68knommu counterpart (ACKed by gerg a while ago).  The
>>>> entire bunch is on ftp.linux.org.uk/pub/people/viro/m68k-signals - both m68k
>>>> and m68knommu sets.  I don't know how you guys would prefer it done, since
>>
>> Thx, good the know the nommu part is there, as I don't seem to have it
>> in my mailbox.
>>
>>>> there's a trivial dependency between m68k and m68knommu parts of series -
>>>> the former has
>>>> +#ifndef __uClinux__
>>>> +#define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>>> +#endif
>>>> in unistd.h and the latter does
>>>> -#ifndef __uClinux__
>>>>   #define __ARCH_WANT_SYS_RT_SIGSUSPEND
>>>> -#endif
>>>> Both parts switch to generic sys_rt_sigsuspend(), for mmu and nommu resp.,
>>>> so they need __ARCH_WANT_SYS_RT_SIGSUSPEND defined as soon as conversion
>>>> is done.  Other than that they are independent.
>>>
>>> I can make sure to send to Linus after Geert. Unless Geert you
>>> want to take and send both the m68k and m68knommu changes?
>>
>> I can take the m68knommu changes with your ack, too.
>> I'll try to take a look at it tomorrow...
>
> I applied the m68k part to master and for-2.6.38/for-linus.
> In addition, I applied the m68knommu part with Greg's acks added to for-next.
>
> Greg, please let me know if this is OK, so I can send a pull request to Linus
> after it's been cooking one night in linux-next.

Oh, yes, that is ok. (I see the pull request now :-)
I have a bunch of things in linux-next for m68knommu, and we
hit nothing there so I think it is all good.

Regards
Greg


>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com