Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173AbdI0WCy (ORCPT ); Wed, 27 Sep 2017 18:02:54 -0400 Received: from fldsmtpe03.verizon.com ([140.108.26.142]:14404 "EHLO fldsmtpe03.verizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbdI0WCw (ORCPT ); Wed, 27 Sep 2017 18:02:52 -0400 From: "Levin, Alexander (Sasha Levin)" X-Host: ranger.odc.vzwcorp.com To: "Eric W. Biederman" CC: Michal Hocko , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , Steven Rostedt , "David S . Miller" Subject: Re: [PATCH] mm: kill kmemcheck again Thread-Topic: [PATCH] mm: kill kmemcheck again Thread-Index: AQHTN9whLxFbFlc7/0+HjBFdOy45aA== Date: Wed, 27 Sep 2017 22:01:12 +0000 Message-ID: <20170927220110.evzjjylk57s3b3we@sasha-lappy> References: <20170927112723.16862-1-alexander.levin@verizon.com> <20170927150207.swmcarc4lqlklohr@dhcp22.suse.cz> <20170927152445.pe5ah3hq5hwup75z@sasha-lappy> <878th0vyas.fsf@xmission.com> In-Reply-To: <878th0vyas.fsf@xmission.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: NeoMutt/20170113 (1.7.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <964CB5A25B4A0B4C91265DBBD370E5AC@vzwcorp.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v8RM35jK024601 Content-Length: 644 Lines: 22 On Wed, Sep 27, 2017 at 12:36:27PM -0500, Eric W. Biederman wrote: >"Levin, Alexander (Sasha Levin)" writes: > >> On Wed, Sep 27, 2017 at 05:02:07PM +0200, Michal Hocko wrote: >>>This is just too large to review manually. How have you generated the >>>patch? >> >> Manualy. Note that most of it (~95%) is the result of 'rm arch/x86/mm/kmemcheck'. >> >> Otherwise, I just removed all uses of __GFP_NOWARN/SLAB_NOWARN, and calls to >> various annotations throughout the code. > >Do you mean GFP_NOTRACK? GFP_NOWARN has a different meaning. uh, yes, thanks Eric! __GFP_NOTRACK and SLAB_NOTRACK. -- Thanks, Sasha