Bug 125922
| Summary: | [patch] Deadlock in arp(8) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Damien Deville <da.deville> | ||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Open --- | ||||||
| Severity: | Affects Only Me | Keywords: | patch | ||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Keyword:
patch
or patch-ready
– in lieu of summary line prefix:
[patch]
* bulk change for the keyword
* summary lines may be edited manually (not in bulk).
Keyword descriptions and search interface:
<https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
|
When two concurrent arp are running one doing an 'arp -a -d' and the other one doing an 'arp -a -d' or 'arp -S', one of the two get blocked in rtmsg function doing a read syscall. Both processes will be in concurrence to access the table. One process will successfully nuke all entries of the arp table, the other one will be blocked in rtmsg function on the read while executing a RTM_GET or RTM_DELETE command after some time. By instrumenting arp we noticed that it happened when both process access to the same entry. It seems that the process that block read all entries available in the PF_ROUTE socket, do not find the one it is looking for and ends blocked on the PF_ROUTE socket as no more entries are available after reading and entry with rtm->rtm_pid == 0 and rtm- Fix: A patch for arp.c is provided for FreeBSD 6.3 it prevent the deadlock but might not be the right solution to the issue. Patch attached with submission follows: How-To-Repeat: Here is a way to reproduce it: - add a bunch of arp entries in your arp table (best is around 255 entries). - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') It can also be done with an 'arp -a -d' in parallel of an 'arp -S' but is more difficult to reproduce.