On Tuesday, November 12, 2013 11:24:05 AM John Stultz wrote: > On Mon, Nov 11, 2013 at 1:22 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > On Monday, November 11, 2013 11:26:31 PM Amit Pundir wrote: > >> While looking into the problem, I found that ep_create_wakeup_source() > >> reports ENOMEM if wakeup_source_register() returns NULL. > >> ep_create_wakeup_source() assumes that NULL is only returned if we run > >> into ENOMEM but NULL is also returned when CONFIG_PM_SLEEP is disabled. > > > > So the error value should not be ENOMEM. > > Right, ENOMEM is clearly wrong. I think its just not clear what the > right thing to do is. > > > >> If CONFIG_PM_SLEEP is disabled, stripping the EPOLLWAKEUP flag seems to > >> be a reasonable solution here, allowing the call to succeed, while > >> dropping the wakeup logic. While returning EINVAL might also be a good > >> solution, stripping the flag seems to follow the established behavior, > >> as is done when the process doesn't have sufficient capabilities to > >> block suspend. > > > > Which is a different thing. > > Well, in the case of the process not having sufficient capabilities, > -EPERM seems like a reasonable return value. But instead the wakeup > flag is silently dropped. That's why Amit is asking if dropping the > wakeup flag is also the right approach for the !PM_SLEEP case instead > of returning EINVAL. > > Dropping the wakeup flag is the easier solution, since we don't have > to then go through all the userspace code and have it handle the error > and resubmit without the wakeup flag. I suspect this was the same > consideration for the decision in the insufficient capabilities case, > but I don't really know. Yes, it was. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
