On 07/11/2012 12:29 AM, Seth Jennings wrote:
> On 07/09/2012 09:21 PM, Minchan Kim wrote:
>> On 07/03/2012 06:15 AM, Seth Jennings wrote:
> <snip>
>>> +static void zs_copy_map_object(char *buf, struct page *firstpage,
>>> + int off, int size)
>>
>> firstpage is rather misleading.
>> As you know, we use firstpage term for real firstpage of zspage but
>> in case of zs_copy_map_object, it could be a middle page of zspage.
>> So I would like to use "page" instead of firstpage.
>
> Accepted.
>
>>> +{
>>> + struct page *pages[2];
>>> + int sizes[2];
>>> + void *addr;
>>> +
>>> + pages[0] = firstpage;
>>> + pages[1] = get_next_page(firstpage);
>>> + BUG_ON(!pages[1]);
>>> +
>>> + sizes[0] = PAGE_SIZE - off;
>>> + sizes[1] = size - sizes[0];
>>> +
>>> + /* disable page faults to match kmap_atomic() return conditions */
>>> + pagefault_disable();
>>
>> If I understand your intention correctly, you want to prevent calling
>> this function on non-atomic context. Right?
>
> This is moved to zs_map_object() in a later patch, but the
> point is to provide uniform return conditions, regardless of
> whether the object to be mapped is contained in a single
> page or spans two pages. kmap_atomic() disables page
> faults, so I did it here to create symmetry. The result is
The one I want to comment out is why we should disable page fault.
ie, if we don't disable page fault, what's happen?
As I read the comment of kmap_atomic about pagefault_disable,
it seems that for preventing reentrant bug in preemptive kernel
while it catch page fault during atomic context in non-preemptive kernel.
But I'm not sure so Ccing Peter.
> that zs_map_object always returns with preemption and page
> faults disabled.
>
> Also, Greg already merged these patches so I'll have to
> incorporate these changes as a separate patch.
>
> Thanks,
> Seth
>
--
Kind regards,
Minchan Kim
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
