Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4768566ybi; Tue, 30 Jul 2019 07:50:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpgkBrfCzJQpNfUfukbkkvyOorG3iyM2a88qnxXtkSOvxmBbBGnwBviHSNVA4gNY+tY/Zm X-Received: by 2002:a17:902:403:: with SMTP id 3mr113492033ple.66.1564498229244; Tue, 30 Jul 2019 07:50:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564498229; cv=none; d=google.com; s=arc-20160816; b=zf6NwZlfs+qYTWeI6SmyS9XULsLP0dULVe5Rh4Bwwxv3naXMVENWK30VPHQt3+Mf7c rdLVFCZKbNDaW1zwb0MvP0TFz/01U4PJZiQahW+bzBUKaotySLfBlmZTjCyMM+GYtr08 F2FCXi5FLGzwo/Aryk5sQUNCr3sqYBGiAv/8/NqzJRTzWjWVlNMR+FYDDz/mwot6Ng2E e8mltipR38LbSCc6Deq2qaRHd5Rj9HgbDHigzm8AHw7jKEGikoT75Y1FEGe1sA2ov56e OLc8pxN8BeRjcxow0kbZdYrHymkCi6NU3MeqJ8ArtsR13MmiPMSGOm3/jnj4Zx5BOBnL S2CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=x6RPycPoRAsF1VkEPpu353GKcUnEMUI9BSmZo5qOVlU=; b=HHR09jxxzZt0+BgImiWsVWhPhc68DQevm+dvs6gbpkty2sAaW3sLaqLznG+AqKCnIQ DrEXBW1Nor7PN9WEkTc6mQtK/YTQn+zUxr0m9uJ2ewypgM9p5AEdAqSx/HwXoxYG9M9A iNOEwnSys9ZdnzCV94EhB20tunBJd2sNybBsOyFHMqF4F7gujpnikcBc9d87/7tFbW8m tDgJgzaIjMTF9GwBmQMdCc+ff1SSHG4Qn29rk3sO5cSBK9JxnMO/lcMk60ckreY7c11u nPwB3dio0irL7wk6eXqCB39EVHlG53vr5p1uX+J0+La0FeNCY0KY4+MNncXUHp3H44ST E0uQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 j17si23995241pgj.15.2019.07.30.07.50.13; Tue, 30 Jul 2019 07:50:29 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730802AbfG3ID6 (ORCPT + 99 others); Tue, 30 Jul 2019 04:03:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33776 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729810AbfG3ID6 (ORCPT ); Tue, 30 Jul 2019 04:03:58 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5026330C5843; Tue, 30 Jul 2019 08:03:57 +0000 (UTC) Received: from [10.72.12.185] (ovpn-12-185.pek2.redhat.com [10.72.12.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id D89B65D6A5; Tue, 30 Jul 2019 08:03:46 +0000 (UTC) Subject: Re: WARNING in __mmdrop From: Jason Wang To: "Michael S. Tsirkin" Cc: syzbot , aarcange@redhat.com, akpm@linux-foundation.org, christian@brauner.io, davem@davemloft.net, ebiederm@xmission.com, elena.reshetova@intel.com, guro@fb.com, hch@infradead.org, james.bottomley@hansenpartnership.com, jglisse@redhat.com, keescook@chromium.org, ldv@altlinux.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, luto@amacapital.net, mhocko@suse.com, mingo@kernel.org, namit@vmware.com, peterz@infradead.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk, wad@chromium.org References: <11802a8a-ce41-f427-63d5-b6a4cf96bb3f@redhat.com> <20190726074644-mutt-send-email-mst@kernel.org> <5cc94f15-b229-a290-55f3-8295266edb2b@redhat.com> <20190726082837-mutt-send-email-mst@kernel.org> <20190726094756-mutt-send-email-mst@kernel.org> <0792ee09-b4b7-673c-2251-e5e0ce0fbe32@redhat.com> <20190729045127-mutt-send-email-mst@kernel.org> <4d43c094-44ed-dbac-b863-48fc3d754378@redhat.com> <20190729104028-mutt-send-email-mst@kernel.org> <96b1d67c-3a8d-1224-e9f0-5f7725a3dc10@redhat.com> Message-ID: Date: Tue, 30 Jul 2019 16:03:45 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <96b1d67c-3a8d-1224-e9f0-5f7725a3dc10@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Tue, 30 Jul 2019 08:03:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/7/30 下午3:44, Jason Wang wrote: >>> >>> } >> Looks good but I'd like to think of a strategy/existing lock that let us >> block properly as opposed to spinning, that would be more friendly to >> e.g. the realtime patch. > > > Does it make sense to disable preemption in the critical section? Then > we don't need to block and we have a deterministic time spent on > memory accssors? Ok, touching preempt counter seems a little bit expensive in the fast path. Will try for blocking. Thanks