Skip to contentSkip to conversation

Why care about signal when instantiate an crypt template

DISCUSSION Fan Du 2 participants 4 messages Apr 11, 2014 – Apr 17, 2014 Crypto API

lore
Share & tools
lore

Fan Du

author
#0 lore raw

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?

Thanks a lot for any explanations.

Signature · 3 lines
浮沉随浪只记今朝笑

--fan
maintainer
#1 lore raw
Quoted 18 lines · Fan Du

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 }

Quoted 1 line

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.

Cheers,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author
#2 lore raw

Hi Herbert

Quoted 19 lines · Herbert Xu
Quoted 18 lines · Fan Du

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 }

Quoted 4 lines
Quoted 1 line

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;
- }

        }
Signature · 3 lines
浮沉随浪只记今朝笑

--fan
maintainer
#3 lore raw
Quoted 5 lines · Fan Du

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?

EAGAIN makes no sense when we bail out due to a signal.

Cheers,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt