Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4532488ybc; Tue, 26 Nov 2019 10:21:28 -0800 (PST) X-Google-Smtp-Source: APXvYqwM776iv/7wglzbj8dikEDvR12uvBlHDvdfqZvncWURQlnixqTMek1w6gcMln2Rotxh6jfS X-Received: by 2002:a05:6402:714:: with SMTP id w20mr22788887edx.93.1574792488741; Tue, 26 Nov 2019 10:21:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574792488; cv=none; d=google.com; s=arc-20160816; b=KYEoCcw6M1QqJwmKdPigobBvU3V99SfREj888iW130Tjs4aDlqkl6UxCHjzS9wXmlW 3V++AJ7NVTQXYNMkb8uCi+h6P62R2CVqaXi6121kbaHlsZN+8hYRubT2j5LktBeW/t7r 9lHpUXgBmlt+OHz2CkAUdqlW8Dr2R3xdlUpSdVFBNCSSGoH9CMBBv9n56UFrufXRsZFk 3pGDEC4o394JdwFUf9UPSaRnpaiaz3JAhCMBT5J2umUBBzevQxcSDrQkRtmljU+2So5d AZS+oYXB+yMMyEBvnDKv88q3X3fS3gQaOb0VQ13QVlA41ZTaMXNmia3Xp/3KyQmr3XsU p4tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=9h7U+x++jdUZb4s45/RCLZWEaWGQ6wogzBkHa5vWa1c=; b=UvKCPHB+ro/HsMY7Csdul4AXhRJ5w3znpFWJ76iWJWwiQWm3rkRL3YdbDcTVmljqvR 83ycC5SNXjqWxBf92AB51G3Mz7dvxL8EIvz+KjEZSLxjj7NKgyO74JsqCLfXafwTJGFL 8YHGRkDTKhmEPy29sOEy35wF9k3Jn6PlznOs/Pt2sYYxj6SfqtFIYCycjTXsk53CA/To j0sDkZfuyB7eIogMRNXLVfuxyWPZQPrgdKcVVSpSJJ5PTO0YA9kWSwuynQ969580L7/1 w4ySqh86B6n2Ifq09HisA7KWw54q5iyWcgcA3E6mQrBti/KxBk3dNVWfhE3hwK62r/t8 5aFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=YtJgMBkM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l20si7576556ejx.389.2019.11.26.10.21.01; Tue, 26 Nov 2019 10:21:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=YtJgMBkM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726103AbfKZSRM (ORCPT + 99 others); Tue, 26 Nov 2019 13:17:12 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:45747 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725895AbfKZSRM (ORCPT ); Tue, 26 Nov 2019 13:17:12 -0500 Received: by mail-pf1-f194.google.com with SMTP id z4so9559874pfn.12 for ; Tue, 26 Nov 2019 10:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9h7U+x++jdUZb4s45/RCLZWEaWGQ6wogzBkHa5vWa1c=; b=YtJgMBkMNLBBUyohAKOr2QoA8hcEAC6cOCr86aCbV9SLFPrvzs48B0wVURW8hx7jwg S7NemHWmKB/ZO25Fr+7To27zSD3sPMLbnJzC6irFe7w4JHamjhZ2oHaPycvFYrEJ7lZV ytAItYERiAI4RUpXtGCh3g8asJbFtaabSeXn5YOfcCPIgQDF8krHH1U9+zIn15oI6ERB Om8HC9dbwRrWCSwWpRFwljfRTMEUbzi2Z2T5cJKbG/XMd8UGU3BuBuSiU9yMw/DYU9z8 uhkIobyyHdOhgEhC8QtWnKHLc2dgfY/oE44cyoxa+ZHufFpm2+U7CNBkUiMXRdoZWPRC OwIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9h7U+x++jdUZb4s45/RCLZWEaWGQ6wogzBkHa5vWa1c=; b=G+OTc9B9wRxC+bOgynuOWuDYhMK29Oh16w1frb60UazQunE/pbRza7FzJ7EH7p8Ojh UtjgJGETubp7nIpMEQCDrIwT5C6ObwoUHDYlXfCXzt8a9V/1qFPNm4Yri+AXL+ParA22 JGpiQpivyMEK+y7+rBN1M63Zuw1sCL0cxA8xQLJcgtxVn+1akOGfpyNy8FJ9A2RVvFN2 DkNGqr9tXYGyASN0WHNQeqLYHQjWicIHb80pyB+EUaJ7Fkkv7TkceCXQSkUdnd5I6YsU B/Fh+GyC9fYN4n5UjRLXUZ4Yk3cT8f3U4Z51+VRODHOjNNAhtesID317YIVglSZuIi1r Le2Q== X-Gm-Message-State: APjAAAUyVBQ69D2ICJ9287gppEE16SE0BMVXibBQsCYTt8cdmm10bP0M heHvJlZU0WM4CXCP9y8MAMeicaz4I+bWtA== X-Received: by 2002:a63:364d:: with SMTP id d74mr40556554pga.408.1574792229426; Tue, 26 Nov 2019 10:17:09 -0800 (PST) Received: from [192.168.1.188] ([66.219.217.79]) by smtp.gmail.com with ESMTPSA id q70sm4342162pjq.26.2019.11.26.10.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 10:17:08 -0800 (PST) Subject: Re: [PATCH] io-wq: fix handling of NUMA node IDs To: Jann Horn Cc: io-uring@vger.kernel.org, Andrew Morton , Michal Hocko , linux-kernel@vger.kernel.org References: <20191126181020.17593-1-jannh@google.com> From: Jens Axboe Message-ID: Date: Tue, 26 Nov 2019 11:17:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191126181020.17593-1-jannh@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/26/19 11:10 AM, Jann Horn wrote: > There are several things that can go wrong in the current code on NUMA > systems, especially if not all nodes are online all the time: > > - If the identifiers of the online nodes do not form a single contiguous > block starting at zero, wq->wqes will be too small, and OOB memory > accesses will occur e.g. in the loop in io_wq_create(). > - If a node comes online between the call to num_online_nodes() and the > for_each_node() loop in io_wq_create(), an OOB write will occur. > - If a node comes online between io_wq_create() and io_wq_enqueue(), a > lookup is performed for an element that doesn't exist, and an OOB read > will probably occur. > > Fix it by: > > - using nr_node_ids instead of num_online_nodes() for the allocation size; > nr_node_ids is calculated by setup_nr_node_ids() to be bigger than the > highest node ID that could possibly come online at some point, even if > those nodes' identifiers are not a contiguous block > - creating workers for all possible CPUs, not just all online ones > > This is basically what the normal workqueue code also does, as far as I can > tell. > > Signed-off-by: Jann Horn > --- > > Notes: > compile-tested only. > > While I think I probably got this stuff right, it might be good if > someone more familiar with the NUMA logic could give an opinion on this. > > An alternative might be to only allocate workers for online nodes, but > then we'd have to either fiddle together logic to create more workers > on demand or punt requests on newly-onlined nodes over to older nodes. > Both of those don't seem very nice to me. I don't think caring about not-online nodes in terms of savings is worth the trouble. I'll run this through the regular testing I have with no and 2 nodes, thanks. -- Jens Axboe