Date: Tue, 5 Jul 2016 09:30:24 +0100 From: David Chisnall <David.Chisnall@cl.cam.ac.uk> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Ed Schouten <ed@nuxi.nl>, Benjamin Kaduk <bjkfbsd@gmail.com>, Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kostikbel@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r302252 - head/sys/kern Message-ID: <453A6F3B-6488-4ACC-AD82-60E4AE7A150A@cl.cam.ac.uk> In-Reply-To: <CAJ-Vmo=1-PbZWdB%2B06bqMH3WBQ-pU6tyR8FjH5eVksVmxb3yQA@mail.gmail.com> References: <201606281643.u5SGhNsi061606@repo.freebsd.org> <20160629175917.O968@besplex.bde.org> <20160629145443.GG38613@kib.kiev.ua> <20160629153233.GI38613@kib.kiev.ua> <20160630040123.F791@besplex.bde.org> <20160629211953.GK38613@kib.kiev.ua> <20160701005401.Q1084@besplex.bde.org> <20160630180106.GU38613@kib.kiev.ua> <20160701031549.GV38613@kib.kiev.ua> <20160701185743.Q1600@besplex.bde.org> <20160701142516.GW38613@kib.kiev.ua> <20160702153817.O1458@besplex.bde.org> <CAJ5_RoA-d8YGeFHEiGziOU6VutfuX6cHh%2BJ4YGYPcLhVv77B3w@mail.gmail.com> <CABh_MKmjSJoLYMAsrtgxfZVpedpX9wDz7osFrsz63qawdOkWLQ@mail.gmail.com> <CABh_MKm1Zat%2By22O5JfBX9vt8=e5dmULqUUELHZXHMpVAjopDA@mail.gmail.com> <CAJ-VmokVp8QmKX6VRMeKn=Er_SG7V=MNJVHyzr%2ByXcN6cRstYw@mail.gmail.com> <CABh_MKmvGFy81ws8G4N-cMPLMYhVVkVzZfQAK2SwAZsxRu%2Bpag@mail.gmail.com> <CAJ-Vmo=1-PbZWdB%2B06bqMH3WBQ-pU6tyR8FjH5eVksVmxb3yQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Jul 2016, at 21:09, Adrian Chadd <adrian.chadd@gmail.com> wrote: >=20 > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. >=20 > (I asked this question because I've been screwed by it recentlyish, > and it looks like the latest C standard didn't fix it..) It was discussed at the WG14 meeting in London in April, but I don=E2=80=99= t think that there was a clear consensus. It gets particularly tricky = for _Atomic types, and I think that there=E2=80=99s now a clarification = (or will be in C2x, if not) that any padding in _Atomic types is zeroed. Generally, compilers will turn this into a bzero and then a set of the = remaining fields, so you=E2=80=99re likely to end up with the right = thing, but it=E2=80=99s not guaranteed by the standard. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?453A6F3B-6488-4ACC-AD82-60E4AE7A150A>