[PATCH V1] um: Fix compilation warnings

[Johannes Berg]

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 at quicinc.com> wrote:
> > On 2/15/2023 3:27 AM, Richard Weinberger wrote:
> > > ----- Ursprüngliche Mail -----
> > > > Von: "Srinivasarao Pathipati" <quic_c_spathi at quicinc.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