linux-kernel - Re: [PATCH V1] um: Fix compilation warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b4bacb46e3a18c1f8d66d25f946dae09ccfcdc4f.camel@sipsolutions.net>
Date:   Wed, 15 Feb 2023 09:13:36 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Srinivasarao Pathipati <quic_c_spathi@...cinc.com>
Cc:     Richard Weinberger <richard@....at>,
        anton ivanov <anton.ivanov@...bridgegreys.com>,
        linux-um <linux-um@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V1] um: Fix compilation warnings

On Wed, 2023-02-15 at 09:07 +0100, Geert Uytterhoeven wrote:
> Hi Srinivasarao,
> 
> On Wed, Feb 15, 2023 at 6:36 AM Srinivasarao Pathipati
> <quic_c_spathi@...cinc.com> wrote:
> > On 2/15/2023 3:27 AM, Richard Weinberger wrote:
> > > ----- Ursprüngliche Mail -----
> > > > Von: "Srinivasarao Pathipati" <quic_c_spathi@...cinc.com>
> > > > static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)
> > > > {
> > > > -    struct uml_pt_regs r;
> > > > +    struct uml_pt_regs *r;
> > > >      int save_errno = errno;
> > > > 
> > > > -    r.is_user = 0;
> > > > +    r = malloc(sizeof(struct uml_pt_regs));
> > > I fear this is not correct since malloc() is not async-signal safe.
> > 
> > Thanks Richard for quick response. Could you please suggest alternative
> > function of malloc() with async-signal safe.
> > 
> > if that is not possible Is there any other way to fix this warning? OR
> > do we need to live with that warning?
> 
> Does this limit actually apply to this file, which calls into the host OS?

Not really. Also, we know we have a signal stack that's large enough,
since we set it up ourselves:

                set_sigstack((void *) STUB_DATA, UM_KERN_PAGE_SIZE);

and it's a full page, so even the OS eating up some of that won't cause
us any trouble. We do have somewhat deep calls into do_IRQ() but those
really shouldn't use much stack space since they can (in non-UM kernels)
be called on top of arbitrary kernel stacks already.

> How come you even see this warning, as we have
> 
>     CFLAGS_signal.o += -Wframe-larger-than=4096
> 
> since commit 517f60206ee5d5f7 ("um: Increase stack frame size threshold
> for signal.c") in v5.11?
> 

Good question, I don't see it. However we probably should make that a
_bit_ smaller since we only have a page and still need to call do_IRQ()
and all.

johannes