Hi. On Thu, 2005-04-07 at 22:29, Rafael J. Wysocki wrote: > I am confused now. AFAICS, we don't check anywhere if a process we > are going to freeze holds any locks. If we have a task in > TASK_INTERRUPTIBLE, we just send it a fake signal which causes it to go > to the refrigerator(). Could you please tell me how we prevent such a task > from holding any locks? [It probably doesn't matter, at least practically, > but ...? :-)] Checking that no locks aren't held is impossible at the moment afaik. There's no 'I'm holding n locks counter'. And even if there were, if you get rid of the refrigerator, you still can't guarantee that you won't deadlock against processes grabbing locks after your atomic copy. Dropping the freezer also means you're forever limiting suspend to writing a maximum of one half of memory - unless you're going to do non-atomic images. > > OTOH... we may want to move completely away from refrigerator. Its > > quite a hack, and it device support is okay, we'll not really need it. > > Still, it won't happen soon, I guess. :-) As of today, we have the > refrigerator and the processes in TASK_UNINTERRUPTIBLE are mishandled. > I think we should do something about it, at least for now, until we drop > the refrigerator altogether (if we are going to drop it). That's why I > started the discussion and sent the patch. I believe dropping the refrigerator is a fundamentally broken idea. You have to (at least) stop processes doing disk I/O (otherwise the snapshot you just took won't match the on-disk state). At the same time, though, you still need I/O to work for your suspend implementation. You're then talking about putting nous in the drivers which says "Hold this I/O, it's not suspend but process this - it's suspend." Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net
