From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752337AbcHHOjS (ORCPT ); Mon, 8 Aug 2016 10:39:18 -0400 Received: from sf2.bxl.stone.is ([5.134.1.43]:52666 "EHLO sf2.bxl.stone.is" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751473AbcHHOjQ (ORCPT ); Mon, 8 Aug 2016 10:39:16 -0400 Subject: Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs To: Peter Zijlstra References: <20160803181128.GH6879@twins.programming.kicks-ass.net> <11007730-3fa5-139a-8091-655743894ae8@sandisk.com> <20160803213006.GA11712@redhat.com> <17b65ff9-215f-ab74-9f5f-15dbd308d054@sandisk.com> <20160804140938.GB24652@twins.programming.kicks-ass.net> <16207b90-2e6c-fe23-1b4b-3763e5cf0384@sandisk.com> <20160808102213.GA6879@twins.programming.kicks-ass.net> Cc: Oleg Nesterov , "mingo@kernel.org" , Andrew Morton , Johannes Weiner , Neil Brown , Michael Shaver , "linux-kernel@vger.kernel.org" From: Bart Van Assche Message-ID: <4091e252-18d9-1795-de63-9fbc678aa6b1@acm.org> Date: Mon, 8 Aug 2016 07:38:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <20160808102213.GA6879@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20160808143859.73885.95695@vz23.stone-is.net> X-PPP-Vhost: bartvanassche.be X-Filter-ID: s0sct1PQhAABKnZB5plbIYrcAt68paBzxGNV4bZScc8DDDH9IcRzs4ldqK5vEMwbuZt+PpRPW1h0 yigPev+a+04My0LQQXIC7WDzp/8ADWUIQz2cxljJb7ms0bCFiVtXgwfiwlJS3fIgwvVR/7BSsYYZ ZS/DUBLA5nGN6cIn1z8pJ2Of1uqA8+WT5qTjvvlss5U0Y49+nMAJFiEeEdi1vgTe9nn8VR14s5h+ 0qpOzM15vI6pca52VjV5mIKutFi31wz56qeWJ3BB0Hxpv7qfrqg9slDa3EWyobP9lCdq71LGQdeB NIkLb6r47afaw/CHvTczy/haGLcWXbgGoE7T4TNRwOn16CFHTLf0X2kQqdjjRTu2Con4TWLpnir6 GMmMkj/7UPepeOhzLgb/uTB8TRxwEiTVJqDh0qKoKsXx5lm6I1iyriV2A2m1VoIRnPESbQmlb7A0 siDumDORbwwbyUQQrwpjxsATYS3iDPyAk1SprYlvne0NUB5b+H12aIr4ZQto/8ClyGMzJ/Thfwv3 fWxpRT+/yJfbGSQNjNMQMxBVVph2J+swW3DdR0HfJWbCowbovTu16yD6VpKabSrkCMhbG1gYCKtX xQumUA+APcwjk453OKkvcBjntLt9yA3C1kaTYScAX7m/CcfAV6pSARqi9VsQBnxqzpq/g9h3DaxG /Dk1XHNFp7zRWsCE086BlDqVWd2Z2uH2gQiQda+kSC8NSf3BEp2jmvXkqbVcDkCNjCeoOQJFpRcT Y+xj0NaiyB2Iv44ISCaVZLyGUM3tARNyLCVwCaAZV9h+Ad5mAHTqf32HRAIXLxSxjQIuPQZem1eU ZOdE2Qn9jdxCpPSlrCIE3MzTAn7ag0WOiSkq5TY= X-Report-Abuse-To: spam@sf1.bxl.stone.is X-Originating-IP: 87.238.162.216 X-SpamExperts-Domain: stone.is X-SpamExperts-Username: 87.238.162.216 Authentication-Results: bxl.stone.is; auth=pass smtp.auth=87.238.162.216@stone.is X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/08/16 03:22, Peter Zijlstra wrote: > That would be the exact scenario I drew a picture of, no? I'm still > failing to see the hole there. > > Please draw a picture like that and illustrate the hole. Hi Peter, This is the sequence of which I think that it leads to the missed wakeup: Task 1 Task 2 Task 3 Task 4 lock_page() ... lock_page_killable() __lock_page_killable() __wait_on_bit_lock() bit_wait_io() io_schedule() ... lock_page() __lock_page() __wait_on_bit_lock() bit_wait_io() io_schedule() ... (signal delivery to task 2) try_to_wake_up(task2, ..., ...) (try_to_wake_up() returns 1) unlock_page() wake_up_page() __wake_up_bit() __wake_up(wq, TASK_NORMAL, 1, &key) __wake_up_common(wq, mode=TASK_NORMAL, nr_exclusive=1, 0, key) wake_bit_function() autoremove_wake_function() default_wake_function() try_to_wake_up() <- skips task 2 because task 3 already changed the task state of task 2 (autoremove_wake_function() does not do list_del_init(&wait->task_list)) bit_wait_io() returns -EINTR abort_exclusive_wait() is called by __wait_on_bit_lock() In the above sequence task 1 does not remove task 2 from the waitqueue because task 3 had already woken up task 2. The result is that when task 2 calls abort_exclusive_wait() that task 2 is still on the waitqueue. With the current implementation of abort_exclusive_wait() in the above scenario task 4 is not woken up although it should be woken up. Hence the patch that removes the "else" keyword from abort_exclusive_wait(). Bart.