On Mon, Jun 26, 2017 at 10:35:21AM +0100, Dave Martin wrote: > On Sun, Jun 25, 2017 at 06:05:44PM +0300, Yury Norov wrote: > > On Fri, Jun 23, 2017 at 10:07:39AM +0100, Dave Martin wrote: > > > ILP32 support uses the same struct sigcontext as the native ABI > > > (i.e., LP64), but a different layout for the rest of the signal > > > frame (since siginfo_t and ucontext_t are both ABI-dependent). > > > > > > Since the purpose of parse_user_sigframe() is really to parse > > > sigcontext and not the whole signal frame, the function does not > > > need to depend on the layout of rt_sigframe -- the only purpose of > > > the rt_sigframe pointer is for use as a base to measure the signal > > > frame size. > > > > > > So, this patch renames the function to parse_user_sigcontext() and > > > makes the sigframe base pointer generic. ABI-specific parsers that > > > share the same sigcontext definition can then call it. > > > > > > To minimise churn in this patch, the native LP64 parser is retained > > > under the old name, but becomes a call to parse_user_sigconext(). > > > It may make sense instead to fold this into its restore_sigframe(), > > > depending on how ILP32 support is integrated. > > > > > > Suggested-by: Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Dave Martin <Dave.Martin@xxxxxxx> > > > --- > > > > > > This patch depends on [1], which does not appear to be applied yet. > > > > > > [1] [PATCH] arm64: signal: Allow expansion of the signal frame http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/514699.html > > [...] > > FYI, [1] above is now merged in arm64 for-next/core, so we shouldn't > have dependency issues with this patch. > > > > +static int parse_user_sigframe(struct user_ctxs *user, > > > + struct rt_sigframe __user const *sf) > > > +{ > > > + return parse_user_sigcontext(user, &sf->uc.uc_mcontext, sf); > > > +} > > > + > > > > Hi Dave, > > > > Thank you. Seems this is what I need. Only one thing. We can #define > > parse_user_sigframe() as macro, and so bypass type control. > > The macro then will be used both by lp64 and ilp32 without any > > modification. > > For the reasons you already gave, parse_user_sigframe is probably not > the right name for such a macro. But it otherwise makes sense as an > interface. Does [2] look OK for you? Yes, looks good, thank you. > Unless you suggest otherwise, I don't plan to maintain or push this > patch -- I think it makes more sense for you to carry it in the ILP32 > series, since that's the only thing that needs it. I'll just add it to ilp32 series. Yury
