1. 11 10月, 2005 31 次提交
  2. 10 10月, 2005 9 次提交
    • M
      [PATCH] i386: fix stack alignment for signal handlers · d347f372
      Markus F.X.J. Oberhumer 提交于
      This fixes the setup of the alignment of the signal frame, so that all
      signal handlers are run with a properly aligned stack frame.
      
      The current code "over-aligns" the stack pointer so that the stack frame
      is effectively always mis-aligned by 4 bytes.  But what we really want
      is that on function entry ((sp + 4) & 15) == 0, which matches what would
      happen if the stack were aligned before a "call" instruction.
      Signed-off-by: NMarkus F.X.J. Oberhumer <markus@oberhumer.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d347f372
    • B
      [PATCH] ide: Workaround PM problem · 867f8b4e
      Benjamin Herrenschmidt 提交于
      The logic in ide_do_request() doesn't guarantee that both drives will be
      serviced after a call.  It may "forget" to service one in some
      circumstances, including when one of the drive is suspended (it will
      eventually fail to service the slave when the master is suspended for
      example).  This prevents the wakeup requests that gets queued on wakeup
      from sleep from beeing serviced in some cases when 2 drives are sharing
      an IDE bus.
      
      The problem is deep enough in the way this code works (and there are
      probably a few other problematic but rare corner cases) and fixing it
      would require some major rethinking of the way IDE decides which channel
      to service.  This is not 2.6.14 material.  However, in the meantime,
      Bart has accepted this simple workaround that will fix the crash on
      wakeup from sleep since this specific corner case is actually hitting
      users to get into 2.6.14.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      867f8b4e
    • T
      [PATCH] relayfs: fix bogus param value in call to vmap · 1cc956e1
      Tom Zanussi 提交于
      The third param in this call to vmap shouldn't be GFP_KERNEL, which
      makes no sense, but rather VM_MAP.  Thanks to Al Viro for spotting
      this.
      Signed-off-by: NTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1cc956e1
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · eb1b74e0
      Linus Torvalds 提交于
      eb1b74e0
    • J
      [PATCH] uml: fix x86_64 with !CONFIG_FRAME_POINTER · 50f72b57
      Jeff Dike 提交于
      UML/x86_64 doesn't run when built with frame pointers disabled.  There
      was an implicit frame pointer assumption in the stub segfault handler.
      With frame pointers disabled, UML dies on handling its first page fault.
      
      The container-of part of this is from Paolo Giarrusso <blaisorblade@yahoo.it>.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      50f72b57
    • R
      [PATCH] x86_64: Set up safe page tables during resume · 3dd08325
      Rafael J. Wysocki 提交于
      The following patch makes swsusp avoid the possible temporary corruption
      of page translation tables during resume on x86-64.  This is achieved by
      creating a copy of the relevant page tables that will not be modified by
      swsusp and can be safely used by it on resume.
      
      The problem is that during resume on x86-64 swsusp may temporarily
      corrupt the page tables used for the direct mapping of RAM.  If that
      happens, a page fault occurs and cannot be handled properly, which leads
      to the solid hang of the affected system.  This leads to the loss of the
      system's state from before suspend and may result in the loss of data or
      the corruption of filesystems, so it is a serious issue.  Also, it
      appears to happen quite often (for me, as often as 50% of the time).
      
      The problem is related to the fact that (at least) one of the PMD
      entries used in the direct memory mapping (starting at PAGE_OFFSET)
      points to a page table the physical address of which is much greater
      than the physical address of the PMD entry itself.  Moreover,
      unfortunately, the physical address of the page table before suspend
      (i.e.  the one stored in the suspend image) happens to be different to
      the physical address of the corresponding page table used during resume
      (i.e.  the one that is valid right before swsusp_arch_resume() in
      arch/x86_64/kernel/suspend_asm.S is executed).  Thus while the image is
      restored, the "offending" PMD entry gets overwritten, so it does not
      point to the right physical address any more (i.e.  there's no page
      table at the address pointed to by it, because it points to the address
      the page table has been at during suspend).  Consequently, if the PMD
      entry is used later on, and it _is_ used in the process of copying the
      image pages, a page fault occurs, but it cannot be handled in the normal
      way and the system hangs.
      
      In principle we can call create_resume_mapping() from
      swsusp_arch_resume() (ie.  from suspend_asm.S), but then the memory
      allocations in create_resume_mapping(), resume_pud_mapping(), and
      resume_pmd_mapping() must be made carefully so that we use _only_
      NosaveFree pages in them (the other pages are overwritten by the loop in
      swsusp_arch_resume()).  Additionally, we are in atomic context at that
      time, so we cannot use GFP_KERNEL.  Moreover, if one of the allocations
      fails, we should free all of the allocated pages, so we need to trace
      them somehow.
      
      All of this is done in the appended patch, except that the functions
      populating the page tables are located in arch/x86_64/kernel/suspend.c
      rather than in init.c.  It may be done in a more elegan way in the
      future, with the help of some swsusp patches that are in the works now.
      
      [AK: move some externs into headers, renamed a function]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3dd08325
    • P
      [PATCH] uml: cleanup whitespace for COW driver · 52a2d3e4
      Paolo 'Blaisorblade' Giarrusso 提交于
      Fix whitespace - I split this off the previous patch for easier review.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      52a2d3e4
    • P
      [PATCH] uml: cleanup byte order macros for COW driver · 028c0cc1
      Paolo 'Blaisorblade' Giarrusso 提交于
      After restoring the existing code, make it work also when included in
      kernelspace code (which isn't currently the case, but at least this will prevent
      people from "fixing" it as just happened).
      Whitespace is fixed in next patch - it cluttered the diff too much.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      028c0cc1
    • P
      [PATCH] uml: restore include breakage, breaking binary format of COW driver · 855ec613
      Paolo 'Blaisorblade' Giarrusso 提交于
      Commit 44456d37, between 2.6.13-rc3 and -rc4,
      was a "nice cleanup" which broke something. Revert the offending part.
      
      It broke because:
      a) because this part doesn't fall under the description
      b) the author didn't know what he was doing here
      c) the author didn't try to compile the existing code and see that it worked
         perfectly.
      d) the author didn't ask us what was happening
      e) you didn't either, and somebody there should have learned that UML is a bit
         different.
      
      In fact, UML is special in linking to host libc and using its includes.
      
      In particular, since host includes always define both __BIG_ENDIAN and
      __LITTLE_ENDIAN, ntohll() macros started thinking to be in a big-endian world;
      and on-disk compatibility was broken.
      
      Many thanks go to Nix for reporting the problem and correctly diagnosing an
      endianness problem.
      
      Btw, this patch restores the previous code, which worked; but the definitions
      would be uncorrect if used in kernelspace files.
      
      Next patch addresses that.
      
      Cc: Nix <nix@esperi.org.uk>, Olaf Hering <olh@suse.de>
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      855ec613