public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.21pre5aa1
Date: Fri, 14 Mar 2003 04:50:29 -0800	[thread overview]
Message-ID: <20030314045029.2f05eeb5.akpm@digeo.com> (raw)
In-Reply-To: <20030314090825.GB1375@dualathlon.random>

Andrea Arcangeli <andrea@suse.de> wrote:
>
> Only in 2.4.21pre5aa1: 00_clean-inode-fix-1
> 
> 	Reset r_dev.

oops.  What problem was this observed to cause btw?

> Only in 2.4.21pre5aa1: 00_smp-timers-not-deadlocking-1
> 
> 	Corrected varsion of the smp timers that can deadlock in 2.5
> 	and in all kernels that were used to incorporate this patch,
> 	including jam.

OK, I'll take a look at that thanks.

> 	This is fixed so that a timer reinserting
> 	itself to run immediate, won't loop forever deadlocking
> 	a CPU spinning in a tight loop. This bug was present in
> 	ancient 2.4 kernels too and this is been fixed after bugreports
> 	in both 2.2 and again in 2.4 because we forgotten to forward
> 	port it to 2.4, these fixes must be forward ported today
> 	to 2.5 too. Fixed also run_all_timers to correctly convert
> 	the logical to physical cpu id (doesn't matter on x86, but
> 	run_all_timers doesn't matter either on x86, other archs
> 	may need this fix to avoid crashing too). This patch
> 	was originally written from Ingo Molnar, David Miller with the help of
> 	Alexey Kuznetsov, for more details see the timer.c added credit lines.

This code is buggy.  See

http://linux.bkbits.net:8080/linux-2.5/user=akpm/cset@1.786.202.5?nav=!-|index.html|stats|!+|index.html|ChangeSet@-6M


> Only in 2.4.21pre5aa1: 9999_fsync-msync-async-errors-1
> 
> 	Allow userspace to always be notified about async write failures
> 	when calling msync and fsync even if they happened long before
> 	the systemcall run.

The code in shrink_cache() has a couple of problems.

a) If someone else is truncating the file at the same time,
   block_write_full_page() will see the page is outside i_size and will
   return -EIO.  That will be propagated into the address_space and
   userspace will see a bogus I/O error.

   Fix: just return zero from writepage-outside-i_size.  There are several
   instances.

b) Can't touch `mapping' after calling writepage().  The page can now be
   unlocked, truncated off the inode and the inode could be freed up.

   No, I don't have a testcase ;)

   The fix is to lock the page again, see if it still has a ->mapping,
   then set mapping->error.



  parent reply	other threads:[~2003-03-14 12:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-14  9:08 2.4.21pre5aa1 Andrea Arcangeli
2003-03-14 10:15 ` 2.4.21pre5aa1 Marc-Christian Petersen
2003-03-14 10:29   ` 2.4.21pre5aa1 Andrea Arcangeli
2003-03-14 12:50 ` Andrew Morton [this message]
2003-03-14 17:27   ` 2.4.21pre5aa1 Andrea Arcangeli
2003-03-14 13:39 ` 2.4.21pre5aa1 Marc-Christian Petersen
2003-03-14 17:05   ` 2.4.21pre5aa1 Marc-Christian Petersen
2003-03-14 17:10   ` 2.4.21pre5aa1 Marc-Christian Petersen
2003-03-14 17:38     ` 2.4.21pre5aa1 Andrea Arcangeli
2003-03-14 18:04       ` 2.4.21pre5aa1 Marc-Christian Petersen
2003-03-14 23:13         ` 2.4.21pre5aa1 Andrea Arcangeli
2003-03-14 13:53 ` 2.4.21pre5aa1 Rik van Riel
2003-03-14 17:35   ` 2.4.21pre5aa1 Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030314045029.2f05eeb5.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox