lkml.org 
[lkml]   [2011]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ocfs2-devel] fs/ocfs2/dlm: Use GFP_ATOMIC under spin_lock
On Thu, Jan 27, 2011 at 05:09:48PM -0800, Andrew Morton wrote:
> > - local = kmalloc(sizeof(qr->qr_regions), GFP_KERNEL);
> > + local = kmalloc(sizeof(qr->qr_regions), GFP_ATOMIC);
> > if (!local) {
> > status = -ENOMEM;
> > goto bail;
> >
>
> Switching to GFP_ATOMIC is the worst of all possible ways of "fixing"
> this bug. GFP_ATOMIC is *unreliable*. We don't want to introduce
> unreliability deep down inside our filesytems. And fs maintainers who
> don't want to make their filesystems less reliable shouldn't blindly
> apply patches that do so :(

Fair enough.

> A reliable way of fixing this bug is below. As an added bonus, it
> makes the fs faster.
>
> --- a/fs/ocfs2/dlm/dlmdomain.c~a
> +++ a/fs/ocfs2/dlm/dlmdomain.c
> @@ -926,9 +926,9 @@ static int dlm_assert_joined_handler(str
> }
>
> static int dlm_match_regions(struct dlm_ctxt *dlm,
> - struct dlm_query_region *qr)
> + struct dlm_query_region *qr, u8 *local)
> {
> - char *local = NULL, *remote = qr->qr_regions;
> + char *remote = qr->qr_regions;

Won't the stack-depth busybodies hate us for this? I realize we
don't go much deeper from here, but it still is 1K of stack.

Joel

--

"When arrows don't penetrate, see...
Cupid grabs the pistol."

http://www.jlbec.org/
jlbec@evilplan.org


\
 
 \ /
  Last update: 2011-01-28 02:39    [W:0.138 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site