On Wed, Dec 18, 2013 at 04:15:44PM -0600, Seth Jennings wrote: > This is the unexpected second patch to go with my previous post: > http://post-office.corp.redhat.com/archives/rhkernel-list/2013-December/msg01419.html > > RHBZ#: > ------ > RHEL7.0: https://bugzilla.redhat.com/show_bug.cgi?id=1019549 > RHEL6.6: https://bugzilla.redhat.com/show_bug.cgi?id=1044117 > RHEL6.5.z: https://bugzilla.redhat.com/show_bug.cgi?id=1044566 > > Upstream commit: ec67ad82814bee92251fd963bf01c7a173856555 > > Description > ---------- > This patch reverts and improves the fix done by upstream commit > c13f20ac48328b05cd3b8c19e31ed6c132b44b42 aka RHEL7 commit > 2228939116d89e7c182987c5d86a93323eec1bd4. > > These two patches should be applied in series, even though the > second reverts the first to maintain consistency with upstream > commits. > Same as the other patch. Acked-by: Don Zickus <dzickus@xxxxxxxxxx> > Brew > ------ > https://brewweb.devel.redhat.com/taskinfo?taskID=6755949 (includes both patches) > > Upstream description > ------------ > In a recent patch: > commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 > Author: Michael Neuling <mikey@xxxxxxxxxxx> > powerpc/signals: Mark VSX not saved with small contexts > > We fixed an issue but an improved solution was later discussed after the patch > was merged. > > Firstly, this patch doesn't handle the 64bit signals case, which could also hit > this issue (but has never been reported). > > Secondly, the original patch isn't clear what MSR VSX should be set to. The > new approach below always clears the MSR VSX bit (to indicate no VSX is in the > context) and sets it only in the specific case where VSX is available (ie. when > VSX has been used and the signal context passed has space to provide the > state). > > This reverts the original patch and replaces it with the improved solution. It > also adds a 64 bit version. > > Signed-off-by: Michael Neuling <mikey@xxxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> > --- > arch/powerpc/kernel/signal_32.c | 16 +++++++--------- > arch/powerpc/kernel/signal_64.c | 6 ++++++ > 2 files changed, 13 insertions(+), 9 deletions(-) > > diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c > index 8deb21c..92bba96 100644 > --- a/arch/powerpc/kernel/signal_32.c > +++ b/arch/powerpc/kernel/signal_32.c > @@ -444,6 +444,12 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame, > #endif /* CONFIG_ALTIVEC */ > if (copy_fpr_to_user(&frame->mc_fregs, current)) > return 1; > + > + /* > + * Clear the MSR VSX bit to indicate there is no valid state attached > + * to this context, except in the specific case below where we set it. > + */ > + msr &= ~MSR_VSX; > #ifdef CONFIG_VSX > /* > * Copy VSR 0-31 upper half from thread_struct to local > @@ -456,15 +462,7 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame, > if (copy_vsx_to_user(&frame->mc_vsregs, current)) > return 1; > msr |= MSR_VSX; > - } else if (!ctx_has_vsx_region) > - /* > - * With a small context structure we can't hold the VSX > - * registers, hence clear the MSR value to indicate the state > - * was not saved. > - */ > - msr &= ~MSR_VSX; > - > - > + } > #endif /* CONFIG_VSX */ > #ifdef CONFIG_SPE > /* save spe registers */ > diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c > index 2fe6fc6..e056618 100644 > --- a/arch/powerpc/kernel/signal_64.c > +++ b/arch/powerpc/kernel/signal_64.c > @@ -116,6 +116,12 @@ static long setup_sigcontext(struct sigcontext __user *sc, struct pt_regs *regs, > flush_fp_to_thread(current); > /* copy fpr regs and fpscr */ > err |= copy_fpr_to_user(&sc->fp_regs, current); > + > + /* > + * Clear the MSR VSX bit to indicate there is no valid state attached > + * to this context, except in the specific case below where we set it. > + */ > + msr &= ~MSR_VSX; > #ifdef CONFIG_VSX > /* > * Copy VSX low doubleword to local buffer for formatting, > -- > 1.8.3.1 > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html