From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com> To: Arnd Bergmann <arnd@arndb.de>, "Russell King - ARM Linux" <linux@arm.linux.org.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>, Nicolas Pitre <nicolas.pitre@linaro.org>, linaro-toolchain@lists.linaro.org Subject: Re: try_to_freeze() called with IRQs disabled on ARM Date: Thu, 1 Sep 2011 15:41:22 +0200 [thread overview] Message-ID: <OF2C5ADB6A.65B1BE36-ONC12578FE.00493A67-C12578FE.004B3315@de.ibm.com> (raw) In-Reply-To: <201108261644.26329.arnd@arndb.de> Arnd Bergmann <arnd@arndb.de> wrote on 08/26/2011 04:44:26 PM: > On Thursday 25 August 2011, Russell King - ARM Linux wrote: > > > > Arnd, can you test this to make sure your gdb test case still works, and > > Mark, can you test this to make sure it fixes your problem please? > > Hi Russell, > > The patch in question was not actually from me but from Ulrich Weigand, > so he's probably the right person to test your patch. > I'm forwarding it in full to Uli for reference. Hi Arnd, hi Russell, sorry for the late reply, I've just returned from vacation today ... I've not yet run the test, but just from reading through the patch it seems that this will at least partially re-introduce the problem my original patch was trying to fix. The situation here is about GDB performing an "inferior function call", e.g. via the GDB "call" command. To do so, GDB will: 0. [ Have gotten control of the target process via some ptrace intercept previously, and then ... ] 1. Save the register state 2. Create a dummy frame on the stack and set up registers (PC, SP, argument registers, ...) as appropriate for a function call 3. Restart via PTRACE_CONTINUE [ ... at this point, the target process runs the function until it returns to a breakpoint instruction and GDB gets control again via another ptrace intercept ... ] 4. Restore the register state saved in [1.] 5. At some later point, continue the target process [at its original location] with PTRACE_CONTINUE The problem now occurs if at point [0.] the target process just happened to be blocked in a restartable system call. For this sequence to then work as expected, two things have to happen: - at point [3.], the kernel must *not* attempt to restart a system call, even though it thinks we're stopped in a restartable system call - at point [5.], the kernel now *must* restart the originally interrupted system call, even though it thinks we're stopped at some breakpoint, and not within a system call My patch achieved both these goals, while it would seem your patch only solves the first issue, not the second one. In fact, since any interaction with ptrace will always cause the TIF_SYS_RESTART flag to be *reset*, and there is no way at all to *set* it, there doesn't appear to be any way for GDB to achive that second goal. [ With my patch, that second goal was implicitly achieved by the fact that at [1.] GDB would save a register state that already corresponds to the way things should be for restarting the system call. When that register set is then restored in [4.], restart just happens automatically without any further kernel intervention. ] One way to fix this might be to make the TIF_SYS_RESTART flag itself visible to ptrace, so the GDB could save/restore it along with the rest of the register set; this would be similar to how that problem is handled on other platforms. However, there doesn't appear to be an obvious place for the flag in the ptrace register set ... Bye, Ulrich
WARNING: multiple messages have this Message-ID (diff)
From: Ulrich.Weigand@de.ibm.com (Ulrich Weigand) To: linux-arm-kernel@lists.infradead.org Subject: try_to_freeze() called with IRQs disabled on ARM Date: Thu, 1 Sep 2011 15:41:22 +0200 [thread overview] Message-ID: <OF2C5ADB6A.65B1BE36-ONC12578FE.00493A67-C12578FE.004B3315@de.ibm.com> (raw) In-Reply-To: <201108261644.26329.arnd@arndb.de> Arnd Bergmann <arnd@arndb.de> wrote on 08/26/2011 04:44:26 PM: > On Thursday 25 August 2011, Russell King - ARM Linux wrote: > > > > Arnd, can you test this to make sure your gdb test case still works, and > > Mark, can you test this to make sure it fixes your problem please? > > Hi Russell, > > The patch in question was not actually from me but from Ulrich Weigand, > so he's probably the right person to test your patch. > I'm forwarding it in full to Uli for reference. Hi Arnd, hi Russell, sorry for the late reply, I've just returned from vacation today ... I've not yet run the test, but just from reading through the patch it seems that this will at least partially re-introduce the problem my original patch was trying to fix. The situation here is about GDB performing an "inferior function call", e.g. via the GDB "call" command. To do so, GDB will: 0. [ Have gotten control of the target process via some ptrace intercept previously, and then ... ] 1. Save the register state 2. Create a dummy frame on the stack and set up registers (PC, SP, argument registers, ...) as appropriate for a function call 3. Restart via PTRACE_CONTINUE [ ... at this point, the target process runs the function until it returns to a breakpoint instruction and GDB gets control again via another ptrace intercept ... ] 4. Restore the register state saved in [1.] 5. At some later point, continue the target process [at its original location] with PTRACE_CONTINUE The problem now occurs if at point [0.] the target process just happened to be blocked in a restartable system call. For this sequence to then work as expected, two things have to happen: - at point [3.], the kernel must *not* attempt to restart a system call, even though it thinks we're stopped in a restartable system call - at point [5.], the kernel now *must* restart the originally interrupted system call, even though it thinks we're stopped at some breakpoint, and not within a system call My patch achieved both these goals, while it would seem your patch only solves the first issue, not the second one. In fact, since any interaction with ptrace will always cause the TIF_SYS_RESTART flag to be *reset*, and there is no way at all to *set* it, there doesn't appear to be any way for GDB to achive that second goal. [ With my patch, that second goal was implicitly achieved by the fact that at [1.] GDB would save a register state that already corresponds to the way things should be for restarting the system call. When that register set is then restored in [4.], restart just happens automatically without any further kernel intervention. ] One way to fix this might be to make the TIF_SYS_RESTART flag itself visible to ptrace, so the GDB could save/restore it along with the rest of the register set; this would be similar to how that problem is handled on other platforms. However, there doesn't appear to be an obvious place for the flag in the ptrace register set ... Bye, Ulrich
next prev parent reply other threads:[~2011-09-01 13:41 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-23 15:19 try_to_freeze() called with IRQs disabled on ARM Mark Brown 2011-08-23 15:19 ` Mark Brown 2011-08-23 15:43 ` Russell King - ARM Linux 2011-08-23 15:43 ` Russell King - ARM Linux 2011-08-23 22:08 ` Rafael J. Wysocki 2011-08-23 22:08 ` Rafael J. Wysocki 2011-08-23 21:51 ` Rafael J. Wysocki 2011-08-23 21:51 ` Rafael J. Wysocki 2011-08-23 21:53 ` Tejun Heo 2011-08-23 21:53 ` Tejun Heo 2011-08-23 22:00 ` Russell King - ARM Linux 2011-08-23 22:00 ` Russell King - ARM Linux 2011-08-23 22:08 ` Tejun Heo 2011-08-23 22:08 ` Tejun Heo 2011-08-23 22:13 ` Russell King - ARM Linux 2011-08-23 22:13 ` Russell King - ARM Linux 2011-08-23 22:17 ` Tejun Heo 2011-08-23 22:17 ` Tejun Heo 2011-08-23 22:35 ` Tejun Heo 2011-08-23 22:35 ` Tejun Heo 2011-08-24 23:15 ` Rafael J. Wysocki 2011-08-24 23:15 ` Rafael J. Wysocki 2011-08-25 12:14 ` Russell King - ARM Linux 2011-08-25 12:14 ` Russell King - ARM Linux 2011-08-25 12:17 ` Tejun Heo 2011-08-25 12:17 ` Tejun Heo 2011-08-25 12:25 ` Russell King - ARM Linux 2011-08-25 12:25 ` Russell King - ARM Linux 2011-08-25 12:35 ` Tejun Heo 2011-08-25 12:35 ` Tejun Heo 2011-08-25 13:04 ` Russell King - ARM Linux 2011-08-25 13:04 ` Russell King - ARM Linux 2011-08-25 13:09 ` Tejun Heo 2011-08-25 13:09 ` Tejun Heo 2011-08-25 14:55 ` Russell King - ARM Linux 2011-08-25 14:55 ` Russell King - ARM Linux 2011-08-26 14:44 ` Arnd Bergmann 2011-08-26 14:44 ` Arnd Bergmann 2011-09-01 13:41 ` Ulrich Weigand [this message] 2011-09-01 13:41 ` Ulrich Weigand 2011-09-01 14:00 ` Russell King - ARM Linux 2011-09-01 14:00 ` Russell King - ARM Linux 2011-09-02 14:47 ` Ulrich Weigand 2011-09-02 14:47 ` Ulrich Weigand 2011-09-02 17:22 ` Russell King - ARM Linux 2011-09-02 17:22 ` Russell King - ARM Linux 2011-09-02 17:40 ` Ulrich Weigand 2011-09-02 17:40 ` Ulrich Weigand 2011-09-02 17:48 ` Russell King - ARM Linux 2011-09-02 17:48 ` Russell King - ARM Linux 2011-09-16 10:31 ` Martin Schwidefsky 2011-09-16 10:31 ` Martin Schwidefsky 2011-09-27 17:45 ` Ulrich Weigand 2011-09-27 17:45 ` Ulrich Weigand 2011-08-30 20:58 ` Mark Brown 2011-08-30 20:58 ` Mark Brown 2011-08-30 21:10 ` Russell King - ARM Linux 2011-08-30 21:10 ` Russell King - ARM Linux 2012-06-26 16:39 ` Mandeep Singh Baines 2012-06-26 16:39 ` Mandeep Singh Baines 2012-06-26 17:16 ` Russell King - ARM Linux 2012-06-26 17:16 ` Russell King - ARM Linux 2011-08-23 22:13 ` Rafael J. Wysocki 2011-08-23 22:13 ` Rafael J. Wysocki 2011-08-25 11:37 ` Mark Brown 2011-08-25 11:37 ` Mark Brown
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=OF2C5ADB6A.65B1BE36-ONC12578FE.00493A67-C12578FE.004B3315@de.ibm.com \ --to=ulrich.weigand@de.ibm.com \ --cc=arnd@arndb.de \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=linaro-toolchain@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=nicolas.pitre@linaro.org \ --cc=rjw@sisk.pl \ --cc=tj@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.