Re: Fw: crash on x86_64 - mm related?

From: Kai Makisara (Kai.Makisara_at_kolumbus.fi)
Date: 11/30/05

  • Next message: Michael Krufky: "Re: Gene's pcHDTV 3000 analog problem"
    Date:	Wed, 30 Nov 2005 07:12:21 +0200 (EET)
    To: Ryan Richter <ryan@tau.solarneutrino.net>
    
    

    On Tue, 29 Nov 2005, Kai Makisara wrote:

    > On Tue, 29 Nov 2005, Ryan Richter wrote:
    >
    > > On Tue, Nov 29, 2005 at 10:04:39PM +0200, Kai Makisara wrote:
    > > > I looked at the driver and it seems that there is a bug: st_write calls
    > > > release_buffering at the end even when it has started an asynchronous
    > > > write. This means that it releases the mapping while it is being used!
    > > > (I wonder why this has not been noticed earlier.)
    > > >
    > > > The patch below (against 2.6.15-rc2) should fix this bug and some others
    > > > related to buffering. It is based on the patch "[PATCH] SCSI tape direct
    > > > i/o fixes" I sent to linux-scsi on Nov 21. The patch restores setting
    > > > pages dirty after reading and clears number of s/g segments when the
    > > > pointers are not valid any more.
    > > >
    > > > The patch has been lightly tested with AMD64.
    > >
    > > This applies cleanly to 2.6.14.2, do you forsee any problems using it
    > > with that kernel? I'd like to not change too many things at once.
    > >
    > No, I don't see any potential problems applying this patch to 2.6.14.2.
    > There is nothing specific to 2.6.15-rc2.
    >
    > If someone sees that there is something wrong, please yell. The
    > main purpose of the patch is not to call release_buffering() at the end of
    > st_write() when starting asynchronous write and call it in
    > write_behind_check() instead.
    >
    Yelling!

    The patch does not cause any problems but my theory about calling
    release_buffering() too early is wrong: asynchronous writes are not done
    with direct i/o. (The reason for this choice is that the API allows the
    user to do anything with the buffer between writes and so the SCSI write
    has to be finished before returning from write().)

    The other fixes in the patch are valid but I don't see how they should fix
    this problem.

    -- 
    Kai
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Michael Krufky: "Re: Gene's pcHDTV 3000 analog problem"

    Relevant Pages

    • Re: Granting some root permissions to certain users
      ... We use a kernel patch called trustees to do just what you're talking ... Unfortunately the patch hasn't really been kept up-to-date. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RT-V0.7.47-17 build fails
      ... On Monday 06 June 2005 03:41, Ingo Molnar wrote: ... >> I thought maybe I'd exersize this kernel, but a patch I thought ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
      ... to avoid so we can get this in to the 2.6 kernel ASAP. ... I am pretty certain the patch won't impact the ... > might want to kill the condition depending on the stepping, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.3-rc1-mm1
      ... > This is the first time that anyone told me that it even existed. ... When we're at kernel version 2.6.3! ... without this patch. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Question re the dot releases such as 2.6.12.3
      ... I'll submit a patch to the ... > kernel from the home page. ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)