Hi,
> Unless you can measure the performance difference, do not use a rw
> semaphore, just use a normal mutex please. Odds are it will be faster
> in the end and take up less space.
>
> So please test, or if you can't test, just use a mutex.
I don't have the device yet, so I won't be able to te
On Fri, Jun 01, 2018 at 08:50:37AM -0400, Hugo Lefeuvre wrote:
> Add a rw semaphore fixing potential NULL pointer dereferences in the
> pi433 driver.
Unless you can measure the performance difference, do not use a rw
semaphore, just use a normal mutex please. Odds are it will be faster
in the end
Hi Valdis,
> > @@ -805,9 +809,11 @@ pi433_read(struct file *filp, char __user *buf, size_t
> > size, loff_t *f_pos)
> > if (bytes_received > 0) {
> > retval = copy_to_user(buf, device->rx_buffer, bytes_received);
> > if (retval)
> > + up_read(&instanc
On Fri, 01 Jun 2018 08:50:37 -0400, Hugo Lefeuvre said:
> @@ -805,9 +809,11 @@ pi433_read(struct file *filp, char __user *buf, size_t
> size, loff_t *f_pos)
> if (bytes_received > 0) {
> retval = copy_to_user(buf, device->rx_buffer, bytes_received);
> if (retval)
Add a rw semaphore fixing potential NULL pointer dereferences in the
pi433 driver.
If pi433_release and pi433_ioctl are concurrently called,
pi433_release might set filp->private_data to NULL while pi433_ioctl
is still accessing it, leading to NULL pointer dereference. This issue
might also affect
