In a move that underscores the Linux kernel community’s uncompromising stance on code maintenance and quality, a significant chunk of IBM-originated networking infrastructure is being ripped out of the kernel. The SMC-TCP Upper Layer Protocol (ULP) functionality — once positioned as a transparent performance optimization for TCP connections — is now slated for removal, marking a rare instance of established kernel code being fully reverted due to sustained neglect and unresolved technical debt.

The decision, which has been building for months, reflects a broader tension in open-source development: what happens when a major corporation contributes complex subsystem code to a critical project and then fails to adequately maintain it? For Linux, the answer is increasingly clear — the code gets shown the door, regardless of the contributor’s stature.

What SMC-TCP Was Supposed to Do — and Why It Mattered

SMC, or Shared Memory Communications, is a protocol family developed by IBM that was designed to leverage high-speed Remote Direct Memory Access (RDMA) hardware to accelerate network communications. The SMC-TCP ULP component specifically aimed to provide a transparent acceleration layer for existing TCP applications. In theory, applications could benefit from RDMA-class performance without any code changes — the kernel’s Upper Layer Protocol mechanism would intercept TCP connections and, where possible, route them over SMC’s shared-memory transport instead.

The technology had particular relevance for IBM’s own hardware ecosystem, including its mainframe (System z) and Power platforms, where RDMA-capable interconnects are common. By integrating SMC-TCP as a ULP in the Linux kernel, IBM sought to make these performance benefits available broadly, positioning Linux as a first-class citizen on its enterprise hardware. The code was merged into the mainline kernel and has been shipping in stable releases for several years.

The Rot Sets In: Maintenance Failures and Growing Technical Debt

Despite its ambitious goals, the SMC-TCP ULP code has been plagued by a persistent lack of adequate maintenance. As reported by Phoronix, the revert is being driven by the reality that the code has accumulated significant issues over time, with insufficient developer attention from IBM or anyone else to address them. The problems are not merely cosmetic — they touch on fundamental correctness and stability concerns within the networking stack.

The Linux kernel’s networking subsystem is among the most performance-sensitive and security-critical components of the entire project. Code that lives in this layer must meet exceptionally high standards for correctness, because bugs can lead to data corruption, security vulnerabilities, or system crashes that affect millions of deployments worldwide. When subsystem maintainers identify code that consistently falls below these standards and lacks active stewardship, they have both the authority and the responsibility to act.

The Kernel Community’s Escalating Frustration

The decision to revert the SMC-TCP ULP did not come out of nowhere. Kernel networking maintainers had been raising concerns for an extended period, signaling that the code needed attention and that its current state was becoming untenable. In the Linux kernel development model, subsystem maintainers serve as gatekeepers for their respective areas of the codebase. When they determine that a piece of code poses more risk than benefit, they can and do push for its removal.

According to the reporting from Phoronix, the networking maintainers ultimately concluded that the SMC-TCP ULP integration was not being maintained to the standard required for inclusion in the mainline kernel. The revert effectively strips out the ULP hooks that allowed SMC to transparently intercept TCP connections. It is worth noting that this does not necessarily remove all SMC functionality from the kernel — the core SMC socket family may persist — but the seamless, transparent TCP acceleration layer is what is being pulled.

A Pattern of Corporate Code Abandonment

IBM’s situation with SMC-TCP is not entirely unique in the Linux kernel’s history, but it is notable given the company’s long and deep involvement with Linux development. IBM was one of the earliest major enterprise backers of Linux, famously investing a billion dollars in the platform in the early 2000s. The company continues to employ kernel developers and contribute to various subsystems. However, the SMC-TCP episode illustrates a recurring challenge: corporate priorities shift, teams get reorganized, and code that was once a strategic priority can become an orphan.

This pattern has played out with other companies and other subsystems over the years. When a corporation contributes code to the kernel, there is an implicit social contract that the contributor will help maintain that code going forward. The kernel community has no formal mechanism to enforce this contract, but it does have the ultimate sanction: removal. The message is clear — contributing code to the Linux kernel is not a one-time act but an ongoing commitment. Companies that fail to honor that commitment risk seeing their contributions unwound, regardless of the engineering effort that originally went into them.

Technical Implications of the Revert

From a technical standpoint, the removal of the SMC-TCP ULP has several implications. For the vast majority of Linux users and deployments, the impact will be negligible. SMC-TCP’s transparent acceleration was primarily relevant in environments with specific RDMA-capable hardware, most commonly found in IBM’s own data center offerings. General-purpose Linux servers, cloud instances, and desktop systems were unlikely to ever trigger the SMC-TCP ULP path.

For IBM’s enterprise customers who were relying on this functionality, however, the revert could be more consequential. Those deployments may need to explore alternative approaches to leveraging RDMA for TCP workloads, or IBM may need to maintain the functionality out-of-tree — carrying it as a patch set against the mainline kernel. Out-of-tree maintenance is significantly more burdensome and fragile than in-tree development, as the code must be continuously rebased against upstream changes without the benefit of community review and testing.

What This Means for Enterprise Linux Contributions

The SMC-TCP revert also carries implications for how enterprise vendors approach kernel contributions going forward. Companies considering contributing complex subsystem code to the Linux kernel should take this episode as a cautionary tale. The kernel community’s expectations around ongoing maintenance are real and enforceable. A contribution that is not backed by a sustained maintenance commitment is, in the long run, a liability rather than an asset — both for the community and for the contributing organization’s reputation.

There is also a governance dimension worth considering. The Linux kernel’s development model is famously meritocratic and decentralized, with subsystem maintainers wielding significant authority over their domains. This model has proven remarkably effective at scaling to one of the largest collaborative software projects in history, but it also means that no single company — no matter how large or historically significant — can count on preferential treatment. Code must stand on its own merits, and it must be actively maintained to retain its place in the tree.

The Broader Health of the Linux Networking Stack

Stepping back, the willingness to revert the SMC-TCP ULP code is arguably a sign of health in the Linux kernel development process. It demonstrates that the community’s quality standards are not merely aspirational but are actively enforced, even when doing so means removing code from a major corporate contributor. The networking subsystem, in particular, has been under intensive development and scrutiny in recent years, with significant work on performance optimization, security hardening, and support for new hardware capabilities like those found in modern SmartNICs and DPUs.

Maintaining the integrity of this critical subsystem requires difficult decisions, and the SMC-TCP revert is one such decision. For industry observers and enterprise technology leaders, the episode serves as a reminder that the Linux kernel’s strength lies not just in the volume of contributions it attracts, but in the rigor with which those contributions are evaluated and maintained over time. In the world of kernel development, there are no permanent residents — only code that continues to earn its place through active, competent stewardship.

As the Linux 6.x development cycle continues, all eyes will be on whether IBM steps up to address the maintenance gap and potentially re-propose the functionality in a form that meets the community’s standards, or whether SMC-TCP’s ULP integration quietly fades into the archives of kernel history. Either way, the precedent has been set: in the Linux kernel, unmaintained code is unwelcome code, full stop.