On 2024-01-21 11:07:34 [+0100], Oliver Hartkopp wrote: > On 2024-01-11 13:14, Sebastian Andrzej Siewior wrote: > > > Why are you afraid of doing > > mod = kmalloc(sizeof(*mod), GFP_KERNEL); > > > > before invoking cgw_parse_attr()? > > The update of the modification content should be performed instantly and > without any potential scheduling from kmalloc(). In most cases, the memory would be acquired without a delay. But if the memory is tight it will get delayed over returning a NULL pointer and (depending on the size) the NULL pointer can still be returned. This code path is preemptible so the scheduler _can_ preempt the code in favour of another task. > As you pointed out one of the problems may arise from changing the > modification functions but not from changing the modification content. > > So what about the below patch then? Well, you do change parts of the data structure while the other side can read it so I would say no. Also, in general there is no guarantee if the memcpy() implementation copies the data from front or the end. > Would a spin_lock() or spin_lock_bh() be an alternative to lock this update > against the modification execution in can_can_gw_rcv()? Yes, that is what locks are for. You would have to put the lock outside of ccgw and acquire it before reading or writting ccgw. > Best regards, > Oliver Sebastian
