Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2289360ybb; Thu, 2 Apr 2020 17:27:26 -0700 (PDT) X-Google-Smtp-Source: APiQypLWh65uprgLH11RiWo0goUcQJSqjgzyUNCcE3cAy06jJ5D800FdnZz6gPo2IZUxtuBbLTax X-Received: by 2002:a05:6830:1bc9:: with SMTP id v9mr4273509ota.169.1585873645926; Thu, 02 Apr 2020 17:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585873645; cv=none; d=google.com; s=arc-20160816; b=OJgXms6qld24VYUTJbK1t3sJY3Jbv/nkfAVVXe84Bsxh4rB/zUApFszsdIM9MQRed/ iUQ6JagB05DpPNxoYwf2pXjPFw9jujerlcvKz1hyQZqCBHSpYl5PYVBWdTF7M2awXhMo jDE3tysfyZU5t5zTHzXlq+fiU8+L9ec+QMYKbh0OJU7J5hqjGXGOXm1wBk2lRlR/H+H6 T35VS1lIvBuYElA1Bnr3cDcGzSW0A8mjdUAZL5Ru3C+4+P+KWEuwfkhYYT5G81/ZRnSQ zRtisxD2psAFa1j8Hw0ocdIkCeLcJ5nMmLRZK748bzFPooPGqvVWPDaTV+rxlhjs2Lej c5Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=G8k/QwTw4qQdBRVrKpDUgP0f41wvfICsPC6bQdhcbWo=; b=NDvLbdOXMLpWTNCwqr1TZrgh/tdZm3Pg59vjnV06JFyllcoF/zNSano/4zpwVqYRSy ZYCVT+0Jq1Yl55eY30w2uFB7cz8+xSlo9rSxs/WPwTplvu3cMMAyiCkbxcJ/wXPd1s0Y C0L8GnCGxdqmmSzpm/3pnlVrRrr0n5KvdZPQpG1uMkBFv/ZCI5xh88yU+0RiGS2uRCkh TR017w5dExpqbO27SNGstUa23DYyHM+Fso0zZaIH6BO8fDgmox9/iHwQLdVLtPMkTGsB waqBFGUhBcmQfz8CNT0hvTaaCrkwDKG5dzzPSre8ck2/mARGr9h0Urozn/XWlvbAd3Oe 0mCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QoU875qh; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r18si2898077otq.124.2020.04.02.17.27.12; Thu, 02 Apr 2020 17:27:25 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=QoU875qh; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390082AbgDBXX4 (ORCPT + 99 others); Thu, 2 Apr 2020 19:23:56 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:43491 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388709AbgDBXXz (ORCPT ); Thu, 2 Apr 2020 19:23:55 -0400 Received: by mail-qt1-f193.google.com with SMTP id a5so4996431qtw.10 for ; Thu, 02 Apr 2020 16:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=G8k/QwTw4qQdBRVrKpDUgP0f41wvfICsPC6bQdhcbWo=; b=QoU875qhDMl9qp0w3pLF62oq653U/4KhAb0KfGbYQ3KdGHHY1iO8uOpyzg8dSlTo+c 9Z6wwvkoh+s9Yhesije1YntqBwO9WgubgycfwRaJ+LMlEKtI8YAb+562E9xCOddPANiX 7LRjXkiMekGtUtcoaxvBmiPhADc+RcfvHF0/exU3KNQT6q6zvunq3ZCLHfuych7Hp2nT XAKqmRLamtJPmMRAOcnhOn5h/sJ7kOHhytJKx+V92Ln69jlxoU+vn56zWUdn5Hfy80lg sPLdty2NFPJ1zvMa6Gt/nxw5Jr4HoGCD1LnhEM3WoNLv70pq8I/kdtOQhiWoTf0KOLBG lLNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=G8k/QwTw4qQdBRVrKpDUgP0f41wvfICsPC6bQdhcbWo=; b=OwG2qqmroJwzjo/GR80hhH0i0NFOPFGVNXg7T8X4e9eUtIaaVw1zr1R3QRDhihZKZW QDzRFWz4RkqATkciFE/o7skjX0zCk89vhgSouvEB7l0gLXYnO8Y0yOD+1WgbwPB2/vWb L6PnLCxx7gHli8XozdsJlGGFJaNUjU8HGRojNpwWuoa5zJga6SCv9fyvBezb3c5HoNYn tmN4AOr/3TuMPw4Fn7xttkOwLcqbNdknoSX3Kpq0ifr4HydM1NxietXGrr9pAy8q9jPY /UQ/06D1n0O87zny0uCQEydgTe1MXlOFueYyarzKqSzRUln6Q35XUjyCFSWnIargQs4i edAQ== X-Gm-Message-State: AGi0PuZphmaNvNAO4Ro/CzFipHGXsQCAyYfp/SxKRvQ/4Pml1Nexfqgg 2uoPqUHuwr+Jwlcbd9L44Ck3LC4u X-Received: by 2002:ac8:16e7:: with SMTP id y36mr5609518qtk.225.1585869834473; Thu, 02 Apr 2020 16:23:54 -0700 (PDT) Received: from smtp.gmail.com (179-193-220-245.user3g.veloxzone.com.br. [179.193.220.245]) by smtp.gmail.com with ESMTPSA id g6sm5187961qtc.31.2020.04.02.16.23.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 16:23:54 -0700 (PDT) Date: Thu, 2 Apr 2020 20:23:50 -0300 From: Marcelo Schmitt To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, lars@metafoo.de Subject: Re: [RFC] genirq: prevent allocated_irqs from being smaller than NR_IRQS Message-ID: <20200402232350.GA1644@smtp.gmail.com> References: <20200402150820.GB5886@smtp.gmail.com> <87k12xn1d7.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k12xn1d7.fsf@nanos.tec.linutronix.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/02, Thomas Gleixner wrote: > Marcelo, > > Marcelo Schmitt writes: > > #ifdef CONFIG_SPARSE_IRQ > > # define IRQ_BITMAP_BITS (NR_IRQS + 8196) > > #else > > # define IRQ_BITMAP_BITS NR_IRQS > > #endif > > > > The thing I'm troubled about is that BITS_TO_LONGS divides > > IRQ_BITMAP_BITS by sizeof(long) * 8, which makes it possible for the > > size of allocated_irqs to be smaller than NR_IRQS. > > No. It calculates the number of longs which are required to store > IRQ_BITMAP_BITS bits. And it does not only divide, it also takes the > reminder into account. > > One byte fits 8 bits. Multiplied with sizeof(long) tells you how many > bits fit into a long: Unsurprisingly that 32 on 32bit and 64 on 64bit > systems. I see. Given that a single bit is enough to mark whether interrupts were allocated for an IRQ line, the allocated_irqs needs only IRQ_BITMAP_BITS bits to track how many IRQs have been allocated. Since BITS_TO_LONGS will calculate the number of longs required to store at least IRQ_BITMAP_BIT bits, the bitmap will have enough room for the tracking bits. Naturally, the number of longs needed to store N bits will depend on the sizeof(long) in each system. Probably this is why BITS_PER_TYPE(long) is taken into account to find out how many longs are needed to house IRQ_BITMAP_BIT bits. Therefore, the initialization of allocated_irqs shall generalize well for systems with different word sizes. A clever implementation. > > > By the way, is there any mailing list for IRQ related discussions? > > I couldn't find one at vger.kernel.org. > > The MAINTAINERS file tells you: > > IRQ SUBSYSTEM > L: linux-kernel@vger.kernel.org > > So you picked the right one. > > Thanks, > > tglx Thanks, Marcelo