Preeti U Murthy | 21 Dec 11:38 2014
Picon

[RFC PATCH] drivers/intel_powerclamp : Redesign implementation of idle injection

The powerclamp driver injects idle periods to stay within the thermal constraints.
The driver does a fake idle by spawning per-cpu threads that call the mwait
instruction. This behavior of fake idle can confuse the other kernel subsystems.
For instance it calls into the nohz tick handlers, which are meant to be called
only by the idle thread. It sets the state of the tick in each cpu to idle and
stops the tick, when there are tasks on the runqueue. As a result the callers of
idle_cpu()/ tick_nohz_tick_stopped() see different states of the cpu; while the
former thinks that the cpu is busy, the latter thinks that it is idle. The outcome
may be  inconsistency in the scheduler/nohz states which can lead to serious
consequences. One of them was reported on this thread:
https://lkml.org/lkml/2014/12/11/365.

Thomas posted out a patch to disable the powerclamp driver from calling into the
tick nohz code which has taken care of the above regression for the moment. However
powerclamp driver as a result, will not be able to inject idle periods due to the
presence of periodic ticks. With the current design of fake idle, we cannot move
towards a better solution.
https://lkml.org/lkml/2014/12/18/169

This patch aims at removing the concept of fake idle and instead makes the cpus
truly idle by throttling the runqueues during the idle injection periods. The situation
is in fact very similar to throttling cfs_rqs when they exceed their bandwidths.
The exception here is that the root cfs_rq is throttled in the presence of available
bandwidth, due to the need to force idle. The runqueues automatically get unthrottled
at all other times and call to reschedule is made. Per-cpu timers are queued to expire
after every active/idle periods of powerclamp driver, which decide whether to throttle
or unthrottle the runqueues. This way, the tick nohz state and the scheduler states of
the cpus are sane during the idle injection periods because they naturally fall in place.

Another point to note is that the scheduler_tick() is called after the timers are
(Continue reading)

Gangadhar Vukkesala | 21 Dec 09:32 2014
Picon

[PATCH] kernel: fixed a space coding style issue

fixed a space coding style issue in pid.c which was found when
running checkpatch.pl on pid.c

Signed-off-by: Gangadhar Vukkesala <gangs.freelancer <at> gmail.com>
---
 kernel/pid.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/pid.c b/kernel/pid.c
index cd36a5e..ad9d780 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
 <at>  <at>  -72,7 +72,7  <at>  <at>  struct pid_namespace init_pid_ns = {
 		.refcount       = ATOMIC_INIT(2),
 	},
 	.pidmap = {
-		[ 0 ... PIDMAP_ENTRIES-1] = { ATOMIC_INIT(BITS_PER_PAGE), NULL }
+		[0 ... PIDMAP_ENTRIES-1] = { ATOMIC_INIT(BITS_PER_PAGE), NULL }
 	},
 	.last_pid = 0,
 	.nr_hashed = PIDNS_HASH_ADDING,
 <at>  <at>  -267,7 +267,7  <at>  <at>  void free_pid(struct pid *pid)
 		struct upid *upid = pid->numbers + i;
 		struct pid_namespace *ns = upid->ns;
 		hlist_del_rcu(&upid->pid_chain);
-		switch(--ns-≥nr_hashed) {
+		switch (--ns-≥nr_hashed) {
 		case 2:
 		case 1:
 			/* When all that is left in the pid namespace
(Continue reading)

Eddie Kovsky | 21 Dec 06:27 2014

[PATCH] staging: vt6655: fix sparse warning: argument type

Fixes following warning generated by sparse:

drivers/staging/vt6655/baseband.c:2180:45: warning: incorrect type in argument 1 (different
address spaces)
drivers/staging/vt6655/baseband.c:2180:45:    expected struct vnt_private *priv
drivers/staging/vt6655/baseband.c:2180:45:    got void [noderef] <asn:2>*dwIoBase

Compile tested on next-20141219.

Signed-off-by: Eddie Kovsky <ewk <at> edkovsky.org>
---
 drivers/staging/vt6655/baseband.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/baseband.c b/drivers/staging/vt6655/baseband.c
index 86c72ba0a0cd..f8c5fc371c4c 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
 <at>  <at>  -2177,7 +2177,7  <at>  <at>  bool BBbVT3253Init(struct vnt_private *priv)
 		/* Init ANT B select,RX Config CR10 = 0x28->0x2A, 0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B
inverted) */
 		/*bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/
 		/* Select VC1/VC2, CR215 = 0x02->0x06 */
-		bResult &= BBbWriteEmbedded(dwIoBase, 0xd7, 0x06);
+		bResult &= BBbWriteEmbedded(priv, 0xd7, 0x06);
 		/* }} */

 		for (ii = 0; ii < CB_VT3253B0_AGC; ii++)
--

-- 
2.1.0
(Continue reading)

Gangadhar Vukkesala | 21 Dec 04:39 2014
Picon

[PATCH] kernel: removed unnecessary initialization of static variable

Removed unnecessary initialization of static variable "zero" to 0 
in pid_namespace.c as default value of static variable is 0.
This issue was found when running checkpatch.pl script on pid_namespace.c.

Signed-off-by: Gangadhar Vukkesala <gangs.freelancer <at> gmail.com>
---
 kernel/pid_namespace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index a65ba13..f21eb3f 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
 <at>  <at>  -290,7 +290,7  <at>  <at>  static int pid_ns_ctl_handler(struct ctl_table *table, int write,
 }

 extern int pid_max;
-static int zero = 0;
+static int zero;
 static struct ctl_table pid_ns_ctl_table[] = {
 	{
 		.procname = "ns_last_pid",
--

-- 
Gangadhar Vukkesala

Andy Lutomirski | 21 Dec 04:31 2014
Picon

Cleaning up the KVM clock

I'm looking at the vdso timing code, and I'm puzzled by the pvclock
code.  My motivation is comprehensibility, performance, and
correctness.

# for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done
10000000 loops in 0.69138s = 69.14 nsec / loop
10000000 loops in 0.63614s = 63.61 nsec / loop
10000000 loops in 0.63213s = 63.21 nsec / loop
10000000 loops in 0.63087s = 63.09 nsec / loop
10000000 loops in 0.63079s = 63.08 nsec / loop
10000000 loops in 0.63096s = 63.10 nsec / loop
10000000 loops in 0.63096s = 63.10 nsec / loop
10000000 loops in 0.63062s = 63.06 nsec / loop
10000000 loops in 0.63100s = 63.10 nsec / loop
10000000 loops in 0.63112s = 63.11 nsec / loop
bash-4.3# echo tsc
>/sys/devices/system/clocksource/clocksource0/current_clocksource
[   45.957524] Switched to clocksource tsc
bash-4.3# for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0;
done10000000 loops in 0.33583s = 33.58 nsec / loop
10000000 loops in 0.28530s = 28.53 nsec / loop
10000000 loops in 0.28904s = 28.90 nsec / loop
10000000 loops in 0.29001s = 29.00 nsec / loop
10000000 loops in 0.28775s = 28.78 nsec / loop
10000000 loops in 0.30102s = 30.10 nsec / loop
10000000 loops in 0.28006s = 28.01 nsec / loop
10000000 loops in 0.28584s = 28.58 nsec / loop
10000000 loops in 0.28175s = 28.17 nsec / loop
10000000 loops in 0.28724s = 28.72 nsec / loop

(Continue reading)

Linus Torvalds | 21 Dec 02:43 2014

Linux 3.19-rc1 - merge window closed

So it's been a day less than two weeks, and the merge window is closed.

Considering how much came in fairly late, I find it hard to care about
anybody who had decided to cut it even closer than some people already
did.   That said, maybe there aren't any real stragglers - and judging
by the size of rc1, there really can't have been much. Not only do I
think there are more commits than there were in linux-next, this is
one of the bigger rc1's (at least by commits) historically. We've had
bigger ones (3.10 and 3.15 both had large merge windows leading up to
them), but this was definitely not a small merge window.

Anyway, we've got changes all over the place, including a new
architecture (nios2). My "short mergelog" is appended, and as usual I
want to point out that that credits the people sending me the changes,
which is generally not necessarily at all the same thing as the people
actually writing the code, even if there is obviously overlap.

In the "big picture", this looks like a fairly normal release. About
two thirds driver updates, with about half of the rest being
architecture updates (and no, the new nios2 patches are not at all
dominant, it's about half ARM, with  the new nios2 support being less
than 10% of the arch updates by lines overall). The remaining one
sixth is "misc": networking, header updates, documentation,
filesystems, tooling, and core kernel (in pretty much that order).

Obviously, with the holidays coming up, I'd expect that the next few
weeks are pretty quiet, but we'll see. I do hope that people will have
time to test this all in between all the eggnog,

                              Linus
(Continue reading)

Andy Lutomirski | 21 Dec 02:11 2014
Picon

[GIT PULL] one vdso fix for x86/urgent

Hi Ingo, etc,

Please consider pulling for x86/urgent.  This fixes a longstanding,
albeit relatively minor, issue in the x86 vdso randomization
algorithm.  Note that this isn't super-urgent, as this bug isn't
directly exploitable, and it's as old as the vdso itself.

Thanks,
Andy

The following changes since commit e589c9e13aeb0c5539bf1314b3a78442ea8fc0c2:

  Merge branch 'x86-apic-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2014-12-19
14:02:02 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git
tags/pr-20141220-x86-vdso

for you to fetch changes up to 394f56fe480140877304d342dec46d50dc823d46:

  x86_64, vdso: Fix the vdso address randomization algorithm
(2014-12-20 16:56:57 -0800)

----------------------------------------------------------------
One vdso fix for a longstanding ASLR bug that's been in the news lately.

The vdso base address has always been randomized, and I don't think there's
(Continue reading)

Rickard Strandqvist | 21 Dec 01:37 2014
Picon

[PATCH] net: wireless: brcm80211: brcmsmac: phy: phy_n.c: Remove unused function

Remove the function wlc_phy_txpwr_idx_get_nphy() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist <at> spectrumdigital.se>
---
 .../net/wireless/brcm80211/brcmsmac/phy/phy_int.h   |    1 -
 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c |   19 -------------------
 2 files changed, 20 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
index 4960f7d..c3d4f17 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
 <at>  <at>  -1104,7 +1104,6  <at>  <at>  void wlc_phy_txpwrctrl_enable_nphy(struct brcms_phy *pi, u8 ctrl_type);
 void wlc_phy_txpwr_fixpower_nphy(struct brcms_phy *pi);
 void wlc_phy_txpwr_apply_nphy(struct brcms_phy *pi);
 void wlc_phy_txpwr_papd_cal_nphy(struct brcms_phy *pi);
-u16 wlc_phy_txpwr_idx_get_nphy(struct brcms_phy *pi);

 struct nphy_txgains wlc_phy_get_tx_gain_nphy(struct brcms_phy *pi);
 int wlc_phy_cal_txiqlo_nphy(struct brcms_phy *pi,
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
index 084f18f..44cb2f0 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
 <at>  <at>  -28257,25 +28257,6  <at>  <at>  static bool wlc_phy_txpwr_ison_nphy(struct brcms_phy *pi)
 					    (0x1 << 14) | (0x1 << 13));
 }

(Continue reading)

Richard | 21 Dec 01:08 2014
Picon

Kernel 3.17.x Attaching Keyspan 4-Port Serial to USB Adapter Causes Kernel Panic

On a new Gentoo based system with Kernel.org Kernels 3.17.4 to 3.17.7
when I physically plug the Keyspan 4-Port Serial to USB adapter into a
usb port my system freezes with a "unable to handle kernel NULL pointer
deference" message.

My old system (also Gentoo based with Kernel.org 3.17.4) does not have
this issue.  Both systems are using the USB_SERIAL_KEYSPAN_USA49W
driver module.

I tried booting into single user mode, using modprobe to load
USB_SERIAL_KEYSPAN_USA49W.  lsmod shows the driver.  When I pluged the
device in I receive the system freeze.  Below is what I copied off the
console ...

BUG:  Unable to handle kernel NULL pointer deference at 000...8c
IP: [<ffffffffa006fbdd>] usa49_instat_callback+0x4d/0xb0[keyspan]
PGD 1037faa067 PUD 1038301067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: keyspan ezusb usbserial hid_generic ...

...

Hardware name:  ASUS All Series/X99-A,  BIOS 1004 10/16/2014

If I can provide any more information, please ask.

Please CC my e-mail address with any replies, I do not subscribe to the
linux kernel list:   richjunk <at> pacbell.net

Richard
(Continue reading)

Rickard Strandqvist | 21 Dec 01:09 2014
Picon

[PATCH v2] net: wireless: brcm80211: brcmsmac: phy: phy_cmn.c: Remove some unused functions

Removes some functions that are not used anywhere:
wlc_phy_edcrs_lock() wlc_phy_txpower_ipa_ison() wlc_phy_upd_rssi_offset()
wlc_phy_get_pwrdet_offsets() wlc_lcnphy_epa_switch() wlc_phy_stf_ssmode_get()
wlc_phy_stf_chain_get() write_phy_channel_reg() wlc_phy_BSSinit()
wlc_phy_set_deaf() wlc_phy_freqtrack_end() wlc_phy_freqtrack_start()
wlc_phy_noise_sample_request_external() wlc_phy_test_ison()
wlc_phy_txpower_hw_ctrl_set() wlc_phy_bf_preempt_enable()
wlc_phy_runbist_config() wlc_phy_txpwr_percent_set()
wlc_phy_txpower_get_target_max() wlc_radioreg_exit()
wlc_phy_txpower_get_target_min() wlc_phy_txpower_boardlimit_band()
wlc_phy_txpower_sromlimit_max_get() wlc_radioreg_enter()
wlc_phy_txpower_target_set() wlc_phy_chanspec_band_firstch()
wlc_phy_chanspec_bandrange_get() wlc_phy_bw_state_get() wlc_phy_clear_tssi()

This was partially found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist <at> spectrumdigital.se>
---
 .../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c  |  433 --------------------
 .../net/wireless/brcm80211/brcmsmac/phy/phy_hal.h  |   29 --
 .../net/wireless/brcm80211/brcmsmac/phy/phy_int.h  |    9 -
 3 files changed, 471 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 941b1e4..af428bb 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
 <at>  <at>  -138,23 +138,6  <at>  <at>  void wlc_phyreg_exit(struct brcms_phy_pub *pih)
 	wlapi_bmac_ucode_wake_override_phyreg_clear(pi->sh->physhim);
 }
(Continue reading)

Rickard Strandqvist | 21 Dec 00:09 2014
Picon

[PATCH] scsi: gdth_proc.c: Remove unused function

Remove the function gdth_ioctl_check_bin() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist <at> spectrumdigital.se>
---
 drivers/scsi/gdth_proc.c |   18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/drivers/scsi/gdth_proc.c b/drivers/scsi/gdth_proc.c
index 9fb6326..efb9df5 100644
--- a/drivers/scsi/gdth_proc.c
+++ b/drivers/scsi/gdth_proc.c
 <at>  <at>  -598,24 +598,6  <at>  <at>  static void gdth_ioctl_free(gdth_ha_str *ha, int size, char *buf, u64 paddr)
     }
 }

-#ifdef GDTH_IOCTL_PROC
-static int gdth_ioctl_check_bin(gdth_ha_str *ha, u16 size)
-{
-    unsigned long flags;
-    int ret_val;
-
-    spin_lock_irqsave(&ha->smp_lock, flags);
-
-    ret_val = FALSE;
-    if (ha->scratch_busy) {
-        if (((gdth_iord_str *)ha->pscratch)->size == (u32)size)
-            ret_val = TRUE;
-    }
(Continue reading)


Gmane