[CRIU] [PATCH 0/3] fsnotify: Bring back "ignore queues" mode

Pavel Emelyanov xemul at parallels.com
Wed Sep 3 11:35:02 PDT 2014


On 09/03/2014 10:31 PM, Cyrill Gorcunov wrote:
> On Wed, Sep 03, 2014 at 10:29:44PM +0400, Pavel Emelyanov wrote:
>> On 09/03/2014 10:22 PM, Cyrill Gorcunov wrote:
>>> On Wed, Sep 03, 2014 at 10:15:04PM +0400, Pavel Emelyanov wrote:
>>>> On 09/03/2014 10:06 PM, Cyrill Gorcunov wrote:
>>>>> Let a user to deside which mode to work with -- refuse to proceed
>>>>> if there is queued fsnotify data, or pass ignoring them. By default
>>>>> ignore them as we were since first fsnotify implementation.
>>>>
>>>> NAK. We did it wrong, now we've fixed it. And test fails simply
>>>> because _it_ generates the events. Just flush the events in the
>>>> test.
>>>
>>> Sigh. Look, the problem is more deeper. Have someone tested new model
>>> with real lcx/docker container? I like the idea to refuse dumping until
>>> queue is empty but otoh I believe we should give users an option to
>>> disable such behaviour. What if there will be some fanotify over
>>> root partition with generates events again and again, does it mean
>>> we should simply not be able to dump such application?
>>
>> Agree. But neither it means we should just drop the events from
>> the queue. Let's fix the test and see (till 1.4) whether we need
>> to add an option to ignore them.
> 
> Lets do another deal -- by default enable strict mode, where we require
> queue to be empty, for inotify00 test itself we enable relaxed mode,
> because the test watches '/' dentry and even if I drop all events the
> kernel generates new ones when I write image files ;)

Stop watching the "/" dentry in the test ;)



More information about the CRIU mailing list