From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=DATE_IN_PAST_03_06, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 283E3C43603 for ; Sat, 7 Dec 2019 16:58:07 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0D5A20637 for ; Sat, 7 Dec 2019 16:58:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QuZJip/v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0D5A20637 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iddPC-0001Xv-1z for qemu-devel@archiver.kernel.org; Sat, 07 Dec 2019 11:58:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50965) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iddOI-0000fM-39 for qemu-devel@nongnu.org; Sat, 07 Dec 2019 11:57:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iddOF-0008K3-S6 for qemu-devel@nongnu.org; Sat, 07 Dec 2019 11:57:09 -0500 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]:43939) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iddO9-0008G5-D8; Sat, 07 Dec 2019 11:57:01 -0500 Received: by mail-oi1-x22f.google.com with SMTP id x14so2679344oic.10; Sat, 07 Dec 2019 08:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3oqtDTZEFM1aOe2l96t5eWqf/P2MM/74EwOzIM+HdmU=; b=QuZJip/vijLlHW8m7XPoXxWGjDqokjfwBnJBA+FnBdVKVBKlHUYEFmwZzIrisP0bfj 973i8Q50e30zuCd6+b2P6aFugeYCFX1DdTUI0i/nkQs4CpXEoBE+H4FdlNk4DOQhpEBa rUHjvot1JhYoIuAAnkE1DOXUVLcUBIpNJWZZ31RhHfdoYmwogQoz7Jqoq0wuSQ1Yf2UA ryOxOsf/NKeO/MBOFpyEiLJwxANP8Ebi5UjU5K46/puWkpAjDHDIBJQv0aq8ineLVNK5 kLDAqsnDYUCTlTKgSnjFz4qtVAO5gyJ94UBS9jUGNxm1eZRCXl2deAJ2vOup+YMup1ct 7/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3oqtDTZEFM1aOe2l96t5eWqf/P2MM/74EwOzIM+HdmU=; b=WnEkipRydm2LQHrUP6JW0LhJYFVuUAIOZwlO1SylU9lmwQXK3FmQvp4Ar7kmUjeLDU xKYJkSK/dpRa+74EYzNs42+PIq++dlIwRVuO9lewBIRzA9rj1b9lGb1/o2+bEg056BKV Wm1jFWeIKec5g14t12qAHiTroLIRe9cn6YMoior5WmFILX04T0AmBcgSwIyj4jlgs5cP V2/nnqsv8RIM33ks28HNI+Xa996ZTKlaGr71vtqEv1nPrhLuM7snkQI6u1FkpT5ZoE+o WFwYPUQGf6/dLR1wFT0E9rSX6tSoWr5K1tIzfo5rVUY7aUGwqmAaHoDLPlg+bxV4bVky 2svg== X-Gm-Message-State: APjAAAUhAbzE7mZBsovl3V/kHBGffjL16qSNErVdswvk1/+Q3wmzP/Ey s4RNUOeChonm7bLyeB/1O4HOKF8flHH4HvIkG2L6qA== X-Google-Smtp-Source: APXvYqxoEiiVn9KtuHpvdUC65yBToR//GQK87U/vLF84L8SKhBmaXD/cJc/m6Xps7KY+fymc2vIueiZvxhz56Ce/Yfc= X-Received: by 2002:aca:bd85:: with SMTP id n127mr11342911oif.136.1575723921850; Sat, 07 Dec 2019 05:05:21 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Sat, 7 Dec 2019 05:05:21 -0800 (PST) In-Reply-To: References: <6542ac57-6b06-1337-825b-dd1187accd15@vivier.eu> From: Aleksandar Markovic Date: Sat, 7 Dec 2019 14:05:21 +0100 Message-ID: Subject: Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 To: Aleksandar Markovic Content-Type: multipart/alternative; boundary="000000000000a0471c05991cd070" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::22f X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , "marlies.ruck@gmail.com" , "qemu-trivial@nongnu.org" , "riku.voipio@iki.fi" , Laurent Vivier , "qemu-devel@nongnu.org" , Aleksandar Markovic , Josh Kunz , Petar Jovanovic , "milos.stojanovic@rt-rk.com" , Shu-Chun Weng Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000a0471c05991cd070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, August 28, 2019, Aleksandar Markovic wrote: > > From: Laurent Vivier > > Sent: Wednesday, August 28, 2019 10:51 AM > > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com > > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; > > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar > Markovic > > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and > SIGRTMAX - 1 > > > > Le 26/08/2019 =C3=A0 23:10, Josh Kunz a =C3=A9crit : > > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier > > > wrote: > > > > > > Le 19/08/2019 =C3=A0 23:46, Josh Kunz via Qemu-devel a =C3=A9crit= : > > > > Hi all, > > > > > > > > I have also experienced issues with SIGRTMIN + 1, and am > interested in > > > > moving this patch forwards. Anything I can do here to help? > Would the > > > > maintainers prefer myself or Marli re-submit the patch? > > > > > > > > The Go issue here seems particularly sticky. Even if we update > the Go > > > > runtime, users may try and run older binaries built with older > > > versions of > > > > Go for quite some time (months? years?). Would it be better to > > > hide this > > > > behind some kind of build-time flag > > > (`--enable-sigrtmin-plus-one-proxy` or > > > > something), so that some users can opt-in, but older binaries > > > still work as > > > > expected? > > > > > > > > Also, here is a link to the original thread this message is in > > > reply to > > > > in-case my mail-client doesn't set up the reply properly: > > > > https://lists.nongnu.org/archive/html/qemu-devel/2019- > 07/msg01303.html > > > > > > The problem here is we break something to fix something else. > > > > > > I'm wondering if the series from Aleksandar Markovic, "linux-user= : > > > Support signal passing for targets having more signals than host" > [1] > > > can fix the problem in a better way? > > > > > > > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusio= n) > > > does not directly fix the issue addressed by this patch (re-wiring > > > SIGRTMIN+1), but since it basically implements generic signal > > > multiplexing, it could be re-worked to address this case as well. The > > > way it handles `si_code` spooks me a little bit. It could easily be > > > broken by a kernel version change, and such a breakage could be hard = to > > > detect or lead to surprising results. Other than that, it looks like = a > > > reasonable implementation. > > > > > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > > > signal-multiplexing mechanism doesn't seem *that* much better to me. = It > > > adds a lot of complexity, and only saves a single signal (assuming > glibc > > > doesn't add more reserved signals). The "big win" is additional > > > emulation features, like those introduced in MUX patch (being able to > > > utilize signals outside of the host range). If having those features = in > > > QEMU warrants the additional complexity, then re-working this patch > > > on-top of that infrastructure seems like a good idea. > > > > > > If the maintainers want to go down that route, then I would be happy = to > > > re-work this patch utilizing the infrastructure from the MUX patch. > > > Unfortunately it will require non-trivial changes, so it may be best = to > > > wait until that patch is merged. I could also provide a patch "on top > > > of" the MUX patch, if that's desired/more convenient. > > > > > > Just one last note, if you do decide to merge the MUX patch, then it > > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > > > multiplexing signal if possible, to avoid breaking go binaries. > > > > > > > Personally, I prefer a solution that breaks nothing. > > > > Aleksandar, Milos, > > > > do you have an updated version of you series "Support signal passing fo= r > > targets having more signals than host"? > > > > Milos is unfortunetely working on an entirely different project now, and > can't spare enough time to finish the series. I am also busy with other > issues, even though I would like very much this or equivalent solution to > be integrated. Alternatively, someone in the team may have time later thi= s > year, but I do not know that yet - perhaps somebody else (Josh) can take > over the series? > > Hello, all. >From my side, status quo. Milos (who ironically works in the office next to mine) expressed interest in modifying his solution to be in accordance with what Peter said, says that this is doable, but requires a lot of meticulous work - however, he is too involved into his project for months to go. I am also involved in other things, and, furthermore, has less background knowledge than Milos. That said, we in MIPS would like the solution described by Peter as much as other platforms, if not more. All this taken into account, perhaps this can be a project for Outreachy or Google Summer of Code, mentored by Peter? The perhaps largest problem with that is that the person doing it would need some steep learning curve (on signals in general, and their treatment in QEMU), that can take some significant time. Yours, Aleksandar > Sincerely, > Aleksandar > > > > Thanks, > > Laurent > > > --000000000000a0471c05991cd070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, August 28, 2019, Aleksandar Markovic <amarkovic@wavecomp.com> wrote:
> From: Laurent Vivier <laurent@vivier.eu>
> Sent: Wednesday, August 28, 2019 10:51 AM
> To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com
> Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; > qemu-trivial@nongnu.org; Peter Maydell;= Shu-Chun Weng; Aleksandar Markovic
> Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIG= RTMAX - 1
>
> Le 26/08/2019 =C3=A0 23:10, Josh Kunz a =C3=A9crit :
> > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu
> > <mailto:laurent@vivier.eu= >> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0Le 19/08/2019 =C3=A0 23:46, Josh Kunz via Qemu= -devel a =C3=A9crit :
> >=C2=A0 =C2=A0 =C2=A0> Hi all,
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> I have also experienced issues with SIGRT= MIN + 1, and am interested in
> >=C2=A0 =C2=A0 =C2=A0> moving this patch forwards. Anything I ca= n do here to help? Would the
> >=C2=A0 =C2=A0 =C2=A0> maintainers prefer myself or Marli re-sub= mit the patch?
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> The Go issue here seems particularly stic= ky. Even if we update the Go
> >=C2=A0 =C2=A0 =C2=A0> runtime, users may try and run older bina= ries built with older
> >=C2=A0 =C2=A0 =C2=A0versions of
> >=C2=A0 =C2=A0 =C2=A0> Go for quite some time (months? years?). = Would it be better to
> >=C2=A0 =C2=A0 =C2=A0hide this
> >=C2=A0 =C2=A0 =C2=A0> behind some kind of build-time flag
> >=C2=A0 =C2=A0 =C2=A0(`--enable-sigrtmin-plus-one-proxy` or > >=C2=A0 =C2=A0 =C2=A0> something), so that some users can opt-in= , but older binaries
> >=C2=A0 =C2=A0 =C2=A0still work as
> >=C2=A0 =C2=A0 =C2=A0> expected?
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Also, here is a link to the original thre= ad this message is in
> >=C2=A0 =C2=A0 =C2=A0reply to
> >=C2=A0 =C2=A0 =C2=A0> in-case my mail-client doesn't set up= the reply properly:
> >=C2=A0 =C2=A0 =C2=A0> https://lists.n= ongnu.org/archive/html/qemu-devel/2019-07/msg01303.html
> >
> >=C2=A0 =C2=A0 =C2=A0The problem here is we break something to fix = something else.
> >
> >=C2=A0 =C2=A0 =C2=A0I'm wondering if the series from Aleksanda= r Markovic, "linux-user:
> >=C2=A0 =C2=A0 =C2=A0Support signal passing for targets having more= signals than host" [1]
> >=C2=A0 =C2=A0 =C2=A0can fix the problem in a better way?
> >
> >
> > That patch[1] (which I'll refer to as the MUX patch to avoid = confusion)
> > does not directly fix the issue addressed by this patch (re-wirin= g
> > SIGRTMIN+1), but since it basically implements generic signal
> > multiplexing, it could be re-worked to address this case as well.= The
> > way it handles `si_code` spooks me a little bit. It could easily = be
> > broken by a kernel version change, and such a breakage could be h= ard to
> > detect or lead to surprising results. Other than that, it looks l= ike a
> > reasonable implementation.
> >
> > That said, overall, fixing the SIGRTMIN+1 issue using a more-gene= ric
> > signal-multiplexing mechanism doesn't seem *that* much better= to me. It
> > adds a lot of complexity, and only saves a single signal (assumin= g glibc
> > doesn't add more reserved signals). The "big win" i= s additional
> > emulation features, like those introduced in MUX patch (being abl= e to
> > utilize signals outside of the host range). If having those featu= res in
> > QEMU warrants the additional complexity, then re-working this pat= ch
> > on-top of that infrastructure seems like a good idea.
> >
> > If the maintainers want to go down that route, then I would be ha= ppy to
> > re-work this patch utilizing the infrastructure from the MUX patc= h.
> > Unfortunately it will require non-trivial changes, so it may be b= est to
> > wait until that patch is merged. I could also provide a patch &qu= ot;on top
> > of" the MUX patch, if that's desired/more convenient. > >
> > Just one last note, if you do decide to merge the MUX patch, then= it
> > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the
> > multiplexing signal if possible, to avoid breaking go binaries. > >
>
> Personally, I prefer a solution that breaks nothing.
>
> Aleksandar, Milos,
>
> do you have an updated version of you series "Support signal pass= ing for
> targets having more signals than host"?
>

Milos is unfortunetely working on an entirely different project now, and ca= n't spare enough time to finish the series. I am also busy with other i= ssues, even though I would like very much this or equivalent solution to be= integrated. Alternatively, someone in the team may have time later this ye= ar, but I do not know that yet=C2=A0 - perhaps somebody else (Josh) can tak= e over the series?



Hello, all.
<= br>
From my side, status quo. Milos (who ironically works in the = office next to mine) expressed interest in modifying his solution to be in = accordance with what Peter said, says that this is doable, but requires a l= ot of meticulous work - however, he is too involved into his project for mo= nths to go. I am also involved in other things, and, furthermore, has less = background knowledge than Milos. That said, we in MIPS would like the solut= ion described by Peter as much as other platforms, if not more.
<= br>
All this taken into account, perhaps this can be a project fo= r Outreachy or Google Summer of Code, mentored by Peter?

The perhaps largest problem with that is that the person doing it wo= uld need some steep learning curve (on signals in general, and their treatm= ent in QEMU), that can take some significant time.

Yours,
Aleksandar
=C2=A0
Sincerely,
Aleksandar


> Thanks,
> Laurent
>
--000000000000a0471c05991cd070--