Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: Dongdong Liu <liudongdong3@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <regressions@lists.linux.dev>
Subject: Re: [REGRESSION] changes to driver_override parsing broke DPDK script
Date: Fri, 12 Aug 2022 10:54:38 +0800	[thread overview]
Message-ID: <f8825129-1566-df86-ade3-8d2885ce90b3@huawei.com> (raw)
In-Reply-To: <872d304a-3aa0-53a4-c26a-3cb30594274d@huawei.com>


在 2022/8/12 9:48, Dongdong Liu 写道:
> cc Huisong who found the issue.
>
> On 2022/8/10 16:21, Greg KH wrote:
>> On Wed, Aug 10, 2022 at 08:11:33AM +0200, Greg KH wrote:
>>> On Wed, Aug 10, 2022 at 08:54:36AM +0300, Krzysztof Kozlowski wrote:
>>>> On 09/08/2022 22:21, Bjorn Helgaas wrote:
>>>>> [+cc regressions list]
>>>>>
>>>>> 23d99baf9d72 appeared in v5.19-rc1.
>>>>>
>>>>> On Tue, Aug 09, 2022 at 11:29:43AM -0700, Stephen Hemminger wrote:
>>>>>> This commit broke the driver override script in DPDK.
>>>>>> This is an API/ABI breakage, please revert or fix the commit.
>>>>>>
>>>>>> Report of problem:
>>>>>> http://mails.dpdk.org/archives/dev/2022-August/247794.html
>>>>
>>>> Thanks for the report. I'll take a look.
>>>>
>>>>>>
>>>>>>
>>>>>> commit 23d99baf9d729ca30b2fb6798a7b403a37bfb800
>>>>>> Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>> Date:   Tue Apr 19 13:34:28 2022 +0200
>>>>>>
>>>>>>     PCI: Use driver_set_override() instead of open-coding
>>>>>>
>>>>>>     Use a helper to set driver_override to the reduce amount of 
>>>>>> duplicated
>>>>>>     code.  Make the driver_override field const char, because it 
>>>>>> is not
>>>>>>     modified by the core and it matches other subsystems.
>>>>>>
>>>>>>     Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>>>>     Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>>>>>>     Signed-off-by: Krzysztof Kozlowski 
>>>>>> <krzysztof.kozlowski@linaro.org>
>>>>>>     Link: 
>>>>>> https://lore.kernel.org/r/20220419113435.246203-6-krzysztof.kozlowski@linaro.org
>>>>>>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>
>>>>>>
>>>>>> The script is sending single nul character to remove override
>>>>>> and that no longer works.
>>>>
>>>> The sysfs API clearly states:
>>>> "and
>>>>  may be cleared with an empty string (echo > driver_override)."
>>>> Documentation/ABI/testing/sysfs-bus-pci
>>>>
>>>> Sending other data and expecting the same result is not conforming to
>>>> API. Therefore we have usual example of some undocumented behavior 
>>>> which
>>>> user-space started relying on and instead using API, user-space expect
>>>> that undocumented behavior to be back.
>>>>
>>>> Yay! I wonder what is the point to even describe the ABI if user-space
>>>> can simply ignore it?
>>>
>>> One can argue that a string of just '\0' is an "empty string" and we
>>> should be able to properly handle this in the kernel.  Heck,
>>> "\0\0\0\0\0\0" is also an "empty string", right?
>>>
>>> I don't have an issue with fixing the kernel up here, it should be able
>>> to handle this.
>>
>> Stephen, does the patch below fix this for you?
>>
>> thanks,
>>
>> greg k-h
>>
>> -----------------
>>
>> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
>> index 15a75afe6b84..676b6275d5b5 100644
>> --- a/drivers/base/driver.c
>> +++ b/drivers/base/driver.c
>> @@ -63,6 +63,12 @@ int driver_set_override(struct device *dev, const 
>> char **override,
>>      if (len >= (PAGE_SIZE - 1))
>>          return -EINVAL;
>>
>> +    /*
>> +     * Compute the real length of the string in case userspace sends 
>> us a
>> +     * bunch of \0 characters like python likes to do.
>> +     */
>> +    len = strlen(s);
>> +
>>      if (!len) {
>>          /* Empty string passed - clear override */
>>          device_lock(dev);
>> .
>>
> This patch looks good,  @huisong, please help to test the patch.
>
> Thanks,
> Dongdong
> .
Tested-by: Huisong Li <lihuisong@huawei.com>

  reply	other threads:[~2022-08-12  2:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 18:29 [REGRESSION] changes to driver_override parsing broke DPDK script Stephen Hemminger
2022-08-09 19:21 ` Bjorn Helgaas
2022-08-10  5:54   ` Krzysztof Kozlowski
2022-08-10  6:11     ` Greg KH
2022-08-10  8:21       ` Greg KH
2022-08-12  1:48         ` Dongdong Liu
2022-08-12  2:54           ` lihuisong (C) [this message]
2022-08-12  5:46             ` Greg KH
2022-09-01 16:41               ` Greg KH
2022-08-10  6:13     ` Krzysztof Kozlowski
2022-08-10 14:03       ` Stephen Hemminger
2022-08-10 14:06     ` Stephen Hemminger
2022-08-10  5:45 ` Greg KH

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=f8825129-1566-df86-ade3-8d2885ce90b3@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liudongdong3@huawei.com \
    --cc=regressions@lists.linux.dev \
    --cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox