Dealing with printk()

2 weeks ago
by Zack Brown

It's odd that printk() would pose so many problems for kernel development, given that it's essentially just a replacement for printf() that doesn't require linking the standard C library into the kernel.

And yet, it's famously a mess, full of edge cases, corner cases, deadlocks, race conditions and a variety of other tough-to-solve problems. The reason for this is, unlike printf(), the printk() system call has to produce reasonable behavior even when the entire system is in the midst of crashing. That's really the whole point—printk() needs to report errors and warnings that can be used to debug whatever strange and unexpected catastrophe has just hit a running system.

Trying to fix all the deadlocks and other problems at the same time would be too large a task for anyone, especially since each one is a special case defined by the particular context in which the printk() call appeared. But, sometimes a bunch of instances in a particular region of code can be addressed all together.

Sergey Senozhatsky recently tried to address some printk() deadlocks, although he acknowledged he wouldn't address any instances that were caused by the printk() code itself triggering a separate recursive printk() call. He wanted to concern himself with non-recursion-based deadlocks only.

Sergey focused on the console code, which was where printk() generally sent its output, and which was one place where printk() could deadlock. He added a very small safeguard to the code, but the result seemed to be that drivers all throughout the kernel would have to be updated to use the new safeguard.

His code was not met with universal acclaim. Alan Cox noticed that Sergey's safeguard added code to the "fast path"—a region of code that needed to be as fast and efficient as possible, because it was run all the time, many times per second. Slowing down the fast path would slow down the whole system. Alan suggested instead of this, it would be better for the kernel simply not to call printk() if the console code would be in a position to deadlock.

Sergey was not in any way satisfied, however. He pointed out that his patch solved real-world problems that users had reported experiencing directly. He didn't see how it would help anything simply to pull out the printk() instances that triggered the problem, especially if those instances were doing important work like reporting on the real reason the system was crashing and so on.

Sergey wanted to keep the printk() instances and implement the safeguards to protect them. However, at this point Linus Torvalds joined the discussion, saying:

The rule is simple: DO NOT DO THAT THEN.

Don't make recursive locks. Don't make random complexity. Just stop doing the thing that hurts.

Go to Full Article
Zack Brown

Antergos Softens Arch Learning Curve

2 weeks 1 day ago
Antergos 8.9 is one of the better Arch Linux options. It is a powerful and modern computing platform, elegantly designed. It gives power users almost all they could desire. Arch distros are not for Linux newcomers -- but for seasoned Linux users who are new to Arch, Antergos has much to offer. One of the biggest challenges in getting started with any Arch distro is surviving the installation.
Jack M. Germain

Android Security Patch for October, Google Pixel Slate, Skype on Debian Vulnerability, PyTorch Beta 1.0 Released and XCOM 2: War of the Chosen - Tactical Legacy Pack Coming Soon to Linux

2 weeks 1 day ago

News briefs for October 3, 2018.

Google this week released the Android Security Patch for October 2018. Softpedia News reports that the patch fixes 26 vulnerabilities, the most severe of which could allow remote attackers to execute arbitrary code. See the Android Security Bulletin for more information.

Rumor has it that Google Pixel Slate will be the official name for the first detachable Pixelbook 2-in-1, which may be coming out soon. According to Appuals, a Google Pixel Slate benchmark was leaked recently and Android Police also mentioned in a tweet that "Google Pixel Slate is the name of Google's first Chrome OS tablet." Further details on the tablet are slim.

Skype on Debian is vulnerable to attack. On installation, the package automatically inserts Microsoft's apt repository, which means "after obtaining control of Microsoft's Debian apt repository, an attacker would be able to inject malicious content in various distro packages using the update system, as well as replace legitimate packages with maliciously crafted ones". See the Softpedia News post for more details and steps you can take to protect your computer after installing Skype.

A beta of PyTorch 1.0 has been released. Facebook recently open-sourced the Python-based project, which "provides developers with the power to seamlessly move from research to production in a single framework". ZDNet reports that the project now has many new supporters, and "with deeper cloud service support from Amazon Web Services (AWS), Google Cloud, and Microsoft Azure, and tighter integration with technology providers ARM, Intel, IBM, NVIDIA, and Qualcomm, developers can easily deploy PyTorch's ecosystem of compatible software, hardware, and developer tools."

Feral Interactive is releasing another game for Linux! XCOM 2: War of the Chosen - Tactical Legacy Pack, the expansion for the XCOM 2 award-winning strategy game, will be released for Linux and macOS soon after the Windows release on October 9, 2018. See this video for a gameplay overview.

News Security tablets ChromeOS skype Debian PyTorch Feral Interactive gaming
Jill Franklin

What's Your System's Uptime?

2 weeks 1 day ago
by Ricardo Fraile

Keep track of your system's uptime and downtime with the tuptime tool.

Finding your system's uptime is easy if the "beginning" means the last startup; the historical uptime command reports that information. But what happens if by "beginning" you mean the first startup ever of the system? Or the last 365 days? Or the last month?

Is there any way to have an accumulated uptime—or even better, a look at the whole system's life? For example, cars have odometers, and you can see the miles/kilometers since the first day. For computers, a tool was developed exactly for this task: tuptime.

tuptime reports the historical and statistical running and stopped time of your system, keeping track between restarts. Its main goals are:

  • Count system startups.
  • Register the first boot time (since installation).
  • Count intended and accidental shutdowns.
  • Show the uptime and downtime percentage since the first boot time.
  • Show the accumulated system uptime, downtime and total.
  • Show the longest, shortest and average uptime and downtime.
  • Show the current uptime.
  • Print a formatted table or list with most of the previous values.
  • Register used kernels.
  • Create reports since and/or until a given startup or timestamp.
  • Create reports in CSV format.

It works very simply. tuptime falls to the init manager for execution at startup and shutdown, and then into a cron task that launches regular executions in the meantime—there isn't any dæmon to worry about. Internally, it looks at the btime value (available in /proc/stat) and the uptime value (from /proc/uptime), and that's basically it.

The installation process is easy in Debian, Ubuntu and derivative distributions, using their respective package managers, and it should be available in all the official repositories. As prerequisites, it needs Python 3 and the SQLite library, which usually are included in core packages by default.

Once it's available on your system, you can get the information. It has three output formats: the default is a summary, and there also are table and list outputs to print the registered behavior.

Figure 1. Example tuptime Execution after Installation

The first execution reports the time since the system was booted, and the lines are self-explanatory (note that the date format is based on the system's locale settings):

Go to Full Article
Ricardo Fraile