Owner match misnaming

Owner match misnaming

[Jan Engelhardt]

Hi,


|OWNER match v1.3.1 options:
|[!] --uid-owner userid     Match local uid
|[!] --gid-owner groupid    Match local gid

After analyzing the kernel part because some packets obviously did not match 
my rules, I notice that these are in reality the socket owner's uid, and not 
the process's uid.

I already started a patch to add process [ug]{,e,s,fs}id to the owner 
kernel and user modules, but according to the comments in the kernel code, 
they would just be as SMP-unsafe as the pid/sid/comm code.

Ideas? Why, after all, is this the case?
BTW,
          /* files->file_lock can not be used in a BH */
a BH is a buffer head, at least in the linux kernel...



Jan Engelhardt                                                               
--                                                                            

Re: Owner match misnaming

[Amin Azez]

Jan Engelhardt wrote:
> Hi,
> 
> 
> |OWNER match v1.3.1 options:
> |[!] --uid-owner userid     Match local uid
> |[!] --gid-owner groupid    Match local gid
> 
> After analyzing the kernel part because some packets obviously did not match 
> my rules, I notice that these are in reality the socket owner's uid, and not 
> the process's uid.
> 
> I already started a patch to add process [ug]{,e,s,fs}id to the owner 
> kernel and user modules, but according to the comments in the kernel code, 
> they would just be as SMP-unsafe as the pid/sid/comm code.
> 
> Ideas? Why, after all, is this the case?
> BTW,
>           /* files->file_lock can not be used in a BH */
> a BH is a buffer head, at least in the linux kernel...

I think BH means bottom-half, referring to the work-side of an
interrupt. I read
http://library.n0i.net/linux-unix/administration/unreliable-guides/kernel-locking/lklockingguide.html
or http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

They talk about the differnt contraints and BH

Azez

Re: Owner match misnaming

[Jan Engelhardt]

>> BTW,
>>           /* files->file_lock can not be used in a BH */
>> a BH is a buffer head, at least in the linux kernel...
>
>I think BH means bottom-half, referring to the work-side of an
>interrupt. I read
>http://library.n0i.net/linux-unix/administration/unreliable-guides/kernel-locking/lklockingguide.html
>or http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

Any way to fix it?



Jan Engelhardt
-- 

Re: Owner match misnaming

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Mon, Jul 11, 2005 at 08:44:32PM +0200, Jan Engelhardt wrote:
> Any way to fix it?

no. The filesystem data structures are just not supposed to be called
from any in_interrupt() context.  We should make this an FAQ entry.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Owner match misnaming

[Patrick McHardy]

Harald Welte schrieb:
> On Mon, Jul 11, 2005 at 08:44:32PM +0200, Jan Engelhardt wrote:
> 
>>Any way to fix it?
> 
> no. The filesystem data structures are just not supposed to be called
> from any in_interrupt() context.  We should make this an FAQ entry.

Actually there are a couple of patches in -mm for lockless fd lookup.
Probably still doesn't work from softirq context, but I'm haveing a
look now.

Regards
Patrick

Re: Owner match misnaming

[Jan Engelhardt]

>> > Any way to fix it?
>> 
>> no. The filesystem data structures are just not supposed to be called
>> from any in_interrupt() context.  We should make this an FAQ entry.
>
> Actually there are a couple of patches in -mm for lockless fd lookup.
> Probably still doesn't work from softirq context, but I'm haveing a
> look now.

What exactly needs to be locked? Right now, I only see the tasklist lock and 
the file list lock being taken, but no lock on individual fds.



Jan Engelhardt
--