Showing posts with label lkml. Show all posts
Showing posts with label lkml. Show all posts

Sunday, November 14, 2010

Eliminate instructions at compile time trick

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.

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:
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