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_spa...@quicinc.com> wrote:
> > On 2/15/2023 3:27 AM, Richard Weinberger wrote:
> > > ----- Ursprüngliche Mail -----
> > > > Von: "Srinivasarao Pathipati" <quic_c_spa...@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
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
