linux-kernel - Re: [PATCH 2/3] MEMSTICK: add support for legacy memorysticks

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]

Date:	Mon, 20 Sep 2010 18:16:03 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] MEMSTICK: add support for legacy memorysticks

> 
> None of that explains why we're putting
> non-memstick-specific
> scatterlist infrastructure into the memstick driver, rather
> than into
> the scatterlist code.

In memstick driver this particular approach is used to get the largest
possible chunk of data from the block layer (to minimise the number of
media block accesses, just like with any other flash device driver).

Considering that legacy memstick, in its current state is not part of the
MTD, it well may be that it is not very useful in a general case. I
actually had "iterator style" interface for this sort of thing implemented
(it was operating on bio lists and was intended to mask the
difference between flat buffer and bio list). If there's an interest in
such an interface, either Maxim or me can try and submit it.

> Probably the code you copied from was wrong.  The IDR
> interface is
> really ugly.  All "container class" code which needs
> to allocate memory
> at element-insertion time has this issue.  You
> should've seen all the
> crap we had to do to make insertion of pagecache into
> radix-trees
> reliable :(
> 

It is indeed wrong, but I myself copied it from elsewhere, so back in a
time it was probably the standard approach. However, do you have a quick
advice for a case, were idr_pre_get happens outside spin-locked section,
as opposed to mutex one?

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