KernelTrap - Marcelo Tosatti

Signaling When Out of Memory

Jeremy — Fri, 19 Oct 2007 13:29:00 +0000

The previous 2.4 Linux kernel maintainer, Marcelo Tossati, resurrected a discussion on adding support for out of memory notifications to the Linux kernel. He explained, "AIX contains the SIGDANGER signal to notify applications to free up some unused cached memory," then noting, "there have been a few discussions on implementing such an idea on Linux, but nothing concrete has been achieved." In a request for discussion, Marcelo added, "on the kernel side Rik suggested two notification points: 'about to swap' (for desktop scenarios) and 'about to OOM' (for embedded-like scenarios)." Rik van Riel explained:

"The first threshold - 'we are about to swap' - means the application frees memory that it can. Eg. free()d memory that glibc has not yet given back to the kernel, or JVM running the garbage collector, or ...

"The second threshold - 'we are out of memory' - means that the first approach has failed and the system needs to do something else. On an embedded system, I would expect some application to exit or maybe restart itself."

Linux: Maintaining the 2.4 Kernel

Jeremy — Tue, 05 Dec 2006 03:08:11 +0000

Willy Tarreau replaced Marcelo Tosatti [interview] as the 2.4 stable Linux kernel maintainer in August of 2006 [story]. In response to a series of compilation fixes sent to the lkml by Mariusz Kozlowski, Willy suggested that all patches would be postponed until 2.4.34 is released. He suggested that in the interum the appropriate subsystem maintainers should be contacted to determine whether or not each of the patches should be merged, "we would merge the accepted patches and those without any reply which we consider relevant early in the 35-pre cycle so that people have some time to inform us about the potential conflicts they encounter."

Willy went on to describe how to determine who maintains each of the files, "check for the maintainer in the files themselves, or in the MAINTAINERS file. As a rule of thumb, if a file has not changed in the last 3 years and its maintainer is not one of the active ones you regularly see posting on LKML, then there are great chances that the file is unmaintained." He continued, "generally, the core subsystems (network, filesystems, archs, ...) are still well maintained by people who *really want* to validate the patches before forwarding them upstream." He went on to note, "they're all busy, so make the question simple enough so that they can quickly reply with ACK/NACK/QUEUED. Keep me CCed so that you don't have to forward me the response. Generally, they will reply within one week." Willy concluded, "if there's no easily identifiable maintainer anymore, or if some maintainers don't reply, then it becomes my job."

Linux: New v2.4 Kernel Maintainer

Jeremy — Tue, 01 Aug 2006 13:32:11 +0000

Recently releasing the 2.4.33-rc3 kernel, Marcelo Tosatti [interview] also announced a new 2.4 Linux kernel maintainer, "Willy Tarreau has stepped up to maintain the mainline v2.4 tree, and will do so starting from v2.4.34. He has devoted great effort to help maintenance for the past few years. His -hotfix tree is quite popular amongst v2.4 users, for instance. I feel very confident in his competence for the job, knowing his good common sense and great technical/communication skills." Willy began maintaining his -hf patchset against the stable 2.4 Linux kernel in February of 2005 [story].

In response to Marcelo's announcement, Willy replied, "hmmm... Like I once told you, I felt like you were trying to sell me your car, but you seem to have maintained it in very good state so I am confident it will not break after a few miles. I still hope that if I have any problem with it, you will come with your breakdown truck to rescue me :-) I hope I will get criticisms if I do things wrong. It's frustrating to work without feedback (either positive or negative)."

Linux: Reporting Kernel Security Issues

Jeremy — Fri, 14 Jan 2005 06:07:47 +0000

A lengthy and interesting thread was started on the lkml by Chris Wright looking to define a centralized place to report security issues in the Linux Kernel. Chris offered his services in getting things set up, addressing his email to Linus Torvalds, Andrew Morton [interview], Alan Cox [interview] and Marcelo Tosatti [interview]. He explained that he wanted to centralize the information "to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure". The resulting discussion was joined by numerous members of the kernel hacking community, exposing a wide range of opinions.

Linus agreed that it sounded like a good idea, but qualified this by adding, "the _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with." An embargo in this case is the time period from when a security problem is first reported to when a fix can be made public. Marcelo pointed out that a certain amount of time is necessary, "for the vendors to catch up", explaining that "it is a simple matter of synchronization". Linus again stressed his dislike for the vendor-sec mailing list suggesting that at times the length of the embargo period is often more about politics than anything else. He then added, "but in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec)." In a followup comment he clarified, "btw, the only thing I care about is the embargo on the _fix_", noting that he was comfortable if there was a need to delay publishing an explanation of the security hole so long as the fix itself was quickly released.