Kernel Traffic #331 by Zack Brown
[email protected] Mon, 10 Oct 2005 20:26:50 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #331 For 10 Oct
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 8 Sep - 30 Sep (83 Linux 2.6.13-mm2 Released; Some Suspend/
posts) Resume Issues
2. 16 Sep - 4 Oct (140 ReiserFS Alienates Contributors
posts)
3. 26 Sep - 4 Oct (34 Patch Submission Policy Documentation
posts)
4. 29 Sep - 30 Sep (6 posts) Thermal Control And cpufreq Support For
iMac G5
5. 29 Sep - 4 Oct (39 git Guide Updated
posts)
6. 29 Sep - 4 Oct (43 Linux 2.6.14-rc2-mm2 Released
posts)
7. 29 Sep - 5 Oct (22 Stable Series Patch Review Begins Towards
posts) 2.6.13.3
8. 30 Sep (1 post) Linux 2.6.14-rc3 Released
9. 3 Oct - 5 Oct (7 posts) Linux 2.6.13.3 Released
10. 5 Oct - 7 Oct (7 posts) Documenting That ksymoops Should No Longer
Be Used
Mailing List Stats For This Week
We looked at 2477 posts in 14MB. See the Full Statistics.
There were 769 different contributors. 303 posted more than once. The average
length of each message was 97 lines.
+-----------------------------------------------------------------------------+
|The top posters of the| The top subjects of the week were: |
| week were: | |
|----------------------+------------------------------------------------------|
|57 posts in 258KB by | |
|jeff garzik |138 posts in 586KB for "i request inclusion of reiser4|
|52 posts in 288KB by |in the mainline kernel" |
|luben tuikov |130 posts in 667KB for "i request inclusion of sas |
|48 posts in 208KB by |transport layer and aic-94xx into" |
|linus torvalds |59 posts in 289KB for "2.6.13-mm2" |
|43 posts in 263KB by |43 posts in 276KB for "2.6.14-rc1-git-now still dying |
|andrew morton |in mm/slab - this time line 1849" |
|43 posts in 182KB by |42 posts in 175KB for "freebox possible gpl violation"|
|paul jackson | |
+-----------------------------------------------------------------------------+
These stats generated by mboxstats version 2.8
1. Linux 2.6.13-mm2 Released; Some Suspend/Resume Issues
8 Sep - 30 Sep (83 posts) Archive Link: "2.6.13-mm2"
Topics: Digital Video Broadcasting, FS: CIFS, Framebuffer, Kernel Release
Announcement, PCI, Power Management: ACPI, USB
People: Andrew Morton, Hugh Dickins, Rafael J. Wysocki, Daniel Ritz, Linus
Torvalds
Andrew Morton announced Linux 2.6.13-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2
/
(kernel.org propagation is slow. There's a temp copy at http://www.zip.com.au/
~akpm/linux/patches/stuff/2.6.13-mm2.bz2)
* Added Andi's x86_64 tree, as separate patches
* Added a driver for TI acx1xx cardbus wireless NICs
* Large revamp of pcmcia suspend handling
* Largeish v4l and DVB updates
* Significant parport rework
* Many tty drivers still won't compile
* Lots of framebuffer driver updates
* There are still many patches here for 2.6.14. We're doing pretty well with
merging up the subsystem trees. ia64 and CIFS are still pending. x86_64 and
several of Greg's trees (especially USB) aren't merged yet.
Andrew tends to get a lot of response to these patches, typically minor reports
of compilation problems on a particular architecture or for particular hardware
drivers. This time was no exception. Various folks reported problems, and
Rafael J. Wysocki requested that a Yenta patch be taken back into the -mm tree,
that had earlier been taken out. He complained that his system would not resume
from suspend without it. Andrew was amenable to this, and couldn't quite
remember why the patch had been dropped in the first place. But Hugh Dickins
replied, "I remember well. My laptop does not APM resume from RAM with it. I've
just rechecked and that's still the case. I did try various patches from Rafael
to help him work it out, but it remained a puzzle." Rafael summarized:
the observations are sort of interesting (just for the record):
1. The problem is due to interrupt sharing. The IRQ is shared between yenta
and 3c59x.
2. Without the yenta driver the box resumes.
3. Without the 3c59x driver the box resumes.
4. If yenta is woken up _before_ 3c59x, the box resumes.
5. If yenta is woken up _after_ 3c59x, the box hangs. Unfortunately, this is
the default, because of the PCI device numbers.
Daniel Ritz hurled himself at this problem, requesting system data from Rafael,
and scouring the archives and the bugs database for former discussion and
similar problems. He put up a patch, saying, "we get interrupt storms from usb
which then hurt when yenta has it's handler installed but usb has not. usb/
hcd-pci.c frees the irq on suspend...so it may be enough not to do that
(survives suspend-to-ram and suspend-to-disk here. yes, restore too :)" Rafael
replied:
I've tried and it apparently works provided that _none_ of the IRQ-sharing
devices drops the IRQ on suspend.
I think that's the whole point: Either all of the devices should drop/request
IRQs on suspend/resume, or none of them should do this. IMHO we need to chose
one of these options and call it "the right way" or there always will be
problems with this.
Close by, Linus Torvalds said, "Trivial decision: if not freeing the irq fixes
the problem, then please send a tested patch that does just that. It's what we
used to do anyway." Elsewhere, as other folks considered various possibilities,
he added:
The right thing is to not free and re-aquire the damn interrupt in the first
place. It was a MISTAKE. We undid the ACPI braindamage that made it be required
a month ago, because sane people REALIZED it was a mistake.
It's not just "random luck" that not releasing the interrupt over suspend fixes
the problem. The problem is _due_ to drivers releasing the interrupt in the
first place.
IT DOESN'T MATTER what we do before the suspend, because we don't control the
wakeup sequence. If the BIOS wakeup enables the devices again, the fact that we
disabled them on suspend makes zero difference.
And yes, we can always "fix" things by selecting the right order to re-aquire
the interrupts, but the thing is, the "right order" will be machine-dependent
and in general depend on the phase of the moon and BIOS version, and ACPI
quirks.
The _only_ sane thing to do is to not drop the interrupts in the first place.
So that if you start getting interrupts before you expect them, you can still
handle them.
2. ReiserFS Alienates Contributors
16 Sep - 4 Oct (140 posts) Archive Link: "I request inclusion of reiser4 in
the mainline kernel"
Topics: FS: ReiserFS
People: Hans Reiser, Christoph Hellwig
Hans Reiser requested that Reiser4 be included in the 2.6 tree, and he tried to
thank folks for their feedback and suggestions, but ultimately the strain was
too much for him, and he couldn't resist needling the developers with
statements like, "Most of my customers remark that Namesys code is head and
shoulders above the rest of the kernel code." So the discussion went nowhere.
After some heated discussion, at one point Christoph Hellwig said:
Thanks a lot for the groundless attacks, but I'm done.
I'll stop helping you to review stuff because it's just totally pointless, you
ignore most of the review anyway and start personal attacks.
Please find someone else to review your code for inclusion, that can stand
beeing attacked everytime they write an email. Before you should probably fix
up various bits I wrote up and especialy make sure to get rid of all
duplication of generic I/O code or explain in detail why you need it and fix
your own implementations.
Andrew collected Christoph's objections, and added them to the Reiser4
ChangeLog entry in his -mm tree, so they would not be forgotten.
3. Patch Submission Policy Documentation
26 Sep - 4 Oct (34 posts) Archive Link: "[PATCH 0/3] CPUMETER (Re: [PATCH 0/
5] SUBCPUSETS: a resource"
People: Linus Torvalds, Paul Jackson
In the course of discussion, Linus Torvalds accepted a patch, saying:
Just a non-technical note: the sign-offs makes me suspect the patch (or an
earlier version of it) may have been written by Kurosawa-san. However, it
wasn't clear, so I didn't make that change, and so it now ends up being in git
with Paul as the author.
If that was wrong, please for the future keep authorship intact by having a
"From: A U Thor <[email protected]>" at the head of the description, which
will make authorship clear and allow the tools to pick that up.
Paul Jackson replied:
You guessed right. Your non-technical note was applicable.
Andrew - why doesn't your "The perfect patch" mention this? http://
www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
Linus - would you like a patch to Documentation/SubmittingPatches that mentions
this?
Hmmm ... I don't even see the "Acked-by" in these patch guides either. Probably
I should include that in SubmittingPatches as well.
Too bad that first line doesn't start "Author:" instead of "From:". Oh well - I
see Andrew already suggested that, and you declined. (You should'a listened to
him ;).
Linus replied:
The "From:" rule has been implicit in my tools for a _loong_ time, and
switching to "Author:" would just break the tools for no actual technical gain.
Not just the tools, either, since Andrew isn't the only one who follows that
From: rule - it would break "people".
So you'd have to make the tools accept _both_ "From:" and "Author:", and I
personally prefer an _unambiguously_ slightly misnamed thing over some "either
X or Y" where X is slightly misnamed but accepted because it's the one more
commonly used.
It's like the unix "creat()" system call. Sure, it would make more sense to add
the "e", but it wouldn't actually really _help_ anybody.
As to documenting the "From:" thing - yes, we probably should. It's quite
commonly used.
4. Thermal Control And cpufreq Support For iMac G5
29 Sep - 30 Sep (6 posts) Archive Link: "iMac G5: experimental thermal &
cpufreq support"
Topics: FS: sysfs, I2C
People: Benjamin Herrenschmidt, Geoff Levand, Dean Hamstead
Benjamin Herrenschmidt said:
I now have some experimental thermal control and cpufreq support for iMac G5. I
have not _yet_ implemented support for the SMU based single CPU desktops
(PowerMac9,1), those will have to wait a little bit more (not too much
hopefully, but I need potential testers to contact me as I lack hardware
access). At this point, it should work on PowerMac8,1 (iMacG5 rev A) and
PowerMac8,2 (iMacG5 rev B).
WARNING: This is really a 'first shot'. There is no overtemp detection, so be
careful. The driver doesn't yet have a sysfs interface for you to read the
temperature, but I left it with verbose debugging enabled in the kernel log so
you can see what's going on with the 2 control loops (the System one which
ticks every 5 seconds and the CPU one which ticks every second). Please tell me
if it appears to behave properly. On my iMac G5 rev A, the target temperature
for the CPU is set by the firmware at 78 degree C with a max at about 83
degree. If I put load on the CPU, the CPU appears to properly ramp up slowly to
82 then go down and stabilize at 78 while the driver slowly ramps the fans up.
The algorithm itself is extracted from darwin. However, it's a rather complex
modified version of the PID algorithm, and thus it could use some review to
make sure I got everything right.
The thermal control is also part of a new infrastructure I have written called
"windfarm" that splits the whole thing into several modules (though I have only
tested with everything built in at this point). Ultimately, it should be
possible to port the existing Desktop G5 and Xserver thermal driver to the new
infrastructure provided that the appropriate sensor & control modules are
written. The old thermal driver uses pretty much the same 2 kind of PID control
loops as provided by the windfarm_pid helper.
I would encourage people doing thermal control on other machines (laptops,
etc...) to also use the new infrastructure.
Ok, now the patches. You need to appy them in proper order. First of all, it
all is on top of current -git as of yesterday. I won't guarantee they will
apply on anything more ancient.
First, you need a fix that is currently pending in -mm (and should be in 2.6.14
before it's final) :
http://gate.crashing.org/~benh/ppc64-smu-fix.diff
Then, you can apply the patch that adds cpufreq support for the iMac G5 (and
possibly the SMU based desktop, though not tested)
http://gate.crashing.org/~benh/ppc64-fx-freq-scaling.diff
Then apply those 2 patches in that order:
http://gate.crashing.org/~benh/ppc64-smu-partitions.diff
http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
That's it. Now enable:
CONFIG_WINDFARM_SMU
and
CONFIG_I2C_PMAC_SMU
If you are using modules, you may have to manually load the whole bunch,
especially the i2c SMU one which isn't requested (yet).
Geoff Levand asked, "As we are already in the digital domain, I would think it
would be more savvy to use a digital controller than try to simulate an analog
controller... Why don't you abstract the control algorithm such that you can
plug in others as they are developed." Benjamin replied:
Because I don't know much about those control algorithms, and all the
calibration data provided by the firmware is in the form of factors for these
algorithms, I wouldn't know how to "unmangle" them to use with different ones.
Actually, the control algorithms (PID and modified PID) are in a "helper", so
it's fairly easy for the platform module to use whatever it wants, feel free to
submit other algorithms :) But for Apple machines, I'd rather use what I have
calibration data for, unless you can produce something that works without
any...
Dean Hamstead said:
Although i dont have an imac g5, i think that in general ben is on the right
track. its better to have something in place than nothing.
not putting down the feedback, but im not sure just how much fiddling people
will really want, and its not a huge audience. which brings me back to the
point of just getting something in place and then people can change it as IMO
linux kernel code is more likely to be fiddled with (and better 'documentation'
- whatever that is) than darwin code.
go ben, keep working hard. and keep chasing the mpeg decoder in the ati cards
of apple ibook and friends!
5. git Guide Updated
29 Sep - 4 Oct (39 posts) Archive Link: "[howto] Kernel hacker's guide to
git, updated"
People: Jeff Garzik, Dave Jones, Anton Altaparmakov, Linus Torvalds, Junio C.
Hamano
Jeff Garzik said:
Just updated my KHGtG to include the latest goodies available in git-core, the
Linux kernel standard SCM tool:
http://linux.yyz.us/git-howto.html
Several changes in git-core have made working with git a lot easier, so be sure
to re-familiarize yourself with the development process.
Comments, corrections, and notes of omission welcome. This document mainly
reflects my typical day-to-day git activities, and may not be very applicable
outside of kernel work.
Dave Jones replied:
You wrote..
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ rsync -a --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
.git/
Could be just..
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ git pull
Likewise, in the next section, git pull doesn't need an argument if pulling
from the repo it cloned.
Anton Altaparmakov pointed out that those two sets of commands were "not
actually the same. "git pull" for example will not download Linus' tags whilst
the rsync would get everything." Dave replied, "Ah. I didn't know this. Thanks.
Hmm, it'd be nice to have a shorthand 'not have to type the url, pull
everything'. Something like 'git pull all'." Linus Torvalds posted a patch,
saying, "Something like this? Except it's called "git fetch --all", and it's
obviously totally untested." Unfortunately the discussion skewed off here,
because he had upgraded to a new version of Pine that by default would mess up
whitespace in patches. Linus reconfigured his Pine, but the subthread clogged
up and died out.
Elsewhere, Jeff updated his guide again, taking into account all the comments
he'd received. Junio C. Hamano, the official git maintainer, responded to the
part of the guide that said, "Once the 'git fetch --tags' changes make it into
the official repository (are they there already?), I'll remove all the
remaining direct references to running rsync." Junio replied to this:
Sounds like a thinly veiled threat and/or very effective prodding ;-).
It is not there yet only because I simply have not got around to it, but it
will happen before 0.99.8.
I suspect the version Linus posted has a funny interaction with 'git-pull';
'git pull --tags' by mistake, or intentionally to file a bug report to annoy me
;-), would create an Octopus out of those tags, if I am not mistaken.
Linus replied:
Hey, even more impressive is "git pull --all", which will happily try to create
an octopus of every single ref available at the other end.
Now, I think that octopus merges in _general_ are likely to be driver error,
and that it might make sense to have a separate flag to enable them in the
first place. That would solve the confusion..
So then you could do
git pull --all --octopus xyzzy
if you _really_ meant to do that.
Junio replied:
True.
However, I think --all is a mistake even if you use it without merging in 'git
fetch', so I am not planning to do refs/heads/ side, at least not yet. Even if
you prevent an Octopus, what would you do then? If you choose to merge one of
them, which one? Not merging any that is not explicitly specified on the
command line, seems to me the most sensible and safe option.
The rule for 'pull' to decide which refs to merge is:
1. if command line has explicit refspecs (--tags and --heads do not count),
they are all merged.
2. if command line has no explicit refspecs (--tags and --heads do not count),
the default one found from either remotes or branches file is merged.
Notice that I am forbidding remotes file to say "by default I always merge
these three heads from there to make an Octopus" by the above rule (branches
file cannot even name more than one head so this is not an issue). Since
everybody seems to agree that Octopus is not something that is done
mechanically and routinely anyway (I do make many Octopus merges, but they
happen across my local topic branches. Topics merged change day-by-day, and
even the set of topics alive at the time changes everyday. IOW, it is not
something I would want to do with the same sets of heads every time by
describing them in the remotes file.), I think this is a sensible way to guard
against accidental Octopus.
We could consider fetching all heads, by minimally renaming remote master to
origin and getting everything else under the same name, but I'd really want to
keep the local namespace for branches isolated from each other. Many kernel.org
public repositories seem to have 'test' and 'release' branches and if you are a
maintainer of such a tree, and if you are interested in another maintainer's
tree, and if that other maintainer has the 'test' and 'release' branches,
--heads (or --tags) overwriting your 'test' with his 'test' is obviously not
what you want.
Possibly, something like this could be arranged later:
* git fetch --heads=$ns $remote "$@"
In addition to the usual refspecs (the rest of the command line arguments),
fetch all remote heads and store remote refs/heads/$a under local refs/heads/
$ns/$a for all $a. If $ns is empty, remote "master" is renamed "origin".
* git fetch --heads $remote "$@"
shorthand for empty $ns
6. Linux 2.6.14-rc2-mm2 Released
29 Sep - 4 Oct (43 posts) Archive Link: "2.6.14-rc2-mm2"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.14-rc2-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/
2.6.14-rc2-mm2/
(temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.14-rc2-mm2.gz
)
* A bunch of memory management updates
* The big pcmcia changes have been temporarily dropped
* Multiple obscure tty drivers still won't compile
* Lots of post-2.6.14-rc2-mm1 patches have been cheerfully tossed out again
due to various bugs, which felt nice.
* I am offline until October 9. Please send critical 2.6.14 fixes direct to
Linus.
7. Stable Series Patch Review Begins Towards 2.6.13.3
29 Sep - 5 Oct (22 posts) Archive Link: "[PATCH 00/10] -stable review"
Topics: Bug Tracking, Networking, PCI
People: Chris Wright, Hugh Dickins, David S. Miller, Stephen Hemminger, Ingo
Molnar, Marc Lehmann, Ivan Kokshaysky, Linus Torvalds, Ion Badulescu, Julian
Anastasov, Roland McGrath, Andi Kleen, Jeff Dike, Andrew Morton, Alexander
Nyberg
Chris Wright said:
This is the start of the stable review cycle for the 2.6.13.3 release. There
are 10 patches in this series, all will be posted as a response to this one. If
anyone has any issues with these being applied, please let us know. If anyone
is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line
to the patch, please respond with it.
These patches are sent out with a number of different people on the Cc: line.
If you wish to be a reviewer, please email [email protected] to add your name
to the list. If you want to be off the reviewer list, also email us.
Responses should be made by Sun Oct 2, 02:00 UTC. Anything received after that
time, might be too late.
He posted a set of patches with the following changelog entries:
* In some cases, especially on modern laptops with a lot of PCI and cardbus
bridges, we're unable to assign correct secondary/subordinate bus numbers
to all cardbus bridges due to BIOS limitations unless we are using "pci=
assign-busses" boot option. So some cardbus controllers may not have
attached subordinate pci_bus structure, and yenta driver must cope with it
- just ignore such cardbus bridges.
For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778
Signed-off-by: Ivan Kokshaysky <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and
can trigger due to the test itself being racy.
de_thread() does
while (atomic_read(&sig->count) > count) {
}
.....
.....
BUG_ON(!thread_group_empty(current));
but release_task does
write_lock_irq(&tasklist_lock)
__exit_signal
(this is where atomic_dec(&sig->count) is run)
__exit_sighand
__unhash_process
takes write lock on tasklist_lock
remove itself out of PIDTYPE_TGID list
write_unlock_irq(&tasklist_lock)
so there's a clear (although small) window between the atomic_dec(&sig->
count) and the actual PIDTYPE_TGID unhashing of the thread.
And actually there is no need for all threads to have exited at this point,
so we simply kill the BUG_ON.
Big thanks to Marc Lehmann who provided the test-case.
Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
Signed-off-by: Alexander Nyberg <[email protected]>
Cc: Roland McGrath <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Ingo Molnar <[email protected]>
Acked-by: Andi Kleen <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* per-socket multicast filters were not being applied to all sockets in the
case of an exact-match bound address, due to an over-exuberant "return" in
the look-up code. Fix below. IPv4 does not have this problem.
Thanks to Hoerdt Mickael for reporting the bug.
Signed-off-by: David L Stevens <[email protected]> Signed-off-by: Chris
Wright <[email protected]>
* ip_vs_ftp when loaded can create NAT connections with unknown client port
for passive FTP. For such expectations we lookup with cport=0 on incoming
packet but it matches the format of the persistence templates causing
packets to other persistent virtual servers to be forwarded to real server
without creating connection. Later the reply packets are treated as foreign
and not SNAT-ed.
If the IPVS box serves both FTP and other services (eg. HTTP) for the time
we wait for first packet for the FTP data connections with unknown client
port (there can be many), other HTTP connections that have nothing common
to the FTP conn break, i.e. HTTP client sends SYN to the virtual IP but the
SYN+ACK is not NAT-ed properly in IPVS box and the client box returns RST
to real server IP. I.e. the result can be 10% broken HTTP traffic if 10% of
the time there are passive FTP connections in connecting state. It hurts
only IPVS connections.
This patch changes the connection lookup for packets from clients:
+ introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the connection
as template
+ create new connection lookup function just for templates -
ip_vs_ct_in_get
+ make sure ip_vs_conn_in_get hits only connections with
IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way we avoid
returning template when looking for cport=0 (ftp)
Signed-off-by: Julian Anastasov <[email protected]> Signed-off-by: Chris Wright
<[email protected]>
* We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled. This fixes
that, has been well tested and is included in mainline tree. Please include
in -stable as well.
Signed-off-by: Jeff Dike <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* Here is the patch (fuzz removed) for 2.6.13.2 that fixes OOPs when using
bonding with skge.
Skge driver was bringing link up/down when changing mac address. This
doesn't work in the bonding environment, and is more effort than needed.
Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=5271 Signed-off-by:
Stephen Hemminger <[email protected]>
Sigend-off-by: Chris Wright <[email protected]>
* Patch from Joel Sing to fix the default congestion control algorithm for
incoming connections. If a new congestion control handler is added (via
module), it should become the default for new connections. Instead, the
incoming connections use reno. The cause is incorrect initialisation causes
the tcp_init_congestion_control() function to return after the initial if
test fails.
Signed-off-by: Stephen Hemminger <[email protected]>
Acked-by: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* Handle better the case where the sender sends full sized frames initially,
then moves to a mode where it trickles out small amounts of data at a time.
This known problem is even mentioned in the comments above tcp_grow_window
() in tcp_input.c, specifically:
..
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
..
When the sender gives full sized frames, the "struct sk_buff" overhead from
each packet is small. So we'll advertize a larger window. If the sender
moves to a mode where small segments are sent, this ratio becomes tilted to
the other extreme and we start overrunning the socket buffer space.
tcp_clamp_window() tries to address this, but it's clamping of tp->
window_clamp is a wee bit too aggressive for this particular case.
Fix confirmed by Ion Badulescu.
Signed-off-by: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Two additional patches received some comment. The first had this changelog
entry:
As I do periodically, I checked to see how far out of sync compat_do_execve()
has gotten from do_execve(). And as usual there was some missing stuff in the
former. Perhaps we need some tighter consolidation of these two routines to
make this less likely to happen in the future.
Anyways, on the success path of compat_do_execve() we forget to call
acct_update_integrals() and update_mem_hiwater(), as is done in do_execve().
Signed-off-by: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Hugh Dickins remarked, "The patch is good, but for -stable? Spelling
corrections next?" Chris replied, "Heh, I think you've got a good point. This
one doesn't have any real nasty side-effects that I can see. David do you have
objections to dropping this one from -stable?" David S. Miller said, "No
objections, you can drop it."
The other patch to be discussed had this changelog entry:
I think we should cache the per-socket route(dst_entry) only when the IPv6 UDP
socket is connect(2)'ed. (which is same as IPv4 UDP send behavior)
Signed-off-by: Mitsuru KANDA <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Chuck Wolber felt this really wasn't a necessary bug fix, and so didn't belong
in the -stable patch set. But David replied, "Without this unconnected ipv6 UDP
sockets end up using the wrong route or IPSEC path." Mitsuru Kanda, the author
of the patch, said he would work on updating the patch. Chris replied, "BTW, we
dropped this one, since it had possible leak in it. I'll let you and DaveM
decide when the updated one is ready for -stable." David said this would be
fine.
8. Linux 2.6.14-rc3 Released
30 Sep (1 post) Archive Link: "Linux v2.6.14-rc3"
Topics: Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.14-rc3, saying:
Ok, this may or may not be the last -rc before 2.6.14, but the point is that
we're getting closer.
The diffstat (not included here) tells the story: most of the changes are just
a couple of lines, with a few outliers: a new "cassini" network driver, the mpt
sas driver, some ip-conntrac work, and net/llc cleanups. Oh, and sparc updates
and some ppc tlb and smu work.
9. Linux 2.6.13.3 Released
3 Oct - 5 Oct (7 posts) Archive Link: "Linux 2.6.13.3"
Topics: Networking
People: Chris Wright, Stephen Hemminger, Chris Wright:, Ivan Kokshaysky, Julian
Anastasov, Alexey Kuznetsov, David Stevens, Alexander Nyberg
Chris Wright announced Linux 2.6.13.3, saying:
We (the -stable team) are announcing the release of the 2.6.13.3 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between 2.6.13.2
and 2.6.13.3, as it is small enough to do so.
The updated 2.6.13.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.13.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/ (http://www.kernel.org/git/)
Alexander Nyberg:
Fix fs/exec.c:788 (de_thread()) BUG_ON
Alexey Kuznetsov:
Don't over-clamp window in tcp_clamp_window()
Chris Wright:
Linux 2.6.13.3
David Stevens:
fix IPv6 per-socket multicast filtering in exact-match case
Ivan Kokshaysky:
yenta oops fix
Julian Anastasov:
ipvs: ip_vs_ftp breaks connections using persistence
Paolo 'Blaisorblade' Giarrusso:
uml - Fix x86_64 page leak
Stephen Hemminger:
skge: set mac address oops with bonding
tcp: set default congestion control correctly for incoming connections
10. Documenting That ksymoops Should No Longer Be Used
5 Oct - 7 Oct (7 posts) Archive Link: "[PATCH] Documentation: ksymoops should
no longer be used to decode Oops messages"
People: Jesper Juhl, Alexey Dobriyan, Randy Dunlap
Jesper Juhl posted a patch to "Document the fact that ksymoops should no longer
be used to decode Oops messages." Alexey Dobriyan replied, "If it's considered
harmful, better remove all references to ksymoops. 2.4 users will happily grab
their copy of this file from 2.4 tree." Jesper said, "I opted to keep the entry
but make an explicit note that ksymoops should not be used for 2.6 kernels to
make it clear. There are still people who use ksymoops on 2.6 Oops messages, so
I thought it would make sense to keep the entry but make it clear that you
should /not/ do that." But he said either way would be fine, and posted another
patch to remove the ksymoops entry instead. He remarked, "I'll leave it up to
the powers that be to sprinkle holy penguin pee on the preferred version."
Elsewhere, Kalin Kozhuharov asked what was the preferred method to decode
oopses on 2.6; and Randy Dunlap replied:
You should just enable CONFIG_KALLSYMS so that the kernel can report (decode)
the symbols with the oops message.
Yes, ksymoops will still work, but it should only be used if the kernel was not
configured with CONFIG_KALLSYMS, and some people say that the kernel oops +
symbols are better than the ksymoops output. I haven't compared them so can't
say.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.