Hi Herbert
On 2014年04月17日 15:44, Herbert Xu wrote:
Fan Du<fan.du@xxxxxxxxxxxxx> wrote:
Hi,
I recently bump into a issue, ike daemon got interrupted(EINTR),
after looking at the code, it seems there are places in crypto code
where returning EINTR when current tasks has signal pending.
For example:
crypto_alloc_base and crypto_alloc_tfm
435 err:
436 if (err != -EAGAIN)
437 break;
438 if (signal_pending(current)) {
439 err = -EINTR;
440 break;
441 }
442 }
I can't understand why the codes here needs to care about signals?
Because otherwise you may end up with something that you can't
kill from user-space. You should fix your app.
Ok, I'm starting to follow your meaning.
The signal checking is only to bail out from the infinite loop, it shouldn't
override original err code -EAGAIN with -EINTR.
With -EAGAIN, user space app can try again, what do you think?
@@ -550,12 +550,8 @@ void *crypto_alloc_tfm(const char *alg_name,
err = PTR_ERR(tfm);
err:
- if (err != -EAGAIN)
+ if ((err != -EAGAIN) || signal_pending(current))
break;
- if (signal_pending(current)) {
- err = -EINTR;
- break;
- }
}
--
浮沉随浪只记今朝笑
--fan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
