From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753251AbcAEVHn (ORCPT <rfc822;w@1wt.eu>);
	Tue, 5 Jan 2016 16:07:43 -0500
Received: from mta02.ornl.gov ([128.219.177.12]:4630 "EHLO mta02.ornl.gov"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753624AbcAEUyS convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 5 Jan 2016 15:54:18 -0500
X-SG: RELAYLIST
X-IronPort-AV: E=Sophos;i="5.20,526,1444708800"; 
   d="scan'208";a="95322084"
From: "Simmons, James A." <simmonsja@ornl.gov>
To: "'Niranjan Dighe'" <niranjan.dighe@gmail.com>,
        "Dilger, Andreas" <andreas.dilger@intel.com>
CC: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "Patrick Boettcher" <patrick.boettcher@posteo.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Drokin, Oleg" <oleg.drokin@intel.com>,
        "Mike Rapoport" <mike.rapoport@gmail.com>,
        Matthew Tyler <matt.tyler@flashics.com>,
        "lustre-devel@lists.lustre.org" <lustre-devel@lists.lustre.org>
Subject: RE: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type
 mismatch reported by sparse
Thread-Topic: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type
 mismatch reported by sparse
Thread-Index: AQHRMqQ49jKEe+m8l0SP3xSMWS6Fgp7safLKgAEmwBA=
Date: Tue, 5 Jan 2016 20:54:16 +0000
Message-ID: <4a016e0876fd4e54ae77763be3667209@EXCHCS32.ornl.gov>
References: <20151209170813.GA12216@codebox>
 <20151221234443.GA11245@kroah.com>
	<CADCM0GL7M=-Em85rMa-L0mJK-TN=-fD1PWqvWRpYJkLXicZYUA@mail.gmail.com>
	<D29F1436.123ED7%andreas.dilger@intel.com>
 <CADCM0GJSpbansEjGRcqVX1H2jQUhOC2kNFxk_15Ffo-=VyGq=g@mail.gmail.com>
In-Reply-To: <CADCM0GJSpbansEjGRcqVX1H2jQUhOC2kNFxk_15Ffo-=VyGq=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.219.12.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>>>2. Is it OK to hardcode the appropriate gfp_t flags for the
>>>IOC_LIBCFS_MEMHOG, as the userspace
>>>seems to be taking the decision about the page allocation
>>>zone/strategy, is this what is intended?
>>
>> The memhog functionality is used to introduce memory pressure on a client
>> or server during operation to test error handling as well as memory
>> allocation deadlocks (e.g. GFP_KERNEL used where GFP_NOFS should be used).
>> There are other ways to do this in the kernel today, so all of the memhog
>> code could just be deleted I think.
>>
>> This looks like kportal_memhog_alloc(), kportal_memhog_free(),
>> IOC_LIBCFS_MEMHOG, and struct libcfs_device_userstate could be removed.
>>
>>
>> Cheers, Andreas
>>
>Thanks Andreas, I will send out a separate patch with the cleanup as
>you suggested.

I missed this email. I just sent the cleanup patches a bit ago.