From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754734AbaDSLoA (ORCPT ); Sat, 19 Apr 2014 07:44:00 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:42252 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbaDSLn5 (ORCPT ); Sat, 19 Apr 2014 07:43:57 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Date: Sat, 19 Apr 2014 13:43:37 +0200 Message-Id: <1397907821-29319-1-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series, and still not ready for merging (see at the end, TASK_SIZE and s390). If we increase the default limits for SHMMAX and SHMALL, integer overflows could happen: SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. on 32-bit, the limit is > 1 TB. --> 32-bit: 4 GB-1 segments are possible. Rounded up to full pages the actual allocated size is 0. --> patch 3 on 64-bit, this is 0x7fff ffff ffff ffff --> no chance for an overflow. - shmat: - find_vma_intersection does not handle overflows properly --> patch 1. - do_mmap_pgoff limits mappings to TASK_SIZE 3 GB on 32-bit (assuming x86) 47 bits on 64-bit (assuming x86) - do_mmap_pgoff checks for overflows: map 2 GB, starting from addr=2.5GB fails. SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> patch 2. And finally: Patch 4, increase the limits to ULONG_MAX Open points: - Better ideas to handle uapi: Is it worth the effort to get access to TASK_SIZE? I would say no. - Better ideas with regards to SHMALL? The values are probably large enough, but still arbitrary. - The TASK_SIZE definition for e.g. S390 differs: It's not a constant, instead it is the current task size for current. And it seems that the task size can change based on (virtual) memory pressure (s390_mmap_check()). For new namespaces, this might have interesting effects, i.e. this must be fixed. -- Manfred