Skip to content
  1. Dec 01, 2006
  3. Nov 30, 2006
  5. Nov 29, 2006
  7. Nov 28, 2006
  9. Nov 27, 2006
    • Linus Torvalds's avatar
      Fix 'ALIGN()' macro, take 2 · 2ea58144
      Linus Torvalds authored 
      

You wouldn't think that doing an ALIGN() macro that aligns something up
to a power-of-two boundary would be likely to have bugs, would you?

But hey, in the wonderful world of mixing integer types, you have to be
careful.  This just makes sure that the alignment is interpreted in the
same type as the thing to be aligned.

Thanks to Roland Dreier, who noticed that the amso1100 driver got broken
by the previous fix (that just extended the mask to "unsigned long", but
was still broken in "unsigned long long" - it just happened to be the
same on 64-bit architectures).

See commit 4c8bd7ee for the history of
bugs here...

Acked-by: default avatarRoland Dreier <rdreier@cisco.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: David Miller <davem@davemloft.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2ea58144
    • Kyle McMartin's avatar
      [PATCH] Fix incorrent type of flags in <asm/semaphore.h> · c9c3b86f
      Kyle McMartin authored 
      

I still think using BUILD_BUG_ON() is unacceptable, especially given how
vague the error message was.

Signed-off-by: default avatarKyle McMartin <kyle@parisc-linux.org>
[ And I already removed gthe BUILD_BUG_ON() in the previous commit ]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c9c3b86f
    • Linus Torvalds's avatar
      Revert "[PATCH] Enforce "unsigned long flags;" when spinlocking" · b8e6ec86
      Linus Torvalds authored 
      

This reverts commit ee3ce191, since it
broke on at least ARM, MIPS and PA-RISC due to complicated header file
dependencies.

Conflicts in include/linux/spinlock.h (due to the "nested" variety
fixes) fixed up by hand.

Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@parisc-linux.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b8e6ec86
  11. Nov 25, 2006
    • Paul Bonser's avatar
      [NET]: Re-fix of doc-comment in sock.h · dc9b3346
      Paul Bonser authored 
      

Restoring old, correct comment for sk_filter_release, moving it to
where it should actually be, and changing new comment into proper
comment for sk_filter_rcu_free, where it actually makes sense.

The original fix submitted for this on Oct 23 mistakenly documented
the wrong function.

Signed-off-by: default avatarPaul Bonser <misterpib@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc9b3346
    • Arjan van de Ven's avatar
      [PATCH] lockdep: spin_lock_irqsave_nested() · cfd3ef23
      Arjan van de Ven authored 
      Introduce spin_lock_irqsave_nested(); implementation from:
 http://lkml.org/lkml/2006/6/1/122
Patch from:
 http://lkml.org/lkml/2006/9/13/258



[akpm@osdl.org: two compile fixes]
Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: default avatarJiri Kosina <jikos@jikos.cz>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cfd3ef23
    • Alexey Dobriyan's avatar
      [PATCH] Enforce "unsigned long flags;" when spinlocking · ee3ce191
      Alexey Dobriyan authored 
      

Make it break or warn if you pass to spin_lock_irqsave() and friends
something different from "unsigned long flags;".  Suprisingly large amount
of these was caught by recent commit
c53421b1 and others.

Idea is largely from FRV typechecking. Suggestions from Andrew Morton.
All stupid typos in first version fixed.

Passes allmodconfig on i386, x86_64, alpha, arm as well as my usual config.

Note #1: checking with sparse is still needed, because a driver can save
	 and pass around flags or something. So far patch is very intrusive.
Note #2: techically, we should break only if
		sizeof(flags) < sizeof(unsigned long),
	 however, the more pain for getting suspicious code into kernel,
	 the better.

Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ee3ce191
    • Vasily Tarasov's avatar
      [PATCH] mounstats NULL pointer dereference · 701e054e
      Vasily Tarasov authored 
      

OpenVZ developers team has encountered the following problem in 2.6.19-rc6
kernel. After some seconds of running script

while [[ 1 ]]
do
	find  /proc -name mountstats | xargs cat
done

this Oops appears:

BUG: unable to handle kernel NULL pointer dereference at virtual address
00000010
 printing eip:
c01a6b70
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle
iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables
parport_pc lp parport sunrpc af_packet thermal processor fan button battery
asus_acpi ac ohci_hcd ehci_hcd usbcore i2c_nforce2 i2c_core tg3 floppy
pata_amd
ide_cd cdrom sata_nv libata
CPU:    1
EIP:    0060:[<c01a6b70>]    Not tainted VLI
EFLAGS: 00010246   (2.6.19-rc6 #2)
EIP is at mountstats_open+0x70/0xf0
eax: 00000000   ebx: e6247030   ecx: e62470f8   edx: 00000000
esi: 00000000   edi: c01a6b00   ebp: c33b83c0   esp: f4105eb4
ds: 007b   es: 007b   ss: 0068
Process cat (pid: 6044, ti=f4105000 task=f4104a70 task.ti=f4105000)
Stack: c33b83c0 c04ee940 f46a4a80 c33b83c0 e4df31b4 c01a6b00 f4105000 c0169231
       e4df31b4 c33b83c0 c33b83c0 f4105f20 00000003 f4105000 c0169445 f2503cf0
       f7f8c4c0 00008000 c33b83c0 00000000 00008000 c0169350 f4105f20 00008000
Call Trace:
 [<c01a6b00>] mountstats_open+0x0/0xf0
 [<c0169231>] __dentry_open+0x181/0x250
 [<c0169445>] nameidata_to_filp+0x35/0x50
 [<c0169350>] do_filp_open+0x50/0x60
 [<c01873d6>] seq_read+0xc6/0x300
 [<c0169511>] get_unused_fd+0x31/0xc0
 [<c01696d3>] do_sys_open+0x63/0x110
 [<c01697a7>] sys_open+0x27/0x30
 [<c01030bd>] sysenter_past_esp+0x56/0x79
 =======================
Code: 45 74 8b 54 24 20 89 44 24 08 8b 42 f0 31 d2 e8 47 cb f8 ff 85 c0 89 c3
74 51 8d 80 a0 04 00 00 e8 46 06 2c 00 8b 83 48 04 00 00 <8b> 78 10 85 ff 74
03
f0 ff 07 b0 01 86 83 a0 04 00 00 f0 ff 4b
EIP: [<c01a6b70>] mountstats_open+0x70/0xf0 SS:ESP 0068:f4105eb4

The problem is that task->nsproxy can be equal NULL for some time during
task exit. This patch fixes the BUG.

Signed-off-by: default avatarVasily Tarasov <vtaras@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      701e054e
  13. Nov 22, 2006
  15. Nov 20, 2006
  17. Nov 19, 2006
  19. Nov 16, 2006
  21. Nov 15, 2006
  23. Nov 14, 2006
    • Hugh Dickins's avatar
      [PATCH] hugetlb: prepare_hugepage_range check offset too · 68589bc3
      Hugh Dickins authored 
      

(David:)

If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example,
because the given file offset is not hugepage aligned - then do_mmap_pgoff
will go to the unmap_and_free_vma backout path.

But at this stage the vma hasn't been marked as hugepage, and the backout path
will call unmap_region() on it.  That will eventually call down to the
non-hugepage version of unmap_page_range().  On ppc64, at least, that will
cause serious problems if there are any existing hugepage pagetable entries in
the vicinity - for example if there are any other hugepage mappings under the
same PUD.  unmap_page_range() will trigger a bad_pud() on the hugepage pud
entries.  I suspect this will also cause bad problems on ia64, though I don't
have a machine to test it on.

(Hugh:)

prepare_hugepage_range() should check file offset alignment when it checks
virtual address and length, to stop MAP_FIXED with a bad huge offset from
unmapping before it fails further down.  PowerPC should apply the same
prepare_hugepage_range alignment checks as ia64 and all the others do.

Then none of the alignment checks in hugetlbfs_file_mmap are required (nor
is the check for too small a mapping); but even so, move up setting of
VM_HUGETLB and add a comment to warn of what David Gibson discovered - if
hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region
when unwinding from error will go the non-huge way, which may cause bad
behaviour on architectures (powerpc and ia64) which segregate their huge
mappings into a separate region of the address space.

Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: default avatarAdam Litke <agl@us.ibm.com>
Acked-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      68589bc3