All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Mel Gorman <mgorman@suse.de>,
	sasha.levin@oracle.com, linux@rasmusvillemoes.dk,
	kosaki.motohiro@jp.fujitsu.com,
	Wu Fengguang <fengguang.wu@intel.com>,
	lczerner@redhat.com, linux-mm@kvack.org
Subject: Re: [PATCH] mm/readahead.c: need always return 0 when system call readahead() succeeds
Date: Thu, 17 Oct 2013 09:32:41 +0800	[thread overview]
Message-ID: <525F3E39.3060603@asianux.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1310161812480.12062@chino.kir.corp.google.com>

On 10/17/2013 09:17 AM, David Rientjes wrote:
> On Thu, 17 Oct 2013, Chen Gang wrote:
> 
>> If possible, you can help me check all my patches again (at least, it is
>> not a bad idea to me).  ;-)
>>
> 
> I think your patches should be acked before being merged into linux-next, 
> Hugh just had to revert another one that did affect Linus's tree in 
> 1ecfd533f4c5 ("mm/mremap.c: call pud_free() after fail calling
> pmd_alloc()").  I had to revert your entire series of mpol_to_str() 
> changes in -mm.  It's getting ridiculous and a waste of other people's 
> time.
> 

If always get no reply, what to do, next?

In fact, in the whole kernel wide, at least, I have almost 10 patches
pending at least 2-3 weeks which got no reply (neither say ack, nor
nack), is it necessary to list them in this mail thread. ;-)

But all together, I welcome you to help ack/nack my patches for mm
sub-system (although I don't know your ack/nack whether have effect or not).

:-)

>>> Nack to this and nack to the problem patch, which is absolutely pointless 
>>> and did nothing but introduce this error.  readahead() is supposed to 
>>> return 0, -EINVAL, or -EBADF and your original patch broke it.  That's 
>>> because your original patch was completely pointless to begin with.
>>>
>>
>> Do you mean: in do_readahead(), we need not check the return value of
>> force_page_cache_readahead()?
>>
> 
> I'm saying we should revert 
> mm-readaheadc-return-the-value-which-force_page_cache_readahead-returns.patch 
> which violates the API of a syscall.  I see that patch has since been 
> removed from -mm, so I'm happy with the result.
> 
> 

Excuse me, I am not quite familiar with the upstream kernel version
trees merging.

Hmm... I think the final result need be: "still need check the return
value of force_patch_cache_readahead(), but need return 0 in readahead()
and madvise_willneed()".

Do you also think so, or do you happy with this result?


Thanks.
-- 
Chen Gang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-10-17  1:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  3:31 [PATCH] mm: readahead: return the value which force_page_cache_readahead() returns Chen Gang
2013-08-20 23:16 ` Andrew Morton
2013-08-21  2:29   ` Chen Gang
2013-08-21  2:41   ` [PATCH v2] m: " Chen Gang
2013-09-03  5:27     ` Chen Gang
2013-09-17 22:56     ` Andrew Morton
2013-09-18  1:59       ` Chen Gang
2013-10-15  8:06         ` [PATCH] mm/readahead.c: need always return 0 when system call readahead() succeeds Chen Gang
2013-10-15 12:12           ` [PATCH] mm/madvise.c: return 0 instead of read bytes after force_page_cache_readahead() succeeds Chen Gang
2013-10-16 23:06           ` [PATCH] mm/readahead.c: need always return 0 when system call readahead() succeeds David Rientjes
2013-10-17  0:57             ` Chen Gang
2013-10-17  1:17               ` David Rientjes
2013-10-17  1:32                 ` Chen Gang [this message]
2013-10-17  2:21                   ` David Rientjes
2013-10-17  2:37                     ` Chen Gang
2013-10-17  2:40                       ` Chen Gang
2013-10-15  8:20     ` [PATCH v2] m: readahead: return the value which force_page_cache_readahead() returns Chen Gang
2013-10-17  9:56       ` Chen Gang
2013-11-04  5:31         ` [PATCH v3] mm: readahead: check return " Chen Gang

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=525F3E39.3060603@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lczerner@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mgorman@suse.de \
    --cc=rientjes@google.com \
    --cc=sasha.levin@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.