Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 05 9月, 2005 5 次提交
  3. 03 9月, 2005 9 次提交
  5. 01 9月, 2005 3 次提交
  7. 30 8月, 2005 2 次提交
  9. 28 8月, 2005 1 次提交
    • P
      [PATCH] Remove race between con_open and con_close · f786648b
      由 Paul Mackerras 提交于 
      [ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]

I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.

What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data.  Then process A closes that and concurrently process
B opens /dev/tty6.  Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1.  However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).

So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data.  Then when the
process tries to do anything with that fd, it oopses.

The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open.  The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem.  We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called.  Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
[ Same patch
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
  in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f786648b
  11. 24 8月, 2005 3 次提交
  13. 23 8月, 2005 1 次提交
    • D
      drm: fix a bad VERSION check. · 7a9aff3c
      由 Dave Airlie 提交于 
      I found why my G5 was crashing when using the linux-2.6 version of the
DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM.
The reason was that dev->agp->cant_use_aperture wasn't getting set,
and the reason for that was that <linux/version.h> no longer gets
included and the #if LINUX_VERSION_CODE < 0x020408 in drm_agpsupport.c
was going the wrong way.  With this patch (and a few others) a 32-bit
server works correctly, as does DRI.

From: Paul Mackerras <paulus@samba.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      7a9aff3c
  15. 20 8月, 2005 2 次提交
  17. 16 8月, 2005 3 次提交
  19. 14 8月, 2005 1 次提交
    • L
      Fix up mmap of /dev/kmem · 4bb82551
      由 Linus Torvalds 提交于 
      This leaves the issue of whether we should deprecate the whole thing (or
if we should check the whole mmap range, for that matter) open. Just do
the minimal fix for now.
      4bb82551
  21. 10 8月, 2005 1 次提交
  23. 07 8月, 2005 2 次提交
  25. 06 8月, 2005 1 次提交
  27. 05 8月, 2005 6 次提交
    • P
      [PATCH] rtc: msleep() cannot be used from interrupt · 403fe5ae
      由 Petr Vandrovec 提交于 
      Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog.  Today it finally did it in front
of me, and this patch will hopefully fix it.

The problem is that at the end of June (the 28th, to be exact: commit
47f176fd, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
and scheduling is not allowed during interrupt.  So I'm reverting this
part of original change, replacing msleep() back with busy loop.

The original code was busy waiting for up to 20ms, but on my hardware in
the worst case update-in-progress bit was asserted for at most 363
passes through loop (on 2GHz dual Opteron), much less than even one
jiffie, not even talking about 20ms.  So I changed code to just wait
only as long as necessary.  Otherwise when RTC was set to generate
8192Hz timer, it stopped doing anything for 20ms (160 pulses were
skipped!) from time to time, and this is rather suboptimal as far as I
can tell.
Signed-off-by: NPetr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      403fe5ae
    • D
      drm: fix warning in drm_pci.c · aa0ca6b4
      由 Dave Airlie 提交于 
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      aa0ca6b4
    • D
      drm: remove the gamma driver · 1fad9949
      由 Dave Airlie 提交于 
      The gamma driver has been broken for quite a while, it doesn't build,
we don't have a userspace, mine is in Ireland etc...
Signed-off-by: NDave Airlie <airlied@linux.ie>
      1fad9949
    • D
      drm: switch drm_handle_t to unsigned int · db215327
      由 Dave Airlie 提交于 
      This converts the drm_handle_t to unsigned int.
This is currently safe to do as we don't pass these across the kernel/user
boundary, but userspace does use these, but no-one builds userspace against
the kernel headers at present so it is okay to switch over the kernel copy
of drm.h at this point. (The CVS tree will switch over soon in sync with
some Mesa changes)

From: Egbert Eich <eich@suse.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      db215327
    • D
      drm: updated DRM map patch for 32/64 bit systems · d1f2b55a
      由 Dave Airlie 提交于 
      I basically combined Paul's patches with additions that I had made
for PCI scatter gather.
I also tried more carefully to avoid problems with the same token
assigned multiple times while trying to use the base address in the
token if possible to gain as much backward compatibility as possible
for broken DRI clients.

From: Paul Mackerras <paulus@samba.org> and Egbert Eich <eich@suse.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      d1f2b55a
    • D
      drm: copy the right data back to userspace for getreserved contexts ioctl · c73681e7
      由 Dave Airlie 提交于 
      This fixes the information copied back to userspace by the get reserved
contexts ioctl.

From: Egbert Eich <eich@suse.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      c73681e7