Vasiliy Kulikov noted a bug in select code and proposed a fix:
[..] struct timeval has padding bytes at the end. This struct is copied to
userspace with these padding bytes uninitialized. This leads to leaking
of contents of kernel stack memory.
--- a/fs/select.c
+++ b/fs/select.c
@@ -306,6 +306,7 @@ static int poll_select_copy_remaining(struct timespec
*end_time, void __user *p,
rts.tv_sec = rts.tv_nsec = 0;
if (timeval) {
+ memset(&rtv, 0, sizeof(rtv));
rtv.tv_sec = rts.tv_sec;
rtv.tv_usec = rts.tv_nsec / NSEC_PER_USEC;
Andrew Morton noted that
| struct timeval has padding bytes at the end.
On sparc and parisc. On all other architectures this patch is a waste
of cycles.
And came up with this patch:
if (timeval) {
- memset(&rtv, 0, sizeof(rtv));
+ if (sizeof(rtv) > sizeof(rtv.tv_sec) + sizeof(rtv.tv_usec))
+ memset(&rtv, 0, sizeof(rtv));
rtv.tv_sec = rts.tv_sec;
rtv.tv_usec = rts.tv_nsec / NSEC_PER_USEC;
The `if' gets eliminated at compile time. With this approach we add
four bytes of text to the sparc64 build and zero bytes of text to the
x86_64 build.
Showing posts with label lkml. Show all posts
Showing posts with label lkml. Show all posts
Sunday, November 14, 2010
Monday, November 8, 2010
"We sometimes do this trick"
Recently on lkml we had a patch proposal by Don Zickus.
I had a minor nit, because I thought that it does make sense
to simplify this loop
touch_all_nmi_watchdogs:
...
for_each_present_cpu(cpu) {
if (per_cpu(watchdog_nmi_touch, cpu) != true)
per_cpu(watchdog_nmi_touch, cpu) = true;
}
to
for_each_present_cpu(cpu) {
per_cpu(watchdog_nmi_touch, cpu) = true;
}
Andrew Morton wrote in responce:
This is really reasonable. Once again, try to think in opposite
each time you make a decision.
I had a minor nit, because I thought that it does make sense
to simplify this loop
touch_all_nmi_watchdogs:
...
for_each_present_cpu(cpu) {
if (per_cpu(watchdog_nmi_touch, cpu) != true)
per_cpu(watchdog_nmi_touch, cpu) = true;
}
to
for_each_present_cpu(cpu) {
per_cpu(watchdog_nmi_touch, cpu) = true;
}
Andrew Morton wrote in responce:
We sometimes do this trick to avoid dirtying lots of cachelines
which already held the correct value. It'll be extra-benefical
when dealing with other CPU's data, I expect.
This is really reasonable. Once again, try to think in opposite
each time you make a decision.
Wednesday, September 22, 2010
Miklos Szeredi: memory barrier question
Miklos Szeredi posted a question about memory barriers (lkml).
Which lead to an interesting discussion on memory barriers, compilers
and the Universe.
Please read lkml.org/lkml/2010/9/15/223
Which lead to an interesting discussion on memory barriers, compilers
and the Universe.
Please read lkml.org/lkml/2010/9/15/223
Subscribe to:
Posts (Atom)