linux-kernel - Re: [PATCH v3 2/5] gpio: sysfs: use cleanup guards for the sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202410280514.EkyQpKfw-lkp@intel.com>
Date: Mon, 28 Oct 2024 06:21:36 +0800
From: kernel test robot <lkp@...el.com>
To: Bartosz Golaszewski <brgl@...ev.pl>,
	Linus Walleij <linus.walleij@...aro.org>,
	Kent Gibson <warthog618@...il.com>
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/5] gpio: sysfs: use cleanup guards for the
 sysfs_lock mutex

Hi Bartosz,

kernel test robot noticed the following build errors:

[auto build test ERROR on a39230ecf6b3057f5897bc4744a790070cfbe7a8]

url:    https://github.com/intel-lab-lkp/linux/commits/Bartosz-Golaszewski/gpio-sysfs-use-cleanup-guards-for-gpiod_data-mutex/20241026-210033
base:   a39230ecf6b3057f5897bc4744a790070cfbe7a8
patch link:    https://lore.kernel.org/r/20241026-gpio-notify-sysfs-v3-2-ad8f127d12f5%40linaro.org
patch subject: [PATCH v3 2/5] gpio: sysfs: use cleanup guards for the sysfs_lock mutex
config: i386-buildonly-randconfig-004-20241028 (https://download.01.org/0day-ci/archive/20241028/202410280514.EkyQpKfw-lkp@intel.com/config)
compiler: clang version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241028/202410280514.EkyQpKfw-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410280514.EkyQpKfw-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpio/gpiolib-sysfs.c:588:3: error: cannot jump from this goto statement to its label
     588 |                 goto err_clear_bit;
         |                 ^
   drivers/gpio/gpiolib-sysfs.c:591:21: note: jump bypasses initialization of variable with __attribute__((cleanup))
     591 |         struct gpiod_data *data __free(kfree) = kzalloc(sizeof(*data),
         |                            ^
   drivers/gpio/gpiolib-sysfs.c:582:3: error: cannot jump from this goto statement to its label
     582 |                 goto err_clear_bit;
         |                 ^
   drivers/gpio/gpiolib-sysfs.c:591:21: note: jump bypasses initialization of variable with __attribute__((cleanup))
     591 |         struct gpiod_data *data __free(kfree) = kzalloc(sizeof(*data),
         |                            ^
   2 errors generated.


vim +588 drivers/gpio/gpiolib-sysfs.c

   534	
   535	/**
   536	 * gpiod_export - export a GPIO through sysfs
   537	 * @desc: GPIO to make available, already requested
   538	 * @direction_may_change: true if userspace may change GPIO direction
   539	 * Context: arch_initcall or later
   540	 *
   541	 * When drivers want to make a GPIO accessible to userspace after they
   542	 * have requested it -- perhaps while debugging, or as part of their
   543	 * public interface -- they may use this routine.  If the GPIO can
   544	 * change direction (some can't) and the caller allows it, userspace
   545	 * will see "direction" sysfs attribute which may be used to change
   546	 * the gpio's direction.  A "value" attribute will always be provided.
   547	 *
   548	 * Returns:
   549	 * 0 on success, or negative errno on failure.
   550	 */
   551	int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
   552	{
   553		struct gpio_device *gdev;
   554		struct device *dev;
   555		int status;
   556	
   557		/* can't export until sysfs is available ... */
   558		if (!class_is_registered(&gpio_class)) {
   559			pr_debug("%s: called too early!\n", __func__);
   560			return -ENOENT;
   561		}
   562	
   563		if (!desc) {
   564			pr_debug("%s: invalid gpio descriptor\n", __func__);
   565			return -EINVAL;
   566		}
   567	
   568		CLASS(gpio_chip_guard, guard)(desc);
   569		if (!guard.gc)
   570			return -ENODEV;
   571	
   572		if (test_and_set_bit(FLAG_EXPORT, &desc->flags))
   573			return -EPERM;
   574	
   575		gdev = desc->gdev;
   576	
   577		guard(mutex)(&sysfs_lock);
   578	
   579		/* check if chip is being removed */
   580		if (!gdev->mockdev) {
   581			status = -ENODEV;
   582			goto err_clear_bit;
   583		}
   584	
   585		if (!test_bit(FLAG_REQUESTED, &desc->flags)) {
   586			gpiod_dbg(desc, "%s: unavailable (not requested)\n", __func__);
   587			status = -EPERM;
 > 588			goto err_clear_bit;
   589		}
   590	
   591		struct gpiod_data *data __free(kfree) = kzalloc(sizeof(*data),
   592								GFP_KERNEL);
   593		if (!data) {
   594			status = -ENOMEM;
   595			goto err_clear_bit;
   596		}
   597	
   598		data->desc = desc;
   599		mutex_init(&data->mutex);
   600		if (guard.gc->direction_input && guard.gc->direction_output)
   601			data->direction_can_change = direction_may_change;
   602		else
   603			data->direction_can_change = false;
   604	
   605		dev = device_create_with_groups(&gpio_class, &gdev->dev,
   606						MKDEV(0, 0), data, gpio_groups,
   607						"gpio%u", desc_to_gpio(desc));
   608		if (IS_ERR(dev)) {
   609			status = PTR_ERR(dev);
   610			goto err_clear_bit;
   611		}
   612	
   613		data = NULL;
   614		return 0;
   615	
   616	err_clear_bit:
   617		clear_bit(FLAG_EXPORT, &desc->flags);
   618		gpiod_dbg(desc, "%s: status %d\n", __func__, status);
   619		return status;
   620	}
   621	EXPORT_SYMBOL_GPL(gpiod_export);
   622	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki