1. Jan 07, 2010
    • Mike Frysinger's avatar
      NOMMU: Avoiding duplicate icache flushes of shared maps · cfe79c00
      Mike Frysinger authored
      
      
      When working with FDPIC, there are many shared mappings of read-only
      code regions between applications (the C library, applet packages like
      busybox, etc.), but the current do_mmap_pgoff() function will issue an
      icache flush whenever a VMA is added to an MM instead of only doing it
      when the map is initially created.
      
      The flush can instead be done when a region is first mmapped PROT_EXEC.
      Note that we may not rely on the first mapping of a region being
      executable - it's possible for it to be PROT_READ only, so we have to
      remember whether we've flushed the region or not, and then flush the
      entire region when a bit of it is made executable.
      
      However, this also affects the brk area.  That will no longer be
      executable.  We can mprotect() it to PROT_EXEC on MPU-mode kernels, but
      for NOMMU mode kernels, when it increases the brk allocation, making
      sys_brk() flush the extra from the icache should suffice.  The brk area
      probably isn't used by NOMMU programs since the brk area can only use up
      the leavings from the stack allocation, where the stack allocation is
      larger than requested.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cfe79c00
    • Mike Frysinger's avatar
      FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack · 04e4f2b1
      Mike Frysinger authored
      The current code will load the stack size and protection markings, but
      then only use the markings in the MMU code path.  The NOMMU code path
      always passes PROT_EXEC to the mmap() call.  While this doesn't matter
      to most people whilst the code is running, it will cause a pointless
      icache flush when starting every FDPIC application.  Typically this
      icache flush will be of a region on the order of 128KB in size, or may
      be the entire icache, depending on the facilities available on the CPU.
      
      In the case where the arch default behaviour seems to be desired
      (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
      whether we should be setting PROT_EXEC or not.
      
      For arches that support an MPU (Memory Protection Unit - an MMU without
      the virtual mapping capability), setting PROT_EXEC or not will make an
      important difference.
      
      It should be noted that this change also affects the executability of
      the brk region, since ELF-FDPIC...
      04e4f2b1
    • Linus Torvalds's avatar
      Merge branch 'for-2.6.33' of git://linux-nfs.org/~bfields/linux · 93939f4e
      Linus Torvalds authored
      * 'for-2.6.33' of git://linux-nfs.org/~bfields/linux:
        sunrpc: fix peername failed on closed listener
        nfsd: make sure data is on disk before calling ->fsync
        nfsd: fix "insecure" export option
      93939f4e
    • Xiaotian Feng's avatar
      sunrpc: fix peername failed on closed listener · b292cf9c
      Xiaotian Feng authored
      There're some warnings of "nfsd: peername failed (err 107)!"
      socket error -107 means Transport endpoint is not connected.
      This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
      when kernel_getpeername returns -107. This means socket might be CLOSED.
      
      And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]
      
              if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
              <snip>
                      newxpt = xprt->xpt_ops->xpo_accept(xprt);
              <snip>
      
      So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.
      
      Let's take a look at commit b0401d72
      
      , this commit has moved the close
      processing after do recvfrom method, but this commit also introduces this
      warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
      close it, not accpet then close.
      
      Signed-off-by: default avatarXiaotian Feng <dfeng@redhat.com>
      Cc: J. Bruce Fields <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      b292cf9c
    • Christoph Hellwig's avatar
      nfsd: make sure data is on disk before calling ->fsync · 7211a4e8
      Christoph Hellwig authored
      
      
      nfsd is not using vfs_fsync, so I missed it when changing the calling
      convention during the 2.6.32 window.  This patch fixes it to not only
      start the data writeout, but also wait for it to complete before calling
      into ->fsync.
      
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      7211a4e8
    • Linus Torvalds's avatar
      Merge branch 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci · b1c0ec89
      Linus Torvalds authored
      * 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci:
        DaVinci: DM365: Add the device_enable for the DaVinci Keyscan
        davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci
        davinci: da8xx/omap-l1: mark RTC as a wakeup source
        davinci: cp_intc: provide set_wake function
        Davinci VPFE Capture: Take i2c adapter id through platform data
      b1c0ec89
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 · 642a74e7
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
        [SCSI] lpfc 8.3.7: Update Driver version to 8.3.7
        [SCSI] lpfc 8.3.7: Fix discovery failures.
        [SCSI] lpfc 8.3.7: Fix SCSI protocol related errors.
        [SCSI] lpfc 8.3.7: Fix hardware/SLI relates issues
        [SCSI] lpfc 8.3.7: Fix NPIV operation errors
        [SCSI] lpfc 8.3.7: Fix FC protocol errors
        [SCSI] stex: fix scan of nonexistent lun
        [SCSI] pmcraid: fix to avoid twice scsi_dma_unmap for a command
        [SCSI] qla2xxx: Update version number to 8.03.01-k9.
        [SCSI] qla2xxx: Added to EEH support.
        [SCSI] qla2xxx: Extend base EEH support in qla2xxx.
        [SCSI] qla2xxx: Fix for a multiqueue bug in CPU affinity mode
        [SCSI] qla2xxx: Get the link data rate explicitly during device resync.
        [SCSI] cxgb3i: Fix a login over vlan issue
      642a74e7
    • Miguel Aguilar's avatar
      DaVinci: DM365: Add the device_enable for the DaVinci Keyscan · c92b29ec
      Miguel Aguilar authored
      
      
      Adds the device_enable function to the DaVinci Keyscan platform data
      to setup the PINMUX configuration.
      
      It also removes #ifdef from the DM365 EVM board in order to load it
      properly as a module.
      
      Signed-off-by: default avatarMiguel Aguilar <miguel.aguilar@ridgerun.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      c92b29ec
    • Sekhar Nori's avatar
      davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci · ae88e05a
      Sekhar Nori authored
      All DaVinci platforms include a DSP or co-processor for
      audio/video acceleration.
      
      While creating memory for the DSP/co-processor, system
      integrator can end up creating a hole in the memory map
      of the sort:
      
      <kernel memory> <hole (memory for DSP)> <kernel memory>
      
      This sort of configuration needs ARCH_HAS_HOLES_MEMORYMODEL
      enabled. See further details see this discussion on ARM
      linux mailing list:
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html
      
      
      
      The patch is boot tested on OMAP-L138, DM6446 and DM355 EVMs
      
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      CC: Sriramakrishnan <srk@ti.com>
      CC: Khasim Syed Mohammed <khasim@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      ae88e05a
    • Sekhar Nori's avatar
      davinci: da8xx/omap-l1: mark RTC as a wakeup source · 75c99bb0
      Sekhar Nori authored
      
      
      On da850, RTC alarm is a wakeup source from deep sleep.
      Mark it as a wakeup source after the rtc platform device
      is registered.
      
      Without this patch, the rtc-omap driver suspends the RTC
      during the suspend sequence and hence it cannot wakeup the
      SoC.
      
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      75c99bb0
    • Sekhar Nori's avatar
      davinci: cp_intc: provide set_wake function · 2d3f5950
      Sekhar Nori authored
      
      
      There is nothing special to be done for interrupts
      which can wakeup the device from sleep on CP-INTC,
      but not having a set_wake implemented prevents use
      of common drivers which expect this function to be
      implemented for all wakeup interrupt sources.
      
      This patch fixes the issue encountered when using the
      omap-rtc driver on DA850. On DA850 the RTC alarm
      interrupt is used to wake up the SoC from deep sleep
      mode. Without this patch, the disable_irq_wake throws
      an unbalanced wake disable warning while resuming
      because the previous enable call fails for lack of
      set_wake implementation.
      
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      2d3f5950
    • Vaibhav Hiremath's avatar
      Davinci VPFE Capture: Take i2c adapter id through platform data · 077639f4
      Vaibhav Hiremath authored
      
      
      The I2C adapter ID is actually depends on Board and may vary, Davinci
      uses id=1, but in case of AM3517 id=3.
      
      So modified respective davinci board files.
      
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      077639f4
  2. Jan 06, 2010
  3. Jan 05, 2010