linux-kernel - Re: [PATCH RFC 03/15] drivers/base: Allocate/free platform-msi interrupts by group

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]

Message-ID: <b6d3e623-55c3-fac4-96ca-d10c42782794@linux.intel.com>
Date:   Sun, 3 May 2020 17:08:45 -0700
From:   "Dey, Megha" <megha.dey@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Dave Jiang <dave.jiang@...el.com>, vkoul@...nel.org,
        maz@...nel.org, bhelgaas@...gle.com, rafael@...nel.org,
        gregkh@...uxfoundation.org, hpa@...or.com,
        alex.williamson@...hat.com, jacob.jun.pan@...el.com,
        ashok.raj@...el.com, jgg@...lanox.com, yi.l.liu@...el.com,
        baolu.lu@...el.com, kevin.tian@...el.com, sanjay.k.kumar@...el.com,
        tony.luck@...el.com, jing.lin@...el.com, dan.j.williams@...el.com,
        kwankhede@...dia.com, eric.auger@...hat.com, parav@...lanox.com
Cc:     dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-pci@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH RFC 03/15] drivers/base: Allocate/free platform-msi
 interrupts by group

Hi Thomas,

On 4/25/2020 2:23 PM, Thomas Gleixner wrote:
> Dave Jiang <dave.jiang@...el.com> writes:
>> From: Megha Dey <megha.dey@...ux.intel.com>
>> --- a/include/linux/msi.h
>> +++ b/include/linux/msi.h
>> @@ -135,6 +135,12 @@ enum platform_msi_type {
>>   	GEN_PLAT_MSI = 1,
>>   };
>>   
>> +struct platform_msi_group_entry {
>> +	unsigned int group_id;
>> +	struct list_head group_list;
>> +	struct list_head entry_list;
> 
> I surely told you before that struct members want to be written tabular.

yep, you surely did :) I will use tabs henceforth!
> 
>> +};
>> +
>>   /* Helpers to hide struct msi_desc implementation details */
>>   #define msi_desc_to_dev(desc)		((desc)->dev)
>>   #define dev_to_msi_list(dev)		(&(dev)->msi_list)
>> @@ -145,21 +151,31 @@ enum platform_msi_type {
>>   #define for_each_msi_entry_safe(desc, tmp, dev)	\
>>   	list_for_each_entry_safe((desc), (tmp), dev_to_msi_list((dev)), list)
>>   
>> -#define dev_to_platform_msi_list(dev)	(&(dev)->platform_msi_list)
>> -#define first_platform_msi_entry(dev)		\
>> -	list_first_entry(dev_to_platform_msi_list((dev)), struct msi_desc, list)
>> -#define for_each_platform_msi_entry(desc, dev)	\
>> -	list_for_each_entry((desc), dev_to_platform_msi_list((dev)), list)
>> -#define for_each_platform_msi_entry_safe(desc, tmp, dev)	\
>> -	list_for_each_entry_safe((desc), (tmp), dev_to_platform_msi_list((dev)), list)
>> +#define dev_to_platform_msi_group_list(dev)    (&(dev)->platform_msi_list)
>> +
>> +#define first_platform_msi_group_entry(dev)				\
>> +	list_first_entry(dev_to_platform_msi_group_list((dev)),		\
>> +			 struct platform_msi_group_entry, group_list)
>>   
>> -#define first_msi_entry_common(dev)	\
>> -	list_first_entry_select((dev)->platform_msi_type, dev_to_platform_msi_list((dev)),	\
>> +#define platform_msi_current_group_entry_list(dev)			\
>> +	(&((list_last_entry(dev_to_platform_msi_group_list((dev)),	\
>> +			    struct platform_msi_group_entry,		\
>> +			    group_list))->entry_list))
>> +
>> +#define first_msi_entry_current_group(dev)				\
>> +	list_first_entry_select((dev)->platform_msi_type,		\
>> +				platform_msi_current_group_entry_list((dev)),	\
>>   				dev_to_msi_list((dev)), struct msi_desc, list)
>>   
>> -#define for_each_msi_entry_common(desc, dev)	\
>> -	list_for_each_entry_select((dev)->platform_msi_type, desc, dev_to_platform_msi_list((dev)), \
>> -				   dev_to_msi_list((dev)), list)	\
>> +#define for_each_msi_entry_current_group(desc, dev)			\
>> +	list_for_each_entry_select((dev)->platform_msi_type, desc,	\
>> +				   platform_msi_current_group_entry_list((dev)),\
>> +				   dev_to_msi_list((dev)), list)
>> +
>> +#define for_each_platform_msi_entry_in_group(desc, platform_msi_group, group, dev)	\
>> +	list_for_each_entry((platform_msi_group), dev_to_platform_msi_group_list((dev)), group_list)	\
>> +		if (((platform_msi_group)->group_id) == (group))			\
>> +			list_for_each_entry((desc), (&(platform_msi_group)->entry_list), list)
> 
> Yet more unreadable macro maze to obfuscate what the code is actually
> doing.

hmm I will i guess add some more documentation either in the commit 
message or somewhere in documentation to make it clearer about the 
purpose of these macros.

> 
>>   /* When an MSI domain is used as an intermediate domain */
>>   int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
>> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
>> index bc5f9e32387f..899ade394ec8 100644
>> --- a/kernel/irq/msi.c
>> +++ b/kernel/irq/msi.c
>> @@ -320,7 +320,7 @@ int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
>>   	struct msi_desc *desc;
>>   	int ret = 0;
>>   
>> -	for_each_msi_entry_common(desc, dev) {
>> +	for_each_msi_entry_current_group(desc, dev) {
> 
> How is anyone supposed to figure out what the heck this means without
> going through several layers of macro maze and some magic type/group
> storage in struct device?
> 

Point noted. I think I am better off committing smaller logical changes 
in each patch.

> Again, function arguments exist for a reason.

ok makes sense, I will do this in the next version.

> 
> Thanks,
> 
>          tglx
>