UBI: Can we handle -EINTR differently in erase/write path???

[Vinit Agnihotri]

Ok the scenario is like this.
1. User created a volume
2. User issues raw writes on device by using "dd"
3.UBI do not find any preerased block & so it tries to erase 1 block
synchronously
4.When sync_erase is invoked... it waits in wait_event_interruptible()
5. At this moment if user presses ctrl+c & wait_event_interruptible()
return -EINTR
6. On error erase_worker() will mark ubi in Read-only mode.

Soo we need to handle -EINTR differently, as I've faced this situation :)

Thanks & Regards
Vinit.


/13/07, Josh Boyer <jwboyer at linux.vnet.ibm.com> wrote:
> On Fri, 2007-07-13 at 11:37 +0530, Vinit Agnihotri wrote:
> > Hi heres few code snip from erase_worker(); from wl.c
> > if (err != -EIO) {
> >         /*
> >          * If this is not %-EIO, we have no idea what to do. Scheduling
> >          * this physical eraseblock for erasure again would cause
> >          * errors again and again. Well, lets switch to RO mode.
> >          */
> >         ubi_ro_mode(ubi);
> >         return err;
> >     }
> >
> > Suppose while erasure in progress & someone pressed "Ctrl+C" then UBI
>
> This is the kernel...  the erase_worker function is called from a kernel
> thread that doesn't allow signals.  How would it get a "Ctrl+C" event?
>
> > This is my initial understanding about handling -EINTR, however I
> > would like to know views of others. If all agrees I can post patch for
> > same.
>
> That is how you handle the EINTR errno in userspace.  I think you'd need
> to show how -EINTR could show up in this code path in the kernel before
> worrying about how to handle it.
>
> josh
>
>


-- 
I feel free now