Re: [PATCH] staging/android: use multiple futex wait queues

ards, Hugo [0] https://lore.kernel.org/patchwork/patch/1039712/ -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C ___ de

Re: [PATCH] staging/android: use multiple futex wait queues

2. Thanks for the feedback! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C ___ devel mailing list de...@linuxdriverproject

[PATCH v2] staging/android: use multiple futex wait queues

Use multiple per-offset wait queues instead of one big wait queue per region. Signed-off-by: Hugo Lefeuvre --- Changes in v2: - dereference the it pointer instead of wait_queue (which is not set yet) in handle_vsoc_cond_wait() --- drivers/staging/android/TODO | 4 --- drivers/staging

Re: [PATCH] staging/android: use multiple futex wait queues

> > Use multiple per-offset wait queues instead of one big wait queue per > > region. > > > > Signed-off-by: Hugo Lefeuvre > > Have you tested this? > > Noticed any performance speedups or slow downs? Not yet. I have started to set up a cuttlefish test env

[PATCH] staging/android: use multiple futex wait queues

Use multiple per-offset wait queues instead of one big wait queue per region. Signed-off-by: Hugo Lefeuvre --- This patch is based on the simplify handle_vsoc_cond_wait patchset, currently under review: https://lkml.org/lkml/2019/2/7/870 --- drivers/staging/android/TODO | 4 --- drivers

Re: [PATCH 1/3] sched/wait: use freezable_schedule when possible

ael (power maintainer) on it. Thanks, I have splitted the patch set[0][1] and submitted the freezable_schedule patch separately (only cc-ing people responsible for the wait api + Rafael). regards, Hugo [0] https://lkml.org/lkml/2019/2/7/802 [1] https://lkml.org/lkml/2019/2/7/870 --

[PATCH v2 2/2] staging/android: simplify handle_vsoc_cond_wait

simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly added wait_event_freezable_hrtimeout helper and remove duplicate include. Signed-off-by: Hugo Lefeuvre --- Changes in v2: - Fix removal of necessary linux/freezer.h include. - Make commit message more precise about

[PATCH v2 1/2] sched/wait: introduce wait_event_freezable_hrtimeout

introduce wait_event_freezable_hrtimeout, an interruptible and freezable version of wait_event_hrtimeout. This helper will allow for simplifications in staging/android/vsoc.c, among others. Signed-off-by: Hugo Lefeuvre --- Changes in v2: - No change. include/linux/wait.h | 25

[PATCH v2 0/2] sched/wait, staging/android: simplification of freeze related code

: use freezable_schedule when possible", it was submitted separately. - Patch 3/3 (now 2/2): Fix removal of a necessary linux/freezer.h include and improve commit message. [1] v1: https://lkml.org/lkml/2019/2/1/19 Hugo Lefeuvre (2): sched/wait: introduce wait_event_freezable_hrtimeout

Re: [PATCH 1/3] sched/wait: use freezable_schedule when possible

quot; lines in kern.log. Results: Without my patch: 448 calls freeze_task, 12 skipped. With my patch: 448 calls, 32 skipped. 2.6x more tasks skipped. Not sure this is the best way to test this patch, though. Any advice? regards, Hugo -- Hugo Lefeuvre (hle)|www.owl

Re: [PATCH 1/3] sched/wait: use freezable_schedule when possible

patch removes a necessary #include . I will submit an updated version tomorrow. Thanks for the review! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36

Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

egards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature ___ devel mailing l

[PATCH 3/3] staging/android: simplify handle_vsoc_cond_wait

simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly added wait_event_freezable_hrtimeout helper and remove useless includes. Signed-off-by: Hugo Lefeuvre --- drivers/staging/android/vsoc.c | 69 +- 1 file changed, 10 insertions(+), 59

[PATCH 1/3] sched/wait: use freezable_schedule when possible

try_to_freeze() when they wake up if the freeze is still underway. It is not a problem since sleeping tasks can't do anything which isn't allowed for a frozen task while sleeping. The result is a potential performance gain during freeze, since less tasks have to be awaken. Signed-of

[PATCH 2/3] sched/wait: introduce wait_event_freezable_hrtimeout

introduce wait_event_freezable_hrtimeout, an interruptible and freezable version of wait_event_hrtimeout. Among others this helper will allow for simplifications in staging/android/vsoc.c. Signed-off-by: Hugo Lefeuvre --- include/linux/wait.h | 25 + 1 file changed, 21

[PATCH 0/3] sched/wait, staging/android: simplification and optimization of freeze related code

[0] https://lkml.org/lkml/2019/1/17/877 [1] https://lkml.org/lkml/2019/1/19/58 Hugo Lefeuvre (3): sched/wait: use freezable_schedule when possible sched/wait: introduce wait_event_freezable_hrtimeout staging/android: simplify handle_vsoc_cond_wait drivers/staging/android/v

Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

anks for your time ! regards, Hugo [0] https://elixir.bootlin.com/linux/latest/source/include/linux/freezer.h#L103 [1] https://elixir.bootlin.com/linux/latest/source/Documentation/power/freezing-of-tasks.txt#L90 [2] https://elixir.bootlin.com/linux/latest/source/kernel/kthread.c#L569 --

Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

dule() avoids blocking the freezer during the schedule() call, but in the end try_to_freeze() is still called so the result is the same, right? I wonder why wait_event_freezable is not calling freezable_schedule(). That being said, I am not sure that the try_to_freeze() call does anything in

Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

Hi Greg, > > introduce wait_event_freezable_hrtimeout, an interruptible and freezable > > version of wait_event_hrtimeout. > > > > simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this > > newly added helper and remove useless includes. > &g

[PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

introduce wait_event_freezable_hrtimeout, an interruptible and freezable version of wait_event_hrtimeout. simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this newly added helper and remove useless includes. Signed-off-by: Hugo Lefeuvre --- drivers/staging/android/vsoc.c

Re: staging/android: questions regarding TODO entries

> It should probably say "address." Thanks. I'm working on a few patches for staging/android, this issue will be addressed as well. regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed255

staging/android: questions regarding TODO entries

. So, once VSOC_SELF_INTERRUPT has been executed once, VSOC_WAIT_FOR_INCOMING_INTERRUPT doesn't work anymore ? Thanks for your work ! cheers, Hugo PS: cc-ing the result of get_maintainer.pl + contacts from todo. Please tell me if this is not the right way to go. -- Hug

pi433: initialization of tx config in pi433_open()

he default values of the rf69 datasheet[0] ? Also, is there a specific reason why you chose 4711 as a default value for the bit rate ? I couldn't find it anywhere in the datasheet nor on the internet. Thanks ! Regards, Hugo [0] http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf --

Re: rf69_set_deviation in rf69.c (pi433 driver)

r going for the first one, but I wanted to have your opinion > > on this. > > Agree. I'll prepare a patch addressing both issues. However I don't own test devices so it would be really great if you could test it ! I'm currently thinking of adapting this driver for ot

Re: [PATCH v2] staging: pi433: fix race condition in pi433_open

On Wed, Jun 20, 2018 at 11:34:39AM +0300, Dan Carpenter wrote: > On Tue, Jun 19, 2018 at 10:33:26PM -0400, Hugo Lefeuvre wrote: > > @@ -1178,6 +1152,11 @@ static int pi433_probe(struct spi_device *spi) > > device->tx_active = false; > > device->i

[PATCH v3] staging: pi433: fix race condition in pi433_open

counter and move rx buffer {de,}allocation to probe() and remove(). Remove associated dead code from open() and release(). Remove related TODO entry from ioctl(). Signed-off-by: Hugo Lefeuvre --- Changes in v3: - add missing free call in probe() (in case of failure during memory allocation

[PATCH v2] staging: pi433: fix race condition in pi433_open

counter and move rx buffer {de,}allocation to probe() and remove(). Remove associated dead code from open() and release(). Remove related TODO entry from ioctl(). Signed-off-by: Hugo Lefeuvre --- Changes in v2: - Remove useless users counter. - Remove unneeded TODO entry in ioctl

Re: [PATCH] staging: pi433: fix race condition in pi433_open

; > > 1296 /* make sure ops on existing fds can abort cleanly */ > > 1297 device->spi = NULL; > > That's when we're unloading the module so there aren't any users left. I'll submit an updated version of my patch getting rid of the counter and addressin

Re: [PATCH] staging: pi433: fix race condition in pi433_open

t remove() was already called and free remaining resources: 1296 /* make sure ops on existing fds can abort cleanly */ 1297 device->spi = NULL; Thanks for your time ! Regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0

[PATCH] staging: pi433: fix race condition in pi433_open

f minor_lock in pi433_open(). Signed-off-by: Hugo Lefeuvre --- drivers/staging/pi433/pi433_if.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index 94e0bfcec991..73c511249f7f 100644 --- a/drivers/staging/pi43

Re: [PATCH v3] staging: pi433: fix race condition in pi433_ioctl

v4. Sorry for the noise. -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriv

Re: [PATCH v2] staging: pi433: fix race condition in pi433_ioctl

ock); > > + if (copy_from_user(&tx_cfg_buffer, argp, > > + sizeof(struct pi433_tx_cfg))) { > > Sorry for the duplicate review, but it got sent to both my inboxes... :P Thanks for your review ! Patch updated. Please tell me if you don&#x

[PATCH v4] staging: pi433: fix race condition in pi433_ioctl

R_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data and simpler code. Signed-off-by: Hugo Lefeuvre --- Changes in v4: - Fix incorrect buffer name in memc

[PATCH v3] staging: pi433: fix race condition in pi433_ioctl

R_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data and simpler code. Signed-off-by: Hugo Lefeuvre --- Changes in v3: - Use tx_cfg for the name of temporary

[PATCH v2] staging: pi433: fix race condition in pi433_ioctl

R_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data. Signed-off-by: Hugo Lefeuvre --- Changes in v2: - Use device->tx_fifo_lock instead of introd

Re: [PATCH v2] staging: pi433: add mutex fixing concurrency issues.

lled by pi433_tx_thread) after the config has been written to the fifo by pi433_write. What kind of checks do you want to perform exactly ? But, right, I prefer the idea of the temporary buffer too, and seeing the rest of kernel code it seems to be the usual way to go. Regards, Hugo --

Re: [PATCH] staging: pi433: add mutex fixing race condition when accessing tx_cfg

s case we don't even need to introduce a new lock, using device->tx_fifo_lock should be fine. I'll update the patch. -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA si

[PATCH] staging: pi433: add mutex fixing race condition when accessing tx_cfg

t enter in an inconsistent state. Add a mutex making sure that the PI433_IOC_WR_TX_CFG case will never be run by several threads concurrently. Signed-off-by: Hugo Lefeuvre --- drivers/staging/pi433/pi433_if.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/sta

Re: [PATCH v2] staging: pi433: add mutex fixing concurrency issues.

epared a patch but couldn't test it because I don't have test devices. -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: pi433: add mutex fixing concurrency issues.

_data, which > wraps struct pi433_instance and its mutex. > > Make filp->private_data point to a struct pi433_data, allowing to > acquire the lock before accessing the struct pi433_instance. > > Signed-off-by: Hugo Lefeuvre > --- > Changes in v2: > - Use mutex

rf69_set_deviation in rf69.c (pi433 driver)

n the pi433 driver these last months] -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.lin

Re: [PATCH] staging: pi433: add rw semaphore fixing concurrency issues

k of was to create a wrapper struct pi433_data which would contain pointers to the pi433_instance and its mutex. I couldn't find any similar situation in the kernel, so I'm not sure it's the right way to go though. Thanks ! Regards, Hugo -- Hugo Lefeuvre (hle)|

[PATCH v2] staging: pi433: add mutex fixing concurrency issues.

ilp->private_data point to a struct pi433_data, allowing to acquire the lock before accessing the struct pi433_instance. Signed-off-by: Hugo Lefeuvre --- Changes in v2: - Use mutex instead of rw semaphore. - Introduce struct pi433_data in order to allow functions t

Re: [PATCH] staging: pi433: add rw semaphore fixing concurrency issues

ight, no curly braces, didn't notice it. Thanks ! Otherwise, do you think the usage of rw semaphore is appropriate in this case ? Regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA ___

[PATCH] staging: pi433: add rw semaphore fixing concurrency issues

lso affect pi433_write and pi433_read. The newly introduced semaphore makes sure that filp->private_data will not be freed by pi433_release (writer) as long as pi433_write, pi433_read or pi433_ioctl (readers) are still executing. Signed-off-by: Hugo Lefeuvre --- drivers/staging/pi433/pi433_if.