[Bug 46472] Linux kernel 4.19 breaks startup of BO2 due to change in PTRACE_POKEUSER hw breakpoint behavior

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=46472

--- Comment #34 from tjb <troyb at us.ibm.com> ---
(In reply to tjb from comment #31)
> (In reply to Anthony Jagers from comment #30)
> > Update, I have received a flurry of emails since I CC'ed the five
> > maintainers of the source file.
> > 
> > I'll just quote what two unnamed individuals have wrote.
> > 
> > > there's a post with simple test code showing what the fix aimed for:
> > >   https://lore.kernel.org/lkml/tip-9b3579fc6c6ac45502de1fa9a1fdf873805c2157@git.kernel.org/
> > >
> > > it might help narow down the potential issue in set_thread_context
> > 
> > Someone with access to the app will need to investigate what it's doing,
> > specifically how it's trying to set the debug registers and why the
> > values that it's setting are causing different behavior with that kernel
> > change. Getting an strace of the wineserver process would probably help,
> > or else adding printfs to all the PTRACE_PEEKUSER/POKEUSER calls in
> > server/ptrace.c.
> > 
> > _____________________________________________________________________________
> > __
> > 
> > Well that's something.
> 
> I tried intercepting the peek and poke calls in ptrace.c but it seems the
> program never gets there ... either pilot error on my part (someone should
> independently check), or some other library got affected by the kernel
> change (maybe even the Nvidia binary blob... but it works fine with other
> wine programs besides BO2 on 4.19 with the new breakpoint behavior).  Cue
> twilight zone jingle.

Instead of trying to pinpoint all wineserver ptrace calls I modified the kernel
hw_breakpoints.c function to add some diagnostics to the output to capture what
is going on.  The debug code is given below.  klogs for the cases where it
starts the game (using old breakpointlogic) and the case where it crashes with
an unhandled exception caught (new breakpoint logic) are attached to the bug
report.

/**
 * modify_user_hw_breakpoint - modify a user-space hardware breakpoint
 * @bp: the breakpoint structure to modify
 * @attr: new breakpoint attributes
 */
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr
*attr)
{
        int err;

        /*
         * modify_user_hw_breakpoint can be invoked with IRQs disabled and
hence it
         * will not be possible to raise IPIs that invoke __perf_event_disable.
         * So call the function directly after making sure we are targeting the
         * current task.
         */
        if (irqs_disabled() && bp->ctx && bp->ctx->task == current)
                perf_event_disable_local(bp);
        else
                perf_event_disable(bp);

        #if 1
        /* new logic : >= kernel 4.19 */
        printk("New logic modify breakpoint.  Callstack :\n");
        dump_stack();

        err = modify_user_hw_breakpoint_check(bp, attr, false);

        printk("Breakpoint modified err %d  disabled
%d\n",err,bp->attr.disabled);

        if (!bp->attr.disabled)
                perf_event_enable(bp);

        return err;
        #else

        printk("Old logic modify breakpoint.  Callstack :\n");
        dump_stack();

        /* old logic : <kernel 4.19 */
        if (!attr->disabled) {
            err = modify_user_hw_breakpoint_check(bp, attr, false);
            printk("Breakpoint modified err %d  disabled
%d\n",err,bp->attr.disabled);
            if (err)
               return err;
            perf_event_enable(bp);
            bp->attr.disabled=0;
            }
        else
           printk("Breakpoint disabled : not modified\n");

        return 0;
        #endif
}

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.