Date: Sat, 25 Sep 2010 01:49:59 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, pluknet <pluknet@gmail.com>, src-committers@freebsd.org Subject: Re: svn commit: r212723 - head/sys/compat/linprocfs Message-ID: <86d3s2og60.fsf@ds4.des.no> In-Reply-To: <20100924115311.GH34228@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Fri, 24 Sep 2010 14:53:11 %2B0300") References: <201009160756.o8G7uZrg065332@svn.freebsd.org> <AANLkTi=20QDe6o2YxM8PTKOLXB3ZuxUCNQEPtWy9P4Rc@mail.gmail.com> <20100924115311.GH34228@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov <kostikbel@gmail.com> writes: > This is easy to fix, isn't it ? But there seems to be much more nits. > > First, allocating 512 * sizeof(char *)-byte object on the stack is not > good. > > Second, the initialization of iov_len for reading the array > of string pointers misses '* sizeof(char *)'. > > And third (probably fatal) is the lack of checks that the end of > array and each string fits into the user portion of the map. I do not > see why addr that already has u_long type is casted to u_long. Also, > VM_MIN_ADDRESS, VM_MAXUSER_ADDRESS constants are for the native host > FreeBSD ABI, they may differ from the target process limits. Blah, I clearly didn't look closely enough at the final version. The original patch used malloc() but introduced a potential race condition due to having to drop the process lock. I wrote a version that used _PHOLD() / _PRELE() to hold the process across the unlock / malloc / lock window, but the originator had trouble with it (albeit only in qemu, not on real hardware), and I wasn't 100% sure my reasoning was sound, so I accepted his suggested solution. I'll look into this tomorrow. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86d3s2og60.fsf>