Re: [libgpiod] gpiod_line_get_value_bulk may be broken?

[Kent Gibson <warthog618@gmail.com>]

On Thu, Aug 10, 2023 at 01:17:13AM +0100, andy pugh wrote:
> On Sun, 6 Aug 2023 at 10:29, Kent Gibson <warthog618@gmail.com> wrote:
> 
> > You can't statically link libgpiod until it is available as a package?
> 
> Would that mean merging the gpiod code into our codebase? Or can this
> be done some other way?
> 

There is no code movement at all, this is just telling the linker to
link libgpiod.a directly into your executable, rather than dynamically
linking against libgpiod.so.

The specifics of how to do that depend on your build.

Later, when libgpiod v2 becomes more widely available, you can switch
the build back to dynamic linkage.

> 
> Anyway, I now have it working, to an extent, but feel that there might
> be a problem with gpiod_line_request_bulk_input() and
> gpiod_line_request_bulk_output() if the bulk contains more than 5
> lines.
> 
> My current code is here (Work in progress!)
> 
> https://github.com/LinuxCNC/linuxcnc/blob/andypugh/hal_gpio/src/hal/drivers/hal_gpio.c
> 
> The test input file (
> https://github.com/LinuxCNC/linuxcnc/blob/andypugh/hal_gpio/src/test.hal
> ) attempts to configure 8 input and 8 output lines.
> However, if I change the 5 to 6 in either of lines 157 or 180 then the
> output looks something like:
> 
> HAL: initializing hal_lib
> /home/andypugh/linuxcnc-dev/bin/rtapi_app load hal_gpio
> inputs=GPIO5,GPIO6,GPIO12,GPIO13,GPIO16,GPIO17,GPIO18,GPIO19
> outputs=GPIO20,GPIO21,GPIO22,GPIO23,GPIO24,GPIO25,GPIO26,GPIO27
> HAL: initializing component 'halcmd9608'
> smalloc_dn: shmem available 1048284
> HAL: component 'halcmd9608' initialized, ID = 02
> Note: Using POSIX realtime
> before request
> rtapi_app: caught signal 11 - dumping core
> 
> The "before request" line was added for debugging, the "after request"
> line is never printed, nor is the error message if the request fails,
> so my belief is that lines 163 and/or 185 are segfaulting in the
> bulk_request functions.
> 
> The driver appears to work fine if I limit the number of parsed input
> strings to 5.

Check the sizes of the memory you are allocating.
e.g. this:

	    arr[c].chip = (struct gpiod_chip *)rtapi_kmalloc(sizeof(arr[c].chip), RTAPI_GFP_KERNEL);

allocates the space for a pointer to a struct, not the struct itself.
So you are corrupting your heap.

Try
	    arr[c].chip = (struct gpiod_chip *)rtapi_kmalloc(sizeof(*arr[c].chip), RTAPI_GFP_KERNEL);

Similarly your other mallocs.

Btw, v2 uses opaque structs so this wouldn't be an issue - it would do
the allocating for you, e.g. gpiod_chip_open() allocates and returns the
pointer to the struct gpiod_chip.

Cheers,
Kent.