All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.