> Would another possible trace look like this?
>
> idr_remove called for id=1 which is not allocated.
> [] dump_trace+0x69/0x1af
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0x15/0x17
> [] idr_remove+0xe2/0x143
> [] release_dev+0x63b/0x652
> [] tty_release+0x7/
Aristeu Sergio Rozanski Filho wrote:
> This patch fixes a possible race that leads to double freeing an idr index.
>
> Without the patch, on some machines it's possible get easily idr warnings like
> this one:
> idr_remove called for id=15 which is not allocated.
> [] idr_remove+0x139/0x170
> []
Aristeu Sergio Rozanski Filho wrote:
This normally would only issue a warning on idr_remove() but in case of a
customer's critical application, it's never too simple:
thread1: opens master, gets index X
thread1: begin closing master
thread2: begin opening slave with index X
thread1: finishes cl
This patch fixes a possible race that leads to double freeing an idr index.
When the master begin to close, release_dev() is called and then pty_close()
is called:
if (tty->driver->close)
tty->driver->close(tty, filp);
This is done without helding any locks other than BKL. I
4 matches
Mail list logo
