linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Evan Teran <eteran@alum.rit.edu>,
	Jan Kratochvil <jan.kratochvil@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Bug 16061 - single stepping in a signal handler can cause the single step flag to get "stuck"
Date: Wed, 2 Jun 2010 22:07:20 +0200	[thread overview]
Message-ID: <20100602200720.GA28062@redhat.com> (raw)
In-Reply-To: <20100602192318.GA26735@redhat.com>

sorry for noise, forgot to mention...

On 06/02, Oleg Nesterov wrote:
>
> However, what I am thinking about is the more "clever" change (it
> passed ptrace-tests).
>
> Do you think it can be correct? I am asking because I never understood
> the TIF_SINGLESTEP/TIF_FORCED_TF interaction. But otoh, shouldn't
> TIF_FORCED_TF + X86_EFLAGS_TF always imply TIF_SINGLESTEP? at least
> in handle_signal().
>
> IOW, help! To me, the patch below is also cleanup. But only if you think
> it can fly ;)

and it is not clear to me if we should keep this code

	/*
	 * Clear TF when entering the signal handler, but
	 * notify any tracer that was single-stepping it.
	 * The tracer may want to single-step inside the
	 * handler too.
	 */
	regs->flags &= ~X86_EFLAGS_TF;

in handle_signal(). If TF was set by us, it was cleared by
user_disable_single_step(). Otherwise, why should we clear it if
the tracer did set_flags(X86_EFLAGS_TF) ?

Oleg.

> --- 34-rc1/arch/x86/kernel/signal.c~BZ16061_MAYBE_FIX	2010-06-02 21:11:07.000000000 +0200
> +++ 34-rc1/arch/x86/kernel/signal.c	2010-06-02 21:11:48.000000000 +0200
> @@ -682,6 +682,7 @@ static int
>  handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka,
>  	      sigset_t *oldset, struct pt_regs *regs)
>  {
> +	bool stepping;
>  	int ret;
>  
>  	/* Are we from a system call? */
> @@ -706,13 +707,10 @@ handle_signal(unsigned long sig, siginfo
>  		}
>  	}
>  
> -	/*
> -	 * If TF is set due to a debugger (TIF_FORCED_TF), clear the TF
> -	 * flag so that register information in the sigcontext is correct.
> -	 */
> -	if (unlikely(regs->flags & X86_EFLAGS_TF) &&
> -	    likely(test_and_clear_thread_flag(TIF_FORCED_TF)))
> -		regs->flags &= ~X86_EFLAGS_TF;
> +	stepping = test_thread_flag(TIF_SINGLESTEP);
> +	if (stepping)
> +		// do this before setup_sigcontext()
> +		user_disable_single_step(current);
>  
>  	ret = setup_rt_frame(sig, ka, info, oldset, regs);
>  
> @@ -748,8 +746,7 @@ handle_signal(unsigned long sig, siginfo
>  	recalc_sigpending();
>  	spin_unlock_irq(&current->sighand->siglock);
>  
> -	tracehook_signal_handler(sig, info, ka, regs,
> -				 test_thread_flag(TIF_SINGLESTEP));
> +	tracehook_signal_handler(sig, info, ka, regs, stepping);
>  
>  	return 0;
>  }


  reply	other threads:[~2010-06-02 20:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 19:23 Bug 16061 - single stepping in a signal handler can cause the single step flag to get "stuck" Oleg Nesterov
2010-06-02 20:07 ` Oleg Nesterov [this message]
2010-06-06 16:38 ` [PATCH 0/1] ptrace: x86: stepping in a signal handler leaks X86_EFLAGS_TF Oleg Nesterov
2010-06-06 16:39   ` [PATCH 1/1] " Oleg Nesterov
2010-06-16  2:31 ` Bug 16061 - single stepping in a signal handler can cause the single step flag to get "stuck" Roland McGrath
2010-06-16 19:56   ` Oleg Nesterov
2010-06-16 20:53     ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100602200720.GA28062@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=eteran@alum.rit.edu \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).