linux-kernel - Re: [PATCH] scsi: fix sense

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0804071851230.14273@blonde.site>
Date:	Mon, 7 Apr 2008 19:07:56 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
cc:	James.Bottomley@...senPartnership.com,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	jens.axboe@...cle.com, clameter@....com, penberg@...helsinki.fi,
	a.p.zijlstra@...llo.nl, rjw@...k.pl, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: fix sense_slab/bio swapping livelock

On Mon, 7 Apr 2008, FUJITA Tomonori wrote:
> On Sun, 6 Apr 2008 23:56:57 +0100 (BST)
> Hugh Dickins <hugh@...itas.com> wrote:
> 
> Really sorry about the bug.

No, it's brought attention to this interesting slab merge issue;
even if in the end we decide that's a non-issue.

> > Another alternative is to revert the separate sense_slab, using
> > cache-line-aligned sense_buffer allocated beyond scsi_cmnd from
> > the one kmem_cache; but that might waste more memory, and is
> > only a way of diverting around the known problem.
> 
> Reverting the separate sense_slab is fine for now but we need the
> separation shortly anyway. We need to support larger sense buffer (260
> bytes). The current 96 byte sense buffer works for the majority of us,
> so we doesn't want to embed 260 byte sense buffer in scsi_cmnd struct.

I don't believe you _need_ a separate sense_slab even for that:
what I meant was that you just need something like
	pool->cmd_slab = kmem_cache_create(pool->cmd_name,
					   cache_line_align(
					   sizeof(struct scsi_cmnd)) +
					   max_scsi_sense_buffersize,
					   0, pool->slab_flags, NULL);
then point cmd->sense_buffer to (unsigned char *) cmd +
			cache_line_align(sizeof(struct scsi_cmnd));
where cache_line_align and max_scsi_sense_buffersize are preferably
determined at runtime.

Now, it may well be that over the different configurations, at least
some would waste significant memory by putting it all in the one big
buffer, and you're better off with the separate slabs: so I didn't
want to interfere with your direction on that.

Hugh
--
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/