Re: [PATCH v3] Show module taint flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> Hi Dave,
> 
> 
> Sorry about the delay. I've finally found the time to attempt another
> version.
> 
> As per your request, I've updated *help_mod[] to document the -T option.
> Also in this particular version, I omit ' ' and '-', when false, as I'm under
> the impression that we're only interested in true values as per module_flags()
> (since 2.6.25).
> I suspect that there shouldn't be a situation where a module isn't tainted since
> every module is either proprietary license or GPL. However, if this is not
> acceptable I can change this behaviour.
> 
> For module.gpgsig_ok case (as seen in kernel-2.6.32-1.el6), I've decided to follow
> the same logic to highlight "(U)" to the user, as per print_modules().
> With regards to module.sig_ok, this is handled, as seen under 3.8.9-200.fc18:
> 
> 	nf_nat                   G
> 	bnx2i                    G
> 	ip6t_REJECT              G
> 	nf_defrag_ipv6           G
> 	be2iscsi                 G
> 	tun                      G
> 	test                     GFO
> 	
> For pre 2.6.28 kernels, I'll work on a solution that simply displays the bit number
> to then refer the user to the relevant kernel source for details on what the bit
> number means, as per your suggestion. I just wanted to get this version out to the
> mailing list for review.

Right -- it seems reasonable to at least print a hexadecimal value for the
earlier kernels.  The "help mod" output should state something to the effect that
the relevant kernel sources should be consulted for the meaning of either the 
letter(s) or hexadecimal bit-value(s). 

Also, this piece had me scratching my head a little bit:

                if (is_module_taint(lm, buf2, &maxtnts_len)) {
                        fprintf(fp, "%s  ", mkstring(buf1, maxnamelen,
                                LJUST, lm->mod_name));
                        fprintf(fp, "%s\n", mkstring(buf2, maxtnts_len,
                                LJUST, buf2));
                }

Why bother with the "maxtnts_len" business and the mkstring() call for the
taints string?  I understand that the lm->mod_name should be passed to 
mkstring() to keep that field length common (i.e. maxnamelen), but for
the taint string, you can just print it as-is without bothering to do
any kind of justification or worrying about the field length.  Since the
string is left-justified when created, and since it's got nothing to 
display after it, you can just do this:

                        fprintf(fp, "%s  %s", mkstring(buf1, maxnamelen,
                                LJUST, lm->mod_name), buf2);
                    
I'm guessing that it's just a left-over from your earlier patch where
you were squeezing it in the general "mod" display string...

Thanks,
  Dave

           
> Cheers,
> Aaron
> 
> --8<--
> 
>  help.c   |   18 ++++++++-
>  kernel.c |  124
>  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 140 insertions(+), 2 deletion
> 
> 
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux