All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
	Kalle Valo <kvalo@qca.qualcomm.com>,
	Michal Kazior <michal.kazior@tieto.com>,
	Yanbo Li <yanbol@qti.qualcomm.com>,
	Ben Greear <greearb@candelatech.com>
Subject: Re: [PATCH 0/4] ath10k: a few incorrect return handling fix-up
Date: Tue, 30 Dec 2014 19:28:43 +0100	[thread overview]
Message-ID: <20141230182842.GA18361@opentech.at> (raw)
In-Reply-To: <54A2DE7C.1050602@cogentembedded.com>

On Tue, 30 Dec 2014, Sergei Shtylyov wrote:

> Hello.
>
> On 12/30/2014 03:20 PM, Nicholas Mc Guire wrote:
>
>> wait_for_completion_timeout does not return negative values so the tests
>> for <= 0 are not needed and the case differentiation in the error handling
>> path unnecessary.
>
>    I decided to verify your statement and I saw that it seems wrong.  
> do_wait_for_common() can return -ERESTARTSYS and the return value gets  
> returned by its callers unchanged.

the -ERESTARTSYS only can be returned if state matches but
wait_for_completion_timemout passes TASK_UNINTERRUPTIBLE
so signal_pending_state will return 0 and never negativ

my understanding of the callchain is:
wait_for_completion_timemout with TASK_UNINTERRUPTIBLE
  -> wait_for_common(...TASK_UNINTERRUPTIBLE)
    -> __wait_for_common(...TASK_UNINTERRUPTIBLE)
      -> do_wait_for_common(...TASK_UNINTERRUPTIBLE)
        -> signal_pending_state(TASK_UNINTERRUPTIBLE...)

static inline int signal_pending_state(long state, struct task_struct *p)
{
        if (!(state & (TASK_INTERRUPTIBLE | TASK_WAKEKILL)))
                return 0;

so wait_for_completion_timemout should return 0 or 1 only

>
>> patch was only compile tested x86_64_defconfig + CONFIG_ATH_CARDS=m
>> CONFIG_ATH10K=m
>
>> patch is against linux-next 3.19.0-rc1 -next-20141226
>
>    Rather patches. It would have been better to send one patch instead of 
> 4 patches with the same name.
>
sorry for that - I had split it into separate patches as it was
in different files - giving them the same name of course was a bit
brain-dead.

please do give it one more look - if the above argument is invalid
I apologize for the noise.


thx!
hofrat

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>,
	Michal Kazior <michal.kazior@tieto.com>,
	Ben Greear <greearb@candelatech.com>,
	Chun-Yeow Yeoh <yeohchunyeow@gmail.com>,
	Yanbo Li <yanbol@qti.qualcomm.com>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] ath10k: a few incorrect return handling fix-up
Date: Tue, 30 Dec 2014 19:28:43 +0100	[thread overview]
Message-ID: <20141230182842.GA18361@opentech.at> (raw)
In-Reply-To: <54A2DE7C.1050602@cogentembedded.com>

On Tue, 30 Dec 2014, Sergei Shtylyov wrote:

> Hello.
>
> On 12/30/2014 03:20 PM, Nicholas Mc Guire wrote:
>
>> wait_for_completion_timeout does not return negative values so the tests
>> for <= 0 are not needed and the case differentiation in the error handling
>> path unnecessary.
>
>    I decided to verify your statement and I saw that it seems wrong.  
> do_wait_for_common() can return -ERESTARTSYS and the return value gets  
> returned by its callers unchanged.

the -ERESTARTSYS only can be returned if state matches but
wait_for_completion_timemout passes TASK_UNINTERRUPTIBLE
so signal_pending_state will return 0 and never negativ

my understanding of the callchain is:
wait_for_completion_timemout with TASK_UNINTERRUPTIBLE
  -> wait_for_common(...TASK_UNINTERRUPTIBLE)
    -> __wait_for_common(...TASK_UNINTERRUPTIBLE)
      -> do_wait_for_common(...TASK_UNINTERRUPTIBLE)
        -> signal_pending_state(TASK_UNINTERRUPTIBLE...)

static inline int signal_pending_state(long state, struct task_struct *p)
{
        if (!(state & (TASK_INTERRUPTIBLE | TASK_WAKEKILL)))
                return 0;

so wait_for_completion_timemout should return 0 or 1 only

>
>> patch was only compile tested x86_64_defconfig + CONFIG_ATH_CARDS=m
>> CONFIG_ATH10K=m
>
>> patch is against linux-next 3.19.0-rc1 -next-20141226
>
>    Rather patches. It would have been better to send one patch instead of 
> 4 patches with the same name.
>
sorry for that - I had split it into separate patches as it was
in different files - giving them the same name of course was a bit
brain-dead.

please do give it one more look - if the above argument is invalid
I apologize for the noise.


thx!
hofrat

  reply	other threads:[~2014-12-30 18:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 12:20 [PATCH 0/4] ath10k: a few incorrect return handling fix-up Nicholas Mc Guire
2014-12-30 12:20 ` Nicholas Mc Guire
2014-12-30 12:20 ` [PATCH 1/4] ath10k: fixup wait_for_completion_timeout return handling Nicholas Mc Guire
2014-12-30 12:20   ` Nicholas Mc Guire
2014-12-30 12:20   ` Nicholas Mc Guire
2014-12-30 12:20 ` [PATCH 2/4] " Nicholas Mc Guire
2014-12-30 12:20   ` Nicholas Mc Guire
2014-12-30 12:20 ` [PATCH 3/4] " Nicholas Mc Guire
2014-12-30 12:20   ` Nicholas Mc Guire
2014-12-30 12:20 ` [PATCH 4/4] " Nicholas Mc Guire
2014-12-30 12:20   ` Nicholas Mc Guire
2014-12-30 17:18 ` [PATCH 0/4] ath10k: a few incorrect return handling fix-up Sergei Shtylyov
2014-12-30 17:18   ` Sergei Shtylyov
2014-12-30 18:28   ` Nicholas Mc Guire [this message]
2014-12-30 18:28     ` Nicholas Mc Guire
2014-12-30 18:39     ` Sergei Shtylyov
2014-12-30 18:39       ` Sergei Shtylyov
2014-12-30 19:42       ` Nicholas Mc Guire
2014-12-30 19:42         ` Nicholas Mc Guire

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=20141230182842.GA18361@opentech.at \
    --to=der.herr@hofr.at \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    --cc=netdev@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=yanbol@qti.qualcomm.com \
    --cc=yeohchunyeow@gmail.com \
    /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.