Skip to content
  1. Jan 27, 2009
  3. Jan 26, 2009
    • Miklos Szeredi's avatar
      fuse: fix poll notify · f6d47a17
      Miklos Szeredi authored 
      

Move fuse_copy_finish() to before calling fuse_notify_poll_wakeup().
This is not a big issue because fuse_notify_poll_wakeup() should be
atomic, but it's cleaner this way, and later uses of notification will
need to be able to finish the copying before performing some actions.

Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      f6d47a17
    • Miklos Szeredi's avatar
      fuse: destroy bdi on umount · 26c36791
      Miklos Szeredi authored 
      

If a fuse filesystem is unmounted but the device file descriptor
remains open and a new mount reuses the old device number, then the
mount fails with EEXIST and the following warning is printed in the
kernel log:

  WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x35/0x3d()
  sysfs: duplicate filename '0:15' can not be created

The cause is that the bdi belonging to the fuse filesystem was
destoryed only after the device file was released.  Fix this by
calling bdi_destroy() from fuse_put_super() instead.

Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
CC: stable@kernel.org
      26c36791
    • Miklos Szeredi's avatar
      fuse: fuse_fill_super error handling cleanup · c2b8f006
      Miklos Szeredi authored 
      

Clean up error handling for the whole of fuse_fill_super() function.

Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      c2b8f006
    • Miklos Szeredi's avatar
      fuse: fix missing fput on error · 3ddf1e7f
      Miklos Szeredi authored 
      

Fix the leaking file reference if allocation or initialization of
fuse_conn failed.

Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
CC: stable@kernel.org
      3ddf1e7f
    • Dan Carpenter's avatar
      fuse: fix NULL deref in fuse_file_alloc() · bb875b38
      Dan Carpenter authored 
      

ff is set to NULL and then dereferenced on line 65.  Compile tested only.

Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
CC: stable@kernel.org
      bb875b38
    • Ian Campbell's avatar
      xen: unitialised return value in xenbus_write_transaction · e88a0faa
      Ian Campbell authored 
      

The return value of xenbus_write_transaction can be uninitialised in
the success case leading to the userspace xenstore utilities failing.

Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e88a0faa
    • Rakib Mullick's avatar
      x86: fix section mismatch warning · 659d2618
      Rakib Mullick authored 
      

Here function vmi_activate calls a init function activate_vmi , which
causes the following section mismatch warnings:

  LD      arch/x86/kernel/built-in.o
WARNING: arch/x86/kernel/built-in.o(.text+0x13ba9): Section mismatch
in reference from the function vmi_activate() to the function
.init.text:vmi_time_init()
The function vmi_activate() references
the function __init vmi_time_init().
This is often because vmi_activate lacks a __init
annotation or the annotation of vmi_time_init is wrong.

WARNING: arch/x86/kernel/built-in.o(.text+0x13bd1): Section mismatch
in reference from the function vmi_activate() to the function
.devinit.text:vmi_time_bsp_init()
The function vmi_activate() references
the function __devinit vmi_time_bsp_init().
This is often because vmi_activate lacks a __devinit
annotation or the annotation of vmi_time_bsp_init is wrong.

WARNING: arch/x86/kernel/built-in.o(.text+0x13bdb): Section mismatch
in reference from the function vmi_activate() to the function
.devinit.text:vmi_time_ap_init()
The function vmi_activate() references
the function __devinit vmi_time_ap_init().
This is often because vmi_activate lacks a __devinit
annotation or the annotation of vmi_time_ap_init is wrong.

Fix it by marking vmi_activate() as __init too.

Signed-off-by: default avatarRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      659d2618
    • Ingo Molnar's avatar
      x86: unmask CPUID levels on Intel CPUs, fix · 99fb4d34
      Ingo Molnar authored 
      

Impact: fix boot hang on pre-model-15 Intel CPUs

rdmsrl_safe() does not work in very early bootup code yet, because we
dont have the pagefault handler installed yet so exception section
does not get parsed. rdmsr_safe() will just crash and hang the bootup.

So limit the MSR_IA32_MISC_ENABLE MSR read to those CPU types that
support it.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      99fb4d34
    • Eric Anholt's avatar
      x86: work around PAGE_KERNEL_WC not getting WC in iomap_atomic_prot_pfn. · ef5fa0ab
      Eric Anholt authored 
      

In the absence of PAT, PAGE_KERNEL_WC ends up mapping to a memory type that
gets UC behavior even in the presence of a WC MTRR covering the area in
question.  By swapping to PAGE_KERNEL_UC_MINUS, we can get the actual
behavior the caller wanted (WC if you can manage it, UC otherwise).

This recovers the 40% performance improvement of using WC in the DRM
to upload vertex data.

Signed-off-by: default avatarEric Anholt <eric@anholt.net>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      ef5fa0ab
  5. Jan 25, 2009
    • Ingo Molnar's avatar
      x86: use standard PIT frequency · e1b4d114
      Ingo Molnar authored 
      

the RDC and ELAN platforms use slighly different PIT clocks, resulting in
a timex.h hack that changes PIT_TICK_RATE during build time. But if a
tester enables any of these platform support .config options, the PIT
will be miscalibrated on standard PC platforms.

So use one frequency - in a subsequent patch we'll add a quirk to allow
x86 platforms to define different PIT frequencies.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e1b4d114
  7. Jan 24, 2009
    • Ian Campbell's avatar
      xen: handle highmem pages correctly when shrinking a domain · ff4ce8c3
      Ian Campbell authored 
      

Commit 1058a75f ("xen: actually release
memory when shrinking domain") causes a crash if the page being released
is a highmem page.

If a page is highmem then there is no need to unmap it.

Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ff4ce8c3
    • Peter Zijlstra's avatar
      x86, mm: fix pte_free() · 42ef73fe
      Peter Zijlstra authored 
      

On -rt we were seeing spurious bad page states like:

Bad page state in process 'firefox'
page:c1bc2380 flags:0x40000000 mapping:c1bc2390 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 503, comm: firefox Not tainted 2.6.26.8-rt13 #3
[<c043d0f3>] ? printk+0x14/0x19
[<c0272d4e>] bad_page+0x4e/0x79
[<c0273831>] free_hot_cold_page+0x5b/0x1d3
[<c02739f6>] free_hot_page+0xf/0x11
[<c0273a18>] __free_pages+0x20/0x2b
[<c027d170>] __pte_alloc+0x87/0x91
[<c027d25e>] handle_mm_fault+0xe4/0x733
[<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
[<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
[<c0218875>] do_page_fault+0x36f/0x88a

This is the case where a concurrent fault already installed the PTE and
we get to free the newly allocated one.

This is due to pgtable_page_ctor() doing the spin_lock_init(&page->ptl)
which is overlaid with the {private, mapping} struct.

union {
    struct {
        unsigned long private;
        struct address_space *mapping;
    };
    spinlock_t ptl;
    struct kmem_cache *slab;
    struct page *first_page;
};

Normally the spinlock is small enough to not stomp on page->mapping, but
PREEMPT_RT=y has huge 'spin'locks.

But lockdep kernels should also be able to trigger this splat, as the
lock tracking code grows the spinlock to cover page->mapping.

The obvious fix is calling pgtable_page_dtor() like the regular pte free
path __pte_free_tlb() does.

It seems all architectures except x86 and nm10300 already do this, and
nm10300 doesn't seem to use pgtable_page_ctor(), which suggests it
doesn't do SMP or simply doesnt do MMU at all or something.

Signed-off-by: default avatarPeter Zijlstra <a.p.zijlsta@chello.nl>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
      42ef73fe
    • Takashi Iwai's avatar
      Merge branch 'fix/asoc' into for-linus · 0f0779b1
      Takashi Iwai authored
      0f0779b1
  9. Jan 23, 2009
  11. Jan 22, 2009
  13. Jan 21, 2009
    • Thomas Renninger's avatar
      x86: mtrr fix debug boot parameter · 731f1872
      Thomas Renninger authored 
      while looking at:

  http://bugzilla.kernel.org/show_bug.cgi?id=11541



I realized that the mtrr.show param cannot work, because
the code is processed much too early.

This patch:
 - Declares mtrr.show as early_param
 - Stays consistent with the previous param (which I doubt
   that it ever worked), so mtrr.show=1 would still work
 - Declares mtrr_show as initdata

Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
Acked-by: default avatarJan Beulich <jbeulich@novell.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      731f1872
    • Suresh Siddha's avatar
      x86: fix page attribute corruption with cpa() · a1e46212
      Suresh Siddha authored 
      

Impact: fix sporadic slowdowns and warning messages

This patch fixes a performance issue reported by Linus on his
Nehalem system. While Linus reverted the PAT patch (commit
58dab916) which exposed the issue,
existing cpa() code can potentially still cause wrong(page attribute
corruption) behavior.

This patch also fixes the "WARNING: at arch/x86/mm/pageattr.c:560" that
various people reported.

In 64bit kernel, kernel identity mapping might have holes depending
on the available memory and how e820 reports the address range
covering the RAM, ACPI, PCI reserved regions. If there is a 2MB/1GB hole
in the address range that is not listed by e820 entries, kernel identity
mapping will have a corresponding hole in its 1-1 identity mapping.

If cpa() happens on the kernel identity mapping which falls into these holes,
existing code fails like this:

	__change_page_attr_set_clr()
		__change_page_attr()
			returns 0 because of if (!kpte). But doesn't
			set cpa->numpages and cpa->pfn.
		cpa_process_alias()
			uses uninitialized cpa->pfn (random value)
			which can potentially lead to changing the page
			attribute of kernel text/data, kernel identity
			mapping of RAM pages etc. oops!

This bug was easily exposed by another PAT patch which was doing
cpa() more often on kernel identity mapping holes (physical range between
max_low_pfn_mapped and 4GB), where in here it was setting the
cache disable attribute(PCD) for kernel identity mappings aswell.

Fix cpa() to handle the kernel identity mapping holes. Retain
the WARN() for cpa() calls to other not present address ranges
(kernel-text/data, ioremap() addresses)

Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: <stable@kernel.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a1e46212
    • Ingo Molnar's avatar
      Revert "x86: signal: change type of paramter for sys_rt_sigreturn()" · 552b8aa4
      Ingo Molnar authored 
      This reverts commit 4217458d.

Justin Madru bisected this commit, it was causing weird Firefox
crashes.

The reason is that GCC mis-optimizes (re-uses) the on-stack parameters of
the calling frame, which corrupts the syscall return pt_regs state and
thus corrupts user-space register state.

So we go back to the slightly less clean but more optimization-safe
method of getting to pt_regs. Also add a comment to explain this.

Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=12505



Reported-and-bisected-by: default avatarJustin Madru <jdm64@gawab.com>
Tested-by: default avatarJustin Madru <jdm64@gawab.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      552b8aa4
    • Andi Kleen's avatar
      x86: use early clobbers in usercopy*.c · e0a96129
      Andi Kleen authored 
      

Impact: fix rare (but currently harmless) miscompile with certain configs and gcc versions

Hugh Dickins noticed that strncpy_from_user() was miscompiled
in some circumstances with gcc 4.3.

Thanks to Hugh's excellent analysis it was easy to track down.

Hugh writes:

> Try building an x86_64 defconfig 2.6.29-rc1 kernel tree,
> except not quite defconfig, switch CONFIG_PREEMPT_NONE=y
> and CONFIG_PREEMPT_VOLUNTARY off (because it expands a
> might_fault() there, which hides the issue): using a
> gcc 4.3.2 (I've checked both openSUSE 11.1 and Fedora 10).
>
> It generates the following:
>
> 0000000000000000 <__strncpy_from_user>:
>    0:   48 89 d1                mov    %rdx,%rcx
>    3:   48 85 c9                test   %rcx,%rcx
>    6:   74 0e                   je     16 <__strncpy_from_user+0x16>
>    8:   ac                      lods   %ds:(%rsi),%al
>    9:   aa                      stos   %al,%es:(%rdi)
>    a:   84 c0                   test   %al,%al
>    c:   74 05                   je     13 <__strncpy_from_user+0x13>
>    e:   48 ff c9                dec    %rcx
>   11:   75 f5                   jne    8 <__strncpy_from_user+0x8>
>   13:   48 29 c9                sub    %rcx,%rcx
>   16:   48 89 c8                mov    %rcx,%rax
>   19:   c3                      retq
>
> Observe that "sub %rcx,%rcx; mov %rcx,%rax", whereas gcc 4.2.1
> (and many other configs) say "sub %rcx,%rdx; mov %rdx,%rax".
> Isn't it returning 0 when it ought to be returning strlen?

The asm constraints for the strncpy_from_user() result were missing an
early clobber, which tells gcc that the last output arguments
are written before all input arguments are read.

Also add more early clobbers in the rest of the file and fix 32-bit
usercopy.c in the same way.

Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
[ since this API is rarely used and no in-kernel user relies on a 'len'
  return value (they only rely on negative return values) this miscompile
  was never noticed in the field. But it's worth fixing it nevertheless. ]
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e0a96129