<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/scripts/mod/modpost.c, branch v2.6.16</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.16</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.16'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2006-03-17T15:51:25Z</updated>
<entry>
<title>[PATCH] kbuild: fix buffer overflow in modpost</title>
<updated>2006-03-17T15:51:25Z</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@ravnborg.org</email>
</author>
<published>2006-03-17T07:04:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7670f023aabd976c25862e4c6fb9f6d9d2758153'/>
<id>urn:sha1:7670f023aabd976c25862e4c6fb9f6d9d2758153</id>
<content type='text'>
Jiri Benc &lt;jbenc@suse.cz&gt; reported that modpost would stop with SIGABRT if
used with long filepaths.
The error looked like:
&gt;   Building modules, stage 2.
&gt;   MODPOST
&gt; *** glibc detected *** scripts/mod/modpost: realloc(): invalid next size:
+0x0809f588 ***
&gt; [...]

Fix this by allocating at least the required memory + SZ bytes each time.
Before we sometimes ended up allocating too little memory resuting in the
glibc detected bug above.  Based on patch originally submitted by: Jiri
Benc &lt;jbenc@suse.cz&gt;

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>kbuild: set correct KBUILD_MODNAME when using well known kernel symbols as module names</title>
<updated>2005-12-25T23:33:41Z</updated>
<author>
<name>Ustyugov Roman</name>
<email>dr_unique@ymg.ru</email>
</author>
<published>2005-09-23T04:42:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f83b5e323f57d6e1f35a839d663e91cebe985e54'/>
<id>urn:sha1:f83b5e323f57d6e1f35a839d663e91cebe985e54</id>
<content type='text'>
This patch fixes a problem when we use well known kernel symbols as module
names.

For example, if module source name is current.c, idle_stack.c or etc.,
we have a bad KBUILD_MODNAME value.
For example, KBUILD_MODNAME will be "get_current()" instead of "current", or
"(init_thread_union.stack)" instead of "idle_task".

The trick is to define a stringify macro on the commandline - named
KBUILD_STR for namespace reasons - and then to stringify the module
name.

There are a few uses of KBUILD_MODNAME throughout the tree but the usage
is for debug and will not be harmed by this change so left untouched for now.

While at it KBUILD_BASENAME was changed too. Any spinlock usage in the
unix module would have created wrong section names without it.
Usage in spinlock.h fixed so it no longer stringify KBUILD_BASENAME.

Original patch from Ustyogov Roman - all bugs introduced by me.

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
</content>
</entry>
<entry>
<title>kbuild: Fix crc-error warning on modules</title>
<updated>2005-12-25T20:18:11Z</updated>
<author>
<name>Luke Yang</name>
<email>luke.adi@gmail.com</email>
</author>
<published>2005-12-21T02:27:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9572b28faf72859c6b91891c627870cfa282d19d'/>
<id>urn:sha1:9572b28faf72859c6b91891c627870cfa282d19d</id>
<content type='text'>
   This is the patch for the following issue:

 In include/linux/module.h, "__crc_" and "__ksymtab_" are hard
coded to be the   prefix for some kinds of symbols (CRC symbol and
ksymtab section). But in script /mod/modpost.c,
MODULE_SYMBOL_PREFIX##"__crc_" is used as the prefix to search CRC
symbols. So if an architecture (such as h8300 or Blackfin) defines
MODULE_SYMBOL_PREFIX as not NULL ("_"), modpost will always warn about
"no invalid crc".
  And it is the same with KSYMTAB_PFX.

Signed-off-by: Luke Yang &lt;luke.adi@gmail.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
</content>
</entry>
<entry>
<title>[SPARC]: Fix dot-symbol exporting for good.</title>
<updated>2005-09-12T03:14:07Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2005-09-12T03:14:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7caaeabb17758295edff9703c18a840073c5b8f4'/>
<id>urn:sha1:7caaeabb17758295edff9703c18a840073c5b8f4</id>
<content type='text'>
From: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;

Instead of playing all of these hand-coded assembler aliasing games,
just translate symbol names in the name space ".sym" to "_Sym" at
module load time.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC]: Deal with glibc changing macro names in modpost.c</title>
<updated>2005-08-19T20:44:57Z</updated>
<author>
<name>Ben Colline</name>
<email>bcollins@debian.org</email>
</author>
<published>2005-08-19T20:44:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8d5290149ee1c6a4cea5f5146d64e2a0d48f4988'/>
<id>urn:sha1:8d5290149ee1c6a4cea5f5146d64e2a0d48f4988</id>
<content type='text'>
GLIBC 2.3.4 and later changed the STT_REGISTER macro to
STT_SPARC_REGISTER, so we need to cope with that somehow.

Original patch from fabbione, reposted by Ben Collins.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
