From patchwork Fri Jan 5 13:24:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aurelien Jarno X-Patchwork-Id: 856042 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-88858-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="cIA0OXvJ"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zCllN1Wfhz9ryv for ; Sat, 6 Jan 2018 00:25:04 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references; q=dns; s=default; b=S6nhkGDy91cAz47ynWgGna1fDAi/9W6 rpy/0IVPIIMnbuQKiGWjOH/ijBQP4XXJWlqxGQgIJoCdjFb2OlQM8Wv8KS9tR5DY 9+EoNC6JygjdUPsWriQ6UH4ncakcmIletmhuXflUVUH6XU0Vt1kfR/g3J92gV8xk VZbzjLMKX/Ic= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references; s=default; bh=87eaVQ7RJri3u2hR/1s0CPy1wlM=; b=cIA0O XvJGdhaVfLln+KsrjkMmUmXHmueW9jI32+wpuM/571kOy0tcPr4TDqooQfkAAmMf hvnHjQKvpAQewA759OM7tEvVcW4YWAcUkFSebXgSoSWuh07HphUhYRc5VIP9UWAs kduIpGqnDzbUuDKUU5OGTYIF32akiP1zxpMBUo= Received: (qmail 101767 invoked by alias); 5 Jan 2018 13:24:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 97113 invoked by uid 89); 5 Jan 2018 13:24:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: hall.aurel32.net From: Aurelien Jarno To: libc-alpha@sourceware.org Cc: Aurelien Jarno Subject: [PATCH 3/4] prlimit: Translate old_rlimit from RLIM64_INFINITY to RLIM_INFINITY [BZ #22678] Date: Fri, 5 Jan 2018 14:24:28 +0100 Message-Id: <20180105132429.21118-4-aurelien@aurel32.net> In-Reply-To: <20180105132429.21118-1-aurelien@aurel32.net> References: <20180105132429.21118-1-aurelien@aurel32.net> prlimit called without a new value fails on 32-bit machines if any of the soft or hard limits are infinity. This is because prlimit does not translate old_rlimit from RLIM64_INFINITY to RLIM_INFINITY, but checks that the value returned by the prlimit64 syscall fits into a 32-bit value, like it is done for example in getrlimit. Note that on the other hand new_rlimit is correctly translated from RLIM_INFINITY to RLIM64_INFINITY before calling the syscall. This patch fixes that. Changelog: [BZ #22678] * sysdeps/unix/sysv/linux/prlimit.c (prlimit): Translate old_rlimit from RLIM64_INFINITY to RLIM_INFINITY. Reviewed-by: Adhemerval Zanella --- ChangeLog | 6 ++++++ sysdeps/unix/sysv/linux/prlimit.c | 15 +++++++++------ 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index fd0fc0bc71..53c3d62b2e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2018-01-05 Aurelien Jarno + + [BZ #22678] + * sysdeps/unix/sysv/linux/prlimit.c (prlimit): Translate + old_rlimit from RLIM64_INFINITY to RLIM_INFINITY. + 2018-01-05 Aurelien Jarno Adhemerval Zanella diff --git a/sysdeps/unix/sysv/linux/prlimit.c b/sysdeps/unix/sysv/linux/prlimit.c index 9db8e821b3..2fa0642c76 100644 --- a/sysdeps/unix/sysv/linux/prlimit.c +++ b/sysdeps/unix/sysv/linux/prlimit.c @@ -50,21 +50,24 @@ prlimit (__pid_t pid, enum __rlimit_resource resource, { /* The prlimit64 syscall is ill-designed for 32-bit machines. We have to provide a 32-bit variant since otherwise the LFS - system would not work. But what shall we do if the syscall - succeeds but the old values do not fit into a rlimit - structure? We cannot return an error because the operation - itself worked. Best is perhaps to return RLIM_INFINITY. */ + system would not work. The infinity value can be translated, + but otherwise what shall we do if the syscall succeeds but the + old values do not fit into a rlimit structure? We cannot return + an error because the operation itself worked. Best is perhaps + to return RLIM_INFINITY. */ old_rlimit->rlim_cur = old_rlimit64_mem.rlim_cur; if (old_rlimit->rlim_cur != old_rlimit64_mem.rlim_cur) { - if (new_rlimit == NULL) + if ((new_rlimit == NULL) + && (old_rlimit64_mem.rlim_cur != RLIM64_INFINITY)) return INLINE_SYSCALL_ERROR_RETURN_VALUE (EOVERFLOW); old_rlimit->rlim_cur = RLIM_INFINITY; } old_rlimit->rlim_max = old_rlimit64_mem.rlim_max; if (old_rlimit->rlim_max != old_rlimit64_mem.rlim_max) { - if (new_rlimit == NULL) + if ((new_rlimit == NULL) + && (old_rlimit64_mem.rlim_max != RLIM64_INFINITY)) return INLINE_SYSCALL_ERROR_RETURN_VALUE (EOVERFLOW); old_rlimit->rlim_max = RLIM_INFINITY; }