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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 May 2024 22:45:36 +0800
From: yaoma <yaoma@...ux.alibaba.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: yaoma <yaoma@...ux.alibaba.com>,
 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

Hi,

> 2024年5月24日 15:53,Lukas Wunner <lukas@...ner.de> 写道:
> 
> 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) {
> 	...
> 	}
I'm not sure if the following scenarios would occur in actual production environment,
but from the code level, there is the possibility of “present <= 0 && link_active > 0”
or “present > 0 && link_active <= 0”. In these cases, the “<= 0” conditions will
not be properly handled, and “ctrl_info” will output incorrect prompt messages.
> So neither "present" nor "link_active" can be < 0 at this point.
> 
Best Regards,

	Bitao Hu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ