All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org,
	dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org,
	oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
	davidel-AhlLAIvw+VEjIGhXcJzhZg@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	hch-jcswGhMUV9g@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org
Subject: Re: [PATCH 2/4] Convert epoll to a bitlock
Date: Wed, 4 Feb 2009 08:13:20 +0100	[thread overview]
Message-ID: <20090204071320.GA19348@lst.de> (raw)
In-Reply-To: <20090203161931.4054a25e-vw3g6Xz/EtPk1uMJSBkQmQ@public.gmane.org>

On Tue, Feb 03, 2009 at 04:19:31PM -0700, Jonathan Corbet wrote:
>  1) Use i_lock to protect accesses to f_flags.  This would enable some 
>     BKL usage to be removed, but would not fix fasync.

What about just turning f_ep_lock into f_lock and using it?

>  2) Move responsibility for the FASYNC bit into ->fasync(), with
>     fasync_helper() doing it in almost all situations.  The remaining
>     BKL usage would then go away.
> 
>  3) The same optional fasync() return values cleanup.

These two sound like a good thing to do no matter what the final locking
looks like.  I think they should be moved to the front of the patch
series and queued up no matter what.

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

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	mpm@selenic.com, dada1@cosmosbay.com,
	linux-kernel@vger.kernel.org, andi@firstfloor.org,
	oleg@redhat.com, viro@ZenIV.linux.org.uk,
	davidel@xmailserver.org, davem@davemloft.net, hch@lst.de,
	linux-api@vger.kernel.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCH 2/4] Convert epoll to a bitlock
Date: Wed, 4 Feb 2009 08:13:20 +0100	[thread overview]
Message-ID: <20090204071320.GA19348@lst.de> (raw)
In-Reply-To: <20090203161931.4054a25e@bike.lwn.net>

On Tue, Feb 03, 2009 at 04:19:31PM -0700, Jonathan Corbet wrote:
>  1) Use i_lock to protect accesses to f_flags.  This would enable some 
>     BKL usage to be removed, but would not fix fasync.

What about just turning f_ep_lock into f_lock and using it?

>  2) Move responsibility for the FASYNC bit into ->fasync(), with
>     fasync_helper() doing it in almost all situations.  The remaining
>     BKL usage would then go away.
> 
>  3) The same optional fasync() return values cleanup.

These two sound like a good thing to do no matter what the final locking
looks like.  I think they should be moved to the front of the patch
series and queued up no matter what.


  parent reply	other threads:[~2009-02-04  7:13 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-02 18:20 [PATCH/RFC] F_SETFL/Fasync BKL removal, now without unsightly global locks Jonathan Corbet
2009-02-02 18:20 ` Jonathan Corbet
     [not found] ` <1233598811-6871-1-git-send-email-corbet-T1hC0tSOHrs@public.gmane.org>
2009-02-02 18:20   ` [PATCH 1/4] Use bit operations for file->f_flags Jonathan Corbet
2009-02-02 18:20     ` Jonathan Corbet
     [not found]     ` <1233598811-6871-2-git-send-email-corbet-T1hC0tSOHrs@public.gmane.org>
2009-02-03 21:37       ` Andrew Morton
2009-02-03 21:37         ` Andrew Morton
2009-02-02 18:20   ` [PATCH 2/4] Convert epoll to a bitlock Jonathan Corbet
2009-02-02 18:20     ` Jonathan Corbet
     [not found]     ` <1233598811-6871-3-git-send-email-corbet-T1hC0tSOHrs@public.gmane.org>
2009-02-03 21:39       ` Andrew Morton
2009-02-03 21:39         ` Andrew Morton
     [not found]         ` <20090203133942.2ecec281.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2009-02-03 21:55           ` Eric Dumazet
2009-02-03 21:55             ` Eric Dumazet
     [not found]             ` <4988BD4E.8080206-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2009-02-03 22:05               ` Andrew Morton
2009-02-03 22:05                 ` Andrew Morton
     [not found]                 ` <20090203140543.6e915f97.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2009-02-03 22:22                   ` Matt Mackall
2009-02-03 22:22                     ` Matt Mackall
2009-02-03 22:37                     ` Jonathan Corbet
2009-02-03 22:37                       ` Jonathan Corbet
     [not found]                       ` <20090203153740.363d0a04-vw3g6Xz/EtPk1uMJSBkQmQ@public.gmane.org>
2009-02-03 22:53                         ` Andrew Morton
2009-02-03 22:53                           ` Andrew Morton
     [not found]                           ` <20090203145346.8df40277.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2009-02-03 23:09                             ` Davide Libenzi
2009-02-03 23:09                               ` Davide Libenzi
     [not found]                               ` <alpine.DEB.1.10.0902031508280.23050-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2009-02-03 23:12                                 ` Davide Libenzi
2009-02-03 23:12                                   ` Davide Libenzi
2009-02-03 23:19                             ` Jonathan Corbet
2009-02-03 23:19                               ` Jonathan Corbet
     [not found]                               ` <20090203161931.4054a25e-vw3g6Xz/EtPk1uMJSBkQmQ@public.gmane.org>
2009-02-03 23:29                                 ` Andrew Morton
2009-02-03 23:29                                   ` Andrew Morton
2009-02-04  7:13                                 ` Christoph Hellwig [this message]
2009-02-04  7:13                                   ` Christoph Hellwig
     [not found]                                   ` <20090204071320.GA19348-jcswGhMUV9g@public.gmane.org>
2009-02-04  7:20                                     ` Nick Piggin
2009-02-04  7:20                                       ` Nick Piggin
     [not found]                                       ` <200902041820.20535.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>
2009-02-04 13:34                                         ` Jonathan Corbet
2009-02-04 13:34                                           ` Jonathan Corbet
2009-02-04 16:51                                     ` Davide Libenzi
2009-02-04 16:51                                       ` Davide Libenzi
2009-02-03 23:08               ` Davide Libenzi
2009-02-03 23:08                 ` Davide Libenzi
     [not found]                 ` <alpine.DEB.1.10.0902031446280.23050-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2009-02-04  2:48                   ` Eric Dumazet
2009-02-04  2:48                     ` Eric Dumazet
2009-02-04  1:00         ` wli
2009-02-04  4:54         ` Nick Piggin
2009-02-02 18:20   ` [PATCH 3/4] Move FASYNC bit handling to f_op->fasync() Jonathan Corbet
2009-02-02 18:20     ` Jonathan Corbet
2009-02-02 18:20   ` [PATCH 4/4] Rationalize fasync return values Jonathan Corbet
2009-02-02 18:20     ` Jonathan Corbet

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=20090204071320.GA19348@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
    --cc=andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org \
    --cc=corbet-T1hC0tSOHrs@public.gmane.org \
    --cc=dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=davidel-AhlLAIvw+VEjIGhXcJzhZg@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org \
    --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.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 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.