[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141008222722.GJ7996@ZenIV.linux.org.uk>
Date: Wed, 8 Oct 2014 23:27:22 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Ley Foon Tan <lftan@...era.com>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
lftan.linux@...il.com, cltang@...esourcery.com
Subject: Re: [PATCH v4 04/29] nios2: Exception handling
> +Lsignal_return:
> + ANDI32 r1, r10, _TIF_SIGPENDING | _TIF_NOTIFY_RESUME
> + beq r1, r0, restore_all
> + mov r4, sp /* pt_regs */
> + SAVE_SWITCH_STACK
> + call do_notify_resume
> + beq r2, r0, no_work_pending
> + RESTORE_SWITCH_STACK
> + /* prepare restart syscall here without leaving kernel */
> + ldw r2, PT_R2(sp) /* reload syscall number in r2 */
> + ldw r4, PT_R4(sp) /* reload syscall arguments r4-r9 */
> + ldw r5, PT_R5(sp)
> + ldw r6, PT_R6(sp)
> + ldw r7, PT_R7(sp)
> + ldw r8, PT_R8(sp)
> + ldw r9, PT_R9(sp)
> + br local_restart /* restart syscall */
> +
> +no_work_pending:
> + RESTORE_SWITCH_STACK
> + br restore_all
Umm... Branch to no_work_pending will be usuall taken. How well does
branch predictor on that processor cope with such things?
Another thing is the point Richard made - multiple pending signals need to be
handled. IOW, that should be a branch to ret_from_exception, not restore_all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists