lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: inline_hunter 0.2 and it's results
Date
[resend, I don't see my mail on lkml.org]

On Tuesday 20 April 2004 00:40, Kevin O'Connor wrote:
> On Fri, Apr 16, 2004 at 10:30:40PM +0300, Denis Vlasenko wrote:
> > Size Uses Wasted Name and definition
> > ===== ==== ====== ================================================
> > 56 461 16560 copy_from_user include/asm/uaccess.h
> > 122 119 12036 skb_dequeue include/linux/skbuff.h
> > 164 78 11088 skb_queue_purge include/linux/skbuff.h
> > 97 141 10780 netif_wake_queue include/linux/netdevice.h
> > 43 468 10741 copy_to_user include/asm/uaccess.h
> > 43 461 10580 copy_from_user include/asm/uaccess.h
>
> Hi Denis,
>
> Why are there two copy_from_user lines?

Good question!

...(/me digs into this)...

Because there are files which has 56 byte copy_from_user().
Namely these:

56 copy_from_user tree/sound/oss/audio.o
56 copy_from_user tree/net/atm/svc.o
56 copy_from_user tree/net/atm/resources.o
56 copy_from_user tree/fs/open.o
56 copy_from_user tree/drivers/video/sstfb.o
56 copy_from_user tree/drivers/video/fbcmap.o
56 copy_from_user tree/drivers/net/pppoe.o

Rest of them (~400 files) has 43 byte one.

disasm, diff of
void inline_copy_from_user_3(void) { copy_from_user(0,0,0); }
yields:
--- copy_from_user_43 Tue Apr 20 23:40:07 2004
+++ copy_from_user_56 Tue Apr 20 23:41:23 2004
@@ -11,11 +11,16 @@
39 5a 18 cmp %ebx,0x18(%edx)
83 d9 00 sbb $0x0,%ecx
85 c9 test %ecx,%ecx
- 75 0b jne XXXX <inline_copy_from_user_3+0x28>
+ 75 0d jne XXXX <inline_copy_from_user_3+0x2a>
31 c9 xor %ecx,%ecx
31 d2 xor %edx,%edx
31 c0 xor %eax,%eax
e8 fc ff ff ff call XXXX <inline_copy_from_user_3+0x24>
+ eb 0b jmp XXXX <inline_copy_from_user_3+0x35>
+ 31 c9 xor %ecx,%ecx
+ 31 d2 xor %edx,%edx
+ 31 c0 xor %eax,%eax
+ e8 4f 01 00 00 call XXXX <__constant_c_and_count_memset>
5b pop %ebx
c9 leave
c3 ret
oops... we've got files which do not honor 'inline' on
__constant_c_and_count_memset()! For example,

fs/open.c:
==========
#include <linux/string.h>
this pulls __constant_c_and_count_memset()
#include <linux/mm.h>
this pulls <compiler.h>, re#defining
inline == __inline__ __attribute__((always_inline)).
too late!
#include <linux/utime.h>
#include <linux/file.h>
#include <linux/smp_lock.h>
#include <linux/quotaops.h>
#include <linux/dnotify.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/namei.h>
#include <linux/backing-dev.h>
#include <linux/security.h>
#include <linux/mount.h>
#include <linux/vfs.h>
#include <asm/uaccess.h>
#include <linux/fs.h>
#include <linux/pagemap.h>
Will do patch tomorrow.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site