Skip to content

L
linux
Switch branch/tag
  1. 13 Dec, 2004 10 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Workaround PCI issue on g5 · 34fb8412
      Benjamin Herrenschmidt authored 
      ppc64 has a global called "pci_probe_only" which, when set, prevents the
arch PCI code from calling pci_assign_unassigned_resources().  This was
cleared by pmac so far, but a bug in the definition of the variable make
that ineffective until 2.6.10, and so we never called
pci_assign_unassigned_resources().

With 2.6.10, that bug was fixed and so we now call it, which results in
some problems.  Some devices who have perfectly valid assigned addresses by
firmware end up beeing moved around anyway, which is a BAD thing can can
break boot on some machines since it breaks the relationship between
addresses in Open Firmware device-tree and actual location of PCI devices. 
(Some low level things like the PIC are ioremap'ed based on their OF
address, way before the PCI based ASIC hosting them has been found).  This
also break the "offb" default framebuffer driver since the video card ends
up beeing moved around as well.

For now, the fix is to set pci_probe_only on pmac, thus reverting to the
old behaviour.  In the long run, it would be interesting to "fix"
pci_assign_unassigned_resources() so that it does what it's name claims,
and only assigns things that have been left unassigned instead of moving
things around gratuituously...
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      34fb8412
    • Hugh Dickins's avatar
      [PATCH] VmLib wrapped: mprotect flags · 2f16b7a1
      Hugh Dickins authored 
      Sometimes /proc/<pid>/status shows VmLib: 42949..... kB.

mprotect_fixup must note oldflags on entry: if vma_merge is successful,
vma->vm_flags afterwards may be either the oldflags or the newflags, and
the extent of the change will be less than the extent of the vma.

And let's use unsigned long for these flags throughout.
Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Acked-by: default avatarWilliam Lee Irwin III <wli@holomorphy.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2f16b7a1
    • Hugh Dickins's avatar
      [PATCH] VmLib wrapped: executable brk · 8c54a50c
      Hugh Dickins authored 
      In some cases /proc/<pid>/status shows VmLib: 42949..... kB.

If READ_IMPLIES_EXEC then the break area is VM_EXEC, but omitted from
exec_vm since do_brk contains no __vm_stat_account call.  Later munmaps
count its pages out of exec_vm, hence (exec_vm - VmExe) can go negative.

do_brk is right not to call __vm_stat_account, its pages shouldn't need to
be counted.  What's wrong is that __vm_stat_account is counting all the
VM_EXEC pages, whereas (to mimic 2.4 and earlier 2.6) it should be leaving
VM_WRITE areas and non-vm_file areas out of exec_vm.

VmLib may still appear larger than before - where a READ_IMPLIES_EXEC
personality makes what was a readonly mapping of a file now executable e.g.
 /usr/lib/locale stuff.  And a program which mprotects its own text as
writable will appear with wrapped VmLib: sorry, but while it's worth
showing ordinary programs as ordinary, it's not worth much effort to avoid
showing odd ones as odd.
Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Acked-by: default avatarWilliam Lee Irwin III <wli@holomorphy.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8c54a50c
    • Hugh Dickins's avatar
      [PATCH] shmctl SHM_LOCK perms · 2637792e
      Hugh Dickins authored 
      Michael Kerrisk has observed that at present any process can SHM_LOCK any
shm segment of size within process RLIMIT_MEMLOCK, despite having no
permissions on the segment: surprising, though not obviously evil.  And any
process can SHM_UNLOCK any shm segment, despite no permissions on it: that
is surely wrong.

Unless CAP_IPC_LOCK, restrict both SHM_LOCK and SHM_UNLOCK to when the
process euid matches the shm owner or creator: that seems the least
surprising behaviour, which could be relaxed if a need appears later.
Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2637792e
    • Gerd Knorr's avatar
      [PATCH] uml: ramdisk config fix · 84aff047
      Gerd Knorr authored 
      ObviouslyCorrect[tm] buildfix ;)
Signed-off-by: default avatarGerd Knorr <kraxel@bytesex.org>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      84aff047
    • Heiko Carstens's avatar
      [PATCH] fix ext2/ext3 memory leak · b0a50ed8
      Heiko Carstens authored 
      The patch below fixes an ext2/ext3 memory leak: the *_fill_super functions
allocate percpu data structures but don't free them in *_put_super.
Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b0a50ed8
    • Andrew Morton's avatar
      [PATCH] do_task_stat() use pid_alive() · b9528b67
      Andrew Morton authored 
      Use pid_alive() rather than testing for a zero value of ->pid.  Is the right
thing to do and addresses an oops dereferencing real_parent which one person
reported.
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b9528b67
    • David Brownell's avatar
      [PATCH] reduce ext3 log spamming (blank lines) · 09775c85
      David Brownell authored 
      When drives go offline, e.g.  usb-storage disconnect, the upper layers
don't behave very intelligently yet: ext3 over scsi keeps retrying reads,
logging three lines for each error:

10:58:31  scsi0 (0:0): rejecting I/O to dead device
10:58:31  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:58:31 
10:59:47  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0

This patch shrinks that log spam by the trivial third, getting rid of those
needless blank lines.  It's not clear to me why the "no such device" errors
don't immediately make ext3 (or is it the block layer?) give up ...  maybe
someone else can make Linux not retry after those errors.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      09775c85
    • Andrew Morton's avatar
      [PATCH] direct-io: set PF_SYNCWRITE · 9f5354ec
      Andrew Morton authored 
      We need to set the PF_SYNCWRITE when performing direct-io writes.  Otherwise
the anticipatory scheduler exhibits bad read-starves-write problems.
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9f5354ec
    • Paul Mackerras's avatar
      [PATCH] ppc64: make UP kernel run on POWER4 logical partition · 6e27d936
      Paul Mackerras authored 
      Recently I tried booting a UP kernel on a 1-processor logical partition on
a POWER4 system.  It failed because the CPU we happened to be running on
was CPU 2, but hard_smp_processor_id() is defined to 0 for !CONFIG_SMP. 
(Note that this code runs quite early, as part of init_IRQ, so
hard_smp_processor_id() should be the physical ID of the boot cpu.)

This patch does a minimal fix to make it work.  I think this patch should
go in 2.6.10.  Ultimately I think the hard_smp_processor_id() definition
should be removed from include/linux/smp.h, but that carries a risk of
breaking other architectures and probably shouldn't be done pre 2.6.10.
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6e27d936
  3. 12 Dec, 2004 9 commits
  5. 11 Dec, 2004 3 commits
  7. 10 Dec, 2004 14 commits
  9. 09 Dec, 2004 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7