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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91BF0C55ABD for ; Fri, 13 Nov 2020 16:25:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D7D3220797 for ; Fri, 13 Nov 2020 16:25:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lwHPFmdE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7D3220797 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F5176B007D; Fri, 13 Nov 2020 11:25:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A1D46B0080; Fri, 13 Nov 2020 11:25:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E11286B0081; Fri, 13 Nov 2020 11:25:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id B0E7D6B007D for ; Fri, 13 Nov 2020 11:25:40 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5072A1EE6 for ; Fri, 13 Nov 2020 16:25:40 +0000 (UTC) X-FDA: 77479920840.28.gate11_59006d527310 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 0EFD36D62 for ; Fri, 13 Nov 2020 16:25:40 +0000 (UTC) X-HE-Tag: gate11_59006d527310 X-Filterd-Recvd-Size: 6474 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Nov 2020 16:25:39 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id c20so8022087pfr.8 for ; Fri, 13 Nov 2020 08:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MnQ23HCE0ZI7qhFXn6nl37F0XxyVN9I61UA+Y02bRi8=; b=lwHPFmdEWRvcdri67q/6P2FbJENUCnCnPl8sdwmtlDeJ1JXCKfT/6wEudf3CYb9+S1 0scBTx6ykcEoSBUCbLFzZVLJiJYcxpwE2VECv5KPea1B6YMbg4SIYMlqffdKPO3jjL74 a5Q+MHdbniSkaZZwWle6qR8Tlx6Q7d9DsTBU5KINBjJR8Y0XCsZW+e8YtwMU+CoU6ACf cTOmhMkldrbsEZ1aI4Or9hIveA6kti+3wJe3FUT7w2nEMZP0I6tgYuO3pzMeluD7m99Z WbycrDv+DXOzkbsYHecxKzfVOOocCcXr4UHxobvgCVeZWYaKB7AMz5OvSbUVQ0ybWAau HzoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=MnQ23HCE0ZI7qhFXn6nl37F0XxyVN9I61UA+Y02bRi8=; b=axwVQFP3RxGI5FNIs1BQozaOVyIEcza5WWRYfmf4wMPYkEZ7QLfRE1C5Nixys76ymT w/AOvHLvrh91Xqc9/6fIC/P1AwYOC6zi/sMq9FLSBFxqo/vdOzYdv2qv8/wnnkBpYte0 WRtuF1rgrwRRlSgbspHIO60VQK4yDqjT61sr82iESPGvde8UD0d1S/bTEr94YQ2zlEC5 ZRYVi/IFgIrJ74qBuHMSkmdHwYq305R/DJiEUW4gFewGmOf3H8V288L7Q/mdS28foY96 tpMXZfU6UbSIshPtA2p6rYBc8yJZ2uGDXKthrsZDsbJp1OrerqTSghJWEiw5aWpMsSN4 JOvg== X-Gm-Message-State: AOAM5315zyD3K5uBDKVNFxhzbp7LAEY1JYzY6qMTU4OMfSC8PyWJbAoH 2ibZFoVJ7u2yOzryS9HI++w= X-Google-Smtp-Source: ABdhPJz+FPzyF4yVbx++2H21xVfP1XR4cB7Li4tsy6vuvvX+vAmSDkShcU+ZR5QhQTk5cPovnPB0tg== X-Received: by 2002:a17:90b:784:: with SMTP id l4mr3906651pjz.56.1605284733023; Fri, 13 Nov 2020 08:25:33 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id e10sm9993725pfh.38.2020.11.13.08.25.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Nov 2020 08:25:31 -0800 (PST) Date: Fri, 13 Nov 2020 08:25:29 -0800 From: Minchan Kim To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm , "Aneesh Kumar K . V" , Harish Sriram , stable@vger.kernel.org Subject: Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range" Message-ID: <20201113162529.GA2378542@google.com> References: <20201105170249.387069-1-minchan@kernel.org> <20201106175933.90e4c8851010c9ce4dd732b6@linux-foundation.org> <20201107083939.GA1633068@google.com> <20201112200101.GC123036@google.com> <20201112144919.5f6b36876f4e59ebb4a99d6d@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201112144919.5f6b36876f4e59ebb4a99d6d@linux-foundation.org> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 12, 2020 at 02:49:19PM -0800, Andrew Morton wrote: > On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote: > > > > > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > > > Hi Andrew, > > > > > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > > > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > > > > > > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > > > > > > > > > While I was doing zram testing, I found sometimes decompression failed > > > > > since the compression buffer was corrupted. With investigation, > > > > > I found below commit calls cond_resched unconditionally so it could > > > > > make a problem in atomic context if the task is reschedule. > > > > > > > > > > Revert the original commit for now. > > > > How should we proceed this problem? > > > > (top-posting repaired - please don't). > > Well, we don't want to reintroduce the softlockup reports which > e47110e90584a2 fixed, and we certainly don't want to do that on behalf > of code which is using the unmap_kernel_range() interface incorrectly. > > So I suggest either > > a) make zs_unmap_object() stop doing the unmapping from atomic context or It's not easy since the path already hold several spin_locks as well as per-cpu context. I could pursuit the direction but it takes several steps to change entire locking scheme in the zsmalloc, which will take time(we couldn't leave zsmalloc broken until then) and hard to land on stable tree. > > b) figure out whether the vmalloc unmap code is *truly* unsafe from > atomic context - perhaps it is only unsafe from interrupt context, > in which case we can rework the vmalloc.c checks to reflect this, or I don't get the point. I assume your suggestion would be "let's make the vunmap code atomic context safe" but how could it solve this problem? The point from e47110e90584a2 was softlockup could be triggered if vunamp deal with large mapping so need *explict reschedule* point for CONFIG_PREEMPT_VOLUNTARY. However, CONFIG_PREEMPT_VOLUNTARY doesn't consider peempt count so even though we could make vunamp atomic safe to make a call under spin_lock: spin_lock(&A); vunmap vunmap_pmd_range cond_resched <- bang Below options would have same problem, too. Let me know if I misunderstand something. > > c) make the vfree code callable from all contexts. Which is by far > the preferred solution, but may be tough. > > > Or maybe not so tough - if the only problem in the vmalloc code is the > use of mutex_trylock() from irqs then it may be as simple as switching > to old-style semaphores and using down_trylock(), which I think is > irq-safe. > > However old-style semaphores are deprecated. A hackyish approach might > be to use an rwsem always in down_write mode and use > down_write_trylock(), which I think is also callable from interrrupt > context. > > But I have a feeling that there are other reasons why vfree shouldn't > be called from atomic context, apart from the mutex_trylock-in-irq > issue.