All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-serial@vger.kernel.org,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	gregkh@linuxfoundation.org, Jan Kara <jack@suse.cz>,
	"Ted Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH 2/2] make both atomic_write_lock and BTM lock acquirement sleepable at tty_write_message()
Date: Sat, 30 Jun 2012 21:35:32 +0800	[thread overview]
Message-ID: <4FEF00A4.6050502@oracle.com> (raw)
In-Reply-To: <20120630134412.55eea39a@pyramind.ukuu.org.uk>

Hey Alan,

On 06/30/2012 08:44 PM, Alan Cox wrote:

>> +		 * tty_write_message() will invoked by print_warning()
>> +		 * at fs/quota/dquot.c if CONFIG_PRINT_QUOTA_WARNING
>> +		 * is enabled when a user running out of disk quota limits.
>> +		 * It will end up call tty_write().  Here is a potential race
> 
> tty->ops->write is the low level write method, not tty_write.

I was wondering if below call trace is come from tty_write_message()->tty->ops->write()?
[ 2739.802106] -> #1 (&mm->mmap_sem){++++++}:
[ 2739.802120]        [<c10fa825>] lock_acquire+0x14e/0x189
[ 2739.802133]        [<c11e3e83>] might_fault+0xbf/0xf8
[ 2739.802154]        [<c13bcbdf>] _copy_from_user+0x40/0x8a
[ 2739.802175]        [<c14addc3>] copy_from_user+0x16/0x26
[ 2739.802195]        [<c14b00b4>] tty_write+0x282/0x3c7
[ 2739.802212]        [<c14b02dd>] redirected_tty_write+0xe4/0xfd
[ 2739.802226]        [<c1231879>] vfs_write+0xf5/0x1a3
[ 2739.802239]        [<c1231bdc>] sys_write+0x6c/0xa9
[ 2739.802253]        [<c186281f>] sysenter_do_call+0x12/0x38

> 
> This appears to be even more wrong than the other one in other ways too -
> it uses interruptible sleeps but doesn't handle the signal case so will
> spin on a signal and kill the box.
> 
> NAK
> 
> Looking gat the traces I suspect what you've actually got is a much more
> complicated deadlock where a process doing perfectly normal I/O to the
> tty has faulted and there is a chain of dependancies through the file
> system code to the thread which is doing the dquot_alloc_inode.
> 
> If that is the case then dquot_alloc_inode shouldn't be making blocking
> calls to tty_write_message and probably the right thing to do is to queue
> work for it so the tty_write_message is done asynchronously.
> 
> There are a very limited number of events that need reporting so probably
> something like a per mount flags and workqueue would allow you to do
> 
> 	set_bit(DQUOT_INODEOVER, &foo->events);
> 	schedule_work()
> 
> and the work queue can just xchg the events long for 0 and spew any
> messages required.

Thanks for the teaching, I'll give a try. 

-Jeff

> 
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



      reply	other threads:[~2012-06-30 13:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-30  9:40 [PATCH 2/2] make both atomic_write_lock and BTM lock acquirement sleepable at tty_write_message() Jeff Liu
2012-06-30 12:44 ` Alan Cox
2012-06-30 13:35   ` Jeff Liu [this message]

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=4FEF00A4.6050502@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.