netdev - Re: [PATCH 0/5] fixup locking on m68knommu fec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Apr 2008 09:52:12 +0200
From:	Sebastian Siewior <bigeasy@...utronix.de>
To:	Greg Ungerer <gerg@...pgear.com>
Cc:	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org,
	uclinux-dev@...inux.org
Subject: Re: [PATCH 0/5] fixup locking on m68knommu fec

* Greg Ungerer | 2008-04-03 16:54:06 [+1000]:

> Hi Sebastian,
Hi Greg,

> Sebastian Siewior wrote:
>> This series basically fixes my locking problem. We have here:
>> #1 the old one which removes some undefined vars.
>> #2 cleans the file with lident. I had trouble reading the code...
>> #3 type def a function pointer so we don't have the long defines
>>    and move the callback after releasing the lock.
>> #4 This one fixes the locking I guess. My mcf5235 did not race anymore
>>    after that one. I saw 0a504779d while forming the patch so I guess
>>    we could revert that one, Greg?
>
> Yes, certainly we can.
> I'd like to do some testing on this as well :-)
No problem. I did ping -f from one box and a single ping from another
box for like an hour.
The only thing I don't really like is that do { } while (int flags) in
the ISR. Is the interrupt level or edge? /proc/interrupts wasn't clear on
this if I remember correctly.

>> #5 removes the registration of interrupt handlers & enabling interrupt
>>    sources that are not handled. I stepped into this after I thought that
>>    it is over :) Greg, Should we also remove that part where we enable
>>    the irq controller (I though request_irq() is doing that).
>
> Currently it doesn't. The main sticking point is what to do
> with the hardware based priority setting logic. We don't really
> rely on it, but they need to be set to sane values.
>
> Need to expand the interrupt controller setup code some more
> before we can take that out.
Okey.

> Regards
> Greg

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html