On Wednesday 18 April 2012 12:15:51 Dmitry V. Levin wrote:
> On Tue, Apr 17, 2012 at 10:19:31PM -0400, Mike Frysinger wrote:
> > +           if (!abbrev(tcp) || info.lo_encrypt_type != LO_CRYPT_NONE) {
> > +                   string_quote((void *) info.lo_encrypt_key, s, 0, 
LO_KEY_SIZE);
> > +                   tprintf(", encrypt_key=%s", s);
> > +           }
> 
> [...]
> 
> > +           if (!abbrev(tcp) || info64.lo_encrypt_type != LO_CRYPT_NONE) {
> > +                   string_quote((void *) info64.lo_crypt_name, s, -1, 
LO_NAME_SIZE);
> > +                   tprintf(", crypt_name=%s", s);
> > +                   string_quote((void *) info64.lo_encrypt_key, s, 0, 
LO_KEY_SIZE);
> > +                   tprintf(", encrypt_key=%s", s);
> > +           }
> 
> I'm not sure the LO_CRYPT_NONE case worth decoding even in verbose mode.
> If the kernel ignores this data, what kind of help for debugging could
> it be?

as a general rule, in verbose mode, i'd really like to see everything the 
kernel sees.  makes it easier to diagnose cases when things go wrong.

i agree that in general, the kernel shouldn't care about these fields when 
encryption is disable.  but consider the case where the user code overflows a 
member of their struct.  in verbose mode, it'd be easier to pick out since you 
see the entire thing vs pieces.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel

Reply via email to