Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>,
	Kent Gibson <warthog618@gmail.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] gpio: sysfs: use cleanup guards for the sysfs_lock mutex
Date: Mon, 28 Oct 2024 06:21:36 +0800	[thread overview]
Message-ID: <202410280514.EkyQpKfw-lkp@intel.com> (raw)
In-Reply-To: <20241026-gpio-notify-sysfs-v3-2-ad8f127d12f5@linaro.org>

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@intel.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

           reply	other threads:[~2024-10-27 22:21 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20241026-gpio-notify-sysfs-v3-2-ad8f127d12f5@linaro.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202410280514.EkyQpKfw-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=warthog618@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox