Commit Graph

4 Commits

Author SHA1 Message Date
Yoann Padioleau dd00cc486a some kmalloc/memset ->kzalloc (tree wide)
Transform some calls to kmalloc/memset to a single kzalloc (or kcalloc).

Here is a short excerpt of the semantic patch performing
this transformation:

@@
type T2;
expression x;
identifier f,fld;
expression E;
expression E1,E2;
expression e1,e2,e3,y;
statement S;
@@

 x =
- kmalloc
+ kzalloc
  (E1,E2)
  ...  when != \(x->fld=E;\|y=f(...,x,...);\|f(...,x,...);\|x=E;\|while(...) S\|for(e1;e2;e3) S\)
- memset((T2)x,0,E1);

@@
expression E1,E2,E3;
@@

- kzalloc(E1 * E2,E3)
+ kcalloc(E1,E2,E3)

[akpm@linux-foundation.org: get kcalloc args the right way around]
Signed-off-by: Yoann Padioleau <padator@wanadoo.fr>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Acked-by: Russell King <rmk@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@analog.com>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Acked-by: Roland Dreier <rolandd@cisco.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Acked-by: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: Greg KH <greg@kroah.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 10:04:50 -07:00
Ivan Kokshaysky 1b75b05b73 alpha: fixes for specific machine types
Files:

arch/alpha/kernel/core_mcpcia.c
arch/alpha/kernel/sys_rawhide.c
include/asm-alpha/core_mcpcia.h

	Determine correct hose configuration; RAWHIDE family can have
        2 or 4 hoses, so make sure non-existent hoses are ignored.

arch/alpha/kernel/err_titan.c

	Supply a needed #include <asm/irq_regs.h>

arch/alpha/kernel/module.c

	Add some useful output to the relocation overflow messages.

arch/alpha/kernel/sys_noritake.c

	Supply necessary noritake_end_irq() to correct interrupt handling.
	This fixes a problem first noted by hangs during boot probing with
	a DE500-BA TULIP NIC present.

arch/alpha/kernel/sys_sio.c

	Correct saving of original PIRQ register (PCI IRQ routing);
	change default PIRQ setting to leave PCI IRQs 9 and 14 free to
	be used for sound (Multia) and IDE (any), respectively.

include/asm-alpha/io.h

	Supply the "isa_virt_to_bus" routine.

Signed-off-by: Jay Estabrook <jay.estabrook@hp.com>
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-04-17 16:36:27 -07:00
Chaskiel Grundman 69ac59647e [PATCH] alpha: process_reloc_for_got confuses r_offset and r_addend
arch/alpha/kernel/module.c:process_reloc_for_got(), which figures out how big
the .got section for a module should be, appears to be confusing r_offset (the
file offset that the relocation needs to be applied to) with r_addend (the
offset of the relocation's actual target address from the address of the
relocation's symbol).  Because of this, one .got entry is allocated for each
relocation instead of one each unique symbol/addend.

In the module I am working with, this causes the .got section to be almost 10
times larger than it needs to be (75544 bytes instead of 7608 bytes).  As the
.got is accessed with global-pointer-relative instructions, it needs to be
within the 64k gp "zone", and a 75544 byte .got clearly does not fit.  The
result of this is that relocation overflows are detected during module load
and the load is aborted.

Change struct got_entry/process_reloc_for_got to fix this.

Acked-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:57:30 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00