1. 17 May, 2010 3 commits
    • Frederic Weisbecker's avatar
      sunrpc: Include missing smp_lock.h · 99df95a2
      Frederic Weisbecker authored
      Now that cache_ioctl_procfs() calls the bkl explicitly, we need to
      include the relevant header as well.
      
      This fixes the following build error:
      
      	net/sunrpc/cache.c: In function 'cache_ioctl_procfs':
      	net/sunrpc/cache.c:1355: error: implicit declaration of function 'lock_kernel'
      	net/sunrpc/cache.c:1359: error: implicit declaration of function 'unlock_kernel'
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      99df95a2
    • Frederic Weisbecker's avatar
      procfs: Kill the bkl in ioctl · c2f98050
      Frederic Weisbecker authored
      There are no more users of procfs that implement the ioctl
      callback. Drop the bkl from this path and warn on any use
      of this callback.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      c2f98050
    • Frederic Weisbecker's avatar
      procfs: Push down the bkl from ioctl · d79b6f4d
      Frederic Weisbecker authored
      Push down the bkl from procfs's ioctl main handler to its users.
      Only three procfs users implement an ioctl (non unlocked) handler.
      Turn them into unlocked_ioctl and push down the Devil inside.
      
      v2: PDE(inode)->data doesn't need to be under bkl
      v3: And don't forget to git-add the result
      v4: Use wrappers to pushdown instead of an invasive and error prone
          handlers surgery.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      d79b6f4d
  2. 09 Apr, 2010 4 commits
    • Frederic Weisbecker's avatar
      procfs: Use generic_file_llseek in /proc/vmcore · 73296bc6
      Frederic Weisbecker authored
      /proc/vmcore has no llseek and then falls down to use default_llseek.
      This is racy against read_vmcore() that directly manipulates fpos
      but it doesn't hold the bkl there so using it in llseek doesn't
      protect anything.
      
      Let's use generic_file_llseek() instead.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      73296bc6
    • Frederic Weisbecker's avatar
      procfs: Use generic_file_llseek in /proc/kmsg · 41775e29
      Frederic Weisbecker authored
      No need to hold the bkl to seek here, none of the other
      fops callbacks use it.
      
      Use generic_file_llseek explicitly.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      41775e29
    • Frederic Weisbecker's avatar
      procfs: Use generic_file_llseek in /proc/kcore · 34aacb29
      Frederic Weisbecker authored
      /proc/kcore has no llseek and then falls down to use default_llseek.
      This is racy against read_kcore() that directly manipulates fpos
      but it doesn't hold the bkl there so using it in llseek doesn't
      protect anything.
      
      Let's use generic_file_llseek() instead.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      34aacb29
    • Arnd Bergmann's avatar
      procfs: Kill BKL in llseek on proc base · 87df8424
      Arnd Bergmann authored
      We don't use the BKL elsewhere, so use generic_file_llseek
      so we can avoid default_llseek taking the BKL.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      [restore proc_fdinfo_file_operations as non-seekable]
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      87df8424
  3. 30 Mar, 2010 6 commits
  4. 29 Mar, 2010 27 commits