Skip to content

L
linux
Switch branch/tag
  1. 19 Jun, 2008 2 commits
  3. 18 Jun, 2008 6 commits
    • Jan Beulich's avatar
      agp: two-stage page destruction issue · da503fa6
      Jan Beulich authored 
      besides it apparently being useful only in 2.6.24 (the changes in 2.6.25
really mean that it could be converted back to a single-stage mechanism),
I'm seeing an issue in Xen Dom0 kernels, which is caused by the calling
of gart_to_virt() in the second stage invocations of the destroy function.
I think that besides this being a real issue with Xen (where
unmap_page_from_agp() is not just a page table attribute change), this
also is invalid from a theoretical perspective: One should not assume that
gart_to_virt() is still valid after unmapping a page. So minimally (keeping
the 2-stage mechanism) a patch like the one below would be needed.

Jan
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      da503fa6
    • Greg KH's avatar
      agp/via: fixup pci ids · dcd981a7
      Greg KH authored 
      add a new PCI ID and remove an old dodgy one, include the explaination
in the commented code so nobody readds later.

(davej also sent the pci id addition).
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      dcd981a7
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · 952f4a0a
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: appletouch - implement reset-resume logic
  Input: i8042 - retry failed CTR writes when resuming
  Input: i8042 - add Fujitsu-Siemens Amilo Pro V2030 to nomux table
  Input: pcspkr - remove negative dependency on snd-pcsp

Manually fixed up trivial conflict in drivers/usb/core/quirks.c
      952f4a0a
    • Miklos Szeredi's avatar
      fuse: fix thinko in max I/O size calucation · f948d564
      Miklos Szeredi authored 
      Use max not min to enforce a lower limit on the max I/O size.

This bug was introduced by "fuse: fix max i/o size calculation" (commit
e5d9a0df).

Thanks to Brian Wang for noticing.
Reported-by: default avatarBrian Wang <ywang221@hotmail.com>
Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
Acked-by: default avatarSzabolcs Szakacsits <szaka@ntfs-3g.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f948d564
    • Eduard - Gabriel Munteanu's avatar
      Unignore vmlinux.lds.h from Git. · cd50e892
      Eduard - Gabriel Munteanu authored 
      Added !vmlinux.lds.h to .gitignore because it would otherwise be ignored.
Signed-off-by: default avatarEduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd50e892
    • Linus Torvalds's avatar
      x86-64: Fix "bytes left to copy" return value for copy_from_user() · 42a886af
      Linus Torvalds authored 
      Most users by far do not care about the exact return value (they only
really care about whether the copy succeeded in its entirety or not),
but a few special core routines actually care deeply about exactly how
many bytes were copied from user space.

And the unrolled versions of the x86-64 user copy routines would
sometimes report that it had copied more bytes than it actually had.

Very few uses actually have partial copies to begin with, but to make
this bug even harder to trigger, most x86 CPU's use the "rep string"
instructions for normal user copies, and that version didn't have this
issue.

To make it even harder to hit, the one user of this that really cared
about the return value (and used the uncached version of the copy that
doesn't use the "rep string" instructions) was the generic write
routine, which pre-populated its source, once more hiding the problem by
avoiding the exception case that triggers the bug.

In other words, very special thanks to Bron Gondwana who not only
triggered this, but created a test-program to show it, and bisected the
behavior down to commit 08291429 ("mm:
fix pagecache write deadlocks") which changed the access pattern just
enough that you can now trigger it with 'writev()' with multiple
iovec's.

That commit itself was not the cause of the bug, it just allowed all the
stars to align just right that you could trigger the problem.

[ Side note: this is just the minimal fix to make the copy routines
  (with __copy_from_user_inatomic_nocache as the particular version that
  was involved in showing this) have the right return values.

  We really should improve on the exceptional case further - to make the
  copy do a byte-accurate copy up to the exact page limit that causes it
  to fail.  As it is, the callers have to do extra work to handle the
  limit case gracefully. ]
Reported-by: default avatarBron Gondwana <brong@fastmail.fm>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>

 (which didn't have this problem), and since
most users that do the carethis was very hard to trigger, but
      42a886af
  5. 17 Jun, 2008 2 commits
  7. 16 Jun, 2008 30 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7