linux-toradex.git, branch v3.10.14

Linux 3.10.14

2013-10-01T16:18:05+00:00

netfilter: ipset: Fix serious failure in CIDR tracking

2013-10-01T16:17:48+00:00

commit 2cf55125c64d64cc106e204d53b107094762dfdf upstream.

This fixes a serious bug affecting all hash types with a net element -
specifically, if a CIDR value is deleted such that none of the same size
exist any more, all larger (less-specific) values will then fail to
match. Adding back any prefix with a CIDR equal to or more specific than
the one deleted will fix it.

Steps to reproduce:
ipset -N test hash:net
ipset -A test 1.1.0.0/16
ipset -A test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS in set
ipset -D test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS NOT in set

This is due to the fact that the nets counter was unconditionally
decremented prior to the iteration that shifts up the entries. Now, we
first check if there is a proceeding entry and if not, decrement it and
return. Otherwise, we proceed to iterate and then zero the last element,
which, in most cases, will already be zero.

Signed-off-by: Oliver Smith 
Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Greg Kroah-Hartman

rpc: let xdr layer allocate gssproxy receieve pages

2013-10-01T16:17:48+00:00

commit d4a516560fc96a9d486a9939bcb567e3fdce8f49 upstream.

In theory the linux cred in a gssproxy reply can include up to
NGROUPS_MAX data, 256K of data.  In the common case we expect it to be
shorter.  So do as the nfsv3 ACL code does and let the xdr code allocate
the pages as they come in, instead of allocating a lot of pages that
won't typically be used.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: fix huge kmalloc's in gss-proxy

2013-10-01T16:17:48+00:00

commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be upstream.

The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will
take up more than a page.  We therefore need to allocate an array of
pages to hold the reply instead of trying to allocate a single huge
buffer.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: comment on linux_cred encoding, treat all as unsigned

2013-10-01T16:17:48+00:00

commit 6a36978e6931e6601be586eb313375335f2cfaa3 upstream.

The encoding of linux creds is a bit confusing.

Also: I think in practice it doesn't really matter whether we treat any
of these things as signed or unsigned, but unsigned seems more
straightforward: uid_t/gid_t are unsigned and it simplifies the ngroups
overflow check.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: clean up decoding of gssproxy linux creds

2013-10-01T16:17:48+00:00

commit 778e512bb1d3315c6b55832248cd30c566c081d7 upstream.

We can use the normal coding infrastructure here.

Two minor behavior changes:

	- we're assuming no wasted space at the end of the linux cred.
	  That seems to match gss-proxy's behavior, and I can't see why
	  it would need to do differently in the future.

	- NGROUPS_MAX check added: note groups_alloc doesn't do this,
	  this is the caller's responsibility.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

cfq: explicitly use 64bit divide operation for 64bit arguments

2013-10-01T16:17:48+00:00

commit f3cff25f05f2ac29b2ee355e611b0657482f6f1d upstream.

'samples' is 64bit operant, but do_div() second parameter is 32.
do_div silently truncates high 32 bits and calculated result
is invalid.

In case if low 32bit of 'samples' are zeros then do_div() produces
kernel crash.

Signed-off-by: Anatol Pomozov 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

bio-integrity: Fix use of bs->bio_integrity_pool after free

2013-10-01T16:17:48+00:00

commit adbe6991efd36104ac9eaf751993d35eaa7f493a upstream.

This fixes a copy and paste error introduced by 9f060e2231
("block: Convert integrity to bvec_alloc_bs()").

Found by Coverity (CID 1020654).

Signed-off-by: Bjorn Helgaas 
Acked-by: Kent Overstreet 
Signed-off-by: Jens Axboe 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

perf tools: Handle JITed code in shared memory

2013-10-01T16:17:48+00:00

commit 89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream.

Need to check for /dev/zero.

Most likely more strings are missing too.

Signed-off-by: Andi Kleen 
Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Vinson Lee 
Signed-off-by: Greg Kroah-Hartman

mm: fix aio performance regression for database caused by THP

2013-10-01T16:17:48+00:00

commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.

I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag.  It then
does aio into these pages from flash disks using various common block
sizes used by database.  I am looking at performance with two of the most
common block sizes - 1M and 64K.  aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:

		pre-THP		2.6.39		3.11-rc5
1M read		8384 MB/s	5629 MB/s	6501 MB/s
64K read	7867 MB/s	4576 MB/s	4251 MB/s

I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines.  perf top shows
>40% of cycles being spent in these two routines.  Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away.  THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page().  It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages.  This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.

Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see.  I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages.  This improved performance
significantly.  Performance numbers with this patch:

		pre-THP		3.11-rc5	3.11-rc5 + Patch
1M read		8384 MB/s	6501 MB/s	8371 MB/s
64K read	7867 MB/s	4251 MB/s	6510 MB/s

Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement.  It does mean there is more work to be done but I
will take a 53% improvement for now.

Please take a look at the following patch and let me know if it looks
reasonable.

[akpm@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz 
Cc: Pravin B Shelar 
Cc: Christoph Lameter 
Cc: Andrea Arcangeli 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Minchan Kim 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman