public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Rik van Riel <riel@conectiva.com.br>,
	Andrew Morton <akpm@digeo.com>,
	torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	tytso@thunk.org, rddunlap@osdl.org
Subject: Re: [PATCH][RESEND 3] disassociate_ctty SMP fix
Date: Wed, 5 Feb 2003 14:51:26 +0000	[thread overview]
Message-ID: <20030205145126.A28758@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030205095114.A25479@flint.arm.linux.org.uk>; from rmk@arm.linux.org.uk on Wed, Feb 05, 2003 at 09:51:14AM +0000

Ok, what seems to be going on is as follows:

1. you kill 'dd' as per the bug report
2. the kernel closes the file descriptors that 'dd' had open as part of
   the do_exit() cleanup.
3. this calls tty_release(), which takes the BKL, and the tty layer
   does its necessary cleanup, setting filp->private_data to NULL.
   *note* the file descriptor is still on the tty->tty_files list.
4. tty_release() releases the BKL, at which point preemption occurs,
   switching to the master sshd process.
5. sshd closes the master end of the pty device, which causes
   tty_vhangup to be called.
6. do_tty_hangup scans the file descriptors attached to tty->tty_files,
   and calls tty_fasync for each.
7. we come across the file descriptor that 'dd' had open (since it is
   still on the tty->tty_files list).
8. tty_fasync looks at filp->private_data, and tty_paranoia_check finds
   it to be NULL, and so complains.

So, where do we take the file descriptor off the tty list?  __fput() -
list_del(&file->f_list);

This problem could still be present on non-preempt configurations,
although to a lesser degree.  As the code currently stands in both
2.4 and 2.5, we generally do not see any reschedules between tty_release
and __fput which would allow the above scenario to occur.  Preempt
just provides the extra bait for the bug to show itself.

As to the fix, umm, yea.  I'll get to that in a little while.  The good
news is that we know what's happening now.

(note: the "scheduling while atomic" below is caused by the method I
used to discover this problem, and shows the point at which the pesky
reschedule happened in the tty code.  pid135 is the dd process on the
pty slave end, pid130 is the sshd on the pty master end.)

tty_release: (pid=135) filp = c131ecb4 filp->private_data = c12d3000
bad: scheduling while atomic!
[<c0227d10>] (dump_stack+0x0/0x14)
[<c023cde8>] (schedule+0x0/0x3b4)
[<c023d19c>] (preempt_schedule+0x0/0x50)
[<c02f17b8>] (tty_release+0x0/0x110)
[<c0276230>] (__fput+0x0/0x1a8)
[<c02761f8>] (fput+0x0/0x38)
[<c0274864>] (filp_close+0x0/0x110)
[<c0242b0c>] (put_files_struct+0x0/0x110)
[<c024357c>] (do_exit+0x0/0x528)
[<c024a724>] (sig_exit+0x0/0x74)
[<c02268f8>] (do_signal+0x0/0x470)
[<c0226d68>] (do_notify_resume+0x0/0x34)
tty_release: (pid=130) filp = c131e984 filp->private_data = c1264000
do_tty_hangup: (pid=130) filp = c131ecb4, filp->private_data = 00000000
Warning: null TTY for (88:01) in tty_fasync
tty_release: (pid=130) done
tty_release: (pid=135) done

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2003-02-05 14:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05  0:36 [PATCH][RESEND 3] disassociate_ctty SMP fix Rik van Riel
2003-02-05  1:07 ` Rik van Riel
2003-02-05  1:51   ` Andrew Morton
2003-02-05  1:58     ` Rik van Riel
2003-02-05  9:51       ` Russell King
2003-02-05 14:51         ` Russell King [this message]
2003-02-05 16:49           ` Russell King

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=20030205145126.A28758@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=riel@conectiva.com.br \
    --cc=torvalds@transmeta.com \
    --cc=tytso@thunk.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