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
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 MLEN makes
struct slcompress 2KB larger than it used to be. BTW the entry
27 matches
Mail list logo
