linux-kernel - SCSI logging sucks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <45CA0716.5060803@redhat.com>
Date:	Wed, 07 Feb 2007 12:06:30 -0500
From:	Chuck Ebbert <cebbert@...hat.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org
Subject: SCSI logging sucks

SCSI logging isn't documented very well, and what little there is
has a problem:

In Documentation/kernel-parameters.txt we have:

        scsi_logging=   [SCSI]

but it's really "scsi_logging_level", as seen here in drivers/scsi/scsi.c:

 module_param(scsi_logging_level, int, S_IRUGO|S_IWUSR);
 MODULE_PARM_DESC(scsi_logging_level, "a bit mask of logging levels");

Not exactly helpful. And the sysctl is called:

    /proc/sys/dev/scsi/logging_level

Using scsi_logging.h, I came up with this:

                0000 0000 0000 0000 0000 0000 0000 0000
       0x7                                          111  Error
      0x38                                      11 1     Timeout
     0x1c0                                  1 11         Scan
     0xe00                               111             Midlevel queue
    0x7000                           111                 Midlevel
completions
   0x38000                       11 1                    Lowlevel queue
  0x1c0000                   1 11                        Lowlevel
completions
  0xe00000                111                            Highlevel queue
 0x7000000            111                                Highlevel
completions
0x38000000        11 1                                   IOCTL

but I'm not sure if it's right.

And the actual implementation looks backwards, at least for highlevel
events. You need to set the level to 800000 to see driver loads and
that means wading through tons of extraneous crap.  The logging
should show more verbosity at the higher numbers, not start
out with the most verbose output at the low numbers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/