linux-kernel - Re: [PATCH] PCI: pciehp: Use appropriate conditions to check the hotplug controller status

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZlBHjbmjjSEnXCMp@wunner.de>
Date: Fri, 24 May 2024 09:53:49 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Bitao Hu <yaoma@...ux.alibaba.com>
Cc: bhelgaas@...gle.com, weirongguang@...inos.cn, kanie@...ux.alibaba.com,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: pciehp: Use appropriate conditions to check the
 hotplug controller status

On Fri, May 24, 2024 at 02:30:23PM +0800, Bitao Hu wrote:
> The values of 'present' and 'link_active' have similar meanings:
> the value is %1 if the status is ready, and %0 if it is not. If the
> hotplug controller itself is not available, the value should be
> %-ENODEV. However, both %1 and %-ENODEV are considered true, which
> obviously does not meet expectations. 'Slot(xx): Card present' and
> 'Slot(xx): Link Up' should only be output when the value is %1.
[...]
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -276,10 +276,10 @@ void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events)
>  	case OFF_STATE:
>  		ctrl->state = POWERON_STATE;
>  		mutex_unlock(&ctrl->state_lock);
> -		if (present)
> +		if (present > 0)
>  			ctrl_info(ctrl, "Slot(%s): Card present\n",
>  				  slot_name(ctrl));
> -		if (link_active)
> +		if (link_active > 0)
>  			ctrl_info(ctrl, "Slot(%s): Link Up\n",
>  				  slot_name(ctrl));
>  		ctrl->request_result = pciehp_enable_slot(ctrl);

We already handle the "<= 0" case immediately above this code excerpt:

	if (present <= 0 && link_active <= 0) {
	...
	}

So neither "present" nor "link_active" can be < 0 at this point.

Hence I don't quite understand what motivates the proposed code change?

Thanks,

Lukas