From patchwork Fri Sep 4 05:37:23 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Torokhov X-Patchwork-Id: 7120021 Return-Path: X-Original-To: patchwork-linux-input@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B11A59F1D5 for ; Fri, 4 Sep 2015 05:37:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A4C6C20837 for ; Fri, 4 Sep 2015 05:37:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 984E420831 for ; Fri, 4 Sep 2015 05:37:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755063AbbIDFh1 (ORCPT ); Fri, 4 Sep 2015 01:37:27 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:36067 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754662AbbIDFh0 (ORCPT ); Fri, 4 Sep 2015 01:37:26 -0400 Received: by pacwi10 with SMTP id wi10so13463921pac.3 for ; Thu, 03 Sep 2015 22:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6B5UJ8D4PLxBOqw8lCoOwSR3vDGa04o8BblIWM1Uv9Y=; b=Q+rc0XxZ/bemSoN+t8ketUrVDwxVB1O+51MkzYojsK7qgrK4MkxQrN8wPxDzaGyZ8w fkm49oTkYlk5gNFS1MaSjRnKtHnXPDpQfLYgp6PKo5gH1mbDf/MrBD+f3RWo7Ci0Lme+ TVmqncPu9S32zGcpM8emqOafM3UhcM+NYWHfu51tfhZhEL+TUzlE08SNRVIbfOW2PaEX 7n8AcgMwUYyAx05AFma4lhdEPYR3aJFxffk703izbfaEnWdQ67O+yYPoMt4CM2Arfhgl GX/fCc6CBg57A/3W9egcZznbpnK9P1PsiPo7c9ys3NP8yNb7JSiuAv5Iq8uAkZQZjla4 E68Q== X-Received: by 10.66.227.2 with SMTP id rw2mr4320917pac.98.1441345046057; Thu, 03 Sep 2015 22:37:26 -0700 (PDT) Received: from dtor-ws ([2620:0:1000:1301:2178:fa68:3028:3596]) by smtp.gmail.com with ESMTPSA id k10sm970183pbq.63.2015.09.03.22.37.24 (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Thu, 03 Sep 2015 22:37:25 -0700 (PDT) Date: Thu, 3 Sep 2015 22:37:23 -0700 From: Dmitry Torokhov To: Takashi Iwai Cc: Al Viro , linux-input@vger.kernel.org Subject: Re: [PATCH] Input: evdev - Use EBADFD for flush() errors Message-ID: <20150904053723.GB22340@dtor-ws> References: <1439969895-26163-1-git-send-email-tiwai@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Takashi, On Tue, Sep 01, 2015 at 07:23:25AM +0200, Takashi Iwai wrote: > On Wed, 19 Aug 2015 09:38:15 +0200, > Takashi Iwai wrote: > > > > We've got bug reports showing the old systemd-logind (at least > > system-210) aborting unexpectedly, and this turned out to be because > > of an invalid error code from close() call to evdev devices. close() > > is supposed to return only either EINTR or EBADFD, while the device > > returned ENODEV. logind was overreacting to it and decided to kill > > itself when an unexpected error code was received. What a tragedy. > > > > The bad error code comes from flush fops, and actually evdev_flush() > > returns -ENODEV and else. This patch papers over it, simply fixing > > the error return code to the acceptable values above. > > > > Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834 > > Cc: > > Signed-off-by: Takashi Iwai > > Hi, > > any comments on this patch? > As we have discussed previously returning EBADF will not actually help failing versions of systemd because they were not expecting getting any errors from close(). Considering the code and close() behavior I think the best way would be to stop reporting any errors from evdev_flush(), like in the version of the patch below. Please let me know if you are OK with this and I'll apply it. Thanks! diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index 9d35499..08d4964 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -290,19 +290,14 @@ static int evdev_flush(struct file *file, fl_owner_t id) { struct evdev_client *client = file->private_data; struct evdev *evdev = client->evdev; - int retval; - retval = mutex_lock_interruptible(&evdev->mutex); - if (retval) - return retval; + mutex_lock(&evdev->mutex); - if (!evdev->exist || client->revoked) - retval = -ENODEV; - else - retval = input_flush_device(&evdev->handle, file); + if (evdev->exist && !client->revoked) + input_flush_device(&evdev->handle, file); mutex_unlock(&evdev->mutex); - return retval; + return 0; } static void evdev_free(struct device *dev)