From patchwork Mon Jun 19 00:45:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Samuel Thibault X-Patchwork-Id: 71273 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E88C4385841A for ; Mon, 19 Jun 2023 00:45:53 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from sonata.ens-lyon.org (domu-toccata.ens-lyon.fr [140.77.166.138]) by sourceware.org (Postfix) with ESMTPS id D7A6C3858D32 for ; Mon, 19 Jun 2023 00:45:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D7A6C3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ens-lyon.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bounce.ens-lyon.org Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 441512010E; Mon, 19 Jun 2023 02:45:38 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrB5Rt6-uniT; Mon, 19 Jun 2023 02:45:38 +0200 (CEST) Received: from begin (lfbn-bor-1-1163-184.w92-158.abo.wanadoo.fr [92.158.138.184]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id 0CF5C2010B; Mon, 19 Jun 2023 02:45:37 +0200 (CEST) Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1qB31V-008jiI-1M; Mon, 19 Jun 2023 02:45:37 +0200 From: Samuel Thibault To: libc-alpha@sourceware.org Cc: Joe Simmons-Talbott , commit-hurd@gnu.org Subject: [hurd,commited] hurd: writev: Get rid of alloca Date: Mon, 19 Jun 2023 02:45:37 +0200 Message-Id: <20230619004537.2082339-1-samuel.thibault@ens-lyon.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Spam-Status: No, score=-13.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" From: Joe Simmons-Talbott Use a scratch_buffer rather than alloca to avoid potential stack overflows. Checked on i686-gnu and x86_64-linux-gnu Message-Id: <20230608155844.976554-1-josimmon@redhat.com> --- sysdeps/posix/writev.c | 37 ++++++++++++++----------------------- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/sysdeps/posix/writev.c b/sysdeps/posix/writev.c index 53e090c087..d4c3cf6f03 100644 --- a/sysdeps/posix/writev.c +++ b/sysdeps/posix/writev.c @@ -19,19 +19,13 @@ #include #include #include +#include #include #include #include #include -static void -ifree (char **ptrp) -{ - free (*ptrp); -} - - /* Write data pointed by the buffers described by VECTOR, which is a vector of COUNT 'struct iovec's, to file descriptor FD. The data is written in the order specified. @@ -53,22 +47,17 @@ __writev (int fd, const struct iovec *vector, int count) bytes += vector[i].iov_len; } - /* Allocate a temporary buffer to hold the data. We should normally - use alloca since it's faster and does not require synchronization - with other threads. But we cannot if the amount of memory - required is too large. */ - char *buffer; - char *malloced_buffer __attribute__ ((__cleanup__ (ifree))) = NULL; - if (__libc_use_alloca (bytes)) - buffer = (char *) __alloca (bytes); - else - { - malloced_buffer = buffer = (char *) malloc (bytes); - if (buffer == NULL) - /* XXX I don't know whether it is acceptable to try writing - the data in chunks. Probably not so we just fail here. */ - return -1; - } + /* Allocate a temporary buffer to hold the data. Use a scratch_buffer + since it's faster for small buffer sizes but can handle larger + allocations as well. */ + + struct scratch_buffer buf; + scratch_buffer_init (&buf); + if (!scratch_buffer_set_array_size (&buf, 1, bytes)) + /* XXX I don't know whether it is acceptable to try writing + the data in chunks. Probably not so we just fail here. */ + return -1; + char *buffer = buf.data; /* Copy the data into BUFFER. */ size_t to_copy = bytes; @@ -86,6 +75,8 @@ __writev (int fd, const struct iovec *vector, int count) ssize_t bytes_written = __write (fd, buffer, bytes); + scratch_buffer_free (&buf); + return bytes_written; } libc_hidden_def (__writev)