From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id 1DA236B0005 for ; Tue, 30 Jan 2018 05:40:23 -0500 (EST) Received: by mail-io0-f197.google.com with SMTP id e186so10976104iof.9 for ; Tue, 30 Jan 2018 02:40:23 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0070.outbound.protection.outlook.com. [104.47.38.70]) by mx.google.com with ESMTPS id 21si1780762itu.74.2018.01.30.02.40.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 30 Jan 2018 02:40:22 -0800 (PST) Subject: Re: [RFC] Per file OOM badness References: <20180118170006.GG6584@dhcp22.suse.cz> <20180123152659.GA21817@castle.DHCP.thefacebook.com> <20180123153631.GR1526@dhcp22.suse.cz> <20180124092847.GI1526@dhcp22.suse.cz> <583f328e-ff46-c6a4-8548-064259995766@daenzer.net> <20180124110141.GA28465@dhcp22.suse.cz> <36b49523-792d-45f9-8617-32b6d9d77418@daenzer.net> <20180124115059.GC28465@dhcp22.suse.cz> <381a868c-78fd-d0d1-029e-a2cf4ab06d37@gmail.com> <20180130093145.GE25930@phenom.ffwll.local> <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <3026d8c5-9313-cb8b-91ef-09c02baf27db@amd.com> Date: Tue, 30 Jan 2018 11:40:06 +0100 MIME-Version: 1.0 In-Reply-To: <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: To: =?UTF-8?Q?Michel_D=c3=a4nzer?= , Michal Hocko , dri-devel@lists.freedesktop.org, Roman Gushchin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, amd-gfx@lists.freedesktop.org Am 30.01.2018 um 10:43 schrieb Michel DA?nzer: > [SNIP] >> Would it be ok to hang onto potentially arbitrary mmget references >> essentially forever? If that's ok I think we can do your process based >> account (minus a few minor inaccuracies for shared stuff perhaps, but no >> one cares about that). > Honestly, I think you and Christian are overthinking this. Let's try > charging the memory to every process which shares a buffer, and go from > there. My problem is that this needs to be bullet prove. For example imagine an application which allocates a lot of BOs, then calls fork() and let the parent process die. The file descriptor lives on in the child process, but the memory is not accounted against the child. Otherwise we would allow easy construction of deny of service problems. To avoid that I think we need to add something like new file_operations callbacks which informs a file descriptor that it is going to be used in a new process or stopped to be used in a process. Regards, Christian. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org