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: > > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. > > (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’t think that there was a clear consensus. It gets particularly tricky for _Atomic types, and I think that there’s 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’re likely to end up with the right thing, but it’s 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>