From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
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 21:39:13 +0300 [thread overview]
Message-ID: <54A2F151.6040205@cogentembedded.com> (raw)
In-Reply-To: <20141230182842.GA18361@opentech.at>
On 12/30/2014 09:28 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;
Right. I didn't look into TASK_UNINTERRUPTIBLE thing before sending my mail.
> so wait_for_completion_timemout should return 0 or 1 only
0 or the remaining time, to be precise.
>>> 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.
You should have mentioned the modified files in the subject. But IMHO it
would be better to have just one patch.
> please do give it one more look - if the above argument is invalid
> I apologize for the noise.
It's me who should apologize. :-<
> thx!
> hofrat
WBR, Sergei
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
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 21:39:13 +0300 [thread overview]
Message-ID: <54A2F151.6040205@cogentembedded.com> (raw)
In-Reply-To: <20141230182842.GA18361@opentech.at>
On 12/30/2014 09:28 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;
Right. I didn't look into TASK_UNINTERRUPTIBLE thing before sending my mail.
> so wait_for_completion_timemout should return 0 or 1 only
0 or the remaining time, to be precise.
>>> 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.
You should have mentioned the modified files in the subject. But IMHO it
would be better to have just one patch.
> please do give it one more look - if the above argument is invalid
> I apologize for the noise.
It's me who should apologize. :-<
> thx!
> hofrat
WBR, Sergei
next prev parent reply other threads:[~2014-12-30 18:39 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
2014-12-30 18:28 ` Nicholas Mc Guire
2014-12-30 18:39 ` Sergei Shtylyov [this message]
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=54A2F151.6040205@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=ath10k@lists.infradead.org \
--cc=der.herr@hofr.at \
--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=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.