From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
hare@suse.de
Subject: Re: [PATCH v2] scsi_debug: randomize command duration option + %p
Date: Tue, 01 Oct 2019 00:28:52 -0400 [thread overview]
Message-ID: <yq1v9t9um0r.fsf@oracle.com> (raw)
In-Reply-To: <74305c57-1d8e-5829-9bcf-db02fc97a7fb@interlog.com> (Douglas Gilbert's message of "Mon, 30 Sep 2019 22:42:39 -0400")
Doug,
>> Since sdebug_random is either 0 or 1, is the "? 1 : 0" part necessary?
>
> No.
> Why didn't you complain when MKP wrote that? That is where I cut and
> pasted that code from (sdebug_removable).
[...]
> Again, copy and paste from MKP's code (which no doubt was a copy +
> paste from my earlier code).
I'll be the first to admit that I make mistakes and almost always
blindly copy surrounding plumbing when I hack on scsi_debug. However, I
am not responsible for the commit that introduced any of this code.
Also, in defense of the original author, our coding practices were
obviously different when this was written many years ago.
>>> @@ -5338,7 +5373,7 @@ static int __init scsi_debug_init(void)
>>> dif_size = sdebug_store_sectors * sizeof(struct t10_pi_tuple);
>>> dif_storep = vmalloc(dif_size);
>>> - pr_err("dif_storep %u bytes @ %p\n", dif_size, dif_storep);
>>> + pr_err("dif_storep %u bytes @ %pK\n", dif_size, dif_storep);
>>> if (dif_storep == NULL) {
>>> pr_err("out of mem. (DIX)\n");
>>
>> Is it useful to print the kernel pointer 'dif_storep'?
>
> Ask MKP, it's his code. All I do know is that doing a printk("%p" ...)
> is useless in lk 5.3 (and probably lk 5.2). Taking the above snippet,
> if vmalloc() returned NULL then the existing pr_err() would print out
> a random number rather than <null>. Sick ...
This used to be somewhat useful for debugging purposes in combination
with the ability to dump the buffer to inspect the PI. In this day and
age with obfuscated kernel pointers, not so much. I suggest just
removing the line. Or--if people feel the size is valuable
information--just zap the pointer. Also, since this is unrelated to the
duration randomization it should be a separate patch.
Thanks!
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2019-10-01 4:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 14:04 [PATCH v2] scsi_debug: randomize command duration option + %p Douglas Gilbert
2019-09-30 15:46 ` Bart Van Assche
2019-10-01 2:42 ` Douglas Gilbert
2019-10-01 4:28 ` Martin K. Petersen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq1v9t9um0r.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=bvanassche@acm.org \
--cc=dgilbert@interlog.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).