From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Subject: Re: [PATCH 2/2] vfs: fix d_path() for unreachable paths Date: Mon, 21 Sep 2009 10:10:17 -0400 Message-ID: <8bd0f97a0909210710h5bb75bcdwb666b51a9155a70a@mail.gmail.com> References: <20090921140220.GD14381@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Miklos Szeredi , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Valdis.Kletnieks@vt.edu, agruen@suse.de, hch@lst.de, hugh.dickins@tiscali.co.uk, matthew@wil.cx To: Al Viro Return-path: In-Reply-To: <20090921140220.GD14381@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Sep 21, 2009 at 10:02, Al Viro wrote: > * blackfin cplbinfo: utter crap; it's used to decide which procfs fil= e > is being opened - by dumping full pathname into a (on-stack) buffer > and then parsing it. =C2=A0Stupid *and* broken. it works without having to copy & paste the same exact structures over and over. a suggestion as how to do it cleanly without bloating the code is certainly welcome. it doesnt really matter that it's on the stack as the usage is small and d_path() is given the size of the buffer, so it isnt going to overflow. > * blackfin traps.c:decode_address(): for one thing, pathnames has bee= n > known to be longer than 256 bytes. we know the paths are longer than 256 bytes. the output is to give a reasonable idea of what is crashing. realistically, nothing executable resides in a 256+ byte path on an embedded system. > =C2=A0For another... locking in that loop > over processes and VMAs of each looks very suspicios, while we are at= it. we've reviewed it several times and exercised it in multiple ways. so unless you have a real idea of something being wrong, the code has been vetted heavily. -mike