Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754570AbcJETXN (ORCPT ); Wed, 5 Oct 2016 15:23:13 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35314 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753129AbcJETXK (ORCPT ); Wed, 5 Oct 2016 15:23:10 -0400 Subject: Re: aio: questions with ioctx_alloc() and large num_possible_cpus() To: Benjamin LaHaise References: <20161005174146.GK23336@kvack.org> <737b5bf7-329e-c59d-7601-aea0f4ffbeab@linux.vnet.ibm.com> <20161005181741.GL23336@kvack.org> Cc: Kent Overstreet , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-kernel@vger.kernel.org From: Mauricio Faria de Oliveira Date: Wed, 5 Oct 2016 16:22:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161005181741.GL23336@kvack.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16100519-1523-0000-0000-000002341A3B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16100519-1524-0000-0000-000029040A26 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-05_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610050324 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 954 Lines: 25 Ben, On 10/05/2016 03:17 PM, Benjamin LaHaise wrote: > Anything's possible when a local user can run code. [snip] That > said, local users tend not to DoS themselves. Agree. I thought of something that could be particularly related to the aio implementation; but I guess there's nothing so special then. > [snip] It probably makes > sense to implement per-user limits rather than the current global limit, > and maybe even convert them to an rlimit to better fit in with the > available frameworks for managing these things. I see it would be a nice improvement, but unfortunately that's not a task that I can take at the moment. For now, the most I'm able to do is to continue to try to understand whether there's something we can do that may help the small nr_events case to be more on par with the large nr_events case.. or any other beginner-level fixes to the area. :) Thanks again, -- Mauricio Faria de Oliveira IBM Linux Technology Center