netdev - Re: [PATCH net-next 1/7] net: ipa: restructure a few functions

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

Message-ID: <2946916e-9f1d-b73a-72b1-5f4ce8b2cc6c@linaro.org>
Date:   Fri, 5 Feb 2021 07:37:04 -0600
From:   Alex Elder <elder@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, elder@...nel.org, evgreen@...omium.org,
        bjorn.andersson@...aro.org, cpratapa@...eaurora.org,
        subashab@...eaurora.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/7] net: ipa: restructure a few functions

On 2/4/21 10:50 PM, Jakub Kicinski wrote:
> On Wed,  3 Feb 2021 09:28:49 -0600 Alex Elder wrote:
>> Make __gsi_channel_start() and __gsi_channel_stop() more structurally
>> and semantically similar to each other:
>>   - Restructure __gsi_channel_start() to always return at the end of
>>     the function, similar to the way __gsi_channel_stop() does.
>>   - Move the mutex calls out of gsi_channel_stop_retry() and into
>>     __gsi_channel_stop().
>>
>> Restructure gsi_channel_stop() to always return at the end of the
>> function, like gsi_channel_start() does.
>>
>> Signed-off-by: Alex Elder <elder@...aro.org>
>> ---
>>  drivers/net/ipa/gsi.c | 45 +++++++++++++++++++++++--------------------
>>  1 file changed, 24 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
>> index 53640447bf123..2671b76ebcfe3 100644
>> --- a/drivers/net/ipa/gsi.c
>> +++ b/drivers/net/ipa/gsi.c
>> @@ -873,17 +873,17 @@ static void gsi_channel_deprogram(struct gsi_channel *channel)
>>  
>>  static int __gsi_channel_start(struct gsi_channel *channel, bool start)
>>  {
>> -	struct gsi *gsi = channel->gsi;
>> -	int ret;
>> +	int ret = 0;
>>  
>> -	if (!start)
>> -		return 0;
>> +	if (start) {
>> +		struct gsi *gsi = channel->gsi;
>>  
>> -	mutex_lock(&gsi->mutex);
>> +		mutex_lock(&gsi->mutex);
>>  
>> -	ret = gsi_channel_start_command(channel);
>> +		ret = gsi_channel_start_command(channel);
>>  
>> -	mutex_unlock(&gsi->mutex);
>> +		mutex_unlock(&gsi->mutex);
>> +	}
> 
> nit: I thought just recently Willem pointed out that keeping main flow
>      unindented is considered good style, maybe it doesn't apply here
>      perfectly, but I'd think it still applies. Why have the entire
>      body of the function indented?

I *like* keeping the main flow un-indented (the way
it was).

It's a little funny, because one of my motivations for
doing it this way was how I interpreted the comment
from Willem (and echoed by you).  He said, "...easier
to parse when the normal control flow is linear and
the error path takes a branch (or goto, if reused)."
And now that I read it again, I see that's what he
was saying.

But the way I interpreted it was "don't return early
for the success case," because that's what the code
in question that elicited that comment was doing.

In any case I concur with your comment and prefer the
code the other way.  I will post v2 that will fix this,
both here and in __gsi_channel_start().

Thanks.

					-Alex

> 
>>  	return ret;
>>  }
>> @@ -910,11 +910,8 @@ int gsi_channel_start(struct gsi *gsi, u32 channel_id)
>>  static int gsi_channel_stop_retry(struct gsi_channel *channel)
>>  {
>>  	u32 retries = GSI_CHANNEL_STOP_RETRIES;
>> -	struct gsi *gsi = channel->gsi;
>>  	int ret;
>>  
>> -	mutex_lock(&gsi->mutex);
>> -
>>  	do {
>>  		ret = gsi_channel_stop_command(channel);
>>  		if (ret != -EAGAIN)
>> @@ -922,19 +919,26 @@ static int gsi_channel_stop_retry(struct gsi_channel *channel)
>>  		usleep_range(3 * USEC_PER_MSEC, 5 * USEC_PER_MSEC);
>>  	} while (retries--);
>>  
>> -	mutex_unlock(&gsi->mutex);
>> -
>>  	return ret;
>>  }
>>  
>>  static int __gsi_channel_stop(struct gsi_channel *channel, bool stop)
>>  {
>> -	int ret;
>> +	int ret = 0;
>>  
>>  	/* Wait for any underway transactions to complete before stopping. */
>>  	gsi_channel_trans_quiesce(channel);
>>  
>> -	ret = stop ? gsi_channel_stop_retry(channel) : 0;
>> +	if (stop) {
>> +		struct gsi *gsi = channel->gsi;
>> +
>> +		mutex_lock(&gsi->mutex);
>> +
>> +		ret = gsi_channel_stop_retry(channel);
>> +
>> +		mutex_unlock(&gsi->mutex);
>> +	}
>> +
>>  	/* Finally, ensure NAPI polling has finished. */
>>  	if (!ret)
>>  		napi_synchronize(&channel->napi);
>> @@ -948,15 +952,14 @@ int gsi_channel_stop(struct gsi *gsi, u32 channel_id)
>>  	struct gsi_channel *channel = &gsi->channel[channel_id];
>>  	int ret;
>>  
>> -	/* Only disable the completion interrupt if stop is successful */
>>  	ret = __gsi_channel_stop(channel, true);
>> -	if (ret)
>> -		return ret;
>> +	if (ret) {
> 
> This inverts the logic, right? Is it intentional?
> 
>> +		/* Disable the completion interrupt and NAPI if successful */
>> +		gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id);
>> +		napi_disable(&channel->napi);
>> +	}
>>  
>> -	gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id);
>> -	napi_disable(&channel->napi);
>> -
>> -	return 0;
>> +	return ret;
>>  }
>>  
>>  /* Reset and reconfigure a channel, (possibly) enabling the doorbell engine */
>