Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3472315ybc; Thu, 21 Nov 2019 08:49:42 -0800 (PST) X-Google-Smtp-Source: APXvYqwNzk10jovTKiBoQ4/qJJxXoMkddohR6iAHMcyvoBnjxT7MQ81JnVoODXkblCWZTZqsTzCv X-Received: by 2002:a2e:6a10:: with SMTP id f16mr8792003ljc.100.1574354982176; Thu, 21 Nov 2019 08:49:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574354982; cv=none; d=google.com; s=arc-20160816; b=WBHu6TGebvz4vymAuYf8sd2RMefh56Kv6Aq/7NJkjion2iUM51E8RTGVR7QCagH7w2 8m/ieyFNkoG2GvAapO34f3Fur+eACfodGZlYUl+ZmUkOaLGTXs8JKSjyUw1LUNl+G/Ih 1GLRmPor8cM8ru8UqRhuAI/dao5DhLblX3AbS8zIT1CFJdyKPLKWnsA3uGZguHuUwu3n 8lC+LEjObBXcZoEGbre8cYeY+x4MncULpr+dUvkzkW5GYUvralZMPSOGRrOCzENVUxfr UuNxlQXS4hxhFHZmaCWYFLbSXMlqKOYJdfr1jQXW9SAU76mcv9OP7rHnnKVVdXXPr1EA hxzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=0Qn10hWiy8/uuGhAalu5dcn/1mOJukydQej1fnpUxnI=; b=J3O3EulFWDKIwJLHxyFWM2VFAy3PjXM3bnEIIhssoygaQjOV8TOdEeMIf5OtE1tyJY Wuz2DZfxse76OE7K3Mif5tUsbhQb3H+9mqFny9HuvTr8dYDyr4+LgQRi/Gthani+jnwp mzpcLUUlxP5OoYMahLH0hL1oYjBZEIAQW0SRuqNXxWhWaTVWd/l2lcKhMTGKJU/UZi6K XjNJAc4nKeyP+qsF8W9zySlbcAZKztkQV3Wr88aYlYeDLQQY299w8L3YL8xKGuGcQlWu 95fPco5Yo72RyMswIql9kVxW3sP/P74/l5kKLtFa6aj9AX4EgWXpWDTY46SObeulgfoC ZRTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PtWa9axG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s2si3001172edi.413.2019.11.21.08.49.17; Thu, 21 Nov 2019 08:49:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PtWa9axG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbfKUQrA (ORCPT + 99 others); Thu, 21 Nov 2019 11:47:00 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:51757 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726541AbfKUQq7 (ORCPT ); Thu, 21 Nov 2019 11:46:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574354818; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Qn10hWiy8/uuGhAalu5dcn/1mOJukydQej1fnpUxnI=; b=PtWa9axGY/iI8kLfNNo1nOSUTVzZA3g13C+aY36NpOCyOHYgg7j5YRVHUu5Gp/VmMOtkPj K/2dEC55qBKtV7xtZ2JcHUyO57X+gY2xk2i41naH4xd1YMu8DAv8D21c+XRfvj+RRgJc71 m0wDyKSF75BHV7Qet+c+qkowEm07ORo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-26-6h2M2xD7NiC0_q3MyI91Sg-1; Thu, 21 Nov 2019 11:46:54 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4899107ACCC; Thu, 21 Nov 2019 16:46:52 +0000 (UTC) Received: from suzdal.zaitcev.lan (ovpn-117-3.phx2.redhat.com [10.3.117.3]) by smtp.corp.redhat.com (Postfix) with ESMTP id F1DB310631CE; Thu, 21 Nov 2019 16:46:51 +0000 (UTC) Date: Thu, 21 Nov 2019 10:46:51 -0600 From: Pete Zaitcev To: Alan Stern Cc: syzbot , , , , , , Kernel development list , USB list , , , , zaitcev@redhat.com Subject: Re: possible deadlock in mon_bin_vma_fault Message-ID: <20191121104651.0d50d2bd@suzdal.zaitcev.lan> In-Reply-To: References: <20191121084842.095edf87@suzdal.zaitcev.lan> Organization: Red Hat, Inc. MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: 6h2M2xD7NiC0_q3MyI91Sg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Nov 2019 11:20:20 -0500 (EST) Alan Stern wrote: > On Thu, 21 Nov 2019, Pete Zaitcev wrote: >=20 > > Anyway... If you are looking at it too, what do you think about not usi= ng > > any locks in mon_bin_vma_fault() at all? Isn't it valid? I think I trie= d > > to be "safe", but it only uses things that are constants unless we're > > opening and closing; a process cannot make page faults unless it has > > some thing mapped; and that is only possible if device is open and stay= s > > open. Can you find a hole in this reasoning? =20 >=20 > I think you're right. But one thing concerns me: What happens if the=20 > same buffer is mapped by more than one process? Do you allow that? Yes, we allow 2 processes reading from mmap in the same time. They may miss events, but there should be no issue to the internal consistency of any pointers in usbmon, and no crashes or deadlocks. Also, we cannot prohibit that. Imagine a process that does open(), mmap(), fork()/clone(). -- Pete