Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4279287pxj; Tue, 25 May 2021 04:35:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVobWp4lOtukpRtHIEbojxL2ccaZu0Ur0Tr+9lU7U0EiScVjAn1Uz3b96JMU8s8c+ulS88 X-Received: by 2002:a02:7f57:: with SMTP id r84mr32359934jac.108.1621942503700; Tue, 25 May 2021 04:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621942503; cv=none; d=google.com; s=arc-20160816; b=hDy1uzCHNtCFKU8WknVKQFePR8dvPtQ4lg1F+YAkbepcr+3F8cQXF9ulgDnqcW+j49 cuBqpDF9VTE3VSXYxH1Q8e3KxB6/Wc+Gyq5rZnYu0YCxFsv7UIsYdShVuDBL/CehepDE xFintq4QVSpu3UXE081fMhWDd/hBYN6iBl9xz2/V7JS//tQq41ZwzkTKuNG+b3Ve2yYQ 5LiK+/76q1Qyl+0VNgsxBP3rNZPWrwPWYUVy7Awk4HmIaUPwPpTekFsyyb3pbVIwBife vvw9uXuIXDxOaP58Ky6frum9nB1JcKHoqyoIzISd4+dZN+zNSyHVp7MDiWcdfLn7mLqb 2Qag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=oE7Izv+5biF7dR+58IhhonpkCLqxPiBEZj9eGjFlRO0=; b=0u/lSF/rhI6azCU12yo3Vr3TXdaYCO4JSA49CVB7SNNipufCBJWMcAc85UHncKK6VC g/MAaXpm3WD9thjYPnZAjWwBSYahLFDFhxioWPRHIWeAnKh/zwbXyiES4AKh8rJfD20k Vw6bG6jrGvogEAhtl8o76ByzIkQpzuUF3ASCBuaIYWJivVYaWDHFUw0ahBGdyx8y/ZDj bBsfABKs3hztdUawvTdbbq1+hDzON7+a5jX9iOnC0d0vU0IEdNGac57RUTMYPt5XrY8a nbz6mt9y/iKVYFwh9d5bxMss/aCsYhNIcj5hZafa35M1/fIyw6mEpsR3KlV7/9pBP/vD 3npQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l21si15216267iow.25.2021.05.25.04.34.50; Tue, 25 May 2021 04:35:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231702AbhEYLfD (ORCPT + 99 others); Tue, 25 May 2021 07:35:03 -0400 Received: from outbound-smtp11.blacknight.com ([46.22.139.106]:33961 "EHLO outbound-smtp11.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231653AbhEYLeu (ORCPT ); Tue, 25 May 2021 07:34:50 -0400 Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp11.blacknight.com (Postfix) with ESMTPS id 018121C3D31 for ; Tue, 25 May 2021 12:33:18 +0100 (IST) Received: (qmail 9938 invoked from network); 25 May 2021 11:33:18 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.168]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 May 2021 11:33:18 -0000 Date: Tue, 25 May 2021 12:33:17 +0100 From: Mel Gorman To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , David Rientjes , Pekka Enberg , Joonsoo Kim , Sebastian Andrzej Siewior , Thomas Gleixner , Jesper Dangaard Brouer , Peter Zijlstra , Jann Horn Subject: Re: [RFC 02/26] mm, slub: allocate private object map for validate_slab_cache() Message-ID: <20210525113317.GM30378@techsingularity.net> References: <20210524233946.20352-1-vbabka@suse.cz> <20210524233946.20352-3-vbabka@suse.cz> <20210525101742.GK30378@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 25, 2021 at 12:36:52PM +0200, Vlastimil Babka wrote: > > Most callers of validate_slab_cache don't care about the return value > > except when the validate sysfs file is written. Should a simply > > informational message be displayed for -ENOMEM in case a writer to > > validate fails and it's not obvious it was because of an allocation > > failure? > > he other callers are all in the effectively dead resiliency_test() code, which > has meanwhile been replaced in mmotm by kunit tests meanwhile. But it's true > those don't check the results either for now. > Ok. > > It's a fairly minor concern so whether you add a message or not > > I think I'll rather fix up the tests. Or do you mean that -ENOMEM for a sysfs > write is also not enough and there should be a dmesg explanation for that case? > I mean the -ENOMEM for a sysfs write. While it's very unlikely, it might would explain an unexpected write failure. -- Mel Gorman SUSE Labs