Bug 125922 - [patch] Deadlock in arp(8)
Summary: [patch] Deadlock in arp(8)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-24 09:00 UTC by Damien Deville
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments
file.diff (655 bytes, patch)
2008-07-24 09:00 UTC, Damien Deville
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Deville 2008-07-24 09:00:15 UTC
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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-07-24 15:28:08 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:34 UTC
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