From patchwork Fri Feb 19 14:36:07 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 62350 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1206406lbl; Fri, 19 Feb 2016 06:44:32 -0800 (PST) X-Received: by 10.66.122.97 with SMTP id lr1mr18519791pab.80.1455892587062; Fri, 19 Feb 2016 06:36:27 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m70si16924373pfj.147.2016.02.19.06.36.26; Fri, 19 Feb 2016 06:36:27 -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; 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; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757635AbcBSOgY (ORCPT + 30 others); Fri, 19 Feb 2016 09:36:24 -0500 Received: from mail-lf0-f53.google.com ([209.85.215.53]:33547 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757214AbcBSOgX (ORCPT ); Fri, 19 Feb 2016 09:36:23 -0500 Received: by mail-lf0-f53.google.com with SMTP id m1so55622926lfg.0 for ; Fri, 19 Feb 2016 06:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=3WE9LyoxnslzLPb2gmW4wIX2D6K8oMHsyLBrBhT51so=; b=VzHGtpJ59fexLYQhonuqlxOVCMZb6m+0ACWJcwD81s+90Y3XDRptBB1iOj/pSSQwr8 oELRc/lzAhpQtdoQ8uhsYIo9ysGBWjbLcRRq//uPXju91jsUvQVOOG1ScnUa3qjC2ywQ xl44ClT33Q+Pld2r29hM2MVvswOqh4qWloOmE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=3WE9LyoxnslzLPb2gmW4wIX2D6K8oMHsyLBrBhT51so=; b=YoDWRhMfDpY8JAycJC8ojng7W5qQhNum1y8rkwqsyLSd/fRSIfv4n7UDxONVhbh2Zy HDHwELB0bLTNxoqAQ/fQoPnMusENeB4cYo5WrmX2G1kIgyLX7zY1tjAspG6HzHnidciC uWnndtrZRD7zJPdOwvAgHSTn3EHO0WRcAc2NUDwD6ifqRWfPumlyUalnQuQ8wC3CCtZi h/tk32Fh00y7dJ8/8Fh0O4GpYXojs0isikz/gvTnK2bTdwccK+24G1mU8V+9fkgJ6PGT 83W0s12wJesU31yDlFMJ0m1SlPsvqmFOcOqCLjQANIgztMSK9Gu7iagtfEge/PMqF22q 3HaQ== X-Gm-Message-State: AG10YORITzg8r7VdhCSbD2DOiSYAvOQouFwW5rackG5r2uDk4Yw4F7MVv+W2tOPgsySkoyi7 X-Received: by 10.25.15.216 with SMTP id 85mr1231856lfp.62.1455892581981; Fri, 19 Feb 2016 06:36:21 -0800 (PST) Received: from localhost.localdomain ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id p191sm1561304lfp.39.2016.02.19.06.36.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2016 06:36:20 -0800 (PST) From: Linus Walleij To: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Alan Cox , Arnd Bergmann Cc: Linus Walleij , Linus Torvalds Subject: [PATCH 1/2] chrdev: emit a warning when we go below dynamic major range Date: Fri, 19 Feb 2016 15:36:07 +0100 Message-Id: <1455892568-22586-1-git-send-email-linus.walleij@linaro.org> X-Mailer: git-send-email 2.4.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently a dynamically allocated character device major is taken from 254 and downward. This mechanism is used for RTC, IIO and a few other subsystems. The kernel currently has no check prevening these dynamic allocations from eating into the assigned numbers at 233 and downward. In a recent test it was reported that so many dynamic device majors were used on a test server, that the major number for infiniband (231) was stolen. This occurred when allocating a new major number for GPIO chips. The error messages from the kernel were not helpful. (See: https://lkml.org/lkml/2016/2/14/124) This patch adds a defined lower limit of the dynamic major allocation region will henceforth emit a warning if we start to eat into the assigned numbers. It does not do any semantic changes and will not change the kernels behaviour: numbers will still continue to be stolen, but we will know from dmesg what is going on. This also updates the Documentation/devices.txt to clearly reflect that we are using this range of major numbers for dynamic allocation. Reported-by: Ying Huang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Linus Walleij --- Alan: is your list at LANANA even maintained? It seems wildly out of sync with what's in the kernel. Maybe time to patch out some of the text in devices.txt directing people over there? --- Documentation/devices.txt | 6 +++--- fs/char_dev.c | 4 ++++ include/linux/fs.h | 2 ++ 3 files changed, 9 insertions(+), 3 deletions(-) -- 2.4.3 diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 87b4c5e82d39..0a3588a9798d 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -3099,9 +3099,9 @@ Your cooperation is appreciated. 129 = /dev/ipath_sma Device used by Subnet Management Agent 130 = /dev/ipath_diag Device used by diagnostics programs -234-239 UNASSIGNED - -240-254 char LOCAL/EXPERIMENTAL USE +234-254 char RESERVED FOR DYNAMIC ASSIGNMENT + Character devices that request a dynamic allocation of major number will + take numbers starting from 254 and downward. 240-254 block LOCAL/EXPERIMENTAL USE Allocated for local/experimental use. For devices not diff --git a/fs/char_dev.c b/fs/char_dev.c index 24b142569ca9..687471dc04a0 100644 --- a/fs/char_dev.c +++ b/fs/char_dev.c @@ -91,6 +91,10 @@ __register_chrdev_region(unsigned int major, unsigned int baseminor, break; } + if (i < CHRDEV_MAJOR_DYN_END) + pr_warn("CHRDEV \"%s\" major number %d goes below the dynamic allocation range", + name, i); + if (i == 0) { ret = -EBUSY; goto out; diff --git a/include/linux/fs.h b/include/linux/fs.h index 1a2046275cdf..6301ac091e54 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2384,6 +2384,8 @@ static inline void bd_unlink_disk_holder(struct block_device *bdev, /* fs/char_dev.c */ #define CHRDEV_MAJOR_HASH_SIZE 255 +/* Marks the bottom of the first segment of free char majors */ +#define CHRDEV_MAJOR_DYN_END 234 extern int alloc_chrdev_region(dev_t *, unsigned, unsigned, const char *); extern int register_chrdev_region(dev_t, unsigned, const char *); extern int __register_chrdev(unsigned int major, unsigned int baseminor,