All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark D Rustad <mrustad@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	torvalds@linux-foundation.org, stable@vger.kernel.org,
	lwn@lwn.net, Jiri Slaby <jslaby@suse.cz>
Subject: Re: Linux 4.4.174
Date: Wed, 13 Feb 2019 08:48:11 +0100	[thread overview]
Message-ID: <20190213074811.GC3246@kroah.com> (raw)
In-Reply-To: <B6967E84-6DCE-4390-B2D1-E3B4A0146DD6@gmail.com>

On Tue, Feb 12, 2019 at 08:13:11PM -0800, Mark D Rustad wrote:
> On Feb 9, 2019, at 12:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Fri, Feb 08, 2019 at 08:44:32PM -0800, Mark D Rustad wrote:
> > > On Feb 8, 2019, at 2:54 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > 
> > > > diff --git a/Documentation/networking/ip-sysctl.txt
> > > > b/Documentation/networking/ip-sysctl.txt
> > > > index 2ea4c45cf1c8..7c229f59016f 100644
> > > > --- a/Documentation/networking/ip-sysctl.txt
> > > > +++ b/Documentation/networking/ip-sysctl.txt
> > > > @@ -112,14 +112,11 @@ min_adv_mss - INTEGER
> > > > 
> > > >  IP Fragmentation:
> > > > 
> > > > -ipfrag_high_thresh - INTEGER
> > > > -	Maximum memory used to reassemble IP fragments. When
> > > > -	ipfrag_high_thresh bytes of memory is allocated for this purpose,
> > > > -	the fragment handler will toss packets until ipfrag_low_thresh
> > > > -	is reached. This also serves as a maximum limit to namespaces
> > > > -	different from the initial one.
> > > > -
> > > > -ipfrag_low_thresh - INTEGER
> > > > +ipfrag_high_thresh - LONG INTEGER
> > > > +	Maximum memory used to reassemble IP fragments.
> > > > +
> > > > +ipfrag_low_thresh - LONG INTEGER
> > > > +	(Obsolete since linux-4.17)
> > > 
> > > It seems very strange to say that it is obsolete since 4.17 in a 4.4
> > > kernel.
> > 
> > 4.17 is a point in time :)
> 
> Of course I understand, but some random non-kernel-developer tuning a kernel
> may be pretty puzzled. I don't know right off the top something brief that
> would be more generally meaningful, but maybe someone might. What does
> obsolete mean in this context? It exists but does nothing? It exists and
> does something but will eventually go away?

Fair enough, want to provide a patch with the real kernel version this
happened in?

thanks,

greg k-h

  reply	other threads:[~2019-02-13  7:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 10:54 Linux 4.4.174 Greg KH
2019-02-08 10:54 ` Greg KH
2019-02-09  4:44   ` Mark D Rustad
2019-02-09  8:13     ` Greg KH
2019-02-13  4:13       ` Mark D Rustad
2019-02-13  7:48         ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-09  8:39 Toralf Förster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190213074811.GC3246@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=mrustad@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.