Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux

Linux 5.3 Released (kernelnewbies.org) 43

Posted by EditorDavid from the good-news-for-AMD-Navi-GPUs dept.
"Linux 5.3 has been released," writes diegocg: This release includes support for AMD Navi GPUs; support for the umwait x86 instructions that let processes wait for short amounts of time without spinning loops; a 'utilization clamping' mechanism that is used to boost interactivity on power-asymmetric CPUs used in phones; a new pidfd_open(2) system call that completes the work done to let users deal with the PID reuse problem; 16 millions of new IPv4 addresses in the 0.0.0.0/8 range are made available; support for Zhaoxin x86 CPUs; support Intel Speed Select for easier power selection in Xeon servers; and support for the lightweight hypervisor ACRN, built for embedded IoT devices. As always, many other new drivers and improvements can be found in the changelog.
This discussion has been archived. No new comments can be posted.

Linux 5.3 Released More

Linux 5.3 Released

Comments Filter:

  • "16 millions of new IPv4 addresses in the 0.0.0.0/8 range are made available"
     
    I'll bet Windows 10 doesn't have THAT!

    • Microshaft will 0day it into every unwilling subject's system. That's still not going to cover OSes like 7 and old un-updated machines running different OSes.

    • kernel.org is showing the latest as 5.3-rc8.

      E

    • I sure hope not, since allowing these as valid addresses completely contradicts a bunch of RFCs, and seems based on some rando Github project listing reserved ranges some people “think” should be made available for use and on a “moonshot” designated paper presented at a conference (https://kernelnewbies.org/Linux_5.3#A_few_millions_of_new_IPv4_addresses). That’s not very serious. They don’t seem to care about all the ways some of these have been used (private multicast ad

      • Re:What? (Score:5, Informative)

        by iggymanz ( 596061 ) on Sunday September 15, 2019 @08:59PM (#59197902)

        No, only a couple RFC in play from BSD 4.2 era which no longer have any applicability to the real world which is discussed in the rationale for this great proposal. Only 0.0.0.0/32 needs to be respected, the rest can and should be usable.

        Not random if you understand the people behind it.

      • Re: (Score:1)

        by Anonymous Coward

        I sure hope not, since allowing these as valid addresses completely contradicts a bunch of RFCs

        Which ones might those be? Can you give a list? Or just one?

        "Special-Use IPv4 Addresses" has never disallowed these IPs in full like most stacks assume.

        The current RFC 3330 says:
        Address 0.0.0.0/32 may be used as a source address for this host on this network;
        other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network

        The first mention of special address blocks is RFC 1340 from 1992, which predates CDIR notation and subnetting, says pretty much the same:
        (a) {0, 0}
        This host on

        • Re:What? (Score:4, Informative)

          by mtaht ( 603670 ) on Monday September 16, 2019 @05:19AM (#59198492) Homepage
          It's so great to learn others on slashdot still read RFCs, and that I didn't need to jump in to defend the 0.0.0.0/8 change. A little backstory - after John came up with bootp, and bsd 4.3 moved to .255 as a broadcast addess, it was kind of assumed that once bsd 4.2 had been completely retired that 0/8 would become usable and the standard modified to suit. Having to wait 30 years for that to actually happen was kind of unimaginable at the time....

    • "16 millions of new IPv4 addresses in the 0.0.0.0/8 range are made available"

      What does it have to do with Linux 5.3 release?

      • Summary good.

      • Just that they have upgraded their logic to cope with a hack making more ipv4 address available. Here is my first firewall rules, it seems like I don't need do deal and duplicate my rules after all for ipv6 or, at least not yet.

        #BEGIN block all ip v6 external to/from internet
        ${IP6TABLES} -A FORWARD -i ${EXTIF} -m limit --limit ${SLASHDOT_SCAN_LIMIT} -j LOG --log-level 7 --log-prefix "IPV6FWD SCAN SLASHDOT : "
        ${IP6TABLES} -A FORWARD -i ${EXTIF} -j DROP

        ${IP6TABLES} -A INPUT -i ${EXTIF} -m limit --limit ${SL

    • Re: (Score:3)

      by Bert64 ( 520050 )

      For this to be usable, it needs to get rolled out everywhere and for all legacy devices which can't handle it to get replaced...
      The only benefit of ipv4 is compatibility with legacy systems, if you're going to replace those systems anyway it's much better to move to ipv6 than deal with all these nasty kludges.

      • Re: (Score:1)

        by Anonymous Coward

        Let the buyer beware, if someone wants ipv4 addresses that may have some issues, let them have it. Hell, they can have some of my 127.0.0.0/8 if the price is right.

  • The "Umm... wait..." instructions (Score:4, Funny)

    by TeknoHog ( 164938 ) on Sunday September 15, 2019 @07:08PM (#59197740) Homepage Journal
    that let processes think about their next move

  • did linus passed maintenance work to his tax preparer or something?

  • Heh heh, you said 'utilization clamping', lol.

    Okay...maybe it's just a fetish for some of us.

  • Kernel.org has 5.3-rc8 as the latest.

    E

  • Fix low memory freezeups (Score:2, Informative)

    by Anonymous Coward

    This is all well and good.

    I would like to see the low memory lockups fixed however. They have IGNORED for over 10 years a serious bug and denial of service vulnerability in the Linux kernel which allows the kernel to be completely locked up in low memory situations. It happens with swap enabled and when RAM is nearly depleted and when swap is barely used at all, so this is not necessarily an out of memory issue, its a design flaw that causes Linux to lock up when RAM is nearly out but when there is still pl

    • Why not submit your patch? Linux is Open Source. It sounds like it is very important to you and you have it figured out.

    • As of ten years ago, there is a list of oom priority, so packagers and users can decide which processes should be protected and which should be killed first. If you want to kill Apache httpd before X, you can set that, or vice-versa. The defaults in most distributions should be reasonable for most people.

      You can also set memory over-commit settings. Most distros allow unlimited over commit. You can set it for no over-commit and leave as much as you want for buffers and cache:

      echo 2 > /proc/sys/vm/ov

    • Raising vfs_cache_pressure from 100 to 7500 or 10000 always seemed to help for me, but I can't advise doing so since I'm not sure of the implications.
  • Oh my, why only now? I could have used this ten years ago when multi core cpus started becoming widespread. The event based thread ping-pong is just too slow. Keyed events an order of magnitude better, but a spin loop is still the fastest.
  • Comment removed based on user account deletion

  • Turns out the Zhaoxin x86 is a derivative of VIA's Centaur architecture.

    Why do they try to pretend the Zhaoxin x86 is indigenous?

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close