Received: by 10.223.164.202 with SMTP id h10csp3685652wrb; Tue, 28 Nov 2017 15:42:05 -0800 (PST) X-Google-Smtp-Source: AGs4zMb5Ow/PioFRjT/2P0qNNPjGQrXbzHbiWN2DcoMG5MUCOszO4NjJ9VhgrpJp+XKfwpo8cRn9 X-Received: by 10.99.115.26 with SMTP id o26mr818683pgc.233.1511912525240; Tue, 28 Nov 2017 15:42:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511912525; cv=none; d=google.com; s=arc-20160816; b=QrCM/so5ZUDupZtY8j4Q3oXDWgOSttVFXOLOmh3at8ccE8xCyOyKM/yIu1oJ9J4l5K PiRGEV+6cF/f8efBrTcYi/HW6e/gryPbnJtDzhfm4BkMDgS/s8wDeVrkNYsHoGJVg/B1 OC/61kkUYuHRBQArCF272Fungiwqo2oiDMJckcTMLeWlEcNK0JImaPUmOW70zGLVxUNz G5uIc3Jh/BlWJHsteHWO9Rk8IEY4KcAD0RI9GtIlwfDMHn8NY+qNB45hVOwEihT57k6P TyLApFEAmevmchtm9/QtjCcbrRUJW7pKqF5wfGFILvrqUyyKipGhQF2XBUX3da0bqd+l enAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=i7NjpDhnIaAwvvcBrbPM/+1apzhGkQOJwTx2uGlEsXI=; b=B5ur/a+5XheFgzAQjU966VBC9LoyE8dLaku+iwfGV+DW0XyMQB1zKuNq3yrlbMcM4k 0hjdP87q9M0tMT4nCIabpTvlHaaKiMmZ6Qx/mg5G0RuQIMydYxS7lNHZsOnKUHfwtpUS x466fTMvM9GAqloergoZVsk4LixgbdhYiUI3yD2UYa/V9upY+ekLj7JmMel692q1rrzy xuR6sZaLHKFm8IQZ8bVj4X236jjMwLMDiyBkUk2XkSLIIDdNj54HYVj/GNy7/1giiKpO E/9e4tHSTv3HbG56jOqCQA06zS2AysaAmlC2yoNbzbxsb7Su2E4V7BGM/WnR7Sk3c0mo eziQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yv4/pC4C; 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=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x11si226896plm.827.2017.11.28.15.41.54; Tue, 28 Nov 2017 15:42:05 -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=@gmail.com header.s=20161025 header.b=Yv4/pC4C; 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=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752681AbdK1XlP (ORCPT + 70 others); Tue, 28 Nov 2017 18:41:15 -0500 Received: from mail-it0-f53.google.com ([209.85.214.53]:35870 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148AbdK1XlN (ORCPT ); Tue, 28 Nov 2017 18:41:13 -0500 Received: by mail-it0-f53.google.com with SMTP id d16so1930988itj.1 for ; Tue, 28 Nov 2017 15:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i7NjpDhnIaAwvvcBrbPM/+1apzhGkQOJwTx2uGlEsXI=; b=Yv4/pC4C/ohXXpwxgAN2Usv7iApzd+/WJ43qIOF0v7bjkvFBIQMdrFYdavWtXV6ipU Hxy1pkdq+qprOFnjx2scMXL3Q8hEcRvO/kmzHXezan0h9CL1t/9gJlQFyGxJFs3hn/a5 gCkJIsM9nlj3QK2crpVj5QF0/YXZHm8Stwxx9BntJZ1KpzUb2kkuL5m+6NW2y0RWSYfO 6ddDRtWHAakmFxB5/mUEpHM5I827cdbty4PSEmYbpM3/WIVSUo0FEvC75EO2V6zsnGKA GQ9h80GYUp6g4joffRnSDLmym7Zep1XM9KPy99Kg9CrZRrXmgPkesMHLOizZvkRe5UFt QkCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i7NjpDhnIaAwvvcBrbPM/+1apzhGkQOJwTx2uGlEsXI=; b=gDZHfLjy5wWCqwSM7R2DQTRsFgOp43oMIbPquz5kQvqydk9L/p2mi29+aUIIWBol1k uZd/eXWPMem8zxUtOtEAoY1OXymCRo/F1KGMkgpgVXSIBugQpRI7Iq9V40vEOJeQRiHd 9TlNi3d2tp/xglAM9epq95dmfyIcoGvk0PFktcTXdtz05lf5NpyEPHGzWayZmo12w0by fxz/IAMz77zHKcZyN41GhdtSOEoFkySjTMf/hBej6DnCmk2YXkNY1zAVKumJ5GrDXbti qy6OenYeirVMNwzcu0mcoRS64k0Kl/f877VF6kD8ySf00ImYDjjTyB99UOdZwLMDMYBd Owrw== X-Gm-Message-State: AJaThX7qvatQ4WO96gWjH4sUydKFqxyQX+n2zCzU8RMplRzRRNAHTYfr JYJDNGKZKoa3p/lQkhddASwSl79Mw7O7pnUQdaE= X-Received: by 10.36.237.202 with SMTP id r193mr5075710ith.74.1511912472900; Tue, 28 Nov 2017 15:41:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.5.21 with HTTP; Tue, 28 Nov 2017 15:41:12 -0800 (PST) In-Reply-To: References: <1511841842-3786-1-git-send-email-zhouzhouyi@gmail.com> From: Zhouyi Zhou Date: Wed, 29 Nov 2017 07:41:12 +0800 Message-ID: Subject: Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache To: Dmitry Vyukov Cc: Andrey Ryabinin , Alexander Potapenko , kasan-dev , Linux-MM , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I will try to reestablish the environment, and design proof of concept of experiment. Cheers On Wed, Nov 29, 2017 at 1:57 AM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov wrote: >> On Tue, Nov 28, 2017 at 12:30 PM, Zhouyi Zhou wrote: >>> Hi, >>> By using perf top, qlist_move_cache occupies 100% cpu did really >>> happen in my environment yesterday, or I >>> won't notice the kasan code. >>> Currently I have difficulty to let it reappear because the frontend >>> guy modified some user mode code. >>> I can repeat again and again now is >>> kgdb_breakpoint () at kernel/debug/debug_core.c:1073 >>> 1073 wmb(); /* Sync point after breakpoint */ >>> (gdb) p quarantine_batch_size >>> $1 = 3601946 >>> And by instrument code, maximum >>> global_quarantine[quarantine_tail].bytes reached is 6618208. >> >> On second thought, size does not matter too much because there can be >> large objects. Quarantine always quantize by objects, we can't part of >> an object into one batch, and another part of the object into another >> object. But it's not a problem, because overhead per objects is O(1). >> We can push a single 4MB object and overflow target size by 4MB and >> that will be fine. >> Either way, 6MB is not terribly much too. Should take milliseconds to process. >> >> >> >> >>> I do think drain quarantine right in quarantine_put is a better >>> place to drain because cache_free is fine in >>> that context. I am willing do it if you think it is convenient :-) > > > Andrey, do you know of any problems with draining quarantine in push? > Do you have any objections? > > But it's still not completely clear to me what problem we are solving. From 1585333592996552869@xxx Tue Nov 28 17:58:50 +0000 2017 X-GM-THRID: 1585281151451498932 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread