linux-kernel - Re: scsi_debug: shared dev context, BUG or FEATURE?

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 27 Mar 2017 21:41:17 -0400
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, dgilbert@...erlog.com,
        martin.petersen@...cle.com
Subject: Re: scsi_debug: shared dev context, BUG or FEATURE?

Dmitry Monakhov <dmonakhov@...nvz.org> writes:

Dmitry,

> scsi_debug has very strange structure from one point it supports
> dynamic number of devices but from other point context is common for
> all devices:

> So basically we may have many devices with single context which refers
> common data. Are any sane reason to share context between devices?
> Who use such behaviour?

As the name implies, scsi_debug was conceived to debug the SCSI layer.
Among other things, the intent was to be able to test hundreds of
controllers and LUNs without having physical hardware or storage to back
that up. Plus to have a target whose reporting could easily be tweaked
to test the SCSI core code.

So that's the reason for the oddball shared buffer setup. scsi_debug
wasn't really meant to be a "useful" storage target.

If you want something with a per-device backing store I suggest you look
at the SCSI target subsystem. With tcm_loop and ramdisk you get
essentially the same thing as scsi_debug. With the added bonus that you
can use files or block devices if you actually want the data to be
persistent.

> IMHO this is a pure bug. Please correct me if I'm wrong, I'll plan to
> fix that by allocation separate context for each dev. 

I don't have a problem with allowing it as an option as long as the
original behavior can be preserved. But again, I think target mode is a
better bet if you actually care about what's being stored on the
"media".

-- 
Martin K. Petersen	Oracle Linux Engineering