All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: rick.jones2@hp.com, bunk@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] always export sysctl_{r,w}mem_max
Date: Fri, 26 Oct 2007 18:04:22 -0600	[thread overview]
Message-ID: <m1d4v1whh5.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20071026.163958.171785530.davem@davemloft.net> (David Miller's message of "Fri, 26 Oct 2007 16:39:58 -0700 (PDT)")

David Miller <davem@davemloft.net> writes:

> From: Rick Jones <rick.jones2@hp.com>
> Date: Fri, 26 Oct 2007 16:31:47 -0700
>
>> Eric W. Biederman wrote:
>> > Adrian Bunk <bunk@kernel.org> writes:
>> > 
>> > 
>> >>This patch fixes the following build error with CONFIG_SYSCTL=n:
>> >>
>> >><--  snip  -->
>> >>
>> >>...
>> >>ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
>> >>ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
>> >>ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
>> >>make[2]: *** [__modpost] Error 1
>> > 
>> > 
>> > I was going to ask if allowing drivers to increase rmem_max
>> > is something that we want to do.  Apparently the road runner
>> > driver has been doing this since the 2.6.12-rc1 when the
>> > git repository starts so this probably isn't a latent bug.
>> 
>> Although it does rather sound like a driver writer yanking the rope from the 
>> hand's of the sysadmin and hanging him with it rather than letting the
> sysadmin
>> do it himself.  I've seen other drivers' README's suggesting larger mem's but
>> not their sources doing it.
>
> I really don't think what the roadrunner driver is doing is
> correct at all.
>
> I also think what DLM is doing is wrong too.
>
> If DLM really wants minimum, it can use SO_SNDBUFFORCE and
> SO_RCVBUFFORCE socket options and use whatever limits it
> likes.
>
> But even this is questionable.
>
> I'll put in Adrian's patch to fix the build as a first
> priority, but in the long term this cruft has gotta go.

As it stands this is a very old build bug.  I believe those
symbols have always been exported inside of #ifdef CONFIG_SYSCTL.

So if this is really something we want to stop doing we should
be able to take a few extra moments remove the code from the
two problem drivers, and remove the exports.

It didn't look like any of the other users could possibly be
modular.

Eric





  parent reply	other threads:[~2007-10-27  0:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 23:08 [2.6 patch] always export sysctl_{r,w}mem_max Adrian Bunk
2007-10-26 23:20 ` Eric W. Biederman
2007-10-26 23:31   ` Rick Jones
2007-10-26 23:39     ` David Miller
2007-10-26 23:46       ` Rick Jones
2007-10-26 23:52         ` David Miller
2007-10-27  0:04       ` Eric W. Biederman [this message]
2007-11-07  7:50         ` David Miller

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=m1d4v1whh5.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=bunk@kernel.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.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.