Tejun Heo | 2 Jul 02:52 2015

[PATCH 1/2 block/for-linus] writeback: don't embed root bdi_writeback_congested in bdi_writeback

52ebea749aae ("writeback: make backing_dev_info host cgroup-specific
bdi_writebacks") made bdi (backing_dev_info) host per-cgroup wb's
(bdi_writeback's).  As the congested state needs to be per-wb and
referenced from blkcg side and multiple wbs, the patch made all
non-root cong's (bdi_writeback_congested's) reference counted and
indexed on bdi.

When a bdi is destroyed, cgwb_bdi_destroy() tries to drain all
non-root cong's; however, this can hang indefinitely because wb's can
also be referenced from blkcg_gq's which are destroyed after bdi
destruction is complete.

To fix the bug, bdi destruction will be updated to not wait for cong's
to drain, which naturally means that cong's may outlive the associated
bdi.  This is fine for non-root cong's but is problematic for the root
cong's which are embedded in their bdi's as they may end up getting
dereferenced after the containing bdi's are freed.

This patch makes root cong's behave the same as non-root cong's.  They
are no longer embedded in their bdi's but allocated separately during
bdi initialization, indexed and reference counted the same way.

* As cong handling is the same for all wb's, wb->congested
  initialization is moved into wb_init().

* When !CONFIG_CGROUP_WRITEBACK, there was no indexing or refcnting.
  bdi->wb_congested is now a pointer pointing to the root cong
  allocated during bdi init and minimal refcnting operations are

(Continue reading)

Oleg Nesterov | 2 Jul 01:02 2015

[PATCH v2 0/5] mremap fix/cleanups

Actually this is resend, not v2. Added the acks I got from David

2/5 (acked by Pavel and Kirill) was sent separately and ignored
too, I think it fits this series.

(and I think that the recently added arch_remap() hook is not
 the right thing, we can remove it with these changes).

Andrew, should I resend the

	[PATCH 0/3] special_mapping_fault() is broken

series too?


Mark Brown | 2 Jul 00:54 2015

[PATCH] regmap: Silence warning on invalid zero length read

Zero length reads make no sense in a regmap context and are likely to
trigger bugs further down the stack so insert an error check, also
silencing compiler warnings about use of ret in cases where we iterate
per register.

Reported-by: Russell King <linux <at> arm.linux.org.uk>
Signed-off-by: Mark Brown <broonie <at> kernel.org>

Not even compile tested yet.

 drivers/base/regmap/regmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 7111d04f2621..db1102e9c34d 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
 <at>  <at>  -2179,6 +2179,8  <at>  <at>  int regmap_raw_read(struct regmap *map, unsigned int reg, void *val,
 		return -EINVAL;
 	if (reg % map->reg_stride)
 		return -EINVAL;
+	if (val_count == 0)
+		return -EINVAL;




(Continue reading)

Matteo Croce | 2 Jul 00:53 2015

[PATCH] add stealth mode

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Dest-Unreach for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.
 include/linux/inetdevice.h | 1 +
 include/linux/ipv6.h       | 1 +
 include/uapi/linux/ip.h    | 1 +
 net/ipv4/devinet.c         | 1 +
 net/ipv4/icmp.c            | 6 ++++++
 net/ipv4/tcp_ipv4.c        | 3 ++-
 net/ipv4/udp.c             | 4 +++-
 net/ipv6/addrconf.c        | 7 +++++++
 net/ipv6/icmp.c            | 3 ++-
 net/ipv6/tcp_ipv6.c        | 2 +-
 net/ipv6/udp.c             | 3 ++-
 11 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index a4328ce..a64c01e 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
 <at>  <at>  -128,6 +128,7  <at>  <at>  static inline void ipv4_devconf_setall(struct
in_device *in_dev)
 #define IN_DEV_ARP_IGNORE(in_dev) IN_DEV_MAXCONF((in_dev), ARP_IGNORE)
 #define IN_DEV_ARP_NOTIFY(in_dev) IN_DEV_MAXCONF((in_dev), ARP_NOTIFY)
+#define IN_DEV_STEALTH(in_dev) IN_DEV_MAXCONF((in_dev), STEALTH)

 struct in_ifaddr {
(Continue reading)

Vikas Shivappa | 2 Jul 00:21 2015

[PATCH V12 0/9] Hot cpu handling changes to cqm, rapl and Intel Cache Allocation support

This patch has some changes to hot cpu handling code in existing cache
monitoring and RAPL kernel code. This improves hot cpu notification
handling by not looping through all online cpus which could be expensive
in large systems. 

Cache allocation patches(dependent on prep patches) adds a cgroup
subsystem to support the new Cache Allocation feature found in future
Intel Xeon Intel processors. Cache Allocation is a sub-feature with in
Resource Director Technology(RDT) feature. RDT which provides support to
control sharing of platform resources like L3 cache.

Cache Allocation Technology provides a way for the Software (OS/VMM) to
restrict cache allocation to a defined 'subset' of cache which may be
overlapping with other 'subsets'.  This feature is used when allocating
a line in cache ie when pulling new data into the cache.  The
programming of the h/w is done via programming  MSRs.  The patch series
support to perform L3 cache allocation.

In todays new processors the number of cores is continuously increasing
which in turn increase the number of threads or workloads that can
simultaneously be run. When multi-threaded applications run
concurrently, they compete for shared resources including L3 cache.  At
times, this L3 cache resource contention may result in inefficient space
utilization. For example a higher priority thread may end up with lesser
L3 cache resource or a cache sensitive app may not get optimal cache
occupancy thereby degrading the performance.  Cache Allocation kernel
patch helps provides a framework for sharing L3 cache so that users can
allocate the resource according to set requirements.

More information about the feature can be found in the Intel SDM, Volume
(Continue reading)

Shaun Ruffell | 1 Jul 23:30 2015

Re: [igb] AER timeout - resend.

On Wed, Jul 01, 2015 at 11:18:36PM +0200, Ian Kumlien wrote:
> It was actually fixed with a bios upgrade from Super Micro (in this case)
> so I'd investigate that first... =)

Hmm...interesting. Thanks for the reply!
Arnaldo Carvalho de Melo | 1 Jul 23:23 2015

[GIT PULL 0/8] perf/core fixes

Hi Ingo,

	Please consider pulling,

- Arnaldo

The following changes since commit 93472aff802fd7b61f2209335207e9bd793012f7:

  perf/x86: Fix 'active_events' imbalance (2015-06-30 13:08:46 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo

for you to fetch changes up to 5ef7bbb09f7b91ef06524c72e1ab1fc48e0d6682:

  perf tools: Allow to specify custom linker command (2015-07-01 17:53:50 -0300)

perf/core fixes:

Build fixes:

- Create config.detected into OUTPUT directory, fixing parallel
  builds sharing the same source directory (Aaro Kiskinen)

- Allow to specify custom linker command, fixing some MIPS64
  builds. (Aaro Kiskinen)

(Continue reading)

Alexey Khoroshilov | 1 Jul 23:23 2015

[PATCH] umem: don't return zero on failure paths in mm_pci_probe()

If pci_alloc_consistent() or blk_alloc_queue() failed,
mm_pci_probe() breaks off initialization, deallocates
resources, but returns zero.

The patch adds -ENOMEM as a return value in these cases.
By the way, it adds blk_cleanup_queue() and pci_disable_device()
to fix leaks in failure handling code.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov <at> ispras.ru>
 drivers/block/umem.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 4cf81b5bf0f7..960a3cadcd6b 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
 <at>  <at>  -808,12 +808,14  <at>  <at>  static int mm_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0xF8);

-	card->dev         = dev;
+	card->dev = dev;

 	csr_base = pci_resource_start(dev, 0);
 	csr_len  = pci_resource_len(dev, 0);
-	if (!csr_base || !csr_len)
-		return -ENODEV;
(Continue reading)

Davidlohr Bueso | 1 Jul 22:29 2015

[PATCH -tip v2 1/2] locking/rtmutex: Support spin on owner

Similar to what we have in other locks, particularly regular mutexes, the
idea is that as long as the owner is running, there is a fair chance it'll
release the lock soon, and thus a task trying to acquire the rtmutex will
better off spinning instead of blocking immediately after the fastpath.
Conditions to stop spinning and enter the slowpath are simple:

(1) Upon need_resched()
(2) Current lock owner blocks

Because rtmutexes track the lock owner atomically, we can extend the fastpath
to continue polling on the lock owner via cmpxchg(lock->owner, NULL, current).

However, this is a conservative approach, such that if there are any waiters
in-line, we stop spinning and immediately take the traditional slowpath. This
allows priority boosting to take precedence over spinning, as otherwise we
could starve a higher priority queued-up task (ie: top waiter) if spinners
constantly steal the lock. This is done by locklesly checking the rbtree
for any waiters (which is safe as if we race all we do is iterate again).
Obviously this means that spinners ignore the "has waiters" flag/bit and thus
tasks can extend their spinning time until the first task queues itself into
the tree. In addition, tasks that failed their spinning and are in the slowpath
still sync with tasks unlocking, respecting try_to_take_rt_mutex() -- spinning
only allows possible lock stealing. Because this of its rt nature, there is
only limited benefits of this approach, as most systems that really need
real-time locks will commonly end up boosting prio, which means we have queued

Passes futextests and was seen to improve total inversions performed on a 60-core
box running pi_stress (with a 10 minute window) in ~5% -- which given the program
characteristics, is a non-trivial speed up). More importantly, it shows that we
(Continue reading)

Borislav Petkov | 1 Jul 22:14 2015

[PATCH 0/2] x86/microcode/amd: Do not overwrite specific patch levels

From: Borislav Petkov <bp <at> suse.de>

Certain patch levels supplied by the BIOS should not be upgraded and
overwritten by the microcode loader because doing so leaves the system
dead in the water.

The two below provide for filtering out those levels and avoiding the
update, thereby making those patch levels final.

Borislav Petkov (2):
  x86/microcode/amd: Extract current patch level read to a function
  x86/microcode/amd: Do not overwrite final patch levels

 arch/x86/include/asm/microcode_amd.h      |  1 +
 arch/x86/kernel/cpu/microcode/amd.c       | 52 +++++++++++++++++++++++++++++--
 arch/x86/kernel/cpu/microcode/amd_early.c | 24 ++++++++------
 3 files changed, 65 insertions(+), 12 deletions(-)



Alexey Dobriyan | 1 Jul 22:04 2015

[PATCH] proc: fixup empty ARGV case for /proc/$PID/cmdline

/proc/*/cmdline code checks if it should look at ENVP area by checking
last byte of ARGV area:

	rv = access_remote_vm(mm, arg_end - 1, &c, 1, 0);
	if (rv <= 0)
		goto out_free_page;

If ARGV is somehow made empty (by doing execve(..., NULL, ...) or
manually setting ->arg_start and ->arg_end to equal values), the decision
will be based on byte which doesn't even belong to ARGV/ENVP.

So, quickly check if ARGV area is empty and report 0 to match previous

Signed-off-by: Alexey Dobriyan <adobriyan <at> gmail.com>

 fs/proc/base.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
 <at>  <at>  -243,6 +243,11  <at>  <at>  static ssize_t proc_pid_cmdline_read(struct file *file, char __user *buf,
 	len1 = arg_end - arg_start;
 	len2 = env_end - env_start;

+	/* Empty ARGV. */
+	if (len1 == 0) {
+		rv = 0;
+		goto out_free_page;
(Continue reading)