An error occurred fetching the project authors.
  1. 26 Apr, 2013 1 commit
  2. 19 Apr, 2013 1 commit
  3. 23 Feb, 2013 1 commit
  4. 08 Feb, 2013 3 commits
  5. 09 Oct, 2012 1 commit
    • Konstantin Khlebnikov's avatar
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov authored
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  6. 29 May, 2012 1 commit
  7. 15 Mar, 2012 1 commit
    • Kay Sievers's avatar
      udlfb: remove sysfs framebuffer device with USB .disconnect() · ce880cb8
      Kay Sievers authored
      The USB graphics card driver delays the unregistering of the framebuffer
      device to a workqueue, which breaks the userspace visible remove uevent
      sequence. Recent userspace tools started to support USB graphics card
      hotplug out-of-the-box and rely on proper events sent by the kernel.
      
      The framebuffer device is a direct child of the USB interface which is
      removed immediately after the USB .disconnect() callback. But the fb device
      in /sys stays around until its final cleanup, at a time where all the parent
      devices have been removed already.
      
      To work around that, we remove the sysfs fb device directly in the USB
      .disconnect() callback and leave only the cleanup of the internal fb
      data to the delayed work.
      
      Before:
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       remove   /2-1.2:1.0/graphics/fb0 (graphics)
      
      After:
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarBernie Thompson <bernie@plugable.com>
      Acked-by: default avatarBernie Thompson <bernie@plugable.com>
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      ce880cb8
  8. 28 Jan, 2012 1 commit
    • Kay Sievers's avatar
      udlfb: remove sysfs framebuffer device with USB .disconnect() · 92a9c19a
      Kay Sievers authored
      The USB graphics card driver delays the unregistering of the framebuffer
      device to a workqueue, which breaks the userspace visible remove uevent
      sequence. Recent userspace tools started to support USB graphics card
      hotplug out-of-the-box and rely on proper events sent by the kernel.
      
      The framebuffer device is a direct child of the USB interface which is
      removed immediately after the USB .disconnect() callback. But the fb device
      in /sys stays around until its final cleanup, at a time where all the parent
      devices have been removed already.
      
      To work around that, we remove the sysfs fb device directly in the USB
      .disconnect() callback and leave only the cleanup of the internal fb
      data to the delayed work.
      
      Before:
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       remove   /2-1.2:1.0/graphics/fb0 (graphics)
      
      After:
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
       remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarBernie Thompson <bernie@plugable.com>
      Acked-by: default avatarBernie Thompson <bernie@plugable.com>
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      92a9c19a
  9. 19 Dec, 2011 1 commit
  10. 02 Sep, 2011 1 commit
    • Herton Ronaldo Krzesinski's avatar
      fb: avoid possible deadlock caused by fb_set_suspend · 9e769ff3
      Herton Ronaldo Krzesinski authored
      A lock ordering issue can cause deadlocks: in framebuffer/console code,
      all needed struct fb_info locks are taken before acquire_console_sem(),
      in places which need to take console semaphore.
      
      But fb_set_suspend is always called with console semaphore held, and
      inside it we call lock_fb_info which gets the fb_info lock, inverse
      locking order of what the rest of the code does. This causes a real
      deadlock issue, when we write to state fb sysfs attribute (which calls
      fb_set_suspend) while a framebuffer is being unregistered by
      remove_conflicting_framebuffers, as can be shown by following show
      blocked state trace on a test program which loads i915 and runs another
      forked processes writing to state attribute:
      
      Test process with semaphore held and trying to get fb_info lock:
      ..
      fb-test2      D 0000000000000000     0   237    228 0x00000000
       ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0
       ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530
       00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0
      Call Trace:
       [<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0
       [<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40
       [<ffffffff814123d3>] mutex_lock+0x23/0x50
       [<ffffffff8125dfc5>] lock_fb_info+0x25/0x60
       [<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80
       [<ffffffff81263e2f>] store_fbstate+0x4f/0x70
       [<ffffffff812e7f70>] dev_attr_store+0x20/0x30
       [<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160
       [<ffffffff81155a26>] vfs_write+0xc6/0x190
       [<ffffffff81155d51>] sys_write+0x51/0x90
       [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b
      ..
      modprobe process stalled because has the fb_info lock (got inside
      unregister_framebuffer) but waiting for the semaphore held by the
      test process which is waiting to get the fb_info lock:
      ..
      modprobe      D 0000000000000000     0   230    218 0x00000000
       ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001
       ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20
       00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0
      Call Trace:
       [<ffffffff81411fe5>] schedule_timeout+0x215/0x310
       [<ffffffff81058051>] ? get_parent_ip+0x11/0x50
       [<ffffffff814130dd>] __down+0x6d/0xb0
       [<ffffffff81089f71>] down+0x41/0x50
       [<ffffffff810629ac>] acquire_console_sem+0x2c/0x50
       [<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0
       [<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890
       [<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50
       [<ffffffff81058051>] ? get_parent_ip+0x11/0x50
       [<ffffffff8141836d>] notifier_call_chain+0x4d/0x70
       [<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80
       [<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20
       [<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130
       [<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180
       [<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0
       [<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper]
       [<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper]
       [<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper]
       [<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915]
       [<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915]
       [<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm]
       [<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0
       [<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915]
       [<ffffffff8124481f>] local_pci_probe+0x5f/0xd0
       [<ffffffff81244f89>] pci_device_probe+0x119/0x120
       [<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0
       [<ffffffff812ed003>] driver_probe_device+0xa3/0x290
       [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
       [<ffffffff812ed29b>] __driver_attach+0xab/0xb0
       [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
       [<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ecc2e>] driver_attach+0x1e/0x20
       [<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffff812ed536>] driver_register+0x76/0x140
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffff81245216>] __pci_register_driver+0x56/0xd0
       [<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm]
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm]
       [<ffffffffa03aa094>] i915_init+0x94/0x96 [i915]
       [<ffffffff81002194>] do_one_initcall+0x44/0x190
       [<ffffffff810a066b>] sys_init_module+0xcb/0x210
       [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b
      ..
      
      fb-test2 which reproduces above is available on kernel.org bug #26232.
      To solve this issue, avoid calling lock_fb_info inside fb_set_suspend,
      and move it out to where needed (callers of fb_set_suspend must call
      lock_fb_info before if needed). So far, the only place which needs to
      call lock_fb_info is store_fbstate, all other places which calls
      fb_set_suspend are suspend/resume hooks that should not need the lock as
      they should be run only when processes are already frozen in
      suspend/resume.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=26232Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton@mandriva.com.br>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@kernel.org
      9e769ff3
  11. 14 May, 2011 2 commits
    • Bruno Prémont's avatar
      Further fbcon sanity checking · c590cece
      Bruno Prémont authored
      This moves the
      
          if (num_registered_fb == FB_MAX)
                  return -ENXIO;
      
      check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
      would (now in a safe way) allow a native driver to replace the
      conflicting one even if all slots in registered_fb[] are taken.
      
      This also prevents unregistering a framebuffer that is no longer
      registered (vga16f will unregister at module unload time even if the
      frame buffer had been unregistered earlier due to being found
      conflicting).
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c590cece
    • Linus Torvalds's avatar
      fbmem: fix remove_conflicting_framebuffers races · 712f3147
      Linus Torvalds authored
      When a register_framebuffer() call results in us removing old
      conflicting framebuffers, the new registration_lock doesn't protect that
      situation.  And we can't just add the same locking to the function,
      because these functions call each other: register_framebuffer() calls
      remove_conflicting_framebuffers, which in turn calls
      unregister_framebuffer for any conflicting entry.
      
      In order to fix it, this just creates wrapper functions around all three
      functions and makes the versions that actually do the work be called
      "do_xxx()", leaving just the wrapper that gets the lock and calls the
      worker function.
      
      So the rule becomes simply that "do_xxxx()" has to be called with the
      lock held, and now do_register_framebuffer() can just call
      do_remove_conflicting_framebuffers(), and that in turn can call
      _do_unregister_framebuffer(), and there is no deadlock, and we can hold
      the registration lock over the whole sequence, fixing the races.
      
      It also makes error cases simpler, and fixes one situation where we
      would return from unregister_framebuffer() without releasing the lock,
      pointed out by Bruno Prémont.
      Tested-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Tested-by: default avatarAnca Emanuel <anca.emanuel@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      712f3147
  12. 12 May, 2011 2 commits
    • Linus Torvalds's avatar
      fbmem: make read/write/ioctl use the frame buffer at open time · c47747fd
      Linus Torvalds authored
      read/write/ioctl on a fbcon file descriptor has traditionally used the
      fbcon not when it was opened, but as it was at the time of the call.
      That makes no sense, but the lack of sense is much more obvious now that
      we properly ref-count the usage - it means that the ref-counting doesn't
      actually protect operations we do on the frame buffer.
      
      This changes it to look at the fb_info that we got at open time, but in
      order to avoid using a frame buffer long after it has been unregistered,
      we do verify that it is still current, and return -ENODEV if not.
      Acked-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Tested-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: default avatarAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c47747fd
    • Linus Torvalds's avatar
      fbcon: add lifetime refcount to opened frame buffers · 698b3682
      Linus Torvalds authored
      This just adds the refcount and the new registration lock logic.  It
      does not (for example) actually change the read/write/ioctl routines to
      actually use the frame buffer that was opened: those function still end
      up alway susing whatever the current frame buffer is at the time of the
      call.
      
      Without this, if something holds the frame buffer open over a
      framebuffer switch, the close() operation after the switch will access a
      fb_info that has been free'd by the unregistering of the old frame
      buffer.
      
      (The read/write/ioctl operations will normally not cause problems,
      because they will - illogically - pick up the new fbcon instead.  But a
      switch that happens just as one of those is going on might see problems
      too, the window is just much smaller: one individual op rather than the
      whole open-close sequence.)
      
      This use-after-free is apparently fairly easily triggered by the Ubuntu
      11.04 boot sequence.
      Acked-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Tested-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: default avatarAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      698b3682
  13. 06 Apr, 2011 1 commit
  14. 26 Jan, 2011 1 commit
    • Torben Hohn's avatar
      console: rename acquire/release_console_sem() to console_lock/unlock() · ac751efa
      Torben Hohn authored
      The -rt patches change the console_semaphore to console_mutex.  As a
      result, a quite large chunk of the patches changes all
      acquire/release_console_sem() to acquire/release_console_mutex()
      
      This commit makes things use more neutral function names which dont make
      implications about the underlying lock.
      
      The only real change is the return value of console_trylock which is
      inverted from try_acquire_console_sem()
      
      This patch also paves the way to switching console_sem from a semaphore to
      a mutex.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
      Signed-off-by: default avatarTorben Hohn <torbenh@gmx.de>
      Cc: Thomas Gleixner <tglx@tglx.de>
      Cc: Greg KH <gregkh@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ac751efa
  15. 24 Dec, 2010 1 commit
  16. 28 Oct, 2010 2 commits
  17. 15 Oct, 2010 1 commit
    • Arnd Bergmann's avatar
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann authored
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      seem to be a way to do that using coccinelle.
      
      Some amount of new code is currently sitting in linux-next that should get
      the same modifications, which I will do at the end of the merge window.
      
      Many thanks to Julia Lawall for helping me learn to write a semantic
      patch that does all this.
      
      ===== begin semantic patch =====
      // This adds an llseek= method to all file operations,
      // as a preparation for making no_llseek the default.
      //
      // The rules are
      // - use no_llseek explicitly if we do nonseekable_open
      // - use seq_lseek for sequential files
      // - use default_llseek if we know we access f_pos
      // - use noop_llseek if we know we don't access f_pos,
      //   but we still want to allow users to call lseek
      //
      @ open1 exists @
      identifier nested_open;
      @@
      nested_open(...)
      {
      <+...
      nonseekable_open(...)
      ...+>
      }
      
      @ open exists@
      identifier open_f;
      identifier i, f;
      identifier open1.nested_open;
      @@
      int open_f(struct inode *i, struct file *f)
      {
      <+...
      (
      nonseekable_open(...)
      |
      nested_open(...)
      )
      ...+>
      }
      
      @ read disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      <+...
      (
         *off = E
      |
         *off += E
      |
         func(..., off, ...)
      |
         E = *off
      )
      ...+>
      }
      
      @ read_no_fpos disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ write @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      <+...
      (
        *off = E
      |
        *off += E
      |
        func(..., off, ...)
      |
        E = *off
      )
      ...+>
      }
      
      @ write_no_fpos @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ fops0 @
      identifier fops;
      @@
      struct file_operations fops = {
       ...
      };
      
      @ has_llseek depends on fops0 @
      identifier fops0.fops;
      identifier llseek_f;
      @@
      struct file_operations fops = {
      ...
       .llseek = llseek_f,
      ...
      };
      
      @ has_read depends on fops0 @
      identifier fops0.fops;
      identifier read_f;
      @@
      struct file_operations fops = {
      ...
       .read = read_f,
      ...
      };
      
      @ has_write depends on fops0 @
      identifier fops0.fops;
      identifier write_f;
      @@
      struct file_operations fops = {
      ...
       .write = write_f,
      ...
      };
      
      @ has_open depends on fops0 @
      identifier fops0.fops;
      identifier open_f;
      @@
      struct file_operations fops = {
      ...
       .open = open_f,
      ...
      };
      
      // use no_llseek if we call nonseekable_open
      ////////////////////////////////////////////
      @ nonseekable1 depends on !has_llseek && has_open @
      identifier fops0.fops;
      identifier nso ~= "nonseekable_open";
      @@
      struct file_operations fops = {
      ...  .open = nso, ...
      +.llseek = no_llseek, /* nonseekable */
      };
      
      @ nonseekable2 depends on !has_llseek @
      identifier fops0.fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...  .open = open_f, ...
      +.llseek = no_llseek, /* open uses nonseekable */
      };
      
      // use seq_lseek for sequential files
      /////////////////////////////////////
      @ seq depends on !has_llseek @
      identifier fops0.fops;
      identifier sr ~= "seq_read";
      @@
      struct file_operations fops = {
      ...  .read = sr, ...
      +.llseek = seq_lseek, /* we have seq_read */
      };
      
      // use default_llseek if there is a readdir
      ///////////////////////////////////////////
      @ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier readdir_e;
      @@
      // any other fop is used that changes pos
      struct file_operations fops = {
      ... .readdir = readdir_e, ...
      +.llseek = default_llseek, /* readdir is present */
      };
      
      // use default_llseek if at least one of read/write touches f_pos
      /////////////////////////////////////////////////////////////////
      @ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read.read_f;
      @@
      // read fops use offset
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = default_llseek, /* read accesses f_pos */
      };
      
      @ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ... .write = write_f, ...
      +	.llseek = default_llseek, /* write accesses f_pos */
      };
      
      // Use noop_llseek if neither read nor write accesses f_pos
      ///////////////////////////////////////////////////////////
      
      @ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      identifier write_no_fpos.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ...
       .write = write_f,
       .read = read_f,
      ...
      +.llseek = noop_llseek, /* read and write both use no f_pos */
      };
      
      @ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write_no_fpos.write_f;
      @@
      struct file_operations fops = {
      ... .write = write_f, ...
      +.llseek = noop_llseek, /* write uses no f_pos */
      };
      
      @ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      @@
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = noop_llseek, /* read uses no f_pos */
      };
      
      @ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      @@
      struct file_operations fops = {
      ...
      +.llseek = noop_llseek, /* no read or write fn */
      };
      ===== End semantic patch =====
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Christoph Hellwig <hch@infradead.org>
      6038f373
  18. 11 Aug, 2010 2 commits
  19. 22 May, 2010 1 commit
    • Randy Dunlap's avatar
      fbmem: avoid printk format warning with 32-bit resources · f4b87dee
      Randy Dunlap authored
      Fix printk formats:
      
        drivers/video/fbmem.c: In function 'fb_do_apertures_overlap':
        drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
        drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
        drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
        drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f4b87dee
  20. 18 May, 2010 3 commits
  21. 25 Feb, 2010 1 commit
  22. 25 Sep, 2009 1 commit
  23. 23 Sep, 2009 2 commits
    • Florian Tobias Schandinat's avatar
      fb: do not ignore fb_set_par errors · 0fcf6ada
      Florian Tobias Schandinat authored
      At the moment about half of the framebuffer drivers can return an error
      code in fb_set_par. Until now it would be silently ignored by fbmem.c
      and fbcon.c. This patch fixes fbmem.c to return the error code and
      restore var on error.
      
      But it is not clear in which video mode the device is when fb_set_par
      fails.  It would be good and reasonable if it were in the old state but
      there is no guarantee that this is true for all existing drivers.
      Additionally print a message if a failing fb_set_par is detected in
      fbmem.c or fbcon.c.
      
      Although most errors should be caught by the previous fb_check_var some
      errors can't as they are dynamic (memory allocations, ...) and can only be
      detected while performing the operations which is forbidden in
      fb_check_var.
      
      This patch shouldn't have a negative impact on normal operation as all
      drivers return 0 on success.  The impact in case of error depends heavily
      on the driver and caller but it's expected to be better than before.
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0fcf6ada
    • Florian Tobias Schandinat's avatar
      fb: fix fb_pan_display range check · 99e9e7d6
      Florian Tobias Schandinat authored
      Fix the range check for panning.  The current code fails to detect some
      invalid values (very high ones that can occur if an app tries to move
      further up/left than 0,0) as the check uses the unknown values for
      calculation so that an overflow can occur.
      
      To fix this it is sufficient to move the calculation to the right side to
      use only trusted values.
      
      Kai Jiang detected this problem and proposed an initial patch.
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Kai Jiang <b18973@freescale.com>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      99e9e7d6
  24. 12 Jul, 2009 1 commit
  25. 08 Jul, 2009 1 commit
  26. 06 Jul, 2009 1 commit
  27. 01 Jul, 2009 1 commit
    • Krzysztof Helt's avatar
      fbdev: add mutex for fb_mmap locking · 537a1bf0
      Krzysztof Helt authored
      Add a mutex to avoid a circular locking problem between the mm layer
      semaphore and fbdev ioctl mutex through the fb_mmap() call.
      
      Also, add mutex to all places where smem_start and smem_len fields change
      so the mutex inside the fb_mmap() is actually used.  Changing of these
      fields before calling the framebuffer_register() are not mutexed.
      
      This is 2.6.31 material.  It removes one lockdep (fb_mmap() and
      register_framebuffer()) but there is still another one (fb_release() and
      register_framebuffer()).  It also cleans up handling of the smem_start and
      smem_len fields used by mutexed section of the fb_mmap().
      Signed-off-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      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>
      537a1bf0
  28. 17 Jun, 2009 1 commit
    • Dave Airlie's avatar
      fbdev: add support for handoff from firmware to hw framebuffers · 4410f391
      Dave Airlie authored
      With KMS we have ran into an issue where we really want the KMS fb driver
      to be the one running the console, so panics etc can be shown by switching
      out of X etc.
      
      However with vesafb/efifb built-in, we end up with those on fb0 and the
      KMS fb driver on fb1, driving the same piece of hw, so this adds an fb
      info flag to denote a firmware fbdev, and adds a new aperture base/size
      range which can be compared when the hw drivers are installed to see if
      there is a conflict with a firmware driver, and if there is the firmware
      driver is unregistered and the hw driver takes over.
      
      It uses new aperture_base/size members instead of comparing on the fix
      smem_start/length, as smem_start/length might for example only cover the
      first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
      into the aperture, thus they would never overlap.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Acked-by: default avatarPeter Jones <pjones@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4410f391
  29. 13 Apr, 2009 1 commit
  30. 01 Apr, 2009 2 commits