linux-kernel - Re: [PATCH v4 09/20] gpiolib: cdev: support edge detection for uAPI v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200818140002.GA17809@sol>
Date:   Tue, 18 Aug 2020 22:00:02 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v4 09/20] gpiolib: cdev: support edge detection for uAPI
 v2

On Sun, Aug 16, 2020 at 04:32:34PM +0200, Bartosz Golaszewski wrote:
> On Fri, Aug 14, 2020 at 5:04 AM Kent Gibson <warthog618@...il.com> wrote:
> >
> > Add support for edge detection to lines requested using
> > GPIO_V2_GET_LINE_IOCTL.
> >
[snip]

> >
> > +       /* event_buffer_size only valid with edge detection */
> > +       has_edge_detection = gpio_v2_line_config_has_edge_detection(lc);
> > +       if (lr.event_buffer_size && !has_edge_detection)
> > +               return -EINVAL;
> > +
> >         line = kzalloc(struct_size(line, descs, lr.num_lines),
> >                        GFP_KERNEL);
> >         if (!line)
> > @@ -666,6 +944,16 @@ static int line_create(struct gpio_device *gdev, void __user *ip)
> >         line->gdev = gdev;
> >         get_device(&gdev->dev);
> >
> > +       line->edets = kcalloc(lr.num_lines, sizeof(*line->edets),
> > +                             GFP_KERNEL);
> 
> You're allocating num_lines of edge detectors even if only certain
> lines have edge detection (via attributes). I don't like it but it
> made me think about struct line. How about having struct line which
> actually only represents a single line (and it contains the relevant
> gpio_desc pointer as well as the associated edge detector and any
> other data only relevant for this line) and a set of lines would be
> aggregated in struct line_request or line_request_data which would
> additionally contain common fields? Does that even make sense?
> 

You are right, and it makes total sense.

I'm not totally thrilled with the block allocation either, but an
earlier draft with edge detectors/debouncers created and destroyed as
required resulted in complicated lifecycle management that this approach
avoids.

I'll have a look at restructuring it as you suggest.
The only downside that springs to mind is that the gpiolib API expects
a desc array, which we'll no longer have handy, so it would have to be
built on the fly as per the sparse gets/sets.

Cheers,
Kent.