Skip to content

L
linux
Switch branch/tag
  1. 17 Dec, 2006 1 commit
  3. 15 Dec, 2006 5 commits
    • Linus Torvalds's avatar
      AGP: Allocate AGP pages with GFP_DMA32 by default · dcc6e343
      Linus Torvalds authored 
      Not all graphic page remappers support physical addresses over the 4GB
mark for remapping, so while some do (the AMD64 GART always did, and I
just fixed the i965 to do so properly), we're safest off just forcing
GFP_DMA32 allocations to make sure graphics pages get allocated in the
low 32-bit address space by default.

AGP sub-drivers that really care, and can do better, could just choose
to implement their own allocator (or we could add another "64-bit safe"
default allocator for their use), but quite frankly, you're not likely
to care in practice.

So for now, this trivial change means that we won't be allocating pages
that we can't map correctly by mistake on x86-64.

[ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
  would never allocate any highmem memory anyway ]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      dcc6e343
    • Neil Brown's avatar
      md: Fix md grow/size code to correctly find the maximum available space · 75ba82c6
      Neil Brown authored 
      An md array can be asked to change the amount of each device that it is using,
and in particular can be asked to use the maximum available space.  This
currently only works if the first device is not larger than the rest.  As
'size' gets changed and so 'fit' becomes wrong.  So check if a 'fit' is
required early and don't corrupt it.
Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      75ba82c6
    • Zachary Amsden's avatar
      softirq: remove BUG_ONs which can incorrectly trigger · e89da8fc
      Zachary Amsden authored 
      It is possible to have tasklets get scheduled before softirqd has had a chance
to spawn on all CPUs.  This is totally harmless; after success during action
CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
softirqd on the appropriate CPU to process the already pending tasklets.  So
there is no danger of having a missed wakeup for any tasklets that were
already pending.

In particular, i386 is affected by this during startup, and is visible when
using a very large initrd; during the time it takes for the initrd to be
decompressed, a timer IRQ can come in and schedule RCU callbacks.  It is also
possible that resending of a hardware IRQ via a softirq triggers the same bug.

Because of different timing conditions, this shows up in all emulators and
virtual machines tested, including Xen, VMware, Virtual PC, and Qemu.  It is
also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.
Signed-off-by: default avatarZachary Amsden <zach@vmware.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      e89da8fc
    • Christophe Saout's avatar
      dm crypt: Fix data corruption with dm-crypt over RAID5 · a26b7719
      Christophe Saout authored 
      Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads to the higher layers (and leaving
random content in the buffer cache). Already fixed in 2.6.19.
Signed-off-by: default avatarChristophe Saout <christophe@saout.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      a26b7719
    • Christophe Saout's avatar
      Fix SUNRPC wakeup/execute race condition · bbb97831
      Christophe Saout authored 
      The sunrpc scheduler contains a race condition that can let an RPC
task end up being neither running nor on any wait queue. The race takes
place between rpc_make_runnable (called from rpc_wake_up_task) and
__rpc_execute under the following condition:

First __rpc_execute calls tk_action which puts the task on some wait
queue. The task is dequeued by another process before __rpc_execute
continues its execution. While executing rpc_make_runnable exactly after
setting the task `running' bit and before clearing the `queued' bit
__rpc_execute picks up execution, clears `running' and subsequently
both functions fall through, both under the false assumption somebody
else took the job.

Swapping rpc_test_and_set_running with rpc_clear_queued in
rpc_make_runnable fixes that hole. This introduces another possible
race condition that can be handled by checking for `queued' after
setting the `running' bit.

Bug noticed on a 4-way x86_64 system under XEN with an NFSv4 server
on the same physical machine, apparently one of the few ways to hit
this race condition at all.
Signed-off-by: default avatarChristophe Saout <christophe@saout.de>
Acked-by: default avatarTrond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      bbb97831
  5. 14 Dec, 2006 24 commits
  7. 13 Dec, 2006 1 commit
  9. 09 Dec, 2006 4 commits
    • Adrian Bunk's avatar
      Linux 2.6.16.36-rc1 · 567e8e58
      Adrian Bunk authored
      567e8e58
    • Chuck Ebbert's avatar
      binfmt_elf: fix checks for bad address · 40618f2d
      Chuck Ebbert authored 
      Fix check for bad address; use macro instead of open-coding two checks.

Taken from RHEL4 kernel update.

From: Ernie Petrides <petrides@redhat.com>

  For background, the BAD_ADDR() macro should return TRUE if the address is
  TASK_SIZE, because that's the lowest address that is *not* valid for
  user-space mappings.  The macro was correct in binfmt_aout.c but was wrong
  for the "equal to" case in binfmt_elf.c.  There were two in-line validations
  of user-space addresses in binfmt_elf.c, which have been appropriately
  converted to use the corrected BAD_ADDR() macro in the patch you posted
  yesterday.  Note that the size checks against TASK_SIZE are okay as coded.

  The additional changes that I propose are below.  These are in the error
  paths for bad ELF entry addresses once load_elf_binary() has already
  committed to exec'ing the new image (following the tearing down of the
  task's original address space).

  The 1st hunk deals with the interp-side of the outer "if".  There were two
  problems here.  The printk() should be removed because this path can be
  triggered at will by a bogus interpreter image created and used by a
  malicious user.  Further, the error code should not be ENOEXEC, because that
  causes the loop in search_binary_handler() to continue trying other exec
  handlers (twice, in fact).  But it's too late for this to work correctly,
  because the user address space has already been torn down, and an exec()
  failure cannot be returned to the user code because the code no longer
  exists.  The only recovery is to force a SIGSEGV, but it's best to terminate
  the search loop immediately.  I somewhat arbitrarily chose EINVAL as a
  fallback error code, but any error returned by load_elf_interp() will
  override that (but this value will never be seen by user-space).

  The 2nd hunk deals with the non-interp-side of the outer "if".  There were
  two problems here as well.  The SIGSEGV needs to be forced, because a prior
  sigaction() syscall might have set the associated disposition to SIG_IGN.
  And the ENOEXEC should be changed to EINVAL as described above.
Signed-off-by: default avatarChuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      40618f2d
    • David S. Miller's avatar
      [IPSEC]: Fix inetpeer leak in ipv4 xfrm dst entries. · 888d358e
      David S. Miller authored 
      We grab a reference to the route's inetpeer entry but
forget to release it in xfrm4_dst_destroy().

Bug discovered by Kazunori MIYAZAWA <kazunori@miyazawa.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      888d358e
    • Patrick McHardy's avatar
      [XFRM]: Use output device disable_xfrm for forwarded packets · 6a24340c
      Patrick McHardy authored 
      Currently the behaviour of disable_xfrm is inconsistent between
locally generated and forwarded packets. For locally generated
packets disable_xfrm disables the policy lookup if it is set on
the output device, for forwarded traffic however it looks at the
input device. This makes it impossible to disable xfrm on all
devices but a dummy device and use normal routing to direct
traffic to that device.

Always use the output device when checking disable_xfrm.
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      6a24340c
  11. 08 Dec, 2006 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7