linux-kernel - Re: [PATCH] physmap: Fix leak of memory returned by parse_mtd

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:	Tue, 18 Nov 2008 13:57:27 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Atsushi Nemoto <anemo@....ocn.ne.jp>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] physmap: Fix leak of memory returned by
	parse_mtd_partitions

On Wed, 2008-11-12 at 11:08 -0500, Mike Frysinger wrote:
> i wonder why we duplicate this same code block in so many places.  and
> why does every driver have to declare its own list of parsers ?  cant
> we unify all of these in one place ?

Well, most boards only really want _one_ partition type; maybe two. And
the probes can be quite expensive and have false positives, so we don't
want to be doing all the probes for all devices.

It might make sense to just pass a bitmask indicating which partition
probes to use. Assuming we can agree on an ordering, that is :)

Another complication is that some boards have registered the whole
device first, while others have just registered the partitions.

I suspect it might be better to take the simple bug-fix approach for
now, given that we are planning a revamp of the MTD core API anyway --
we can redo partitions properly at the point, so they aren't just an
evil hack.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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