From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F7E0C3A59F for ; Fri, 16 Aug 2019 04:17:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25578206C2 for ; Fri, 16 Aug 2019 04:17:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="L4c36XAE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726437AbfHPERq (ORCPT ); Fri, 16 Aug 2019 00:17:46 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:32901 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726220AbfHPERp (ORCPT ); Fri, 16 Aug 2019 00:17:45 -0400 Received: by mail-wr1-f68.google.com with SMTP id u16so266578wrr.0; Thu, 15 Aug 2019 21:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gEuZ0oQvlc1hh0fzWt3HdqljZG+E0Tl/80jYC8+qyFg=; b=L4c36XAEfLn5DR9m82nrwS0IJpMOF7dsO5gY6LEoNm98X6lDb1sUutgfBkfYcbtdOo IPlNuny3JhRetWi0bC9mwRWnE+ZbGF0TKm2WV2a819FDD5tMFoyRL79HF8Sik9llMiwU c+z96vRmNLVxOZCFjVcxne+WdfcK9LHtNWyFq/nD+rghtyovDAACBHSo6LY03/dI9ocB SNT2S3M4QuEkk6YF8n99+EBBkVbPmRomsGXUEnEMrT/i80bUwG00WZhTI0QFwZ9avEJP 0x6pJglk8v4qpuUFJ02Z9Aft21XtrVYjRQK3Nr+dwLS5kf+HJmr9FnOfIwaRJpwS10Up rDpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gEuZ0oQvlc1hh0fzWt3HdqljZG+E0Tl/80jYC8+qyFg=; b=Lr4oZnH5ptHXQQ1nD8J+M2tgiSHQfJqTfEO/HV0wqJH2CEakVnpnP8/mrhnmpZf1ds xSPVzOH40A/6gZ1kke8XDpUGl41LTRSQaa76VJribv+6OaD6UexHARkNu5hSpGNrh0eH Hw6oVZL1OfoJjil7YT2qCqnHEE8XJDv8x2Ipg7bAxKKcvRXB82lSqjVyFqLM3ry9PAja MM4fIAsWqytOfsGYyz7fthTiiLopo0IFGb7pGMmHzwYmMQTVT9xWLhR2soRV+j49PiP0 r76I+ZpkvF92+R/9ayFp6JwW/daF6IEWpz6qR9rP6Fd+hNNdcufVxv8LilC7URZqZ6Wo 4f4A== X-Gm-Message-State: APjAAAWCgm0RYhYFh2jcKTplYKpsoD8kaIU5CwbBwIKf79RvzY51j+Lb tWZYPeNgKri4/FqxA5yP4NIvWvRJHCuJw610WXw= X-Google-Smtp-Source: APXvYqw3G/gjqF/Ef0gievuOoaEo2CmKMPOffL1prKRF+hPNNtI7ZzB8+W0WfRHdA0FbeHoo958/7AkNMylQYtN2New= X-Received: by 2002:adf:e4c6:: with SMTP id v6mr7628091wrm.315.1565929063662; Thu, 15 Aug 2019 21:17:43 -0700 (PDT) MIME-Version: 1.0 References: <20190816025417.28964-1-ming.lei@redhat.com> In-Reply-To: From: Ming Lei Date: Fri, 16 Aug 2019 12:17:31 +0800 Message-ID: Subject: Re: [PATCH V2] blk-mq: avoid sysfs buffer overflow by too many CPU cores To: Bart Van Assche Cc: Ming Lei , Jens Axboe , linux-block , stable , Mark Ray , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Aug 16, 2019 at 11:42 AM Bart Van Assche wrote: > > On 8/15/19 7:54 PM, Ming Lei wrote: > > It is reported that sysfs buffer overflow can be triggered in case > > of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in > > blk_mq_hw_sysfs_cpus_show(). > > > > So use cpumap_print_to_pagebuf() to print the info and fix the potential > > buffer overflow issue. > > > > Cc: stable@vger.kernel.org > > Cc: Mark Ray > > Cc: Greg KH > > Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queue map on driver load") > > Signed-off-by: Ming Lei > > --- > > block/blk-mq-sysfs.c | 15 +-------------- > > 1 file changed, 1 insertion(+), 14 deletions(-) > > > > diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c > > index d6e1a9bd7131..4d0d32377ba3 100644 > > --- a/block/blk-mq-sysfs.c > > +++ b/block/blk-mq-sysfs.c > > @@ -166,20 +166,7 @@ static ssize_t blk_mq_hw_sysfs_nr_reserved_tags_show(struct blk_mq_hw_ctx *hctx, > > > > static ssize_t blk_mq_hw_sysfs_cpus_show(struct blk_mq_hw_ctx *hctx, char *page) > > { > > - unsigned int i, first = 1; > > - ssize_t ret = 0; > > - > > - for_each_cpu(i, hctx->cpumask) { > > - if (first) > > - ret += sprintf(ret + page, "%u", i); > > - else > > - ret += sprintf(ret + page, ", %u", i); > > - > > - first = 0; > > - } > > - > > - ret += sprintf(ret + page, "\n"); > > - return ret; > > + return cpumap_print_to_pagebuf(true, page, hctx->cpumask); > > } > > > > static struct blk_mq_hw_ctx_sysfs_entry blk_mq_hw_sysfs_nr_tags = { > > Although this patch looks fine to me, shouldn't this attribute be > documented under Documentation/ABI/? That is another problem, not closely related with this buffer-overflow issue. I suggest to fix the buffer overflow first, which is triggered from userspace. Thanks, Ming Lei