David Teigland writes:
> > +#define RETRY_MALLOC(do_this, until_this) \
> > +for (;;) { \
> > + { do_this; } \
> > + if (until_this) \
> > + break; \
> > + if (time_after_eq(jiffies, gfs2_malloc_warning + 5 * HZ)) { \
> > + printk("GFS2: out of memory: %s, %u\n", __FILE__, __LINE__); \
> > + gfs2_malloc_warning = jiffies; \
> > + } \
> > + yield(); \
> > +}
>
> Please drop this.
Done in the spot that could deal with an error, but there are three other
places that still need it.
Which places are those? I only see these:
gfs2-02.patch:+ RETRY_MALLOC(ip = kmem_cache_alloc(gfs2_inode_cachep,
GFP_KERNEL), ip);
gfs2-02.patch-+ gfs2_memory_add(ip);
gfs2-02.patch-+ memset(ip, 0, sizeof(struct gfs2_inode));
gfs2-02.patch-+
gfs2-02.patch-+ ip->i_num = *inum;
gfs2-02.patch-+
-> GFP_NOFAIL.
gfs2-02.patch:+ RETRY_MALLOC(page =
grab_cache_page(aspace->i_mapping, index),
gfs2-02.patch-+ page);
gfs2-02.patch-+ } else {
gfs2-02.patch-+ page = find_lock_page(aspace->i_mapping, index);
gfs2-02.patch-+ if (!page)
gfs2-02.patch-+ return NULL;
I think you can set aspace->flags to GFP_NOFAIL but why can't you return
NULL here on failure like you do for find_lock_page()?
gfs2-02.patch:+ RETRY_MALLOC(bd = kmem_cache_alloc(gfs2_bufdata_cachep,
GFP_KERNEL),
gfs2-02.patch-+ bd);
gfs2-02.patch-+ gfs2_memory_add(bd);
gfs2-02.patch-+ atomic_inc(&gl->gl_sbd->sd_bufdata_count);
gfs2-02.patch-+
gfs2-02.patch-+ memset(bd, 0, sizeof(struct gfs2_bufdata));
-> GFP_NOFAIL
gfs2-08.patch:+ RETRY_MALLOC(gm = kmalloc(sizeof(struct gfs2_memory),
GFP_KERNEL), gm);
gfs2-08.patch-+ gm->gm_data = data;
gfs2-08.patch-+ gm->gm_file = file;
gfs2-08.patch-+ gm->gm_line = line;
gfs2-08.patch-+
gfs2-08.patch-+ spin_lock(&memory_lock);
-> GFP_NOFAIL
gfs2-10.patch:+ RETRY_MALLOC(new_gh = gfs2_holder_get(gl, state,
gfs2-10.patch-+ LM_FLAG_TRY |
gfs2-10.patch-+
GL_NEVER_RECURSE),
gfs2-10.patch-+ new_gh);
gfs2-10.patch-+ set_bit(HIF_DEMOTE, &new_gh->gh_iflags);
gfs2-10.patch-+ set_bit(HIF_DEALLOC, &new_gh->gh_iflags);
gfs2_holder_get uses kmalloc which can use GFP_NOFAIL.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |