On 2000-Apr-14 23:40:53 +1000, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>, Peter Jeremy write
>s:
>>Many years ago, I wrote a tool that analysed stack requirements by
>>parsing the assembler output from the compiler.
...
>Commit it either as a general tool or as a
Peter Jeremy <[EMAIL PROTECTED]> wrote:
>
> On 3/04, John Polstra wrote:
> [don't allocate big structs on kernel stack]
>
> Many years ago, I wrote a tool that analysed stack requirements by
> parsing the assembler output from the compiler. It determined the
> stack frame requirements and buil
In message <[EMAIL PROTECTED]>, Peter Jeremy write
s:
>Many years ago, I wrote a tool that analysed stack requirements by
>parsing the assembler output from the compiler. It determined the
>stack frame requirements and built a call flow graph to determine
>total stack depth. It had some hooks to
On 3/04, John Polstra wrote:
[don't allocate big structs on kernel stack]
Many years ago, I wrote a tool that analysed stack requirements by
parsing the assembler output from the compiler. It determined the
stack frame requirements and built a call flow graph to determine
total stack depth. It
Gary Jennejohn wrote:
> Peter Wemm writes:
> >Gary Jennejohn wrote:
> >> Bruce Evans writes:
> >> >On Mon, 3 Apr 2000, Gary Jennejohn wrote:
> >> >
> >> >> Bruce Evans writes:
> >> >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> >> >> >> I think we should nuke csu_hdr since it's not used anywhere.
Peter Wemm writes:
>Gary Jennejohn wrote:
>> Bruce Evans writes:
>> >On Mon, 3 Apr 2000, Gary Jennejohn wrote:
>> >
>> >> Bruce Evans writes:
>> >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote:
>> >> >> I think we should nuke csu_hdr since it's not used anywhere. Is that
>> >> >> what you really mean
Gary Jennejohn wrote:
> Bruce Evans writes:
> >On Mon, 3 Apr 2000, Gary Jennejohn wrote:
> >
> >> Bruce Evans writes:
> >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> >> >> I think we should nuke csu_hdr since it's not used anywhere. Is that
> >> >> what you really mean ?
> >> >
> >> >Yes. I'm t
Bruce Evans writes:
>On Mon, 3 Apr 2000, Gary Jennejohn wrote:
>
>> Bruce Evans writes:
>> >On Sun, 2 Apr 2000, Gary Jennejohn wrote:
>> >> I think we should nuke csu_hdr since it's not used anywhere. Is that
>> >> what you really mean ?
>> >
>> >Yes. I'm trying the following patch. Only tested
On Mon, 3 Apr 2000, Gary Jennejohn wrote:
> Bruce Evans writes:
> >On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> >> I think we should nuke csu_hdr since it's not used anywhere. Is that
> >> what you really mean ?
> >
> >Yes. I'm trying the following patch. Only tested at compile time.
> >
> [patc
On 3/04, John Polstra wrote:
| I doubt if it's possible to implement that at compile time. Remember,
| the preprocessor doesn't understand "sizeof". It doesn't recognize
| keywords in expressions at all.
Then don't use the preprocessor alone and use both the preprocessor and
the compiler. I s
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
> If you're worried about such things happening then you can use
> the pre-processor to catch things that may make your structures
> too large.
>
> > I wonder how too "big" can be detected. The code in question is per
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Gary Jennejohn writes:
>
> >Yes, but it was perfectly legal to put the structure on the stack
> >_before_ MLEN was doubled.
>
> Just because it worked doesn't mean that it was correct.
>
> We need to be frugal about the kernel stack, fo
Bruce Evans writes:
>On Sun, 2 Apr 2000, Gary Jennejohn wrote:
>> I think we should nuke csu_hdr since it's not used anywhere. Is that
>> what you really mean ?
>
>Yes. I'm trying the following patch. Only tested at compile time.
>
[patch snipped]
Thank you, Bruce ! This is pretty much the same
Hellmuth Michaelis wrote:
>
> >From the keyboard of Poul-Henning Kamp:
>
> > We need to be frugal about the kernel stack, for a lot of reasons,
> > that's just the way it is, and as far as I know it is the way
> > it will continue to be.
>
> Good. I'd like to learn something from it: Shall i av
On Mon, 3 Apr 2000, Alfred Perlstein wrote:
> * Hellmuth Michaelis <[EMAIL PROTECTED]> [000403 02:12] wrote:
> > >From the keyboard of Bruce Evans:
> >
> > > It's just a bug to allocate big structs on the kernel stack.
> >
> > Please specify "big"! :-)
>
> have a look at src/sys/nfs/nfs_vnops.
In message <[EMAIL PROTECTED]>, Hellmuth Michaelis writes
:
>>From the keyboard of Poul-Henning Kamp:
>
>> We need to be frugal about the kernel stack, for a lot of reasons,
>> that's just the way it is, and as far as I know it is the way
>> it will continue to be.
>
>Good. I'd like to learn somet
>From the keyboard of Poul-Henning Kamp:
> We need to be frugal about the kernel stack, for a lot of reasons,
> that's just the way it is, and as far as I know it is the way
> it will continue to be.
Good. I'd like to learn something from it: Shall i avoid allocating
structs on the kernel stack
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> Bruce Evans writes:
> >Big structs need to be malloced.
>
> Yes, but how does one know that a struct is too big ? Before the increase
> in MLEN strucct sppp was not too big.
All structs should be considered too big until proven otherwise :-).
> >I th
In message <[EMAIL PROTECTED]>, Gary Jennejohn writes:
>Yes, but it was perfectly legal to put the structure on the stack
>_before_ MLEN was doubled.
Just because it worked doesn't mean that it was correct.
We need to be frugal about the kernel stack, for a lot of reasons,
that's just the way i
Alfred Perlstein writes:
>* Hellmuth Michaelis <[EMAIL PROTECTED]> [000403 02:12] wrote:
>> Please don't misunderstand. I can fully accept accecpt and acknowledge what
>> you write (i've converted the piece of code in question to malloc'ing its
>> data already), i'm just a bit concerned because it
* Hellmuth Michaelis <[EMAIL PROTECTED]> [000403 02:12] wrote:
> >From the keyboard of Bruce Evans:
>
> > It's just a bug to allocate big structs on the kernel stack.
>
> Please specify "big"! :-)
have a look at src/sys/nfs/nfs_vnops.c:
line ~2787:
#ifndef NFS_COMMITBVECSIZ
#define NFS_COMMITB
>From the keyboard of Bruce Evans:
> It's just a bug to allocate big structs on the kernel stack.
Please specify "big"! :-)
I wonder how too "big" can be detected. The code in question is perfectly
valid syntactically and semantically correct C-code.
If a piece of code being considered buggy d
Bruce Evans writes:
>On Sun, 2 Apr 2000, Gary Jennejohn wrote:
>> Moving the struct spppreq into global address space solves the problem,
>> but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
>> 128 also fixes the problem, even with the struct spppreq on the stack.
>
>Big stru
> I wonder how wise it was to change MLEN without more testing. But hey,
> this is -current, that's what it's there for.
I've been running with MLEN set to 256 bytes for more than a year for
reasons unrelated to this commit, and haven't seen any problems at all.
(Of course, I don't use sppp..)
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
> struct slcompress is now in struct sppp, which is passed by ispppcontrol
> as part of an ioctl call. Eventually the kernel lands in sppp_params,
> which does a copyin to a struct spppreq (which contains struct sppp) on
> the kernel stack. Because struct
* Gary Jennejohn <[EMAIL PROTECTED]> [000402 01:43] wrote:
> This is a HEADS UP.
>
> The recent increase in MLEN from 128 to 256 bytes led to very surprising
> problems with the latest, so called developers', version of isdn4bsd.
>
> The new version uses slcompress by default. The change in MLE
26 matches
Mail list logo
