All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2/dlmfs: use GFP_KERNEL instead of GFP_NOFS
Date: Tue, 16 Nov 2010 09:19:08 -0800	[thread overview]
Message-ID: <4CE2BD0C.3020501@oracle.com> (raw)
In-Reply-To: <201011161537.oAG4gEQI002875@acsinet15.oracle.com>

We do NOFS allocs in the dlm to prevent deadlocks (not live locks).
And you are right we don't have to do NOFS allocs here. But the sizes
we are talking about are really small. Do we really care?

On 11/16/2010 07:33 AM, Wengang Wang wrote:
> There is no need for dlmfs to sync data to disk so that no memory is needed
> for that purpose. So no worry about the live lock: sync data ->  alloc mem ->
> sync data ->.... We'd better use GFP_KERNEL instead of GFP_NOFS to allow FS sync
> during the memory allocation.
>
> Signed-off-by: Wengang Wang<wen.gang.wang@oracle.com>
> ---
>   fs/ocfs2/dlmfs/dlmfs.c |    8 ++++----
>   1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ocfs2/dlmfs/dlmfs.c b/fs/ocfs2/dlmfs/dlmfs.c
> index b2df490..979b593 100644
> --- a/fs/ocfs2/dlmfs/dlmfs.c
> +++ b/fs/ocfs2/dlmfs/dlmfs.c
> @@ -151,7 +151,7 @@ static int dlmfs_file_open(struct inode *inode,
>   	 * doesn't make sense for LVB writes. */
>   	file->f_flags&= ~O_APPEND;
>
> -	fp = kmalloc(sizeof(*fp), GFP_NOFS);
> +	fp = kmalloc(sizeof(*fp), GFP_KERNEL);
>   	if (!fp) {
>   		status = -ENOMEM;
>   		goto bail;
> @@ -265,7 +265,7 @@ static ssize_t dlmfs_file_read(struct file *filp,
>   	else
>   		readlen = count;
>
> -	lvb_buf = kmalloc(readlen, GFP_NOFS);
> +	lvb_buf = kmalloc(readlen, GFP_KERNEL);
>   	if (!lvb_buf)
>   		return -ENOMEM;
>
> @@ -313,7 +313,7 @@ static ssize_t dlmfs_file_write(struct file *filp,
>   	else
>   		writelen = count - *ppos;
>
> -	lvb_buf = kmalloc(writelen, GFP_NOFS);
> +	lvb_buf = kmalloc(writelen, GFP_KERNEL);
>   	if (!lvb_buf)
>   		return -ENOMEM;
>
> @@ -344,7 +344,7 @@ static struct inode *dlmfs_alloc_inode(struct super_block *sb)
>   {
>   	struct dlmfs_inode_private *ip;
>
> -	ip = kmem_cache_alloc(dlmfs_inode_cache, GFP_NOFS);
> +	ip = kmem_cache_alloc(dlmfs_inode_cache, GFP_KERNEL);
>   	if (!ip)
>   		return NULL;
>

  reply	other threads:[~2010-11-16 17:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16 15:33 [Ocfs2-devel] [PATCH] ocfs2/dlmfs: use GFP_KERNEL instead of GFP_NOFS Wengang Wang
2010-11-16 17:19 ` Sunil Mushran [this message]
2010-11-17  1:12   ` Wengang Wang
2010-11-17 23:29     ` Joel Becker

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=4CE2BD0C.3020501@oracle.com \
    --to=sunil.mushran@oracle.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /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.