http://lwn.net/Articles/281029/ This is a special feed containing comments posted to the individual LWN article titled "The last things through the 2.6.26 merge window". hourly 2 http://lwn.net/Articles/282495/rss 2008-05-15T14:01:28+00:00 mcortese <p>Kernel address space maps 1-to-1 to physical memory (at least for less than 1 GiB of RAM). The argument is 1 page vs. 2 pages of stack. Having just 1 page of stack plus 1 <em>guard</em> page just doesn't save anything. http://lwn.net/Articles/282465/rss 2008-05-15T11:37:09+00:00 cras <div class="FormattedComment"><pre> Maybe a small (32bit?) canary at the end of the stack would help a bit? Although if an overflow happens I guess by the time it's noticed the kernel might have crashed already. </pre></div> http://lwn.net/Articles/281546/rss 2008-05-09T00:57:50+00:00 corbet All memory is virtual memory when the kernel is running. But kernel-space addresses are a sort of special case, in that they are mapped as one big page using a single page table entry. So it's not possible to insert inaccessible guard pages after the kernel stacks - at least, not without dropping the big mapping, which would have a significant performance cost. http://lwn.net/Articles/281543/rss 2008-05-09T00:48:08+00:00 jmspeex <div class="FormattedComment"><pre> I believe we're talking non-virtual memory, so an overflow would just end up on the next physical page with no way to detect it. Or maybe I'm just talking through my ass (I'm not a kernel dev). </pre></div> http://lwn.net/Articles/281535/rss 2008-05-08T23:12:13+00:00 kbob <div class="FormattedComment"><pre> I'm asking this from a position of ignorance -- I haven't looked at kernel code in a long time. But wouldn't it be possible to allocate 4k stacks with guard pages between them, thus (a) saving memory and (b) generating a loud exception on stack overflow? Or is there some kind of overhead in leaving holes into the kernel address space that I'm not aware of? </pre></div> http://lwn.net/Articles/281474/rss 2008-05-08T16:47:36+00:00 jzbiciak <div class="FormattedComment"><pre> Well, there's chop() and there's chomp(). Methinks chomp() is more appropriate to handle optional newlines. :-) </pre></div> http://lwn.net/Articles/281466/rss 2008-05-08T16:37:44+00:00 bronson <div class="FormattedComment"><pre> As of this year, I think chop is 20 years old (+/- 1 year). So this is what the future looks like... not very impressive. I thought we'd all be using CORBA-connected dataflow languages by now! </pre></div> http://lwn.net/Articles/281450/rss 2008-05-08T15:16:35+00:00 jzbiciak <div class="FormattedComment"><pre> Hmm... It seems like removing optional trailing newlines early ought to be more general and robust. After all, perl has had chomp() for what, a decade or more? </pre></div> http://lwn.net/Articles/281397/rss 2008-05-08T09:25:16+00:00 johill <div class="FormattedComment"><pre> I'd think that the function isn't all that generic, when would you want to use it (outside of the sysfs braindamage)? Sure, its definition might sound generic, but I wouldn't think you should use it often anyway. </pre></div> http://lwn.net/Articles/281387/rss 2008-05-08T08:06:33+00:00 cventers <div class="FormattedComment"><pre> bool sysfs_streq(const char *s1, const char *s2); Shouldn't such a generic function be named something like streqnl()? </pre></div>