On (20/09/23 15:56), Petr Mladek wrote:
[..]
> /*
> * To reduce unnecessarily reopening, first check if the descriptor
> - * state and caller ID are correct.
> + * state and caller infromation are correct.
> */
> - d_state = desc_read(desc_ring, id, &desc, NULL, &cid);
> - if (d_state != desc_committed || cid != caller_id)
> + d_state = desc_read(desc_ring, id, &desc, NULL, &cal);
> + if (d_state != desc_committed ||
> + cal.pid != caller->pid ||
> + cal.cpu_ctx != caller->cpu_ctx) {
You probably might want to factor out ctx check into a static
inline helper. Since you use this check in several places, and
we may check more context fields in the future.
[..]
> +/* Information about the process and context that adds the message */
> +struct printk_caller {
> + pid_t pid; /* thread id */
> + u32 cpu_ctx; /* processor id and interrupt context */
> +};
A question. Suppose we have a task which does
CPU0
pr_err(...);
preempt_disable();
pr_err(...);
preempt_enable();
pr_err(...);
rcu_read_lock();
pr_info(...);
rcu_read_unlock();
Should we distinguish those as 3 different contexts?
- normal printk
- printk under disabled preemption (affects scheduling)
- printk under RCU read side lock (affects RCU grace periods)
-ss
