1. 20 1月, 2011 1 次提交
    • C
      drm/i915: Initialise ring vfuncs for old DRI paths · e8616b6c
      Chris Wilson 提交于
      We weren't setting up the vfunc table when initialising the old DRI
      ringbuffer, leading to such OOPSes as:
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<(null)>] (null)
      PGD 10c441067 PUD 1185e5067 PMD 0
      Oops: 0010 [#1] PREEMPT SMP
      last sysfs file: /sys/class/dmi/id/chassis_asset_tag
      CPU 3
      Modules linked in: i915 drm_kms_helper drm fb fbdev i2c_algo_bit
      cfbcopyarea video backlight output cfbimgblt cfbfillrect autofs4 ipv6
      nfs lockd fscache nfs_acl auth_rpcgss sunrpc coretemp hwmon_vid mousedev
      usbhid hid option usb_wwan snd_hda_codec_via asus_atk0110 atl1e
      usbserial snd_hda_intel snd_hda_codec firmware_class snd_hwdep snd_pcm
      snd_seq snd_timer snd_seq_device processor parport_pc thermal snd
      thermal_sys parport 8250_pnp button rng_core rtc_cmos shpchp hwmon
      rtc_core ehci_hcd pci_hotplug uhci_hcd soundcore tpm_tis i2c_i801
      rtc_lib tpm serio_raw snd_page_alloc tpm_bios i2c_core usbcore psmouse
      intel_agp sg pcspkr sr_mod evdev cdrom ext3 jbd mbcache dm_mod sd_mod
      ata_piix libata scsi_mod unix
      Jan 18 15:49:29 lithui kernel:
      Pid: 3605, comm: Xorg Not tainted 2.6.36.2 #5 P5KPL-CM/System Product
      Name
      RIP: 0010:[<0000000000000000>]  [<(null)>] (null)
      RSP: 0018:ffff8801150d1d40  EFLAGS: 00010202
      RAX: 000000000001ffff RBX: ffff88011a011b00 RCX: 000000000001a704
      RDX: ffff880118566028 RSI: ffff880118566028 RDI: ffff880117876800
      RBP: ffff8801150d1d48 R08: ffff8801195fe300 R09: 00000000c0086444
      R10: 0000000000000001 R11: 0000000000003206 R12: ffff880117876800
      R13: ffff880118566000 R14: ffff880117876820 R15: ffff8801150d1df8
      FS:  00007f1038d456e0(0000) GS:ffff880001780000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000001187e7000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process Xorg (pid: 3605, threadinfo ffff8801150d0000, task
      ffff88011b016e40)
      Stack:
      ffffffffa043b8e6 ffff8801150d1d98 ffffffffa041768b dead000000000000
      <0> 0000000000000048 00007f1023f2a000 0000000000000044 0000000000000008
      <0> ffff88010d26bd80 ffff880117876800 ffff8801150d1df8 ffff8801150d1ea8
      Call Trace:
      [<ffffffffa043b8e6>] ? intel_ring_advance+0x16/0x20 [i915]
      [<ffffffffa041768b>] i915_irq_emit+0x15b/0x240 [i915]
      [<ffffffffa03ea7b1>] drm_ioctl+0x1f1/0x460 [drm]
      [<ffffffffa0417530>] ? i915_irq_emit+0x0/0x240 [i915]
      [<ffffffff810dd8f1>] ? do_sync_read+0xd1/0x120
      [<ffffffff81025b1f>] ? do_page_fault+0x1df/0x3d0
      [<ffffffff810ed5c7>] do_vfs_ioctl+0x97/0x550
      [<ffffffff8115c2ea>] ? security_file_permission+0x7a/0x90
      [<ffffffff810edb19>] sys_ioctl+0x99/0xa0
      [<ffffffff810024ab>] system_call_fastpath+0x16/0x1b
      Code:  Bad RIP value.
      RIP  [<(null)>] (null)
      RSP <ffff8801150d1d40>
      CR2: 0000000000000000
      Reported-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29153
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23172Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      e8616b6c
  2. 19 1月, 2011 1 次提交
  3. 18 1月, 2011 3 次提交
  4. 17 1月, 2011 21 次提交
  5. 16 1月, 2011 2 次提交
    • G
      dt/flattree: Return virtual address from early_init_dt_alloc_memory_arch() · 672c5446
      Grant Likely 提交于
      The physical address is never used by the device tree code when
      allocating memory for unflattening.  Change the architecture's alloc
      hook to return the virutal address instead.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      672c5446
    • D
      Add a dentry op to allow processes to be held during pathwalk transit · cc53ce53
      David Howells 提交于
      Add a dentry op (d_manage) to permit a filesystem to hold a process and make it
      sleep when it tries to transit away from one of that filesystem's directories
      during a pathwalk.  The operation is keyed off a new dentry flag
      (DCACHE_MANAGE_TRANSIT).
      
      The filesystem is allowed to be selective about which processes it holds and
      which it permits to continue on or prohibits from transiting from each flagged
      directory.  This will allow autofs to hold up client processes whilst letting
      its userspace daemon through to maintain the directory or the stuff behind it
      or mounted upon it.
      
      The ->d_manage() dentry operation:
      
      	int (*d_manage)(struct path *path, bool mounting_here);
      
      takes a pointer to the directory about to be transited away from and a flag
      indicating whether the transit is undertaken by do_add_mount() or
      do_move_mount() skipping through a pile of filesystems mounted on a mountpoint.
      
      It should return 0 if successful and to let the process continue on its way;
      -EISDIR to prohibit the caller from skipping to overmounted filesystems or
      automounting, and to use this directory; or some other error code to return to
      the user.
      
      ->d_manage() is called with namespace_sem writelocked if mounting_here is true
      and no other locks held, so it may sleep.  However, if mounting_here is true,
      it may not initiate or wait for a mount or unmount upon the parameter
      directory, even if the act is actually performed by userspace.
      
      Within fs/namei.c, follow_managed() is extended to check with d_manage() first
      on each managed directory, before transiting away from it or attempting to
      automount upon it.
      
      follow_down() is renamed follow_down_one() and should only be used where the
      filesystem deliberately intends to avoid management steps (e.g. autofs).
      
      A new follow_down() is added that incorporates the loop done by all other
      callers of follow_down() (do_add/move_mount(), autofs and NFSD; whilst AFS, NFS
      and CIFS do use it, their use is removed by converting them to use
      d_automount()).  The new follow_down() calls d_manage() as appropriate.  It
      also takes an extra parameter to indicate if it is being called from mount code
      (with namespace_sem writelocked) which it passes to d_manage().  follow_down()
      ignores automount points so that it can be used to mount on them.
      
      __follow_mount_rcu() is made to abort rcu-walk mode if it hits a directory with
      DCACHE_MANAGE_TRANSIT set on the basis that we're probably going to have to
      sleep.  It would be possible to enter d_manage() in rcu-walk mode too, and have
      that determine whether to abort or not itself.  That would allow the autofs
      daemon to continue on in rcu-walk mode.
      
      Note that DCACHE_MANAGE_TRANSIT on a directory should be cleared when it isn't
      required as every tranist from that directory will cause d_manage() to be
      invoked.  It can always be set again when necessary.
      
      ==========================
      WHAT THIS MEANS FOR AUTOFS
      ==========================
      
      Autofs currently uses the lookup() inode op and the d_revalidate() dentry op to
      trigger the automounting of indirect mounts, and both of these can be called
      with i_mutex held.
      
      autofs knows that the i_mutex will be held by the caller in lookup(), and so
      can drop it before invoking the daemon - but this isn't so for d_revalidate(),
      since the lock is only held on _some_ of the code paths that call it.  This
      means that autofs can't risk dropping i_mutex from its d_revalidate() function
      before it calls the daemon.
      
      The bug could manifest itself as, for example, a process that's trying to
      validate an automount dentry that gets made to wait because that dentry is
      expired and needs cleaning up:
      
      	mkdir         S ffffffff8014e05a     0 32580  24956
      	Call Trace:
      	 [<ffffffff885371fd>] :autofs4:autofs4_wait+0x674/0x897
      	 [<ffffffff80127f7d>] avc_has_perm+0x46/0x58
      	 [<ffffffff8009fdcf>] autoremove_wake_function+0x0/0x2e
      	 [<ffffffff88537be6>] :autofs4:autofs4_expire_wait+0x41/0x6b
      	 [<ffffffff88535cfc>] :autofs4:autofs4_revalidate+0x91/0x149
      	 [<ffffffff80036d96>] __lookup_hash+0xa0/0x12f
      	 [<ffffffff80057a2f>] lookup_create+0x46/0x80
      	 [<ffffffff800e6e31>] sys_mkdirat+0x56/0xe4
      
      versus the automount daemon which wants to remove that dentry, but can't
      because the normal process is holding the i_mutex lock:
      
      	automount     D ffffffff8014e05a     0 32581      1              32561
      	Call Trace:
      	 [<ffffffff80063c3f>] __mutex_lock_slowpath+0x60/0x9b
      	 [<ffffffff8000ccf1>] do_path_lookup+0x2ca/0x2f1
      	 [<ffffffff80063c89>] .text.lock.mutex+0xf/0x14
      	 [<ffffffff800e6d55>] do_rmdir+0x77/0xde
      	 [<ffffffff8005d229>] tracesys+0x71/0xe0
      	 [<ffffffff8005d28d>] tracesys+0xd5/0xe0
      
      which means that the system is deadlocked.
      
      This patch allows autofs to hold up normal processes whilst the daemon goes
      ahead and does things to the dentry tree behind the automouter point without
      risking a deadlock as almost no locks are held in d_manage() and none in
      d_automount().
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Was-Acked-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      cc53ce53
  6. 15 1月, 2011 12 次提交