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=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 A8EB2C43441 for ; Fri, 23 Nov 2018 13:30:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 76BC320672 for ; Fri, 23 Nov 2018 13:30:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76BC320672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2410041AbeKXAOw (ORCPT ); Fri, 23 Nov 2018 19:14:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:43454 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388620AbeKXAOw (ORCPT ); Fri, 23 Nov 2018 19:14:52 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CABB4AD7D; Fri, 23 Nov 2018 13:30:38 +0000 (UTC) Date: Fri, 23 Nov 2018 14:30:38 +0100 From: Michal Hocko To: Daniel Vetter Cc: Linux Kernel Mailing List , Linux MM , intel-gfx , dri-devel , Andrew Morton , Christian =?iso-8859-1?Q?K=F6nig?= , David Rientjes , Jerome Glisse , Paolo Bonzini , Daniel Vetter Subject: Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail Message-ID: <20181123133038.GQ8625@dhcp22.suse.cz> References: <20181122165106.18238-1-daniel.vetter@ffwll.ch> <20181122165106.18238-2-daniel.vetter@ffwll.ch> <20181123111557.GG8625@dhcp22.suse.cz> <20181123123057.GK4266@phenom.ffwll.local> <20181123124358.GJ8625@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 23-11-18 14:15:11, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko wrote: > > On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > > > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > > > > Just a bit of paranoia, since if we start pushing this deep into > > > > > callchains it's hard to spot all places where an mmu notifier > > > > > implementation might fail when it's not allowed to. > > > > > > > > What does WARN give you more than the existing pr_info? Is really > > > > backtrace that interesting? > > > > > > Automated tools have to ignore everything at info level (there's too much > > > of that). I guess I could do something like > > > > > > if (blockable) > > > pr_warn(...) > > > else > > > pr_info(...) > > > > > > WARN() is simply my goto tool for getting something at warning level > > > dumped into dmesg. But I think the pr_warn with the callback function > > > should be enough indeed. > > > > I wouldn't mind s@pr_info@pr_warn@ > > Well that's too much, because then it would misfire in the oom > testcase, where failing is ok (desireble even, we want to avoid > blocking after all). So needs to be a switch (or else we need to > filter it in results, and that's a bit a maintenance headache from a > CI pov). I thought the failure should be rare enough that warning about them can be actually useful. E.g. in the oom case we can live with the failure because we want to release _some_ memory but know about a callback that prevents us to go the full way might be interesting. But I do not really feel strongly about this. I find WARN a bit abuse because the trace is unlikely going to help us much. If you want to make a verbosity depending on the blockable context then I will surely not stand in the way. -- Michal Hocko SUSE Labs