All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek-AlSwsSmVLrQ@public.gmane.org>
To: Jan Beulich <JBeulich-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
	tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-modules-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] reduce export symbol CRC table size on 64-bit archs
Date: Fri, 03 Jul 2009 22:16:28 +0200	[thread overview]
Message-ID: <4A4E671C.2090201@suse.cz> (raw)
In-Reply-To: <4A4A18780200007800008345-Qfbpwmsw6RoS3W1tAdPHOtBPR1lH4CV8@public.gmane.org>

Jan Beulich napsal(a):
> Since these CRCs are really only 32-bit quantities, there's no need to
> store them in 64-bit slots. Since, however, gcc doesn't allow
> respective initializations, asm() constructs get used to create the CRC
> tables (and its for that reason that the patch only makes x86-64 and
> ia64 utilize that functionality, as I can't verify this doesn't break
> in some subtle way elsewhere).
> 
...
>  struct modversion_info
>  {
> -	unsigned long crc;
> +	ksym_crc_t crc;
>  	char name[MODULE_NAME_LEN];
>  };

This change breaks module-init-tools:
Before:
$ /sbin/modprobe --dump-modversions _build/drivers/usb/core/usbcore.ko
| head
0xb49b735a      module_layout
0xdb7e6a70      bus_register
0xe3a25bcc      device_remove_file
0x1fedf0f4      __request_region
0x37429b3b      device_remove_bin_file
0x27ac237c      cdev_del
0xf3be63b3      per_cpu__current_task
0x26b76a45      kmalloc_caches
0x5a34a45c      __kmalloc
0x1c820358      cdev_init

After:
$ /sbin/modprobe --dump-modversions
_build-crc-int/drivers/usb/core/usbcore.ko  | head
0x75646f6d91ea7b5c      le_layout
0x5f7375623e215f43      register
0x69766564848c67e2      ce_remove_file
0x65725f5f1fedf0f4      quest_region
0x69766564a0c29c25      ce_remove_bin_file
0x766564633ce98bc2      _del
0x5f72657012c9615b      cpu__current_task
0x6c616d6b6ea6c464      loc_caches
0x6d6b5f5f5a34a45c      alloc
0x766564631e5d885b      _init

It also breaks the newly added depmod -E option (check symbol versions),
which also reads the struct modversion_info array (*). Is it possible
name the section differently (__versions2?) on those architectures where
the size changes, so that it is possible to fix m-i-t in a
backwards-compatible manner?

Michal


(*) dump_modvers() and load_symbols() in
http://git.kernel.org/?p=utils/kernel/module-init-tools/module-init-tools.git;a=blob;f=elfops_core.c;hb=HEAD
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Michal Marek <mmarek@suse.cz>
To: Jan Beulich <JBeulich@novell.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	tony.luck@intel.com, Thomas Gleixner <tglx@linutronix.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	hpa@zytor.com, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org
Subject: Re: [PATCH] reduce export symbol CRC table size on 64-bit archs
Date: Fri, 03 Jul 2009 22:16:28 +0200	[thread overview]
Message-ID: <4A4E671C.2090201@suse.cz> (raw)
Message-ID: <20090703201628.G7WInLirDCNd-3dOdvT2KtpQngdUd-_A2CFztVcjOes@z> (raw)
In-Reply-To: <4A4A18780200007800008345@vpn.id2.novell.com>

Jan Beulich napsal(a):
> Since these CRCs are really only 32-bit quantities, there's no need to
> store them in 64-bit slots. Since, however, gcc doesn't allow
> respective initializations, asm() constructs get used to create the CRC
> tables (and its for that reason that the patch only makes x86-64 and
> ia64 utilize that functionality, as I can't verify this doesn't break
> in some subtle way elsewhere).
> 
...
>  struct modversion_info
>  {
> -	unsigned long crc;
> +	ksym_crc_t crc;
>  	char name[MODULE_NAME_LEN];
>  };

This change breaks module-init-tools:
Before:
$ /sbin/modprobe --dump-modversions _build/drivers/usb/core/usbcore.ko
| head
0xb49b735a      module_layout
0xdb7e6a70      bus_register
0xe3a25bcc      device_remove_file
0x1fedf0f4      __request_region
0x37429b3b      device_remove_bin_file
0x27ac237c      cdev_del
0xf3be63b3      per_cpu__current_task
0x26b76a45      kmalloc_caches
0x5a34a45c      __kmalloc
0x1c820358      cdev_init

After:
$ /sbin/modprobe --dump-modversions
_build-crc-int/drivers/usb/core/usbcore.ko  | head
0x75646f6d91ea7b5c      le_layout
0x5f7375623e215f43      register
0x69766564848c67e2      ce_remove_file
0x65725f5f1fedf0f4      quest_region
0x69766564a0c29c25      ce_remove_bin_file
0x766564633ce98bc2      _del
0x5f72657012c9615b      cpu__current_task
0x6c616d6b6ea6c464      loc_caches
0x6d6b5f5f5a34a45c      alloc
0x766564631e5d885b      _init

It also breaks the newly added depmod -E option (check symbol versions),
which also reads the struct modversion_info array (*). Is it possible
name the section differently (__versions2?) on those architectures where
the size changes, so that it is possible to fix m-i-t in a
backwards-compatible manner?

Michal


(*) dump_modvers() and load_symbols() in
http://git.kernel.org/?p=utils/kernel/module-init-tools/module-init-tools.git;a=blob;f=elfops_core.c;hb=HEAD

  parent reply	other threads:[~2009-07-03 20:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-30 11:51 [PATCH] reduce export symbol CRC table size on 64-bit archs Jan Beulich
2009-06-30 11:51 ` Jan Beulich
2009-06-30 22:09 ` Ingo Molnar
2009-07-01  5:00 ` Rusty Russell
2009-07-01  7:00   ` Jan Beulich
2009-07-01  7:00     ` Jan Beulich
     [not found] ` <4A4A18780200007800008345-Qfbpwmsw6RoS3W1tAdPHOtBPR1lH4CV8@public.gmane.org>
2009-07-03 20:16   ` Michal Marek [this message]
2009-07-03 20:16     ` Michal Marek
2009-07-06  7:42     ` Jan Beulich
2009-07-06  7:42       ` Jan Beulich
     [not found]       ` <4A51C71B0200007800008EE2-Qfbpwmsw6RoS3W1tAdPHOtBPR1lH4CV8@public.gmane.org>
2009-07-09 11:14         ` Rusty Russell
2009-07-09 11:14           ` Rusty Russell
2009-07-10  7:23           ` Jan Beulich
2009-07-10  7:23             ` Jan Beulich
     [not found]             ` <4A57089B0200007800009C0E-Qfbpwmsw6RoS3W1tAdPHOtBPR1lH4CV8@public.gmane.org>
2009-07-10 14:36               ` H. Peter Anvin
2009-07-10 14:36                 ` H. Peter Anvin
2009-07-10 15:50               ` Jon Masters
2009-07-10 15:50                 ` Jon Masters
2009-07-13  8:11               ` Michal Marek
2009-07-13  8:11                 ` Michal Marek
2009-07-13  8:44                 ` Jan Beulich
2009-07-13  8:44                   ` Jan Beulich
     [not found]                   ` <4A5B101E020000780000A284-Qfbpwmsw6RoS3W1tAdPHOtBPR1lH4CV8@public.gmane.org>
2009-07-14 10:29                     ` Jon Masters
2009-07-14 10:29                       ` Jon Masters
     [not found]                       ` <1247567372.31188.229.camel-gHXTUq7nJ1kAgR79ElizB2+biTydnCM9ILAQCsJbaHk@public.gmane.org>
2009-07-14 10:44                         ` Marco d'Itri
2009-07-14 10:44                           ` Marco d'Itri
2009-07-14 16:43                       ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A4E671C.2090201@suse.cz \
    --to=mmarek-alswssmvlrq@public.gmane.org \
    --cc=JBeulich-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-modules-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mingo-X9Un+BFzKDI@public.gmane.org \
    --cc=rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.