<!DOCTYPE html>
<!-- BaNnErBlUrFlE-BoDy-start -->
<!-- Preheader Text : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">
On 9/11/2026 11: 31 AM, Fernando Fernandez Mancera wrote: > On 9/11/26 7: 46 PM, Casey Schaufler wrote: >> On 9/10/2026 7: 48 AM, Fernando Fernandez Mancera wrote: >>> Historically, the IPv4 protocol has been linked to the core</div>
<!-- Preheader Text : END -->

<!-- Email Banner : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;"></div>
<!-- Email Banner : END -->

<!-- BaNnErBlUrFlE-BoDy-end -->
<html>
<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
  #pfptBannerv8brmas { all: revert !important; display: block !important;
    visibility: visible !important; opacity: 1 !important;
    background-color: #c2d4d4 !important;
    max-width: none !important; max-height: none !important }
  .pfptPrimaryButtonv8brmas:hover, .pfptPrimaryButtonv8brmas:focus {
    background-color: #a2b1b1 !important; }
  .pfptPrimaryButtonv8brmas:active {
    background-color: #828e8e !important; }
  html:root, html:root>body { all: revert !important; display: block !important;
    visibility: visible !important; opacity: 1 !important; }
</style>

<!-- BaNnErBlUrFlE-HeAdEr-end -->
</head><body><pre style="font-family: sans-serif; font-size: 100%; white-space: pre-wrap; word-wrap: break-word">On 9/11/2026 11:31 AM, Fernando Fernandez Mancera wrote:
> On 9/11/26 7:46 PM, Casey Schaufler wrote:
>> On 9/10/2026 7:48 AM, Fernando Fernandez Mancera wrote:
>>> Historically, the IPv4 protocol has been linked to the core INET
>>> subsystem. Because shared infrastructure like the TCP/UDP engine,
>>> routing or INET hashtables live inside net/ipv4/, it has been
>>> impossible
>>> to compile a kernel with only IPv6 support.
>>>
>>> This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
>>> 'def_bool y' for now. This does not allow to completely disable the
>>> IPv4 stack yet but it lays the necessary build-system work for that
>>> goal.
>>>
>>> In addition, multiple subsystems Kconfig symbols across networking
>>> features like tunnels, drivers and filesystems have been adjusted to
>>> depend on IPv4. Keep on mind that follow-up work is required to convert
>>> the Kconfig symbol to bool and remove the dependency on IPv4 where it
>>> makes sense.
>>>
>>> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
>>> ---
>>>   
>>
>> ...
>>
>>
>>>   security/smack/Kconfig                        |  1 +
>>>   54 files changed, 126 insertions(+), 66 deletions(-)
>>>
>> ...
>>
>>> diff --git a/security/smack/Kconfig b/security/smack/Kconfig
>>> index 5a8dfad469c3..b4e6d0168bd1 100644
>>> --- a/security/smack/Kconfig
>>> +++ b/security/smack/Kconfig
>>> @@ -3,6 +3,7 @@ config SECURITY_SMACK
>>>       bool "Simplified Mandatory Access Control Kernel Support"
>>>       depends on NET
>>>       depends on INET
>>> +    depends on IPV4
>>>       depends on SECURITY
>>>       select NETLABEL
>>>       select SECURITY_NETWORK
>>
>> Why would this make sense? You're introducing the capability to use
>> IP6 by itself, which is admirable, but you're disallowing that
>> configuration
>> with the Smack LSM. It appears that you've done a mechanical lookup
>> in the
>> Kconfig files and applied the minimal change to make the kernel compile,
>> which probably works for most cases. It does not work for Smack. Unless
>> there's a strong argument that Smack with IPv6 and without IPv4 is
>> and always
>> will be a pointless configuration you have my NAK.
>>
>>
>
> Right, that was kind of the point. The idea was to be able to compile
> core networking without IPv4. There are still plenty of modules that
> depends on IPv4. It does not mean that they will remain like that
> forever as I mentioned my idea was a follow-up on the series to avoid
> having a too long series.
>
> Anyway, I can make Smack to do not depend on IPv4 on this series if
> that could grant an ACK.

Yes, that would be acceptable. I apologize in advance for the Smack IPv6
implementation. Replacing it with a proper CALIPSO stack has been on the
todo list since CALIPSO was introduced.

>
> Thanks,
> Fernando.
>
</pre></body></html>