Re: [PATCH 4/4] mvolatile: Add page purging logic SIGBUS trap
On Fri, Apr 11, 2014 at 01:15:40PM -0700, John Stultz wrote:
This patch adds the hooks in the vmscan logic to purge volatile pages
and mark their pte as purged. With this, volatile pages will be purged
under pressure, and their ptes swap entry's marked. If the purged pages
are accessed before being marked non-volatile, we catch this and send a
SIGBUS.
This is a simplified implementation that uses logic from Minchan's earlier
efforts, so credit to Minchan for his work.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Android Kernel Team kernel-t...@android.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Robert Love rl...@google.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Hugh Dickins hu...@google.com
Cc: Dave Hansen d...@sr71.net
Cc: Rik van Riel r...@redhat.com
Cc: Dmitry Adamushko dmitry.adamus...@gmail.com
Cc: Neil Brown ne...@suse.de
Cc: Andrea Arcangeli aarca...@redhat.com
Cc: Mike Hommey m...@glandium.org
Cc: Taras Glek tg...@mozilla.com
Cc: Jan Kara j...@suse.cz
Cc: KOSAKI Motohiro kosaki.motoh...@gmail.com
Cc: Michel Lespinasse wal...@google.com
Cc: Minchan Kim minc...@kernel.org
Cc: Keith Packard kei...@keithp.com
Cc: linux...@kvack.org linux...@kvack.org
Signed-off-by: John Stultz john.stu...@linaro.org
---
include/linux/mvolatile.h | 2 +
mm/internal.h | 2 -
mm/memory.c | 8
mm/mvolatile.c| 120
++
mm/rmap.c | 5 ++
mm/vmscan.c | 12 +
6 files changed, 147 insertions(+), 2 deletions(-)
diff --git a/include/linux/mvolatile.h b/include/linux/mvolatile.h
index 973bb3b..8cfe6e0 100644
--- a/include/linux/mvolatile.h
+++ b/include/linux/mvolatile.h
@@ -5,4 +5,6 @@
#define MVOLATILE_VALID_FLAGS (0) /* Don't yet support any flags */
+extern int purge_volatile_page(struct page *page);
+
#endif /* _LINUX_MVOLATILE_H */
diff --git a/mm/internal.h b/mm/internal.h
index 29e1e76..ea66bf9 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -225,10 +225,8 @@ static inline void mlock_migrate_page(struct page
*newpage, struct page *page)
extern pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma);
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
extern unsigned long vma_address(struct page *page,
struct vm_area_struct *vma);
-#endif
#else /* !CONFIG_MMU */
static inline int mlocked_vma_newpage(struct vm_area_struct *v, struct page
*p)
{
diff --git a/mm/memory.c b/mm/memory.c
index 22dfa61..9043e4c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -60,6 +60,7 @@
#include linux/migrate.h
#include linux/string.h
#include linux/dma-debug.h
+#include linux/mvolatile.h
#include asm/io.h
#include asm/pgalloc.h
@@ -3643,6 +3644,8 @@ static int handle_pte_fault(struct mm_struct *mm,
entry = *pte;
if (!pte_present(entry)) {
+ swp_entry_t mvolatile_entry;
+
if (pte_none(entry)) {
if (vma-vm_ops) {
if (likely(vma-vm_ops-fault))
@@ -3652,6 +3655,11 @@ static int handle_pte_fault(struct mm_struct *mm,
return do_anonymous_page(mm, vma, address,
pte, pmd, flags);
}
+
+ mvolatile_entry = pte_to_swp_entry(entry);
+ if (unlikely(is_purged_entry(mvolatile_entry)))
+ return VM_FAULT_SIGBUS;
+
There is no pte lock so that is_purged_entry isn't safe so if race happens,
do_swap_page could have a problem so it would be better to handle it
do_swap_page with pte lock because we used swp_pte to indicate purged pte.
I tried to solve it while we were in Napa(you could remember I sent
crap patchset to you privately but failed to fix and I still didn't get
a time to fix it :( ) but I'd like to inform this problem.
if (pte_file(entry))
return do_nonlinear_fault(mm, vma, address,
pte, pmd, flags, entry);
diff --git a/mm/mvolatile.c b/mm/mvolatile.c
index 38c8315..16dccee 100644
--- a/mm/mvolatile.c
+++ b/mm/mvolatile.c
@@ -279,3 +279,123 @@ SYSCALL_DEFINE5(mvolatile, unsigned long, start,
size_t, len,
out:
return ret;
}
+
+
+/**
+ * try_to_purge_one - Purge a volatile page from a vma
+ * @page: page to purge
+ * @vma: vma to purge page from
+ *
+ * Finds the pte for a page in a vma, marks the pte as purged
+ * and release the page.
+ */
+static void try_to_purge_one(struct page *page, struct vm_area_struct *vma)
+{
+ struct mm_struct *mm = vma-vm_mm;
+ pte_t *pte;
+ pte_t pteval;
+ spinlock_t *ptl;
+ unsigned long addr;
+
+ VM_BUG_ON(!PageLocked(page));
+
+ addr = vma_address(page, vma);
+ pte = page_check_address(page, mm, addr, ptl, 0);
+ if (!pte)
+ return;
+
+ BUG_ON(vma-vm_flags
Re: [PATCH] net: ipv4: current group_info should be put after using.
From: Wang, Xiaoming xiaoming.w...@intel.com Date: Mon, 14 Apr 2014 12:30:45 -0400 Plug a group_info refcount leak in ping_init. group_info is only needed during initialization and the code failed to release the reference on exit. While here move grabbing the reference to a place where it is actually needed. Signed-off-by: Chuansheng Liu chuansheng@intel.com Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com Signed-off-by: xiaoming wang xiaoming.w...@intel.com Applied and queued up for -stable, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] kernel/rcu/tree.c: remove duplicate extern definition
On Sun, Apr 13, 2014 at 10:50 PM, Joe Perches j...@perches.com wrote: -/* - * This function really isn't for public consumption, but RCU is special in - * that context switches can allow the state machine to make progress. - */ -extern void resched_cpu(int cpu); why not #include sched.h and remove both declarations? As the comment mentions, resched_cpu is internal to the scheduler and hence is in sched/sched.h file and not in linux/sched.h. sched/sched.h cannot be included in other subsystems directly. Regards, -- Pranith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] kernel/rcu/tree.c: remove duplicate extern definition
On Sun, 2014-04-13 at 23:03 -0400, Pranith Kumar wrote: On Sun, Apr 13, 2014 at 10:50 PM, Joe Perches j...@perches.com wrote: -/* - * This function really isn't for public consumption, but RCU is special in - * that context switches can allow the state machine to make progress. - */ -extern void resched_cpu(int cpu); why not #include sched.h and remove both declarations? As the comment mentions, resched_cpu is internal to the scheduler and hence is in sched/sched.h file and not in linux/sched.h. Note the use of quotes and lack of angle brackets. sched/sched.h cannot be included in other subsystems directly. If functions from it can be declared extern, then likely it could be used in an #include. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] kernel/rcu/tree.c: remove duplicate extern definition
On Sun, Apr 13, 2014 at 11:18 PM, Joe Perches j...@perches.com wrote: As the comment mentions, resched_cpu is internal to the scheduler and hence is in sched/sched.h file and not in linux/sched.h. Note the use of quotes and lack of angle brackets. sched/sched.h cannot be included in other subsystems directly. If functions from it can be declared extern, then likely it could be used in an #include. All the users of resched_cpu are in kernel/sched/ and in kernel/rcu/tree.c. I think the only reason this was declared extern was for the special use in rcu/tree.c. -- Pranith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] module: Introduce MODULE_STATE_COMING_FINAL to avoid ftrace warning
(2014/04/14 11:49), Takao Indoh wrote:
ping, any comments?
(2014/04/02 16:54), Takao Indoh wrote:
This patch adds new module state MODULE_STATE_COMING_FINAL to avoid
ftrace waring message when loading two modules simultaneously.
The original patch was written by Steven Rostedt, see below.
https://lkml.org/lkml/2014/3/24/242
Ftrace waring message below is got when insmod two modules almost at the
same time and at least one of them uses register_kprobe() in its
module_init.
[ 409.337936] [ cut here ]
[ 409.337945] WARNING: CPU: 12 PID: 10028 at
/mnt/repos/linux/kernel/trace/ftrace.c:1716 ftrace_bug+0x206/0x270()
(snip)
[ 409.337983] Call Trace:
[ 409.337990] [81547bfe] dump_stack+0x45/0x56
[ 409.337993] [81049a0d] warn_slowpath_common+0x7d/0xa0
[ 409.337997] [a0364000] ? 0xa0363fff
[ 409.337999] [81049aea] warn_slowpath_null+0x1a/0x20
[ 409.338001] [810e79f6] ftrace_bug+0x206/0x270
[ 409.338004] [a0364000] ? 0xa0363fff
[ 409.338006] [810e7d8e] ftrace_process_locs+0x32e/0x710
[ 409.338008] [810e8206] ftrace_module_notify_enter+0x96/0xf0
[ 409.338012] [81551dec] notifier_call_chain+0x4c/0x70
[ 409.338018] [8106fbfd] __blocking_notifier_call_chain+0x4d/0x70
[ 409.338020] [8106fc36] blocking_notifier_call_chain+0x16/0x20
[ 409.338026] [810bf3f4] load_module+0x1f54/0x25d0
[ 409.338028] [810baab0] ? store_uevent+0x40/0x40
[ 409.338031] [810bfbe6] SyS_finit_module+0x86/0xb0
[ 409.338036] [81556752] system_call_fastpath+0x16/0x1b
[ 409.338037] ---[ end trace e7e27c36e7a65831 ]---
[ 409.338040] ftrace faulted on writing [a0364000]
handler_pre+0x0/0x10 [test2]
This is the sequence when this problem occurs.
insmod module A
init_module
load_module
do_init_module
do_one_initcall
(module_init)
register_kprobe
arm_kprobe
arm_kprobe_ftrace
register_ftrace_function
mutex_lock(ftrace_lock) --- (1)
ftrace_startup
ftrace_startup_enable
ftrace_run_update_code
ftrace_arch_code_modify_post_process
set_all_modules_text_ro (2)
mutex_unlock(ftrace_lock) - (3)
insmod module B
init_module
load_module
do_init_module
blocking_notifier_call_chain
ftrace_module_notify_enter
ftrace_init_module
ftrace_process_locs
mutex_lock(ftrace_lock) (4)
ftrace_update_code
__ftrace_replace_code
ftrace_make_nop
ftrace_modify_code_direct
do_ftrace_mod_code
probe_kernel_write (5)
o Module A gets ftrace_lock at (1)
o Module B also tries to get ftrace_lock at (4) somewhat late, and waits
here because module A got it.
o Module A sets all modules text to ReadOnly at (2), and then release
ftrace_lock at (3)
o Module B wakes up and tries to rewrite its text at (5), but it fails
because it is already changed to RO at (2) by modules A. The ftrace
waring message is outputted.
This patch introduces MODULE_STATE_COMING_FINAL which means that the
module is ready to be changed to ReadOnly. By this, the modules B is not
change to RO at (2) because its state is still MODULE_STATE_COMING, so
this warning message is avoided. Module B is changed to RO in the
do_init_module() after comes back from notifier.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
As Steven said, it should have his signed-off too, anyway,
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you,
---
include/linux/module.h | 9 +
kernel/module.c| 13 -
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index eaf60ff..32f4481 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -207,10 +207,11 @@ struct module_use {
};
enum module_state {
-MODULE_STATE_LIVE, /* Normal state. */
-MODULE_STATE_COMING,/* Full formed, running module_init. */
-MODULE_STATE_GOING, /* Going away. */
-MODULE_STATE_UNFORMED, /* Still setting it up. */
+MODULE_STATE_LIVE, /* Normal state. */
+MODULE_STATE_COMING,/* Full formed, running module_init. */
+MODULE_STATE_COMING_FINAL, /* Ready to be changed to read only. */
+MODULE_STATE_GOING, /* Going away. */
+MODULE_STATE_UNFORMED, /* Still setting it up. */
};
/**
diff --git a/kernel/module.c b/kernel/module.c
index
Re: [PATCH v2] tuntap: add flow control to support back pressure
On 04/13/2014 09:40 PM, David Miller wrote: From: Steven Galgano sgalg...@adjacentlink.com Date: Sun, 13 Apr 2014 21:30:27 -0400 Added optional per queue flow control support using IFF_FLOW_CONTROL. When the IFF_FLOW_CONTROL TUNSETIFF flag is specified it will set a per queue flag to indicate that the queue should be stopped using netif_tx_stop_queue(), rather than discarding frames once full. After reading a frame from the respective stopped queue, a netif_tx_wake_queue() is issued to signal resource availability. The per queue TUN_FLOW_CONTROL flag is stored in struct tun_file. This provides the flexibility to enable flow control on all, none or some queues when using IFF_MULTI_QUEUE. When not using IFF_MULTI_QUEUE, IFF_FLOW_CONTROL will apply to the single queue. No changes were made to the default drop frame policy. This change adds support for back pressure use cases. Reported-by: Brian Adamson brian.adam...@nrl.navy.mil Tested-by: Joseph Giovatto jgiova...@djacentlink.com Signed-off-by: Steven Galgano sgalg...@adjacentlink.com Please format your commit messages to ~80 columns of text. It won't be automatically formatted by GIT and in fact it looks ugly with all the wrapping in text based tools. Added optional per queue flow control support using IFF_FLOW_CONTROL. When the IFF_FLOW_CONTROL TUNSETIFF flag is specified it will set a per queue flag to indicate that the queue should be stopped using netif_tx_stop_queue(), rather than discarding frames once full. After reading a frame from the respective stopped queue, a netif_tx_wake_queue() is issued to signal resource availability. The per queue TUN_FLOW_CONTROL flag is stored in struct tun_file. This provides the flexibility to enable flow control on all, none or some queues when using IFF_MULTI_QUEUE. When not using IFF_MULTI_QUEUE, IFF_FLOW_CONTROL will apply to the single queue. No changes were made to the default drop frame policy. This change adds support for back pressure use cases. Reported-by: Brian Adamson brian.adam...@nrl.navy.mil Tested-by: Joseph Giovatto jgiova...@djacentlink.com Signed-off-by: Steven Galgano sgalg...@adjacentlink.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 6/6] iio: Added ABI description for quaternion
Added documentation for reading quaternion components for 3D rotations. Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com --- Documentation/ABI/testing/sysfs-bus-iio | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..d2c59f9 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -784,6 +784,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en What: /sys/.../iio:deviceX/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -799,6 +800,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type What: /sys/.../iio:deviceX/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -845,6 +847,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index What: /sys/.../iio:deviceX/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -891,3 +894,12 @@ Contact: linux-...@vger.kernel.org Description: This attribute is used to get/set the integration time in seconds. + +What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw +KernelVersion: 3.15 +Contact: linux-...@vger.kernel.org +Description: + Raw value of quaternion components using a format + x y z w. Here x, y, and z component represents the axis about + which a rotation will occur and w component represents the + amount of rotation. -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 4/6] IIO: core: Add quaternion modifier
Added quaternion in the list of supported modifiers.
Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e22a984..dcc1849 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -84,6 +84,7 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_LIGHT_RED] = red,
[IIO_MOD_LIGHT_GREEN] = green,
[IIO_MOD_LIGHT_BLUE] = blue,
+ [IIO_MOD_QUATERNION] = quaternion,
};
/* relies on pairs of these shared then separate */
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index a13c224..4fdab2e 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_modifier {
IIO_MOD_LIGHT_RED,
IIO_MOD_LIGHT_GREEN,
IIO_MOD_LIGHT_BLUE,
+ IIO_MOD_QUATERNION,
};
enum iio_event_type {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 3/6] IIO: core: Modify scan element type
The current scan element type uses the following format:
[be|le]:[s|u]bits/storagebits[shift].
To specify multiple elements in this type, added a repeat value.
So new format is:
[be|le]:[s|u]bits/storagebits{X[repeat]}[shift].
Here X is specifying how may times, real/storage bits are repeating.
When X is value is 0 or 1, then repeat value is not used in the format,
and it will be same as existing format.
Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
drivers/iio/industrialio-buffer.c | 41 +--
include/linux/iio/iio.h | 9 +
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/industrialio-buffer.c
b/drivers/iio/industrialio-buffer.c
index e108f2a..aa90c68 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -150,7 +150,16 @@ static ssize_t iio_show_fixed_type(struct device *dev,
type = IIO_BE;
#endif
}
- return sprintf(buf, %s:%c%d/%d%u\n,
+ if (this_attr-c-scan_type.repeat 1)
+ return sprintf(buf, %s:%c%d/%d{%d[repeat]}%u\n,
+ iio_endian_prefix[type],
+ this_attr-c-scan_type.sign,
+ this_attr-c-scan_type.realbits,
+ this_attr-c-scan_type.storagebits,
+ this_attr-c-scan_type.repeat,
+ this_attr-c-scan_type.shift);
+ else
+ return sprintf(buf, %s:%c%d/%d%u\n,
iio_endian_prefix[type],
this_attr-c-scan_type.sign,
this_attr-c-scan_type.realbits,
@@ -474,14 +483,22 @@ static int iio_compute_scan_bytes(struct iio_dev
*indio_dev,
for_each_set_bit(i, mask,
indio_dev-masklength) {
ch = iio_find_channel_from_si(indio_dev, i);
- length = ch-scan_type.storagebits / 8;
+ if (ch-scan_type.repeat 1)
+ length = ch-scan_type.storagebits / 8 *
+ ch-scan_type.repeat;
+ else
+ length = ch-scan_type.storagebits / 8;
bytes = ALIGN(bytes, length);
bytes += length;
}
if (timestamp) {
ch = iio_find_channel_from_si(indio_dev,
indio_dev-scan_index_timestamp);
- length = ch-scan_type.storagebits / 8;
+ if (ch-scan_type.repeat 1)
+ length = ch-scan_type.storagebits / 8 *
+ ch-scan_type.repeat;
+ else
+ length = ch-scan_type.storagebits / 8;
bytes = ALIGN(bytes, length);
bytes += length;
}
@@ -957,7 +974,11 @@ static int iio_buffer_update_demux(struct iio_dev
*indio_dev,
indio_dev-masklength,
in_ind + 1);
ch = iio_find_channel_from_si(indio_dev, in_ind);
- length = ch-scan_type.storagebits/8;
+ if (ch-scan_type.repeat 1)
+ length = ch-scan_type.storagebits / 8 *
+ ch-scan_type.repeat;
+ else
+ length = ch-scan_type.storagebits / 8;
/* Make sure we are aligned */
in_loc += length;
if (in_loc % length)
@@ -969,7 +990,11 @@ static int iio_buffer_update_demux(struct iio_dev
*indio_dev,
goto error_clear_mux_table;
}
ch = iio_find_channel_from_si(indio_dev, in_ind);
- length = ch-scan_type.storagebits/8;
+ if (ch-scan_type.repeat 1)
+ length = ch-scan_type.storagebits / 8 *
+ ch-scan_type.repeat;
+ else
+ length = ch-scan_type.storagebits / 8;
if (out_loc % length)
out_loc += length - out_loc % length;
if (in_loc % length)
@@ -990,7 +1015,11 @@ static int iio_buffer_update_demux(struct iio_dev
*indio_dev,
}
ch = iio_find_channel_from_si(indio_dev,
indio_dev-scan_index_timestamp);
- length = ch-scan_type.storagebits/8;
+ if (ch-scan_type.repeat 1)
+ length = ch-scan_type.storagebits / 8 *
+ ch-scan_type.repeat;
+ else
+ length = ch-scan_type.storagebits / 8;
if (out_loc % length)
out_loc += length - out_loc % length;
if (in_loc % length)
diff --git a/include/linux/iio/iio.h
[Patch v4 2/6] IIO: core: Introduce read_raw_multi
This callback is introduced to overcome some limitations of existing
read_raw callback. The functionality of both existing read_raw and
read_raw_multi is similar, both are used to request values from the
device. The current read_raw callback allows only two return values.
The new read_raw_multi allows returning multiple values. Instead of
passing just address of val and val2, it passes length and pointer
to values. Depending on the type and length of passed buffer, iio
client drivers can return multiple values.
Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
drivers/iio/iio_core.h | 2 +-
drivers/iio/industrialio-core.c | 65 ++--
drivers/iio/industrialio-event.c | 6 ++--
drivers/iio/inkern.c | 16 --
include/linux/iio/iio.h | 17 +++
include/linux/iio/types.h| 1 +
6 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
index f6db6af..30327ad 100644
--- a/drivers/iio/iio_core.h
+++ b/drivers/iio/iio_core.h
@@ -35,7 +35,7 @@ int __iio_add_chan_devattr(const char *postfix,
struct list_head *attr_list);
void iio_free_chan_devattr_list(struct list_head *attr_list);
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2);
+ssize_t iio_format_value(char *buf, unsigned int type, int size, int *val);
/* Event interface flags */
#define IIO_BUSY_BIT_POS 1
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index ede16aec..e22a984 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -373,41 +373,53 @@ EXPORT_SYMBOL_GPL(iio_enum_write);
* @buf: The buffer to which the formated value gets written
* @type: One of the IIO_VAL_... constants. This decides how the val and val2
*parameters are formatted.
- * @val: First part of the value, exact meaning depends on the type parameter.
- * @val2: Second part of the value, exact meaning depends on the type
parameter.
+ * @vals: pointer to the values, exact meaning depends on the type parameter.
*/
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2)
+ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals)
{
unsigned long long tmp;
bool scale_db = false;
switch (type) {
case IIO_VAL_INT:
- return sprintf(buf, %d\n, val);
+ return sprintf(buf, %d\n, vals[0]);
case IIO_VAL_INT_PLUS_MICRO_DB:
scale_db = true;
case IIO_VAL_INT_PLUS_MICRO:
- if (val2 0)
- return sprintf(buf, -%ld.%06u%s\n, abs(val), -val2,
+ if (vals[1] 0)
+ return sprintf(buf, -%ld.%06u%s\n, abs(vals[0]),
+ -vals[1],
scale_db ? dB : );
else
- return sprintf(buf, %d.%06u%s\n, val, val2,
+ return sprintf(buf, %d.%06u%s\n, vals[0], vals[1],
scale_db ? dB : );
case IIO_VAL_INT_PLUS_NANO:
- if (val2 0)
- return sprintf(buf, -%ld.%09u\n, abs(val), -val2);
+ if (vals[1] 0)
+ return sprintf(buf, -%ld.%09u\n, abs(vals[0]),
+ -vals[1]);
else
- return sprintf(buf, %d.%09u\n, val, val2);
+ return sprintf(buf, %d.%09u\n, vals[0], vals[1]);
case IIO_VAL_FRACTIONAL:
- tmp = div_s64((s64)val * 10LL, val2);
- val2 = do_div(tmp, 10LL);
- val = tmp;
- return sprintf(buf, %d.%09u\n, val, val2);
+ tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
+ vals[1] = do_div(tmp, 10LL);
+ vals[0] = tmp;
+ return sprintf(buf, %d.%09u\n, vals[0], vals[1]);
case IIO_VAL_FRACTIONAL_LOG2:
- tmp = (s64)val * 10LL val2;
- val2 = do_div(tmp, 10LL);
- val = tmp;
- return sprintf(buf, %d.%09u\n, val, val2);
+ tmp = (s64)vals[0] * 10LL vals[1];
+ vals[1] = do_div(tmp, 10LL);
+ vals[0] = tmp;
+ return sprintf(buf, %d.%09u\n, vals[0], vals[1]);
+ case IIO_VAL_INT_MULTIPLE:
+ {
+ int i;
+ int len = 0;
+
+ for (i = 0; i size; ++i)
+ len += snprintf(buf[len], PAGE_SIZE - len, %d ,
+ vals[i]);
+ len += snprintf(buf[len], PAGE_SIZE - len, \n);
+ return len;
+ }
default:
return 0;
}
@@ -419,14 +431,23 @@ static
[Patch v4 1/6] devres: introduce API devm_kmemdup
Introduce devm_kmemdup, which uses resource managed kmalloc.
There are several request from maintainers to add this instead
of using kmemdup.
Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
Documentation/driver-model/devres.txt | 1 +
drivers/base/devres.c | 21 +
include/linux/device.h| 2 ++
3 files changed, 24 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 4f7897e..4999518 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core layer).
MEM
devm_kzalloc()
devm_kfree()
+ devm_kmemdup()
IIO
devm_iio_device_alloc()
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index db4e264..d0914cb 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -831,3 +831,24 @@ void devm_kfree(struct device *dev, void *p)
WARN_ON(rc);
}
EXPORT_SYMBOL_GPL(devm_kfree);
+
+/**
+ * devm_kmemdup - Resource-managed kmemdup
+ * @dev: Device this memory belongs to
+ * @src: Memory region to duplicate
+ * @len: Memory region length
+ * @gfp: GFP mask to use
+ *
+ * Duplicate region of a memory using resource managed kmalloc
+ */
+void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp)
+{
+ void *p;
+
+ p = devm_kmalloc(dev, len, gfp);
+ if (p)
+ memcpy(p, src, len);
+
+ return p;
+}
+EXPORT_SYMBOL_GPL(devm_kmemdup);
diff --git a/include/linux/device.h b/include/linux/device.h
index 233bbbe..0b3117a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -629,6 +629,8 @@ static inline void *devm_kcalloc(struct device *dev,
}
extern void devm_kfree(struct device *dev, void *p);
extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp);
+extern void *devm_kmemdup(struct device *dev, const void *src, size_t len,
+ gfp_t gfp);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
void __iomem *devm_request_and_ioremap(struct device *dev,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 5/6] iio: hid-sensors: Added device rotation support
Added usage id processing for device rotation. This uses IIO
interfaces for triggered buffer to present data to user
mode.This uses HID sensor framework for registering callback
events from the sensor hub.
Data is exported to user space in the form of quaternion rotation
format.
Signed-off-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
drivers/iio/orientation/Kconfig | 12 +
drivers/iio/orientation/Makefile | 1 +
drivers/iio/orientation/hid-sensor-rotation.c | 348 ++
include/linux/hid-sensor-ids.h| 1 +
4 files changed, 362 insertions(+)
create mode 100644 drivers/iio/orientation/hid-sensor-rotation.c
diff --git a/drivers/iio/orientation/Kconfig b/drivers/iio/orientation/Kconfig
index 58c62c8..e3aa1e5 100644
--- a/drivers/iio/orientation/Kconfig
+++ b/drivers/iio/orientation/Kconfig
@@ -16,4 +16,16 @@ config HID_SENSOR_INCLINOMETER_3D
Say yes here to build support for the HID SENSOR
Inclinometer 3D.
+config HID_SENSOR_DEVICE_ROTATION
+ depends on HID_SENSOR_HUB
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ select HID_SENSOR_IIO_COMMON
+ select HID_SENSOR_IIO_TRIGGER
+ tristate HID Device Rotation
+ help
+ Say yes here to build support for the HID SENSOR
+ device rotation. The output of a device rotation sensor
+ is presented using quaternion format.
+
endmenu
diff --git a/drivers/iio/orientation/Makefile b/drivers/iio/orientation/Makefile
index 2c97572..4734dab 100644
--- a/drivers/iio/orientation/Makefile
+++ b/drivers/iio/orientation/Makefile
@@ -4,3 +4,4 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_HID_SENSOR_INCLINOMETER_3D) += hid-sensor-incl-3d.o
+obj-$(CONFIG_HID_SENSOR_DEVICE_ROTATION) += hid-sensor-rotation.o
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c
b/drivers/iio/orientation/hid-sensor-rotation.c
new file mode 100644
index 000..51387bb
--- /dev/null
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -0,0 +1,348 @@
+/*
+ * HID Sensors Driver
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/slab.h
+#include linux/hid-sensor-hub.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/buffer.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+#include ../common/hid-sensors/hid-sensor-trigger.h
+
+struct dev_rot_state {
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_common common_attributes;
+ struct hid_sensor_hub_attribute_info quaternion;
+ u32 sampled_vals[4];
+};
+
+/* Channel definitions */
+static const struct iio_chan_spec dev_rot_channels[] = {
+ {
+ .type = IIO_ROT,
+ .modified = 1,
+ .channel2 = IIO_MOD_QUATERNION,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS)
+ }
+};
+
+/* Adjust channel real bits based on report descriptor */
+static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec *chan,
+ int size)
+{
+ chan-scan_type.sign = 's';
+ /* Real storage bits will change based on the report desc. */
+ chan-scan_type.realbits = size * 8;
+ /* Maximum size of a sample to capture is u32 */
+ chan-scan_type.storagebits = sizeof(u32) * 8;
+ chan-scan_type.repeat = 4;
+}
+
+/* Channel read_raw handler */
+static int dev_rot_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int size, int *vals, int *val_len,
+ long mask)
+{
+ struct dev_rot_state *rot_state = iio_priv(indio_dev);
+ int ret_type;
+ int i;
+
+ vals[0] = 0;
+ vals[1] = 0;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (size = 4) {
+ for (i = 0; i 4; ++i)
+ vals[i] = rot_state-sampled_vals[i];
+ ret_type = IIO_VAL_INT_MULTIPLE;
+ *val_len = 4;
+ } else
+ ret_type = -EINVAL;
+ break;
+
Re: [Patch v4 1/6] devres: introduce API devm_kmemdup
On Sun, 2014-04-13 at 21:27 -0700, Srinivas Pandruvada wrote: Introduce devm_kmemdup, which uses resource managed kmalloc. There are several request from maintainers to add this instead of using kmemdup. [] diff --git a/include/linux/device.h b/include/linux/device.h [] @@ -629,6 +629,8 @@ static inline void *devm_kcalloc(struct device *dev, } extern void devm_kfree(struct device *dev, void *p); extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp); +extern void *devm_kmemdup(struct device *dev, const void *src, size_t len, + gfp_t gfp); Please align the arguments to the open parenthesis. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] tuntap: add flow control to support back pressure
Please do not post new versions of a patch as a reply to an existing discussion. Instead, post a fresh new email for the patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel/panic: Add late_kdump option for kdump in unstable condition
Add a late_kdump option to run kdump after running panic
notifiers and dump kmsg. This can help rare situations which
kdump drops in failure because of unstable crashed kernel
or hardware failure (memory corruption on critical data/code),
or the 2nd kernel is broken by the 1st kernel (it's a broken
behavior, but who can guarantee that the crashed kernel
works correctly?).
Usage: add late_kdump to kernel boot option. That's all.
Note that this actually increases risks of the failure of
kdump. This option should be set only if you worry about
the rare case of kdump failure rather than increasing the
chance of success.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Eric Biederman ebied...@xmission.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Satoru MORIYA satoru.moriya...@hitachi.com
Cc: Motohiro Kosaki motohiro.kos...@us.fujitsu.com
Cc: Takenori Nagano t-nag...@ah.jp.nec.com
---
Documentation/kernel-parameters.txt |7 +++
kernel/panic.c | 24 ++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 03e50b4..1ba58da 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2339,6 +2339,13 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
timeout 0: reboot immediately
Format: timeout
+ late_kdump Run kdump after running panic-notifiers and dumping
+ kmsg. This only for the users who doubt kdump always
+ succeeds in any situation.
+ Note that this also increases risks of kdump failure,
+ because some panic notifiers can make the crashed
+ kernel more unstable.
+
parkbd.port=[HW] Parallel port number the keyboard adapter is
connected to, default is 0.
Format: parport#
diff --git a/kernel/panic.c b/kernel/panic.c
index d02fa9f..bba42b5 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -32,6 +32,7 @@ static unsigned long tainted_mask;
static int pause_on_oops;
static int pause_on_oops_flag;
static DEFINE_SPINLOCK(pause_on_oops_lock);
+static bool late_kdump;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
EXPORT_SYMBOL_GPL(panic_timeout);
@@ -112,9 +113,14 @@ void panic(const char *fmt, ...)
/*
* If we have crashed and we have a crash kernel loaded let it handle
* everything else.
-* Do we want to call this before we try to display a message?
+* If we want to call this after we try to display a message, pass
+* the late_kdump option to the kernel.
*/
- crash_kexec(NULL);
+ if (!late_kdump)
+ crash_kexec(NULL);
+ else
+ pr_emerg(Warning: late_kdump option is set. Please DO NOT
+ report bugs about kdump failure with this option.\n);
/*
* Note smp_send_stop is the usual smp shutdown function, which
@@ -131,6 +137,13 @@ void panic(const char *fmt, ...)
kmsg_dump(KMSG_DUMP_PANIC);
+ /*
+* If you doubt kdump always works perfectly in any situation,
+* late_kdump offers you to try kdump after running panic_notifier
+* and dumping kmsg.
+*/
+ crash_kexec(NULL);
+
bust_spinlocks(0);
if (!panic_blink)
@@ -472,6 +485,13 @@ EXPORT_SYMBOL(__stack_chk_fail);
core_param(panic, panic_timeout, int, 0644);
core_param(pause_on_oops, pause_on_oops, int, 0644);
+static int __init setup_late_kdump(char *s)
+{
+ late_kdump = true;
+ return 0;
+}
+early_param(late_kdump, setup_late_kdump);
+
static int __init oops_setup(char *s)
{
if (!s)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Dear Olof and Tomasz,
On 04/11/2014 05:39 PM, Tomasz Figa wrote:
On 11.04.2014 08:32, Chanwoo Choi wrote:
Hi,
On 04/11/2014 10:46 AM, Olof Johansson wrote:
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo Choi wrote:
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses
Cortex-A7
dual cores and has a target speed of 1.0GHz.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/Kconfig | 22 ++
arch/arm/mach-exynos/exynos.c| 1 +
arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
3 files changed, 33 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
menu SAMSUNG EXYNOS SoCs Support
+config ARCH_EXYNOS3
+bool SAMSUNG EXYNOS3
+select ARM_AMBA
+select CLKSRC_OF
+select HAVE_ARM_SCU if SMP
+select HAVE_SMP
+select PINCTRL
+select PM_GENERIC_DOMAINS if PM_RUNTIME
+help
+ Samsung EXYNOS3 SoCs based systems
+
config ARCH_EXYNOS4
bool SAMSUNG EXYNOS4
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
comment EXYNOS SoCs
+config SOC_EXYNOS3250
+bool SAMSUNG EXYNOS3250
+default y
+depends on ARCH_EXYNOS3
+select ARCH_HAS_BANDGAP
+select ARM_CPU_SUSPEND if PM
+select PINCTRL_EXYNOS
+select SAMSUNG_DMADEV
+help
+ Enable EXYNOS3250 CPU support
+
config CPU_EXYNOS4210
bool SAMSUNG EXYNOS4210
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..b134868 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -370,6 +370,7 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+samsung,exynos3250,
Please consider samsung,exynos3 instead, so you don't have to update this
table
for every SoC. We've talked about this before..
This patchset included only exynos3250.dtsi without exynos3.dtsi.
So, I added only samsung,exynos3250 compatible name.
There is no direct relation between dts file names and compatible string
(although usually they correspond). You don't need exynos3.dtsi (at least
until another SoC from this family shows up).
Do you prefer to add SoC version as following?
+ samsung,exynos3,
+ samsung,exynos3250,
or ?
+ samsung,exynos3,
This is actually a good question. If adding exynos3 anyway, it probably
wouldn't hurt to add exynos3250 anyway, to avoid adding it in future if some
SoC specific quirks show up, especially when both of compatible strings need
to be documented anyway.
samsung,exynos4,
samsung,exynos4210,
samsung,exynos4212,
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID0x4311
#define S5PV210_CPU_MASK0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID0x4321
#define EXYNOS4212_CPU_ID0x4322
#define EXYNOS4412_CPU_ID0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210()0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
In general, I think we have too much code littered with soc_is_foo() going
on, so please try to avoid adding more for this SoC. Especially in cases
where
you just want to bail out of certain features where we might already have
function pointers to control if a function is called or not, such as the
firmware interfaces.
Do you prefer dt helper function such as following function instead of new
soc_is_xx() ?
- of_machine_is_compatible(samsung,exynos3250)
If you are OK, I'll use of_machine_is_compatible() instead of soc_is_xx().
Re: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
(2014/04/11 2:02), Denys Vlasenko wrote: The (f64) modifier in x86-opcode-map.txt means that inat_is_force64() is true for call opcode. So we won't reach case 2: in __get_immv32(): insn_get_prefixes() did set insn-opnd_bytes to 2 when it saw 0x66 prefix, but it was before we reach this place, and here we overrode it. This is a bug in insn decoder. I tested it on both Intel and AMD CPUs and my worst fears came true: this instruction has different widths on different CPUs. This program: # compile with: gcc -nostartfiles -nostdlib -o int3 int3.S _start: .globl _start .byte 0x66,0xe9,0,0 .byte 0,0 1: jmp 1b compiles to this: 004000b0 _start: 4000b0: 66 e9 00 00 jmpw b4 _start-0x3c 4000b4: 00 00 add%al,(%rax) 4000b6: eb fe jmp4000b6 _start+0x6 and it will reach 0x4000b6 on Intel CPU. IOW, Intel SandyBridge CPU thinks that insn is in fact 66 e9 00 00 00 00, no RIP truncation occurs. On AMD K10 CPU, the very same binary jumps to 0x00b4 and gets SIGSEGV with MAPERR. AMD thinks that the insn is 66 e9 00 00 as shown above. Hmm, interesting. Thus, insn.c decoder implements Intel's idea of this insn while binutils (objdump, gdb) implement AMD decode. Yeah, insn.c relays on intel's opcode map. This same program can be compiled to 32-bit code, in this mode both CPUs treat insn as 66 e9 00 00. In 32 bit mode, insn.c treats it as 66 e9 00 00 correctly. Oleg, I'm sure you are very sympathetic by now to the idea of just not supporting this insn at all. ;) You can check whether insn had any prefix by checking insn-prefixes-nbytes != 0... No, since there are other prefixes (and it may be meaningless) you should find 0x66 in insn-prefixes-bytes[]. ..but there is a problem with that. P4 introduced branch hints, which are implemented using segment prefixes on conditional jumps. Meaning that some compilers produce 2e 0f 82 nn nn nn nn as (hint not taken) JB offset32 insn. 2e is CS segment prefix. insn-prefixes-nbytes == 1 for this insn. DS prefix (3e) hints that branch is taken. They were nearly useless on P4 anyway and ignored by all CPUs before or since, but they can be seen in some programs. Hm, this could be done. Looks like we'll need this: /* * 16-bit overrides such as CALLW (66 e8 nn nn) are not supported. * Intel and AMD behavior differ in 64-bit mode: Intel ignores 66 prefix. * No one uses these insns. * To filter them out, reject any branch insns with prefixes... */ if (insn-prefixes-nbytes 1) bail_out; As I said above, check insn-prefixes.bytes[0..nbytes]. /* * ...Except a single 3e or 2e branch taken/not taken hint prefix. * These are (rarely) used, but ignored by any CPU except P4. * Example: 2e 0f 82 nn nn nn nn is JB,PN offset32 */ if (insn-prefixes-nbytes == 1 (insn-prefixes-bytes[0] | 0x10) != 0x3e)) bail_out; Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/panic: Add late_kdump option for kdump in unstable condition
Masami Hiramatsu masami.hiramatsu...@hitachi.com writes:
Add a late_kdump option to run kdump after running panic
notifiers and dump kmsg. This can help rare situations which
kdump drops in failure because of unstable crashed kernel
or hardware failure (memory corruption on critical data/code),
or the 2nd kernel is broken by the 1st kernel (it's a broken
behavior, but who can guarantee that the crashed kernel
works correctly?).
Usage: add late_kdump to kernel boot option. That's all.
Note that this actually increases risks of the failure of
kdump. This option should be set only if you worry about
the rare case of kdump failure rather than increasing the
chance of success.
This is better than some others, but every time I have seen a request
to do this it is because someone wants to do something horrible that
makes kdump more brittle and generally unsupportable.
You seem to in general understand that.
But how can we support an option to make the kernel flakier?
I suspect it would be more productive to work on the lkcd (spelling?)
test module and show that crash dump actually works in the situation
people are worried about.
Just thinking about this send shivers up my spine. Ick.
Eric
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Eric Biederman ebied...@xmission.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Satoru MORIYA satoru.moriya...@hitachi.com
Cc: Motohiro Kosaki motohiro.kos...@us.fujitsu.com
Cc: Takenori Nagano t-nag...@ah.jp.nec.com
---
Documentation/kernel-parameters.txt |7 +++
kernel/panic.c | 24 ++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 03e50b4..1ba58da 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2339,6 +2339,13 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
timeout 0: reboot immediately
Format: timeout
+ late_kdump Run kdump after running panic-notifiers and dumping
+ kmsg. This only for the users who doubt kdump always
+ succeeds in any situation.
+ Note that this also increases risks of kdump failure,
+ because some panic notifiers can make the crashed
+ kernel more unstable.
+
parkbd.port=[HW] Parallel port number the keyboard adapter is
connected to, default is 0.
Format: parport#
diff --git a/kernel/panic.c b/kernel/panic.c
index d02fa9f..bba42b5 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -32,6 +32,7 @@ static unsigned long tainted_mask;
static int pause_on_oops;
static int pause_on_oops_flag;
static DEFINE_SPINLOCK(pause_on_oops_lock);
+static bool late_kdump;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
EXPORT_SYMBOL_GPL(panic_timeout);
@@ -112,9 +113,14 @@ void panic(const char *fmt, ...)
/*
* If we have crashed and we have a crash kernel loaded let it handle
* everything else.
- * Do we want to call this before we try to display a message?
+ * If we want to call this after we try to display a message, pass
+ * the late_kdump option to the kernel.
*/
- crash_kexec(NULL);
+ if (!late_kdump)
+ crash_kexec(NULL);
+ else
+ pr_emerg(Warning: late_kdump option is set. Please DO NOT
+ report bugs about kdump failure with this option.\n);
/*
* Note smp_send_stop is the usual smp shutdown function, which
@@ -131,6 +137,13 @@ void panic(const char *fmt, ...)
kmsg_dump(KMSG_DUMP_PANIC);
+ /*
+ * If you doubt kdump always works perfectly in any situation,
+ * late_kdump offers you to try kdump after running panic_notifier
+ * and dumping kmsg.
+ */
+ crash_kexec(NULL);
+
bust_spinlocks(0);
if (!panic_blink)
@@ -472,6 +485,13 @@ EXPORT_SYMBOL(__stack_chk_fail);
core_param(panic, panic_timeout, int, 0644);
core_param(pause_on_oops, pause_on_oops, int, 0644);
+static int __init setup_late_kdump(char *s)
+{
+ late_kdump = true;
+ return 0;
+}
+early_param(late_kdump, setup_late_kdump);
+
static int __init oops_setup(char *s)
{
if (!s)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thermal: samsung: Only update available threshold limits
Currently the threshold limits are updated in 2 stages, once for all
software trigger levels and again for hardware trip point.
While updating the software trigger levels, it overwrites the threshold
limit for hardware trip point thereby forcing the Exynos core to issue
an emergency shutdown.
Updating only the required fields in threshold register fixes this issue.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Based on v3.15-rc1.
drivers/thermal/samsung/exynos_tmu.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 0d96a51..ffccc89 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -225,6 +225,8 @@ skip_calib_data:
trigger_levs++;
}
+ rising_threshold = readl(data-base + reg-threshold_th0);
+
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
@@ -249,6 +251,7 @@ skip_calib_data:
ret = threshold_code;
goto out;
}
+ rising_threshold = ~(0xff 8 * i);
rising_threshold |= threshold_code 8 * i;
if (pdata-threshold_falling) {
threshold_code = temp_to_code(data,
@@ -281,6 +284,7 @@ skip_calib_data:
}
if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
/* 1-4 level to be assigned in th0 reg */
+ rising_threshold = ~(0xff 8 * i);
rising_threshold |= threshold_code 8 * i;
writel(rising_threshold,
data-base + reg-threshold_th0);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tuntap: add flow control to support back pressure
On Sun, Apr 13, 2014 at 09:28:51PM -0400, Steven Galgano wrote: On 04/13/2014 10:14 AM, Michael S. Tsirkin wrote: Steven, Brian, thanks for reporting this issue. Please see my comments below. On Fri, Apr 11, 2014 at 12:41:42PM -0400, Brian Adamson wrote: To weigh in on the desire to have support (at least as an optional behavior) for the legacy flow control behavior, there are many existing uses of it. Many these are related to experimental purposes where the tuntap driver can be used (with a little user space code) as a surrogate for a network interface type that may not even yet exist. And in some cases these experimental purposes have had utility for actual deployment (e.g. disaster relief wireless networks where the TAP device has provided some intermediate assistance for routing or other protocols, even an underwater acoustic sensor network proposed for reef monitoring, etc where a TAP device provides a network interface and the sound card is used as a modem on an embedded system). Some of these networks have low data rates or packet loss and delays that make TCP (which provides flow control as part of its usual reliable transport for more typical networking purpose) not an ideal protocol to use and so UDP or oth! er alterna tives or used. To keep this short, I'll list a few use cases here I know (and was involved with the implementation of some) with some links (where I know them): 1) CORE network emulation tool (http://code.google.com/p/coreemu/) 2) EMANE network emulation tool (https://github.com/adjacentlink/emane) (likely other network emulation tools exist that have used tuntap as surrogates for real physical interfaces and expect the same backpressure to sockets and queues that physical interfaces provide) 3) I don't have a link to it but I implemented an experimental IP interface/ MAC protocol called SLIDE (serial-link internet daemon) that implemented a user-space CSMA MAC protocol where an underwater acoustic modem was connected to the serial port and TAP was used to present a virtual network interface to the IP stack. Because of the low data rates involved, the back pressure flow control to application sockets (and protocol daemons and qdiscs applied) was important. 4) User space implementation of Simplified Multicast Forwarding (SMF) of RFC 6621 has a device option that establishes TAP interfaces to perform distributed backpressure based flow control (and potentially routing) for MANET wireless networks. (http://www.nrl.navy.mil/itd/ncs/products/smf) There are probably some more, among the more esoteric wireless and other special networking communities, where host (or routing/gateway/proxy non-host), e.g. special embedded system devices based on Linux such as sensors, etc) have a first hop network attachment that is _not_ the typical Ethernet or something and may be using tuntap along with a sort of user-space driver to present an IP interface to the network stack. some of this stuff, especially embedded systems, tend to lag behind with respect to kernel versions and this behavior change in Linux may be yet undiscovered so far even though the change was put in a couple years ago. Several of these are implemented across multiple platforms, and, for example, BSD-based systems tuntap provides the same flow control behavior. Even if it was never formally documented, I think this behavior was fairly well known (at least for these sorts of experimental purposes) and used. I understand the concern that a single bad behaving flow can possibly block the flow of others unless traffic control queuing disciplines (as done for other network interfaces). For the purposes of which I'm aware, I think having this behavior as _optional_ is probably OK … If accepted, and something is implemented here, it may be a good opportunity to have it documented (and the pros and cons of its use) for the more general Linux community. Yes, a UDP socket with sufficiently deep qdisc and tun queues would previously get slowed down so it matches the speed of the interface. But IIUC this was not really designed to be a flow control measure, so depending on what else is in the qdisc you could easily get into a setup where it behaves exactly as it does now. For example, have several UDP sockets send data out a single interface. Another problem is that this depends on userspace to be well-behaved and consume packets in a timely manner: a misbehaving userspace operating a tun device can cause other tun devices and/or sockets to get blocked forever and prevent them from communicating with all destinations (not just the misbehaving one) as their wmem limit is exhausted. It should be possible to reproduce with an old kernel and your userspace drivers, too - just stop the daemon temporarily. I
[PATCH] percpu: make pcpu_alloc_chunk() use pcpu_mem_free() instead of kfree()
pcpu_chunk_struct_size = sizeof(struct pcpu_chunk) +
BITS_TO_LONGS(pcpu_unit_pages) * sizeof(unsigned long)
It hardly could be ever bigger than PAGE_SIZE even for large-scale machine,
but for consistency with its couterpart pcpu_mem_zalloc(),
use pcpu_mem_free() instead.
Commit b4916cb17c261a6043bcb2a98d0d6512497a7cf8 addressed this
problem, but missed this one.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
mm/percpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 63e24fb..2ddf9a9 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -610,7 +610,7 @@ static struct pcpu_chunk *pcpu_alloc_chunk(void)
chunk-map = pcpu_mem_zalloc(PCPU_DFL_MAP_ALLOC *
sizeof(chunk-map[0]));
if (!chunk-map) {
- kfree(chunk);
+ pcpu_mem_free(chunk, pcpu_chunk_struct_size);
return NULL;
}
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
