Date: Wed, 5 Jun 2013 09:52:24 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: aio_mlock(2) system call Message-ID: <20130605093622.L11224@besplex.bde.org> In-Reply-To: <20130604191152.GW3047@kib.kiev.ua> References: <20130603100618.GH67170@FreeBSD.org> <20130603161255.GM3047@kib.kiev.ua> <20130604113035.GV67170@glebius.int.ru> <20130604191152.GW3047@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Jun 2013, Konstantin Belousov wrote: > On Tue, Jun 04, 2013 at 03:30:35PM +0400, Gleb Smirnoff wrote: >> Updated patch. >> > I have no further comments. > > You might want to make the switch of double casts to DEVOLATILE() > in the other parts of vfs_aio.c as separate commit. DEVOLATILE() should only be committed to /dev/null. It masks API bugs. An ordinary cast is sufficiently ugly and doesn't break detection of the bugs by -Wcast-qual. If a variable is actually volatile, then casting away its volatile'ness breaks it. The breakage is larger than with casting away const. But I think that with aio, the bug is using the application API in the kernel. The buffer is volatile in userland but isn't really volatile in the kernel (no more than any buffer that may be written to by DMA. Others are mostly not declared volatile). uio has sort of the opposite problem. It is older than const and void, so it cannot use them. More fundamentally, it only has a single i/o pointer so the pointer cannot be const since it is used for input. But when writing, the source buffer may be const or even volatile. Its pointer cannot be assigned to the uio pointer without casting away qualifiers. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130605093622.L11224>