Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1287878
| From | NeilBrown <nfbrown@novell.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers |
| Date | 2015-12-09 22:40 +0100 |
| Message-ID | <qDUCS-5lP-1@gated-at.bofh.it> (permalink) |
| References | <qASQW-1Dr-23@gated-at.bofh.it> <qBXbS-2b5-47@gated-at.bofh.it> <qDo0i-1f5-11@gated-at.bofh.it> <qDBqx-1qn-7@gated-at.bofh.it> <qDHFE-5pb-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Wed, Dec 09 2015, Peter Zijlstra wrote:
> On Wed, Dec 09, 2015 at 12:06:33PM +1100, NeilBrown wrote:
>> On Tue, Dec 08 2015, Peter Zijlstra wrote:
>>
>> >>
>> >
>> > *sigh*, so that patch was broken.. the below might fix it, but please
>> > someone look at it, I seem to have a less than stellar track record
>> > here...
>>
>> This new change seems to be more intrusive than should be needed.
>> Can't we just do:
>>
>>
>> __sched int bit_wait(struct wait_bit_key *word)
>> {
>> + long state = current->state;
>
> No, current->state can already be changed by this time.
Does that matter?
It can only have changed to TASK_RUNNING - right?
In that case signal_pending_state() will return 0 and the bit_wait() acts
as though the thread was woken up normally (which it was) rather than by
a signal (which maybe it was too, but maybe that happened just a tiny
bit later).
As long as signal delivery doesn't change ->state, we should be safe.
We should even be safe testing ->state *after* the call the schedule().
NeilBrown
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [BISECTED] rcu_sched self-detected stall since 3.17 Peter Zijlstra <peterz@infradead.org> - 2015-12-01 14:10 +0100
Re: [BISECTED] rcu_sched self-detected stall since 3.17 Vladimir Murzin <vladimir.murzin@arm.com> - 2015-12-02 10:10 +0100
[tip:locking/core] sched/wait: Fix signal handling in bit wait helpers tip-bot for Peter Zijlstra <tipbot@zytor.com> - 2015-12-04 13:00 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Peter Zijlstra <peterz@infradead.org> - 2015-12-08 11:50 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers NeilBrown <nfbrown@novell.com> - 2015-12-09 02:10 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Peter Zijlstra <peterz@infradead.org> - 2015-12-09 08:50 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers NeilBrown <nfbrown@novell.com> - 2015-12-09 22:40 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Peter Zijlstra <peterz@infradead.org> - 2015-12-10 14:20 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Paul Turner <pjt@google.com> - 2015-12-11 12:40 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Peter Zijlstra <peterz@infradead.org> - 2015-12-11 12:50 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Vladimir Murzin <vladimir.murzin@arm.com> - 2015-12-11 13:00 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Jan Stancek <jstancek@redhat.com> - 2015-12-11 14:10 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Peter Zijlstra <peterz@infradead.org> - 2015-12-11 14:30 +0100
Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers Vladimir Murzin <vladimir.murzin@arm.com> - 2015-12-11 19:00 +0100
csiph-web