Re: [PATCH] mm/readahead.c: need always return 0 when system call readahead() succeeds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]