Re: [PATCH v2 03/26] clk: Add regmap support
On 01/14, Maxime Ripard wrote:
> From: Matthias Brugger
>
> Some devices like SoCs from Mediatek need to use the clock
> through a regmap interface.
> This patch adds regmap support for the simple multiplexer clock,
> the divider clock and the clock gate code.
>
> Signed-off-by: Matthias Brugger
> Signed-off-by: Maxime Ripard
Nak.
The whole anonymous union thing and clk-io.c file is not
appealing at all. I'd prefer we remove clk_readl/writel, not add
to it. Plus we're bloating the basic clock types and adding a
bunch of parallel registration APIs to assign a regmap pointer.
Really, let's stop adding stuff to the basic clock types, it's
getting out of hand.
To move forward on making regmap clks generic for everyone, let's
make sure that regmap clk code is a library that any driver can
use. No OF_CLK_DECLARE should exist because it doesn't make any
sense. No clk_register_regmap_{div,mux,gate}() functions, just a
clk_register_regmap() function to assign the regmap pointer from
the device. Drivers that want to use the code should need to
select a Kconfig symbol, so that we don't compile in support for
regmap clocks unless we really need them.
If we had a clk_regmap structure with a regmap pointer and a
clk_hw inside it I think that's all we would need. Once we had
that, we could let driver writers wrap that in their own
structures for dividers, muxes, gates, etc. and then have them
call library functions from their clk_ops that takes a regmap (or
clk_regmap struct), and offset to do the get_div/set_div,
get_parent/set_parent, enable/disable stuff.
The policy part can be shared with the basic clock types, because
we've already started libifying them. For example, we can ask the
divider code what the hardware value should be for a particular
divider type and it will tell us without writing any registers.
I had a patch for libifying muxes, not sure where it went. The
point being to leave the I/O part to the regmap code without
putting it behind another layer of indirection buried inside the
basic types. Make things flat and easy to follow.
I haven't thought through making new structs to hold the data for
offsets, masks, etc. but I guess we would want those so that we
could assign functions directly to clk_ops and not require any
boiler plate clk_ops implementations in drivers. There are a few
approaches here: different regmap structs for different basic
types, one mega struct that combines all the needs of the basic
types, or some private void pointer inside struct clk_regmap that
points to different basic type structs. Let's see how that goes.
Maybe we can lift drivers/clk/qcom/clk-regmap.c up into the
drivers/clk/ directory too. In the qcom design I put the
enable/disable bits (gate functionality) directly into the
clk_regmap structure. That may need some more thought if it was
the right idea to force enable/disable on every regmap clock
though. If we remove that and introduce a clk_regmap_gate things
should turn out alright.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v1 2/8] mm, kasan: SLAB support
On Wed, Jan 27, 2016 at 07:25:07PM +0100, Alexander Potapenko wrote:
> This patch adds KASAN hooks to SLAB allocator.
>
> This patch is based on the "mm: kasan: unified support for SLUB and
> SLAB allocators" patch originally prepared by Dmitry Chernenkov.
>
> Signed-off-by: Alexander Potapenko
> ---
> Documentation/kasan.txt | 5 ++-
...
> +#ifdef CONFIG_SLAB
> +struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> + const void *object)
> +{
> + return (void *)object + cache->kasan_info.alloc_meta_offset;
> +}
> +
> +struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> + const void *object)
> +{
> + return (void *)object + cache->kasan_info.free_meta_offset;
> +}
> +#endif
I cannot find the place to store stack info for free. get_free_info()
isn't used except print_object(). Plese let me know where.
Thanks.
Re: [PATCH v1 5/8] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB
Hello, On Wed, Jan 27, 2016 at 07:25:10PM +0100, Alexander Potapenko wrote: > Stack depot will allow KASAN store allocation/deallocation stack traces > for memory chunks. The stack traces are stored in a hash table and > referenced by handles which reside in the kasan_alloc_meta and > kasan_free_meta structures in the allocated memory chunks. Looks really nice! Could it be more generalized to be used by other feature that need to store stack trace such as tracepoint or page owner? If it could be, there is one more requirement. I understand the fact that entry is never removed from depot makes things very simpler, but, for general usecases, it's better to use reference count and allow to remove. Is it possible? Thanks.
[PATCH V8 1/1] usb:serial: Add Fintek F81532/534 driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. F81532 spec: https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp=sharing F81534 spec: https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?usp=sharing F81438 transceiver spec: http://www.alldatasheet.com/datasheet-pdf/pdf/459082/FINTEK/F81438.html Features: 1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can do auto-direction control by user-space tool. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). It's also controlled by user-space tool. 5. User-space tool will save the configuration in internal storage and the IC will read it when power on or driver loaded. Please reference https://bitbucket.org/hpeter/fintek-general/src/ with f81534/tools to get user-space tool to change F81532/534 setting. Please use it carefully. Signed-off-by: Peter Hung --- Changelog: v8 1. Remove driver mode GPIOLIB & RS485 control support, the driver will only load GPIO/UART Mode when driver attach() & port_probe(). 2. Add more documents for 3 generation IC with f81534_calc_num_ports(). 3. Simplify the GPIO register structure "f81534_pin_control". 4. Change all counter type from int to size_t. 5. Change some failed message with failed: "status code" and remove all exclamation mark in messages. 6. Change all save blocks to block0 due to the driver is only used 1 block (block0) to save data. 7. Change read MSR in open() instead of port_probe(). 8. use GFP_ATOMIC kmalloc mode in write(). 9. Maintain old style with 1 read URBs and 4 write URBs like mxuports.c I had tested with submit 4 read URBs, but it'll make some port freeze when doing BurnInTest Port test. v7 1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block. Due to F81532/534 could run without gpiolib, we implements f81534_prepare_gpio()/f81534_release_gpio() always success without CONFIG_GPIOLIB. 2. Fix crash when receiving MSR change on driver load/unload. It's cause by f81534_process_read_urb() get read URB callback data, but port private data is not init complete or released. We solve with 2 modifications. 1. add null pointer check with f81534_process_read_urb(). We'll skip this report when port_priv = NULL. 2. when "one" port f81534_port_remove() is called, kill the port-0 read URB before kfree port_priv. v6 1. Re-implement the write()/resume() function. Due to this device cant be suitable with generic write(), we'll do the submit write URB when write()/received tx empty/set_termios()/resume() 2. Logic/Phy Port mapping rewrite in f81534_port_probe() & f81534_phy_to_logic_port(). 3. Introduced "Port Hide" function. Some customer use F81532 reference design for HW layout, but really use F81534 IC. We'll check F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do port hide with port not used. It can be avoid end-user to use not layouted port. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So we decide to implement with gpiolib interface. 5. Add device vendor id with 0x2c42 v5 1. Change f81534_port_disable/enable() from H/W mode to S/W mode It'll skip all rx data when port is not opened. 2. Some function modifier add with static (Thanks for Paul Bolle) 3. It's will direct return when count=0 in f81534_write() to reduce spin_lock usage. v4 1. clearify f81534_process_read_urb() with f81534_process_per_serial_block(). (referenced from mxuport.c) 2. We limited f81534_write() max tx kfifo with 124Bytes. Original subsystem is designed for auto tranmiting fifo data if available. But we must wait for tx_empty for next tx data (H/W design). With this kfifo size limit, we can use generic subsystem api with f81534_write(). When usb_serial_generic_write_start() called after first write URB complete, the fifo will no data. The generic subsystem of write will go to idle state. Until we received TX_EMPTY and release write spinlock, the fifo will fill max 124Bytes by following f81534_write(). v3 1. Migrate read, write and some routine from custom code to usbserial subsystem callback function. 2. Use more defines to replece magic numbers to make it meaningful 3. Make more comments as document in source code. v2 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code & re-submit it to
[PATCH v7 5/6] cpufreq: powernv: Replace pr_info with trace print for throttle event
Currently we use printk message to notify the throttle event. But this
can flood the console if the cpu is throttled frequently. So replace the
printk with the tracepoint to notify the throttle event. And also events
like throttle below nominal frequency and OCC_RESET are reduced to
pr_warn/pr_warn_once as pointed by MFG to not mark them as critical
messages. This patch adds 'throttle_reason' to struct chip to store the
throttle reason.
Signed-off-by: Shilpasri G Bhat
---
Changes from v6:
- Rename struct chip member 'throt_reason' to 'throttle_reason'
No changes from v5.
Changes from v4:
- Taken care of Gautham's comments to remove the new function
powernv_cpufreq_check_pmax()
- Modified commit message
Changes from v3:
- Separate this patch to contain trace_point changes
- Move struct chip member 'restore' of type bool above 'mask' to reduce
structure padding.
No changes from v2.
Changes from v1:
- As suggested by Paul Clarke replaced char * throttle_reason[][30] by
const char * const throttle_reason[].
drivers/cpufreq/powernv-cpufreq.c | 73 ++-
1 file changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index c670314..1bbc10a 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -45,12 +46,22 @@ static struct cpufreq_frequency_table
powernv_freqs[POWERNV_MAX_PSTATES+1];
static bool rebooting, throttled, occ_reset;
static unsigned int *core_to_chip_map;
+static const char * const throttle_reason[] = {
+ "No throttling",
+ "Power Cap",
+ "Processor Over Temperature",
+ "Power Supply Failure",
+ "Over Current",
+ "OCC Reset"
+};
+
static struct chip {
unsigned int id;
bool throttled;
+ bool restore;
+ u8 throttle_reason;
cpumask_t mask;
struct work_struct throttle;
- bool restore;
} *chips;
static int nr_chips;
@@ -331,17 +342,17 @@ static void powernv_cpufreq_throttle_check(void *data)
goto next;
chips[i].throttled = true;
if (pmsr_pmax < powernv_pstate_info.nominal)
- pr_crit("CPU %d on Chip %u has Pmax reduced below
nominal frequency (%d < %d)\n",
- cpu, chips[i].id, pmsr_pmax,
- powernv_pstate_info.nominal);
- else
- pr_info("CPU %d on Chip %u has Pmax reduced below turbo
frequency (%d < %d)\n",
- cpu, chips[i].id, pmsr_pmax,
- powernv_pstate_info.max);
+ pr_warn_once("CPU %d on Chip %u has Pmax reduced below
nominal frequency (%d < %d)\n",
+cpu, chips[i].id, pmsr_pmax,
+powernv_pstate_info.nominal);
+ trace_powernv_throttle(chips[i].id,
+ throttle_reason[chips[i].throttle_reason],
+ pmsr_pmax);
} else if (chips[i].throttled) {
chips[i].throttled = false;
- pr_info("CPU %d on Chip %u has Pmax restored to %d\n", cpu,
- chips[i].id, pmsr_pmax);
+ trace_powernv_throttle(chips[i].id,
+ throttle_reason[chips[i].throttle_reason],
+ pmsr_pmax);
}
/* Check if Psafe_mode_active is set in PMSR. */
@@ -359,7 +370,7 @@ next:
if (throttled) {
pr_info("PMSR = %16lx\n", pmsr);
- pr_crit("CPU Frequency could be throttled\n");
+ pr_warn("CPU Frequency could be throttled\n");
}
}
@@ -452,15 +463,6 @@ out:
put_online_cpus();
}
-static char throttle_reason[][30] = {
- "No throttling",
- "Power Cap",
- "Processor Over Temperature",
- "Power Supply Failure",
- "Over Current",
- "OCC Reset"
-};
-
static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
unsigned long msg_type, void *_msg)
{
@@ -486,7 +488,7 @@ static int powernv_cpufreq_occ_msg(struct notifier_block
*nb,
*/
if (!throttled) {
throttled = true;
- pr_crit("CPU frequency is throttled for duration\n");
+ pr_warn("CPU frequency is throttled for duration\n");
}
break;
@@ -510,23 +512,18 @@ static int powernv_cpufreq_occ_msg(struct notifier_block
*nb,
[PATCH v7 4/6] cpufreq: powernv/tracing: Add powernv_throttle tracepoint
This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
CC: Ingo Molnar
CC: Steven Rostedt
---
No changes since v2.
include/trace/events/power.h | 22 ++
kernel/trace/power-traces.c | 1 +
2 files changed, 23 insertions(+)
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..19e5030 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -38,6 +38,28 @@ DEFINE_EVENT(cpu, cpu_idle,
TP_ARGS(state, cpu_id)
);
+TRACE_EVENT(powernv_throttle,
+
+ TP_PROTO(int chip_id, const char *reason, int pmax),
+
+ TP_ARGS(chip_id, reason, pmax),
+
+ TP_STRUCT__entry(
+ __field(int, chip_id)
+ __string(reason, reason)
+ __field(int, pmax)
+ ),
+
+ TP_fast_assign(
+ __entry->chip_id = chip_id;
+ __assign_str(reason, reason);
+ __entry->pmax = pmax;
+ ),
+
+ TP_printk("Chip %d Pmax %d %s", __entry->chip_id,
+ __entry->pmax, __get_str(reason))
+);
+
TRACE_EVENT(pstate_sample,
TP_PROTO(u32 core_busy,
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index eb4220a..81b8745 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -15,4 +15,5 @@
EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume);
EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle);
+EXPORT_TRACEPOINT_SYMBOL_GPL(powernv_throttle);
--
1.9.3
[PATCH v7 6/6] cpufreq: powernv: Add sysfs attributes to show throttle stats
Create sysfs attributes to export throttle information in
/sys/devices/system/cpu/cpufreq/chipN. The newly added sysfs files are as
follows:
1)/sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
This gives the throttle stats for each of the available frequencies.
The throttle stat of a frequency is the total number of times the max
frequency is reduced to that frequency.
# cat /sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
4023000 0
399 0
3956000 1
3923000 0
389 0
3857000 2
3823000 0
379 0
3757000 2
3724000 1
369 1
...
2)/sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
This directory contains throttle reason files. Each file gives the
total number of times the max frequency is throttled, except for
'unthrottle_count', which gives the total number of times the max
frequency is unthrottled after being throttled.
# cd /sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
# cat cpu_over_temperature
7
# cat occ_reset
0
# cat over_current
0
# cat power_cap
0
# cat power_supply_failure
0
# cat unthrottle_count
7
3)/sys/devices/system/cpu/cpufreq/chip0/throttle_stat
This gives the total number of events of max frequency throttling to
lower frequencies in the turbo range of frequencies and the sub-turbo(at
and below nominal) range of frequencies.
# cat /sys/devices/system/cpu/cpufreq/chip0/throttle_stat
turbo 7
sub-turbo 0
Signed-off-by: Shilpasri G Bhat
Cc: linux-...@vger.kernel.org
---
Changes from v6:
- Rename struct chip members 'throt_{nominal/turbo}' to throttle_*
- Rename sysfs throttle_reason attribute 'throttle_reset' to
'unthrottle_count'
- Add sysfs attribute details in
Documentation/ABI/testing/sysfs-devices-system-cpu
- Add helper routine get_chip_index_from_kobj() for throttle sysfs
attribute show() to get chip index from kobject.
- Add the chip id in the pr_warn_once
No changes from v5.
Changes from v4:
- Taken care of Gautham's comments to use inline get_chip_index()
Changes from v3:
- Seperate the patch to contain only the throttle sysfs attribute changes.
- Add helper inline function get_chip_index()
Changes from v2:
- Fixed kbuild test warning.
drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return
value of 'kstrtoint', declared with attribute warn_unused_result
[-Wunused-result]
Changes from v1:
- Added a kobject to struct chip
- Grouped the throttle reasons under a separate attribute_group and
exported each reason as individual file.
- Moved the sysfs files from /sys/devices/system/node/nodeN to
/sys/devices/system/cpu/cpufreq/chipN
- As suggested by Paul Clarke replaced 'Nominal' with 'sub-turbo'.
Documentation/ABI/testing/sysfs-devices-system-cpu | 45 +
drivers/cpufreq/powernv-cpufreq.c | 205 -
2 files changed, 241 insertions(+), 9 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index b683e8e..dea4620 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -271,3 +271,48 @@ Description: Parameters for the CPU cache attributes
- WriteBack: data is written only to the cache line and
the modified cache line is written to main
memory only when it is replaced
+
+What: /sys/devices/system/cpu/cpufreq/chip*/throttle_stats
+Date: Jan 2016
+Contact: Linux kernel mailing list
+ Linux for PowerPC mailing list
+Description: CPU Frequency throttle stat for the chip
+
+ This attribute gives the total number of events of max-frequency
+ throttling to any lower frequency in the turbo(above nominal)
and
+ the sub-turbo (at and below nominal) range of frequencies.
+
+
+What: /sys/devices/system/cpu/cpufreq/chip*/throttle_frequencies
+Date: Jan 2016
+Contact: Linux kernel mailing list
+ Linux for PowerPC mailing list
+Description: CPU Frequency throttle stat for all available frequencies in
the chip
+
+ This attribute gives the throttle stats for each of the
available
+ frequencies. The throttle stat of a frequency is the total
+ number of times the max frequency is reduced to that frequency.
+
+What:
/sys/devices/system/cpu/cpufreq/chip*/throttle_reasons/
+Date: Jan 2016
+Contact: Linux kernel mailing list
+ Linux for PowerPC mailing list
+Description: CPU Frequency throttle reason stat for the chip
+
+ This directory contains throttle reason files. Each file gives
+ the total number of times the max frequency is throttled, except
+ for 'unthrottle_count', which gives the total number of times
+ the m
[PATCH v7 3/6] cpufreq: powernv: Remove cpu_to_chip_id() from hot-path
cpu_to_chip_id() does a DT walk through to find out the chip id by
taking a contended device tree lock. This adds an unnecessary overhead
in a hot path. So instead of calling cpu_to_chip_id() everytime cache
the chip ids for all cores in the array 'core_to_chip_map' and use it
in the hotpath.
Reported-by: Anton Blanchard
Signed-off-by: Shilpasri G Bhat
---
Changes from v6:
- Minor changes to move the code 'cpumask_copy()' after 'core_to_chip_map'
is allocated.
- Move 'kfree(chips)' to a separate patch.
No changes from v5.
Changes from v4:
- Taken care of Shreyas's comments to add a core_to_chip_map array to
store the chip id.
drivers/cpufreq/powernv-cpufreq.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index a271b0f..c670314 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -43,6 +43,7 @@
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
static bool rebooting, throttled, occ_reset;
+static unsigned int *core_to_chip_map;
static struct chip {
unsigned int id;
@@ -313,13 +314,14 @@ static inline unsigned int get_nominal_index(void)
static void powernv_cpufreq_throttle_check(void *data)
{
unsigned int cpu = smp_processor_id();
+ unsigned int chip_id = core_to_chip_map[cpu_core_index_of_thread(cpu)];
unsigned long pmsr;
int pmsr_pmax, i;
pmsr = get_pmspr(SPRN_PMSR);
for (i = 0; i < nr_chips; i++)
- if (chips[i].id == cpu_to_chip_id(cpu))
+ if (chips[i].id == chip_id)
break;
/* Check for Pmax Capping */
@@ -559,19 +561,29 @@ static int init_chip_info(void)
unsigned int chip[256];
unsigned int cpu, i;
unsigned int prev_chip_id = UINT_MAX;
+ cpumask_t cpu_mask;
+ int ret = -ENOMEM;
- for_each_possible_cpu(cpu) {
+ core_to_chip_map = kcalloc(cpu_nr_cores(), sizeof(unsigned int),
+ GFP_KERNEL);
+ if (!core_to_chip_map)
+ goto out;
+
+ cpumask_copy(&cpu_mask, cpu_possible_mask);
+ for_each_cpu(cpu, &cpu_mask) {
unsigned int id = cpu_to_chip_id(cpu);
if (prev_chip_id != id) {
prev_chip_id = id;
chip[nr_chips++] = id;
}
+ core_to_chip_map[cpu_core_index_of_thread(cpu)] = id;
+ cpumask_andnot(&cpu_mask, &cpu_mask, cpu_sibling_mask(cpu));
}
chips = kmalloc_array(nr_chips, sizeof(struct chip), GFP_KERNEL);
if (!chips)
- return -ENOMEM;
+ goto free_chip_map;
for (i = 0; i < nr_chips; i++) {
chips[i].id = chip[i];
@@ -582,6 +594,10 @@ static int init_chip_info(void)
}
return 0;
+free_chip_map:
+ kfree(core_to_chip_map);
+out:
+ return ret;
}
static int __init powernv_cpufreq_init(void)
@@ -616,6 +632,7 @@ static void __exit powernv_cpufreq_exit(void)
opal_message_notifier_unregister(OPAL_MSG_OCC,
&powernv_cpufreq_opal_nb);
kfree(chips);
+ kfree(core_to_chip_map);
cpufreq_unregister_driver(&powernv_cpufreq_driver);
}
module_exit(powernv_cpufreq_exit);
--
1.9.3
[PATCH v7 2/6] cpufreq: powernv: Hot-plug safe the kworker thread
In the kworker_thread powernv_cpufreq_work_fn(), we can end up
sending an IPI to a cpu going offline. This is a rare corner case
which is fixed using {get/put}_online_cpus(). Along with this fix,
this patch adds changes to do oneshot cpumask_{clear/and} operation.
Suggested-by: Shreyas B Prabhu
Suggested-by: Gautham R Shenoy
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
Acked-by: Viresh Kumar
---
No changes from v6.
Changes form v5:
- Fix the kbuild-error:
drivers/cpufreq/powernv-cpufreq.c:428:2: error: implicit declaration of
function 'get_online_cpus' [-Werror=implicit-function-declaration
drivers/cpufreq/powernv-cpufreq.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 53f980b..a271b0f 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -423,18 +424,19 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
{
struct chip *chip = container_of(work, struct chip, throttle);
unsigned int cpu;
- cpumask_var_t mask;
+ cpumask_t mask;
- smp_call_function_any(&chip->mask,
+ get_online_cpus();
+ cpumask_and(&mask, &chip->mask, cpu_online_mask);
+ smp_call_function_any(&mask,
powernv_cpufreq_throttle_check, NULL, 0);
if (!chip->restore)
- return;
+ goto out;
chip->restore = false;
- cpumask_copy(mask, &chip->mask);
- for_each_cpu_and(cpu, mask, cpu_online_mask) {
- int index, tcpu;
+ for_each_cpu(cpu, &mask) {
+ int index;
struct cpufreq_policy policy;
cpufreq_get_policy(&policy, cpu);
@@ -442,9 +444,10 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
policy.cur,
CPUFREQ_RELATION_C, &index);
powernv_cpufreq_target_index(&policy, index);
- for_each_cpu(tcpu, policy.cpus)
- cpumask_clear_cpu(tcpu, mask);
+ cpumask_andnot(&mask, &mask, policy.cpus);
}
+out:
+ put_online_cpus();
}
static char throttle_reason[][30] = {
--
1.9.3
[PATCH v7 1/6] cpufreq: powernv: Free 'chips' on module exit
This will free the dynamically allocated memory of'chips' on module exit. Signed-off-by: Shilpasri G Bhat --- drivers/cpufreq/powernv-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index 547890f..53f980b 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -612,6 +612,7 @@ static void __exit powernv_cpufreq_exit(void) unregister_reboot_notifier(&powernv_cpufreq_reboot_nb); opal_message_notifier_unregister(OPAL_MSG_OCC, &powernv_cpufreq_opal_nb); + kfree(chips); cpufreq_unregister_driver(&powernv_cpufreq_driver); } module_exit(powernv_cpufreq_exit); -- 1.9.3
[PATCH v7 0/6] cpufreq: powernv: Redesign the presentation of throttle notification and solve bug-fixes in the driver
In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the CPU when the chip crosses its thermal and power limits. Currently, powernv-cpufreq driver detects and reports this event as a console message. Some machines may not sustain the max turbo frequency in all conditions and can be throttled frequently. This can lead to the flooding of console with throttle messages. So this patchset aims to redesign the presentation of this event via sysfs counters and tracepoints. And it also fixes couple of bugs reported in the driver. - Patch [1] fixes a memory leak bug - Patch [2] fixes the cpu hot-plug bug in powernv_cpufreq_work_fn(). - Patch [3] solves a bug in powernv_cpufreq_throttle_check(), which calls in to cpu_to_chip_id() in hot path which reads DT every time to find the chip id. - Patches [4] to [6] will add a perf trace point "power:powernv_throttle" and sysfs throttle counter stats in /sys/devices/system/cpu/cpufreq/chipN. Changes from v6: - Changes wrt comments from Balbir Singh and Viresh Kumar. Changes from v5: - Fix kbuild error: drivers/cpufreq/powernv-cpufreq.c:428:2: error: implicit declaration of function 'get_online_cpus' [-Werror=implicit-function-declaration] Changes from v4: - Fix a hot-plug bug in powernv_cpufreq_work_fn() - Changes wrt Gautham's and Shreyas's comments Changes from v3: - Add a fix to replace cpu_to_chip_id() with simpler PIR shift to obtain the chip id. - Break patch2 in to two patches separating the tracepoint and sysfs attribute changes. Changes from v2: - Fixed kbuild test warning. drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return value of 'kstrtoint', declared with attribute warn_unused_result [-Wunused-result] Shilpasri G Bhat (6): cpufre: powernv: Free 'chips' on module exit cpufreq: powernv: Hot-plug safe the kworker thread cpufreq: powernv: Remove cpu_to_chip_id() from hot-path cpufreq: powernv/tracing: Add powernv_throttle tracepoint cpufreq: powernv: Replace pr_info with trace print for throttle event cpufreq: powernv: Add sysfs attributes to show throttle stats Documentation/ABI/testing/sysfs-devices-system-cpu | 45 +++ drivers/cpufreq/powernv-cpufreq.c | 313 + include/trace/events/power.h | 22 ++ kernel/trace/power-traces.c| 1 + 4 files changed, 326 insertions(+), 55 deletions(-) -- 1.9.3
Re: [PATCH] include/linux/list_bl.h: Use bool instead of int for boolean functions
On Mon, Jan 25, 2016 at 04:58:18AM +0800, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang
>
> hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so
> return bool instead of int.
>
> Signed-off-by: Chen Gang
> ---
> include/linux/list_bl.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/list_bl.h b/include/linux/list_bl.h
> index ee7229a..cb48330 100644
> --- a/include/linux/list_bl.h
> +++ b/include/linux/list_bl.h
> @@ -48,7 +48,7 @@ static inline void INIT_HLIST_BL_NODE(struct hlist_bl_node
> *h)
>
> #define hlist_bl_entry(ptr, type, member) container_of(ptr,type,member)
>
> -static inline int hlist_bl_unhashed(const struct hlist_bl_node *h)
> +static inline bool hlist_bl_unhashed(const struct hlist_bl_node *h)
> {
> return !h->pprev;
> }
> @@ -68,7 +68,7 @@ static inline void hlist_bl_set_first(struct hlist_bl_head
> *h,
> h->first = (struct hlist_bl_node *)((unsigned long)n |
> LIST_BL_LOCKMASK);
> }
>
> -static inline int hlist_bl_empty(const struct hlist_bl_head *h)
> +static inline bool hlist_bl_empty(const struct hlist_bl_head *h)
> {
> return !((unsigned long)READ_ONCE(h->first) & ~LIST_BL_LOCKMASK);
Sorry for my ignorance, but what's the point of doing conversions like
this? It has zero impact on code generation.
Re: [PATCH 0/5] Fix races & improve the radix tree iterator patterns
On Thu, Jan 28, 2016 at 12:17 AM, Matthew Wilcox wrote: > From: Matthew Wilcox > > The first two patches here are bugfixes, and I would like to see them > make their way into stable ASAP since they can lead to data corruption > (very low probabilty). > > The last three patches do not qualify as bugfixes. They simply improve > the standard pattern used to do radix tree iterations by removing the > 'goto restart' part. Partially this is because this is an ugly & > confusing goto, and partially because with multi-order entries in the > tree, it'll be more likely that we'll see an indirect_ptr bit, and > it's more efficient to kep going from the point of the iteration we're > currently in than restart from the beginning each time. Ack whole set. I think we should go deeper in hide dereference/retry inside iterator. Something like radix_tree_for_each_data(data, slot, root, iter, start). I'll prepare patch for that. > > Matthew Wilcox (5): > radix-tree: Fix race in gang lookup > hwspinlock: Fix race between radix tree insertion and lookup > btrfs: Use radix_tree_iter_retry() > mm: Use radix_tree_iter_retry() > radix-tree,shmem: Introduce radix_tree_iter_next() > > drivers/hwspinlock/hwspinlock_core.c | 4 +++ > fs/btrfs/tests/btrfs-tests.c | 3 +- > include/linux/radix-tree.h | 31 + > lib/radix-tree.c | 12 ++-- > mm/filemap.c | 53 > > mm/shmem.c | 30 ++-- > 6 files changed, 78 insertions(+), 55 deletions(-) > > -- > 2.7.0.rc3 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org
Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
Hi Mark, On Wed, 2016-01-27 at 14:41 +, Mark Brown wrote: > On Wed, Jan 27, 2016 at 01:00:59PM +0100, John Crispin wrote: > > > + /* Constrain board-specific capabilities according to what > > +* this driver and the chip itself can actually do. > > +*/ > > + c = rdev->constraints; > > + c->valid_modes_mask |= REGULATOR_MODE_NORMAL | > > + REGULATOR_MODE_STANDBY; > > + c->valid_ops_mask |= REGULATOR_CHANGE_MODE; > > No, drivers should *never* enable things that weren't explictly enabled > by the machine constraints. This misses the whole point of having > constraints. They are there so that the system integrator can enable > the functionality that is safe on a given board. Okay..the constrains should be define on device tree. But which optional properties was suitable to fill on device tree if consumers want to call regulator_set_mode directly ? I have check the of_regulator.c and not found the suitable property name which can set valid_modes_mask & valid_ops_mask. Thanks, Henry > > The comment is also inaccurate, it claims it's imposing constraints but > in fact it's adding additional permissions. > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v5 00/12] MADV_FREE support
Hello Minchan, On 11/30/2015 07:39 AM, Minchan Kim wrote: > In v4, Andrew wanted to settle in old basic MADV_FREE and introduces > new stuffs(ie, lazyfree LRU, swapless support and lazyfreeness) later > so this version doesn't include them. > > I have been tested it on mmotm-2015-11-25-17-08 with additional > patch[1] from Kirill to prevent BUG_ON which he didn't send to > linux-mm yet as formal patch. With it, I couldn't find any > problem so far. > > Note that this version is based on THP refcount redesign so > I needed some modification on MADV_FREE because split_huge_pmd > doesn't split a THP page any more and pmd_trans_huge(pmd) is not > enough to guarantee the page is not THP page. > As well, for MAVD_FREE lazy-split, THP split should respect > pmd's dirtiness rather than marking ptes of all subpages dirty > unconditionally. Please, review last patch in this patchset. Now that MADV_FREE has been merged, would you be willing to write patch to the madvise(2) man page that describes the semantics, noes limitations and restrictions, and (ideally) has some sentences describing use cases? Thanks, Michael > mm: don't split THP page when syscall is called > > [1] https://lkml.org/lkml/2015/11/17/134 > > git: git://git.kernel.org/pub/scm/linux/kernel/git/minchan/linux.git > branch: mm/madv_free-v4.4-rc2-mmotm-2015-11-25-17-08-v5r2 > > In this stage, I don't think we need to write man page. > It could be done after solid policy and implementation. > > * Change from v4 >* drop lazyfree LRU >* drop swapless support >* drop lazyfreeness >* rebase on recent mmotom with THP refcount redesign > > * Change from v3 >* some bug fix >* code refactoring >* lazyfree reclaim logic change >* reordering patch > > * Change from v2 >* vm_lazyfreeness tuning knob >* add new LRU list - Johannes, Shaohua >* support swapless - Johannes > > * Change from v1 >* Don't do unnecessary TLB flush - Shaohua >* Added Acked-by - Hugh, Michal >* Merge deactivate_page and deactivate_file_page >* Add pmd_dirty/pmd_mkclean patches for several arches >* Add lazy THP split patch >* Drop zhangyan...@cn.fujitsu.com - Delivery Failure > > Chen Gang (1): > arch: uapi: asm: mman.h: Let MADV_FREE have same value for all > architectures > > Minchan Kim (11): > mm: support madvise(MADV_FREE) > mm: define MADV_FREE for some arches > mm: free swp_entry in madvise_free > mm: move lazily freed pages to inactive list > mm: mark stable page dirty in KSM > x86: add pmd_[dirty|mkclean] for THP > sparc: add pmd_[dirty|mkclean] for THP > powerpc: add pmd_[dirty|mkclean] for THP > arm: add pmd_mkclean for THP > arm64: add pmd_mkclean for THP > mm: don't split THP page when syscall is called > > arch/alpha/include/uapi/asm/mman.h | 2 + > arch/arm/include/asm/pgtable-3level.h| 1 + > arch/arm64/include/asm/pgtable.h | 1 + > arch/mips/include/uapi/asm/mman.h| 2 + > arch/parisc/include/uapi/asm/mman.h | 2 + > arch/powerpc/include/asm/pgtable-ppc64.h | 2 + > arch/sparc/include/asm/pgtable_64.h | 9 ++ > arch/x86/include/asm/pgtable.h | 5 + > arch/xtensa/include/uapi/asm/mman.h | 2 + > include/linux/huge_mm.h | 3 + > include/linux/rmap.h | 1 + > include/linux/swap.h | 1 + > include/linux/vm_event_item.h| 1 + > include/uapi/asm-generic/mman-common.h | 1 + > mm/huge_memory.c | 87 +- > mm/ksm.c | 6 + > mm/madvise.c | 199 > +++ > mm/rmap.c| 8 ++ > mm/swap.c| 44 +++ > mm/swap_state.c | 5 +- > mm/vmscan.c | 10 +- > mm/vmstat.c | 1 + > 22 files changed, 383 insertions(+), 10 deletions(-) > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] epoll: add exclusive wakeups flag
Hi Jason, On 12/08/2015 04:23 AM, Jason Baron wrote: > Hi, > > Re-post of an old series addressing thundering herd issues when sharing > an event source fd amongst multiple epoll fds. Last posting was here > for reference: https://lkml.org/lkml/2015/2/25/56 > > The patch herein drops the core scheduler 'rotate' changes I had previously > proposed as this patch seems performant without those. > > I was prompted to re-post this because Madars Vitolins reported some good > speedups with this patch using Enduro/X application. His writeup is here: > https://mvitolin.wordpress.com/2015/12/05/endurox-testing-epollexclusive-flag/ > > Thanks, > > -Jason > > Sample epoll_clt text: Thanks for the proposed text. I have some questions about points that are not quite clear to me. > EPOLLEXCLUSIVE > Sets an exclusive wakeup mode for the epfd file descriptor that is > being attached to the target file descriptor, fd. Thus, when an > event occurs and multiple epfd file descriptors are attached to the > same target file using EPOLLEXCLUSIVE, one or more epfds will receive > an event with epoll_wait(2). The default in this scenario (when > EPOLLEXCLUSIVE is not set) is for all epfds to receive an event. > EPOLLEXLUSVIE may only be specified with the op EPOLL_CTL_ADD. So, assuming an FD is present in the interest list of multiple (say 6) epoll FDs, and some (say 3) of those attachments were done using EPOLLEXCLUSVE. Which of the following statements are correct: (a) It's guaranteed that *none* of the epoll FDs that did NOT specify EPOLLEXCLUSIVE will receive an event. (b) It's guaranteed that *all* of the epoll FDs that did NOT specify EPOLLEXCLUSIVE will receive an event. (c) From 1 to 3 of the epoll FDs that did specify EPOLLEXCLUSIVE will receive an event. (d) Exactly one epoll FD that did specify EPOLLEXCLUSIVE will get an event, and it is indeterminate which one. I suppose one point I'm trying to uncover in the above is: what is the scope of EPOLLEXCLUSIVE? Is it just applicable for one process's FD, or is it setting an attribute in the epoll "interest list" record for that FD that affects notification behavior across all processes? And then: (1) What are the semantics of EPOLLEXCLUSIVE if the added FD becomes disabled via EPOLLONESHOT (or explicitly via EPOLL_CTL_MOD with the 'events' field set to 0)? (2) The source code contains a comment "we do not currently supported nested exclusive wakeups". Could you elaborate on this point? It sounds like something that should be documented. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code
On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote:
> And we already have lockdep turned off to avoid triggering a recursive
> lockdep report (which I think is a mistake).
Yes, we already have a way to turn off the lock debug so that we can
avoid it. So I used it in v4.
thanks,
byungchul
>
> I think we should be working toward properly handling recursion
> in printk().
>
> Regards,
> Peter Hurley
>
>
> > When the debug spinlock code is called from printk(), we should prevent
> > calling spin_dump() and the like, calling printk() again in that context.
> >
> > Signed-off-by: Byungchul Park
> > ---
> > include/linux/debug_locks.h | 4
> > kernel/locking/spinlock_debug.c | 14 +++---
> > 2 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
> > index 822c135..b0f977e 100644
> > --- a/include/linux/debug_locks.h
> > +++ b/include/linux/debug_locks.h
> > @@ -10,6 +10,10 @@ struct task_struct;
> > extern int debug_locks;
> > extern int debug_locks_silent;
> >
> > +static inline void __debug_locks_on(void)
> > +{
> > + debug_locks = 1;
> > +}
> >
> > static inline int __debug_locks_off(void)
> > {
> > diff --git a/kernel/locking/spinlock_debug.c
> > b/kernel/locking/spinlock_debug.c
> > index 0374a59..65177ba 100644
> > --- a/kernel/locking/spinlock_debug.c
> > +++ b/kernel/locking/spinlock_debug.c
> > @@ -113,11 +113,19 @@ static void __spin_lock_debug(raw_spinlock_t *lock)
> > return;
> > __delay(1);
> > }
> > - /* lockup suspected: */
> > - spin_dump(lock, "lockup suspected");
> > +
> > + /*
> > +* We should prevent calling printk() further, since it would cause
> > +* an infinite recursive cycle if it's called from printk()!
> > +*/
> > + if (__debug_locks_off()) {
> > + /* lockup suspected: */
> > + spin_dump(lock, "lockup suspected");
> > #ifdef CONFIG_SMP
> > - trigger_all_cpu_backtrace();
> > + trigger_all_cpu_backtrace();
> > #endif
> > + __debug_locks_on();
> > + }
> >
> > /*
> > * The trylock above was causing a livelock. Give the lower level arch
> >
Re: sound: heap out-of-bounds write in dummy_systimer_prepare
On Thu, 28 Jan 2016 07:38:08 +0100, Takashi Iwai wrote: > > The easiest fix for this is obviously to disable the switch via > sysfs like below. Meanwhile we may copy the ops to the runtime > instance so that it won't affect the running stream. This can be done > for 4.6, while disabling sysfs for 4.5 and stable. FWIW, below is the patch with a proper description. Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] ALSA: dummy: Disable switching timer backend via sysfs ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This can be also switched dynamically via sysfs, but it may lead to a memory corruption when switching is done while a PCM stream is running; the stream instance for the newly switched timer method tries to access the memory that was allocated by another timer method although the sizes differ. As the simplest fix, this patch just disables the switch via sysfs by dropping the writable bit. BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dwyy-wfzvu...@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai --- sound/drivers/dummy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index 75b74850c005..bde33308f0d6 100644 --- a/sound/drivers/dummy.c +++ b/sound/drivers/dummy.c @@ -87,7 +87,7 @@ MODULE_PARM_DESC(pcm_substreams, "PCM substreams # (1-128) for dummy driver."); module_param(fake_buffer, bool, 0444); MODULE_PARM_DESC(fake_buffer, "Fake buffer allocations."); #ifdef CONFIG_HIGH_RES_TIMERS -module_param(hrtimer, bool, 0644); +module_param(hrtimer, bool, 0444); MODULE_PARM_DESC(hrtimer, "Use hrtimer as the timer source."); #endif -- 2.7.0
RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee0 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
Re: [PATCH v2] android: binder: Sanity check at binder ioctl
Hi,
On 2016/1/20 6:40, David Rientjes wrote:
> On Tue, 19 Jan 2016, Chen Feng wrote:
>
>> When a process fork a child process, we should not allow the
>> child process use the binder which opened by parent process.
>>
>> But if the binder-object creater is a thread of one process who exit,
>> the other thread can also use this binder-object normally.
>> We can distinguish this by the member proc->tsk->mm.
>> If the thread exit the tsk->mm will be NULL.
>>
>
> Why does exit_mm(), the point where tsk->mm == NULL, signify the point at
> which the binder can now be used by other threads?
Yes,the other threads used this shared mm for communication. A lots of APPs
have this issue.
For example: system_server process use many libs,libstagefright,
Libdrmframeworketc,
In these lib, binder global object exist like static sp
sDeathNotifier,
static sp sDrmManagerService;
When system_sever process fork failed, the new child process call exit, which
will call
hook destruction function.
In destruction, the parent process *binder reference count will be wrong*. To
protect
these exception, we need to add the code in binder.
For v2 patch, I agree with your opinion, some race condition exist in some
special case.
I found that the task->mm already cached at binder_mm.
proc->vma_vm_mm = vma->vm_mm;
I will change the condition to if (unlikely(current->mm != proc->tsk->mm)).
But in some scenes, the thread do communication before the mmap called.
So I add proc->vma_vm_mm = current->mm where the binder_open function.
Since the binder init process in libbinder, the fix won't produce side effect.
If these are accepted, I will send a new V3 version.
>
>> proc->tsk->mm != current->mm && proc->tsk->mm
>>
>> So only allow the shared mm_struct to use the same binder-object and
>> check the existence of mm_struct.
>>
>> V2: Fix compile error for error commit
>>
>> Signed-off-by: Chen Feng
>> Signed-off-by: Wei Dong
>> Signed-off-by: Junmin Zhao
>> Reviewed-by: Zhuangluan Su
>> ---
>> drivers/android/binder.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
>> index a39e85f..279063c 100644
>> --- a/drivers/android/binder.c
>> +++ b/drivers/android/binder.c
>> @@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned
>> int cmd, unsigned long arg)
>>
>> /*pr_info("binder_ioctl: %d:%d %x %lx\n",
>> proc->pid, current->pid, cmd, arg);*/
>> +if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
>> +return -EINVAL;
>>
>> trace_binder_ioctl(cmd, arg);
>>
>
> I would imagine that you would want to do READ_ONCE(proc->tsk->mm) so you
> are guaranteed to be testing the same value.
>
> .
>
[PATCH] cputime: Fix timeval-->cputime conversion
The structure:
struct timeval {
__kernel_time_t tv_sec; /* seconds */
__kernel_suseconds_ttv_usec;/* microseconds */
};
both __kernel_time_t and __kernel_suseconds_t are short than u64
when it is 32bit platform, so force u64 conversion here.
Signed-off-by: zengtao
---
include/asm-generic/cputime_nsecs.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/cputime_nsecs.h
b/include/asm-generic/cputime_nsecs.h
index 0419485..e2f7ff9 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -91,7 +91,8 @@ static inline void cputime_to_timespec(const cputime_t ct,
struct timespec *val)
*/
static inline cputime_t timeval_to_cputime(const struct timeval *val)
{
- u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_usec * NSEC_PER_USEC;
+ u64 ret = (u64)val->tv_sec * NSEC_PER_SEC +
+ val->tv_usec * NSEC_PER_USEC;
return (__force cputime_t) ret;
}
static inline void cputime_to_timeval(const cputime_t ct, struct timeval *val)
--
1.9.1
Re: [PATCH] storvsc: use small sg_tablesize on x86
On Wed, Jan 27, James Bottomley wrote: > It's not really architecture independent, is it? Just use the bit > width config. Again: which one? This driver is not for mips|powerpc|score|sh. Olaf
RE: [RFC 3/4] ARM: imx: add the platform related rpmsg implementation
Thanks a lot. Best Regards hongxing zhu Linux BSP team Office: 86-21-28937189 Email: hongxing@nxp.com -Original Message- From: Shawn Guo [mailto:shawn...@kernel.org] Sent: Thursday, January 28, 2016 1:50 PM To: Richard Zhu Cc: o...@wizery.com; Stefan Agner; linux-kernel@vger.kernel.org Subject: Re: [RFC 3/4] ARM: imx: add the platform related rpmsg implementation On Thu, Jan 28, 2016 at 02:17:21AM +, Richard Zhu wrote: > > arch/arm/mach-imx/Kconfig | 12 ++ > > arch/arm/mach-imx/Makefile| 2 + > > arch/arm/mach-imx/imx_rpmsg.c | 364 > > ++ > > arch/arm/mach-imx/mu.c| 217 + > > I'm not rpmsg expert, but it seems to me that the driver should be put into > drivers/rpmsg/ rather than mach-imx. > [Richard] This part rpmsg codes are closed related to the platform. For > example, kinds of ops callback functions. > Thus, these codes are placed into arch/arm/mach-imx/ folder. BTW, so does to > omap rpmsg implementation. > http://omappedia.org/wiki/RPMsg_Kernel_Sources Okay, I will find some time slot to get myself familiar with rpmsg subsystem and then review the patch. Shawn
Re: [PATCH V5 5/5] regulator: max77620: add regulator driver for max77620/max20024
On 28.01.2016 15:24, Laxman Dewangan wrote: > > On Thursday 28 January 2016 09:25 AM, Krzysztof Kozlowski wrote: >> On 27.01.2016 23:10, Laxman Dewangan wrote: >>> MAXIM Semiconductor's PMIC, MAX77620 and MAX20024 have the >>> multiple DCDC and LDOs. This supplies the power to different >>> components of the system. >>> Also these rails has configuration for ramp time, flexible >>> power sequence, slew rate etc. >>> >>> Add regulator driver to access these rails via regulator APIs. >>> >>> Signed-off-by: Laxman Dewangan >>> Signed-off-by: Mallikarjun Kasoju >>> --- >>> Changes from V1: >>> - Cleanup code based on comment received on mfd/rtc. >>> - Avoid duplication on error message. >>> >>> Changes form V2: >>> - Run coccicheck and checkpatch in strict mode for the alignment. >>> - Refactor Regulator driver to use core API for DT parsing. >>> - Update based on API changes. >>> >>> Changes from V3: >>> - Change all sys initcall to module driver. >>> - change the max77620_read argument to unisgned int from u8. >>> >>> Changes from V4: >>> - Added DT binding document as >>> devicetree/bindings/regulator/regulator-max77620.txt >>> - Detail out properties. >> What does it mean "Detail out properties"? What have changed> > > Based on review comment from Linus W, I added more description on the > properties. Ah, ok. >> I already reviewed the patchset but because of adding bindings here, you >> could not add my reviewed-by tag (which makes my effort not tracked...). > Yaah, This patch include the dt binding and so wanted your review again. > This si only reason to not add reviewed-by. > > Now I am going to separate out DT binding and driver, I will add > reviewed-by tag for you in driver file. Yeah, but the driver nor the bindings do not change so it really does not need my additional review. Best regards, Krzysztof
Re: [PATCH v8 0/5] mfd: tps65912: Driver rewrite with DT support
Mark, Just need your stamp for this to go in. > In an effort to cleanup this driver and add Device Tree support > the driver has been rewritten based on new driver styles and > modern kernel driver helpers. This has nearly halved the lines > of code while keeping all previous functionality. > > Platform file based initialization has been dropped as there is > no examples of this use in the kernel. > > v1 can be found here: [1] v2: [2] v3: [3] v4: [4] v5: [5] v6: [6] v7: [7] > > Changes from v7: > - Now complies with gpiolib changes > > Changes from v6: > - Removed compatible strings from DT sub-nodes > - Rearranged DT bindings > - Small fixes > > Changes from v5: > - Small formatting changes to DT Docs > - Converted to_tps65912_gpio from macro to inline function > > Changes from v4: > - Use mfd core to add sub-devices > > Changes from v3: > - Reorganized regulator driver and related DT node > - Other small fixes as discussed in v3 thread > > Changes from v2: > - Split the series further into subsystems > > Changes from v1: > - Split the rewrite into delete/create patches > - Several small fixes as discussed in v1 thread > > [1] http://www.spinics.net/lists/devicetree/msg93863.html > [2] http://www.spinics.net/lists/devicetree/msg95003.html > [3] http://www.spinics.net/lists/devicetree/msg95133.html > [4] http://www.spinics.net/lists/devicetree/msg96109.html > [5] http://www.spinics.net/lists/devicetree/msg100601.html > [6] https://lkml.org/lkml/2015/10/30/690 > [7] https://www.spinics.net/lists/linux-gpio/msg09710.html > > Andrew F. Davis (5): > Documentation: tps65912: Add DT bindings for the TPS65912 PMIC > mfd: tps65912: Remove old driver in preparation for new driver > mfd: tps65912: Add driver for the TPS65912 PMIC > regulator: tps65912: Add regulator driver for the TPS65912 PMIC > gpio: tps65912: Add GPIO driver for the TPS65912 PMIC > > Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++ > drivers/gpio/Kconfig | 2 +- > drivers/gpio/gpio-tps65912.c | 309 - > drivers/mfd/Kconfig| 20 +- > drivers/mfd/Makefile | 3 +- > drivers/mfd/tps65912-core.c| 286 - > drivers/mfd/tps65912-i2c.c | 218 +++ > drivers/mfd/tps65912-irq.c | 217 --- > drivers/mfd/tps65912-spi.c | 218 +++ > drivers/regulator/Kconfig | 2 +- > drivers/regulator/tps65912-regulator.c | 709 > + > include/linux/mfd/tps65912.h | 209 +++--- > 12 files changed, 767 insertions(+), 1476 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt > rewrite drivers/gpio/gpio-tps65912.c (74%) > rewrite drivers/mfd/tps65912-core.c (96%) > rewrite drivers/mfd/tps65912-i2c.c (93%) > delete mode 100644 drivers/mfd/tps65912-irq.c > rewrite drivers/mfd/tps65912-spi.c (92%) > rewrite drivers/regulator/tps65912-regulator.c (94%) > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066
Hi Doug, We are in HOST mode, we only need to receive data from USB camera with RX FIFO, and no need to use TX FIFO for USB webcam, right? :) Any way, I think we need to NAK this patch after look into the design of dwc2 controller. Because all the dwc2 controller inside the Rockchip chips don't support the thresholding FIFO mode, in this case, there is no more transaction before a whole packet is send out and the dwc2 only care if the available FIFO is enough for next packet or not. So, the addition 48 words won't help to shorten the latency for data prepare in this case. Thanks, - Kever On 01/28/2016 11:28 AM, Doug Anderson wrote: Kever, On Wed, Jan 27, 2016 at 7:10 PM, Kever Yang wrote: Hi Doug, We are using the minimum FIFO size mode for TX now, which only equal to one max packet size. The addition FIFO size may help shorten the inter-packet data prepare latency when the bus/DRAM is busy. For the actual usage in TX, we have very little change to use the period TX FIFO with more than one max packet size in host mode. So far as I know, usb audio use the isochronous tx FIFO, but this king of device won't have much data payload and won't, I haven't see a usb audio have more data than 1024byte/ms. So I suggest we assign this 48 words to host_nperio_tx_fifi_size instead if we have to do this. Because we are using device base on bulk transaction like U-disk very frequently. Try using a USB webcam. With that plus a USB audio device it's easy to overwhelm the periodic TX FIFO. If we overwhelm the periodic TX FIFO we might actually fail to transmit ISO or INT packets at the scheduled time. That seems more serious of a problem to try to fix than eeking out a tiny bit performance on a USB disk. ...but of course, it all depends on what you consider important. ;) We could split the difference, I suppose and put half on each? -Doug
[mpt3sas driver 02/10] mpt3sas: Used IEEE SGL instead of MPI SGL while framing a SMP Passthrough request message.
From: Suganath prabu Subramani As driver was using MPI SGL while framing the SMP Passthrough request message due to which firmware unable to post the Reply Data in the host memory and timeout is observed for this SMP Passthrough request message and so unable to perform phy disable operation. Signed-off-by: Suganath prabu Subramani Signed-off-by: Chaitra P B --- drivers/scsi/mpt3sas/mpt3sas_transport.c | 23 --- 1 file changed, 4 insertions(+), 19 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c index ca36d7e..df08aeb 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_transport.c +++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c @@ -1418,7 +1418,6 @@ _transport_expander_phy_control(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state; unsigned long timeleft; void *psge; - u32 sgl_flags; u8 issue_reset = 0; void *data_out = NULL; dma_addr_t data_out_dma; @@ -1507,24 +1506,10 @@ _transport_expander_phy_control(struct MPT3SAS_ADAPTER *ioc, cpu_to_le16(sizeof(struct phy_error_log_request)); psge = &mpi_request->SGL; - /* WRITE sgel first */ - sgl_flags = (MPI2_SGE_FLAGS_SIMPLE_ELEMENT | - MPI2_SGE_FLAGS_END_OF_BUFFER | MPI2_SGE_FLAGS_HOST_TO_IOC); - sgl_flags = sgl_flags << MPI2_SGE_FLAGS_SHIFT; - ioc->base_add_sg_single(psge, sgl_flags | - sizeof(struct phy_control_request), data_out_dma); - - /* incr sgel */ - psge += ioc->sge_size; - - /* READ sgel last */ - sgl_flags = (MPI2_SGE_FLAGS_SIMPLE_ELEMENT | - MPI2_SGE_FLAGS_LAST_ELEMENT | MPI2_SGE_FLAGS_END_OF_BUFFER | - MPI2_SGE_FLAGS_END_OF_LIST); - sgl_flags = sgl_flags << MPI2_SGE_FLAGS_SHIFT; - ioc->base_add_sg_single(psge, sgl_flags | - sizeof(struct phy_control_reply), data_out_dma + - sizeof(struct phy_control_request)); + ioc->build_sg(ioc, psge, data_out_dma, + sizeof(struct phy_control_request), + data_out_dma + sizeof(struct phy_control_request), + sizeof(struct phy_control_reply)); dtransportprintk(ioc, pr_info(MPT3SAS_FMT "phy_control - send to sas_addr(0x%016llx), phy(%d), opcode(%d)\n", -- 1.8.3.1
[mpt3sas driver 04/10] mpt3sas: Never block the Enclosure device
From: Suganath prabu Subramani
Never block the SEP device (i.e. Never invoke the
scsi_internal_device_block() API for SEP device) even for the delay not
responding events. Blocking the SEP device will create a deadlock while
adding any device to the OS.
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 1 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 5ad271e..2786222 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -398,6 +398,7 @@ struct MPT3SAS_DEVICE {
u8 configured_lun;
u8 block;
u8 tlr_snoop_check;
+ u8 ignore_delay_remove;
};
#define MPT3_CMD_NOT_USED 0x8000 /* free */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 686a46a..dcb4c18 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1953,7 +1953,15 @@ scsih_slave_configure(struct scsi_device *sdev)
if (sas_device->device_info & MPI2_SAS_DEVICE_INFO_SSP_TARGET) {
qdepth = MPT3SAS_SAS_QUEUE_DEPTH;
ssp_target = 1;
- ds = "SSP";
+ if (sas_device->device_info &
+ MPI2_SAS_DEVICE_INFO_SEP) {
+ sdev_printk(KERN_WARNING, sdev,
+ "set ignore_delay_remove for handle(0x%04x)\n",
+ sas_device_priv_data->sas_target->handle);
+ sas_device_priv_data->ignore_delay_remove = 1;
+ ds = "SES";
+ } else
+ ds = "SSP";
} else {
qdepth = MPT3SAS_SATA_QUEUE_DEPTH;
if (sas_device->device_info & MPI2_SAS_DEVICE_INFO_STP_TARGET)
@@ -2943,6 +2951,12 @@ _scsih_block_io_all_device(struct MPT3SAS_ADAPTER *ioc)
continue;
if (sas_device_priv_data->block)
continue;
+ if (sas_device_priv_data->ignore_delay_remove) {
+ sdev_printk(KERN_INFO, sdev,
+ "%s skip device_block for SES handle(0x%04x)\n",
+ __func__, sas_device_priv_data->sas_target->handle);
+ continue;
+ }
_scsih_internal_device_block(sdev, sas_device_priv_data);
}
}
@@ -2975,6 +2989,12 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
continue;
if (sas_device->pend_sas_rphy_add)
continue;
+ if (sas_device_priv_data->ignore_delay_remove) {
+ sdev_printk(KERN_INFO, sdev,
+ "%s skip device_block for SES handle(0x%04x)\n",
+ __func__, sas_device_priv_data->sas_target->handle);
+ continue;
+ }
_scsih_internal_device_block(sdev, sas_device_priv_data);
}
--
1.8.3.1
[mpt3sas driver 07/10] mpt3sas: Add support for configurable Chain Frame Size
From: Suganath prabu Subramani
Added support for configurable Chain Frame Size. Calculate the
Chain Message Frame size from the IOCMaxChainSegementSize (iocfacts).
Applicable only for mpt3sas/SAS3.0 HBA's.
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 27 ++-
drivers/scsi/mpt3sas/mpt3sas_base.h | 8 +++-
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a1a3b39..0f623fb 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3248,6 +3248,19 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
/* reply frame size */
ioc->reply_sz = facts->ReplyFrameSize * 4;
+ /* chain segment size */
+ if (ioc->hba_mpi_version_belonged != MPI2_VERSION) {
+ if (facts->IOCMaxChainSegmentSize)
+ ioc->chain_segment_sz =
+ facts->IOCMaxChainSegmentSize *
+ MAX_CHAIN_ELEMT_SZ;
+ else
+ /* set to 128 bytes size if IOCMaxChainSegmentSize is zero */
+ ioc->chain_segment_sz = DEFAULT_NUM_FWCHAIN_ELEMTS *
+ MAX_CHAIN_ELEMT_SZ;
+ } else
+ ioc->chain_segment_sz = ioc->request_sz;
+
/* calculate the max scatter element size */
sge_size = max_t(u16, ioc->sge_size, ioc->sge_size_ieee);
@@ -3259,7 +3272,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
ioc->max_sges_in_main_message = max_sge_elements/sge_size;
/* now do the same for a chain buffer */
- max_sge_elements = ioc->request_sz - sge_size;
+ max_sge_elements = ioc->chain_segment_sz - sge_size;
ioc->max_sges_in_chain_message = max_sge_elements/sge_size;
/*
@@ -3451,7 +3464,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
goto out;
}
ioc->chain_dma_pool = pci_pool_create("chain pool", ioc->pdev,
- ioc->request_sz, 16, 0);
+ ioc->chain_segment_sz, 16, 0);
if (!ioc->chain_dma_pool) {
pr_err(MPT3SAS_FMT "chain_dma_pool: pci_pool_create failed\n",
ioc->name);
@@ -3465,13 +3478,13 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER
*ioc, int sleep_flag)
ioc->chain_depth = i;
goto chain_done;
}
- total_sz += ioc->request_sz;
+ total_sz += ioc->chain_segment_sz;
}
chain_done:
dinitprintk(ioc, pr_info(MPT3SAS_FMT
"chain pool depth(%d), frame_size(%d), pool_size(%d kB)\n",
- ioc->name, ioc->chain_depth, ioc->request_sz,
- ((ioc->chain_depth * ioc->request_sz))/1024));
+ ioc->name, ioc->chain_depth, ioc->chain_segment_sz,
+ ((ioc->chain_depth * ioc->chain_segment_sz))/1024));
/* initialize hi-priority queue smid's */
ioc->hpr_lookup = kcalloc(ioc->hi_priority_depth,
@@ -4332,6 +4345,10 @@ _base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int
sleep_flag)
facts->FWVersion.Word = le32_to_cpu(mpi_reply.FWVersion.Word);
facts->IOCRequestFrameSize =
le16_to_cpu(mpi_reply.IOCRequestFrameSize);
+ if (ioc->hba_mpi_version_belonged != MPI2_VERSION) {
+ facts->IOCMaxChainSegmentSize =
+ le16_to_cpu(mpi_reply.IOCMaxChainSegmentSize);
+ }
facts->MaxInitiators = le16_to_cpu(mpi_reply.MaxInitiators);
facts->MaxTargets = le16_to_cpu(mpi_reply.MaxTargets);
ioc->shost->max_id = -1;
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 4b52a07..d1fee34 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -129,6 +129,9 @@
#define MPT3SAS_INVALID_DEVICE_HANDLE 0x
+#define MAX_CHAIN_ELEMT_SZ 16
+#define DEFAULT_NUM_FWCHAIN_ELEMTS 8
+
/*
* reset phases
*/
@@ -759,7 +762,7 @@ struct mpt3sas_facts {
u32 IOCCapabilities;
union mpi3_version_unionFWVersion;
u16 IOCRequestFrameSize;
- u16 Reserved3;
+ u16 IOCMaxChainSegmentSize;
u16 MaxInitiators;
u16 MaxTargets;
u16 MaxSasExpanders;
@@ -906,6 +909,8 @@ typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct
MPT3SAS_ADAPTER *ioc);
* @max_sges_in_chain_message: number sg elements per chain
* @chains_needed_per_io: max chains per io
* @chain_depth: total chains allocated
+ * @chain_segment_sz: gives the max number of
+ *
[PATCH v4] perf/x86/amd/power: Add AMD accumulated power reporting mechanism
Introduce an AMD accumlated power reporting mechanism for Carrizo (Family 15h, Model 60h) processor that should be used to calculate the average power consumed by a processor during a measurement interval. The feature of accumulated power mechanism is indicated by CPUID Fn8000_0007_EDX[12]. - * Tsample: compute unit power accumulator sample period * Tref: the PTSC counter period * PTSC: performance timestamp counter * N: the ratio of compute unit power accumulator sample period to the PTSC period * Jmax: max compute unit accumulated power which is indicated by MaxCpuSwPwrAcc MSR C001007b * Jx/Jy: compute unit accumulated power which is indicated by CpuSwPwrAcc MSR C001007a * Tx/Ty: the value of performance timestamp counter which is indicated by CU_PTSC MSR C0010280 * PwrCPUave: CPU average power i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007. N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]]. ii. Read the full range of the cumulative energy value from the new MSR MaxCpuSwPwrAcc. Jmax = value returned. iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC. Jx = value read from CpuSwPwrAcc and Tx = value read from PTSC. iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC. Jy = value read from CpuSwPwrAcc and Ty = value read from PTSC. v. Calculate the average power consumption for a compute unit over time period (y-x). Unit of result is uWatt. if (Jy < Jx) // Rollover has occurred Jdelta = (Jy + Jmax) - Jx else Jdelta = Jy - Jx PwrCPUave = N * Jdelta * 1000 / (Ty - Tx) -- This feature will be implemented both on hwmon and perf that discussed in mail list before. At current design, it provides one event to report per package/processor power consumption by counting each compute unit power value. Simple example: root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h SKIPPED include/generated/compile.h Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#40) MODPOST 4225 modules Performance counter stats for 'system wide': 183.44 mWatts power/power-pkg/ 341.837270111 seconds time elapsed root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' sleep 10 Performance counter stats for 'system wide': 0.18 mWatts power/power-pkg/ 10.012551815 seconds time elapsed Reference: http://lkml.kernel.org/r/20150831160622.ga29...@nazgul.tnic Suggested-by: Peter Zijlstra Suggested-by: Ingo Molnar Suggested-by: Borislav Petkov Signed-off-by: Huang Rui Cc: Guenter Roeck --- Hi, This series of patches introduces the perf implementation of accumulated power reporting algorithm. It will calculate the average power consumption for the processor. The CPU feature flag is CPUID.8000_0007H:EDX[12]. Changes from v1 -> v2: - Add a patch to fix the build issue which is reported by kbuild test robot. Changes from v2 -> v3: - Use raw_spinlock_t instead of spinlock_t, because it need meet the -rt mode use case. - Use topology_sibling_cpumask to make the cpumask operation easier. Changes from v3 -> v4: - Remove active_list, because it is not iterated. - Capitalize sentences consistently and fix some typos. - Fix some code style issues. - Initialize structures in a vertically aligned manner. - Remove unnecessary comment. - Fix the runtime bug, and do some testing on CPU-hotplug scenario. Thanks, Rui --- arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/perf_event_amd_power.c | 498 + 2 files changed, 499 insertions(+) create mode 100644 arch/x86/kernel/cpu/perf_event_amd_power.c diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 5803130..97f3413 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_PERF_EVENTS) += perf_event.o ifdef CONFIG_PERF_EVENTS obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o perf_event_amd_uncore.o +obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_power.o ifdef CONFIG_AMD_IOMMU obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_iommu.o endif diff --git a/arch/x86/kernel/cpu/perf_event_amd_power.c b/arch/x86/kernel/cpu/perf_event_amd_power.c new file mode 100644 index 000..01630ec --- /dev/null +++ b/arch/x86/kernel/cpu/perf_event_amd_power.c @@ -0,0 +1,498 @@ +/* + * Performance events - AMD Processo
[mpt3sas driver 08/10] mpt3sas: Updated MPI Header to 2.00.42
From: Suganath prabu Subramani
Updated MPI version and MPI header files.
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 8 +---
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 7 +--
drivers/scsi/mpt3sas/mpi/mpi2_init.h | 3 ++-
drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 2 +-
drivers/scsi/mpt3sas/mpi/mpi2_sas.h | 2 +-
5 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index 367e6ac..dfad5b8 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
* scatter/gather formats.
* Creation Date: June 21, 2006
*
- * mpi2.h Version: 02.00.37
+ * mpi2.h Version: 02.00.39
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -94,10 +94,12 @@
* 06-13-14 02.00.35 Bumped MPI2_HEADER_VERSION_UNIT.
* 11-18-14 02.00.36 Updated copyright information.
* Bumped MPI2_HEADER_VERSION_UNIT.
- * 03-xx-15 02.00.37 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 03-16-15 02.00.37 Bumped MPI2_HEADER_VERSION_UNIT.
* Added Scratchpad registers to
* MPI2_SYSTEM_INTERFACE_REGS.
* Added MPI2_DIAG_SBR_RELOAD.
+ * 03-19-15 02.00.38 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 05-25-15 02.00.39 Bumped MPI2_HEADER_VERSION_UNIT.
* --
*/
@@ -137,7 +139,7 @@
#define MPI2_VERSION_02_06 (0x0206)
/*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x23)
+#define MPI2_HEADER_VERSION_UNIT(0x27)
#define MPI2_HEADER_VERSION_DEV (0x00)
#define MPI2_HEADER_VERSION_UNIT_MASK (0xFF00)
#define MPI2_HEADER_VERSION_UNIT_SHIFT (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index 43a6fe9..9cf09bf 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -6,7 +6,7 @@
* Title: MPI Configuration messages and pages
* Creation Date: November 10, 2006
*
- * mpi2_cnfg.h Version: 02.00.31
+ * mpi2_cnfg.h Version: 02.00.33
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -182,8 +182,10 @@
* 11-18-14 02.00.30 Updated copyright information.
* Added MPI2_BIOSPAGE1_OPTIONS_ADVANCED_CONFIG.
* Added AdapterOrderAux fields to BIOS Page 3.
- * 03-xx-15 02.00.31 Updated for MPI v2.6.
+ * 03-16-15 02.00.31 Updated for MPI v2.6.
* Added new SAS Phy Event codes
+ * 05-25-15 02.00.33 Added more defines for the BiosOptions field of
+ * MPI2_CONFIG_PAGE_BIOS_1.
* --
*/
@@ -1412,6 +1414,7 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
#define MPI2_BIOSPAGE1_PAGEVERSION (0x07)
/*values for BIOS Page 1 BiosOptions field */
+#define MPI2_BIOSPAGE1_OPTIONS_BOOT_LIST_ADD_ALT_BOOT_DEVICE(0x8000)
#define MPI2_BIOSPAGE1_OPTIONS_ADVANCED_CONFIG (0x4000)
#define MPI2_BIOSPAGE1_OPTIONS_PNS_MASK (0x3800)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_init.h
b/drivers/scsi/mpt3sas/mpi/mpi2_init.h
index 4916699..c38f624 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_init.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_init.h
@@ -47,7 +47,8 @@
* 04-09-13 02.00.15 Added SCSIStatusQualifier field to MPI2_SCSI_IO_REPLY,
* replacing the Reserved4 field.
* 11-18-14 02.00.16 Updated copyright information.
- * 03-xx-15 02.00.17 Updated for MPI v2.6.
+ * 03-16-15 02.00.17 Updated for MPI v2.6.
+ * Added MPI26_SCSIIO_IOFLAGS_ESCAPE_PASSTHROUGH.
* Added MPI2_SEP_REQ_SLOTSTATUS_DEV_OFF and
* MPI2_SEP_REPLY_SLOTSTATUS_DEV_OFF.
* --
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
b/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
index 26e1ba4..cf510ed 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
@@ -134,7 +134,7 @@
* Added Encrypted Hash Extended Image.
* 12-05-13 02.00.24 Added MPI25_HASH_IMAGE_TYPE_BIOS.
* 11-18-14 02.00.25 Updated copyright information.
- * 03-xx-15 02.00.26 Added MPI26_FW_HEADER_PID_FAMILY_3324_SAS and
+ * 03-16-15 02.00.26 Added MPI26_FW_HEADER_PID_FAMILY_3324_SAS and
* MPI26_FW_HEADER_PID_FAMILY_3516_SAS.
* Added MPI26_CTRL_OP_SHUTDOWN.
* --
[mpt3sas driver 05/10] mpt3sas: Make use of additional HighPriority credit message frames for sending SCSI IO's
From: Suganath prabu Subramani
Driver assumes HighPriority credit as part of Global credit. But,
Firmware treats HighPriority credit value and global cedits as two
different values. Changed host queue algorithm to treat global credits and
highPriority credits as two different values.
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 63 +++---
drivers/scsi/mpt3sas/mpt3sas_base.h | 27 ++
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 154 ++-
3 files changed, 228 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index f59495b..31838d9a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -775,7 +775,7 @@ mpt3sas_base_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8
msix_index,
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
if (mpi_reply && mpi_reply->Function == MPI2_FUNCTION_EVENT_ACK)
- return 1;
+ return mpt3sas_check_for_pending_internal_cmds(ioc, smid);
if (ioc->base_cmds.status == MPT3_CMD_NOT_USED)
return 1;
@@ -806,6 +806,7 @@ _base_async_event(struct MPT3SAS_ADAPTER *ioc, u8
msix_index, u32 reply)
Mpi2EventNotificationReply_t *mpi_reply;
Mpi2EventAckRequest_t *ack_request;
u16 smid;
+ struct _event_ack_list *delayed_event_ack;
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
if (!mpi_reply)
@@ -819,8 +820,18 @@ _base_async_event(struct MPT3SAS_ADAPTER *ioc, u8
msix_index, u32 reply)
goto out;
smid = mpt3sas_base_get_smid(ioc, ioc->base_cb_idx);
if (!smid) {
- pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n",
- ioc->name, __func__);
+ delayed_event_ack = kzalloc(sizeof(*delayed_event_ack),
+ GFP_ATOMIC);
+ if (!delayed_event_ack)
+ goto out;
+ INIT_LIST_HEAD(&delayed_event_ack->list);
+ delayed_event_ack->Event = mpi_reply->Event;
+ delayed_event_ack->EventContext = mpi_reply->EventContext;
+ list_add_tail(&delayed_event_ack->list,
+ &ioc->delayed_event_ack_list);
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "DELAYED: EVENT ACK: event (0x%04x)\n",
+ ioc->name, le16_to_cpu(mpi_reply->Event)));
goto out;
}
@@ -3189,20 +3200,35 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER
*ioc, int sleep_flag)
}
ioc->shost->sg_tablesize = sg_tablesize;
- ioc->hi_priority_depth = facts->HighPriorityCredit;
- ioc->internal_depth = ioc->hi_priority_depth + (5);
+ ioc->internal_depth = min_t(int, (facts->HighPriorityCredit + (5)),
+ (facts->RequestCredit / 4));
+ if (ioc->internal_depth < INTERNAL_CMDS_COUNT) {
+ if (facts->RequestCredit <= (INTERNAL_CMDS_COUNT +
+ INTERNAL_SCSIIO_CMDS_COUNT)) {
+ pr_err(MPT3SAS_FMT "IOC doesn't have enough Request \
+ Credits, it has just %d number of credits\n",
+ ioc->name, facts->RequestCredit);
+ return -ENOMEM;
+ }
+ ioc->internal_depth = 10;
+ }
+
+ ioc->hi_priority_depth = ioc->internal_depth - (5);
/* command line tunables for max controller queue depth */
if (max_queue_depth != -1 && max_queue_depth != 0) {
max_request_credit = min_t(u16, max_queue_depth +
- ioc->hi_priority_depth + ioc->internal_depth,
- facts->RequestCredit);
+ ioc->internal_depth, facts->RequestCredit);
if (max_request_credit > MAX_HBA_QUEUE_DEPTH)
max_request_credit = MAX_HBA_QUEUE_DEPTH;
} else
max_request_credit = min_t(u16, facts->RequestCredit,
MAX_HBA_QUEUE_DEPTH);
- ioc->hba_queue_depth = max_request_credit;
+ /* Firmware maintains additional facts->HighPriorityCredit number of
+* credits for HiPriprity Request messages, so hba queue depth will be
+* sum of max_request_credit and high priority queue depth.
+*/
+ ioc->hba_queue_depth = max_request_credit + ioc->hi_priority_depth;
/* request frame size */
ioc->request_sz = facts->IOCRequestFrameSize * 4;
@@ -3249,7 +3275,6 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
ioc->reply_post_queue_depth += 16 -
(ioc->reply_post_queue_depth % 16);
-
if (ioc->reply_post_queue_depth >
facts->MaxReplyDescriptorPostQueueDepth) {
Re: sound: heap out-of-bounds write in dummy_systimer_prepare
On Wed, 27 Jan 2016 10:55:45 +0100, Dmitry Vyukov wrote: > > Hello, > > I've got the following report while running syzkaller fuzzer: > > == > BUG: KASAN: slab-out-of-bounds in dummy_systimer_prepare+0x268/0x2a0 > at addr 88006067aa30 > Write of size 4 by task syz-executor/5841 > = > BUG kmalloc-192 (Not tainted): kasan: bad access detected > - > > INFO: Allocated in dummy_hrtimer_create+0x49/0x1a0 age=77 cpu=2 pid=5841 > [< inline >] slab_alloc_node mm/slub.c:2562 > [< inline >] slab_alloc mm/slub.c:2604 > [< none >] kmem_cache_alloc_trace+0x25c/0x300 mm/slub.c:2621 > [< inline >] kmalloc include/linux/slab.h:463 > [< inline >] kzalloc include/linux/slab.h:607 > [< none >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:458 > [< none >] dummy_pcm_open+0xef/0x570 sound/drivers/dummy.c:573 > [< none >] snd_pcm_open_substream+0x188/0x430 > sound/core/pcm_native.c:2264 > [< inline >] snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2342 > [< none >] snd_pcm_oss_open.part.17+0x5a4/0x1110 > sound/core/oss/pcm_oss.c:2424 > [< none >] snd_pcm_oss_open+0x35/0x50 sound/core/oss/pcm_oss.c:2388 > [< none >] soundcore_open+0x30f/0x640 sound/sound_core.c:639 > [< none >] chrdev_open+0x22a/0x4c0 fs/char_dev.c:388 > [< none >] do_dentry_open+0x6a2/0xcb0 fs/open.c:736 > [< none >] vfs_open+0x17b/0x1f0 fs/open.c:853 > [< inline >] do_last fs/namei.c:3254 > [< none >] path_openat+0xde9/0x5e30 fs/namei.c:3386 > [< none >] do_filp_open+0x18e/0x250 fs/namei.c:3421 > [< none >] do_sys_open+0x1fc/0x420 fs/open.c:1022 > [< inline >] SYSC_open fs/open.c:1040 > [< none >] SyS_open+0x2d/0x40 fs/open.c:1035 > > INFO: Slab 0xea0001819e00 objects=24 used=20 fp=0x8800606799f0 > flags=0x5fffc004080 > INFO: Object 0x88006067a980 @offset=10624 fp=0x (null) > CPU: 2 PID: 5841 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #291 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > 8800316af4c8 829e798d 88003e804c00 > 88006067a980 880060678000 8800316af4f8 8175b394 > 88003e804c00 ea0001819e00 88006067a980 8002 > > Call Trace: > [< inline >] kasan_report mm/kasan/report.c:274 > [] __asan_report_store4_noabort+0x3e/0x40 > mm/kasan/report.c:299 > [] dummy_systimer_prepare+0x268/0x2a0 > sound/drivers/dummy.c:295 > [] dummy_pcm_prepare+0x7b/0xa0 sound/drivers/dummy.c:512 > [] snd_pcm_do_prepare+0x5a/0x90 > sound/core/pcm_native.c:1512 > [] snd_pcm_action_single+0x76/0x120 > sound/core/pcm_native.c:944 > [] snd_pcm_action_nonatomic+0x95/0xa0 > sound/core/pcm_native.c:1011 > [< inline >] snd_pcm_prepare sound/core/pcm_native.c:1552 > [] snd_pcm_common_ioctl1+0x1045/0x21a0 > sound/core/pcm_native.c:2765 > [] snd_pcm_playback_ioctl1+0x2a2/0x5e0 > sound/core/pcm_native.c:2884 > [] snd_pcm_kernel_ioctl+0x136/0x160 > sound/core/pcm_native.c:3004 > [] snd_pcm_oss_prepare+0x4b/0x200 > sound/core/oss/pcm_oss.c:1112 > [] snd_pcm_oss_make_ready+0xae/0x120 > sound/core/oss/pcm_oss.c:1140 > [] snd_pcm_oss_sync+0xba/0xa30 > sound/core/oss/pcm_oss.c:1609 > [] snd_pcm_oss_release+0x1ad/0x280 > sound/core/oss/pcm_oss.c:2479 > [] __fput+0x236/0x780 fs/file_table.c:208 > [] fput+0x15/0x20 fs/file_table.c:244 > [] task_work_run+0x170/0x210 kernel/task_work.c:115 > [< inline >] exit_task_work include/linux/task_work.h:21 > [] do_exit+0x8b5/0x2cb0 kernel/exit.c:748 > [] do_group_exit+0x108/0x330 kernel/exit.c:878 > [] get_signal+0x5e4/0x14f0 kernel/signal.c:2307 > [] do_signal+0x83/0x1c90 arch/x86/kernel/signal.c:712 > [] exit_to_usermode_loop+0x1a5/0x210 > arch/x86/entry/common.c:247 > [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:282 > [] syscall_return_slowpath+0x2ba/0x340 > arch/x86/entry/common.c:344 > [] int_ret_from_sys_call+0x25/0x9f > arch/x86/entry/entry_64.S:281 > > Memory state around the buggy address: > 88006067a900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > 88006067a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >88006067aa00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc > ^ > 88006067aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > 88006067ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > == > > > The timer is created by dummy_hrtimer_create as hrtimer, but then > accessed by dummy_systimer_prepare as systimer. The root cause seems > to be a data race on dummy->
[mpt3sas driver 09/10] mpt3sas: Fix for Asynchronous completion of timedout IO and task abort of timedout IO.
From: Suganath prabu Subramani
Track msix of each IO and use the same msix for issuing
abort to timed out IO. With this driver will process IO's
reply first followed by TM.
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 20 +++-
drivers/scsi/mpt3sas/mpt3sas_base.h | 5 -
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 12 +---
4 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0f623fb..9307269 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2258,6 +2258,12 @@ mpt3sas_base_get_reply_virt_addr(struct MPT3SAS_ADAPTER
*ioc, u32 phys_addr)
return ioc->reply + (phys_addr - (u32)ioc->reply_dma);
}
+static inline u8
+_base_get_msix_index(struct MPT3SAS_ADAPTER *ioc)
+{
+ return ioc->cpu_msix_table[raw_smp_processor_id()];
+}
+
/**
* mpt3sas_base_get_smid - obtain a free smid from internal queue
* @ioc: per adapter object
@@ -2318,6 +2324,7 @@ mpt3sas_base_get_smid_scsiio(struct MPT3SAS_ADAPTER *ioc,
u8 cb_idx,
request->scmd = scmd;
request->cb_idx = cb_idx;
smid = request->smid;
+ request->msix_io = _base_get_msix_index(ioc);
list_del(&request->tracker_list);
spin_unlock_irqrestore(&ioc->scsi_lookup_lock, flags);
return smid;
@@ -2440,12 +2447,6 @@ _base_writeq(__u64 b, volatile void __iomem *addr,
spinlock_t *writeq_lock)
}
#endif
-static inline u8
-_base_get_msix_index(struct MPT3SAS_ADAPTER *ioc)
-{
- return ioc->cpu_msix_table[raw_smp_processor_id()];
-}
-
/**
* mpt3sas_base_put_smid_scsi_io - send SCSI_IO request to firmware
* @ioc: per adapter object
@@ -2499,18 +2500,19 @@ mpt3sas_base_put_smid_fast_path(struct MPT3SAS_ADAPTER
*ioc, u16 smid,
* mpt3sas_base_put_smid_hi_priority - send Task Managment request to firmware
* @ioc: per adapter object
* @smid: system request message index
- *
+ * @msix_task: msix_task will be same as msix of IO incase of task abort else
0.
* Return nothing.
*/
void
-mpt3sas_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc, u16 smid)
+mpt3sas_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+ u16 msix_task)
{
Mpi2RequestDescriptorUnion_t descriptor;
u64 *request = (u64 *)&descriptor;
descriptor.HighPriority.RequestFlags =
MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY;
- descriptor.HighPriority.MSIxIndex = 0;
+ descriptor.HighPriority.MSIxIndex = msix_task;
descriptor.HighPriority.SMID = cpu_to_le16(smid);
descriptor.HighPriority.LMID = 0;
descriptor.HighPriority.Reserved1 = 0;
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index d1fee34..24bd19a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -649,6 +649,7 @@ struct chain_tracker {
* @cb_idx: callback index
* @direct_io: To indicate whether I/O is direct (WARPDRIVE)
* @tracker_list: list of free request (ioc->free_list)
+ * @msix_io: IO's msix
*/
struct scsiio_tracker {
u16 smid;
@@ -657,6 +658,7 @@ struct scsiio_tracker {
u8 direct_io;
struct list_head chain_list;
struct list_head tracker_list;
+ u16 msix_io;
};
/**
@@ -1245,7 +1247,8 @@ void mpt3sas_base_put_smid_scsi_io(struct MPT3SAS_ADAPTER
*ioc, u16 smid,
u16 handle);
void mpt3sas_base_put_smid_fast_path(struct MPT3SAS_ADAPTER *ioc, u16 smid,
u16 handle);
-void mpt3sas_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc, u16 smid);
+void mpt3sas_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc,
+ u16 smid, u16 msix_task);
void mpt3sas_base_put_smid_default(struct MPT3SAS_ADAPTER *ioc, u16 smid);
void mpt3sas_base_initialize_callback_handler(void);
u8 mpt3sas_base_register_callback_handler(MPT_CALLBACK cb_func);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index d872587..7d00f09 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -832,7 +832,7 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct
mpt3_ioctl_command karg,
tm_request->DevHandle));
ioc->build_sg_mpi(ioc, psge, data_out_dma, data_out_sz,
data_in_dma, data_in_sz);
- mpt3sas_base_put_smid_hi_priority(ioc, smid);
+ mpt3sas_base_put_smid_hi_priority(ioc, smid, 0);
break;
}
case MPI2_FUNCTION_SMP_PASSTHROUGH:
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index b12cada..e0e4920 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2217,6 +2217,7 @@ mpt3sas_scsih_issue_tm(struct MPT
[mpt3sas driver 10/10] mpt3sas: Updating mpt3sas driver version to 12.100.00.00
From: Suganath prabu Subramani Bump mpt3sas driver version from 09.102.00.00 to 12.100.00.00 Signed-off-by: Suganath prabu Subramani Signed-off-by: Chaitra P B --- drivers/scsi/mpt3sas/mpt3sas_base.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index 24bd19a..32580b5 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -73,9 +73,9 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "09.102.00.00" -#define MPT3SAS_MAJOR_VERSION 9 -#define MPT3SAS_MINOR_VERSION 102 +#define MPT3SAS_DRIVER_VERSION "12.100.00.00" +#define MPT3SAS_MAJOR_VERSION 12 +#define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 1.8.3.1
[mpt3sas driver 06/10] mpt3sas: Added smp_affinity_enable module parameter.
From: Suganath prabu Subramani
Module parameter to enable/disable configuring
affinity hint for msix vector.
SMP affinity feature can be enabled/disabled by setting
module parameter "smp_affinity_enable" to 1/0.
By default this feature is enabled. (smp_affinity_enable = 1 enabled).
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 31838d9a..a1a3b39 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -83,6 +83,10 @@ static int msix_disable = -1;
module_param(msix_disable, int, 0);
MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts (default=0)");
+static int smp_affinity_enable = 1;
+module_param(smp_affinity_enable, int, S_IRUGO);
+MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale
Default: enable(1)");
+
static int max_msix_vectors = -1;
module_param(max_msix_vectors, int, 0);
MODULE_PARM_DESC(max_msix_vectors,
@@ -1812,8 +1816,10 @@ _base_free_irq(struct MPT3SAS_ADAPTER *ioc)
list_for_each_entry_safe(reply_q, next, &ioc->reply_queue_list, list) {
list_del(&reply_q->list);
- irq_set_affinity_hint(reply_q->vector, NULL);
- free_cpumask_var(reply_q->affinity_hint);
+ if (smp_affinity_enable) {
+ irq_set_affinity_hint(reply_q->vector, NULL);
+ free_cpumask_var(reply_q->affinity_hint);
+ }
synchronize_irq(reply_q->vector);
free_irq(reply_q->vector, reply_q);
kfree(reply_q);
@@ -1844,9 +1850,11 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 index,
u32 vector)
reply_q->msix_index = index;
reply_q->vector = vector;
- if (!alloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL))
- return -ENOMEM;
- cpumask_clear(reply_q->affinity_hint);
+ if (smp_affinity_enable) {
+ if (!alloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL))
+ return -ENOMEM;
+ cpumask_clear(reply_q->affinity_hint);
+ }
atomic_set(&reply_q->busy, 0);
if (ioc->msix_enable)
@@ -1909,16 +1917,17 @@ _base_assign_reply_queues(struct MPT3SAS_ADAPTER *ioc)
for (i = 0 ; i < group ; i++) {
ioc->cpu_msix_table[cpu] = index;
- cpumask_or(reply_q->affinity_hint,
+ if (smp_affinity_enable)
+ cpumask_or(reply_q->affinity_hint,
reply_q->affinity_hint, get_cpu_mask(cpu));
cpu = cpumask_next(cpu, cpu_online_mask);
}
-
- if (irq_set_affinity_hint(reply_q->vector,
+ if (smp_affinity_enable)
+ if (irq_set_affinity_hint(reply_q->vector,
reply_q->affinity_hint))
- dinitprintk(ioc, pr_info(MPT3SAS_FMT
- "error setting affinity hint for irq vector %d\n",
- ioc->name, reply_q->vector));
+ dinitprintk(ioc, pr_info(MPT3SAS_FMT
+"Err setting affinity hint to irq vector %d\n",
+ioc->name, reply_q->vector));
index++;
}
}
@@ -1976,6 +1985,9 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
} else if (max_msix_vectors == 0)
goto try_ioapic;
+ if (ioc->msix_vector_count < ioc->cpu_count)
+ smp_affinity_enable = 0;
+
entries = kcalloc(ioc->reply_queue_count, sizeof(struct msix_entry),
GFP_KERNEL);
if (!entries) {
--
1.8.3.1
[mpt3sas driver 01/10] mpt3sas: Added support for high port count HBA variants.
From: Suganath prabu Subramani
Updated hardware description headers with MPI v2.6 and mpt3sas_pci_table[]
with vendor_ids,device_ids of Cutlass and Intruder HBA which has support
for 4 ports
Signed-off-by: Suganath prabu Subramani
Signed-off-by: Chaitra P B
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 78 +++---
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 124 +++
drivers/scsi/mpt3sas/mpi/mpi2_init.h | 21 --
drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 117 ++---
drivers/scsi/mpt3sas/mpi/mpi2_raid.h | 5 +-
drivers/scsi/mpt3sas/mpi/mpi2_sas.h | 10 ++-
drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 5 +-
drivers/scsi/mpt3sas/mpi/mpi2_type.h | 5 +-
drivers/scsi/mpt3sas/mpt3sas_base.c | 5 ++
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 32 +++--
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 80 ++
11 files changed, 423 insertions(+), 59 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index ec27ad2..367e6ac 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2000-2014 LSI Corporation.
+ * Copyright 2000-2015 Avago Technologies. All rights reserved.
*
*
* Name: mpi2.h
@@ -8,7 +8,7 @@
* scatter/gather formats.
* Creation Date: June 21, 2006
*
- * mpi2.h Version: 02.00.35
+ * mpi2.h Version: 02.00.37
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -92,6 +92,12 @@
* 12-05-13 02.00.33 Bumped MPI2_HEADER_VERSION_UNIT.
* 01-08-14 02.00.34 Bumped MPI2_HEADER_VERSION_UNIT
* 06-13-14 02.00.35 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 11-18-14 02.00.36 Updated copyright information.
+ * Bumped MPI2_HEADER_VERSION_UNIT.
+ * 03-xx-15 02.00.37 Bumped MPI2_HEADER_VERSION_UNIT.
+ * Added Scratchpad registers to
+ * MPI2_SYSTEM_INTERFACE_REGS.
+ * Added MPI2_DIAG_SBR_RELOAD.
* --
*/
@@ -124,6 +130,12 @@
MPI25_VERSION_MINOR)
#define MPI2_VERSION_02_05 (0x0205)
+/*minor version for MPI v2.6 compatible products */
+#define MPI26_VERSION_MINOR(0x06)
+#define MPI26_VERSION ((MPI2_VERSION_MAJOR << MPI2_VERSION_MAJOR_SHIFT) | \
+ MPI26_VERSION_MINOR)
+#define MPI2_VERSION_02_06 (0x0206)
+
/*Unit and Dev versioning for this MPI header set */
#define MPI2_HEADER_VERSION_UNIT(0x23)
#define MPI2_HEADER_VERSION_DEV (0x00)
@@ -179,10 +191,12 @@ typedef volatile struct _MPI2_SYSTEM_INTERFACE_REGS {
U32 HCBSize;/*0x74 */
U32 HCBAddressLow; /*0x78 */
U32 HCBAddressHigh; /*0x7C */
- U32 Reserved6[16]; /*0x80 */
+ U32 Reserved6[12]; /*0x80 */
+ U32 Scratchpad[4]; /*0xB0 */
U32 RequestDescriptorPostLow; /*0xC0 */
U32 RequestDescriptorPostHigh; /*0xC4 */
- U32 Reserved7[14]; /*0xC8 */
+ U32 AtomicRequestDescriptorPost;/*0xC8 */
+ U32 Reserved7[13]; /*0xCC */
} MPI2_SYSTEM_INTERFACE_REGS,
*PTR_MPI2_SYSTEM_INTERFACE_REGS,
Mpi2SystemInterfaceRegs_t,
@@ -224,6 +238,8 @@ typedef volatile struct _MPI2_SYSTEM_INTERFACE_REGS {
*/
#define MPI2_HOST_DIAGNOSTIC_OFFSET (0x0008)
+#define MPI2_DIAG_SBR_RELOAD(0x2000)
+
#define MPI2_DIAG_BOOT_DEVICE_SELECT_MASK (0x1800)
#define MPI2_DIAG_BOOT_DEVICE_SELECT_DEFAULT(0x)
#define MPI2_DIAG_BOOT_DEVICE_SELECT_HCDW (0x0800)
@@ -298,10 +314,19 @@ typedef volatile struct _MPI2_SYSTEM_INTERFACE_REGS {
#define MPI2_HCB_ADDRESS_HIGH_OFFSET(0x007C)
/*
- *Offsets for the Request Queue
+ *Offsets for the Scratchpad registers
+ */
+#define MPI26_SCRATCHPAD0_OFFSET(0x00B0)
+#define MPI26_SCRATCHPAD1_OFFSET(0x00B4)
+#define MPI26_SCRATCHPAD2_OFFSET(0x00B8)
+#define MPI26_SCRATCHPAD3_OFFSET(0x00BC)
+
+/*
+ *Offsets for the Request Descriptor Post Queue
*/
#define MPI2_REQUEST_DESCRIPTOR_POST_LOW_OFFSET (0x00C0)
#define MPI2_REQUEST_DESCRIPTOR_POST_HIGH_OFFSET(0x00C4)
+#define MPI26_ATOMIC_REQUEST_DESCRIPTOR_POST_OFFSET (0x00C8)
/*Hard Reset delay timings */
#define MPI2_HARD_RESET_PCIE_FIRST_READ_DELAY_MICRO_SEC (5)
@@ -329,7 +354,8 @@ typedef struct _MPI2_DEFAULT_REQUEST_DESCRIPTOR {
*pMpi2DefaultRequestDescriptor_t;
/*defines for the RequestFlags field */
-#define MPI2_REQ_DESCRIPT_FLAGS_TYPE_MASK (0x0E)
+#define MPI2_REQ_DESCRIPT_FLAGS_TYPE_MASK (0x1E)
+#define
[mpt3sas driver 03/10] mpt3sas: Fix static analyzer(coverity) tool identified defects
From: Suganath prabu Subramani 1.Wrong size of argument is being passed The size of struct being passed as an argument to memset func and area of memory being pointed by an instance of struct in memset func should be of same structure type. 2.Dereference null return value 3.Array compared against '0' Check whether value pointed by particular index of an array is null or not in "if" statement. Signed-off-by: Suganath prabu Subramani Signed-off-by: Chaitra P B --- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 3 ++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++-- drivers/scsi/mpt3sas/mpt3sas_transport.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c index ef9971e..d872587 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c @@ -401,7 +401,8 @@ mpt3sas_ctl_event_callback(struct MPT3SAS_ADAPTER *ioc, u8 msix_index, Mpi2EventNotificationReply_t *mpi_reply; mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply); - mpt3sas_ctl_add_to_event_log(ioc, mpi_reply); + if (mpi_reply) + mpt3sas_ctl_add_to_event_log(ioc, mpi_reply); return 1; } diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 0fb4ccd..686a46a 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -2399,7 +2399,7 @@ _scsih_tm_display_info(struct MPT3SAS_ADAPTER *ioc, struct scsi_cmnd *scmd) (unsigned long long) sas_device->enclosure_logical_id, sas_device->slot); - if (sas_device->connector_name) + if (sas_device->connector_name[0] != '\0') starget_printk(KERN_INFO, starget, "enclosure level(0x%04x),connector name(%s)\n", sas_device->enclosure_level, @@ -3134,7 +3134,7 @@ _scsih_tm_tr_send(struct MPT3SAS_ADAPTER *ioc, u16 handle) " slot(%d)\n", ioc->name, (unsigned long long) sas_device->enclosure_logical_id, sas_device->slot)); - if (sas_device->connector_name) + if (sas_device->connector_name[0] != '\0') dewtprintk(ioc, pr_info(MPT3SAS_FMT "setting delete flag: enclosure level(0x%04x)," " connector name( %s)\n", ioc->name, diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c index df08aeb..6a84b82 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_transport.c +++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c @@ -1600,7 +1600,7 @@ _transport_phy_reset(struct sas_phy *phy, int hard_reset) SMP_PHY_CONTROL_LINK_RESET); /* handle hba phys */ - memset(&mpi_request, 0, sizeof(Mpi2SasIoUnitControlReply_t)); + memset(&mpi_request, 0, sizeof(Mpi2SasIoUnitControlRequest_t)); mpi_request.Function = MPI2_FUNCTION_SAS_IO_UNIT_CONTROL; mpi_request.Operation = hard_reset ? MPI2_SAS_OP_PHY_HARD_RESET : MPI2_SAS_OP_PHY_LINK_RESET; -- 1.8.3.1
[mpt3sas driver patches 00/10] mpt3sas driver enhancements and
From: Suganath prabu Subramani Here is the change list: Posting 10 patches for mpt3sas driver enhancements and few fixes. * Updated hardware description headers with MPI v2.6 and mpt3sas_pci_table[] with vendor_ids,device_ids of Cutlass and Intruder HBA which has support for 4 ports. * Static analyzer(coverity) tool identified defects. * Never block the SEP device even for the delay not responding events. Blocking the SEP device will create a deadlock while adding any device to the OS. * Modified host queue algorithm to treat global credits and highPriority credits as two different values. * Module parameter to enable/disable configuring affinity hint for msix vector. * Added support for configurable Chain Frame Size for SAS 3.0 HBA'S. * Updated MPI version and MPI header files. * Fix for Asynchronous completion of timedout IO and task abort of timedout IO. * Updated driver version to 12.100.00.00 Suganath prabu Subramani (10): mpt3sas: Added support for high port count HBA variants. mpt3sas: Used IEEE SGL instead of MPI SGL while framing a SMP Passthrough request message. mpt3sas: Fix static analyzer(coverity) tool identified defects mpt3sas: Never block the Enclosure device mpt3sas: Make use of additional HighPriority credit message frames for sending SCSI IO's mpt3sas: Added smp_affinity_enable module parameter. mpt3sas: Add support for configurable Chain Frame Size mpt3sas: Updated MPI Header to 2.00.42 mpt3sas: Fix for Asynchronous completion of timedout IO and task abort of timedout IO. mpt3sas: Updating mpt3sas driver version to 12.100.00.00 drivers/scsi/mpt3sas/mpi/mpi2.h | 82 +- drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 127 +-- drivers/scsi/mpt3sas/mpi/mpi2_init.h | 22 ++- drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 117 - drivers/scsi/mpt3sas/mpi/mpi2_raid.h | 5 +- drivers/scsi/mpt3sas/mpi/mpi2_sas.h | 10 +- drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 5 +- drivers/scsi/mpt3sas/mpi/mpi2_type.h | 5 +- drivers/scsi/mpt3sas/mpt3sas_base.c | 149 - drivers/scsi/mpt3sas/mpt3sas_base.h | 47 +- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 37 - drivers/scsi/mpt3sas/mpt3sas_scsih.c | 272 --- drivers/scsi/mpt3sas/mpt3sas_transport.c | 25 +-- 13 files changed, 769 insertions(+), 134 deletions(-) Thanks, Suganath prabu S -- 1.8.3.1
Re: [PATCH V5 5/5] regulator: max77620: add regulator driver for max77620/max20024
On Thursday 28 January 2016 09:25 AM, Krzysztof Kozlowski wrote: On 27.01.2016 23:10, Laxman Dewangan wrote: MAXIM Semiconductor's PMIC, MAX77620 and MAX20024 have the multiple DCDC and LDOs. This supplies the power to different components of the system. Also these rails has configuration for ramp time, flexible power sequence, slew rate etc. Add regulator driver to access these rails via regulator APIs. Signed-off-by: Laxman Dewangan Signed-off-by: Mallikarjun Kasoju --- Changes from V1: - Cleanup code based on comment received on mfd/rtc. - Avoid duplication on error message. Changes form V2: - Run coccicheck and checkpatch in strict mode for the alignment. - Refactor Regulator driver to use core API for DT parsing. - Update based on API changes. Changes from V3: - Change all sys initcall to module driver. - change the max77620_read argument to unisgned int from u8. Changes from V4: - Added DT binding document as devicetree/bindings/regulator/regulator-max77620.txt - Detail out properties. What does it mean "Detail out properties"? What have changed> Based on review comment from Linus W, I added more description on the properties. .../bindings/regulator/regulator-max77620.txt | 163 Please put the bindings in separate patch. It might be easier for DT guys to review them (they are acking the bindings, not the driver). Also OK, will push it. I already reviewed the patchset but because of adding bindings here, you could not add my reviewed-by tag (which makes my effort not tracked...). Yaah, This patch include the dt binding and so wanted your review again. This si only reason to not add reviewed-by. Now I am going to separate out DT binding and driver, I will add reviewed-by tag for you in driver file.
[PATCH v11 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h
Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic
discovery of kvm events (if its needed). To do this, some extern
variables have been introduced with which we can keep the generic
functions generic.
Signed-off-by: Hemant Kumar
Acked-by: Alexander Yarygin
---
Changelog:
v10 to v11:
- No changes.
v9 to v10:
- Changed from dynamic to static declaration of "decode".
v8 to v9:
- Removed the macro definitions.
- Changed the access of kvm_entry_trace and kvm_exit_trace
- Removed unnecessary formatting.
v7 to v8:
- Removed unnecessary __unused_parameter modifiers.
tools/perf/arch/s390/util/kvm-stat.c | 8 +++-
tools/perf/arch/x86/util/kvm-stat.c | 14 +++---
tools/perf/builtin-kvm.c | 20 ++--
tools/perf/util/kvm-stat.h | 5 +
4 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/tools/perf/arch/s390/util/kvm-stat.c
b/tools/perf/arch/s390/util/kvm-stat.c
index a5dbc07..b85a94b 100644
--- a/tools/perf/arch/s390/util/kvm-stat.c
+++ b/tools/perf/arch/s390/util/kvm-stat.c
@@ -10,7 +10,7 @@
*/
#include "../../util/kvm-stat.h"
-#include
+#include
define_exit_reasons_table(sie_exit_reasons, sie_intercept_code);
define_exit_reasons_table(sie_icpt_insn_codes, icpt_insn_codes);
@@ -18,6 +18,12 @@ define_exit_reasons_table(sie_sigp_order_codes,
sigp_order_codes);
define_exit_reasons_table(sie_diagnose_codes, diagnose_codes);
define_exit_reasons_table(sie_icpt_prog_codes, icpt_prog_codes);
+const char *vcpu_id_str = "id";
+const int decode_str_len = 40;
+const char *kvm_exit_reason = "icptcode";
+const char *kvm_entry_trace = "kvm:kvm_s390_sie_enter";
+const char *kvm_exit_trace = "kvm:kvm_s390_sie_exit";
+
static void event_icpt_insn_get_key(struct perf_evsel *evsel,
struct perf_sample *sample,
struct event_key *key)
diff --git a/tools/perf/arch/x86/util/kvm-stat.c
b/tools/perf/arch/x86/util/kvm-stat.c
index 14e4e66..babefda 100644
--- a/tools/perf/arch/x86/util/kvm-stat.c
+++ b/tools/perf/arch/x86/util/kvm-stat.c
@@ -1,5 +1,7 @@
#include "../../util/kvm-stat.h"
-#include
+#include
+#include
+#include
define_exit_reasons_table(vmx_exit_reasons, VMX_EXIT_REASONS);
define_exit_reasons_table(svm_exit_reasons, SVM_EXIT_REASONS);
@@ -11,6 +13,12 @@ static struct kvm_events_ops exit_events = {
.name = "VM-EXIT"
};
+const char *vcpu_id_str = "vcpu_id";
+const int decode_str_len = 20;
+const char *kvm_exit_reason = "exit_reason";
+const char *kvm_entry_trace = "kvm:kvm_entry";
+const char *kvm_exit_trace = "kvm:kvm_exit";
+
/*
* For the mmio events, we treat:
* the time of MMIO write: kvm_mmio(KVM_TRACE_MMIO_WRITE...) -> kvm_entry
@@ -65,7 +73,7 @@ static void mmio_event_decode_key(struct perf_kvm_stat *kvm
__maybe_unused,
struct event_key *key,
char *decode)
{
- scnprintf(decode, DECODE_STR_LEN, "%#lx:%s",
+ scnprintf(decode, decode_str_len, "%#lx:%s",
(unsigned long)key->key,
key->info == KVM_TRACE_MMIO_WRITE ? "W" : "R");
}
@@ -109,7 +117,7 @@ static void ioport_event_decode_key(struct perf_kvm_stat
*kvm __maybe_unused,
struct event_key *key,
char *decode)
{
- scnprintf(decode, DECODE_STR_LEN, "%#llx:%s",
+ scnprintf(decode, decode_str_len, "%#llx:%s",
(unsigned long long)key->key,
key->info ? "POUT" : "PIN");
}
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 4418d92..ab5645c 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -30,7 +30,6 @@
#include
#ifdef HAVE_KVM_STAT_SUPPORT
-#include
#include "util/kvm-stat.h"
void exit_event_get_key(struct perf_evsel *evsel,
@@ -38,12 +37,12 @@ void exit_event_get_key(struct perf_evsel *evsel,
struct event_key *key)
{
key->info = 0;
- key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
+ key->key = perf_evsel__intval(evsel, sample, kvm_exit_reason);
}
bool kvm_exit_event(struct perf_evsel *evsel)
{
- return !strcmp(evsel->name, KVM_EXIT_TRACE);
+ return !strcmp(evsel->name, kvm_exit_trace);
}
bool exit_event_begin(struct perf_evsel *evsel,
@@ -59,7 +58,7 @@ bool exit_event_begin(struct perf_evsel *evsel,
bool kvm_entry_event(struct perf_evsel *evsel)
{
- return !strcmp(evsel->name, KVM_ENTRY_TRACE);
+ return !strcmp(evsel->name, kvm_entry_trace);
}
bool exit_event_end(struct perf_evsel *evsel,
@@ -91,7 +90,7 @@ void exit_event_decode_key(struct perf_kvm_stat *kvm,
const char *exit_reason = get_exit_reason(kvm, key->exit_reasons,
key->key);
- scnprintf(decode, DECODE_STR_LEN, "%s", exit_reason);
+ scnprintf(decode, decode_str_le
[PATCH v11 4/4] perf,kvm/powerpc: Add support for HCALL reasons
Powerpc provides hcall events that also provides insights into guest
behaviour. Enhance perf kvm stat to record and analyze hcall events.
- To trace hcall events :
perf kvm stat record
- To show the results :
perf kvm stat report --event=hcall
The result shows the number of hypervisor calls from the guest grouped
by their respective reasons displayed with the frequency.
This patch makes use of two additional tracepoints
"kvm_hv:kvm_hcall_enter" and "kvm_hv:kvm_hcall_exit". To map the hcall
codes to their respective names, it needs a mapping. Such mapping is
added in this patch in book3s_hcalls.h.
# pgrep qemu
A sample output :
19378
60515
2 VMs running.
# perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624
samples) ]
# perf kvm stat report -p 60515 --event=hcall
Analyze events for all VMs, all VCPUs:
HCALL-EVENTSamples Samples% Time%Min TimeMax Time
Avg time
H_IPI82266.08%88.10% 0.63us 11.38us
2.05us ( +- 1.42% )
H_SEND_CRQ14411.58% 3.77% 0.41us 0.88us
0.50us ( +- 1.47% )
H_VIO_SIGNAL118 9.49% 2.86% 0.37us 0.83us
0.47us ( +- 1.43% )
H_PUT_TERM_CHAR 76 6.11% 2.07% 0.37us 0.90us
0.52us ( +- 2.43% )
H_GET_TERM_CHAR 74 5.95% 2.23% 0.37us 1.70us
0.58us ( +- 4.77% )
H_RTAS 6 0.48% 0.85% 1.10us 9.25us
2.70us ( +- 48.57% )
H_PERFMON 4 0.32% 0.12% 0.41us 0.96us
0.59us ( +- 20.92% )
Total Samples:1244, Total events handled time:1916.69us.
Signed-off-by: Hemant Kumar
---
Changelog:
v9 to v11:
- No Changes.
v8 to v9:
- Removed the macros (which were being used only once).
v6 to v7:
- Removed dependency on uapi.
v4 to v5:
- Removed dependency on arch/powerpc/include/asm/hvall.h and added them
in userspace side.
- No more arch side dependency.
v1 to v2:
- Split the patches for powerpc and perf.
tools/perf/arch/powerpc/util/book3s_hcalls.h | 123 +++
tools/perf/arch/powerpc/util/kvm-stat.c | 65 +-
2 files changed, 187 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/powerpc/util/book3s_hcalls.h
diff --git a/tools/perf/arch/powerpc/util/book3s_hcalls.h
b/tools/perf/arch/powerpc/util/book3s_hcalls.h
new file mode 100644
index 000..0dd6b7f
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/book3s_hcalls.h
@@ -0,0 +1,123 @@
+#ifndef ARCH_PERF_BOOK3S_HV_HCALLS_H
+#define ARCH_PERF_BOOK3S_HV_HCALLS_H
+
+/*
+ * PowerPC HCALL codes : hcall code to name mapping
+ */
+#define kvm_trace_symbol_hcall \
+ {0x4, "H_REMOVE"}, \
+ {0x8, "H_ENTER"}, \
+ {0xc, "H_READ"},\
+ {0x10, "H_CLEAR_MOD"}, \
+ {0x14, "H_CLEAR_REF"}, \
+ {0x18, "H_PROTECT"},\
+ {0x1c, "H_GET_TCE"},\
+ {0x20, "H_PUT_TCE"},\
+ {0x24, "H_SET_SPRG0"}, \
+ {0x28, "H_SET_DABR"}, \
+ {0x2c, "H_PAGE_INIT"}, \
+ {0x30, "H_SET_ASR"},\
+ {0x34, "H_ASR_ON"}, \
+ {0x38, "H_ASR_OFF"},\
+ {0x3c, "H_LOGICAL_CI_LOAD"},\
+ {0x40, "H_LOGICAL_CI_STORE"}, \
+ {0x44, "H_LOGICAL_CACHE_LOAD"}, \
+ {0x48, "H_LOGICAL_CACHE_STORE"},\
+ {0x4c, "H_LOGICAL_ICBI"}, \
+ {0x50, "H_LOGICAL_DCBF"}, \
+ {0x54, "H_GET_TERM_CHAR"}, \
+ {0x58, "H_PUT_TERM_CHAR"}, \
+ {0x5c, "H_REAL_TO_LOGICAL"},\
+ {0x60, "H_HYPERVISOR_DATA"},\
+ {0x64, "H_EOI"},\
+ {0x68, "H_CPPR"}, \
+ {0x6c, "H_IPI"},\
+ {0x70, "H_IPOLL"}, \
+ {0x74, "H_XIRR"}, \
+ {0x78, "H_MIGRATE_DMA"},\
+ {0x7c, "H_PERFMON"},\
+ {0xdc, "H_REGISTER_VPA"}, \
+ {0xe0, "H_CEDE"}, \
+ {0xe4, "H_CONFER"},
[PATCH v11 3/4] perf,kvm/powerpc: Port perf kvm stat to powerpc
perf kvm can be used to analyze guest exit reasons. This support already
exists in x86. Hence, porting it to powerpc.
- To trace KVM events :
perf kvm stat record
If many guests are running, we can track for a specific guest by using
--pid as in : perf kvm stat record --pid
- To see the results :
perf kvm stat report
The result shows the number of exits (from the guest context to
host/hypervisor context) grouped by their respective exit reasons with
their frequency.
Since, different powerpc machines have different KVM tracepoints, this
patch discovers the available tracepoints dynamically and accordingly
looks for them. If any single tracepoint is not present, this support
won't be enabled for reporting. To record, this will fail if any of the
events we are looking to record isn't available.
Right now, its only supported on PowerPC Book3S_HV architectures.
To analyze the different exits, group them and present them (in a slight
descriptive way) to the user, we need a mapping between the "exit
code" (dumped in the kvm_guest_exit tracepoint data) and to its related
Interrupt vector description (exit reason). This patch adds this mapping
in book3s_hv_exits.h.
It records on two available KVM tracepoints for book3s_hv:
"kvm_hv:kvm_guest_exit" and "kvm_hv:kvm_guest_enter".
Here is a sample o/p:
# pgrep qemu
19378
60515
2 Guests are running on the host.
# perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624
samples) ]
# perf kvm stat report -p 60515
Analyze events for pid(s) 60515, all VCPUs:
VM-EXITSamples Samples% Time%Min TimeMax Time
Avg time
SYSCALL 914163.67% 7.49% 1.26us 5782.39us
9.87us ( +- 6.46% )
H_DATA_STORAGE 411428.66% 5.07% 1.72us 4597.68us
14.84us ( +- 20.06% )
HV_DECREMENTER418 2.91% 4.26% 0.70us 30002.22us
122.58us ( +- 70.29% )
EXTERNAL392 2.73% 0.06% 0.64us104.10us
1.94us ( +- 18.83% )
RETURN_TO_HOST287 2.00%83.11% 1.53us 124240.15us
3486.52us ( +- 16.81% )
H_INST_STORAGE 5 0.03% 0.00% 1.88us 3.73us
2.39us ( +- 14.20% )
Total Samples:14357, Total events handled time:1203918.42us.
Signed-off-by: Srikar Dronamraju
Signed-off-by: Hemant Kumar
---
Changelog:
v10 to v11:
- Fixed a bug related to tracepoint_error when rebasing to v4.5-rc1.
v8 to v9:
- Moved the book3s specific setup into one function.
- Removed the macros (which were being used only once).
- Formatting changes.
v7 to v8:
- Fixed a perf kvm stat live bug.
v6 to v7:
- Removed dependency on uapi.
v4 to v5:
- Removed dependency on arch/powerpc/kvm/trace_book3s.h and added them in
the userspace side.
- No more arch side dependency.
v1 to v3:
- Split the patches for powerpc and perf
tools/perf/arch/powerpc/Makefile | 2 +
tools/perf/arch/powerpc/util/Build | 1 +
tools/perf/arch/powerpc/util/book3s_hv_exits.h | 33
tools/perf/arch/powerpc/util/kvm-stat.c| 107 +
tools/perf/builtin-kvm.c | 18 +
tools/perf/util/kvm-stat.h | 1 +
6 files changed, 162 insertions(+)
create mode 100644 tools/perf/arch/powerpc/util/book3s_hv_exits.h
create mode 100644 tools/perf/arch/powerpc/util/kvm-stat.c
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 7fbca17..9f9cea3 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -1,3 +1,5 @@
ifndef NO_DWARF
PERF_HAVE_DWARF_REGS := 1
endif
+
+HAVE_KVM_STAT_SUPPORT := 1
diff --git a/tools/perf/arch/powerpc/util/Build
b/tools/perf/arch/powerpc/util/Build
index 7b8b0d1..c8fe207 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,6 @@
libperf-y += header.o
libperf-y += sym-handling.o
+libperf-y += kvm-stat.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/book3s_hv_exits.h
b/tools/perf/arch/powerpc/util/book3s_hv_exits.h
new file mode 100644
index 000..e68ba2d
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/book3s_hv_exits.h
@@ -0,0 +1,33 @@
+#ifndef ARCH_PERF_BOOK3S_HV_EXITS_H
+#define ARCH_PERF_BOOK3S_HV_EXITS_H
+
+/*
+ * PowerPC Interrupt vectors : exit code to name mapping
+ */
+
+#define kvm_trace_symbol_exit \
+ {0x0, "RETURN_TO_HOST"}, \
+ {0x100, "SYSTEM_RESET"}, \
+ {0x200, "MACHINE_CHECK"}, \
+ {0x300, "DATA_STORAGE"}, \
+ {0x380, "DATA_SEGMENT"}, \
+ {0x400, "INST_STORAGE"}, \
+ {0x480, "INST_SEGMENT"}, \
+ {0x500, "EXTERNAL"}, \
+ {0x501, "EXTERNAL_LEVEL"}, \
+ {0x502, "EXTERNAL_HV"}, \
+ {0x600, "ALIGNMENT"}, \
+ {0x700, "PROGRAM"}, \
+ {0x800, "FP_UNAVAIL"},
[PATCH v11 2/4] perf,kvm/{x86,s390}: Remove const from kvm_events_tp
This patch removes the "const" qualifier from kvm_events_tp declaration
to account for the fact that some architectures may need to update this
variable dynamically. For instance, powerpc will need to update this
variable dynamically depending on the machine type.
Signed-off-by: Hemant Kumar
---
Changelog:
v1 to v11:
- No Changes.
tools/perf/arch/s390/util/kvm-stat.c | 2 +-
tools/perf/arch/x86/util/kvm-stat.c | 2 +-
tools/perf/util/kvm-stat.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/s390/util/kvm-stat.c
b/tools/perf/arch/s390/util/kvm-stat.c
index b85a94b..ed57df2 100644
--- a/tools/perf/arch/s390/util/kvm-stat.c
+++ b/tools/perf/arch/s390/util/kvm-stat.c
@@ -79,7 +79,7 @@ static struct kvm_events_ops exit_events = {
.name = "VM-EXIT"
};
-const char * const kvm_events_tp[] = {
+const char *kvm_events_tp[] = {
"kvm:kvm_s390_sie_enter",
"kvm:kvm_s390_sie_exit",
"kvm:kvm_s390_intercept_instruction",
diff --git a/tools/perf/arch/x86/util/kvm-stat.c
b/tools/perf/arch/x86/util/kvm-stat.c
index babefda..b63d4be 100644
--- a/tools/perf/arch/x86/util/kvm-stat.c
+++ b/tools/perf/arch/x86/util/kvm-stat.c
@@ -129,7 +129,7 @@ static struct kvm_events_ops ioport_events = {
.name = "IO Port Access"
};
-const char * const kvm_events_tp[] = {
+const char *kvm_events_tp[] = {
"kvm:kvm_entry",
"kvm:kvm_exit",
"kvm:kvm_mmio",
diff --git a/tools/perf/util/kvm-stat.h b/tools/perf/util/kvm-stat.h
index dd55548..c965dc8 100644
--- a/tools/perf/util/kvm-stat.h
+++ b/tools/perf/util/kvm-stat.h
@@ -133,7 +133,7 @@ bool kvm_entry_event(struct perf_evsel *evsel);
*/
int cpu_isa_init(struct perf_kvm_stat *kvm, const char *cpuid);
-extern const char * const kvm_events_tp[];
+extern const char *kvm_events_tp[];
extern struct kvm_reg_events_ops kvm_reg_events_ops[];
extern const char * const kvm_skip_events[];
extern const char *vcpu_id_str;
--
1.9.3
Re: [PATCH 1/1] imx25: Fix LCD pixelclock configuration
On Wed, Dec 23, 2015 at 09:30:10PM +0100, Carlos Soto wrote: > Set LCDC base clock (per_7) parent clock to UPLL clock. > This is needed to allow finer resolution in pixelclock > > Signed-off-by: Carlos Soto > --- > drivers/clk/imx/clk-imx25.c |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c > index c4c141c..656340e 100644 > --- a/drivers/clk/imx/clk-imx25.c > +++ b/drivers/clk/imx/clk-imx25.c > @@ -238,6 +238,12 @@ static int __init __mx25_clocks_init(unsigned long > osc_rate, > clk_set_parent(clk[per5_sel], clk[ahb]); > > /* > + * set LCDC base clock (per 7) to highest possible frequency (UPLL) > + * to get best resolution for pixel clock > + */ > + clk_set_parent(clk[per7_sel], clk[upll]); This can be done in device tree via assigned-clock-parents without the need of touching kernel. Shawn > + > + /* >* Let's initially set up CLKO parent as ipg, since this configuration >* is used on some imx25 board designs to clock the audio codec. >*/ > -- > 1.7.10.4 > >
Re: [PULL] virtio: fixes, tests
Linus Torvalds writes: > On Wed, Jan 27, 2016 at 2:15 PM, Michael S. Tsirkin wrote: >>> >>> Anyway, pulled. Just curious about how that thing happened. >> >> That's because apparently diffstat obeys orderfile rules: > > Ugh. I guess that makes sense, but it's still very annoying for > something like a pull request, where now different people end up > having different diffstats. And the reason I never noticed it is that > likely there aren't that many people who use an orderfile. > > I guess something like "-O /dev/null" in the pull-request would undo > it, but it is a bit annoying. > > I've never actually met anybody (knowingly) that used that option. I > thought it was a Junio-only use case (it's been around forever as a > command line option, but the config file entry seems to be somewhat > recent and I wasn't even aware of it). > > Adding Junio just as background to see what he thinks. Looks like the > diff.orderfile config option hits not just porcelain, but plumbing > too. Note: without enough context, I am guessing that you are annoyed that diffstat graph in a pull request did not match what you got locally after pulling. I've never actually met anybody who uses the orderfile, either. And I tend to agree that it probably is a mistake if the configuration is not limited to diff_ui_config(). Wait. It _is_ limited to diff_ui_config(). The thing is, "git request-pull" does use the Porcelain "git diff" to emit the final diffstat. So there is nothing to fix in diff.c, at least ;-) I am of two minds about the configuration affecting the output from "git request-pull" command as a whole. In a sense, "request-pull" command itself _is_ a UI level thing, i.e. Porcelain, and if a project chooses to standardize on a certain patch/diff presentation order using the diff.orderfile facility, there should be a way to tell your project participants to use the same order when they send in their patches and their pull requests, but with the hardcoded "git diff --stat" invocation at the end of "git request-pull", such a per-project customization must happen via _some_ configuration variable. We _could_ make up request-pull.difforderfile that is read by that script and gets turned into "-O $file" arguments to the "git diff" invocation, but if projects really wants to standardize on a single patch/diff presentation order, I do not think such a split configuration buys us anything. We'd be better off using a single diff.orderfile and have it consistently honoured by tools everybody who participates in the project uses. You obviously can declare "With MY project, the standard order in which you must present patch/diff is with this empty file", and tell your project participants to set diff.orderfile to /dev/null in the repository config when they work on the kernel. That would be what any such hypothetical project would do, when it has a specific preference of the patch/diff presentation order. After all, you do have a specific preference, which is "do not futz with the order in which Git gives the paths by default", so...
Re: [PATCH] crypto: af_alg - add async support to algif_aead
Am Mittwoch, 27. Januar 2016, 14:10:31 schrieb Tadeusz Struk:
Hi Tadeusz,
> Following the async change for algif_skcipher
> this patch adds similar async read to algif_aead.
>
> changes in v2:
> - change internal data structures from fixed size arrays, limited to
> RSGL_MAX_ENTRIES, to linked list model with no artificial limitation.
Thank you for the dynamic allocation support, but I do have a question.
> - use sock_kmalloc instead of kmalloc for memory allocation
> - use sock_hold instead of separate atomic ctr to wait for outstanding
> request
>
> Signed-off-by: Tadeusz Struk
> ---
> crypto/algif_aead.c | 278
> +-- 1 file changed, 248
> insertions(+), 30 deletions(-)
>
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 147069c..3fa1a95 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -29,15 +29,24 @@ struct aead_sg_list {
> struct scatterlist sg[ALG_MAX_PAGES];
> };
>
> +struct aead_async_rsgl {
> + struct af_alg_sgl sgl;
> + struct list_head list;
> +};
> +
> +struct aead_async_req {
> + struct scatterlist *tsgl;
> + struct aead_async_rsgl first_rsgl;
> + struct list_head list;
> + struct kiocb *iocb;
> + unsigned int tsgls;
> + char iv[];
> +};
> +
> struct aead_ctx {
> struct aead_sg_list tsgl;
> - /*
> - * RSGL_MAX_ENTRIES is an artificial limit where user space at maximum
> - * can cause the kernel to allocate RSGL_MAX_ENTRIES * ALG_MAX_PAGES
> - * pages
> - */
> -#define RSGL_MAX_ENTRIES ALG_MAX_PAGES
> - struct af_alg_sgl rsgl[RSGL_MAX_ENTRIES];
> + struct aead_async_rsgl first_rsgl;
> + struct list_head list;
>
> void *iv;
>
> @@ -75,6 +84,17 @@ static inline bool aead_sufficient_data(struct aead_ctx
> *ctx) return ctx->used >= ctx->aead_assoclen + as;
> }
>
> +static void aead_reset_ctx(struct aead_ctx *ctx)
> +{
> + struct aead_sg_list *sgl = &ctx->tsgl;
> +
> + sg_init_table(sgl->sg, ALG_MAX_PAGES);
> + sgl->cur = 0;
> + ctx->used = 0;
> + ctx->more = 0;
> + ctx->merge = 0;
> +}
> +
> static void aead_put_sgl(struct sock *sk)
> {
> struct alg_sock *ask = alg_sk(sk);
> @@ -90,11 +110,6 @@ static void aead_put_sgl(struct sock *sk)
> put_page(sg_page(sg + i));
> sg_assign_page(sg + i, NULL);
> }
> - sg_init_table(sg, ALG_MAX_PAGES);
> - sgl->cur = 0;
> - ctx->used = 0;
> - ctx->more = 0;
> - ctx->merge = 0;
> }
>
> static void aead_wmem_wakeup(struct sock *sk)
> @@ -240,6 +255,7 @@ static int aead_sendmsg(struct socket *sock, struct
> msghdr *msg, size_t size) if (!aead_writable(sk)) {
> /* user space sent too much data */
> aead_put_sgl(sk);
> + aead_reset_ctx(ctx);
> err = -EMSGSIZE;
> goto unlock;
> }
> @@ -251,6 +267,7 @@ static int aead_sendmsg(struct socket *sock, struct
> msghdr *msg, size_t size)
>
> if (sgl->cur >= ALG_MAX_PAGES) {
> aead_put_sgl(sk);
> + aead_reset_ctx(ctx);
> err = -E2BIG;
> goto unlock;
> }
> @@ -287,6 +304,7 @@ static int aead_sendmsg(struct socket *sock, struct
> msghdr *msg, size_t size) ctx->more = msg->msg_flags & MSG_MORE;
> if (!ctx->more && !aead_sufficient_data(ctx)) {
> aead_put_sgl(sk);
> + aead_reset_ctx(ctx);
> err = -EMSGSIZE;
> }
>
> @@ -322,6 +340,7 @@ static ssize_t aead_sendpage(struct socket *sock, struct
> page *page, if (!aead_writable(sk)) {
> /* user space sent too much data */
> aead_put_sgl(sk);
> + aead_reset_ctx(ctx);
> err = -EMSGSIZE;
> goto unlock;
> }
> @@ -339,6 +358,7 @@ done:
> ctx->more = flags & MSG_MORE;
> if (!ctx->more && !aead_sufficient_data(ctx)) {
> aead_put_sgl(sk);
> + aead_reset_ctx(ctx);
> err = -EMSGSIZE;
> }
>
> @@ -349,23 +369,189 @@ unlock:
> return err ?: size;
> }
>
> -static int aead_recvmsg(struct socket *sock, struct msghdr *msg, size_t
> ignored, int flags) +#define GET_ASYM_REQ(req, tfm) (struct aead_async_req
> *) \
> + ((char *)req + sizeof(struct aead_request) + \
> + crypto_aead_reqsize(tfm))
> +
> + #define GET_REQ_SIZE(tfm) sizeof(struct aead_async_req) + \
> + crypto_aead_reqsize(tfm) + crypto_aead_ivsize(tfm) + \
> + sizeof(struct aead_request)
> +
> +static void aead_async_cb(struct crypto_async_request *_req, int err)
> +{
> + struct sock *sk = _req->data;
> + struct alg_sock *ask = alg_sk(sk);
> + struct aead_ctx *ctx = ask->private;
> + struct crypto_aead *tfm = crypto_aead_reqtfm(&ctx->aead_req);
> + struc
Re: [PATCH] kexec: unmap reserved pages for each error-return way
On 01/27/16 at 02:48pm, Dmitry Safonov wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390 also changes os_info structure let's check return code
> and add info only on success.
Hi, Dmitry.
Previously, I sent a patch to fix this issue. You can refer it in
following link.
http://lists.infradead.org/pipermail/kexec/2015-July/013960.html
And this patch is fixed from kexec.
If crash_map_reserved_pages fails to map reserved memory, is it
necessary to continue the process on s390? If no, it is better to enter
the error handle path, then return. Thus there is no need to pass the
parameter to indicate the error or not.
> @@ -147,39 +147,34 @@ static int kdump_csum_valid(struct kimage *image)
> }
>
> /*
> - * Map or unmap crashkernel memory
> + * Map crashkernel memory
> */
> -static void crash_map_pages(int enable)
> +void crash_map_reserved_pages(void)
> {
> unsigned long size = resource_size(&crashk_res);
>
> BUG_ON(crashk_res.start % KEXEC_CRASH_MEM_ALIGN ||
> size % KEXEC_CRASH_MEM_ALIGN);
> - if (enable)
> - vmem_add_mapping(crashk_res.start, size);
> - else {
> - vmem_remove_mapping(crashk_res.start, size);
> - if (size)
> - os_info_crashkernel_add(crashk_res.start, size);
> - else
> - os_info_crashkernel_add(0, 0);
> - }
> -}
> -
> -/*
> - * Map crashkernel memory
> - */
> -void crash_map_reserved_pages(void)
> -{
> - crash_map_pages(1);
> + vmem_add_mapping(crashk_res.start, size);
> }
It is fine to cleanup this function. And add the logic into function
crash_unmap_reserved_pages.
>
> /*
> * Unmap crashkernel memory
> */
> -void crash_unmap_reserved_pages(void)
> +void crash_unmap_reserved_pages(int error)
> {
> - crash_map_pages(0);
> + unsigned long size = resource_size(&crashk_res);
> +
> + BUG_ON(crashk_res.start % KEXEC_CRASH_MEM_ALIGN ||
> +size % KEXEC_CRASH_MEM_ALIGN);
> + vmem_remove_mapping(crashk_res.start, size);
> +
> + if (error)
> + return;
> + if (size)
> + os_info_crashkernel_add(crashk_res.start, size);
> + else
> + os_info_crashkernel_add(0, 0);
> }
>
> /*
Thanks
Minfei
Re: [PATCH] sound: fix SND_PCM_TIMER Kconfig text
On Thu, 28 Jan 2016 03:04:10 +0100, Randy Dunlap wrote: > > From: Randy Dunlap > > Fix spelling and typos for SND_PCM_TIMER. > > Signed-off-by: Randy Dunlap > Cc: Jie Yang > Cc: Takashi Iwai Applied, thanks. Takashi > --- > sound/core/Kconfig |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > --- lnx-45-rc1.orig/sound/core/Kconfig > +++ lnx-45-rc1/sound/core/Kconfig > @@ -97,11 +97,11 @@ config SND_PCM_TIMER > bool "PCM timer interface" if EXPERT > default y > help > - If you disable this option, pcm timer will be inavailable, so > - those stubs used pcm timer (e.g. dmix, dsnoop & co) may work > + If you disable this option, pcm timer will be unavailable, so > + those stubs that use pcm timer (e.g. dmix, dsnoop & co) may work > incorrectlly. > > - For some embedded device, we may disable it to reduce memory > + For some embedded devices, we may disable it to reduce memory > footprint, about 20KB on x86_64 platform. > > config SND_SEQUENCER_OSS >
[RFC PATCH] mm: CONFIG_NR_ZONES_EXTENDED
ZONE_DEVICE (merged in 4.3) and ZONE_CMA (proposed) are examples of new
mm zones that are bumping up against the current maximum limit of 4
zones, i.e. 2 bits in page->flags. When adding a zone this equation
still needs to be satisified:
SECTIONS_WIDTH + ZONES_WIDTH + NODES_SHIFT + LAST_CPUPID_SHIFT
<= BITS_PER_LONG - NR_PAGEFLAGS
ZONE_DEVICE currently tries to satisfy this equation by requiring that
ZONE_DMA be disabled, but this is untenable given generic kernels want
to support ZONE_DEVICE and ZONE_DMA simultaneously. ZONE_CMA would like
to increase the amount of memory covered per section, but that limits
the minimum granularity at which consecutive memory ranges can be added
via devm_memremap_pages().
The trade-off of what is acceptable to sacrifice depends heavily on the
platform. For example, ZONE_CMA is targeted for 32-bit platforms where
page->flags is constrained, but those platforms likely do not care about
the minimum granularity of memory hotplug. A big iron machine with 1024
numa nodes can likely sacrifice ZONE_DMA where a general purpose
distribution kernel can not.
CONFIG_NR_ZONES_EXTENDED is a configuration symbol that gets selected
when the number of configured zones exceeds 4. It documents the
configuration symbols and definitions that get modified when ZONES_WIDTH
is greater than 2.
For now, it steals a bit from NODES_SHIFT. Later on it can be used to
document the definitions that get modified when a 32-bit configuration
wants more zone bits.
Note that GFP_ZONE_TABLE poses an interesting constraint since
include/linux/gfp.h gets included by the 32-bit portion of a 64-bit
build. We need to be careful to only build the table for zones that
have a corresponding gfp_t flag. GFP_ZONES_SHIFT is introduced for this
purpose. This patch does not attempt to solve the problem of adding a
new zone that also has a corresponding GFP_ flag.
Cc: Mel Gorman
Cc: Rik van Riel
Cc: Joonsoo Kim
Cc: Dave Hansen
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110931
Fixes: 033fbae988fc ("mm: ZONE_DEVICE for "device memory"")
Cc: Sudip Mukherjee
Reported-by: Mark
Signed-off-by: Dan Williams
---
arch/x86/Kconfig |6 --
include/linux/gfp.h | 33 -
include/linux/page-flags-layout.h |2 ++
mm/Kconfig|7 +--
4 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 330e738ccfc1..9dfc52eb3976 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1409,8 +1409,10 @@ config NUMA_EMU
config NODES_SHIFT
int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
- range 1 10
- default "10" if MAXSMP
+ range 1 10 if !NR_ZONES_EXTENDED
+ range 1 9 if NR_ZONES_EXTENDED
+ default "10" if MAXSMP && !NR_ZONES_EXTENDED
+ default "9" if MAXSMP && NR_ZONES_EXTENDED
default "6" if X86_64
default "3"
depends on NEED_MULTIPLE_NODES
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 28ad5f6494b0..5979c2c80140 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -329,22 +329,29 @@ static inline bool gfpflags_allow_blocking(const gfp_t
gfp_flags)
* 0xe=> BAD (MOVABLE+DMA32+HIGHMEM)
* 0xf=> BAD (MOVABLE+DMA32+HIGHMEM+DMA)
*
- * ZONES_SHIFT must be <= 2 on 32 bit platforms.
+ * GFP_ZONES_SHIFT must be <= 2 on 32 bit platforms.
*/
-#if 16 * ZONES_SHIFT > BITS_PER_LONG
-#error ZONES_SHIFT too large to create GFP_ZONE_TABLE integer
+#if defined(CONFIG_ZONE_DEVICE) && (MAX_NR_ZONES-1) <= 4
+/* ZONE_DEVICE is not a valid GFP zone specifier */
+#define GFP_ZONES_SHIFT 2
+#else
+#define GFP_ZONES_SHIFT ZONES_SHIFT
+#endif
+
+#if 16 * GFP_ZONES_SHIFT > BITS_PER_LONG
+#error GFP_ZONES_SHIFT too large to create GFP_ZONE_TABLE integer
#endif
#define GFP_ZONE_TABLE ( \
- (ZONE_NORMAL << 0 * ZONES_SHIFT) \
- | (OPT_ZONE_DMA << ___GFP_DMA * ZONES_SHIFT) \
- | (OPT_ZONE_HIGHMEM << ___GFP_HIGHMEM * ZONES_SHIFT) \
- | (OPT_ZONE_DMA32 << ___GFP_DMA32 * ZONES_SHIFT) \
- | (ZONE_NORMAL << ___GFP_MOVABLE * ZONES_SHIFT) \
- | (OPT_ZONE_DMA << (___GFP_MOVABLE | ___GFP_DMA) * ZONES_SHIFT) \
- | (ZONE_MOVABLE << (___GFP_MOVABLE | ___GFP_HIGHMEM) * ZONES_SHIFT) \
- | (OPT_ZONE_DMA32 << (___GFP_MOVABLE | ___GFP_DMA32) * ZONES_SHIFT) \
+ (ZONE_NORMAL << 0 * GFP_ZONES_SHIFT)
\
+ | (OPT_ZONE_DMA << ___GFP_DMA * GFP_ZONES_SHIFT)
\
+ | (OPT_ZONE_HIGHMEM << ___GFP_HIGHMEM * GFP_ZONES_SHIFT)
\
+ | (OPT_ZONE_DMA32 << ___GFP_DMA32 * GFP_ZONES_SHIFT)
\
+ | (ZONE_NORMAL << ___GFP_MOVABLE * GFP_ZONES_SHIFT)
\
+ | (OPT_ZONE_DMA << (___GF
ANNOUNCE: mdadm 3.4 - A tool for managing md Soft RAID under Linux
I am pleased to announce the availability of mdadm version 3.4 It is available at the usual places: http://www.kernel.org/pub/linux/utils/raid/mdadm/ and via git at git://github.com/neilbrown/mdadm git://neil.brown.name/mdadm http://git.neil.brown.name/git/mdadm The new second-level version number reflects significant new functionality, particular support for journalled RAID5/6 and clustered RAID1. This new support is probably still buggy. Please report bugs. There are also a number of fixes for Intel's IMSM metadata support, and an assortment of minor bug fixes. I plan for this to be the last release of mdadm that I provide as I am retiring from MD and mdadm maintenance. Jes Sorensen has volunteered to oversee mdadm for the next while. Thanks Jes! NeilBrown 28th January 2016 signature.asc Description: PGP signature
Re: [PATCH net 0/4] net: add rx_unhandled stat counter
On Thu, Jan 28, 2016 at 01:02:15AM -0500, Jarod Wilson wrote:
> On Wed, Jan 27, 2016 at 01:09:47PM -0800, Eric Dumazet wrote:
> > On Wed, 2016-01-27 at 15:21 -0500, Jarod Wilson wrote:
> >
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > index 289c231..7973ab5 100644
> > > --- a/include/linux/netdevice.h
> > > +++ b/include/linux/netdevice.h
> > > @@ -180,6 +180,7 @@ struct net_device_stats {
> > > unsigned long tx_window_errors;
> > > unsigned long rx_compressed;
> > > unsigned long tx_compressed;
> > > + unsigned long rx_unhandled;
> > > };
> > >
> >
> > This structure is deprecated, please do not add new fields in it,
> > as it will increase netlink answers for no good reason.
> >
> > rtnl_link_stats64 is what really matters these days.
>
> I'll respin the set without that
Or not. Now I remember why I added that in the first place:
In file included from ./arch/x86/include/asm/uaccess.h:7:0,
from net/core/dev.c:75:
net/core/dev.c: In function 'netdev_stats_to_stats64':
include/linux/compiler.h:484:20: error: call to '__compiletime_assert_7263'
declared with attribute error: BUILD_BUG_ON failed: sizeof(*stats64) !=
sizeof(*netdev_stats)
prefix ## suffix();\
^
Things are actually hard-wired to require that addition at the moment, or
you get the above build failure. Not sure if it's safe to remove that
BUILD_BUG_ON() yet, haven't looked closely, it's past my bed time. :)
--
Jarod Wilson
ja...@redhat.com
Re: [PATCH net 0/4] net: add rx_unhandled stat counter
On Thu, Jan 28, 2016 at 01:02:15AM -0500, Jarod Wilson wrote:
> On Wed, Jan 27, 2016 at 01:09:47PM -0800, Eric Dumazet wrote:
> > On Wed, 2016-01-27 at 15:21 -0500, Jarod Wilson wrote:
> >
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > index 289c231..7973ab5 100644
> > > --- a/include/linux/netdevice.h
> > > +++ b/include/linux/netdevice.h
> > > @@ -180,6 +180,7 @@ struct net_device_stats {
> > > unsigned long tx_window_errors;
> > > unsigned long rx_compressed;
> > > unsigned long tx_compressed;
> > > + unsigned long rx_unhandled;
> > > };
> > >
> >
> > This structure is deprecated, please do not add new fields in it,
> > as it will increase netlink answers for no good reason.
> >
> > rtnl_link_stats64 is what really matters these days.
>
> I'll respin the set without that, along with s/unhandled/nohandler/, which
> I somehow got screwed up in my head and realized a split second after
> hitting send. Outside of that, does this approach look sane? Should I
> bother with touching /proc/net/dev output or not?
Also, please excuse the poor excuse for a cover-letter that had a
duplicate of patch 1 in it. I'll fix that the next pass too.
/me hangs head in shame...
--
Jarod Wilson
ja...@redhat.com
Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code
On (01/28/16 13:36), byungchul.park wrote:
[..]
> > the thing is, it's really-really hard to lockup in console_trylock()...
> >
> > int down_trylock(struct semaphore *sem)
> > {
> > unsigned long flags;
> > int count;
> >
> > raw_spin_lock_irqsave(&sem->lock, flags); << um...
>
> I also think it's hard, but a backtrace said the lockup happened here.
what was the state of `struct semaphore *sem' and especially of `sem->lock'?
what was the lock->owner_cpu doing? (addr2line of its pc registe, for example).
> > count = sem->count - 1;
> > if (likely(count >= 0))
> > sem->count = count;
> > raw_spin_unlock_irqrestore(&sem->lock, flags);
> >
> > return (count < 0);
> > }
> >
> > was not able to dereference sem->count? `*sem' was corrupted? or because
> > sem->lock was corrupted? in any of those cases you solve the problem from
> > the wrong side. if you have a memory corruption then it can corrupt
>
> What I solved here is to make it possible to print what the problem is, by
> the spinlock debug code instead of system lockup while printing a debug
> message. I think it's not wrong.
none of the CPUs will print anything anymore. it's done.
your CPUa - CPUx are spinning in down_trylock()
vprintk_emit()
down_trylock()
raw_spin_lock_irqsave() << spin here
and they are spinnig because CPUz is keeping the sem->lock and is
_not_ going to release it. and this is the root cause, not spin_dump().
CPUz was expected to do a quick thing in down_trylock()
raw_spin_lock_irqsave(&sem->lock, flags);
count = sem->count - 1;
if (likely(count >= 0))
sem->count = count;
raw_spin_unlock_irqrestore(&sem->lock, flags);
or down()/down_common()
raw_spin_lock_irqsave(&sem->lock, flags);
if (likely(sem->count > 0))
sem->count--;
else
down_common()
{
...
for (;;) {
if (signal_pending_state(state, task))
goto interrupted;
if (unlikely(timeout <= 0))
goto timed_out;
__set_task_state(task, state);
raw_spin_unlock_irq(&sem->lock);
timeout = schedule_timeout(timeout);
raw_spin_lock_irq(&sem->lock);
if (waiter.up)
return 0;
}
...
}
raw_spin_unlock_irqrestore(&sem->lock, flags);
I can't see how it's even possible to keep that spin_lock locked
longer than `loops_per_jiffy * HZ'.
and the fact that you saw N recursive
printk()->down_trylock()->spin_lock()->spin_dump()->printk()->...
sounds like a good prove of the fact the your CPUz was either dead,
or gone crazy, and took the spin_lock with it. but this is not
spinlock_debug's business.
console_flush_on_panic() _probably_ would help in this particular
case -- it does not care about console_sem state and goes to
console_unlock() directly -- but it still locks the logbuf_lock.
so if CPUz died with logbuf_lock being locked, then nothing will
save your day.
do you have any reproducer or you've seen it once?
-ss
Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Wed, 2016-01-27 at 23:29 -0800, K. Y. Srinivasan wrote: > tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2 > f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2fli > nux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad7108d3 > 2796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS%2ftO > z%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master > head: 03c21cb775a313f1ff19be59c5d02df3e3526471 > commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly > support Fibre Channel devices > date: 3 weeks ago > config: x86_64-randconfig-s3-01281016 (attached as .config) > reproduce: > git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `storvsc_remove': > > > storvsc_drv.c:(.text+0x213af7): undefined reference to > > > `fc_remove_host' >drivers/built-in.o: In function `storvsc_drv_init': > > > storvsc_drv.c:(.init.text+0xcbcc): undefined reference to > > > `fc_attach_transport' > > > storvsc_drv.c:(.init.text+0xcc06): undefined reference to > > > `fc_release_transport' >drivers/built-in.o: In function `storvsc_drv_exit': > > > storvsc_drv.c:(.exit.text+0x123c): undefined reference to > > > `fc_release_transport' > > With this commit, the storvsc driver depends on FC atttributes. Make > this > dependency explicit. > > Signed-off-by: K. Y. Srinivasan > Reported-by: Fengguang Wu > --- > drivers/scsi/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > index 64eed87..24365c3 100644 > --- a/drivers/scsi/Kconfig > +++ b/drivers/scsi/Kconfig > @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND > config HYPERV_STORAGE > tristate "Microsoft Hyper-V virtual storage driver" > depends on SCSI && HYPERV > + depends on SCSI_FC_ATTRS > default HYPERV > help > Select this option to enable the Hyper-V virtual storage > driver. OK, so I thought Hannes requested that you not make the hyperv driver depend on the FC attrs and you said you would ... has this changed? James
Re: [PATCH net 0/4] net: add rx_unhandled stat counter
On Wed, Jan 27, 2016 at 01:09:47PM -0800, Eric Dumazet wrote:
> On Wed, 2016-01-27 at 15:21 -0500, Jarod Wilson wrote:
>
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 289c231..7973ab5 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -180,6 +180,7 @@ struct net_device_stats {
> > unsigned long tx_window_errors;
> > unsigned long rx_compressed;
> > unsigned long tx_compressed;
> > + unsigned long rx_unhandled;
> > };
> >
>
> This structure is deprecated, please do not add new fields in it,
> as it will increase netlink answers for no good reason.
>
> rtnl_link_stats64 is what really matters these days.
I'll respin the set without that, along with s/unhandled/nohandler/, which
I somehow got screwed up in my head and realized a split second after
hitting send. Outside of that, does this approach look sane? Should I
bother with touching /proc/net/dev output or not?
Thanks much,
--
Jarod Wilson
ja...@redhat.com
Re: [PATCH] storvsc: use small sg_tablesize on x86
On Wed, 2016-01-27 at 23:09 +, KY Srinivasan wrote: > > > -Original Message- > > From: Olaf Hering [mailto:o...@aepfle.de] > > Sent: Monday, January 25, 2016 12:35 AM > > To: James Bottomley > > Cc: KY Srinivasan ; Haiyang Zhang > > ; linux-kernel@vger.kernel.org; linux- > > s...@vger.kernel.org > > Subject: Re: [PATCH] storvsc: use small sg_tablesize on x86 > > > > On Fri, Oct 02, Olaf Hering wrote: > > > > > On Thu, Oct 01, James Bottomley wrote: > > > > > > > On Thu, 2015-10-01 at 20:30 +, KY Srinivasan wrote: > > > > > > > > > +#if defined(CONFIG_X86_32) > > > > > > > Um, this is a bit architecture specific (I know Azure is x86, > > > > but > > > > still). Can you make the define check CONFIG_32BIT rather than > > > > CONFIG_X86_32? > > > > > > According to arch/x86/Kconfig there is no such thing. > > > > What is the status of this change? Looks like there is nothing more > > to do on my side. > > Olaf, > > We do have the config option: CONFIG_X86_64. Perhaps we could use > this. Could you resubmit the patch with this change. It's not really architecture independent, is it? Just use the bit width config. James
Re: PROBLEM: Intel HDMI output busticated on 4.4 (regression)
On 2016-01-21, Nick Bowler wrote: > On 2016-01-21, Jindal, Sonika wrote: >> On 1/21/2016 8:59 AM, Nick Bowler wrote: >>> On 1/20/16, Nick Bowler wrote: On 2016-01-20, Jindal, Sonika wrote: > [...] > Does the same system works with any other monitor? I'll see if I can find another to try. >>> I tried another monitor, and the same problem occurs. >> Which make are these monitors? > > - LG Flatron W2253V > - Dell E228WFPc > >> Do you have any other system other than G45? > > Nothing else with Linux 4.4, unfortunately. Anything else you want me to try? This issue is still present in 4.5-rc1. Cheers, Nick
[PATCH 2/8] mtd: spi-nor: guard against underflows in stm_is_locked_sr
Users of stm_is_locked_sr() might do arithmetic that could result in a negative offset. For example, when stm_unlock() tries to check the status of the eraseblock below the range, it doesn't check for: ofs - mtd->erasesize < 0 Instead of forcing callers to be extra careful, let's just make stm_is_locked_sr() do the right thing and report errors for invalid ranges. Also, fixup the calculations in stm_unlock(), so we: (a) can handle non-eraseblock-aligned offsets and (b) don't look for a negative offset when checking the first block Signed-off-by: Brian Norris --- drivers/mtd/spi-nor/spi-nor.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index ef89bed1e5ea..c19674573eec 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -447,6 +447,9 @@ static int stm_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len, loff_t lock_offs; uint64_t lock_len; + if (ofs < 0 || ofs + len > nor->mtd.size) + return -EINVAL; + stm_get_locked_range(nor, sr, &lock_offs, &lock_len); return (ofs + len <= lock_offs + lock_len) && (ofs >= lock_offs); @@ -543,9 +546,13 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len) if (status_old < 0) return status_old; - /* Cannot unlock; would unlock larger region than requested */ - if (stm_is_locked_sr(nor, ofs - mtd->erasesize, mtd->erasesize, -status_old)) + /* +* Check the eraseblock next to us; if locked, then this would unlock +* larger region than requested +*/ + if (ofs > 0 && stm_is_locked_sr(nor, ALIGN(ofs - mtd->erasesize, + mtd->erasesize), mtd->erasesize, + status_old)) return -EINVAL; /* -- 1.7.9.5
[PATCH 3/8] mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region
If, for instance, the entire flash is already unlocked and I try to mtd_unlock() the entire device, I don't expect to see an EINVAL error. It should just silently succeed. Ditto for mtd_lock(). Signed-off-by: Brian Norris --- drivers/mtd/spi-nor/spi-nor.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index c19674573eec..3a08aa53c171 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -518,8 +518,12 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len) status_new = (status_old & ~mask) | val; + /* Don't bother if they're the same */ + if (status_new == status_old) + return 0; + /* Only modify protection if it will not unlock other areas */ - if ((status_new & mask) <= (status_old & mask)) + if ((status_new & mask) < (status_old & mask)) return -EINVAL; write_enable(nor); @@ -576,8 +580,12 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len) status_new = (status_old & ~mask) | val; + /* Don't bother if they're the same */ + if (status_new == status_old) + return 0; + /* Only modify protection if it will not lock other areas */ - if ((status_new & mask) >= (status_old & mask)) + if ((status_new & mask) > (status_old & mask)) return -EINVAL; write_enable(nor); -- 1.7.9.5
Re: [PATCH v1] mm/madvise: update comment on sys_madvise()
On Wed, Jan 27, 2016 at 04:28:35PM +0100, Michal Hocko wrote: > On Wed 27-01-16 10:24:25, Naoya Horiguchi wrote: > > Some new MADV_* advices are not documented in sys_madvise() comment. > > So let's update it. > > > > Signed-off-by: Naoya Horiguchi > > Other than few suggestions below > Acked-by: Michal Hocko > > > --- > > mm/madvise.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git v4.4-mmotm-2016-01-20-16-10/mm/madvise.c > > v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c > > index 6a77114..c897b15 100644 > > --- v4.4-mmotm-2016-01-20-16-10/mm/madvise.c > > +++ v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c > > @@ -639,14 +639,26 @@ madvise_behavior_valid(int behavior) > > * some pages ahead. > > * MADV_DONTNEED - the application is finished with the given range, > > * so the kernel can free resources associated with it. > > + * MADV_FREE - the application marks pages in the given range as lasyfree, > > s@lasyfree@lazy free@ > > > + * where actual purges are postponed until memory pressure happens. > > * MADV_REMOVE - the application wants to free up the given range of > > * pages and associated backing store. > > * MADV_DONTFORK - omit this area from child's address space when forking: > > * typically, to avoid COWing pages pinned by get_user_pages(). > > * MADV_DOFORK - cancel MADV_DONTFORK: no longer omit this area when > > forking. > > + * MADV_HWPOISON - trigger memory error handler as if the given memory > > range > > + * were corrupted by unrecoverable hardware memory failure. > > + * MADV_SOFT_OFFLINE - try to soft-offline the given range of memory. > > * MADV_MERGEABLE - the application recommends that KSM try to merge > > pages in > > * this area with pages of identical content from other such areas. > > * MADV_UNMERGEABLE- cancel MADV_MERGEABLE: no longer merge pages with > > others. > > + * MADV_HUGEPAGE - the application wants to allocate transparent > > hugepages to > > + * load the content of the given memory range. > > I guess that a slightly different wording would be better: > > application wants to back the given range by transparent huge pages in > the future. Existing pages might be coalesced and new pages might be > allocated as THP. > > > + * MADV_NOHUGEPAGE - cancel MADV_HUGEPAGE: no longer allocate transparent > > + * hugepages. > > Mark the given range as not worth being backed by transparent huge pages > so neither existing pages will be coalesced into THP nor new pages will > be allocated as THP. Thank you for the elaboration. I'm fine for all these change. - Naoya
[PATCH 5/8] mtd: spi-nor: use BIT() for flash_info flags
It's a little easier to read and make sure there are no collisions
(IMO).
Signed-off-by: Brian Norris
---
drivers/mtd/spi-nor/spi-nor.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 46da6bb706fa..ac930e902ee3 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -61,14 +61,14 @@ struct flash_info {
u16 addr_width;
u16 flags;
-#defineSECT_4K 0x01/* SPINOR_OP_BE_4K works
uniformly */
-#defineSPI_NOR_NO_ERASE0x02/* No erase command needed */
-#defineSST_WRITE 0x04/* use SST byte programming */
-#defineSPI_NOR_NO_FR 0x08/* Can't do fastread */
-#defineSECT_4K_PMC 0x10/* SPINOR_OP_BE_4K_PMC works
uniformly */
-#defineSPI_NOR_DUAL_READ 0x20/* Flash supports Dual Read */
-#defineSPI_NOR_QUAD_READ 0x40/* Flash supports Quad Read */
-#defineUSE_FSR 0x80/* use flag status register */
+#define SECT_4KBIT(0) /* SPINOR_OP_BE_4K works
uniformly */
+#define SPI_NOR_NO_ERASE BIT(1) /* No erase command needed */
+#define SST_WRITE BIT(2) /* use SST byte programming */
+#define SPI_NOR_NO_FR BIT(3) /* Can't do fastread */
+#define SECT_4K_PMCBIT(4) /* SPINOR_OP_BE_4K_PMC works uniformly
*/
+#define SPI_NOR_DUAL_READ BIT(5) /* Flash supports Dual Read */
+#define SPI_NOR_QUAD_READ BIT(6) /* Flash supports Quad Read */
+#define USE_FSRBIT(7) /* use flag status register */
};
#define JEDEC_MFR(info)((info)->id[0])
--
1.7.9.5
[PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low
Locking the flash is most useful if it provides real hardware security. Otherwise, it's little more than a software permission bit. A reasonable use case that provides real HW security might be like follows: (1) hardware WP# is deasserted (2) program flash (3) flash range is protected via status register (4) hardware WP# is asserted (5) flash protection range can no longer be changed, until WP# is deasserted In this way, flash protection is co-owned by hardware and software. Now, one would expect to be able to perform step (3) with ioctl(MEMLOCK), except that the spi-nor driver does not set the Status Register Protect bit (a.k.a. Status Register Write Disable (SRWD)), so even though the range is now locked, it does not satisfy step (5) -- it can still be changed by a call to ioctl(MEMUNLOCK). So, let's enable status register protection after the first lock command. Signed-off-by: Brian Norris --- drivers/mtd/spi-nor/spi-nor.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 3a08aa53c171..46da6bb706fa 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -518,6 +518,9 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len) status_new = (status_old & ~mask) | val; + /* Disallow further writes if WP pin is asserted */ + status_new |= SR_SRWD; + /* Don't bother if they're the same */ if (status_new == status_old) return 0; -- 1.7.9.5
[PATCH 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag
We can't determine this purely by manufacturer type (see commit
67b9bcd36906 ("mtd: spi-nor: fix Spansion regressions (aliased with
Winbond)")), and it's not autodetectable by anything like SFDP. So make
a new flag for it.
Signed-off-by: Brian Norris
---
drivers/mtd/spi-nor/spi-nor.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ac930e902ee3..8846b575b526 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -69,6 +69,7 @@ struct flash_info {
#define SPI_NOR_DUAL_READ BIT(5) /* Flash supports Dual Read */
#define SPI_NOR_QUAD_READ BIT(6) /* Flash supports Quad Read */
#define USE_FSRBIT(7) /* use flag status register */
+#define SPI_NOR_HAS_LOCK BIT(8) /* Flash supports lock/unlock via SR */
};
#define JEDEC_MFR(info)((info)->id[0])
@@ -1251,7 +1252,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
enum read_mode mode)
if (JEDEC_MFR(info) == SNOR_MFR_ATMEL ||
JEDEC_MFR(info) == SNOR_MFR_INTEL ||
- JEDEC_MFR(info) == SNOR_MFR_SST) {
+ JEDEC_MFR(info) == SNOR_MFR_SST ||
+ info->flags & SPI_NOR_HAS_LOCK) {
write_enable(nor);
write_sr(nor, 0);
spi_nor_wait_till_ready(nor);
@@ -1268,7 +1270,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
enum read_mode mode)
mtd->_read = spi_nor_read;
/* NOR protection support for STmicro/Micron chips and similar */
- if (JEDEC_MFR(info) == SNOR_MFR_MICRON) {
+ if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+ info->flags & SPI_NOR_HAS_LOCK) {
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_locked = stm_is_locked;
--
1.7.9.5
[PATCH 8/8] mtd: spi-nor: support lock/unlock for a few Winbond chips
These are recent Winbond models that are known to have lock/unlock
support via writing the Status Register, and that also support the TB
(Top/Bottom) protection bit.
Tested on w25q32dw.
[Note on style: these entries are getting pretty long lines, so I picked
a style that seems reasonable for splitting up the flags separate from
the other mostly-similar fields.]
Signed-off-by: Brian Norris
---
drivers/mtd/spi-nor/spi-nor.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 5e84e3c543aa..cd3908e26712 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -942,11 +942,23 @@ static const struct flash_info spi_nor_ids[] = {
{ "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
{ "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
{ "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ {
+ "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
{ "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q64dw", INFO(0xef6017, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "w25q128fw", INFO(0xef6018, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ {
+ "w25q64dw", INFO(0xef6017, 0, 64 * 1024, 128,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
+ {
+ "w25q128fw", INFO(0xef6018, 0, 64 * 1024, 256,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
{ "w25q80", INFO(0xef5014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
--
1.7.9.5
[PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2flinux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad7108d32796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS%2ftOz%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master head: 03c21cb775a313f1ff19be59c5d02df3e3526471 commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly support Fibre Channel devices date: 3 weeks ago config: x86_64-randconfig-s3-01281016 (attached as .config) reproduce: git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/built-in.o: In function `storvsc_remove': >> storvsc_drv.c:(.text+0x213af7): undefined reference to `fc_remove_host' drivers/built-in.o: In function `storvsc_drv_init': >> storvsc_drv.c:(.init.text+0xcbcc): undefined reference to >> `fc_attach_transport' >> storvsc_drv.c:(.init.text+0xcc06): undefined reference to >> `fc_release_transport' drivers/built-in.o: In function `storvsc_drv_exit': >> storvsc_drv.c:(.exit.text+0x123c): undefined reference to >> `fc_release_transport' With this commit, the storvsc driver depends on FC atttributes. Make this dependency explicit. Signed-off-by: K. Y. Srinivasan Reported-by: Fengguang Wu --- drivers/scsi/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 64eed87..24365c3 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND config HYPERV_STORAGE tristate "Microsoft Hyper-V virtual storage driver" depends on SCSI && HYPERV + depends on SCSI_FC_ATTRS default HYPERV help Select this option to enable the Hyper-V virtual storage driver. -- 1.7.4.1
[PATCH 0/8] mtd: spi-nor: locking fixes and updates
Hi, These are an assortment of fixes and updates to the SPI NOR lock/unlock feature. The biggest new features are: (a) Status Register protection; I don't see why this shouldn't be enabled by default. See patch 4's description. (b) Bottom-block protection support (via TB status bit) (c) Lock/unlock support for a few Winbond flash Patch 7 (Top/Bottom protection support) is still an RFC, as I think it deserves a bit more work. But I'm just getting it out there, as it's been sitting on my plate for a while. Regards, Brian Brian Norris (8): mtd: spi-nor: wait for SR_WIP to clear on initial unlock mtd: spi-nor: guard against underflows in stm_is_locked_sr mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region mtd: spi-nor: disallow further writes to SR if WP# is low mtd: spi-nor: use BIT() for flash_info flags mtd: spi-nor: add SPI_NOR_HAS_LOCK flag mtd: spi-nor: add TB (Top/Bottom) protect support mtd: spi-nor: support lock/unlock for a few Winbond chips drivers/mtd/spi-nor/spi-nor.c | 153 + include/linux/mtd/spi-nor.h |2 + 2 files changed, 128 insertions(+), 27 deletions(-) -- 1.7.9.5
[PATCH 1/8] mtd: spi-nor: wait for SR_WIP to clear on initial unlock
Fixup a piece leftover by commit 32321e950d8a ("mtd: spi-nor: wait until
lock/unlock operations are ready"). That commit made us wait for the WIP
bit to settle after lock/unlock operations, but it missed the open-coded
"unlock" that happens at probe() time.
We should probably have this code utilize the unlock() routines in the
future, to avoid duplication, but unfortunately, flash which need to be
unlocked don't all have a proper ->flash_unlock() callback.
Signed-off-by: Brian Norris
Cc: Stas Sergeev
Cc: Ezequiel Garcia
---
drivers/mtd/spi-nor/spi-nor.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ed0c19c558b5..ef89bed1e5ea 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1236,6 +1236,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
enum read_mode mode)
JEDEC_MFR(info) == SNOR_MFR_SST) {
write_enable(nor);
write_sr(nor, 0);
+ spi_nor_wait_till_ready(nor);
}
if (!mtd->name)
--
1.7.9.5
[RFC PATCH 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support
Some flash support a bit in the status register that inverts protection
so that it applies to the bottom of the flash, not the top. This yields
additions to the protection range table, as noted in the comments.
Because this feature is not universal to all flash that support
lock/unlock, control it via a new flag.
Signed-off-by: Brian Norris
---
This one hasn't been exhaustively tested yet, so I labeled it 'RFC'. I hope to
have some sort of test scripts (possibly targeting mtd-utils) ready, to help
make sure the locking APIs behave as expected. (And "as expected" is a little
ill-defined, IMO.)
drivers/mtd/spi-nor/spi-nor.c | 85 -
include/linux/mtd/spi-nor.h |2 +
2 files changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 8846b575b526..5e84e3c543aa 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -70,6 +70,11 @@ struct flash_info {
#define SPI_NOR_QUAD_READ BIT(6) /* Flash supports Quad Read */
#define USE_FSRBIT(7) /* use flag status register */
#define SPI_NOR_HAS_LOCK BIT(8) /* Flash supports lock/unlock via SR */
+#define SPI_NOR_HAS_TB BIT(9) /*
+* Flash SR has Top/Bottom (TB) protect
+* bit. Must be used with
+* SPI_NOR_HAS_LOCK.
+*/
};
#define JEDEC_MFR(info)((info)->id[0])
@@ -435,7 +440,10 @@ static void stm_get_locked_range(struct spi_nor *nor, u8
sr, loff_t *ofs,
} else {
pow = ((sr & mask) ^ mask) >> shift;
*len = mtd->size >> pow;
- *ofs = mtd->size - *len;
+ if (nor->flags & SNOR_F_HAS_SR_TB && sr & SR_TB)
+ *ofs = 0;
+ else
+ *ofs = mtd->size - *len;
}
}
@@ -458,12 +466,14 @@ static int stm_is_locked_sr(struct spi_nor *nor, loff_t
ofs, uint64_t len,
/*
* Lock a region of the flash. Compatible with ST Micro and similar flash.
- * Supports only the block protection bits BP{0,1,2} in the status register
+ * Supports the block protection bits BP{0,1,2} in the status register
* (SR). Does not support these features found in newer SR bitfields:
- * - TB: top/bottom protect - only handle TB=0 (top protect)
* - SEC: sector/block protect - only handle SEC=0 (block protect)
* - CMP: complement protect - only support CMP=0 (range is not complemented)
*
+ * Support for the following is provided conditionally for some flash:
+ * - TB: top/bottom protect
+ *
* Sample table portion for 8MB flash (Winbond w25q64fw):
*
* SEC | TB | BP2 | BP1 | BP0 | Prot Length | Protected Portion
@@ -476,6 +486,13 @@ static int stm_is_locked_sr(struct spi_nor *nor, loff_t
ofs, uint64_t len,
*0 | 0 | 1 | 0 | 1 | 2 MB | Upper 1/4
*0 | 0 | 1 | 1 | 0 | 4 MB | Upper 1/2
*X | X | 1 | 1 | 1 | 8 MB | ALL
+ * --|---|---|---|---|---|---
+ *0 | 1 | 0 | 0 | 1 | 128 KB | Lower 1/64
+ *0 | 1 | 0 | 1 | 0 | 256 KB | Lower 1/32
+ *0 | 1 | 0 | 1 | 1 | 512 KB | Lower 1/16
+ *0 | 1 | 1 | 0 | 0 | 1 MB | Lower 1/8
+ *0 | 1 | 1 | 0 | 1 | 2 MB | Lower 1/4
+ *0 | 1 | 1 | 1 | 0 | 4 MB | Lower 1/2
*
* Returns negative on errors, 0 on success.
*/
@@ -485,6 +502,8 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs,
uint64_t len)
int status_old, status_new;
u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
u8 shift = ffs(mask) - 1, pow, val;
+ bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
+ bool use_top;
int ret;
status_old = read_sr(nor);
@@ -496,10 +515,24 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs,
uint64_t len)
/* Does combined region extend to end? */
if (!stm_is_locked_sr(nor, ofs + len, mtd->size - ofs - len,
status_old))
- return -EINVAL;
- len = mtd->size - ofs;
+ can_be_top = false;
+ else
+ len = mtd->size - ofs;
}
+ if (can_be_bottom && ofs != 0) {
+ /* Does combined region extend to beginning? */
+ if (!stm_is_locked_sr(nor, 0, ofs, status_old))
+ can_be_bottom = false;
+ else
+ ofs = 0;
+ }
+
+ if (!can_be_bottom && !can_be_top)
+ return -EINVAL;
+ /* Prefer top, if both are valid */
+
Re: [PATCH v1] mm/madvise: pass return code of memory_failure() to userspace
On Wed, Jan 27, 2016 at 02:59:11PM +0100, Vlastimil Babka wrote:
> [CC += linux-api, linux-man]
>
> On 01/22/2016 09:27 AM, Naoya Horiguchi wrote:
> > Currently the return value of memory_failure() is not passed to userspace,
> > which
> > is inconvenient for test programs that want to know the result of error
> > handling.
> > So let's return it to the caller as we already do in MADV_SOFT_OFFLINE case.
> >
> > Signed-off-by: Naoya Horiguchi
> > ---
> > mm/madvise.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git v4.4-mmotm-2016-01-20-16-10/mm/madvise.c
> > v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c
> > index f56825b..6a77114 100644
> > --- v4.4-mmotm-2016-01-20-16-10/mm/madvise.c
> > +++ v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c
> > @@ -555,8 +555,9 @@ static int madvise_hwpoison(int bhv, unsigned long
> > start, unsigned long end)
> > }
> > pr_info("Injecting memory failure for page %#lx at %#lx\n",
> >page_to_pfn(p), start);
> > - /* Ignore return value for now */
> > - memory_failure(page_to_pfn(p), 0, MF_COUNT_INCREASED);
> > + ret = memory_failure(page_to_pfn(p), 0, MF_COUNT_INCREASED);
> > + if (ret)
> > + return ret;
>
> Can you explain what madvise can newly return for MADV_HWPOISON in which
> situations, for the purposes of updated man page?
OK, this patch newly allows madvise(MADV_HWPOISON) to return EBUSY when
error handling failed due to 2 major reasons:
- the target page is a page type which memory error handler doesn't support
(like slab pages, kernel-reserved pages)
- the memory error handler failed to isolate the target page (for example,
due to failure in unmapping)
And for man page purpose, errnos of MADV_SOFT_OFFLINE is not documented either.
So let me refer to 2 possible error code from madvise(MADV_SOFT_OFFLINE):
- EBUSY: failed to isolate from lru list,
- EIO: failed to migrate the target page to another page.
Thanks,
Naoya Horiguchi
Re: [RFC 3/4] ARM: imx: add the platform related rpmsg implementation
On Thu, Jan 28, 2016 at 02:17:21AM +, Richard Zhu wrote: > > arch/arm/mach-imx/Kconfig | 12 ++ > > arch/arm/mach-imx/Makefile| 2 + > > arch/arm/mach-imx/imx_rpmsg.c | 364 > > ++ > > arch/arm/mach-imx/mu.c| 217 + > > I'm not rpmsg expert, but it seems to me that the driver should be put into > drivers/rpmsg/ rather than mach-imx. > [Richard] This part rpmsg codes are closed related to the platform. For > example, kinds of ops callback functions. > Thus, these codes are placed into arch/arm/mach-imx/ folder. BTW, so does to > omap rpmsg implementation. > http://omappedia.org/wiki/RPMsg_Kernel_Sources Okay, I will find some time slot to get myself familiar with rpmsg subsystem and then review the patch. Shawn
RE: [PATCH V7 0/6] i2c: qup: Add support for v2 tags and bam dma
Hi Wolfram, > -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Wolfram Sang > Sent: Sunday, January 24, 2016 5:03 PM > To: Sricharan > Cc: devicet...@vger.kernel.org; arch...@codeaurora.org; linux-arm- > m...@vger.kernel.org; ntel...@codeaurora.org; agr...@codeaurora.org; > linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org; linux- > i...@vger.kernel.org; iiva...@mm-sol.com; ga...@codeaurora.org; > andy.gr...@linaro.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH V7 0/6] i2c: qup: Add support for v2 tags and bam dma > > > > Sricharan R (6): > > > i2c: qup: Change qup_wait_writeready function to use for all timeouts > > > i2c: qup: Add V2 tags support > > > i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit > > > i2c: qup: Add bam dma capabilities > > > dts: msm8974: Add blsp2_bam dma node > > > dts: msm8974: Add dma channels for blsp2_i2c1 node > > > > > Wolfram, Does the first 4 patches looks good to be picked up ? > > Except for patch 3 (I replied seperately), the rest looks okay to me. I > wondered a little if it would make sense to make a new driver for v2 + DMA, > because the additions were quite massive. But I'll leave it up to you if there is > enough shared code between the two versions, so that a single driver will be > better. Hmm, addition of V2 reused code, more than 50% addition of new loc in this series, lot of it from DMA, but at this point it feels ok to have it in a single driver. Regards, Sricharan
Re: [PATCH] mm/vmstat: retrieve more accurate vmstat value
On Wed, Jan 27, 2016 at 03:13:12PM -0800, David Rientjes wrote: > On Thu, 26 Nov 2015, Joonsoo Kim wrote: > > > I understand design decision, but, it is better to get value as much > > as accurate if there is no performance problem. My patch would not > > cause much performance degradation because it is just adding one > > this_cpu_read(). > > > > Consider about following example. Current implementation returns > > interesting output if someone do following things. > > > > v1 = zone_page_state(XXX); > > mod_zone_page_state(XXX, 1); > > v2 = zone_page_state(XXX); > > > > v2 would be same with v1 in most of cases even if we already update > > it. > > > > This situation could occurs in page allocation path and others. If > > some task try to allocate many pages, then watermark check returns > > same values until updating vmstat even if some freepage are allocated. > > There are some adjustments for this imprecision but why not do it become > > accurate? I think that this change is reasonable trade-off. > > > > I'm not sure that NR_ISOLATED_* should be vmstats in the first place. The > most important callers that depend on its accuracy is > zone_reclaimable_pages() and the too_many_isolated() loop in both > shrink_inactive_list() and memory compaction. If zlc's are updated every > 1s, the HZ/10 in those loops don't really matter, they may as well be > HZ/2. > > I think memory compaction updates the counters in the most appropriate > way, by incrementing a counter and then finally doing > mod_zone_page_state() for the counter. The other updaters are thp > collapse and page migration. > > I discount user-visible vmstats here because the trade-off has already > been made that they may be stale for up to 1s and userspace isn't > affected. > > So what happens if we simply convert NR_ISOLATED_* into per-zone > atomic64_t? Just a small uncomfortable thing is that calculation is done with different kinds of metric. For example, comparing vmstat values (NR_INACTIVE_*, NR_ACTIVE_*) with per-zone atomic NR_ISOLATED_* looks ugly and error-prone because their accuracy is different. Thanks.
RE: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
Hi Wolfram, > -Original Message- > From: Wolfram Sang [mailto:w...@the-dreams.de] > Sent: Sunday, January 24, 2016 4:59 PM > To: Sricharan R > Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org; > agr...@codeaurora.org; linux-kernel@vger.kernel.org; linux- > i...@vger.kernel.org; iiva...@mm-sol.com; ga...@codeaurora.org; > dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > andy.gr...@linaro.org; ntel...@codeaurora.org; arch...@codeaurora.org > Subject: Re: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs > without a stop bit > > Hi, > > > "If this is the last message in a group, it is followed by a STOP. > > Otherwise it is followed by the next @i2c_msg transaction segment, > > beginning with a (repeated) START" > > This is correct. > > > So the expectation is that there is no 'STOP' bit inbetween individual > > i2c_msg segments with repeated 'START'. The QUP i2c hardware has no > > way to inform that there should not be a 'STOP' at the end of transaction. > > The only way to implement this is to coalesce all the i2c_msg in > > i2c_msgs in to one transaction and transfer them. Adding the support for > the same. > > So, there will not be a REP_START condition on the bus? I am sorry to say that > I can't accept this. A REP_START is a REP_START and nothing else. There are > devices which will get confused if there is no real REP_START condition. > > Without knowing the HW in detail, can't you implement I2C_M_NOSTART > and let the touchscreen driver use it via regmap? That would be the proper > way (from what I understand). Ah, so what I meant above is there is no 'STOP' bit between each msg in i2c_msgs, but 'REAPEATED_START' still holds true. We are sending 'START' bit for each msg. So these is how each msg in i2c_msg is sent, |--MSG1|-MSG2-|--MSG3| |START|DATA|--|START|DATA|---|START|DATA|STOP| If my commit text does not make this clear, I can reword that ? Regards, Sricharan
[PATCH V2 12/13] Drivers: hv: vmbus: Eliminate the spin lock on the read path
The function hv_ringbuffer_read() is called always on a pre-assigned
CPU. Each chnnel is bound to a specific CPU and this function is
always called on the CPU the channel is bound. There is no need to
acquire the spin lock; get rid of this overhead.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/ring_buffer.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index b53702c..1145f3b 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -388,7 +388,6 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
*inring_info,
u32 bytes_avail_toread;
u32 next_read_location = 0;
u64 prev_indices = 0;
- unsigned long flags;
struct vmpacket_descriptor desc;
u32 offset;
u32 packetlen;
@@ -397,7 +396,6 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
*inring_info,
if (buflen <= 0)
return -EINVAL;
- spin_lock_irqsave(&inring_info->ring_lock, flags);
*buffer_actual_len = 0;
*requestid = 0;
@@ -412,7 +410,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
*inring_info,
* No error is set when there is even no header, drivers are
* supposed to analyze buffer_actual_len.
*/
- goto out_unlock;
+ return ret;
}
next_read_location = hv_get_next_read_location(inring_info);
@@ -425,15 +423,11 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
*inring_info,
*buffer_actual_len = packetlen;
*requestid = desc.trans_id;
- if (bytes_avail_toread < packetlen + offset) {
- ret = -EAGAIN;
- goto out_unlock;
- }
+ if (bytes_avail_toread < packetlen + offset)
+ return -EAGAIN;
- if (packetlen > buflen) {
- ret = -ENOBUFS;
- goto out_unlock;
- }
+ if (packetlen > buflen)
+ return -ENOBUFS;
next_read_location =
hv_get_next_readlocation_withoffset(inring_info, offset);
@@ -460,7 +454,5 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
*inring_info,
*signal = hv_need_to_signal_on_read(bytes_avail_towrite, inring_info);
-out_unlock:
- spin_unlock_irqrestore(&inring_info->ring_lock, flags);
return ret;
}
--
1.7.4.1
[PATCH V2 08/13] Drivers: hv: vmbus: define a new VMBus message type for hvsock
From: Dexuan Cui
A function to send the type of message is also added.
The coming net/hvsock driver will use this function to proactively request
the host to offer a VMBus channel for a new hvsock connection.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel.c | 15 +++
drivers/hv/channel_mgmt.c |4
include/linux/hyperv.h| 13 +
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 3f04533..fcab234 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -219,6 +219,21 @@ error0:
}
EXPORT_SYMBOL_GPL(vmbus_open);
+/* Used for Hyper-V Socket: a guest client's connect() to the host */
+int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
+ const uuid_le *shv_host_servie_id)
+{
+ struct vmbus_channel_tl_connect_request conn_msg;
+
+ memset(&conn_msg, 0, sizeof(conn_msg));
+ conn_msg.header.msgtype = CHANNELMSG_TL_CONNECT_REQUEST;
+ conn_msg.guest_endpoint_id = *shv_guest_servie_id;
+ conn_msg.host_service_id = *shv_host_servie_id;
+
+ return vmbus_post_msg(&conn_msg, sizeof(conn_msg));
+}
+EXPORT_SYMBOL_GPL(vmbus_send_tl_connect_request);
+
/*
* create_gpadl_header - Creates a gpadl for the specified buffer
*/
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index d6c6114..60ca25b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -958,6 +958,10 @@ struct vmbus_channel_message_table_entry
{CHANNELMSG_VERSION_RESPONSE, 1, vmbus_onversion_response},
{CHANNELMSG_UNLOAD, 0, NULL},
{CHANNELMSG_UNLOAD_RESPONSE,1, vmbus_unload_response},
+ {CHANNELMSG_18, 0, NULL},
+ {CHANNELMSG_19, 0, NULL},
+ {CHANNELMSG_20, 0, NULL},
+ {CHANNELMSG_TL_CONNECT_REQUEST, 0, NULL},
};
/*
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 79c4aa7..898eac9 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -392,6 +392,10 @@ enum vmbus_channel_message_type {
CHANNELMSG_VERSION_RESPONSE = 15,
CHANNELMSG_UNLOAD = 16,
CHANNELMSG_UNLOAD_RESPONSE = 17,
+ CHANNELMSG_18 = 18,
+ CHANNELMSG_19 = 19,
+ CHANNELMSG_20 = 20,
+ CHANNELMSG_TL_CONNECT_REQUEST = 21,
CHANNELMSG_COUNT
};
@@ -562,6 +566,13 @@ struct vmbus_channel_initiate_contact {
u64 monitor_page2;
} __packed;
+/* Hyper-V socket: guest's connect()-ing to host */
+struct vmbus_channel_tl_connect_request {
+ struct vmbus_channel_message_header header;
+ uuid_le guest_endpoint_id;
+ uuid_le host_service_id;
+} __packed;
+
struct vmbus_channel_version_response {
struct vmbus_channel_message_header header;
u8 version_supported;
@@ -1283,4 +1294,6 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid);
extern __u32 vmbus_proto_version;
+int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
+ const uuid_le *shv_host_servie_id);
#endif /* _HYPERV_H */
--
1.7.4.1
[PATCH V2 11/13] Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()
From: Dexuan Cui
The hvsock driver needs this API to release all the resources related
to the channel.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 33 -
drivers/hv/connection.c |4 ++--
include/linux/hyperv.h|2 ++
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 76864c9..cf311be 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -310,6 +310,7 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
vmbus_release_relid(relid);
BUG_ON(!channel->rescind);
+ BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
if (channel->target_cpu != get_cpu()) {
put_cpu();
@@ -321,9 +322,7 @@ void hv_process_channel_removal(struct vmbus_channel
*channel, u32 relid)
}
if (channel->primary_channel == NULL) {
- mutex_lock(&vmbus_connection.channel_mutex);
list_del(&channel->listentry);
- mutex_unlock(&vmbus_connection.channel_mutex);
primary_channel = channel;
} else {
@@ -367,6 +366,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
bool fnew = true;
unsigned long flags;
u16 dev_type;
+ int ret;
/* Make sure this is a new offer */
mutex_lock(&vmbus_connection.channel_mutex);
@@ -449,7 +449,11 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
* binding which eventually invokes the device driver's AddDevice()
* method.
*/
- if (vmbus_device_register(newchannel->device_obj) != 0) {
+ mutex_lock(&vmbus_connection.channel_mutex);
+ ret = vmbus_device_register(newchannel->device_obj);
+ mutex_unlock(&vmbus_connection.channel_mutex);
+
+ if (ret != 0) {
pr_err("unable to add child device object (relid %d)\n",
newchannel->offermsg.child_relid);
kfree(newchannel->device_obj);
@@ -725,6 +729,8 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
struct device *dev;
rescind = (struct vmbus_channel_rescind_offer *)hdr;
+
+ mutex_lock(&vmbus_connection.channel_mutex);
channel = relid2channel(rescind->child_relid);
if (channel == NULL) {
@@ -733,7 +739,7 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
* vmbus_process_offer(), we have already invoked
* vmbus_release_relid() on error.
*/
- return;
+ goto out;
}
spin_lock_irqsave(&channel->lock, flags);
@@ -743,7 +749,7 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
if (channel->device_obj) {
if (channel->chn_rescind_callback) {
channel->chn_rescind_callback(channel);
- return;
+ goto out;
}
/*
* We will have to unregister this device from the
@@ -758,8 +764,25 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
hv_process_channel_removal(channel,
channel->offermsg.child_relid);
}
+
+out:
+ mutex_unlock(&vmbus_connection.channel_mutex);
}
+void vmbus_hvsock_device_unregister(struct vmbus_channel *channel)
+{
+ mutex_lock(&vmbus_connection.channel_mutex);
+
+ BUG_ON(!is_hvsock_channel(channel));
+
+ channel->rescind = true;
+ vmbus_device_unregister(channel->device_obj);
+
+ mutex_unlock(&vmbus_connection.channel_mutex);
+}
+EXPORT_SYMBOL_GPL(vmbus_hvsock_device_unregister);
+
+
/*
* vmbus_onoffers_delivered -
* This is invoked when all offers have been delivered.
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 3dc5a9c..deb48e6 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -288,7 +288,8 @@ struct vmbus_channel *relid2channel(u32 relid)
struct list_head *cur, *tmp;
struct vmbus_channel *cur_sc;
- mutex_lock(&vmbus_connection.channel_mutex);
+ BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
+
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
if (channel->offermsg.child_relid == relid) {
found_channel = channel;
@@ -307,7 +308,6 @@ struct vmbus_channel *relid2channel(u32 relid)
}
}
}
- mutex_unlock(&vmbus_connection.channel_mutex);
return found_channel;
}
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 2e54e34..c056f05 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1069,6 +1069,8 @@ int __must_check __
[PATCH V2 10/13] Drivers: hv: vmbus: add a per-channel rescind callback
From: Dexuan Cui
This will be used by the coming hv_sock driver.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 11 +++
include/linux/hyperv.h|9 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 60ca25b..76864c9 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -741,6 +741,10 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
spin_unlock_irqrestore(&channel->lock, flags);
if (channel->device_obj) {
+ if (channel->chn_rescind_callback) {
+ channel->chn_rescind_callback(channel);
+ return;
+ }
/*
* We will have to unregister this device from the
* driver core.
@@ -1110,3 +1114,10 @@ bool vmbus_are_subchannels_present(struct vmbus_channel
*primary)
return ret;
}
EXPORT_SYMBOL_GPL(vmbus_are_subchannels_present);
+
+void vmbus_set_chn_rescind_callback(struct vmbus_channel *channel,
+ void (*chn_rescind_cb)(struct vmbus_channel *))
+{
+ channel->chn_rescind_callback = chn_rescind_cb;
+}
+EXPORT_SYMBOL_GPL(vmbus_set_chn_rescind_callback);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index f636f91..2e54e34 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -766,6 +766,12 @@ struct vmbus_channel {
void (*sc_creation_callback)(struct vmbus_channel *new_sc);
/*
+* Channel rescind callback. Some channels (the hvsock ones), need to
+* register a callback which is invoked in vmbus_onoffer_rescind().
+*/
+ void (*chn_rescind_callback)(struct vmbus_channel *channel);
+
+ /*
* The spinlock to protect the structure. It is being used to protect
* test-and-set access to various attributes of the structure as well
* as all sc_list operations.
@@ -851,6 +857,9 @@ int vmbus_request_offers(void);
void vmbus_set_sc_create_callback(struct vmbus_channel *primary_channel,
void (*sc_cr_cb)(struct vmbus_channel *new_sc));
+void vmbus_set_chn_rescind_callback(struct vmbus_channel *channel,
+ void (*chn_rescind_cb)(struct vmbus_channel *));
+
/*
* Retrieve the (sub) channel on which to send an outgoing request.
* When a primary channel has multiple sub-channels, we choose a
--
1.7.4.1
Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
* Suravee Suthikulpanit [2016-01-27 15:11]: > +AMD SEATTLE DEVICE TREE SUPPORT > +M: Brijesh Singh > +M: Suravee Suthikulpanit > +S: Supported > +M: Tom Lendacky > +S: Supported Just a minor comment, but you have a duplicate "S: Supported" line. -- Martin Michlmayr http://www.cyrius.com/
[PATCH V2 06/13] Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock)
From: Dexuan Cui
A helper function is also added.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
include/linux/hyperv.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 4af51a3..79c4aa7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -235,6 +235,7 @@ struct vmbus_channel_offer {
#define VMBUS_CHANNEL_LOOPBACK_OFFER 0x100
#define VMBUS_CHANNEL_PARENT_OFFER 0x200
#define VMBUS_CHANNEL_REQUEST_MONITORED_NOTIFICATION 0x400
+#define VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER 0x2000
struct vmpacket_descriptor {
u16 type;
@@ -795,6 +796,12 @@ struct vmbus_channel {
enum hv_signal_policy signal_policy;
};
+static inline bool is_hvsock_channel(const struct vmbus_channel *c)
+{
+ return !!(c->offermsg.offer.chn_flags &
+ VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER);
+}
+
static inline void set_channel_signal_state(struct vmbus_channel *c,
enum hv_signal_policy policy)
{
--
1.7.4.1
[PATCH V2 13/13] Drivers: hv: vmbus: Give control over how the ring access is serialized
On the channel send side, many of the VMBUS device drivers explicity serialize access to the outgoing ring buffer. Give more control to the VMBUS device drivers in terms how to serialize accesss to the outgoing ring buffer. The default behavior will be to aquire the ring lock to preserve the current behavior. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c | 15 +++ drivers/hv/channel_mgmt.c |1 + drivers/hv/hyperv_vmbus.h |2 +- drivers/hv/ring_buffer.c | 13 - include/linux/hyperv.h| 16 5 files changed, 37 insertions(+), 10 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index fcab234..56dd261 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -639,6 +639,7 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, u64 aligned_data = 0; int ret; bool signal = false; + bool lock = channel->acquire_ring_lock; int num_vecs = ((bufferlen != 0) ? 3 : 1); @@ -658,7 +659,7 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, bufferlist[2].iov_len = (packetlen_aligned - packetlen); ret = hv_ringbuffer_write(&channel->outbound, bufferlist, num_vecs, - &signal); + &signal, lock); /* * Signalling the host is conditional on many factors: @@ -738,6 +739,7 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, struct kvec bufferlist[3]; u64 aligned_data = 0; bool signal = false; + bool lock = channel->acquire_ring_lock; if (pagecount > MAX_PAGE_BUFFER_COUNT) return -EINVAL; @@ -774,7 +776,8 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, bufferlist[2].iov_base = &aligned_data; bufferlist[2].iov_len = (packetlen_aligned - packetlen); - ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); + ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, + &signal, lock); /* * Signalling the host is conditional on many factors: @@ -837,6 +840,7 @@ int vmbus_sendpacket_mpb_desc(struct vmbus_channel *channel, struct kvec bufferlist[3]; u64 aligned_data = 0; bool signal = false; + bool lock = channel->acquire_ring_lock; packetlen = desc_size + bufferlen; packetlen_aligned = ALIGN(packetlen, sizeof(u64)); @@ -856,7 +860,8 @@ int vmbus_sendpacket_mpb_desc(struct vmbus_channel *channel, bufferlist[2].iov_base = &aligned_data; bufferlist[2].iov_len = (packetlen_aligned - packetlen); - ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); + ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, + &signal, lock); if (ret == 0 && signal) vmbus_setevent(channel); @@ -881,6 +886,7 @@ int vmbus_sendpacket_multipagebuffer(struct vmbus_channel *channel, struct kvec bufferlist[3]; u64 aligned_data = 0; bool signal = false; + bool lock = channel->acquire_ring_lock; u32 pfncount = NUM_PAGES_SPANNED(multi_pagebuffer->offset, multi_pagebuffer->len); @@ -919,7 +925,8 @@ int vmbus_sendpacket_multipagebuffer(struct vmbus_channel *channel, bufferlist[2].iov_base = &aligned_data; bufferlist[2].iov_len = (packetlen_aligned - packetlen); - ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); + ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, + &signal, lock); if (ret == 0 && signal) vmbus_setevent(channel); diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index cf311be..b40f429 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -259,6 +259,7 @@ static struct vmbus_channel *alloc_channel(void) return NULL; channel->id = atomic_inc_return(&chan_num); + channel->acquire_ring_lock = true; spin_lock_init(&channel->inbound_lock); spin_lock_init(&channel->lock); diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index 4ebc796..822566f 100644 --- a/drivers/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -531,7 +531,7 @@ void hv_ringbuffer_cleanup(struct hv_ring_buffer_info *ring_info); int hv_ringbuffer_write(struct hv_ring_buffer_info *ring_info, struct kvec *kv_list, - u32 kv_count, bool *signal); + u32 kv_count, bool *signal, bool lock); int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info, void *buffer, u32 buflen, u32 *buffer_actual_len, diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 1145f3b..56
[PATCH V2 04/13] Drivers: hv: vmbus: don't manipulate with clocksources on crash
From: Vitaly Kuznetsov
clocksource_change_rating() involves mutex usage and can't be called
in interrupt context. It also makes sense to avoid doing redundant work
on crash.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 11bca51..257de21 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -295,8 +295,14 @@ void hv_cleanup(void)
* Cleanup the TSC page based CS.
*/
if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
- clocksource_change_rating(&hyperv_cs_tsc, 10);
- clocksource_unregister(&hyperv_cs_tsc);
+ /*
+* Crash can happen in an interrupt context and unregistering
+* a clocksource is impossible and redundant in this case.
+*/
+ if (!oops_in_progress) {
+ clocksource_change_rating(&hyperv_cs_tsc, 10);
+ clocksource_unregister(&hyperv_cs_tsc);
+ }
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_REFERENCE_TSC, hypercall_msr.as_uint64);
--
1.7.4.1
[PATCH V2 07/13] Drivers: hv: vmbus: vmbus_sendpacket_ctl: hvsock: avoid unnecessary signaling
From: Dexuan Cui When the hvsock channel's outbound ringbuffer is full (i.e., hv_ringbuffer_write() returns -EAGAIN), we should avoid the unnecessary signaling the host. Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 1161d68..3f04533 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -659,6 +659,9 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, * If we cannot write to the ring-buffer; signal the host * even if we may not have written anything. This is a rare * enough condition that it should not matter. +* NOTE: in this case, the hvsock channel is an exception, because +* it looks the host side's hvsock implementation has a throttling +* mechanism which can hurt the performance otherwise. */ if (channel->signal_policy) @@ -666,7 +669,8 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, else kick_q = true; - if (((ret == 0) && kick_q && signal) || (ret)) + if (((ret == 0) && kick_q && signal) || + (ret && !is_hvsock_channel(channel))) vmbus_setevent(channel); return ret; -- 1.7.4.1
[PATCH V2 05/13] Drivers: hv: vmbus: add a helper function to set a channel's pending send size
From: Dexuan Cui
This will be used by the coming net/hvsock driver.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
include/linux/hyperv.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 3172521..4af51a3 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -816,6 +816,12 @@ static inline void *get_per_channel_state(struct
vmbus_channel *c)
return c->per_channel_state;
}
+static inline void set_channel_pending_send_size(struct vmbus_channel *c,
+u32 size)
+{
+ c->outbound.ring_buffer->pending_send_sz = size;
+}
+
void vmbus_onmessage(void *context);
int vmbus_request_offers(void);
--
1.7.4.1
[PATCH V2 09/13] Drivers: hv: vmbus: add a hvsock flag in struct hv_driver
From: Dexuan Cui
Only the coming hv_sock driver has a "true" value for this flag.
We treat the hvsock offers/channels as special VMBus devices.
Since the hv_sock driver handles all the hvsock offers/channels, we need to
tweak vmbus_match() for hv_sock driver, so we introduce this flag.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/vmbus_drv.c |4
include/linux/hyperv.h | 14 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 3668a95..063e5f5 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -582,6 +582,10 @@ static int vmbus_match(struct device *device, struct
device_driver *driver)
struct hv_driver *drv = drv_to_hv_drv(driver);
struct hv_device *hv_dev = device_to_hv_device(device);
+ /* The hv_sock driver handles all hv_sock offers. */
+ if (is_hvsock_channel(hv_dev->channel))
+ return drv->hvsock;
+
if (hv_vmbus_get_id(drv->id_table, &hv_dev->dev_type))
return 1;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 898eac9..f636f91 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -990,6 +990,20 @@ extern void vmbus_ontimer(unsigned long data);
struct hv_driver {
const char *name;
+ /*
+* A hvsock offer, which has a VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER
+* channel flag, actually doesn't mean a synthetic device because the
+* offer's if_type/if_instance can change for every new hvsock
+* connection.
+*
+* However, to facilitate the notification of new-offer/rescind-offer
+* from vmbus driver to hvsock driver, we can handle hvsock offer as
+* a special vmbus device, and hence we need the below flag to
+* indicate if the driver is the hvsock driver or not: we need to
+* specially treat the hvosck offer & driver in vmbus_match().
+*/
+ bool hvsock;
+
/* the device type supported by this driver */
uuid_le dev_type;
const struct hv_vmbus_device_id *id_table;
--
1.7.4.1
[PATCH V2 02/13] Drivers: hv: vmbus: avoid infinite loop in init_vp_index()
From: Vitaly Kuznetsov
When we pick a CPU to use for a new subchannel we try find a non-used one
on the appropriate NUMA node, we keep track of them with the
primary->alloced_cpus_in_node mask. Under normal circumstances we don't run
out of available CPUs but it is possible when we we don't initialize some
cpus in Linux, e.g. when we boot with 'nr_cpus=' limitation.
Avoid the infinite loop in init_vp_index() by checking that we still have
non-used CPUs in the alloced_cpus_in_node mask and resetting it in case
we don't.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 107d72f..af1d82e 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -549,6 +549,17 @@ static void init_vp_index(struct vmbus_channel *channel,
u16 dev_type)
cpumask_of_node(primary->numa_node));
cur_cpu = -1;
+
+ /*
+* Normally Hyper-V host doesn't create more subchannels than there
+* are VCPUs on the node but it is possible when not all present VCPUs
+* on the node are initialized by guest. Clear the alloced_cpus_in_node
+* to start over.
+*/
+ if (cpumask_equal(&primary->alloced_cpus_in_node,
+ cpumask_of_node(primary->numa_node)))
+ cpumask_clear(&primary->alloced_cpus_in_node);
+
while (true) {
cur_cpu = cpumask_next(cur_cpu, &available_mask);
if (cur_cpu >= nr_cpu_ids) {
--
1.7.4.1
[PATCH V2 01/13] tools/hv: Use include/uapi with __EXPORTED_HEADERS__
From: Kamal Mostafa
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. VSS_OP_REGISTER1).
Fixes: 3eb2094c59e8 ("Adding makefile for tools/hv")
Cc:
Signed-off-by: Kamal Mostafa
Signed-off-by: K. Y. Srinivasan
---
tools/hv/Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8ab795..a8c4644 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -5,6 +5,8 @@ PTHREAD_LIBS = -lpthread
WARNINGS = -Wall -Wextra
CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
+
all: hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
%: %.c
$(CC) $(CFLAGS) -o $@ $^
--
1.7.4.1
[PATCH V2 00/13] Drivers: hv: vmbus: Miscellaneous fixes and enhancements
Miscellaneous fixes and enhancements. V2: Fixed a merge error in Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister() Dexuan Cui (7): Drivers: hv: vmbus: add a helper function to set a channel's pending send size Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock) Drivers: hv: vmbus: vmbus_sendpacket_ctl: hvsock: avoid unnecessary signaling Drivers: hv: vmbus: define a new VMBus message type for hvsock Drivers: hv: vmbus: add a hvsock flag in struct hv_driver Drivers: hv: vmbus: add a per-channel rescind callback Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister() K. Y. Srinivasan (2): Drivers: hv: vmbus: Eliminate the spin lock on the read path Drivers: hv: vmbus: Give control over how the ring access is serialized Kamal Mostafa (1): tools/hv: Use include/uapi with __EXPORTED_HEADERS__ Vitaly Kuznetsov (3): Drivers: hv: vmbus: avoid infinite loop in init_vp_index() Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload() Drivers: hv: vmbus: don't manipulate with clocksources on crash drivers/hv/channel.c | 36 ++-- drivers/hv/channel_mgmt.c | 102 ++-- drivers/hv/connection.c |4 +- drivers/hv/hv.c | 10 - drivers/hv/hyperv_vmbus.h |2 +- drivers/hv/ring_buffer.c | 31 ++ drivers/hv/vmbus_drv.c|4 ++ include/linux/hyperv.h| 67 + tools/hv/Makefile |2 + 9 files changed, 225 insertions(+), 33 deletions(-) -- 1.7.4.1
[PATCH V2 03/13] Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()
From: Vitaly Kuznetsov
We have to call vmbus_initiate_unload() on crash to make kdump work but
the crash can also be happening in interrupt (e.g. Sysrq + c results in
such) where we can't schedule or the following will happen:
[ 314.905786] bad: scheduling from the idle thread!
Just skipping the wait (and even adding some random wait here) won't help:
to make host-side magic working we're supposed to receive CHANNELMSG_UNLOAD
(and actually confirm the fact that we received it) but we can't use
interrupt-base path (vmbus_isr()-> vmbus_on_msg_dpc()). Implement a simple
busy wait ignoring all the other messages and use it if we're in an
interrupt context.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 44 +++-
1 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index af1d82e..d6c6114 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "hyperv_vmbus.h"
@@ -589,6 +590,40 @@ static void init_vp_index(struct vmbus_channel *channel,
u16 dev_type)
channel->target_vp = hv_context.vp_index[cur_cpu];
}
+static void vmbus_wait_for_unload(void)
+{
+ int cpu = smp_processor_id();
+ void *page_addr = hv_context.synic_message_page[cpu];
+ struct hv_message *msg = (struct hv_message *)page_addr +
+ VMBUS_MESSAGE_SINT;
+ struct vmbus_channel_message_header *hdr;
+ bool unloaded = false;
+
+ while (1) {
+ if (msg->header.message_type == HVMSG_NONE) {
+ mdelay(10);
+ continue;
+ }
+
+ hdr = (struct vmbus_channel_message_header *)msg->u.payload;
+ if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
+ unloaded = true;
+
+ msg->header.message_type = HVMSG_NONE;
+ /*
+* header.message_type needs to be written before we do
+* wrmsrl() below.
+*/
+ mb();
+
+ if (msg->header.message_flags.msg_pending)
+ wrmsrl(HV_X64_MSR_EOM, 0);
+
+ if (unloaded)
+ break;
+ }
+}
+
/*
* vmbus_unload_response - Handler for the unload response.
*/
@@ -614,7 +649,14 @@ void vmbus_initiate_unload(void)
hdr.msgtype = CHANNELMSG_UNLOAD;
vmbus_post_msg(&hdr, sizeof(struct vmbus_channel_message_header));
- wait_for_completion(&vmbus_connection.unload_event);
+ /*
+* vmbus_initiate_unload() is also called on crash and the crash can be
+* happening in an interrupt context, where scheduling is impossible.
+*/
+ if (!in_interrupt())
+ wait_for_completion(&vmbus_connection.unload_event);
+ else
+ vmbus_wait_for_unload();
}
/*
--
1.7.4.1
RE: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> Sent: Thursday, January 28, 2016 11:38 AM
> To: Byungchul Park
> Cc: a...@linux-foundation.org; mi...@kernel.org; linux-
> ker...@vger.kernel.org; akinobu.m...@gmail.com; j...@suse.cz;
> torva...@linux-foundation.org; pe...@hurleysoftware.com;
> sergey.senozhatsky.w...@gmail.com; sergey.senozhat...@gmail.com
> Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in
> the debug code
>
> ok, I'll repeat the questions.
>
> under what circumstances you hit this problem? ...memory corruption, cpu
> core has been powered off, while it owned the spin_lock... your irqsave
> didn't work?
I think these are not the my case.
>
> the thing is, it's really-really hard to lockup in console_trylock()...
>
> int down_trylock(struct semaphore *sem)
> {
> unsigned long flags;
> int count;
>
> raw_spin_lock_irqsave(&sem->lock, flags); << um...
I also think it's hard, but a backtrace said the lockup happened here.
> count = sem->count - 1;
> if (likely(count >= 0))
> sem->count = count;
> raw_spin_unlock_irqrestore(&sem->lock, flags);
>
> return (count < 0);
> }
>
> was not able to dereference sem->count? `*sem' was corrupted? or because
> sem->lock was corrupted? in any of those cases you solve the problem from
> the wrong side. if you have a memory corruption then it can corrupt
What I solved here is to make it possible to print what the problem is, by
the spinlock debug code instead of system lockup while printing a debug
message. I think it's not wrong.
> anything,
> including, for example, console driver spin_lock.
>
>
> suppose, that you hit do_raw_spin_lock()->spin_dump(), which means that
> the
> spin_lock was not corrupted, it passed debug_spin_lock_before() after all.
> and that spin_lock was taken for longer than `loops_per_jiffy * HZ', while
> other CPU was doing
>
> count = sem->count - 1;
> if (likely(count >= 0))
> sem->count = count;
>
> ???
>
> was the CPU that owned the lock alive? (h/w fault, perhaps?).
I am just curious.. Is it impossible but by h/w fault? e.g. timing to
allocate
virtual cpus to a guest machine when using virtual machine and so on.
>
>
> dunno... yes, this
> printk()->console_trylock()->do_raw_spin_lock()->spin_dump()-
> >printk()
> is possible, but it's possible only when your system is screwed up badly,
> so
> badly that this spin_dump() loop is not really a problem, IMHO.
IMHO, even though a system is screwed up badly, the spinlock debug code have
to print the information about the problem without lockup.
>
> if I'm missing something terribly obvious here, then please give more
> details.
There are already codes to prevent the recursive cycle in the bug case,
but not for the just suspected case. I just made it possible for the
latter case. That's all this patch is doing, now. :)
thanks,
byungchul
>
> -ss
>
> > > Signed-off-by: Byungchul Park
> > > ---
> > > include/linux/debug_locks.h | 4
> > > kernel/locking/spinlock_debug.c | 14 +++---
> > > 2 files changed, 15 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
> > > index 822c135..b0f977e 100644
> > > --- a/include/linux/debug_locks.h
> > > +++ b/include/linux/debug_locks.h
> > > @@ -10,6 +10,10 @@ struct task_struct;
> > > extern int debug_locks;
> > > extern int debug_locks_silent;
> > >
> > > +static inline void __debug_locks_on(void)
> > > +{
> > > + debug_locks = 1;
> > > +}
> > >
> > > static inline int __debug_locks_off(void)
> > > {
> > > diff --git a/kernel/locking/spinlock_debug.c
> b/kernel/locking/spinlock_debug.c
> > > index 0374a59..65177ba 100644
> > > --- a/kernel/locking/spinlock_debug.c
> > > +++ b/kernel/locking/spinlock_debug.c
> > > @@ -113,11 +113,19 @@ static void __spin_lock_debug(raw_spinlock_t
> *lock)
> > > return;
> > > __delay(1);
> > > }
> > > - /* lockup suspected: */
> > > - spin_dump(lock, "lockup suspected");
> > > +
> > > + /*
> > > + * We should prevent calling printk() further, since it would cause
> > > + * an infinite recursive cycle if it's called from printk()!
> > > + */
> > > + if (__debug_locks_off()) {
> > > + /* lockup suspected: */
> > > + spin_dump(lock, "lockup suspected");
> > > #ifdef CONFIG_SMP
> > > - trigger_all_cpu_backtrace();
> > > + trigger_all_cpu_backtrace();
> > > #endif
> > > + __debug_locks_on();
> > > + }
> > >
> > > /*
> > >* The trylock above was causing a livelock. Give the lower level
> arch
> > > --
> > > 1.9.1
> >
Re: [PATCH 16/16] mm/slab: introduce new slab management type, OBJFREELIST_SLAB
On Wed, Jan 27, 2016 at 02:35:04PM +0100, Vlastimil Babka wrote: > On 01/14/2016 06:24 AM, Joonsoo Kim wrote: > > In fact, I tested another idea implementing OBJFREELIST_SLAB with > > extendable linked array through another freed object. It can remove > > memory waste completely but it causes more computational overhead > > in critical lock path and it seems that overhead outweigh benefit. > > So, this patch doesn't include it. > > Can you elaborate? Do we actually need an extendable linked array? Why not > just > store the pointer to the next free object into the object, NULL for the last > one? I.e. a singly-linked list. We should never need to actually traverse it? As Christoph explained, it's the way SLUB manages freed objects. In SLAB case, it doesn't want to touch object itself. It's one of main difference between SLAB and SLUB. These objects are cache-cold now so touching object itself could cause more cache footprint. > > freeing object obj: > *obj = page->freelist; > page->freelist = obj; > > allocating object: > obj = page->freelist; > page->freelist = *obj; > *obj = NULL; > > That means two writes, but if we omit managing page->active, it's not an It's not just matter of number of instructions as explained above. Touching more cache line should also be avoided. Thanks.
Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver
Hi HS,
Sorry for the delay. It is hard to find time to review a >3700 line
driver :-o in detail
Some review comments inline, although I still do not completely
understand how all that this driver does and how it works.
I'll try to find time to go through this driver in detail again next
time you post it for review.
On Tue, Jan 19, 2016 at 9:14 PM, wrote:
> From: HS Liao
>
> This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> CMDQ is used to help read/write registers with critical time limitation,
> such as updating display configuration during the vblank. It controls
> Global Command Engine (GCE) hardware to achieve this requirement.
> Currently, CMDQ only supports display related hardwares, but we expect
> it can be extended to other hardwares for future requirements.
>
> Signed-off-by: HS Liao
[snip]
> diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
> new file mode 100644
> index 000..7570f00
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-cmdq.c
[snip]
> +/*
> + * Maximum prefetch buffer size.
> + * Unit is instructions.
> + */
> +#define CMDQ_MAX_PREFETCH_INSTUCTION 240
INSTRUCTION
[snip]
> +
> +/* get lsb for subsys encoding in arg_a (range: 0 - 31) */
> +
> +enum cmdq_eng {
> + CMDQ_ENG_DISP_UFOE = 0,
> + CMDQ_ENG_DISP_AAL,
> + CMDQ_ENG_DISP_COLOR0,
> + CMDQ_ENG_DISP_COLOR1,
> + CMDQ_ENG_DISP_RDMA0,
> + CMDQ_ENG_DISP_RDMA1,
> + CMDQ_ENG_DISP_RDMA2,
> + CMDQ_ENG_DISP_WDMA0,
> + CMDQ_ENG_DISP_WDMA1,
> + CMDQ_ENG_DISP_OVL0,
> + CMDQ_ENG_DISP_OVL1,
> + CMDQ_ENG_DISP_GAMMA,
> + CMDQ_ENG_DISP_DSI0_CMD,
> + CMDQ_ENG_DISP_DSI1_CMD,
Why do these last two have "_CMD" at the end?
> + CMDQ_MAX_ENGINE_COUNT /* ALWAYS keep at the end */
> +};
> +
> +struct cmdq_command {
> + struct cmdq *cqctx;
> + u32 scenario;
> + /* task priority (NOT HW thread priority) */
> + u32 priority;
> + /* bit flag of used engines */
> + u64 engine_flag;
> + /*
> +* pointer of instruction buffer
> +* This must point to an 64-bit aligned u32 array
> +*/
> + u32 *va_base;
All of your "va" and "va_base" should be void *, not u32 *.
> + /* size of instruction buffer, in bytes. */
> + u32 block_size;
Better to use size_t for "size in bytes".
> +};
> +
> +enum cmdq_code {
> + /* These are actual HW op code. */
> + CMDQ_CODE_MOVE = 0x02,
> + CMDQ_CODE_WRITE = 0x04,
> + CMDQ_CODE_JUMP = 0x10,
> + CMDQ_CODE_WFE = 0x20, /* wait for event (and clear) */
> + CMDQ_CODE_CLEAR_EVENT = 0x21, /* clear event */
> + CMDQ_CODE_EOC = 0x40, /* end of command */
> +};
> +
> +enum cmdq_task_state {
> + TASK_STATE_IDLE,/* free task */
> + TASK_STATE_BUSY,/* task running on a thread */
> + TASK_STATE_KILLED, /* task process being killed */
> + TASK_STATE_ERROR, /* task execution error */
> + TASK_STATE_DONE,/* task finished */
> + TASK_STATE_WAITING, /* allocated but waiting for available thread
> */
> +};
> +
> +struct cmdq_cmd_buf {
> + atomic_tused;
> + void*va;
> + dma_addr_t pa;
> +};
> +
> +struct cmdq_task_cb {
> + /* called by isr */
> + cmdq_async_flush_cb isr_cb;
> + void*isr_data;
> + /* called by releasing task */
> + cmdq_async_flush_cb done_cb;
> + void*done_data;
> +};
> +
> +struct cmdq_task {
> + struct cmdq *cqctx;
> + struct list_headlist_entry;
> +
> + /* state for task life cycle */
> + enum cmdq_task_statetask_state;
> + /* virtual address of command buffer */
> + u32 *va_base;
> + /* physical address of command buffer */
> + dma_addr_t mva_base;
> + /* size of allocated command buffer */
> + u32 buf_size;
size_t
> + /* It points to a cmdq_cmd_buf if this task use command buffer pool.
> */
> + struct cmdq_cmd_buf *cmd_buf;
> +
> + int scenario;
> + int priority;
> + u64 engine_flag;
> + u32 command_size;
> + u32 num_cmd;
> + int reorder;
> + /* HW thread ID; CMDQ_INVALID_THREAD if not running */
> + int thread;
I think this driver will be a lot more clear if you do this:
struct cmdq_thread *thread;
And then use "NULL" for "invalid thread" instead of CMDQ_INVALID_THREAD.
> + /* flag of IRQ received */
> + int irq_flag;
> + /*
Re: [PATCH v7 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Hi Gabriel,
[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on v4.5-rc1 next-20160127]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gabriel-L-Somlo/SysFS-driver-for-QEMU-fw_cfg-device/20160128-111609
config: ia64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
>> drivers/firmware/qemu_fw_cfg.c:112:4: warning: #warning "QEMU FW_CFG may not
>> be available on this architecture!" [-Wcpp]
# warning "QEMU FW_CFG may not be available on this architecture!"
^
vim +112 drivers/firmware/qemu_fw_cfg.c
96 release_region(fw_cfg_p_base, fw_cfg_p_size);
97 }
98 }
99
100 /* arch-specific ctrl & data register offsets are not available in
ACPI, DT */
101 #if !(defined(FW_CFG_CTRL_OFF) && defined(FW_CTRL_DATA_OFF))
102 # if (defined(CONFIG_ARM) || defined(CONFIG_ARM64))
103 # define FW_CFG_CTRL_OFF 0x08
104 # define FW_CFG_DATA_OFF 0x00
105 # elif (defined(CONFIG_PPC_PMAC) || defined(CONFIG_SPARC32)) /*
ppc/mac,sun4m */
106 # define FW_CFG_CTRL_OFF 0x00
107 # define FW_CFG_DATA_OFF 0x02
108 # elif (defined(CONFIG_X86) || defined(CONFIG_SPARC64)) /* x86, sun4u */
109 # define FW_CFG_CTRL_OFF 0x00
110 # define FW_CFG_DATA_OFF 0x01
111 # else
> 112 # warning "QEMU FW_CFG may not be available on this architecture!"
113 # define FW_CFG_CTRL_OFF 0x00
114 # define FW_CFG_DATA_OFF 0x01
115 # endif
116 #endif
117
118 /* initialize fw_cfg device i/o from platform data */
119 static int fw_cfg_do_platform_probe(struct platform_device *pdev)
120 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
PM domain change on unbound devices warning on ipmi_si unload
Starting in 4.5-rc1, I noticed this warning on ipmi_si driver removal: % modprobe ipmi_si % rmmod ipmi_si bus: 'platform': driver_probe_device: matched device IPI0001:00 with driver ipmi_si bus: 'platform': really_probe: probing driver ipmi_si with device IPI0001:00 ipmi_si IPI0001:00: ipmi_si: probing via ACPI ipmi_si IPI0001:00: [io 0x0ca2-0x0ca3] regsize 1 spacing 1 irq 0 ipmi_si: Adding ACPI-specified kcs state machine driver: 'ipmi_si': driver_bound: bound to device 'IPI0001:00' bus: 'platform': really_probe: bound device IPI0001:00 to driver ipmi_si IPMI System Interface driver. ipmi_si: probing via SMBIOS ipmi_si: SMBIOS: io 0xda2 regsize 1 spacing 1 irq 0 ipmi_si: Adding SMBIOS-specified kcs state machine ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0 Registering platform device 'ipmi_bmc.0674.66'. Parent at platform driver: 'ipmi': driver_bound: bound to device 'ipmi_bmc.0674.66' ipmi_si IPI0001:00: Found new BMC (man_id: 0x77, prod_id: 0x0674, dev_id: 0x42) ipmi_si IPI0001:00: IPMI kcs interface initialized [ cut here ] WARNING: CPU: 39 PID: 3678 at drivers/base/power/common.c:150 dev_pm_domain_set+0x52/0x60() PM domains can only be changed for unbound devices [ ... snip ... ] CPU: 39 PID: 3678 Comm: rmmod Tainted: G OE 4.5.0-rc1+ #57 Hardware name: Stratus ftServer 6800/G7LYY, BIOS BIOS Version 8.1:61 09/10/2015 3883b68d 8820334d7d30 8132caf0 8820334d7d78 8820334d7d68 8107f1b6 8810351eca00 0001 01c2a330 01c29010 Call Trace: [] dump_stack+0x44/0x64 [] warn_slowpath_common+0x86/0xc0 [] warn_slowpath_fmt+0x5c/0x80 [] dev_pm_domain_set+0x52/0x60 [] acpi_dev_pm_detach+0x3f/0x84 [] dev_pm_domain_detach+0x27/0x30 [] platform_drv_remove+0x38/0x40 [] __device_release_driver+0x9a/0x140 [] driver_detach+0xb8/0xc0 [] bus_remove_driver+0x55/0xd0 [] driver_unregister+0x2c/0x50 [] platform_driver_unregister+0x12/0x20 [] cleanup_ipmi_si+0x29/0xa0 [ipmi_si] [] SyS_delete_module+0x190/0x220 [] entry_SYSCALL_64_fastpath+0x12/0x71 ---[ end trace 671ca97b9ac15462 ]--- My platform has two BMCs (perhaps this is messing with a refcount somewhere), but I wonder about the ordering of this code: __device_release_driver(struct device *dev) drv->remove(dev); [ platform_drv_remove ] ... dev_pm_domain_detach device_is_bound return dev->p && klist_node_attached(&dev->p->knode_driver) ... klist_remove(&dev->p->knode_driver); Is the klist_remove at the bottom of __device_release_driver necessary to satisfy the earlier check in dev_pm_domain_detach's device_is_bound assertion? If so, could these be out of order? This is core driver code, so I'm assuming it's not something as simple as the following (which avoided the warning on unload at least). Any suggestions or extra debugging ideas welcome! This occurs on every unload, so I'd be glad to test real solutions :) Thanks, -- Joe -->8-- diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c4da2df..bba54e1 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -756,6 +756,7 @@ static void __device_release_driver(struct device *dev) pm_runtime_put_sync(dev); + klist_remove(&dev->p->knode_driver); if (dev->bus && dev->bus->remove) dev->bus->remove(dev); else if (drv->remove) @@ -767,7 +768,6 @@ static void __device_release_driver(struct device *dev) dev->pm_domain->dismiss(dev); pm_runtime_reinit(dev); - klist_remove(&dev->p->knode_driver); device_pm_check_callbacks(dev); if (dev->bus) blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
Re: [PATCH/RFC 3/3] s390: query dynamic DEBUG_PAGEALLOC setting
On Wed, Jan 27, 2016 at 02:03:36PM +0100, Vlastimil Babka wrote: > On 01/27/2016 01:47 PM, Christian Borntraeger wrote: > > On 01/27/2016 01:41 PM, Vlastimil Babka wrote: > >> On 01/27/2016 01:59 AM, Joonsoo Kim wrote: > >> > >> I think it might be worth also to convert debug_pagealloc_enabled() to be > >> based > >> on static key, like I did for page_owner [1]. That should help make it > >> possible > >> to have virtually no overhead when compiling kernel with > >> CONFIG_DEBUG_PAGEALLOC > >> without enabling it boot-time. I assume it's one of the goals here? > > > > We could do something like that but dump_stack and setup of the initial > > identity > > mapping of the kernel as well as the initial page protection are not hot > > path > > as far as I can tell. Any other places? > > Well, mostly kernel_map_pages() which is used in page allocation hotpaths. We cannot just convert it because setup_arch() is called before jump_label_init(). We can do it by introducing _early variant but I'm not sure it's worth doing. I think that just make it unlikely works well. Recently, I tested a micro benchmark on slab alloc/free on CONFIG_SLUB with applying static branch for debug option which currently is using unlikely branch and can't find any noticeble performance difference. Thanks.
Re: [PATCH v6 1/9] ppc64 (le): prepare for -mprofile-kernel
On Wed, 2016-01-27 at 11:44 +0100, Torsten Duwe wrote:
> On Wed, Jan 27, 2016 at 09:19:27PM +1100, Michael Ellerman wrote:
> > Hi Torsten,
> >
> > > +++ b/arch/powerpc/kernel/entry_64.S
> > > @@ -1206,7 +1206,12 @@ _GLOBAL(enter_prom)
> > > #ifdef CONFIG_DYNAMIC_FTRACE
> > > _GLOBAL(mcount)
> > > _GLOBAL(_mcount)
> > > - blr
> > > + std r0,LRSAVE(r1) /* gcc6 does this _after_ this call _only_ */
> > > + mflrr0
> > > + mtctr r0
> > > + ld r0,LRSAVE(r1)
> > > + mtlrr0
> > > + bctr
> >
> > Can we use r11 instead? eg:
> >
> > _GLOBAL(_mcount)
> > mflrr11
> > mtctr r11
> > mtlrr0
> > bctr
> >
> > Otherwise I worry the std/ld is going to cause a load-hit-store. And it's
> > just
> > plain more instructions too.
> >
> > I don't quite grok the gcc code enough to tell if that's always safe, GCC
> > does
> > use r11 sometimes, but I don't think it ever expects it to survive across
> > _mcount()?
>
> I used r11 in that area once, and it crashed, but I don't recall the deatils.
> We'll see. The performance shouldn't be critical, as the code is only used
> during boot-up. With DYNAMIC_FTRACE, The calls will be replaced by
> 0x60^W PPC_INST_NOP :)
True.
That raises an interesting question, how does it work *without* DYNAMIC_FTRACE?
It looks like you haven't updated that version of _mcount at all? Or maybe I'm
missing an #ifdef somewhere?
_GLOBAL_TOC(_mcount)
/* Taken from output of objdump from lib64/glibc */
mflrr3
ld r11, 0(r1)
stdur1, -112(r1)
std r3, 128(r1)
ld r4, 16(r11)
subir3, r3, MCOUNT_INSN_SIZE
LOAD_REG_ADDR(r5,ftrace_trace_function)
ld r5,0(r5)
ld r5,0(r5)
mtctr r5
bctrl
nop
It doesn't look like that will work right with the -mprofile-kernel ABI. And
indeed it doesn't boot.
So we'll need to work that out. I guess the minimum would be to disable
-mprofile-kernel if DYNAMIC_FTRACE is disabled.
Frankly I think we'd be happy to *only* support DYNAMIC_FTRACE, but the generic
code doesn't let us do that at the moment.
> > > index 44d4d8e..080c525 100644
> > > --- a/arch/powerpc/kernel/ftrace.c
> > > +++ b/arch/powerpc/kernel/ftrace.c
> > > @@ -306,11 +306,19 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned
> > > long addr)
> > >* The load offset is different depending on the ABI. For simplicity
> > >* just mask it out when doing the compare.
> > >*/
> > > +#ifndef CC_USING_MPROFILE_KERNEL
> > > if ((op[0] != 0x4808) || ((op[1] & 0x) != 0xe841)) {
> > > - pr_err("Unexpected call sequence: %x %x\n", op[0], op[1]);
> > > + pr_err("Unexpected call sequence at %p: %x %x\n",
> > > + ip, op[0], op[1]);
> > > return -EINVAL;
> > > }
> > > -
> > > +#else
> > > + /* look for patched "NOP" on ppc64 with -mprofile-kernel */
> > > + if (op[0] != 0x6000) {
> >
> > That is "PPC_INST_NOP".
> >
> > > + pr_err("Unexpected call at %p: %x\n", ip, op[0]);
> > > + return -EINVAL;
> > > + }
> > > +#endif
> >
> > Can you please break that out into a static inline, with separate versions
> > for
> > the two cases.
> >
> > We should aim for no #ifdefs inside functions.
>
> Points taken.
Thanks.
> Does this set _work_ for you now? That'd be great to hear.
Sort of, see previous comments.
But it's better than the previous version which didn't boot :)
Also ftracetest fails at step 8:
...
[8] ftrace - function graph filters with stack tracer
Unable to handle kernel paging request for data at address 0xd33d7f70
Faulting instruction address: 0xc01b16ec
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: virtio_balloon fuse autofs4 virtio_net virtio_pci
virtio_ring virtio
CPU: 15 PID: 0 Comm: swapper/15 Not tainted 4.5.0-rc1-9-g325e167adf2b #4
task: c001fefe0400 ti: c001fff74000 task.ti: c001fb0e
NIP: c01b16ec LR: c0048abc CTR: d32d0424
REGS: c001fff77aa0 TRAP: 0300 Not tainted
(4.5.0-rc1-9-g325e167adf2b)
MSR: 80009033 CR: 28002422 XER: 2000
CFAR: c04ebbf0 DAR: d33d7f70 DSISR: 4000 SOFTE: 0
GPR00: c0009f84 c001fff77d20 d32d9fb0 c0118d70
GPR04: d32d0420 0001ff17
GPR08: d33d9fb0 c001f36f2c00 d32d1898
GPR12: c0118d70 cfe03c00 c001fb0e c0d6d3c8
GPR16: c0d59c28 c001fb0e 0001 0008
GPR20: c001fb0e0080 0001 0002 0019
GPR24: c001f36f2c00
GPR28: d32d0420 c0118d70 c001f3570680
NIP [c01b16ec] ftrace_graph_is_dead+0xc/0x20
LR [c0048abc] p
linux-next: Tree for Jan 28
Hi all, Changes since 20160127: The aio tree still had a build failure so I used the version from next-20160111. Non-merge commits (relative to Linus' tree): 1465 1366 files changed, 48045 insertions(+), 18337 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 239 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (03c21cb775a3 Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost) Merging fixes/master (92e963f50fc7 Linux 4.5-rc1) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7) Merging arm-current/fixes (03590cb56d5d ARM: wire up copy_file_range() syscall) Merging m68k-current/for-linus (eb37bc3f85b6 m68k: Provide __phys_to_pfn() and __pfn_to_phys()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (7e56f627768d powerpc/eeh: Fix PE location code) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (1a40b95374f6 sparc: Fix system call tracing register handling.) Merging net/master (3b9e9488098a Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (b16c29191dc8 netfilter: nf_conntrack: use safer way to lock all buckets) Merging wireless-drivers/master (f9ead9beef3f Merge tag 'iwlwifi-for-kalle-2016-01-26_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (6736fde9672f rfkill: fix rfkill_fop_read wait_event usage) Merging sound-current/for-linus (61595dca742a ALSA: Add missing dependency on CONFIG_SND_TIMER) Merging pci-current/for-linus (c43e4b52cbf2 PCI: iproc: Fix BCMA PCIe bus scanning regression) Merging driver-core.current/driver-core-linus (25cad69f21f5 base/platform: Fix platform drivers with no probe callback) Merging tty.current/tty-linus (f4f9edcf9b52 staging/speakup: Use tty_ldisc_ref() for paste kworker) Merging usb.current/usb-linus (d8f00cd685f5 usb: hub: do not clear BOS field during reset device) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (4152b387da81 USB: option: fix Cinterion AHxx enumeration) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (f744c423cacf Merge tag 'iio-fixes-for-4.4c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (587198ba5206 vmstat: Remove BUG_ON from vmstat_update) Merging input-current/for-linus (b26a95d43519 Merge branch 'next' into for-linus) Merging crypto-current/master (00420a65fa2b crypto: shash - Fix has_key setting) Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver explicitly non-modular) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put
Re: [PATCH 1/4] mailbox: mailbox-test: Use more consistent format for calling copy_from_user()
On Thu, Jan 14, 2016 at 12:41 PM, Lee Jones wrote:
> While we're at it, ensure copy-to location is NULL'ed in the error path.
>
> Suggested-by: Dan Carpenter
> Signed-off-by: Lee Jones
> ---
> drivers/mailbox/mailbox-test.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
> index 684ae17..7d9b915 100644
> --- a/drivers/mailbox/mailbox-test.c
> +++ b/drivers/mailbox/mailbox-test.c
> @@ -63,9 +63,9 @@ static ssize_t mbox_test_signal_write(struct file *filp,
> if (!tdev->signal)
> return -ENOMEM;
>
> - ret = copy_from_user(tdev->signal, userbuf, count);
> - if (ret) {
> + if (copy_from_user(tdev->signal, userbuf, count)) {
> kfree(tdev->signal);
> + tdev->signal = NULL;
> return -EFAULT;
> }
>
The function is left to return based on an uninitialized variable
('ret' on stack), so please merge this and the patch 2/4.
Thanks.
Re: [PATCH] pinctrl: mediatek: guard sub-directory with CONFIG_PINCTRL_MTK
Hi Linus 2016-01-27 23:11 GMT+09:00 Linus Walleij : > On Sat, Jan 23, 2016 at 4:33 PM, Masahiro Yamada > wrote: > >> CONFIG_PINCTRL_MTK is more suitable than CONFIG_ARCH_MEDIATEK >> to guard the drivers/pinctrl/mediatek/ directory. >> (I renamed CONFIG_PINCTRL_MTK_COMMON to CONFIG_PINCTRL_MTK.) >> >> Signed-off-by: Masahiro Yamada > > This patch does not apply to linux v4.5-rc1, please rebase the > patch and resend. These two patches can be applied in this order: https://patchwork.kernel.org/patch/8097541/ https://patchwork.kernel.org/patch/8097551/ (Sorry, I should have sent them as a series.) If you want to apply only the latter onto v4.5-rc1, "git am -C2" can apply it. -- Best Regards Masahiro Yamada
[PATCH v2] locktorture: Fix NULL pointer when torture_type is invalid
Insmod locktorture with torture_type=mutex will lead to crash,
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = ffc0f6c1
[0008] *pgd=00013b221003, *pud=00013b221003, *pmd=a
Internal error: Oops: 9406 [#1] PREEMPT SMP
Modules linked in: locktorture(+) torture
CPU: 2 PID: 1462 Comm: insmod Not tainted 4.4.0+ #19
Hardware name: linux,dummy-virt (DT)
task: ffc0fb2b3700 ti: ffc0fa938000 task.ti: ffc0fa938000
PC is at __torture_print_stats+0x18/0x180 [locktorture]
LR is at lock_torture_stats_print+0x68/0x110 [locktorture]
pc : [] lr : [] pstate: 6145
sp : ffc0fa93bb20
[snip...]
Call trace:
[] __torture_print_stats+0x18/0x180 [locktorture]
[] lock_torture_stats_print+0x68/0x110 [locktorture]
[] lock_torture_cleanup+0xc4/0x278 [locktorture]
[] lock_torture_init+0x144/0x5b0 [locktorture]
[] do_one_initcall+0x94/0x1a0
[] do_init_module+0x60/0x1c8
[] load_module+0x1880/0x1c9c
[] SyS_finit_module+0x7c/0x88
[] el0_svc_naked+0x24/0x28
Fix it by check statp in __torture_print_stats(), if it is NULL, just
create a lock-torture-statistics message with zero statistic argument.
Cc: Josh Triplett
Cc: Paul E. McKenney
Signed-off-by: Kefeng Wang
---
kernel/locking/locktorture.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 8ef1919..7f0cf9c 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -647,19 +647,23 @@ static void __torture_print_stats(char *page,
bool fail = 0;
int i, n_stress;
long max = 0;
- long min = statp[0].n_lock_acquired;
+ long min = 0;
long long sum = 0;
- n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
- for (i = 0; i < n_stress; i++) {
- if (statp[i].n_lock_fail)
- fail = true;
- sum += statp[i].n_lock_acquired;
- if (max < statp[i].n_lock_fail)
- max = statp[i].n_lock_fail;
- if (min > statp[i].n_lock_fail)
- min = statp[i].n_lock_fail;
+ if (statp) {
+ min = statp[0].n_lock_acquired;
+ n_stress = write ? cxt.nrealwriters_stress :
cxt.nrealreaders_stress;
+ for (i = 0; i < n_stress; i++) {
+ if (statp[i].n_lock_fail)
+ fail = true;
+ sum += statp[i].n_lock_acquired;
+ if (max < statp[i].n_lock_fail)
+ max = statp[i].n_lock_fail;
+ if (min > statp[i].n_lock_fail)
+ min = statp[i].n_lock_fail;
+ }
}
+
page += sprintf(page,
"%s: Total: %lld Max/Min: %ld/%ld %s Fail: %d %s\n",
write ? "Writes" : "Reads ",
--
2.6.0.GIT
