Re: [LTP] [PATCH v4 2/3] mm/zram01: fix errno not captured

[Caspar Z. <ca...@ca...>]

On 11/16/2011 04:32 PM, Wanlong Gao wrote:
> On 11/16/2011 03:38 PM, Caspar Zhang wrote:
> 
>> On 11/16/2011 03:24 PM, Wanlong Gao wrote:
>>>>> I originally wanted to force-unload zram no matter it was already loaded
>>>>> before testing, because if not do so, next time testing will always
>>>>> fail. But I think it twice, you're right. We shouldn't change the module
>>>>> behavior after testing. The problem I concerned should be another issue
>>>>> I should fix. I will update the patch again. Sorry for flooding mail
>>>>> today for this _staging_ driver...
>>>
>>> Hmmm..., if the module is loaded before testing, you can *rmmod*
>>> in the test, and then restore the status when doing cleanup. Right?
>>
>> yes, and zram has a 'reset' mechanism to finish similar thing. but seems
>> that reset doesn't work in my test program... So I think I'd better find
>> why reset not working instead of using rmmod to hide it :)
> 
> 
> Sure. I see that if we write 512m to *disksize*, it will sometimes not be
> 512M, so, IMO, we must re-read from *disksize* after write 512M to it.
> and instead of using *SIZE* in *mmap* and *memset*. It's should be the issue.

I hardly think so... After some experiments, I guess the problem should
be that reset happened right before /dev/zram0 I/O operation started to
execute. So that the following scenario would happen:

- command: cat somefile > /dev/zram0 or mmap /dev/zram0 to memory
- I/O is just about to start
- echo 1 > /sys/block/zram0/reset got executed -> blocksize == 0
- I/O start -> blocksize == 0 -> blocksize set to 25% of phy mem
- I/O finish -> blocksize remains non-zero
- 2nd time test -> blocksize non-zero, returning EBUSY (that's what we saw)

Since writing to /dev/zram0 operation is async from echoing values to
/sys/block/zram0/*, I think it is difficult to lock the whole I/O from
the beginning, that is to say, this will always happen, if we do reset
immediately after executing I/O op. So we need to modify the case, e.g.
sleep sometime between I/O op & reset op. Thoughts?

Thanks,
Caspar