From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D46AC433EF for ; Tue, 29 Mar 2022 22:05:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235800AbiC2WGn (ORCPT ); Tue, 29 Mar 2022 18:06:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235689AbiC2WGl (ORCPT ); Tue, 29 Mar 2022 18:06:41 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 38D9235DCD for ; Tue, 29 Mar 2022 15:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648591496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IBLVNEPOUf5WmMPDsR6Y4RldMomDgegBLpjKSzD4JRA=; b=JLHV1TI5dOZ/MWOs/vk6MHKAZPjdI113aN/CSiVGSWI22mHerM5KOmTJXt1six4jHUHo7e tkYXCcq5z+JfczSZNnnbBaYqBeIG9L8z/2UF42U94ujbSaBbUVJz5VOMJwUBce17+i/2fT +kCs+PyPekonz0VaIvarXcQq0GgIT2g= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-629-ZmXwXS_eOV-9d7RzHXXpYg-1; Tue, 29 Mar 2022 18:04:55 -0400 X-MC-Unique: ZmXwXS_eOV-9d7RzHXXpYg-1 Received: by mail-wr1-f69.google.com with SMTP id 15-20020adf808f000000b00203e488fa4eso5354224wrl.3 for ; Tue, 29 Mar 2022 15:04:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IBLVNEPOUf5WmMPDsR6Y4RldMomDgegBLpjKSzD4JRA=; b=fLri+k49/yULhLG+lWBYjjM9QXZTF3KtLC/maQvzeaXfzqWHhoL/+F2oLrtomAuCVb vIZLq2bNPvZYpQA4HXzHBNmm3PtSmWxJv1WDsLIm8okqQ4JvzZrU03/2lSJoRNM30FZU 1b7ECdpmWrkHz1Z5313xq5hQhquiroj6z+bikDuPvyhGwg0YJ/UhT3LjV8ZJ8AZtooC+ WAfwS+ji3N/vX7bGH8NEfzUddvIxVxm4uAMbib0WHMtNGxOZ4dPcGlxFVzaIXfb/2TTU VIShuxUYlFsEnpXWnt90bJSlot/ayWGGc9ZBUjipUgYXD1YWmfZieCchyupbaoI/8nmN vXkw== X-Gm-Message-State: AOAM533KZOCOkpJxWK74oVkwd5x5lpib4kyuKhoTHkH1IzMgLjLsIpnU EH1QJyJ0p5qUaBuYj8/qi/grW9DMPXLfpa3x79GAFd0D9OOOYZcEz3kJYXgJdUhEVKNGRChLLgs Ae0epBOwbYqaisjcTCu0XlHCe X-Received: by 2002:a05:6000:1848:b0:204:e90:cb55 with SMTP id c8-20020a056000184800b002040e90cb55mr33430809wri.58.1648591493929; Tue, 29 Mar 2022 15:04:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZklsWDLtlBufF6gMqI6XIA4yF+Av43mfXR6BICacO/J+twKmWzR7EUSvOK/qjb3IJxAX0yw== X-Received: by 2002:a05:6000:1848:b0:204:e90:cb55 with SMTP id c8-20020a056000184800b002040e90cb55mr33430788wri.58.1648591493646; Tue, 29 Mar 2022 15:04:53 -0700 (PDT) Received: from redhat.com ([2.52.9.207]) by smtp.gmail.com with ESMTPSA id j16-20020a05600c191000b0038ca3500494sm5309811wmq.27.2022.03.29.15.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 15:04:53 -0700 (PDT) Date: Tue, 29 Mar 2022 18:04:48 -0400 From: "Michael S. Tsirkin" To: Thomas Gleixner Cc: Jason Wang , virtualization , linux-kernel , Marc Zyngier , Peter Zijlstra , Stefano Garzarella , Keir Fraser , "Paul E. McKenney" Subject: Re: Message-ID: <20220329175426-mutt-send-email-mst@kernel.org> References: <20220325050947-mutt-send-email-mst@kernel.org> <20220325060659-mutt-send-email-mst@kernel.org> <20220328015757-mutt-send-email-mst@kernel.org> <20220328062452-mutt-send-email-mst@kernel.org> <87fsn1f96e.ffs@tglx> <20220329100859-mutt-send-email-mst@kernel.org> <87v8vweie2.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v8vweie2.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > We are trying to fix the driver since at the moment it does not > > have the dev->ok flag at all. > > > > And I suspect virtio is not alone in that. > > So it would have been nice if there was a standard flag > > replacing the driver-specific dev->ok above, and ideally > > would also handle the case of an interrupt triggering > > too early by deferring the interrupt until the flag is set. > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > enable_irq instead of dev->ok = true, except > > - it doesn't work with affinity managed IRQs > > - it does not work with shared IRQs > > > > So using dev->ok as you propose above seems better at this point. > > Unless there is a big enough amount of drivers which could make use of a > generic mechanism for that. > > >> If any driver does this in the wrong order, then the driver is > >> broken. > > > > I agree, however: > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > 113 > > $ git grep -l request_irq drivers/net/|wc -l > > 397 > > > > I suspect there are more drivers which in theory need the > > synchronize_irq dance but in practice do not execute it. > > That really depends on when the driver requests the interrupt, when > it actually enables the interrupt in the device itself This last point does not matter since we are talking about protecting against buggy/malicious devices. They can inject the interrupt anyway even if driver did not configure it. > and how the > interrupt service routine works. > > So just doing that grep dance does not tell much. You really have to do > a case by case analysis. > > Thanks, > > tglx I agree. In fact, at least for network the standard approach is to request interrupts in the open call, virtio net is unusual in doing it in probe. We should consider changing that. Jason? -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 19FBAC433F5 for ; Tue, 29 Mar 2022 22:05:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A172A41942; Tue, 29 Mar 2022 22:05:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8kXGCNoouuY; Tue, 29 Mar 2022 22:05:00 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id E477240224; Tue, 29 Mar 2022 22:04:59 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id C19A9C002C; Tue, 29 Mar 2022 22:04:59 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E0143C0012 for ; Tue, 29 Mar 2022 22:04:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DA19640245 for ; Tue, 29 Mar 2022 22:04:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLeOZf3OO5V4 for ; Tue, 29 Mar 2022 22:04:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id B9C0640224 for ; Tue, 29 Mar 2022 22:04:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648591496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IBLVNEPOUf5WmMPDsR6Y4RldMomDgegBLpjKSzD4JRA=; b=JLHV1TI5dOZ/MWOs/vk6MHKAZPjdI113aN/CSiVGSWI22mHerM5KOmTJXt1six4jHUHo7e tkYXCcq5z+JfczSZNnnbBaYqBeIG9L8z/2UF42U94ujbSaBbUVJz5VOMJwUBce17+i/2fT +kCs+PyPekonz0VaIvarXcQq0GgIT2g= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-210-2WNn7TBfPDq9gAWSLcjHYA-1; Tue, 29 Mar 2022 18:04:55 -0400 X-MC-Unique: 2WNn7TBfPDq9gAWSLcjHYA-1 Received: by mail-wr1-f71.google.com with SMTP id i27-20020adfa51b000000b00205c997f177so1318451wrb.21 for ; Tue, 29 Mar 2022 15:04:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IBLVNEPOUf5WmMPDsR6Y4RldMomDgegBLpjKSzD4JRA=; b=d+zCSmKiIZmrCjZOI3dVU0Iwo2giPcnk4rJigG3dJyGWgxwCoQ0OJFfSpVNVompfx2 WH8jzi4wohaR5q1FgDPyv+rIZ44cYHl19WsHX2ZRi4jW/lkHNd7LDp/mtl//oJd5XVkm zAmQiYFICknvLlwFG1THDjn+Wymg5QsmRgJAEGLdXXpma1j889g9+X5CQAAUoc64Rf2J ee1QjVQj4Z8jY2GBF5USB4ebPxrnO/7Ei/xbteu9qa70j9kO6I8Pvp+Ub7tJIyR0DYgk kAmBu3ZVnhIRhr58rHa/P4zerIiyX9TxkhSh2intVQBq6+hQ7Dztpr7ti0dRLeb4s/yS GQjQ== X-Gm-Message-State: AOAM532TvJky7O+16tOhym4ljx+yaYDjNm06TwpX0wLmOBeJeYzIIVcW CZKxDv4OAciGIt4cdrzvGao4L5iihPh9bH5DHcqPm0frff92vRljqf3hSHfQ6sq/qr7n8GLUQ5G CS8HastOqkONiHxjmfOv6P/054kHRkOQUXBuPJy0Uog== X-Received: by 2002:a05:6000:1848:b0:204:e90:cb55 with SMTP id c8-20020a056000184800b002040e90cb55mr33430807wri.58.1648591493928; Tue, 29 Mar 2022 15:04:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZklsWDLtlBufF6gMqI6XIA4yF+Av43mfXR6BICacO/J+twKmWzR7EUSvOK/qjb3IJxAX0yw== X-Received: by 2002:a05:6000:1848:b0:204:e90:cb55 with SMTP id c8-20020a056000184800b002040e90cb55mr33430788wri.58.1648591493646; Tue, 29 Mar 2022 15:04:53 -0700 (PDT) Received: from redhat.com ([2.52.9.207]) by smtp.gmail.com with ESMTPSA id j16-20020a05600c191000b0038ca3500494sm5309811wmq.27.2022.03.29.15.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 15:04:53 -0700 (PDT) Date: Tue, 29 Mar 2022 18:04:48 -0400 From: "Michael S. Tsirkin" To: Thomas Gleixner Subject: Re: Message-ID: <20220329175426-mutt-send-email-mst@kernel.org> References: <20220325050947-mutt-send-email-mst@kernel.org> <20220325060659-mutt-send-email-mst@kernel.org> <20220328015757-mutt-send-email-mst@kernel.org> <20220328062452-mutt-send-email-mst@kernel.org> <87fsn1f96e.ffs@tglx> <20220329100859-mutt-send-email-mst@kernel.org> <87v8vweie2.ffs@tglx> MIME-Version: 1.0 In-Reply-To: <87v8vweie2.ffs@tglx> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mst@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Cc: "Paul E. McKenney" , Peter Zijlstra , Marc Zyngier , Keir Fraser , linux-kernel , virtualization X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > We are trying to fix the driver since at the moment it does not > > have the dev->ok flag at all. > > > > And I suspect virtio is not alone in that. > > So it would have been nice if there was a standard flag > > replacing the driver-specific dev->ok above, and ideally > > would also handle the case of an interrupt triggering > > too early by deferring the interrupt until the flag is set. > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > enable_irq instead of dev->ok = true, except > > - it doesn't work with affinity managed IRQs > > - it does not work with shared IRQs > > > > So using dev->ok as you propose above seems better at this point. > > Unless there is a big enough amount of drivers which could make use of a > generic mechanism for that. > > >> If any driver does this in the wrong order, then the driver is > >> broken. > > > > I agree, however: > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > 113 > > $ git grep -l request_irq drivers/net/|wc -l > > 397 > > > > I suspect there are more drivers which in theory need the > > synchronize_irq dance but in practice do not execute it. > > That really depends on when the driver requests the interrupt, when > it actually enables the interrupt in the device itself This last point does not matter since we are talking about protecting against buggy/malicious devices. They can inject the interrupt anyway even if driver did not configure it. > and how the > interrupt service routine works. > > So just doing that grep dance does not tell much. You really have to do > a case by case analysis. > > Thanks, > > tglx I agree. In fact, at least for network the standard approach is to request interrupts in the open call, virtio net is unusual in doing it in probe. We should consider changing that. Jason? -- MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization