All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] PCI/ASPM: Reject sysfs attempts to enable states that are not covered by policy
Date: Sun, 6 Dec 2020 18:48:55 +0100	[thread overview]
Message-ID: <38f73412-ebbf-f1a5-3a9e-9f4621c830b2@gmail.com> (raw)
In-Reply-To: <20200909182846.GA719960@bjorn-Precision-5520>

Am 09.09.2020 um 20:28 schrieb Bjorn Helgaas:
> On Mon, Jul 20, 2020 at 08:08:59AM +0200, Heiner Kallweit wrote:
>> When trying to enable a state that is not covered by the policy,
>> then the change request will be silently ignored. That's not too
>> nice to the user, therefore reject such attempts explicitly.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>>  drivers/pci/pcie/aspm.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>> index b17e5ffd3..cd0f30ca9 100644
>> --- a/drivers/pci/pcie/aspm.c
>> +++ b/drivers/pci/pcie/aspm.c
>> @@ -1224,11 +1224,16 @@ static ssize_t aspm_attr_store_common(struct device *dev,
>>  {
>>  	struct pci_dev *pdev = to_pci_dev(dev);
>>  	struct pcie_link_state *link = pcie_aspm_get_link(pdev);
>> +	u32 policy_state = policy_to_aspm_state(link);
>>  	bool state_enable;
>>  
>>  	if (strtobool(buf, &state_enable) < 0)
>>  		return -EINVAL;
>>  
>> +	/* reject attempts to enable states not covered by policy */
>> +	if (state_enable && state & ~policy_state)
>> +		return -EPERM;
> 
> I really like the sentiment of this patch, but I don't like the fact
> that this test for states being covered by the policy is here by
> itself.
> 
> There must be some place in the pcie_config_aspm_link() path that does
> a similar test and silently ignores things not covered by the policy?
> If we could take advantage of *that* test, we won't have to worry
> about things getting out of sync if we change that test in the future.
> 
> Maybe pcie_config_aspm_link() could return -EPERM if the policy
> doesn't allow the requested state, and we could just notice that here?
> 
Oh, I just see that I missed to follow-up on this topic.

Currently pcie_config_aspm_link() is called in two versions:
1. with state argument 0
2. with state argument policy_to_aspm_state(link)

Therefore pcie_config_aspm_link() doesn't check for states not covered
by the policy. We could add a policy check, but the only use case where
this check would be needed is the call from aspm_attr_store_common().
Is this worth it? Ot better go with the check in
aspm_attr_store_common() as proposed?

In addition, based on the two types of calls to pcie_config_aspm_link(),
we could simplify usage of this function and replace the state argument
with a bool enable flag. If set, then pcie_config_aspm_link() would
internally select policy_to_aspm_state() as requested state.

>>  	down_read(&pci_bus_sem);
>>  	mutex_lock(&aspm_lock);
>>  
>> @@ -1241,7 +1246,7 @@ static ssize_t aspm_attr_store_common(struct device *dev,
>>  		link->aspm_disable |= state;
>>  	}
>>  
>> -	pcie_config_aspm_link(link, policy_to_aspm_state(link));
>> +	pcie_config_aspm_link(link, policy_state);
>>  
>>  	mutex_unlock(&aspm_lock);
>>  	up_read(&pci_bus_sem);
>> -- 
>> 2.27.0
>>


      reply	other threads:[~2020-12-06 17:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20  6:08 [PATCH] PCI/ASPM: Reject sysfs attempts to enable states that are not covered by policy Heiner Kallweit
2020-09-09 18:28 ` Bjorn Helgaas
2020-12-06 17:48   ` Heiner Kallweit [this message]

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=38f73412-ebbf-f1a5-3a9e-9f4621c830b2@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.