linux-kernel - Re: [PATCH v2] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130214142159.d0516a5f.akpm@linux-foundation.org>
Date:	Thu, 14 Feb 2013 14:21:59 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Julian Anastasov <ja@....bg>
Cc:	Zhang Yanfei <zhangyanfei@...fujitsu.com>, davem@...emloft.net,
	Simon Horman <horms@...ge.net.au>,
	Linux MM <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] net: fix functions and variables related to
 netns_ipvs->sysctl_sync_qlen_max

On Thu, 7 Feb 2013 10:40:26 +0200 (EET)
Julian Anastasov <ja@....bg> wrote:

> > Another question about the sysctl_sync_qlen_max:
> > This variable is assigned as:
> > 
> > ipvs->sysctl_sync_qlen_max = nr_free_buffer_pages() / 32;
> > 
> > The function nr_free_buffer_pages actually means: counts of pages
> > which are beyond high watermark within ZONE_DMA and ZONE_NORMAL.
> > 
> > is it ok to be called here? Some people misused this function because
> > the function name was misleading them. I am sorry I am totally not
> > familiar with the ipvs code, so I am just asking you about
> > this.
> 
> 	Using nr_free_buffer_pages should be fine here.
> We are using it as rough estimation for the number of sync
> buffers we can use in NORMAL zones. We are using dev->mtu
> for such buffers, so it can take a PAGE_SIZE for a buffer.
> We are not interested in HIGHMEM size. high watermarks
> should have negliable effect. I'm even not sure whether
> we need to clamp it for systems with TBs of memory.

Using nr_free_buffer_pages() is good-enough-for-now.  There are
questions around the name of this thing and its exact functionality and
whether callers are using it appropriately.  But if anything is changed
there, it will be as part of kernel-wide sweep.

One thing to bear in mind is memory hot[un]plug.  Anything which was
sized using nr_free_buffer_pages() (or similar) may become
inappropriately sized if memory is added or removed.  So any site which
uses nr_free_buffer_pages() really should be associated with a hotplug
handler and a great pile of code to resize the structure at runtime. 
It's pretty ugly stuff :(  I suspect it usually Just Doesn't Matter.

Redarding this patch:
net-change-type-of-netns_ipvs-sysctl_sync_qlen_max.patch and
net-fix-functions-and-variables-related-to-netns_ipvs-sysctl_sync_qlen_max.patch
are joined at the hip and should be redone as a single patch with a
suitable changelog, please.  And with a cc:netdev@...r.kernel.org.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/