From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756109AbbFPGld (ORCPT ); Tue, 16 Jun 2015 02:41:33 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:38205 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753890AbbFPGlZ (ORCPT ); Tue, 16 Jun 2015 02:41:25 -0400 MIME-Version: 1.0 In-Reply-To: <20150615221946.GI18909@redhat.com> References: <1434388931-24487-1-git-send-email-aarcange@redhat.com> <1434388931-24487-6-git-send-email-aarcange@redhat.com> <20150615221946.GI18909@redhat.com> Date: Mon, 15 Jun 2015 20:41:24 -1000 X-Google-Sender-Auth: 2MiZjzIssy2pvRPn7U8jZtIZT48 Message-ID: Subject: Re: [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads From: Linus Torvalds To: Andrea Arcangeli Cc: "Huangpeng (Peter)" , Paolo Bonzini , qemu-devel@nongnu.org, Pavel Emelyanov , Hugh Dickins , Andrew Morton , "Dr. David Alan Gilbert" , Andres Lagar-Cavilla , Andy Lutomirski , linux-mm , Johannes Weiner , Rik van Riel , "Kirill A. Shutemov" , Linux Kernel Mailing List , zhang.zhanghailiang@huawei.com, Sanidhya Kashyap , Dave Hansen , Peter Feiner , Mel Gorman , KVM list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli wrote: > > Yes, it would leave the other blocked, how is it different from having > just 1 reader and it gets killed? Either is completely wrong. But the read() code can at least see that "I'm returning early due to a signal, so I'll wake up any other waiters". Poll simply *cannot* do that. Because by definition poll always returns without actually clearing the thing that caused the wakeup. So for "poll()", using exclusive waits is wrong very much by definition. For read(), you *can* use exclusive waits correctly, it just requires you to wake up others if you don't read all the data (either due to being killed by a signal, or because the read was incomplete). > If any qemu thread gets killed the thing is going to be noticeable, > there's no fault-tolerance-double-thread for anything. What does qemu have to do with anything? We don't implement kernel interfaces that are broken, and that can leave processes blocked when they shouldn't be blocked. We also don't implement kernel interfaces that only work with one program and then say "if that program is broken, it's not our problem". > I'm not saying doing wakeone is easy [...] Bullshit, Andrea. That's *exactly* what you said in the commit message for the broken patch that I complained about. And I quote: "Blocking reads can easily use exclusive wakeups. Poll in theory could too but there's no poll_wait_exclusive in common code yet" and I pointed out that your commit message was garbage, and that it's not at all as easy as you claim, and that your patch was broken, and your description was even more broken. The whole "poll cannot use exclsive waits" has _nothing_ to do with us not having "poll_wait_exclusive()". Poll *fundamentally* cannot use exclusive waits. Your commit message was garbage, and actively misleading. Don't make excuses. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by kanga.kvack.org (Postfix) with ESMTP id 607D56B0038 for ; Tue, 16 Jun 2015 02:41:25 -0400 (EDT) Received: by iecrd14 with SMTP id rd14so6862692iec.3 for ; Mon, 15 Jun 2015 23:41:25 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com. [2607:f8b0:4001:c05::230]) by mx.google.com with ESMTPS id g14si616341icn.23.2015.06.15.23.41.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 23:41:24 -0700 (PDT) Received: by igblz2 with SMTP id lz2so7531346igb.1 for ; Mon, 15 Jun 2015 23:41:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150615221946.GI18909@redhat.com> References: <1434388931-24487-1-git-send-email-aarcange@redhat.com> <1434388931-24487-6-git-send-email-aarcange@redhat.com> <20150615221946.GI18909@redhat.com> Date: Mon, 15 Jun 2015 20:41:24 -1000 Message-ID: Subject: Re: [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli Cc: "Huangpeng (Peter)" , Paolo Bonzini , qemu-devel@nongnu.org, Pavel Emelyanov , Hugh Dickins , Andrew Morton , "Dr. David Alan Gilbert" , Andres Lagar-Cavilla , Andy Lutomirski , linux-mm , Johannes Weiner , Rik van Riel , "Kirill A. Shutemov" , Linux Kernel Mailing List , zhang.zhanghailiang@huawei.com, Sanidhya Kashyap , Dave Hansen , Peter Feiner , Mel Gorman , KVM list On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli wrote: > > Yes, it would leave the other blocked, how is it different from having > just 1 reader and it gets killed? Either is completely wrong. But the read() code can at least see that "I'm returning early due to a signal, so I'll wake up any other waiters". Poll simply *cannot* do that. Because by definition poll always returns without actually clearing the thing that caused the wakeup. So for "poll()", using exclusive waits is wrong very much by definition. For read(), you *can* use exclusive waits correctly, it just requires you to wake up others if you don't read all the data (either due to being killed by a signal, or because the read was incomplete). > If any qemu thread gets killed the thing is going to be noticeable, > there's no fault-tolerance-double-thread for anything. What does qemu have to do with anything? We don't implement kernel interfaces that are broken, and that can leave processes blocked when they shouldn't be blocked. We also don't implement kernel interfaces that only work with one program and then say "if that program is broken, it's not our problem". > I'm not saying doing wakeone is easy [...] Bullshit, Andrea. That's *exactly* what you said in the commit message for the broken patch that I complained about. And I quote: "Blocking reads can easily use exclusive wakeups. Poll in theory could too but there's no poll_wait_exclusive in common code yet" and I pointed out that your commit message was garbage, and that it's not at all as easy as you claim, and that your patch was broken, and your description was even more broken. The whole "poll cannot use exclsive waits" has _nothing_ to do with us not having "poll_wait_exclusive()". Poll *fundamentally* cannot use exclusive waits. Your commit message was garbage, and actively misleading. Don't make excuses. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4kYp-0004li-RG for qemu-devel@nongnu.org; Tue, 16 Jun 2015 02:41:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4kYn-0004aC-Gm for qemu-devel@nongnu.org; Tue, 16 Jun 2015 02:41:27 -0400 Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:34635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4kYn-0004a2-9E for qemu-devel@nongnu.org; Tue, 16 Jun 2015 02:41:25 -0400 Received: by iebmu5 with SMTP id mu5so6895319ieb.1 for ; Mon, 15 Jun 2015 23:41:24 -0700 (PDT) MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <20150615221946.GI18909@redhat.com> References: <1434388931-24487-1-git-send-email-aarcange@redhat.com> <1434388931-24487-6-git-send-email-aarcange@redhat.com> <20150615221946.GI18909@redhat.com> Date: Mon, 15 Jun 2015 20:41:24 -1000 Message-ID: From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: Dave Hansen , zhang.zhanghailiang@huawei.com, KVM list , Pavel Emelyanov , Linux Kernel Mailing List , "Kirill A. Shutemov" , Hugh Dickins , "Huangpeng (Peter)" , qemu-devel@nongnu.org, Sanidhya Kashyap , linux-mm , Andres Lagar-Cavilla , Mel Gorman , Johannes Weiner , Paolo Bonzini , Andrew Morton , Andy Lutomirski , "Dr. David Alan Gilbert" , Peter Feiner On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli wrote: > > Yes, it would leave the other blocked, how is it different from having > just 1 reader and it gets killed? Either is completely wrong. But the read() code can at least see that "I'm returning early due to a signal, so I'll wake up any other waiters". Poll simply *cannot* do that. Because by definition poll always returns without actually clearing the thing that caused the wakeup. So for "poll()", using exclusive waits is wrong very much by definition. For read(), you *can* use exclusive waits correctly, it just requires you to wake up others if you don't read all the data (either due to being killed by a signal, or because the read was incomplete). > If any qemu thread gets killed the thing is going to be noticeable, > there's no fault-tolerance-double-thread for anything. What does qemu have to do with anything? We don't implement kernel interfaces that are broken, and that can leave processes blocked when they shouldn't be blocked. We also don't implement kernel interfaces that only work with one program and then say "if that program is broken, it's not our problem". > I'm not saying doing wakeone is easy [...] Bullshit, Andrea. That's *exactly* what you said in the commit message for the broken patch that I complained about. And I quote: "Blocking reads can easily use exclusive wakeups. Poll in theory could too but there's no poll_wait_exclusive in common code yet" and I pointed out that your commit message was garbage, and that it's not at all as easy as you claim, and that your patch was broken, and your description was even more broken. The whole "poll cannot use exclsive waits" has _nothing_ to do with us not having "poll_wait_exclusive()". Poll *fundamentally* cannot use exclusive waits. Your commit message was garbage, and actively misleading. Don't make excuses. Linus