headers
Serge E. Hallyn | 1 Dec 2007 01:01
Picon
Favicon

Re: [PATCH 4/4] net: Implement the per network namespace sysctl infrastructure

Quoting Eric W. Biederman (ebiederm <at> xmission.com):
> "Serge E. Hallyn" <serue <at> us.ibm.com> writes:
> 
> >
> > Hey Eric,
> >
> > the patches look nice.
> >
> > The hand-forcing of the passed-in net_ns into a copy of current->nsproxy
> > does make it seem like nsproxy may not be the best choice of what to
> > pass in.  Doesn't only net_sysctl_root->lookup() look at the argument?
> 
> Yes.  Although I call it from __register_sysctl_paths.
> 
> > But I assume you don't want to be more general than sending in a
> > nsproxy so as to dissuade abuse of this interface for needlessly complex
> > sysctl interfaces?
> 
> A bit of that.  I would love to pass in a task_struct so you can use
> anything from a task.  The trouble is I don't have any task_structs or
> nsproxys with the proper value at the point where I am first setting
> this up.  Further I have to have the full sysctl lookup working or I
> could not call sysctl_check.
> 
> > (Well I expect that'll become clear once the the patches using this
> > come out.)
> >
> > Are you planning to use this infrastructure for the uts and ipc
> > sysctls as well?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Morris | 1 Dec 2007 01:05
Favicon

Re: Out of tree module using LSM

On Fri, 30 Nov 2007, Crispin Cowan wrote:

> > The only case of this so far has been Multiadm, although there seems to be 
> > no reason for it to stay out of tree.
> >   
> Dazuko. It has the same yucky code issues as Talpa, but AFAIK is pure
> GPL2 and thus is clean on the license issues.
>
> That these modules are valid modules that users want to use, are GPL
> clean, and are *not* something LKML wants to upstream because of code
> issues, is precisely why the LSM interface makes sense.

I think the idea is to try and fix code quality issues through 
participation in the upstream process, rather than have upstream maintain 
stable kernel APIs which are naturally mismatched to the unknown 
requirements of out of tree users.

- James
--

-- 
James Morris 
<jmorris <at> namei.org>

-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Arnaldo Carvalho de Melo | 1 Dec 2007 01:05
Picon
Favicon

Re: Kernel Development & Objective-C

Em Fri, Nov 30, 2007 at 11:40:13PM +0000, Alan Cox escreveu:
> > BCPL was typeless, as was the successor B (between Bell Labs and GE we 
> 
> B isn't quite typeless. It has minimal inbuilt support for concepts like
> strings (although you can of course multiply a string by an array
> pointer ;))
> 
> It also had some elegances that C lost, notably 
> 
> 	case 1..5:

Hey, the language we use, gcC has this too 8-)

[acme <at> doppio net-2.6.25]$ find . -name "*.c" | xargs grep 'case.\+\.\.' | wc -l
400
[acme <at> doppio net-2.6.25]$ find . -name "*.c" | xargs grep 'case.\+\.\.' | head
./kernel/signal.c:      default: /* this is just in case for now ... */
./kernel/audit.c:       case AUDIT_FIRST_USER_MSG ...  AUDIT_LAST_USER_MSG:
./kernel/audit.c:       case AUDIT_FIRST_USER_MSG2 ...  AUDIT_LAST_USER_MSG2:
./kernel/audit.c:       case AUDIT_FIRST_USER_MSG ...  AUDIT_LAST_USER_MSG:
./kernel/audit.c:       case AUDIT_FIRST_USER_MSG2 ...  AUDIT_LAST_USER_MSG2:
./kernel/timer.c:        * well, in that case 2.2.x was broken anyways...
./arch/frv/kernel/traps.c:      case TBR_TT_TRAP2 ... TBR_TT_TRAP126:
./arch/frv/kernel/ptrace.c:             case 0 ... PT__END - 1:
./arch/frv/kernel/ptrace.c:             case 0 ... PT__END-1:
./arch/frv/kernel/gdb-stub.c:                   case GDB_REG_GR(1) ...  GDB_REG_GR(63):
[acme <at> doppio net-2.6.25]$

- Arnaldo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Dike | 1 Dec 2007 01:21

Re: capabilities-introduce-per-process-capability-bounding-set.patch breaks FC6 Avahi

On Fri, Nov 30, 2007 at 11:29:47PM +0100, Jiri Slaby wrote:
> Nope, try this :):
> http://lkml.org/lkml/2007/11/28/390

Excellent, thanks.

I just wanted to make sure that someone knew about this.

			Jeff

--

-- 
Work email - jdike at linux dot intel dot com
Permalink | Reply | 0 comments |
headers
Al Viro | 1 Dec 2007 01:31
Picon

Re: Kernel Development & Objective-C

On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> An vtable in C++ takes exactly the same space that the function
> table pointer present in every driver nowadays... and probably
> the virtual method call that C++ does itself with
> 
> 	thing->do_something(with,this)
> 
> like
> 	push thing
> 	push with
> 	push this
> 	call THING_vtable+indexof(do_something) // constants at compile time

This is not what vtables are.  Think for a minute - all codepaths arriving
to that point in your code will pick the address to call from the same
location.  Either the contents of that location is constant (in which case
you could bloody well call it directly in the first place) *or* it has to
somehow be reassigned back and forth, according to the value of this.  The
former is dumb, the latter - outright insane.

The contents of vtables is constant.  The whole point of that thing is
to deal with the situations where we _can't_ tell which derived class
this ->do_something() is from; if we could tell which vtable it is at
compile time, we wouldn't need to bother at all.

It's a tradeoff - we pay the extra memory access (fetch vtable pointer, then 
fetch method from vtable) for not having to store a slew of method pointers
in each instance of base class.  But the extra memory access is very much
there.  It can be further optimized away if you have several method calls
for the same object next to each other (then vtable can be picked once),
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adrian Bunk | 1 Dec 2007 01:33

Re: [PATCH] Avoid overflows in kernel/time.c

On Thu, Nov 29, 2007 at 04:19:51PM -0800, H. Peter Anvin wrote:
> When the conversion factor between jiffies and milli- or microseconds
> is not a single multiply or divide, as for the case of HZ == 300, we
> currently do a multiply followed by a divide.  The intervening
> result, however, is subject to overflows, especially since the
> fraction is not simplified (for HZ == 300, we multiply by 300 and
> divide by 1000).
>...
>  kernel/Makefile     |    8 +++
>  kernel/time.c       |   29 +++++++++---
>  kernel/timeconst.bc |  123 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 152 insertions(+), 8 deletions(-)
>  create mode 100644 kernel/timeconst.bc
>...

I have read the hep text, but are the advantages of HZ == 300 really 
visible or was this more theoretical?

In the latter case, we might remove the HZ == 300 choice instead.

cu
Adrian

--

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rene Herman | 1 Dec 2007 01:33
Picon

Re: [PATCH] Declare PNP option parsing functions as __init

On 01-12-07 00:52, Bjorn Helgaas wrote:

> On Friday 30 November 2007 04:37:26 pm Rene Herman wrote:
>> On 30-11-07 18:04, Thomas Renninger wrote:
>>> If I have not overseen something, it should be rather obvious that those
>>> can all be declared __init...
>>> ---------------
>>>
>>> Declare PNP option parsing functions as __init
>>>
>>> There are three kind of parse functions provided by PNP acpi/bios:
>>>  - get current resources
>>>  - set resources
>>>  - get possible resources
>>> The first two may be needed later at runtime.
>>> The possible resource settings should never change dynamically.
>>> And even if this would make any sense (I doubt it), the current implementation
>>> only parses possible resource settings at early init time:
>>>   -> declare all the option parsing __init
>>>
>>> Signed-off-by: Thomas Renninger <trenn <at> suse.de>
>> Yes. Obviousness aside,
>>
>> (0) pnpacpi_add_device                          is only caller of
>> ...
> 
> I agree this is probably safe in the current implementation.
> 
> However, I think the current implementation is just broken because
> we can't really handle hotplug of ACPI devices.  Specifically, I think
(Continue reading)

Permalink | Reply | 2 comments |
headers
Al Viro | 1 Dec 2007 01:34
Picon

Re: Kernel Development & Objective-C

On Sat, Dec 01, 2007 at 12:31:19AM +0000, Al Viro wrote:
> somehow be reassigned back and forth, according to the value of this.  The
s/this/thing/, of course
Permalink | Reply | 0 comments |
headers
Kristen Carlson Accardi | 1 Dec 2007 01:34
Picon
Favicon

Re: [patch] ata: ahci: Enclosure Management via LED rev2

Enclosure Management via LED

This patch implements Enclosure Management via the LED protocol as specified
in AHCI specification.

Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi <at> intel.com>
---
This revision makes the change to the comment requested by Mark Lord,
fixes some bugs in the bit shifting for writing the new led state,
and implements a show function so that led status can be read as
well as written.

 drivers/ata/ahci.c        |  184 +++++++++++++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-scsi.c |    5 -
 include/linux/libata.h    |    2 
 3 files changed, 187 insertions(+), 4 deletions(-)

Index: 2.6-git/drivers/ata/ahci.c
===================================================================
--- 2.6-git.orig/drivers/ata/ahci.c	2007-11-30 12:04:12.000000000 -0800
+++ 2.6-git/drivers/ata/ahci.c	2007-11-30 18:02:19.000000000 -0800
 <at>  <at>  -44,6 +44,7  <at>  <at> 
 #include <linux/dmi.h>
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_device.h>
 #include <linux/libata.h>

 #define DRV_NAME	"ahci"
 <at>  <at>  -92,6 +93,8  <at>  <at>  enum {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul E. McKenney | 1 Dec 2007 01:37
Picon

[PATCH] Remove rcu_assign_pointer() penalty for NULL pointers

Hello!

The rcu_assign_pointer() primitive currently unconditionally executes
a memory barrier, even when a NULL pointer is being assigned.  This
has lead some to avoid using rcu_assign_pointer() for NULL pointers,
which loses the self-documenting advantages of rcu_assign_pointer()
This patch uses __builtin_const_p() to omit needless memory barriers
for NULL-pointer assignments at compile time with no runtime penalty,
as discussed in the following thread:

	http://www.mail-archive.com/netdev <at> vger.kernel.org/msg54852.html

Tested on x86_64 and ppc64, also compiled the four cases (NULL/non-NULL
and const/non-const) with gcc version 4.1.2, and hand-checked the
assembly output.

Signed-off-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
---

 rcupdate.h |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff -urpNa -X dontdiff linux-2.6.24-rc1-ego/include/linux/rcupdate.h linux-2.6.24-rc1-egoxu/include/linux/rcupdate.h
--- linux-2.6.24-rc1-ego/include/linux/rcupdate.h	2007-11-06 15:30:02.000000000 -0800
+++ linux-2.6.24-rc1-egoxu/include/linux/rcupdate.h	2007-11-30 09:06:11.000000000 -0800
 <at>  <at>  -191,10 +191,13  <at>  <at>  static inline void rcu_preempt_boost(voi
  * code.
  */

-#define rcu_assign_pointer(p, v)	({ \
(Continue reading)

Permalink | Reply | 5 comments |

Gmane