From: Jeroen Vreeken <jeroen@vreeken.net>
To: Matt VK2RQ <matt.vk2rq@gmail.com>
Cc: "linux-hams@vger.kernel.org" <linux-hams@vger.kernel.org>
Subject: Re: [RFC] Future of INP3 patch
Date: Tue, 18 Dec 2012 23:13:37 +0100 [thread overview]
Message-ID: <50D0EA91.30908@vreeken.net> (raw)
In-Reply-To: <4B30F8D4-7679-400F-8606-BC0D449DCA8D@gmail.com>
Hi Matt,
On 12/16/2012 12:08 AM, Matt VK2RQ wrote:
>> Hi,
>>
>> I haven't seen any replies after posting about the inp3 patches for 2.6 so
>> either the spontanious combustion problems are fixed or nobody cares.....
>> At the moment the patch seems to be pretty stable and running without
>> problems so I was wondering what to do next:
>>
>> - Keep making new patches for the 2.6 kernels and try to get it in in 2.7
>> (Should be very safe, although less testing)
>>
>> - Try to get it in 2.6.
>> (The patch only affects netrom and is for 99% configurable with
>> CONFIG_NETROM_INP with the exeption of the netrom node sorting but this
>> shouldn't be a problem)
>>
>> Any comments?
> Hi Jeroen,
>
> I just tried installing version 007 of your INP3 patch to kernel 2.6.32. There have
> been some changes to the kernel since 2.6.4, so I needed to tweak it a bit to
> get it to compile:
> http://qsl.net/vk2rq/2.6.32-inp3_007.patch
>
> However, there are some deadlock problems arising from this patch. Specifically,
> when inp3_nodes_neg() is called, neigh_list will already be locked, and if
> it was called from inp3_route_neg(), then node_list will be locked as well.
>
> However, inp3_nodes_neg() calls nr_del_node_found(), which assumes
> there are no locks in place. If nr_del_node_found() places a call to
> nr_remove_neigh() or nr_remove_node(), then those functions will
> try to acquire a lock on neigh_list or node_list, which will lead to a
> deadlock situation if those locks are already in place.
>
> This thread is already quite old, so not sure if you or anyone else is
> still maintaining this code?
I have not been actively maintaining the code. However I am currently
re-building the local packet access point in Eindhoven, and I was
planning on updating the patch to a more recent kernel. (probably 3.7 based)
I haven't got around to this since I am still fighting with scc cards...
but I hope to get to the netrom part soon.
73,
Jeroen PE1RXQ
next prev parent reply other threads:[~2012-12-18 22:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1355612939-3148455801.80b07a7cbd@bliksem.vehosting.nl>
2012-12-15 23:08 ` [RFC] Future of INP3 patch Matt VK2RQ
2012-12-18 22:13 ` Jeroen Vreeken [this message]
2004-03-29 18:26 Jeroen Vreeken
2004-03-30 12:27 ` Wilbert Knol
2004-03-30 14:14 ` Ralf Baechle DL5RB
2004-03-30 13:35 ` Øyvind Hanssen
2004-03-30 14:21 ` Ralf Baechle DL5RB
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D0EA91.30908@vreeken.net \
--to=jeroen@vreeken.net \
--cc=linux-hams@vger.kernel.org \
--cc=matt.vk2rq@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.