Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1454825ybl; Thu, 5 Dec 2019 01:32:11 -0800 (PST) X-Google-Smtp-Source: APXvYqw0htM/HOkiroXpGUFocQLlPusiY6AcrzK1OO3MuZCJ8KCR6oEck5AZe7WeNf/M49mPXfwt X-Received: by 2002:a05:6830:22ee:: with SMTP id t14mr5612223otc.236.1575538331850; Thu, 05 Dec 2019 01:32:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575538331; cv=none; d=google.com; s=arc-20160816; b=QatDHSoUbrn1f4mUch72qTOutRR1kzvGAOQTTNj3uZOO9fdlrwWnu9RE0S6WUxMZnB BhEcm/pbdulzqf2oY0JInbc6Zll0Y+vdzViXBz2rdASByUfblqPq6B+hQCt+8EZ0E+jy 8n8Hjm5lr3+XxLdMZkEJsCwKk3+t+g14shQcuchspn/lSJ4muITUrViU3qFkZyVkDMws sXM14dMF3wRDuu6tpyh3ZXTdu06fsq8hBf+AAAJu1CmE6Tu7zLnKcFNB/S8BxaHNGQBU ghwU44ASG/JNhqxd2JrlRwQDbvi3THgebRqp0QMU9dA460+FfTzrIr0wRTtJkjXn6vHh P4TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=aHb1VO0xR+IPYYvVFCIzNRZ9emff31Jj/WMc/RTpBkM=; b=iwiabbKiz82Y4SQ+pjTy7epKjLb2FNjEYNR/d6AOODLY5XtMRTniatE/qI7wALs9Wr OUfCxuQvaJritHC5HFzeFFa8g7DM8rkgDlky1B60OH0GD1CRc4OoKfRlScBmMQnTiiBE Y6lK4C+LWox+6li+kOFQ59B/mwf9KLxuiyfpPBirL34HQhZeKzyS9Av0cY/GOjoFpzFW 5PtdeGsONYufyEB/Uys0DgwjqAfBr9LLOdjRvFGpIagXq7mswlUxD7aZ+aMZ65WZSMGa qwyk6HGZ+rI/Vo4iH5zehyHijwZFQsCv2TMaHSMLZfb0kKTTg5c/vvzADZH71HdaMcx2 jTgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=GdP1Dayr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j13si4714963otq.146.2019.12.05.01.31.59; Thu, 05 Dec 2019 01:32:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=GdP1Dayr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728991AbfLEJbd (ORCPT + 99 others); Thu, 5 Dec 2019 04:31:33 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:40433 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbfLEJbc (ORCPT ); Thu, 5 Dec 2019 04:31:32 -0500 Received: by mail-ot1-f68.google.com with SMTP id i15so2000147oto.7 for ; Thu, 05 Dec 2019 01:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aHb1VO0xR+IPYYvVFCIzNRZ9emff31Jj/WMc/RTpBkM=; b=GdP1Dayrp1byZDNq+kDIEblYRD+qV/omiAYqmUcsazuy2zrOpTmK7+HcD2PMqTEB+Q vOjQ1QisF0vLwIIaKBQ0HMJzt1YVjvUNF9a2FedoljZGIrkdxC6srjB2aQ+vivJktyfK c8osz+HLeJs4OXv8IlknXvbGguyE7Risz/VDmUGe5cqgYGRlUMDmMLIIBW8WUunpnZHC eizhEpchE/6f+E9dMdaeSlsJV5F0E181kpJkyXk+nOGjFyOcNdtWvkuUNylHP9FfJqo2 4rACwT82dEONNo7Pv9gQ0IL1Vk8OeOa+2nEulr13vDC8vuDBuAwEsF5Z2Gg9ndN5nHK8 xH2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aHb1VO0xR+IPYYvVFCIzNRZ9emff31Jj/WMc/RTpBkM=; b=WjAGzuwcXcsqGySRe6dfy2xeqUJ9Fpyb2QXZxdmoIRrFYcSWx1DkD3ZRyhmloCKtNE feY48LrsXpUcyqWed/vINnl6Sso9dg8Jms4CnBPMfYu2xpWHzbMAn+xJFSF+LATYInFy AYRTc14vczUCZo6q4e+i2DLi0F5xVaOmEfnLCIWhVwZ3Hmxm1lOoHrCmZ0kouGqDFUaT T9cr+ghYltsAxYrOaTw+BusOJgVFdTxzFXaCFSrDvKsYQwU1/Uq2qOjaDaFKaWh0owqG oGL53wvWavLsXErxcJ8Ltu5Fz0+m8XDJJMCU5LTDvkCPDo8EaMkv2d9Xm4o47EIAuUNe bcjw== X-Gm-Message-State: APjAAAU3ksKH2VAPs1fMGX6tC2CbrHfbPohebLINBOVZTaDSNUrphPWz oQtGmshHWgnnOBPiFnWBnKMzWAhSNwLMUYXbEsQJpg== X-Received: by 2002:a9d:27c4:: with SMTP id c62mr6001704otb.292.1575538291595; Thu, 05 Dec 2019 01:31:31 -0800 (PST) MIME-Version: 1.0 References: <20191204155912.17590-1-brgl@bgdev.pl> <20191204155912.17590-8-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Thu, 5 Dec 2019 10:31:20 +0100 Message-ID: Subject: Re: [PATCH v2 07/11] gpiolib: rework the locking mechanism for lineevent kfifo To: Andy Shevchenko Cc: Bartosz Golaszewski , Kent Gibson , Linus Walleij , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =C5=9Br., 4 gru 2019 o 23:25 Andy Shevchenko na= pisa=C5=82(a): > > On Wed, Dec 4, 2019 at 6:01 PM Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski > > > > The read_lock mutex is supposed to prevent collisions between reading > > and writing to the line event kfifo but it's actually only taken when > > the events are being read from it. > > > > Drop the mutex entirely and reuse the spinlock made available to us in > > the waitqueue struct. Take the lock whenever the fifo is modified or > > inspected. Drop the call to kfifo_to_user() and instead first extract > > the new element from kfifo when the lock is taken and only then pass > > it on to the user after the spinlock is released. > > > > My comments below. > > > + spin_lock(&le->wait.lock); > > if (!kfifo_is_empty(&le->events)) > > events =3D EPOLLIN | EPOLLRDNORM; > > + spin_unlock(&le->wait.lock); > > Sound like a candidate to have kfifo_is_empty_spinlocked(). Yeah, I noticed but I thought I'd just add it later separately - it's always easier to merge self-contained series. > > > > struct lineevent_state *le =3D filep->private_data; > > - unsigned int copied; > > + struct gpioevent_data event; > > int ret; > > > + if (count < sizeof(event)) > > return -EINVAL; > > This still has an issue with compatible syscalls. See patch I have > sent recently. > I dunno how you see is the better way: a) apply mine and rebase your > series, or b) otherwise. > I can do b) if you think it shouldn't be backported. > Looking at your patch it seems to me it's best to rebase yours on top of this one - where I simply do copy_to_user() we can add a special case for 32-bit user-space. I can try to do this myself for v3 if you agree. Bart > Btw, either way we have a benifits for the following one (I see you > drop kfifo_to_user() and add event variable on stack). > > > + return sizeof(event); > > Also see comments in my patch regarding the event handling. > > -- > With Best Regards, > Andy Shevchenko