1. 27 Aug, 2009 36 commits
    • Dave Hansen's avatar
      ecryptfs: improved dependency checking and reporting · 55deb64a
      Dave Hansen authored
      So, I compiled a 2.6.31-rc5 kernel with ecryptfs and loaded its module.
      When it came time to mount my filesystem, I got this in dmesg, and it
      refused to mount:
      
      [93577.776637] Unable to allocate crypto cipher with name [aes]; rc = [-2]
      [93577.783280] Error attempting to initialize key TFM cipher with name = [aes]; rc = [-2]
      [93577.791183] Error attempting to initialize cipher with name = [aes] and key size = [32]; rc = [-2]
      [93577.800113] Error parsing options; rc = [-22]
      
      I figured from the error message that I'd either forgotten to load "aes"
      or that my key size was bogus.  Neither one of those was the case.  In
      fact, I was missing the CRYPTO_ECB config option and the 'ecb' module.
      Unfortunately, there's no trace of 'ecb' in that error message.
      
      I've done two things to fix this.  First, I've modified ecryptfs's
      Kconfig entry to select CRYPTO_ECB and CRYPTO_CBC.  I also took CRYPTO
      out of the dependencies since the 'select' will take care of it for us.
      
      I've also modified the error messages to print a string that should
      contain both 'ecb' and 'aes' in my error case.  That will give any
      future users a chance of finding the right modules and Kconfig options.
      
      I also wonder if we should:
      
      	select CRYPTO_AES if !EMBEDDED
      
      since I think most ecryptfs users are using AES like me.
      
      Cc: ecryptfs-devel@lists.launchpad.net
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Dustin Kirkland <kirkland@canonical.com>
      Signed-off-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      [tyhicks@linux.vnet.ibm.com: Removed extra newline, 80-char violation]
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      55deb64a
    • Roland Dreier's avatar
      eCryptfs: Fix lockdep-reported AB-BA mutex issue · a6dd1522
      Roland Dreier authored
      Lockdep reports the following valid-looking possible AB-BA deadlock with
      global_auth_tok_list_mutex and keysig_list_mutex:
      
        ecryptfs_new_file_context() ->
            ecryptfs_copy_mount_wide_sigs_to_inode_sigs() ->
                mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
                -> ecryptfs_add_keysig() ->
                    mutex_lock(&crypt_stat->keysig_list_mutex);
      
      vs
      
        ecryptfs_generate_key_packet_set() ->
            mutex_lock(&crypt_stat->keysig_list_mutex);
            -> ecryptfs_find_global_auth_tok_for_sig() ->
                mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
      
      ie the two mutexes are taken in opposite orders in the two different
      code paths.  I'm not sure if this is a real bug where two threads could
      actually hit the two paths in parallel and deadlock, but it at least
      makes lockdep impossible to use with ecryptfs since this report triggers
      every time and disables future lockdep reporting.
      
      Since ecryptfs_add_keysig() is called only from the single callsite in
      ecryptfs_copy_mount_wide_sigs_to_inode_sigs(), the simplest fix seems to
      be to move the lock of keysig_list_mutex back up outside of the where
      global_auth_tok_list_mutex is taken.  This patch does that, and fixes
      the lockdep report on my system (and ecryptfs still works OK).
      
      The full output of lockdep fixed by this patch is:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.31-2-generic #14~rbd2
      -------------------------------------------------------
      gdm/2640 is trying to acquire lock:
       (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}, at: [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
      
      but task is already holding lock:
       (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&crypt_stat->keysig_list_mutex){+.+.+.}:
             [<ffffffff8108c897>] check_prev_add+0x2a7/0x370
             [<ffffffff8108cfc1>] validate_chain+0x661/0x750
             [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
             [<ffffffff8108d585>] lock_acquire+0xa5/0x150
             [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
             [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
             [<ffffffff8121526a>] ecryptfs_add_keysig+0x5a/0xb0
             [<ffffffff81213299>] ecryptfs_copy_mount_wide_sigs_to_inode_sigs+0x59/0xb0
             [<ffffffff81214b06>] ecryptfs_new_file_context+0xa6/0x1a0
             [<ffffffff8120e42a>] ecryptfs_initialize_file+0x4a/0x140
             [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
             [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
             [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
             [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
             [<ffffffff8112d8d9>] do_sys_open+0x69/0x140
             [<ffffffff8112d9f0>] sys_open+0x20/0x30
             [<ffffffff81013132>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #0 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}:
             [<ffffffff8108c675>] check_prev_add+0x85/0x370
             [<ffffffff8108cfc1>] validate_chain+0x661/0x750
             [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
             [<ffffffff8108d585>] lock_acquire+0xa5/0x150
             [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
             [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
             [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
             [<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0
             [<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120
             [<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200
             [<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140
             [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
             [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
             [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
             [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
             [<ffffffff8112d8d9>] do_sys_open+0x69/0x140
             [<ffffffff8112d9f0>] sys_open+0x20/0x30
             [<ffffffff81013132>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      other info that might help us debug this:
      
      2 locks held by gdm/2640:
       #0:  (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8113cb8b>] do_filp_open+0x3cb/0xae0
       #1:  (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [<ffffffff81217728>] ecryptfs_generate_key_packet_set+0x58/0x2b0
      
      stack backtrace:
      Pid: 2640, comm: gdm Tainted: G         C 2.6.31-2-generic #14~rbd2
      Call Trace:
       [<ffffffff8108b988>] print_circular_bug_tail+0xa8/0xf0
       [<ffffffff8108c675>] check_prev_add+0x85/0x370
       [<ffffffff81094912>] ? __module_text_address+0x12/0x60
       [<ffffffff8108cfc1>] validate_chain+0x661/0x750
       [<ffffffff81017275>] ? print_context_stack+0x85/0x140
       [<ffffffff81089c68>] ? find_usage_backwards+0x38/0x160
       [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
       [<ffffffff8108d585>] lock_acquire+0xa5/0x150
       [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
       [<ffffffff8108b0b0>] ? check_usage_backwards+0x0/0xb0
       [<ffffffff815526cd>] __mutex_lock_common+0x4d/0x3d0
       [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
       [<ffffffff8121591e>] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
       [<ffffffff8108c02c>] ? mark_held_locks+0x6c/0xa0
       [<ffffffff81125b0d>] ? kmem_cache_alloc+0xfd/0x1a0
       [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190
       [<ffffffff81552b56>] mutex_lock_nested+0x46/0x60
       [<ffffffff8121591e>] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
       [<ffffffff812177d5>] ecryptfs_generate_key_packet_set+0x105/0x2b0
       [<ffffffff81212f49>] ecryptfs_write_headers_virt+0xc9/0x120
       [<ffffffff8121306d>] ecryptfs_write_metadata+0xcd/0x200
       [<ffffffff81210240>] ? ecryptfs_init_persistent_file+0x60/0xe0
       [<ffffffff8120e44b>] ecryptfs_initialize_file+0x6b/0x140
       [<ffffffff8120e54d>] ecryptfs_create+0x2d/0x60
       [<ffffffff8113a7d4>] vfs_create+0xb4/0xe0
       [<ffffffff8113a8c4>] __open_namei_create+0xc4/0x110
       [<ffffffff8113d1c1>] do_filp_open+0xa01/0xae0
       [<ffffffff8129a93e>] ? _raw_spin_unlock+0x5e/0xb0
       [<ffffffff8155410b>] ? _spin_unlock+0x2b/0x40
       [<ffffffff81139e9b>] ? getname+0x3b/0x240
       [<ffffffff81148a5a>] ? alloc_fd+0xfa/0x140
       [<ffffffff8112d8d9>] do_sys_open+0x69/0x140
       [<ffffffff81553b8f>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8112d9f0>] sys_open+0x20/0x30
       [<ffffffff81013132>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      a6dd1522
    • Roland Dreier's avatar
      ecryptfs: Remove unneeded locking that triggers lockdep false positives · 216e0d39
      Roland Dreier authored
      In ecryptfs_destroy_inode(), inode_info->lower_file_mutex is locked,
      and just after the mutex is unlocked, the code does:
      
       	kmem_cache_free(ecryptfs_inode_info_cache, inode_info);
      
      This means that if another context could possibly try to take the same
      mutex as ecryptfs_destroy_inode(), then it could end up getting the
      mutex just before the data structure containing the mutex is freed.
      So any such use would be an obvious use-after-free bug (catchable with
      slab poisoning or mutex debugging), and therefore the locking in
      ecryptfs_destroy_inode() is not needed and can be dropped.
      
      Similarly, in ecryptfs_destroy_crypt_stat(), crypt_stat->keysig_list_mutex
      is locked, and then the mutex is unlocked just before the code does:
      
       	memset(crypt_stat, 0, sizeof(struct ecryptfs_crypt_stat));
      
      Therefore taking this mutex is similarly not necessary.
      
      Removing this locking fixes false-positive lockdep reports such as the
      following (and they are false-positives for exactly the same reason
      that the locking is not needed):
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.31-2-generic #14~rbd3
      ---------------------------------
      inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      kswapd0/323 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&inode_info->lower_file_mutex){+.+.?.}, at: [<ffffffff81210d34>] ecryptfs_destroy_inode+0x34/0x100
      {RECLAIM_FS-ON-W} state was registered at:
        [<ffffffff8108c02c>] mark_held_locks+0x6c/0xa0
        [<ffffffff8108c10f>] lockdep_trace_alloc+0xaf/0xe0
        [<ffffffff81125a51>] kmem_cache_alloc+0x41/0x1a0
        [<ffffffff8113117a>] get_empty_filp+0x7a/0x1a0
        [<ffffffff8112dd46>] dentry_open+0x36/0xc0
        [<ffffffff8121a36c>] ecryptfs_privileged_open+0x5c/0x2e0
        [<ffffffff81210283>] ecryptfs_init_persistent_file+0xa3/0xe0
        [<ffffffff8120e838>] ecryptfs_lookup_and_interpose_lower+0x278/0x380
        [<ffffffff8120f97a>] ecryptfs_lookup+0x12a/0x250
        [<ffffffff8113930a>] real_lookup+0xea/0x160
        [<ffffffff8113afc8>] do_lookup+0xb8/0xf0
        [<ffffffff8113b518>] __link_path_walk+0x518/0x870
        [<ffffffff8113bd9c>] path_walk+0x5c/0xc0
        [<ffffffff8113be5b>] do_path_lookup+0x5b/0xa0
        [<ffffffff8113bfe7>] user_path_at+0x57/0xa0
        [<ffffffff811340dc>] vfs_fstatat+0x3c/0x80
        [<ffffffff8113424b>] vfs_stat+0x1b/0x20
        [<ffffffff81134274>] sys_newstat+0x24/0x50
        [<ffffffff81013132>] system_call_fastpath+0x16/0x1b
        [<ffffffffffffffff>] 0xffffffffffffffff
      irq event stamp: 7811
      hardirqs last  enabled at (7811): [<ffffffff810c037f>] call_rcu+0x5f/0x90
      hardirqs last disabled at (7810): [<ffffffff810c0353>] call_rcu+0x33/0x90
      softirqs last  enabled at (3764): [<ffffffff810631da>] __do_softirq+0x14a/0x220
      softirqs last disabled at (3751): [<ffffffff8101440c>] call_softirq+0x1c/0x30
      
      other info that might help us debug this:
      2 locks held by kswapd0/323:
       #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810f67ed>] shrink_slab+0x3d/0x190
       #1:  (&type->s_umount_key#35){.+.+..}, at: [<ffffffff811429a1>] prune_dcache+0xd1/0x1b0
      
      stack backtrace:
      Pid: 323, comm: kswapd0 Tainted: G         C 2.6.31-2-generic #14~rbd3
      Call Trace:
       [<ffffffff8108ad6c>] print_usage_bug+0x18c/0x1a0
       [<ffffffff8108aff0>] ? check_usage_forwards+0x0/0xc0
       [<ffffffff8108bac2>] mark_lock_irq+0xf2/0x280
       [<ffffffff8108bd87>] mark_lock+0x137/0x1d0
       [<ffffffff81164710>] ? fsnotify_clear_marks_by_inode+0x30/0xf0
       [<ffffffff8108bee6>] mark_irqflags+0xc6/0x1a0
       [<ffffffff8108d337>] __lock_acquire+0x287/0x430
       [<ffffffff8108d585>] lock_acquire+0xa5/0x150
       [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100
       [<ffffffff8108d2e7>] ? __lock_acquire+0x237/0x430
       [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0
       [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100
       [<ffffffff81164710>] ? fsnotify_clear_marks_by_inode+0x30/0xf0
       [<ffffffff81210d34>] ? ecryptfs_destroy_inode+0x34/0x100
       [<ffffffff8129a91e>] ? _raw_spin_unlock+0x5e/0xb0
       [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60
       [<ffffffff81210d34>] ecryptfs_destroy_inode+0x34/0x100
       [<ffffffff81145d27>] destroy_inode+0x87/0xd0
       [<ffffffff81146b4c>] generic_delete_inode+0x12c/0x1a0
       [<ffffffff81145832>] iput+0x62/0x70
       [<ffffffff811423c8>] dentry_iput+0x98/0x110
       [<ffffffff81142550>] d_kill+0x50/0x80
       [<ffffffff81142623>] prune_one_dentry+0xa3/0xc0
       [<ffffffff811428b1>] __shrink_dcache_sb+0x271/0x290
       [<ffffffff811429d9>] prune_dcache+0x109/0x1b0
       [<ffffffff81142abf>] shrink_dcache_memory+0x3f/0x50
       [<ffffffff810f68dd>] shrink_slab+0x12d/0x190
       [<ffffffff810f9377>] balance_pgdat+0x4d7/0x640
       [<ffffffff8104c4c0>] ? finish_task_switch+0x40/0x150
       [<ffffffff810f63c0>] ? isolate_pages_global+0x0/0x60
       [<ffffffff810f95f7>] kswapd+0x117/0x170
       [<ffffffff810777a0>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff810f94e0>] ? kswapd+0x0/0x170
       [<ffffffff810773be>] kthread+0x9e/0xb0
       [<ffffffff8101430a>] child_rip+0xa/0x20
       [<ffffffff81013c90>] ? restore_args+0x0/0x30
       [<ffffffff81077320>] ? kthread+0x0/0xb0
       [<ffffffff81014300>] ? child_rip+0x0/0x20
      Signed-off-by: default avatarRoland Dreier <roland@digitalvampire.org>
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      216e0d39
    • James Bottomley's avatar
      module: workaround duplicate section names · 1b364bf4
      James Bottomley authored
      The root cause is a duplicate section name (.text); is this legal?
      [ Amerigo Wang: "AFAIK, yes." ]
      
      However, there's a problem with commit
      6d760133 in that if you fail to allocate
      a mod->sect_attrs (in this case it's null because of the duplication),
      it still gets used without checking in add_notes_attrs()
      
      This should fix it
      
      [ This patch leaves other problems, particularly the sections directory,
        but recent parisc toolchains seem to produce these modules and this
        prevents a crash and is a minimal change -- RR ]
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Tested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1b364bf4
    • Rusty Russell's avatar
      module: fix BUG_ON() for powerpc (and other function descriptor archs) · 7d1d16e4
      Rusty Russell authored
      The rarely-used symbol_put_addr() needs to use dereference_function_descriptor
      on powerpc.
      Reported-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d1d16e4
    • Jeremy Fitzhardinge's avatar
      xenfb: connect to backend before registering fb · 0a80fb10
      Jeremy Fitzhardinge authored
      As soon as the framebuffer is registered, our methods may be called by the
      kernel. This leads to a crash as xenfb_refresh() gets called before we have
      the irq.
      
      Connect to the backend before registering our framebuffer with the kernel.
      
      [ Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14059 ]
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a80fb10
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.infradead.org/users/eparis/notify · 9c504cad
      Linus Torvalds authored
      * 'for-linus' of git://git.infradead.org/users/eparis/notify:
        inotify: Ensure we alwasy write the terminating NULL.
        inotify: fix locking around inotify watching in the idr
        inotify: do not BUG on idr entries at inotify destruction
        inotify: seperate new watch creation updating existing watches
      9c504cad
    • Benjamin Herrenschmidt's avatar
      lmb: Remove __init from lmb_end_of_DRAM() · 4f8ee2c9
      Benjamin Herrenschmidt authored
      We call lmb_end_of_DRAM() to test whether a DMA mask is ok on a machine
      without IOMMU, but this function is marked as __init.
      
      I don't think there's a clean way to get the top of RAM max_pfn doesn't
      appear to include highmem or I missed (or we have a bug :-) so for now,
      let's just avoid having a broken 2.6.31 by making this function
      non-__init and we can revisit later.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f8ee2c9
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs · cf481442
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
        9p: update documentation pointers
        9p: remove unnecessary v9fses->options which duplicates the mount string
        net/9p: insulate the client against an invalid error code sent by a 9p server
        9p: Add missing cast for the error return value in v9fs_get_inode
        9p: Remove redundant inode uid/gid assignment
        9p: Fix possible regressions when ->get_sb fails.
        9p: Fix v9fs show_options
        9p: Fix possible memleak in v9fs_inode_from fid.
        9p: minor comment fixes
        9p: Fix possible inode leak in v9fs_get_inode.
        9p: Check for error in return value of v9fs_fid_add
      cf481442
    • Julien TINNES's avatar
      ipv4: make ip_append_data() handle NULL routing table · 788d908f
      Julien TINNES authored
      Add a check in ip_append_data() for NULL *rtp to prevent future bugs in
      callers from being exploitable.
      Signed-off-by: default avatarJulien Tinnes <julien@cr0.org>
      Signed-off-by: default avatarTavis Ormandy <taviso@sdf.lonestar.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      788d908f
    • David Howells's avatar
      AFS: Stop readlink() on AFS crashing due to NULL 'file' ptr · 9886e836
      David Howells authored
      kAFS crashes when asked to read a symbolic link because page_getlink()
      passes a NULL file pointer to read_mapping_page(), but afs_readpage()
      expects a file pointer from which to extract a key.
      
      Modify afs_readpage() to request the appropriate key from the calling
      process's keyrings if a file struct is not supplied with one attached.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9886e836
    • Eric W. Biederman's avatar
      inotify: Ensure we alwasy write the terminating NULL. · 0db501bd
      Eric W. Biederman authored
      Before the rewrite copy_event_to_user always wrote a terqminating '\0'
      byte to user space after the filename.  Since the rewrite that
      terminating byte was skipped if your filename is exactly a multiple of
      event_size.  Ouch!
      
      So add one byte to name_size before we round up and use clear_user to
      set userspace to zero like /dev/zero does instead of copying the
      strange nul_inotify_event.  I can't quite convince myself len_to_zero
      will never exceed 16 and even if it doesn't clear_user should be more
      efficient and a more accurate reflection of what the code is trying to
      do.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      0db501bd
    • Eric Paris's avatar
      inotify: fix locking around inotify watching in the idr · dead537d
      Eric Paris authored
      The are races around the idr storage of inotify watches.  It's possible
      that a watch could be found from sys_inotify_rm_watch() in the idr, but it
      could be removed from the idr before that code does it's removal.  Move the
      locking and the refcnt'ing so that these have to happen atomically.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      dead537d
    • Eric Paris's avatar
      inotify: do not BUG on idr entries at inotify destruction · cf437426
      Eric Paris authored
      If an inotify watch is left in the idr when an fsnotify group is destroyed
      this will lead to a BUG.  This is not a dangerous situation and really
      indicates a programming bug and leak of memory.  This patch changes it to
      use a WARN and a printk rather than killing people's boxes.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      cf437426
    • Eric Paris's avatar
      inotify: seperate new watch creation updating existing watches · 52cef755
      Eric Paris authored
      There is nothing known wrong with the inotify watch addition/modification
      but this patch seperates the two code paths to make them each easy to
      verify as correct.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      52cef755
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 1e23502c
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        virtio: net refill on out-of-memory
        smc91x: fix compilation on SMP
      1e23502c
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · e99b1f22
      Linus Torvalds authored
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc/ps3: Update ps3_defconfig
        powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
      e99b1f22
    • Geoff Levand's avatar
      powerpc/ps3: Update ps3_defconfig · b080f187
      Geoff Levand authored
      Update ps3_defconfig.
      
       o Refresh for 2.6.31.
       o Remove MTD support.
       o Add more HID drivers.
      Signed-off-by: default avatarGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b080f187
    • Geert Uytterhoeven's avatar
      powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration · 7b6a09f3
      Geert Uytterhoeven authored
      On non-PS3, we get:
      
      | kernel BUG at drivers/rtc/rtc-ps3.c:36!
      
      because the rtc-ps3 platform device is registered unconditionally in a kernel
      with builtin support for PS3.
      Reported-by: default avatarSachin Sant <sachinp@in.ibm.com>
      Signed-off-by: default avatarGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Acked-by: default avatarGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7b6a09f3
    • Linus Torvalds's avatar
      5311034d
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k · 533995ed
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
        m68k,m68knommu: Wire up rt_tgsigqueueinfo and perf_counter_open
        m68k: Fix redefinition of pgprot_noncached
        arch/m68k/include/asm/motorola_pgalloc.h: fix kunmap arg
        m68k: cnt reaches -1, not 0
        m68k: count can reach 51, not 50
      533995ed
    • Thadeu Lima de Souza Cascardo's avatar
      leds: after setting inverted attribute, we must update the LED · cc674c81
      Thadeu Lima de Souza Cascardo authored
      If we change the inverted attribute to another value, the LED will not be
      inverted until we change the GPIO state.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Cc: Samuel R. C. Vale <srcvale@holoscopio.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cc674c81
    • Thadeu Lima de Souza Cascardo's avatar
      leds: fix multiple requests and releases of IRQ for GPIO LED Trigger · 48cccd26
      Thadeu Lima de Souza Cascardo authored
      When setting the same GPIO number, multiple IRQ shared requests will be
      done without freing the previous request.  It will also try to free a
      failed request or an already freed IRQ if 0 was written to the gpio file.
      
      All these oops and leaks were fixed with the following solution: keep the
      previous allocated GPIO (if any) still allocated in case the new request
      fails.  The alternative solution would desallocate the previous allocated
      GPIO and set gpio as 0.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Signed-off-by: default avatarSamuel R. C. Vale <srcvale@holoscopio.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      48cccd26
    • Frans Pop's avatar
      acpi processor: remove superfluous warning message · bdf57de4
      Frans Pop authored
      This failure is very common on many platforms.  Handling it in the ACPI
      processor driver is enough, and we don't need a warning message unless
      CONFIG_ACPI_DEBUG is set.
      
      Based on a patch from Zhang Rui.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      Acked-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bdf57de4
    • Frans Pop's avatar
      ACPI processor: force throttling state when BIOS returns incorrect value · 2a908002
      Frans Pop authored
      If the BIOS reports an invalid throttling state (which seems to be
      fairly common after system boot), a reset is done to state T0.
      Because of a check in acpi_processor_get_throttling_ptc(), the reset
      never actually gets executed, which results in the error reoccurring
      on every access of for example /proc/acpi/processor/CPU0/throttling.
      
      Add a 'force' option to acpi_processor_set_throttling() to ensure
      the reset really takes effect.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
      
      This patch, together with the next one, fixes a regression introduced in
      2.6.30, listed on the regression list. They have been available for 2.5
      months now in bugzilla, but have not been picked up, despite various
      reminders and without any reason given.
      
      Google shows that numerous people are hitting this issue. The issue is in
      itself relatively minor, but the bug in the code is clear.
      
      The patches have been in all my kernels and today testing has shown that
      throttling works correctly with the patches applied when the system
      overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).
      Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      Acked-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2a908002
    • Costantino Leandro's avatar
      wmi: fix kernel panic when stack protection enabled. · f3d83e24
      Costantino Leandro authored
      Summary:
      Kernel panic arise when stack protection is enabled, since strncat will
      add a null terminating byte '\0'; So in functions
      like this one (wmi_query_block):
              char wc[4]="WC";
      	....
      	strncat(method, block->object_id, 2);
              ...
      the length of wc should be n+1 (wc[5]) or stack protection
      fault will arise. This is not noticeable when stack protection is
      disabled,but , isn't good either.
      Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y,
      	      CONFIG_CC_STACKPROTECTOR=y]
      
      Panic Trace
      ------------
             .... stack-protector: kernel stack corrupted in : fa7b182c
             2.6.30-rc8-obelisco-generic
             call_trace:
                 [<c04a6c40>] ? panic+0x45/0xd9
      	   [<c012925d>] ? __stack_chk_fail+0x1c/0x40
      	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
      	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
      	   [<fa7e7000>] ? acer_wmi_init+0x00/0x61a [acer_wmi]
      	   [<fa7e7135>] ? acer_wmi_init+0x135/0x61a [acer_wmi]
      	   [<c0101159>] ? do_one_initcall+0x50+0x126
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514Signed-off-by: default avatarCostantino Leandro <lcostantino@gmail.com>
      Signed-off-by: default avatarCarlos Corbacho <carlos@strangeworlds.co.uk>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f3d83e24
    • Yinghai Lu's avatar
      acpi: don't call acpi_processor_init if acpi is disabled · ce8442b5
      Yinghai Lu authored
      Jens reported early_ioremap messages with old ASUS board...
      
      > [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
      > [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
      > [    1.561007] Call Trace:
      > [    1.568638]  [<c136e48b>] ? printk+0x18/0x1d
      > [    1.581734]  [<c15513ff>] __early_ioremap+0x74/0x1e9
      > [    1.596898]  [<c15515aa>] early_ioremap+0x1a/0x1c
      > [    1.611270]  [<c154a187>] __acpi_map_table+0x18/0x1a
      > [    1.626451]  [<c135a7f8>] acpi_os_map_memory+0x1d/0x25
      > [    1.642129]  [<c119459c>] acpi_tb_verify_table+0x20/0x49
      > [    1.658321]  [<c1193e50>] acpi_get_table_with_size+0x53/0xa1
      > [    1.675553]  [<c1193eae>] acpi_get_table+0x10/0x15
      > [    1.690192]  [<c155cc19>] acpi_processor_init+0x23/0xab
      > [    1.706126]  [<c1001043>] do_one_initcall+0x33/0x180
      > [    1.721279]  [<c155cbf6>] ? acpi_processor_init+0x0/0xab
      > [    1.737479]  [<c106893a>] ? register_irq_proc+0xaa/0xc0
      > [    1.753411]  [<c10689b7>] ? init_irq_proc+0x67/0x80
      > [    1.768316]  [<c15405e7>] kernel_init+0x120/0x176
      > [    1.782678]  [<c15404c7>] ? kernel_init+0x0/0x176
      > [    1.797062]  [<c10038b7>] kernel_thread_helper+0x7/0x10
      > [    1.812984] 00000080 + ffe00000
      
      that is rather later.
      acpi_gbl_permanent_mmap should be set in acpi_early_init()
      if acpi is not disabled
      
      and we have
      > [    0.000000] ASUS P2B-DS detected: force use of acpi=ht
      
      just don't load acpi_processor_init...
      Reported-and-tested-by: default avatarJens Rosenboom <jens@leia.mcbone.net>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ce8442b5
    • Michael Brunner's avatar
      thermal_sys: check get_temp return value · 0d288162
      Michael Brunner authored
      The return value of the get_temp function is not checked when doing a
      thermal zone update.  This may lead to a critical shutdown if get_temp
      fails and the content of the temp variable is incorrectly set higher than
      the critical trip point.
      
      This has been observed on a system with incorrect ACPI implementation
      where the corresponding methods were not serialized and therefore
      sometimes triggered ACPI errors (AE_ALREADY_EXISTS).  The following
      critical shutdowns indicated a temperature of 2097 C, which was obviously
      wrong.
      
      The patch adds a return value check that jumps over all trip point
      evaluations printing a warning if get_temp fails.  The trip points are
      evaluated again on the next polling interval with successful get_temp
      execution.
      Signed-off-by: default avatarMichael Brunner <mibru@gmx.de>
      Acked-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0d288162
    • Oleg Nesterov's avatar
      clone(): fix race between copy_process() and de_thread() · 4ab6c083
      Oleg Nesterov authored
      Spotted by Hiroshi Shimamoto who also provided the test-case below.
      
      copy_process() uses signal->count as a reference counter, but it is not.
      This test case
      
      	#include <sys/types.h>
      	#include <sys/wait.h>
      	#include <unistd.h>
      	#include <stdio.h>
      	#include <errno.h>
      	#include <pthread.h>
      
      	void *null_thread(void *p)
      	{
      		for (;;)
      			sleep(1);
      
      		return NULL;
      	}
      
      	void *exec_thread(void *p)
      	{
      		execl("/bin/true", "/bin/true", NULL);
      
      		return null_thread(p);
      	}
      
      	int main(int argc, char **argv)
      	{
      		for (;;) {
      			pid_t pid;
      			int ret, status;
      
      			pid = fork();
      			if (pid < 0)
      				break;
      
      			if (!pid) {
      				pthread_t tid;
      
      				pthread_create(&tid, NULL, exec_thread, NULL);
      				for (;;)
      					pthread_create(&tid, NULL, null_thread, NULL);
      			}
      
      			do {
      				ret = waitpid(pid, &status, 0);
      			} while (ret == -1 && errno == EINTR);
      		}
      
      		return 0;
      	}
      
      quickly creates an unkillable task.
      
      If copy_process(CLONE_THREAD) races with de_thread()
      copy_signal()->atomic(signal->count) breaks the signal->notify_count
      logic, and the execing thread can hang forever in kernel space.
      
      Change copy_process() to increment count/live only when we know for sure
      we can't fail.  In this case the forked thread will take care of its
      reference to signal correctly.
      
      If copy_process() fails, check CLONE_THREAD flag.  If it it set - do
      nothing, the counters were not changed and current belongs to the same
      thread group.  If it is not set, ->signal must be released in any case
      (and ->count must be == 1), the forked child is the only thread in the
      thread group.
      
      We need more cleanups here, in particular signal->count should not be used
      by de_thread/__exit_signal at all.  This patch only fixes the bug.
      Reported-by: default avatarHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Tested-by: default avatarHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4ab6c083
    • Minchan Kim's avatar
      mm: fix for infinite churning of mlocked pages · 03ef83af
      Minchan Kim authored
      An mlocked page might lose the isolatation race.  This causes the page to
      clear PG_mlocked while it remains in a VM_LOCKED vma.  This means it can
      be put onto the [in]active list.  We can rescue it by using try_to_unmap()
      in shrink_page_list().
      
      But now, As Wu Fengguang pointed out, vmscan has a bug.  If the page has
      PG_referenced, it can't reach try_to_unmap() in shrink_page_list() but is
      put into the active list.  If the page is referenced repeatedly, it can
      remain on the [in]active list without being moving to the unevictable
      list.
      
      This patch fixes it.
      Reported-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarMinchan Kim <minchan.kim@gmail.com>
      Reviewed-by: default avatarKOSAKI Motohiro <&lt;kosaki.motohiro@jp.fujitsu.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03ef83af
    • David Rientjes's avatar
      flex_array: convert element_nr formals to unsigned · b62e408c
      David Rientjes authored
      It's problematic to allow signed element_nr's or total's to be passed as
      part of the flex array API.
      
      flex_array_alloc() allows total_nr_elements to be set to a negative
      quantity, which is obviously erroneous.
      
      flex_array_get() and flex_array_put() allows negative array indices in
      dereferencing an array part, which could address memory mapped before
      struct flex_array.
      
      The fix is to convert all existing element_nr formals to be qualified as
      unsigned.  Existing checks to compare it to total_nr_elements or the max
      array size based on element_size need not be changed.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Dave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b62e408c
    • David Rientjes's avatar
      flex_array: declare parts member to have incomplete type · 8e7ee270
      David Rientjes authored
      The `parts' member of struct flex_array should evaluate to an incomplete
      type so that sizeof() cannot be used and C99 does not require the
      zero-length specification.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8e7ee270
    • David Rientjes's avatar
      flex_array: fix flex_array_free_parts comment · 105b6e8a
      David Rientjes authored
      flex_array_free_parts() does not take `src' or `element_nr' formals, so
      remove their respective comments.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      105b6e8a
    • David Rientjes's avatar
      flex_array: fix get function for elements in base starting at non-zero · a30b595d
      David Rientjes authored
      If all array elements fit into the base structure and data is copied using
      flex_array_put() starting at a non-zero index, flex_array_get() will fail
      to return the data.
      
      This fixes the bug by only checking for NULL parts when all elements do
      not fit in the base structure when flex_array_get() is used.  Otherwise,
      fa_element_to_part_nr() will always be 0 since there are no parts
      structures needed and such element may never have been put.  Thus, it will
      remain NULL due to the kzalloc() of the base.
      
      Additionally, flex_array_put() now only checks for a NULL part when all
      elements do not fit in the base structure.  This is otherwise unnecessary
      since the base structure is guaranteed to exist (or we would have already
      hit a NULL pointer).
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a30b595d
    • Joonwoo Park's avatar
      pps: fix incorrect verdict check · 054b2b13
      Joonwoo Park authored
      Fix incorrect verdict check and returns error if device_create failed,
      otherwise driver triggers kernel oops.
      
      Signed-off-by: Joonwoo Park<joonwpark81@gmail.com>
      Cc: Rodolfo Giometti <giometti@enneenne.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      054b2b13
    • Eric Paris's avatar
      IMA: iint put in ima_counts_get and put · 53a7197a
      Eric Paris authored
      ima_counts_get() calls ima_iint_find_insert_get() which takes a reference
      to the iint in question, but does not put that reference at the end of the
      function.  This can lead to a nasty memory leak.  Easy enough to reproduce:
      
      #include <sys/mman.h>
      #include <stdio.h>
      
      int main (void)
      {
      	int i;
      	void *ptr;
      
      	for (i=0; i < 100000; i++) {
      		ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
      			   MAP_SHARED|MAP_ANONYMOUS, -1, 0);
      		if (ptr == MAP_FAILED)
      			return 2;
      		munmap(ptr, 4096);
      	}
      
      	return 0;
      }
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      53a7197a
  2. 26 Aug, 2009 4 commits