1. 11 Oct, 2005 9 commits
    • akpm@osdl.org's avatar
      [PATCH] binfmt_elf bss padding fix · 6de50517
      akpm@osdl.org authored
      Nir Tzachar <tzachar@cs.bgu.ac.il> points out that if an ELF file specifies a
      zero-length bss at a whacky address, we cannot load that binary because
      padzero() tries to zero out the end of the page at the whacky address, and
      that may not be writeable.
      
      See also http://bugzilla.kernel.org/show_bug.cgi?id=5411
      
      So teach load_elf_binary() to skip the bss settng altogether if the elf file
      has a zero-length bss segment.
      
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Daniel Jacobowitz <dan@debian.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6de50517
    • Paolo Galtieri's avatar
      [PATCH] ppc highmem fix · a0c111c6
      Paolo Galtieri authored
      I've noticed that the calculations for seg_size and nr_segs in
      __dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong.  The
      incorrect calculations can result in either an oops or a panic when running
      fsck depending on the size of the partition.
      
      The problem with the seg_size calculation is that it can result in a
      negative number if size is offset > size.  The problem with the nr_segs
      caculation is returns the wrong number of segments, e.g.  it returns 1 when
      size is 200 and offset is 4095, when it should return 2 or more.
      Acked-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>
      a0c111c6
    • Suzuki's avatar
      [PATCH] madvise: Avoid returning error code -EBADF for anonymous mappings · 1bef4003
      Suzuki authored
      Revert this recent correctness change: Douglas Crosher <dcrosher@scieneer.com>
      reported that it broke an existing application, and that madvise() works
      without error on anonymous mappings on Solaris.
      
      This means that madvise() will remain non-standards-compliant: we should
      return -EBADF for all requests against non-file-backed vma's, but Linux only
      does this for MADV_WILLNEED requests.
      Signed-off-by: default avatarSuzuki K P <suzuki@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1bef4003
    • Andreas Gruenbacher's avatar
      [PATCH] nfsacl: Solaris VxFS compatibility fix · 22c1ea44
      Andreas Gruenbacher authored
      Here is a compatibility fix between Linux and Solaris when used with VxFS
      filesystems: Solaris usually accepts acl entries in any order, but with
      VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
      in canonical form.  It may also fail with other non-canonical acls -- I
      can't tell, because that case never triggers: We only send non-canonical
      acls when we fake up an ACL_MASK entry.
      
      Instead of adding fake ACL_MASK entries at the end, inserting them in the
      correct position makes Solaris+VxFS happy.  The Linux client and server
      sides don't care about entry order.  The three-entry-acl special case in
      which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode.  The
      patch moves this into nfsacl_encode.
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@suse.de>
      Acked-by: default avatarTrond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      22c1ea44
    • Latchesar Ionkov's avatar
      [PATCH] v9fs: remove additional buffer allocation from v9fs_file_read and v9fs_file_write · 19cba8ab
      Latchesar Ionkov authored
      v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
      as the data buffer received as parameter.  kmalloc cannot be used to
      allocate buffers bigger than 128K, so reading/writing data in chunks bigger
      than 128k fails.
      
      This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
      buffers as big as the maximum data that can be sent in one 9P message.
      Signed-off-by: default avatarLatchesar Ionkov <lucho@ionkov.net>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      19cba8ab
    • Abhay Salunke's avatar
      [PATCH] dell_rbu: changes in packet update mechanism · ad6ce87e
      Abhay Salunke authored
      In the current dell_rbu code ver 2.0 the packet update mechanism makes the
      user app dump every individual packet in to the driver.
      
      This adds in efficiency as every packet update makes the
      /sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
      again.  Thus the user app needs to wait for the files to reappear to dump
      another packet.  This slows down the packet update tremendously in case of
      large number of packets.  I am submitting a new patch for dell_rbu which will
      change the way we do packet updates;
      
      In the new method the user app will create a new single file which has already
      packetized the rbu image and all the packets are now staged in this file.
      
      This driver also creates a new entry in
      /sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
      size here before downloading the packet file.
      
      The user should do the following:
      
       create one single file which has all the packets stacked together.
       echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
       echo 1 > /sys/class/firmware/dell_rbu/loading
       cat the packetfile > /sys/class/firmware/dell_rbu/data
       echo 0 > /sys/class/firmware/dell_rbu/loading
      
      The driver takes the file which came through /sys/class/firmware/dell_rbu/data
      and takes chunks of paket_size data from it and place in contiguous memory.
      
      This makes packet update process very efficient and fast.  As all the packet
      update happens in one single operation.  The user can still read back the
      downloaded file from /sys/devices/platform/dell_rbu/data.
      Signed-off-by: default avatarAbhay Salunke <abhay_salunke@dell.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ad6ce87e
    • Anton Blanchard's avatar
      [PATCH] ppc64: Fix PCI hotplug · e4314bf4
      Anton Blanchard authored
      pSeries_irq_bus_setup is marked __devinit but references s7a_workaround
      which is marked __initdata.
      
      Depending on who got the memory for s7a_workaround (and if the value was
      now positive), it was possible for PCI hotplugged devices to have 3
      subtracted from their interrupt number.  This would happen randomly and
      caused me much confusion :)
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e4314bf4
    • Cornelia Huck's avatar
      [PATCH] s390: ccw device reconnect oops. · e5945b4f
      Cornelia Huck authored
      Search for a disconnect ccw_device on the ccw bus rather than on the css
      bus (was a typo in patch I did for the klist conversion).  A cast to an
      embedding ccw_device from an embedded device in a struct subchannel will
      lead us to oopses.
      Signed-off-by: default avatarCornelia Huck <cohuck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e5945b4f
    • Linus Torvalds's avatar
      Linux v2.6.14-rc4 · 907a4261
      Linus Torvalds authored
      907a4261
  2. 10 Oct, 2005 31 commits