Re: [PATCH -V1 19/22] vfs: Cache richacl in struct inode
Dave Chinner da...@fromorbit.com writes:
On Sun, Apr 27, 2014 at 09:44:50PM +0530, Aneesh Kumar K.V wrote:
From: Andreas Gruenbacher agr...@kernel.org
Cache richacls in struct inode so that this doesn't have to be done
individually in each filesystem.
Signed-off-by: Andreas Gruenbacher agr...@kernel.org
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
fs/inode.c | 25 ++-
include/linux/fs.h | 12 +--
include/linux/richacl.h | 53
+
3 files changed, 83 insertions(+), 7 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index f96d2a6f88cc..b96a16d5c653 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -18,6 +18,7 @@
#include linux/buffer_head.h /* for inode_has_buffers */
#include linux/ratelimit.h
#include linux/list_lru.h
+#include linux/richacl.h
#include internal.h
/*
@@ -185,7 +186,12 @@ int inode_init_always(struct super_block *sb, struct
inode *inode)
inode-i_mapping = mapping;
INIT_HLIST_HEAD(inode-i_dentry); /* buggered by rcu freeing */
#ifdef CONFIG_FS_POSIX_ACL
-inode-i_acl = inode-i_default_acl = ACL_NOT_CACHED;
+if (IS_POSIXACL(inode))
+inode-i_acl = inode-i_default_acl = ACL_NOT_CACHED;
+#endif
+#ifdef CONFIG_FS_RICHACL
+if (IS_RICHACL(inode))
+inode-i_richacl = ACL_NOT_CACHED;
#endif
That's just plain wrong. i think this is what Christoph didn't like.
An inode can have either a POSIX ACL or a RICH ACL, so there is no
need for multiple pointers in the inode for them.
We don't really have multiple pointers
union {
#ifdef CONFIG_FS_POSIX_ACL
struct {
struct posix_acl *i_acl;
struct posix_acl *i_default_acl;
};
#endif
#ifdef CONFIG_FS_RICHACL
struct richacl *i_richacl;
#endif
};
But I understand what you are suggesting here. Will try to rework and
see how much easy/simpler it makes the code.
#ifdef CONFIG_FSNOTIFY
@@ -240,10 +246,19 @@ void __destroy_inode(struct inode *inode)
}
#ifdef CONFIG_FS_POSIX_ACL
-if (inode-i_acl inode-i_acl != ACL_NOT_CACHED)
-posix_acl_release(inode-i_acl);
-if (inode-i_default_acl inode-i_default_acl != ACL_NOT_CACHED)
-posix_acl_release(inode-i_default_acl);
+if (IS_POSIXACL(inode)) {
+if (inode-i_acl inode-i_acl != ACL_NOT_CACHED)
+posix_acl_release(inode-i_acl);
+if (inode-i_default_acl
+inode-i_default_acl != ACL_NOT_CACHED)
+posix_acl_release(inode-i_default_acl);
+}
+#endif
+#ifdef CONFIG_FS_RICHACL
+if (IS_RICHACL(inode)) {
+if (inode-i_richacl inode-i_richacl != ACL_NOT_CACHED)
+richacl_put(inode-i_richacl);
+}
#endif
if (inode-i_acl inode-i_acl != ACL_NOT_CACHED)
acl_release(inode-i_acl);
And all the mess of working out what acl needs releasing get taken
out of of this code.
Understood. Will try to see how much I can simplify.
index 22d85798b520..95df64d21e55 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -492,6 +492,7 @@ static inline int mapping_writably_mapped(struct
address_space *mapping)
#endif
struct posix_acl;
+struct richacl;
#define ACL_NOT_CACHED ((void *)(-1))
#define IOP_FASTPERM0x0001
@@ -510,10 +511,17 @@ struct inode {
kgid_t i_gid;
unsigned inti_flags;
+union {
#ifdef CONFIG_FS_POSIX_ACL
-struct posix_acl*i_acl;
-struct posix_acl*i_default_acl;
+struct {
+struct posix_acl *i_acl;
+struct posix_acl *i_default_acl;
+};
#endif
+#ifdef CONFIG_FS_RICHACL
+struct richacl *i_richacl;
+#endif
+};
const struct inode_operations *i_op;
struct super_block *i_sb;
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index 88f95d78b897..a7db341e4ee9 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -191,6 +191,59 @@ richacl_put(struct richacl *acl)
kfree(acl);
}
+#ifdef CONFIG_FS_RICHACL
+static inline struct richacl *get_cached_richacl(struct inode *inode)
+{
+struct richacl **p, *acl;
+
+p = inode-i_richacl;
+acl = ACCESS_ONCE(*p);
+if (acl) {
+spin_lock(inode-i_lock);
+acl = *p;
+if (acl != ACL_NOT_CACHED)
+acl = richacl_get(acl);
+spin_unlock(inode-i_lock);
+}
+return acl;
+}
+
+static inline void set_cached_richacl(struct inode *inode,
+ struct richacl *acl)
+{
+struct richacl *old = NULL;
+spin_lock(inode-i_lock);
+old = inode-i_richacl;
+
Re: [perf] more perf_fuzzer memory corruption
On Thu, 1 May 2014, Peter Zijlstra wrote: But yes please! OK, sorry for the delay, had forgotten to re-enable -pg for perf in the makefile when I applied your patch so had to re-build the kernel. The trace is here: www.eece.maine.edu/~vweaver/junk/pzbug.out.bz2 No analysis so hopefully it's good, I've got an event to go to in a few minutes. The messages: [ 634.846367] [ cut here ] [ 634.851477] WARNING: CPU: 6 PID: 2915 at kernel/events/core.c:3232 __free_event+0x93/0xa0() [ 634.860583] Modules linked in: fuse snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp kvm crct10dif_pclmul snd_hda_codec_realtek snd_hda_codec_generic i915 drm_kms_helper crc32_pclmul snd_hda_intel snd_hda_controller ghash_clmulni_intel aesni_intel snd_hda_codec aes_x86_64 drm snd_hwdep evdev psmouse iTCO_wdt iTCO_vendor_support lrw gf128mul glue_helper snd_pcm pcspkr serio_raw i2c_i801 ablk_helper tpm_tis parport_pc parport cryptd snd_seq snd_timer snd_seq_device video battery button snd i2c_algo_bit i2c_core tpm mei_me mei lpc_ich mfd_core processor wmi soundcore sg sd_mod sr_mod crc_t10dif crct10dif_common cdrom ehci_pci ahci xhci_hcd e1000e libahci ehci_hcd libata usbcore ptp crc32c_intel pps_core scsi_mod usb_common thermal fan thermal_sys [ 634.935276] CPU: 6 PID: 2915 Comm: perf_fuzzer Not tainted 3.15.0-rc1+ #94 [ 634.942754] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 [ 634.950728] 0009 8801174b7b78 81649bf0 [ 634.958795] 8801174b7bb0 810646ad 8800cef05000 [ 634.966855] 8800cd47be10 880036c7b388 8800cef052a0 8801174b7bc0 [ 634.974858] Call Trace: [ 634.977482] [81649bf0] dump_stack+0x45/0x56 [ 634.983007] [810646ad] warn_slowpath_common+0x7d/0xa0 [ 634.989447] [8106478a] warn_slowpath_null+0x1a/0x20 [ 634.995674] [811330e3] __free_event+0x93/0xa0 [ 635.001429] [81133cce] _free_event+0xce/0x210 [ 635.007180] [81133f90] put_event+0x180/0x1f0 [ 635.012796] [81133e80] ? put_event+0x70/0x1f0 [ 635.018487] [81134037] perf_release+0x17/0x20 [ 635.024228] [811b694c] __fput+0xdc/0x1e0 [ 635.029457] [811b6a9e] fput+0xe/0x10 [ 635.034719] [81085137] task_work_run+0xa7/0xe0 [ 635.040524] [81066d5c] do_exit+0x2cc/0xa50 [ 635.045978] [81076949] ? get_signal_to_deliver+0x249/0x650 [ 635.052880] [8106756c] do_group_exit+0x4c/0xc0 [ 635.058669] [81076991] get_signal_to_deliver+0x291/0x650 [ 635.065384] [81012438] do_signal+0x48/0x990 [ 635.070911] [8101f516] ? ftrace_raw_event_sys_exit+0x56/0x80 [ 635.077994] [81012df0] do_notify_resume+0x70/0xa0 [ 635.084059] [81651f3c] retint_signal+0x48/0x8c [ 635.089912] ---[ end trace bf0bdbfdb698177c ]--- [ 635.995839] Slab corruption (Tainted: GW): kmalloc-2048 start=8800cef05000, len=2048 [ 636.006669] 040: 6b 6b 6b 6b 6b 6b 6b 6b a8 75 90 17 01 88 ff ff .u.. [ 636.017593] Next obj: start=8800cef05800, len=2048 [ 636.024510] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 636.035462] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b -- 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 -V1 22/22] ext4: Add Ext4 compat richacl feature flag
Andreas Dilger adil...@dilger.ca writes:
On Apr 27, 2014, at 10:14 AM, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
This feature flag can be used to enable richacl on
the file system. Once enabled the acl mount option
will enable richacl instead of posix acl
I was going to complain about this patch, because re-using the acl
mount option to specify richacl instead of POSIX ACL would be very
confusing, since older kernels used the acl mount option to enable
POSIX ACLs.
Looking closer, I see that acl and noacl just means enable or disable
the ACL functionality on the filesystem. Please fix up the commit
comment.
Will clarify in the commit message.
Some more comments inline.
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6f9e6fadac04..2a0221652d79 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1274,6 +1274,30 @@ static ext4_fsblk_t get_sb_block(void **data)
return sb_block;
}
+static void enable_acl(struct super_block *sb)
+{
+#if !defined(CONFIG_EXT4_FS_POSIX_ACL) !defined(CONFIG_EXT4_FS_RICHACL)
+return;
+#endif
+if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
+sb-s_flags |= MS_RICHACL;
+sb-s_flags = ~MS_POSIXACL;
+} else {
+sb-s_flags |= MS_POSIXACL;
+sb-s_flags = ~MS_RICHACL;
+}
This should put the #ifdef around the code that is being enabled/disabled,
otherwise it just becomes dead code:
static int enable_acl(struct super_block *sb)
{
if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
#if defined(CONFIG_EXT4_FS_RICHACL)
sb-s_flags |= MS_RICHACL;
sb-s_flags = ~MS_POSIXACL;
#else
return -EOPNOTSUPP;
#endif
} else {
#if defined(CONFIG_EXT4_FS_POSIX_ACL)
sb-s_flags |= MS_POSIXACL;
sb-s_flags = ~MS_RICHACL;
#else
return -EOPNOTSUPP;
#endif
}
return 0;
}
That is too much #ifdef with no real benefit ?
+
+static void disable_acl(struct super_block *sb)
+{
+#if !defined(CONFIG_EXT4_FS_POSIX_ACL) !defined(CONFIG_EXT4_FS_RICHACL)
+return;
+#endif
+sb-s_flags = ~(MS_POSIXACL | MS_RICHACL);
+return;
+}
return is not needed at the end of void functions. Same comment on
#ifdef:
ok
static void disable_acl(struct super_block *sb)
{
#if defined(CONFIG_EXT4_FS_POSIX_ACL) || defined(CONFIG_EXT4_FS_RICHACL)
sb-s_flags = ~(MS_POSIXACL | MS_RICHACL);
#endif
}
+
#define DEFAULT_JOURNAL_IOPRIO (IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 3))
static char deprecated_msg[] = Mount option \%s\ will be removed by %s\n
Contact linux-e...@vger.kernel.org if you think we should keep it.\n;
@@ -1417,9 +1441,9 @@ static const struct mount_opts {
MOPT_NO_EXT2 | MOPT_DATAJ},
{Opt_user_xattr, EXT4_MOUNT_XATTR_USER, MOPT_SET},
{Opt_nouser_xattr, EXT4_MOUNT_XATTR_USER, MOPT_CLEAR},
if ((def_mount_opts EXT4_DEFM_JMODE) == EXT4_DEFM_JMODE_DATA)
set_opt(sb, JOURNAL_DATA);
@@ -3569,8 +3593,12 @@ static int ext4_fill_super(struct super_block *sb,
void *data, int silent)
clear_opt(sb, DELALLOC);
}
-sb-s_flags = (sb-s_flags ~MS_POSIXACL) |
-(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
+/*
+ * clear ACL flags
+ */
+disable_acl(sb);
Is there any expectation that the flags would be set on a newly mounted
filesystem?
+if (test_opt(sb, ACL))
+enable_acl(sb);
if (le32_to_cpu(es-s_rev_level) == EXT4_GOOD_OLD_REV
(EXT4_HAS_COMPAT_FEATURE(sb, ~0U) ||
@@ -4844,8 +4872,9 @@ static int ext4_remount(struct super_block *sb, int
*flags, char *data)
if (sbi-s_mount_flags EXT4_MF_FS_ABORTED)
ext4_abort(sb, Abort forced by user);
-sb-s_flags = (sb-s_flags ~MS_POSIXACL) |
-(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
+disable_acl(sb);
+if (test_opt(sb, ACL))
+enable_acl(sb);
Similarly, it seems racy to me to disable ACL support and then re-enable
it here during remount, since that might cause some concurrent operations
to fail. It seems like enable_acl() already handles clearing the flags
correctly, so something like the following would be better:
if (test_opt(sb, ACL))
enable_acl(sb);
else
disable_acl(sb);
ok
-aneesh
--
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 -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner da...@fromorbit.com writes: On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote: Dave Chinner da...@fromorbit.com writes: On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: Hi As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way https://github.com/kvaneesh/richacl-tools/tree/master/test FYI, I doubt very much that anyone will run a stand-alone richacls test suite regularly. Can you please work to integrate this into xfstests so it becomes a regular part of a filesystem developer's daily workflow? Will update xfstest based on the progress made with this patchset. -aenesh -- 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/
[RFC PATCH 0/2] kpatch: dynamic kernel patching
Hi, Since Jiri posted the kGraft patches [1], I wanted to share an alternative live patching solution called kpatch, which is something we've been working on at Red Hat for quite a while. The kernel piece of it (kpatch core module) is completely self-contained in a GPL module. It compiles and works without needing to change any kernel code, and in fact we already have it working fine with Fedora 20 [2] without any distro kernel patches needed. We'd definitely like to see it (or some combination of it and kGraft) merged into Linux. This patch set is for the core module, which provides the kernel infrastructure for kpatch. It has a kpatch_register() interface which allows kernel modules (patch modules) to replace old functions with new functions which are loaded with the modules. There are also some user space tools [2] which aren't included in this patch set, which magically generate binary patch modules from source diffs, and manage the loading and unloading of these modules. I didn't include them here because I think we should agree on what the kernel parts should look like before trying to discuss the user space tools (and whether they should be in-tree). kpatch vs kGraft I think the biggest difference between kpatch and kGraft is how they ensure that the patch is applied atomically and safely. kpatch checks the backtraces of all tasks in stop_machine() to ensure that no instances of the old function are running when the new function is applied. I think the biggest downside of this approach is that stop_machine() has to idle all other CPUs during the patching process, so it inserts a small amount of latency (a few ms on an idle system). Instead, kGraft uses per-task consistency: each task either sees the old version or the new version of the function. This gives a consistent view with respect to functions, but _not_ data, because the old and new functions are allowed to run simultaneously and share data. This could be dangerous if a patch changes how a function uses a data structure. The new function could make a data change that the old function wasn't expecting. With kpatch, that's not an issue because all the functions are patched at the same time. So kpatch is safer with respect to data interactions. Other advantages of the kpatch stop_machine() approach: - IMO, the kpatch code is much simpler than kGraft. The implementation is very straightforward and is completely self-contained. It requires zero changes to the kernel. (However a new TAINT_KPATCH flag would be a good idea, and we do anticipate some minor changes to kprobes and ftrace for better compatibility.) - The use of stop_machine() will enable an important not-yet-implemented feature to call a user-supplied callback function at loading time which can be used to atomically update data structures when applying a patch. I don't see how such a feature would be possible with the kGraft approach. - kpatch applies patches immediately without having to send signals to sleeping processes, and without having to hope that those processes handle the signal appropriately. - kpatch's patching behavior is more deterministic because stop_machine() ensures that all tasks are sleeping and interrupts are disabled when the patching occurs. - kpatch already supports other cool features like: - removing patches and rolling back to the original functions - atomically replacing existing patches - incremental patching - loading multiple patch modules TODO Here are the only outstanding issues: - A new FTRACE_OPS_FL_PERMANENT flag is needed to tell ftrace to never disable the handler. Otherwise a patch could be temporarily or permanently removed in certain situations. - A few kprobes compatibility issues: - Patching of a kprobed function doesn't take effect until the kprobe is removed. - kretprobes removes the probed function's calling function's IP from the stack, which could lead to a false negative in the kpatch backtrace safety check. [1] http://thread.gmane.org/gmane.linux.kernel/1694304 [2] https://github.com/dynup/kpatch Josh Poimboeuf (2): kpatch: add TAINT_KPATCH flag kpatch: add kpatch core module Documentation/kpatch.txt| 193 + Documentation/oops-tracing.txt | 3 + Documentation/sysctl/kernel.txt | 1 + MAINTAINERS | 9 + arch/Kconfig| 14 + include/linux/kernel.h | 1 + include/linux/kpatch.h | 61 kernel/Makefile | 1 + kernel/kpatch/Makefile | 1 + kernel/kpatch/kpatch.c | 615 kernel/panic.c | 2 + 11 files changed, 901 insertions(+) create mode 100644 Documentation/kpatch.txt create mode 100644 include/linux/kpatch.h create mode 100644 kernel/kpatch/Makefile create mode 100644 kernel/kpatch/kpatch.c -- 1.9.0 -- To
[RFC PATCH 2/2] kpatch: add kpatch core module
Add the kpatch core module. It's a self-contained module with a kernel patching infrastructure that enables patching a running kernel without rebooting or restarting any processes. Kernel modules (patch modules) can call kpatch_register() to replace new functions with old ones. Before applying a patch, kpatch checks the stacks of all tasks in stop_machine() to ensure that the patch is applied atomically, to prevent any weird effects from function interface changes or data semantic changes that might occur between old and new versions of the functions running simultaneously. If any of the to-be-patched functions are on the stack, it fails with -EBUSY. ftrace is used to do the code modification. For each function to be patched, kpatch registers an ftrace ops handler. When called, the handler modifies regs-ip on the stack and returns back to ftrace, which restores the RIP and returns to the beginning of the new function. Other features: * Safe unpatching * Atomic repatching (replacing one patch module with another) * Support for multiple patch modules * kpatch_[register|unregister] are properly synchronized with kpatch_ftrace_handler() when it runs in NMI context (thanks to Masami for helping with this) Signed-off-by: Josh Poimboeuf jpoim...@redhat.com Cc: Seth Jennings sjenn...@redhat.com Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com --- Documentation/kpatch.txt | 193 +++ MAINTAINERS | 9 + arch/Kconfig | 14 ++ include/linux/kpatch.h | 61 + kernel/Makefile | 1 + kernel/kpatch/Makefile | 1 + kernel/kpatch/kpatch.c | 615 +++ 7 files changed, 894 insertions(+) create mode 100644 Documentation/kpatch.txt create mode 100644 include/linux/kpatch.h create mode 100644 kernel/kpatch/Makefile create mode 100644 kernel/kpatch/kpatch.c diff --git a/Documentation/kpatch.txt b/Documentation/kpatch.txt new file mode 100644 index 000..697c054 --- /dev/null +++ b/Documentation/kpatch.txt @@ -0,0 +1,193 @@ +kpatch: dynamic kernel patching +=== + +kpatch is a Linux dynamic kernel patching infrastructure which allows you to +patch a running kernel without rebooting or restarting any processes. It +enables sysadmins to apply critical security patches to the kernel immediately, +without having to wait for long-running tasks to complete, users to log off, or +for scheduled reboot windows. It gives more control over uptime without +sacrificing security or stability. + +How it works + + +kpatch works at a function granularity: old functions are replaced with new +ones. It has four main components: + +- **kpatch-build**: a collection of tools which convert a source diff patch to + a patch module. They work by compiling the kernel both with and without + the source patch, comparing the binaries, and generating a patch module + which includes new binary versions of the functions to be replaced. + +- **patch module**: a kernel module (.ko file) which includes the + replacement functions and metadata about the original functions. + +- **kpatch core module**: the kernel infrastructure which provides an interface + for the patch modules to register new functions for replacement. It uses the + kernel ftrace subsystem to hook into the original function's mcount call + instruction, so that a call to the original function is redirected to the + replacement function. + +- **kpatch utility:** a command-line tool which allows a user to manage a + collection of patch modules. One or more patch modules may be + configured to load at boot time, so that a system can remain patched + even after a reboot into the same version of the kernel. + + +How to use it +- + +Currently, only the core module is in the kernel tree. The supporting +kpatch-build and kpatch utility tools can be found at: + + https://github.com/dynup/kpatch + +You can also find directions there for how to create binary patch modules and +load them into your kernel. + + +Limitations +--- + +- Patches which modify kernel modules are not supported (yet). Only + functions in the vmlinux file (listed in System.map) can be patched. + +- Patches to functions which are always on the stack of at least one + process in the system are not supported. Examples: schedule(), + sys_poll(), sys_select(), sys_read(), sys_nanosleep(). Attempting to + apply such a patch will cause the insmod of the patch module to return + an error. + +- Patches which modify init functions (annotated with `__init`) are not + supported. kpatch-build will return an error if the patch attempts + to do so. + +- Patches which modify statically allocated data are not supported. + kpatch-build will detect that and return an error. (In the future + we will add a facility to support it. It will probably require the + user to write code which runs at patch module loading time which manually +
[RFC PATCH 1/2] kpatch: add TAINT_KPATCH flag
Add a TAINT_KPATCH flag to be set whenever a kpatch patch module
successfully replaces a function.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Seth Jennings sjenn...@redhat.com
---
Documentation/oops-tracing.txt | 3 +++
Documentation/sysctl/kernel.txt | 1 +
include/linux/kernel.h | 1 +
kernel/panic.c | 2 ++
4 files changed, 7 insertions(+)
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index e315599..2ed7ed1 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -268,6 +268,9 @@ characters, each representing a particular tainted value.
14: 'E' if an unsigned module has been loaded in a kernel supporting
module signature.
+ 15: 'H' if a kpatch hot patch module has replaced any functions in the
+ running kernel.
+
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 9886c3d..7d31b1e 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -788,6 +788,7 @@ can be ORed together:
4096 - An out-of-tree module has been loaded.
8192 - An unsigned module has been loaded in a kernel supporting module
signature.
+16384 - A kpatch module has replaced a function in the running kernel.
==
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c52907..cdfbe73 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -470,6 +470,7 @@ extern enum system_states {
#define TAINT_FIRMWARE_WORKAROUND 11
#define TAINT_OOT_MODULE 12
#define TAINT_UNSIGNED_MODULE 13
+#define TAINT_KPATCH 14
extern const char hex_asc[];
#define hex_asc_lo(x) hex_asc[((x) 0x0f)]
diff --git a/kernel/panic.c b/kernel/panic.c
index d02fa9f..2c04a88 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -212,6 +212,7 @@ static const struct tnt tnts[] = {
{ TAINT_FIRMWARE_WORKAROUND,'I', ' ' },
{ TAINT_OOT_MODULE, 'O', ' ' },
{ TAINT_UNSIGNED_MODULE,'E', ' ' },
+ { TAINT_KPATCH, 'H', ' ' },
};
/**
@@ -231,6 +232,7 @@ static const struct tnt tnts[] = {
* 'I' - Working around severe firmware bug.
* 'O' - Out-of-tree module has been loaded.
* 'E' - Unsigned module has been loaded.
+ * 'H' - kpatch replaced a function.
*
* The string is overwritten by the next call to print_tainted().
*/
--
1.9.0
--
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 6/6] cgroup, memcg: implement css-id and convert css_from_id() to use it
On Mon, Apr 28, 2014 at 11:33:16AM +0800, Li Zefan wrote: On 2014/4/25 5:02, Tejun Heo wrote: Until now, cgroup-id has been used to identify all the associated csses and css_from_id() takes cgroup ID and returns the matching css by looking up the cgroup and then dereferencing the css associated with it; however, now that the lifetimes of cgroup and css are separate, this is incorrect and breaks on the unified hierarchy when a controller is disabled and enabled back again before the previous instance is released. This patch adds css-id which is a subsystem-unique ID and converts css_from_id() to look up by the new css-id instead. memcg is the only user of css_from_id() and also converted to use css-id instead. netprio_cgroup also needs to be updated. Why? Wouldn't it be more natural to tie that to the associated cgroup's ID rather than the specific css instance. It's different for memcg as it involves css refcnts but netprio_cgroup, AFAICS, only uses it for cgroup identification anyway. Thanks. -- tejun -- 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/
Fwd: Re: [PATCH 1/1] fanotify: for FAN_MARK_FLUSH check flags
Hello Andrew, the patch below was Acked-by: Michael Kerrisk mtk.manpa...@gmail.com https://lkml.org/lkml/2014/4/24/23 Acked-by: Jan Kara j...@suse.cz https://lkml.org/lkml/2014/4/24/1048 Please, consider it for inclusion in the mm tree. Best regards Heinrich Schuchardt On 24.04.2014 12:03, Jan Kara wrote: On Wed 23-04-14 23:55:51, Heinrich Schuchardt wrote: If fanotify_mark is called with illegal value of arguments flags and marks it usually returns EINVAL. When fanotify_mark is called with FAN_MARK_FLUSH the argument flags is not checked for irrelevant flags like FAN_MARK_IGNORED_MASK. The patch removes this inconsistency. If an irrelevant flag is set error EINVAL is returned. OK, as Michael I think this shouldn't cause real userspace breakage and it's better to have the flags checked. So feel free to add: Acked-by: Jan Kara j...@suse.cz Honza Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de --- fs/notify/fanotify/fanotify_user.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index 287a22c..8bba549 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -819,7 +819,10 @@ SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, unsigned int, flags, case FAN_MARK_REMOVE: if (!mask) return -EINVAL; + break; case FAN_MARK_FLUSH: + if (flags ~(FAN_MARK_MOUNT | FAN_MARK_FLUSH)) + return -EINVAL; break; default: return -EINVAL; -- 1.9.2 -- 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 v4 1/1] Driver for Beckhoff CX5020 EtherCAT master module.
Darek Marcinkiewicz rek...@newterm.pl :
[changes]
(you may add those after the --- above the diffstat)
[...]
diff --git a/drivers/net/ethernet/ec_bh.c b/drivers/net/ethernet/ec_bh.c
new file mode 100644
index 000..2ed2cee
--- /dev/null
+++ b/drivers/net/ethernet/ec_bh.c
[...]
+#define TX_HEADER_SIZE 16
sizeof() ?
+#define MAX_TX_BODY_SIZE 1518
s/1518/ETH_FRAME_LEN + ETH_FCS_LEN/ ?
+#define MAX_TX_PKT_SIZE (MAX_TX_BODY_SIZE + TX_HEADER_SIZE)
+
+#define FIFO_SIZE64
+
+static long polling_frequency = TIMER_INTERVAL_NSEC;
+
+struct bh_priv {
Nit: it would be nice to avoid _bh_ as it is already used in a set of
common kernel functions.
[...]
+ u8 *tx_put;
+ u8 *tx_get;
It's part u8 and part tx_header.
You may consider using a struct that adds an extra 'u8 data[0]' at
the end of the struct tx_header.
skb_copy_and_csum_dev in the xmit path rings a bell but the DMA FIFO
zone handling could imho save some pointer arithmetic and turn a bit
more literate.
[...]
+static void ec_bh_print_status(struct bh_priv *priv)
+{
+ dev_info(PRIV_TO_DEV(priv),
+ Frame error counter:%d\n,
- Excess new line. The message always fits within the (less than) 80 columns
limit. There are several occurences of it in the driver.
- You may add a local variable to save the numerous PRIV_TO_DEV(priv).
- A space between the : and the % should help reading.
[...]
+static void ec_bh_send_packet(struct bh_priv *priv)
+{
+ struct tx_header *header = (struct tx_header *)priv-tx_get;
+ u32 addr = priv-tx_get - priv-tx;
+ u32 len = le16_to_cpu(header-len) + sizeof(*header);
Please reorder so as to get an inverted xmas tree. You should do it
wherever it can be done in the driver.
+
+ iowrite32len + 8) / 8) 24) | addr,
+ priv-fifo_io + FIFO_TX_REG);
iowrite32(addr | (((len + 8) / 8) 24), priv-fifo_io + FIFO_TX_REG);
[...]
+static void ec_bh_process_tx(struct bh_priv *priv)
+{
+ int sent;
+ struct tx_header *header;
+ u8 *pkt_end, *next_pkt;
+
+ if (!priv-tx_in_flight)
+ return;
+
+ header = (struct tx_header *)priv-tx_get;
You may merge it with the variable declaration.
+ sent = le32_to_cpu(header-sent) TX_HDR_SENT;
+ if (!sent)
+ return;
+
+ pkt_end = priv-tx_get;
+ pkt_end += (sizeof(*header) + le16_to_cpu(header-len) + 7) / 8 * 8;
ALIGN() ?
[...]
+ if (netif_queue_stopped(priv-net_dev)
+ (priv-tx_put priv-tx_get
+ || priv-tx_put + MAX_TX_PKT_SIZE priv-tx_get)) {
|| should be a the end of the preceding line
[...]
+static void ec_bh_process_rx(struct bh_priv *priv)
+{
+ struct rx_desc *desc = priv-rx_desc;
+
+ while (ec_bh_pkt_received(desc)) {
+ int pkt_size = (le16_to_cpu(desc-header.len) RXHDR_LEN_MASK)
+- sizeof(struct rx_header)
+- 4;
The operator should be at the end of the preceding line.
+ u8 *data = desc-data;
+ struct sk_buff *skb;
+
+ skb = netdev_alloc_skb_ip_align(priv-net_dev, pkt_size);
+ dev_dbg(PRIV_TO_DEV(priv),
You may use local variable instead of repeating (capitalized) macro.
[...]
+static enum hrtimer_restart ec_bh_timer_fun(struct hrtimer *timer)
+{
+ struct bh_priv *priv = container_of(timer,
+ struct bh_priv,
+ hrtimer);
+ unsigned long flags;
+
+ spin_lock_irqsave(priv-lock, flags);
+
+ ec_bh_process_rx(priv);
The Rx part should not race with anything. You should thus push the
locked section into ec_bh_process_tx (then narrow it).
+ ec_bh_process_tx(priv);
+
+ spin_unlock_irqrestore(priv-lock, flags);
+
+ if (atomic_read(priv-shutting_down))
+ return HRTIMER_NORESTART;
You can use 'netif_running' and remove 'shutting_down'.
[...]
+static netdev_tx_t ec_bh_start_xmit(struct sk_buff *skb,
+ struct net_device *net_dev)
+{
+ unsigned long flags;
+ unsigned len;
+ struct bh_priv *priv = netdev_priv(net_dev);
+ struct tx_header *header = (struct tx_header *)priv-tx_put;
+ u8 *tx = priv-tx_put + sizeof(struct tx_header);
+
+ spin_lock_irqsave(priv-lock, flags);
+
+ dev_dbg(PRIV_TO_DEV(priv), Starting xmit\n);
+
+ /* Drop packets that are too large or have no chance
+ * to be a ethercat packets (cause they are too small)
+ */
+ if (unlikely(skb-len priv-tx_len
+ || skb-len 13)) {
+ net_dev-stats.tx_dropped++;
+ dev_info(PRIV_TO_DEV(priv), Dropping packet\n);
+ goto out_unlock;
+ }
+
+ skb_copy_and_csum_dev(skb, tx);
+ len = skb-len;
Up to this point the lock is not required (ec_bh_process_tx does not
Re: [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board
Hi, On Thu, May 1, 2014 at 7:15 AM, Mark Brown broo...@kernel.org wrote: On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote: Okay, I will extend the existing clock driver to support XCLKOUT. It may make more sense to add another clock driver for this clock depending on how things are done, I don't know. Of the many parents of XCLKOUT, we need to set XXTI clock as the parent. Is it okay if we pass two clocks mclk (XCLKOUT) and mclk_parent (XXTI) to sound-card driver via DT and do the necessary reparenting during the sound-card driver probe call? No, that's not OK at all, it won't allow for configuration of the system. This is what I was talking about when I was talking the clock framework extensions to allow the clock tree to be configured using DT, that would allow the settings to be put in DT. Else, we can push that change to bootloader (to set the XCLKOUT mux register) and only enable/disable the clock in sound-card driver. That's not going to work given that the existing bootloaders don't do this. This is exactly the thing (expected clock parenting) we agreed could be put in the device tree I think. ...but I don't know that anyone proposed exactly how that would work. NOTE: in existing ChromeOS this type of thing is done a tiny amount in https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8/arch/arm/mach-exynos/mach-exynos5-dt.c. See apply_clock_muxing(). -Doug -- 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] DMA-API: Clarify physical/bus address distinction
On Thu, May 1, 2014 at 7:47 AM, Randy Dunlap rdun...@infradead.org wrote: On 04/30/2014 12:42 PM, Bjorn Helgaas wrote: The DMA-API documentation sometimes refers to physical addresses when it really means bus addresses. Historically these were often the same, but they may be different if the bridge leading to the bus performs address transaction. Update the documentation to use bus address when translation. Fixed, 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] spi: Fix hung task timeout when initialization fails
On Thu, May 01, 2014 at 04:33:58PM +0200, Geert Uytterhoeven wrote: On Thu, May 1, 2014 at 4:11 PM, Mark Brown broo...@kernel.org wrote: master-kworker_task is set like this: master-kworker_task = kthread_run(...) so it just contains the status of the creation of the kthread, not if it was killed, right? Hence we don't check if it was killed. So Ricardo's patch prevents the stopping and destruction of the thread if it failed to be _created_. OK, so that means that the description is very confusing then since it's talking about the issue being due to kthread_run being killed. What if it is killed? I suppose the kthread API handles that internally, as it could happen to any thread (e.g. OOM)? I'm not 100% clear on this to be honest. Since I'm at ELC I've not investigated fully yet and I'm mostly going on the patch descriptions here. signature.asc Description: Digital signature
Re: [PATCH] cpufreq: intel_pstate: Remove sample parameter in intel_pstate_calc_busy
On 04/29/2014 10:53 AM, Stratos Karafotis wrote:
Since commit d37e2b7644 (intel_pstate: remove unneeded sample buffers)
we use only one sample. So, there is no need to pass the sample
pointer to intel_pstate_calc_busy. Instead, get the pointer from
cpudata. Also, remove the unused SAMPLE_COUNT macro.
While at it, reformat the first line in this function.
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
Acked-by: Dirk Brandewie dirk.j.brande...@intel.com
---
drivers/cpufreq/intel_pstate.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 95b3958..8192ff1 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -32,8 +32,6 @@
#include asm/msr.h
#include asm/cpu_device_id.h
-#define SAMPLE_COUNT 3
-
#define BYT_RATIOS0x66a
#define BYT_VIDS 0x66b
#define BYT_TURBO_RATIOS 0x66c
@@ -553,14 +551,13 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
intel_pstate_set_pstate(cpu, cpu-pstate.max_pstate);
}
-static inline void intel_pstate_calc_busy(struct cpudata *cpu,
- struct sample *sample)
+static inline void intel_pstate_calc_busy(struct cpudata *cpu)
{
+ struct sample *sample = cpu-sample;
int32_t core_pct;
int32_t c0_pct;
- core_pct = div_fp(int_tofp((sample-aperf)),
- int_tofp((sample-mperf)));
+ core_pct = div_fp(int_tofp(sample-aperf), int_tofp(sample-mperf));
core_pct = mul_fp(core_pct, int_tofp(100));
FP_ROUNDUP(core_pct);
@@ -595,7 +592,7 @@ static inline void intel_pstate_sample(struct cpudata *cpu)
cpu-sample.mperf -= cpu-prev_mperf;
cpu-sample.tsc -= cpu-prev_tsc;
- intel_pstate_calc_busy(cpu, cpu-sample);
+ intel_pstate_calc_busy(cpu);
cpu-prev_aperf = aperf;
cpu-prev_mperf = mperf;
--
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 2/2] PCI/MSI: Phase out pci_enable_msi_block()
On Wed, Apr 30, 2014 at 05:49:33PM -0600, Bjorn Helgaas wrote: I mistakenly assumed this would have to wait because I thought there were other pci_enable_msi_block() users that wouldn't be removed until the v3.16 merge window. But I think I was wrong: I put your GenWQE patch in my tree, and I think that was the last use, so I can just add this patch on top. That is right, GenWQE is the last one. But I need a little help understanding the changelog: Up until now, when enabling MSI mode for a device a single successful call to arch_msi_check_device() was followed by a single call to arch_setup_msi_irqs() function. I understand this part; the following two paths call arch_msi_check_device() once and then arch_setup_msi_irqs() once: pci_enable_msi_block pci_msi_check_device arch_msi_check_device msi_capability_init arch_setup_msi_irqs pci_enable_msix pci_msi_check_device arch_msi_check_device msix_capability_init arch_setup_msi_irqs Yet, if arch_msi_check_device() returned success we should be able to call arch_setup_msi_irqs() multiple times - while it returns a number of MSI vectors that could have been allocated (a third state). I don't know what you mean by a third state. That is a number of MSI vectors that could have been allocated, which is neither success nor failure. In previous conversations someone branded it this as third state. Previously we only called arch_msi_check_device() once. After your patch, pci_enable_msi_range() can call it several times. The only non-trivial implementation of arch_msi_check_device() is in powerpc, and all the ppc_md.msi_check_device() possibilities look safe to call multiple times. Yep, I see it the same way. After your patch, the pci_enable_msi_range() path can also call arch_setup_msi_irqs() several times. I don't see a problem with that -- even if the first call succeeds and allocates something, then a subsequent call fails, I assume the allocations will be cleaned up when msi_capability_init() calls free_msi_irqs(). Well, the potential problem related to the fact arch_msi_check_device() could be called with 'nvec1' while arch_setup_msi_irqs() could be called with 'nvec2', where 'nvec1' 'nvec2'. While it is not a problem with current implementations, in therory it is possible free_msi_irqs() could be called with 'nvec2' and fail to clean up 'nvec1' - 'nvec2' number of resources. The only assumption that makes the above scenario impossible is if arch_msi_check_device() is stateless. Again, that is purely theoretical with no particular architecture in mind. This update makes use of the assumption described above. It could have broke things had the architectures done any pre- allocations or switch to some state in a call to function arch_msi_check_device(). But because arch_msi_check_device() is expected stateless and MSI resources are allocated in a follow-up call to arch_setup_msi_irqs() we should be fine. I guess you mean that your patch assumes arch_msi_check_device() is stateless. That looks like a safe assumption to me. Moreover, if arch_msi_check_device() was not stateless then it would be superfluous, since all state switches and allocations are done in arch_setup_msi_irqs() anyway. In fact, I think arch_msi_check_device() could be eliminated, but I do not want to engage with PPC folks at this stage ;) arch_setup_msi_irqs() is clearly not stateless, but I assume free_msi_irqs() is enough to clean up any state if we fail. Bjorn -- Regards, Alexander Gordeev agord...@redhat.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] spi: Fix hung task timeout when initialization fails
On Thu, May 01, 2014 at 10:15:15AM +0200, Ricardo Ribalda Delgado wrote:
If kthread_run on spi_init_queue() fails, spi_destroy_queue can lead to
hang timeout.
...
When this happens, spi_destroy_queue() leads to a hung process that
outputs a error message and avoids the computer to be halted/rebooted.
Why is the fix for this not to avoid running spi_destroy_queue() in the
first place? I would not in general expect it to be robust to call the
destructor function if the init function failed (and indeed this looks
like what's happening with the kthread code here) - even if it works now
it seems like it will be a source of bugs in the future.
- flush_kthread_worker(master-kworker);
- kthread_stop(master-kworker_task);
+ if (!IS_ERR(master-kworker_task)) {
+ flush_kthread_worker(master-kworker);
+ kthread_stop(master-kworker_task);
+ }
This still just looks like a race condition.
signature.asc
Description: Digital signature
Re: [PATCH 2/2] Hexagon: Delete stale barrier.h
On Fri, Apr 18, 2014 at 01:38:35PM +0530, Vineet Gupta wrote: It is likely Hexagon build is broken too in 3.15. But I don't have a working compiler to be sure. Cc: Richard Kuo r...@codeaurora.org Cc: Peter Zijlstra pet...@infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta vgu...@synopsys.com Hexagon build is still broken with 3.15-rc3 and with the latest upstream. This patch fixes the (build) problem. Would be great if the arch maintainer could apply this (or a similar) patch and send it to Linus. Compile-tested-by: Guenter Roeck li...@roeck-us.net -- 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/
powerpc:allmodconfig build failure (since 3.14)
Hi all, the powerpc:allmodconfig build has been broken since 3.14 with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 Any chance to get this fixed, or is it time to drop powerpc:allmodconfig from my test builds ? I would give it a shot myself, but that file is one that I would prefer not to touch. Thanks, Guenter -- 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 00/13] PCI/iommu: Fix DMA alias problems
This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (13): PCI: Add DMA alias iterator PCI: quirk pci_for_each_dma_alias() PCI: quirk dma_func_alias for Ricoh devices PCI: quirk dma_func_alias for Marvell devices PCI: Consolidate isolation domain code iommu/amd: Use pci_find_dma_isolation_root() for IOMMU groups iommu/amd: Update to use PCI DMA aliases iommu/intel: Use pci_find_dma_isolation_root() for IOMMU groups iommu/intel: Update to use PCI DMA aliases iommu/fsl: Use pci_find_dma_isolation_root() for IOMMU groups iommu: Remove pci.h PCI: Remove pci_find_upstream_pcie_bridge() PCI: Remove pci_get_dma_source() drivers/iommu/amd_iommu.c | 185 -- drivers/iommu/amd_iommu_types.h |1 drivers/iommu/fsl_pamu_domain.c | 67 drivers/iommu/intel-iommu.c | 293 +-- drivers/iommu/intel_irq_remapping.c | 55 +-- drivers/iommu/pci.h | 29 --- drivers/pci/quirks.c| 73 - drivers/pci/search.c| 234 +--- include/linux/pci.h | 21 +-- 9 files changed, 430 insertions(+), 528 deletions(-) delete mode 100644 drivers/iommu/pci.h -- 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 01/13] PCI: Add DMA alias iterator
In a mixed PCI/PCI-X/PCI-e topology, bridges can take ownership of
transactions, replacing the original requester ID with their own.
Sometimes we just want to know the resulting device or resulting
alias, sometimes we want each step in the chain. This iterator
allows either usage. When an endpoint is connected via an unbroken
chain of PCIe switches and root ports, it has no alias and its
requester ID is visible to the root bus. When PCI/X get in the way,
we pick up aliases for bridges.
The reason why we potentially care about each step in the path is
because of PCI-X. PCI-X has the concept of a requester ID, but
bridges may or may not take ownership of various types of
transactions. We therefore leave it to the consumer of this function
to prune out what they don't care about rather than attempt to flatten
the alias ourselves.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 70 ++
include/linux/pci.h |4 +++
2 files changed, 74 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 4a1b972..5601cdb 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -18,6 +18,76 @@ DECLARE_RWSEM(pci_bus_sem);
EXPORT_SYMBOL_GPL(pci_bus_sem);
/*
+ * pci_for_each_dma_alias - Iterate over DMA aliases for a device
+ * @pdev: starting downstream device
+ * @fn: function to call for each alias
+ * @data: opaque data to pass to @fn
+ *
+ * Starting @pdev, walk up the bus calling @fn for each possible alias
+ * of @pdev at the root bus.
+ */
+int pci_for_each_dma_alias(struct pci_dev *pdev,
+ int (*fn)(struct pci_dev *pdev,
+u16 alias, void *data), void *data)
+{
+ struct pci_bus *bus;
+ int ret;
+
+ ret = fn(pdev, PCI_DEVID(pdev-bus-number, pdev-devfn), data);
+ if (ret)
+ return ret;
+
+ for (bus = pdev-bus; !pci_is_root_bus(bus); bus = bus-parent) {
+ struct pci_dev *tmp;
+
+ /* Skip virtual buses */
+ if (!bus-self)
+ continue;
+
+ tmp = bus-self;
+
+ /*
+* PCIe-to-PCI/X bridges alias transactions from downstream
+* devices using the subordinate bus number (PCI Express to
+* PCI/PCI-X Bridge Spec, rev 1.0, sec 2.3). For all cases
+* where the upstream bus is PCI/X we alias to the bridge
+* (there are various conditions in the previous reference
+* where the bridge may take ownership of transactions, even
+* when the secondary interface is PCI-X).
+*/
+ if (pci_is_pcie(tmp)) {
+ switch (pci_pcie_type(tmp)) {
+ case PCI_EXP_TYPE_ROOT_PORT:
+ case PCI_EXP_TYPE_UPSTREAM:
+ case PCI_EXP_TYPE_DOWNSTREAM:
+ continue;
+ case PCI_EXP_TYPE_PCI_BRIDGE:
+ ret = fn(tmp,
+PCI_DEVID(tmp-subordinate-number,
+ PCI_DEVFN(0, 0)), data);
+ if (ret)
+ return ret;
+ continue;
+ case PCI_EXP_TYPE_PCIE_BRIDGE:
+ ret = fn(tmp,
+PCI_DEVID(tmp-bus-number,
+ tmp-devfn), data);
+ if (ret)
+ return ret;
+ continue;
+ }
+ } else {
+ ret = fn(tmp, PCI_DEVID(tmp-bus-number, tmp-devfn),
+data);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+/*
* find the upstream PCIe-to-PCI bridge of a PCI device
* if the device is PCIE, return NULL
* if the device isn't connected to a PCIe bridge (that is its parent is a
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..14b074b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1795,6 +1795,10 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct
pci_dev *pdev)
}
#endif
+int pci_for_each_dma_alias(struct pci_dev *pdev,
+ int (*fn)(struct pci_dev *pdev,
+u16 alias, void *data), void *data);
+
/**
* pci_find_upstream_pcie_bridge - find upstream PCIe-to-PCI bridge of a device
* @pdev: the PCI device
--
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
[PATCH 07/13] iommu/amd: Update to use PCI DMA aliases
AMD-Vi already has a concept of an alias provided via the IVRS table.
This alias only handles topology based aliases, such as PCIe-to-PCI
bridges. When such an alias is present, we continue to use it. When
a platform alias is not present, we can now add a check of the device
dma_func_alias to create our own. Note that the current code can
only handle a single alias of a device, and we don't attempt to change
that here. It would only become a factor for the requester ID seen by
the IOMMU if PCI-X were involved anway.
Since the alias is now potentially device specific rather than the
topology based alias provided by the platform, we need to clear it
when the device goes away.
With the DMA alias and isolation infrastructure now in PCI-core, we
could opt to ignore IVRS provided aliases. We now do this for IOMMU
groups. However, for this more common use case, the don't fix what
isn't broken mantra seems like the safer route.
This should allow AMD-Vi to work with devices like Marvell and Ricoh
with DMA function alias quirks.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Joerg Roedel j...@8bytes.org
---
drivers/iommu/amd_iommu.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 3d58de4..4621692 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -294,6 +294,7 @@ static int iommu_init_device(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
u16 alias;
+ u8 func_alias;
int ret;
if (dev-archdata.iommu)
@@ -304,6 +305,19 @@ static int iommu_init_device(struct device *dev)
return -ENOMEM;
alias = amd_iommu_alias_table[dev_data-devid];
+
+ /*
+* If there is no platform provided alias (topology-based) check
+* if we have a device quirk based alias.
+*/
+ func_alias = pdev-dma_func_alias ~(1 PCI_SLOT(pdev-devfn));
+ if (func_alias alias == dev_data-devid) {
+ WARN_ON(hweight8(func_alias) 1);
+ alias = PCI_DEVID(pdev-bus-number,
+ PCI_DEVFN(PCI_SLOT(pdev-devfn),
+ ffs(func_alias) - 1));
+ }
+
if (alias != dev_data-devid) {
struct iommu_dev_data *alias_data;
@@ -351,12 +365,19 @@ static void iommu_ignore_device(struct device *dev)
static void iommu_uninit_device(struct device *dev)
{
+ struct iommu_dev_data *dev_data = search_dev_data(get_device_id(dev));
+
+ if (!dev_data)
+ return;
+
iommu_group_remove_device(dev);
+ /* Unlink from alias, it may change if another device is re-plugged */
+ dev_data-alias_data = NULL;
+
/*
-* Nothing to do here - we keep dev_data around for unplugged devices
-* and reuse it when the device is re-plugged - not doing so would
-* introduce a ton of races.
+* We keep dev_data around for unplugged devices and reuse it when the
+* device is re-plugged - not doing so would introduce a ton of races.
*/
}
--
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 02/13] PCI: quirk pci_for_each_dma_alias()
There are a few broken devices that use the requester ID of a different
function in the slot for their DMA. To handle these, add a bitmap to
struct pci_dev (using an alignment gap) that quirks can populate. As
we iterate over the device and bus DMA aliases, also iterate over any
bits in the map.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 21 +
include/linux/pci.h |2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 5601cdb..ad698b2 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -37,6 +37,27 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
if (ret)
return ret;
+ /*
+* dma_func_alias provides a bitmap of other function numbers on
+* this same PCI slot to use as DMA aliases.
+*/
+ if (unlikely(pdev-dma_func_alias)) {
+ u8 map = pdev-dma_func_alias ~(1 PCI_FUNC(pdev-devfn));
+ int func;
+
+ for (func = 0; map func 8; func++, map = 1) {
+ if (!(map 1))
+ continue;
+
+ ret = fn(pdev,
+PCI_DEVID(pdev-bus-number,
+ PCI_DEVFN(PCI_SLOT(pdev-devfn),
+ func)), data);
+ if (ret)
+ return ret;
+ }
+ }
+
for (bus = pdev-bus; !pci_is_root_bus(bus); bus = bus-parent) {
struct pci_dev *tmp;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 14b074b..b4c97d2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -268,6 +268,8 @@ struct pci_dev {
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
u16 pcie_flags_reg; /* cached PCIe Capabilities Register */
+ u8 dma_func_alias; /* bitmap of functions used as DMA
+ aliases for this device */
struct pci_driver *driver; /* which driver has allocated this
device */
u64 dma_mask; /* Mask of the bits of bus address this
--
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 05/13] PCI: Consolidate isolation domain code
Each of the IOMMU drivers supporting IOMMU groups has their own
implementation of an algorithm to find the base device for an IOMMU
group. This N:1 function takes into account visibility of a PCI
device on the bus using DMA aliases, as well as the isolation of
devices using ACS. Since these are all generic PCI properties,
provide this helper in PCI code to create a single, standard
implementation.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 130 ++
include/linux/pci.h |1
2 files changed, 131 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index ad698b2..1eab231 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -109,6 +109,136 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
}
/*
+ * last_dma_alias_dev - Isolation root helper to record the last DMA alias pdev
+ */
+static int last_dma_alias_dev(struct pci_dev *pdev, u16 alias, void *data)
+{
+ *(struct pci_dev **)data = pdev;
+ return 0;
+}
+
+/*
+ * To consider a device isolated, we require ACS to support Source Validation,
+ * Request Redirection, Completer Redirection, and Upstream Forwarding. This
+ * effectively means that devices cannot spoof their requester ID, requests
+ * and commpletions cannot be redirected, and all transactions are forwarded
+ * upstream, even as it passes through a bridge where the target device is
+ * downstream.
+ */
+#define REQ_ACS_FLAGS (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
+
+/*
+ * pci_find_dma_isolation_root - Given a PCI device, find the root device for
+ * an isolation domain.
+ * @pdev: target device
+ *
+ * This function takes DMA alias quirks, bus topology, and PCI ACS into
+ * account to find the root device for an isolation domain. The root device
+ * is a consistent and representative device within the isolation domain.
+ * Passing any device within a given isolation domain results in the same
+ * returned root device, allowing this root device to be used for lookup
+ * for structures like IOMMU groups. Note that the root device is not
+ * necessarily a bridge, in the case of a multifunction device without
+ * DMA isolation between functions, the root device is the lowest function
+ * without isolation.
+ */
+struct pci_dev *pci_find_dma_isolation_root(struct pci_dev *pdev)
+{
+ struct pci_bus *bus;
+
+ /*
+* Step 1: Find the upstream DMA alias device
+*
+* A device can be aliased by bridges or DMA alias quirks. Being able
+* to differentiate devices is a minimum requirement for isolation.
+*/
+ pci_for_each_dma_alias(pdev, last_dma_alias_dev, pdev);
+
+ /*
+* Step 2: Find the upstream ACS device
+*
+* Beyond differentiation, ACS prevents uncontrolled peer-to-peer
+* transactions. Therefore the next step is to find the upstream
+* ACS device.
+*/
+ for (bus = pdev-bus; !pci_is_root_bus(bus); bus = bus-parent) {
+ if (!bus-self)
+ continue;
+
+ if (pci_acs_path_enabled(bus-self, NULL, REQ_ACS_FLAGS))
+ break;
+
+ pdev = bus-self;
+ }
+
+ /*
+* Step 3: Handle DMA function aliases
+*
+* PCI functions are sometimes broken and use the wrong requester
+* ID for DMA transactions. The requester ID for this device may
+* actually be used by another function in this slot. If such a
+* function exists, use it.
+*/
+ if (pdev-multifunction) {
+ u8 func, func_mask = 1 PCI_FUNC(pdev-devfn);
+
+ for (func = 0; func 8; func++) {
+ struct pci_dev *tmp;
+
+ if (func == PCI_FUNC(pdev-devfn))
+ continue;
+
+ tmp = pci_get_slot(pdev-bus,
+ PCI_DEVFN(PCI_SLOT(pdev-devfn),
+func));
+ if (!tmp)
+ continue;
+
+ pci_dev_put(tmp);
+ /*
+* If this device has a DMA alias to us, it becomes
+* the base device regardless of ACS.
+*/
+ if (tmp-dma_func_alias func_mask) {
+ pdev = tmp;
+ break;
+ }
+ }
+ }
+
+ /*
+* Step 4: Handle multifunction ACS
+*
+* If the resulting device is multifunction and does not itself
+* support ACS then we cannot assume isolation between functions.
+* The root device needs to be consistent, therefore we return the
+* lowest numbered function that also lacks ACS support.
+
[PATCH 04/13] PCI: quirk dma_func_alias for Marvell devices
Several Marvell devices and a JMicron device have a similar DMA
requester ID problem to Ricoh, except they use function 1 as the
PCIe requester ID. Add a quirk for these to populate the DMA
function alias bitmap.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a458c6b..82b2733 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3349,6 +3349,28 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe230,
quirk_dma_func0_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
+static void quirk_dma_func1_alias(struct pci_dev *dev)
+{
+ if (PCI_SLOT(dev-devfn) != 1)
+ dev-dma_func_alias |= (1 1);
+}
+
+/*
+ * Marvell 88SE9123 uses function 1 as the requester ID for DMA. In some
+ * SKUs function 1 is present and is a legacy IDE controller, in other
+ * SKUs this function is not present, making this a ghost requester.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=42679
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
+quirk_dma_func1_alias);
+/* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
+PCI_DEVICE_ID_JMICRON_JMB388_ESD,
+quirk_dma_func1_alias);
+
static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
{
if (!PCI_FUNC(dev-devfn))
--
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 15/21] of/fdt: move memreserve and dtb memory reservations into core
On Tue, Apr 22, 2014 at 08:18:15PM -0500, Rob Herring wrote: From: Rob Herring r...@kernel.org Move the /memreserve/ processing and dtb memory reservations into early_init_fdt_scan_reserved_mem. This converts arm, arm64, and powerpc as they are the only users of early_init_fdt_scan_reserved_mem. memblock_reserve is safe to call on the same region twice, so the reservation check for the dtb in powerpc 32-bit reservations is safe to remove. Signed-off-by: Rob Herring r...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org --- v2: No change arch/arm/include/asm/prom.h | 2 -- arch/arm/kernel/devtree.c | 27 --- arch/arm/mm/init.c | 1 - arch/arm64/mm/init.c| 21 - arch/powerpc/kernel/prom.c | 22 -- drivers/of/fdt.c| 16 6 files changed, 16 insertions(+), 73 deletions(-) For arm64: Acked-by: Catalin Marinas catalin.mari...@arm.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 13/13] PCI: Remove pci_get_dma_source()
It has no users; replaced by dma_func_alias.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c | 51 --
include/linux/pci.h |5 -
2 files changed, 56 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 82b2733..ea55b0f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3371,57 +3371,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
PCI_DEVICE_ID_JMICRON_JMB388_ESD,
quirk_dma_func1_alias);
-static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
-{
- if (!PCI_FUNC(dev-devfn))
- return pci_dev_get(dev);
-
- return pci_get_slot(dev-bus, PCI_DEVFN(PCI_SLOT(dev-devfn), 0));
-}
-
-static const struct pci_dev_dma_source {
- u16 vendor;
- u16 device;
- struct pci_dev *(*dma_source)(struct pci_dev *dev);
-} pci_dev_dma_source[] = {
- /*
-* https://bugzilla.redhat.com/show_bug.cgi?id=605888
-*
-* Some Ricoh devices use the function 0 source ID for DMA on
-* other functions of a multifunction device. The DMA devices
-* is therefore function 0, which will have implications of the
-* iommu grouping of these devices.
-*/
- { PCI_VENDOR_ID_RICOH, 0xe822, pci_func_0_dma_source },
- { PCI_VENDOR_ID_RICOH, 0xe230, pci_func_0_dma_source },
- { PCI_VENDOR_ID_RICOH, 0xe832, pci_func_0_dma_source },
- { PCI_VENDOR_ID_RICOH, 0xe476, pci_func_0_dma_source },
- { 0 }
-};
-
-/*
- * IOMMUs with isolation capabilities need to be programmed with the
- * correct source ID of a device. In most cases, the source ID matches
- * the device doing the DMA, but sometimes hardware is broken and will
- * tag the DMA as being sourced from a different device. This function
- * allows that translation. Note that the reference count of the
- * returned device is incremented on all paths.
- */
-struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
-{
- const struct pci_dev_dma_source *i;
-
- for (i = pci_dev_dma_source; i-dma_source; i++) {
- if ((i-vendor == dev-vendor ||
-i-vendor == (u16)PCI_ANY_ID)
- (i-device == dev-device ||
-i-device == (u16)PCI_ANY_ID))
- return i-dma_source(dev);
- }
-
- return pci_dev_get(dev);
-}
-
/*
* AMD has indicated that the devices below do not support peer-to-peer
* in any system where they are found in the southbridge with an AMD
diff --git a/include/linux/pci.h b/include/linux/pci.h
index bf4b0e9..65bdcfd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1530,16 +1530,11 @@ enum pci_fixup_pass {
#ifdef CONFIG_PCI_QUIRKS
void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
-struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
void pci_dev_specific_enable_acs(struct pci_dev *dev);
#else
static inline void pci_fixup_device(enum pci_fixup_pass pass,
struct pci_dev *dev) { }
-static inline struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
-{
- return pci_dev_get(dev);
-}
static inline int pci_dev_specific_acs_enabled(struct pci_dev *dev,
u16 acs_flags)
{
--
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 11/13] iommu: Remove pci.h
The single helper here no longer has any users.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Joerg Roedel j...@8bytes.org
---
drivers/iommu/pci.h | 29 -
1 file changed, 29 deletions(-)
delete mode 100644 drivers/iommu/pci.h
diff --git a/drivers/iommu/pci.h b/drivers/iommu/pci.h
deleted file mode 100644
index 352d80a..000
--- a/drivers/iommu/pci.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- *
- * Copyright (C) 2013 Red Hat, Inc.
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- */
-#ifndef __IOMMU_PCI_H
-#define __IOMMU_PCI_H
-
-/* Helper function for swapping pci device reference */
-static inline void swap_pci_ref(struct pci_dev **from, struct pci_dev *to)
-{
- pci_dev_put(*from);
- *from = to;
-}
-
-#endif /* __IOMMU_PCI_H */
--
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 12/13] PCI: Remove pci_find_upstream_pcie_bridge()
It's broken and has no users.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 35 ---
include/linux/pci.h | 11 ---
2 files changed, 46 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 1eab231..6d3b9be 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -238,41 +238,6 @@ struct pci_dev *pci_find_dma_isolation_root(struct pci_dev
*pdev)
return pdev;
}
-/*
- * find the upstream PCIe-to-PCI bridge of a PCI device
- * if the device is PCIE, return NULL
- * if the device isn't connected to a PCIe bridge (that is its parent is a
- * legacy PCI bridge and the bridge is directly connected to bus 0), return its
- * parent
- */
-struct pci_dev *
-pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
-{
- struct pci_dev *tmp = NULL;
-
- if (pci_is_pcie(pdev))
- return NULL;
- while (1) {
- if (pci_is_root_bus(pdev-bus))
- break;
- pdev = pdev-bus-self;
- /* a p2p bridge */
- if (!pci_is_pcie(pdev)) {
- tmp = pdev;
- continue;
- }
- /* PCI device should connect to a PCIe bridge */
- if (pci_pcie_type(pdev) != PCI_EXP_TYPE_PCI_BRIDGE) {
- /* Busted hardware? */
- WARN_ON_ONCE(1);
- return NULL;
- }
- return pdev;
- }
-
- return tmp;
-}
-
static struct pci_bus *pci_do_find_bus(struct pci_bus *bus, unsigned char
busnr)
{
struct pci_bus *child;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0d50064..bf4b0e9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1802,15 +1802,4 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
u16 alias, void *data), void *data);
struct pci_dev *pci_find_dma_isolation_root(struct pci_dev *pdev);
-/**
- * pci_find_upstream_pcie_bridge - find upstream PCIe-to-PCI bridge of a device
- * @pdev: the PCI device
- *
- * if the device is PCIE, return NULL
- * if the device isn't connected to a PCIe bridge (that is its parent is a
- * legacy PCI bridge and the bridge is directly connected to bus 0), return its
- * parent
- */
-struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
-
#endif /* LINUX_PCI_H */
--
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 10/13] iommu/fsl: Use pci_find_dma_isolation_root() for IOMMU groups
Drop custom code and use PCI provided isolation root support.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu_domain.c | 67 ++-
1 file changed, 3 insertions(+), 64 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 93072ba..83e3e7c 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -38,7 +38,6 @@
#include sysdev/fsl_pci.h
#include fsl_pamu_domain.h
-#include pci.h
/*
* Global spinlock that needs to be held while
@@ -892,8 +891,6 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain
*domain,
return ret;
}
-#define REQ_ACS_FLAGS (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
-
static struct iommu_group *get_device_iommu_group(struct device *dev)
{
struct iommu_group *group;
@@ -950,74 +947,16 @@ static struct iommu_group *get_pci_device_group(struct
pci_dev *pdev)
struct pci_controller *pci_ctl;
bool pci_endpt_partioning;
struct iommu_group *group = NULL;
- struct pci_dev *bridge, *dma_pdev = NULL;
+ struct pci_dev *dma_pdev;
pci_ctl = pci_bus_to_host(pdev-bus);
pci_endpt_partioning = check_pci_ctl_endpt_part(pci_ctl);
/* We can partition PCIe devices so assign device group to the device */
if (pci_endpt_partioning) {
- bridge = pci_find_upstream_pcie_bridge(pdev);
- if (bridge) {
- if (pci_is_pcie(bridge))
- dma_pdev = pci_get_domain_bus_and_slot(
- pci_domain_nr(pdev-bus),
- bridge-subordinate-number, 0);
- if (!dma_pdev)
- dma_pdev = pci_dev_get(bridge);
- } else
- dma_pdev = pci_dev_get(pdev);
-
- /* Account for quirked devices */
- swap_pci_ref(dma_pdev, pci_get_dma_source(dma_pdev));
-
- /*
-* If it's a multifunction device that does not support our
-* required ACS flags, add to the same group as lowest numbered
-* function that also does not suport the required ACS flags.
-*/
- if (dma_pdev-multifunction
- !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
- u8 i, slot = PCI_SLOT(dma_pdev-devfn);
+ dma_pdev = pci_find_dma_isolation_root(pdev);
- for (i = 0; i 8; i++) {
- struct pci_dev *tmp;
-
- tmp = pci_get_slot(dma_pdev-bus,
PCI_DEVFN(slot, i));
- if (!tmp)
- continue;
-
- if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
- swap_pci_ref(dma_pdev, tmp);
- break;
- }
- pci_dev_put(tmp);
- }
- }
-
- /*
-* Devices on the root bus go through the iommu. If that's not
us,
-* find the next upstream device and test ACS up to the root
bus.
-* Finding the next device may require skipping virtual buses.
-*/
- while (!pci_is_root_bus(dma_pdev-bus)) {
- struct pci_bus *bus = dma_pdev-bus;
-
- while (!bus-self) {
- if (!pci_is_root_bus(bus))
- bus = bus-parent;
- else
- goto root_bus;
- }
-
- if (pci_acs_path_enabled(bus-self, NULL,
REQ_ACS_FLAGS))
- break;
-
- swap_pci_ref(dma_pdev, pci_dev_get(bus-self));
- }
-
-root_bus:
group = get_device_iommu_group(dma_pdev-dev);
- pci_dev_put(dma_pdev);
+
/*
* PCIe controller is not a paritionable entity
* free the controller device iommu_group.
--
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 08/13] iommu/intel: Use pci_find_dma_isolation_root() for IOMMU groups
Drop custom code that attempts to do the exact same thing and use
PCI provided isolation root support. Existing IOMMU group laytout
should not change.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: David Woodhouse david.woodho...@intel.com
---
drivers/iommu/intel-iommu.c | 71 +--
1 file changed, 8 insertions(+), 63 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f256ffc..f0e50f1 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -44,7 +44,6 @@
#include asm/iommu.h
#include irq_remapping.h
-#include pci.h
#define ROOT_SIZE VTD_PAGE_SIZE
#define CONTEXT_SIZE VTD_PAGE_SIZE
@@ -4359,12 +4358,9 @@ static int intel_iommu_domain_has_cap(struct
iommu_domain *domain,
return 0;
}
-#define REQ_ACS_FLAGS (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
-
static int intel_iommu_add_device(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pci_dev *bridge, *dma_pdev = NULL;
+ struct pci_dev *pdev;
struct iommu_group *group;
int ret;
u8 bus, devfn;
@@ -4372,68 +4368,16 @@ static int intel_iommu_add_device(struct device *dev)
if (!device_to_iommu(dev, bus, devfn))
return -ENODEV;
- bridge = pci_find_upstream_pcie_bridge(pdev);
- if (bridge) {
- if (pci_is_pcie(bridge))
- dma_pdev = pci_get_domain_bus_and_slot(
- pci_domain_nr(pdev-bus),
- bridge-subordinate-number, 0);
- if (!dma_pdev)
- dma_pdev = pci_dev_get(bridge);
- } else
- dma_pdev = pci_dev_get(pdev);
-
- /* Account for quirked devices */
- swap_pci_ref(dma_pdev, pci_get_dma_source(dma_pdev));
-
- /*
-* If it's a multifunction device that does not support our
-* required ACS flags, add to the same group as lowest numbered
-* function that also does not suport the required ACS flags.
-*/
- if (dma_pdev-multifunction
- !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
- u8 i, slot = PCI_SLOT(dma_pdev-devfn);
-
- for (i = 0; i 8; i++) {
- struct pci_dev *tmp;
-
- tmp = pci_get_slot(dma_pdev-bus, PCI_DEVFN(slot, i));
- if (!tmp)
- continue;
-
- if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
- swap_pci_ref(dma_pdev, tmp);
- break;
- }
- pci_dev_put(tmp);
- }
+ group = iommu_group_get(dev);
+ if (group) {
+ iommu_group_put(group);
+ return 0;
}
- /*
-* Devices on the root bus go through the iommu. If that's not us,
-* find the next upstream device and test ACS up to the root bus.
-* Finding the next device may require skipping virtual buses.
-*/
- while (!pci_is_root_bus(dma_pdev-bus)) {
- struct pci_bus *bus = dma_pdev-bus;
+ pdev = pci_find_dma_isolation_root(to_pci_dev(dev));
- while (!bus-self) {
- if (!pci_is_root_bus(bus))
- bus = bus-parent;
- else
- goto root_bus;
- }
+ group = iommu_group_get(pdev-dev);
- if (pci_acs_path_enabled(bus-self, NULL, REQ_ACS_FLAGS))
- break;
-
- swap_pci_ref(dma_pdev, pci_dev_get(bus-self));
- }
-
-root_bus:
- group = iommu_group_get(dma_pdev-dev);
- pci_dev_put(dma_pdev);
if (!group) {
group = iommu_group_alloc();
if (IS_ERR(group))
@@ -4443,6 +4387,7 @@ root_bus:
ret = iommu_group_add_device(group, dev);
iommu_group_put(group);
+
return ret;
}
--
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 09/13] iommu/intel: Update to use PCI DMA aliases
VT-d code currently makes use of pci_find_upstream_pcie_bridge() in
order to find the topology based alias of a device. This function has
a few problems. First, it doesn't check the entire alias path of the
device to the root bus, therefore if a PCIe device is masked upstream,
the wrong result is produced. Also, it's known to get confused and
give up when it crosses a bridge from a conventional PCI bus to a PCIe
bus that lacks a PCIe capability. The PCI-core provided DMA alias
support solves both of these problems and additionally adds support
for DMA function quirks allowing VT-d to work with devices like
Marvell and Ricoh with known broken requester IDs.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: David Woodhouse david.woodho...@intel.com
---
drivers/iommu/intel-iommu.c | 222 ---
drivers/iommu/intel_irq_remapping.c | 55 ++---
2 files changed, 139 insertions(+), 138 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f0e50f1..d87b3c9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1840,54 +1840,56 @@ static int domain_context_mapping_one(struct
dmar_domain *domain,
return 0;
}
+struct domain_context_mapping_data {
+ struct dmar_domain *domain;
+ struct intel_iommu *iommu;
+ int translation;
+};
+
+static int domain_context_mapping_cb(struct pci_dev *pdev,
+u16 alias, void *opaque)
+{
+ struct domain_context_mapping_data *data = opaque;
+
+ return domain_context_mapping_one(data-domain, data-iommu,
+ PCI_BUS_NUM(alias), alias 0xff,
+ data-translation);
+}
+
static int
domain_context_mapping(struct dmar_domain *domain, struct device *dev,
int translation)
{
- int ret;
- struct pci_dev *pdev, *tmp, *parent;
struct intel_iommu *iommu;
u8 bus, devfn;
+ struct domain_context_mapping_data data;
iommu = device_to_iommu(dev, bus, devfn);
if (!iommu)
return -ENODEV;
- ret = domain_context_mapping_one(domain, iommu, bus, devfn,
-translation);
- if (ret || !dev_is_pci(dev))
- return ret;
-
- /* dependent device mapping */
- pdev = to_pci_dev(dev);
- tmp = pci_find_upstream_pcie_bridge(pdev);
- if (!tmp)
- return 0;
- /* Secondary interface's bus number and devfn 0 */
- parent = pdev-bus-self;
- while (parent != tmp) {
- ret = domain_context_mapping_one(domain, iommu,
-parent-bus-number,
-parent-devfn, translation);
- if (ret)
- return ret;
- parent = parent-bus-self;
- }
- if (pci_is_pcie(tmp)) /* this is a PCIe-to-PCI bridge */
- return domain_context_mapping_one(domain, iommu,
- tmp-subordinate-number, 0,
- translation);
- else /* this is a legacy PCI bridge */
- return domain_context_mapping_one(domain, iommu,
- tmp-bus-number,
- tmp-devfn,
+ if (!dev_is_pci(dev))
+ return domain_context_mapping_one(domain, iommu, bus, devfn,
translation);
+
+ data.domain = domain;
+ data.iommu = iommu;
+ data.translation = translation;
+
+ return pci_for_each_dma_alias(to_pci_dev(dev),
+ domain_context_mapping_cb, data);
+}
+
+static int domain_context_mapped_cb(struct pci_dev *pdev,
+ u16 alias, void *opaque)
+{
+ struct intel_iommu *iommu = opaque;
+
+ return !device_context_mapped(iommu, PCI_BUS_NUM(alias), alias 0xff);
}
static int domain_context_mapped(struct device *dev)
{
- int ret;
- struct pci_dev *pdev, *tmp, *parent;
struct intel_iommu *iommu;
u8 bus, devfn;
@@ -1895,30 +1897,11 @@ static int domain_context_mapped(struct device *dev)
if (!iommu)
return -ENODEV;
- ret = device_context_mapped(iommu, bus, devfn);
- if (!ret || !dev_is_pci(dev))
- return ret;
+ if (dev_is_pci(dev))
+ return device_context_mapped(iommu, bus, devfn);
- /* dependent device mapping */
- pdev = to_pci_dev(dev);
- tmp = pci_find_upstream_pcie_bridge(pdev);
- if (!tmp)
- return ret;
- /* Secondary interface's bus number and devfn 0 */
- parent = pdev-bus-self;
- while (parent != tmp) {
- ret =
[PATCH 06/13] iommu/amd: Use pci_find_dma_isolation_root() for IOMMU groups
The IVRS tables provides aliases, but not to the extent now provided
by PCI core with DMA alias support and pci_find_dma_isolation_root().
The expectation is that the kernel and IVRS will produce the same
result for topology based aliases while the kernel will also include
device specific DMA quirks. We therefore drop the AMD-specific IOMMU
group discovery in favor of the common code. This also allows us to
drop tracking of the IOMMU group on the alias dev_data structure.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Joerg Roedel j...@8bytes.org
---
drivers/iommu/amd_iommu.c | 158 ++-
drivers/iommu/amd_iommu_types.h |1
2 files changed, 10 insertions(+), 149 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index c949520..3d58de4 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -46,7 +46,6 @@
#include amd_iommu_proto.h
#include amd_iommu_types.h
#include irq_remapping.h
-#include pci.h
#define CMD_SET_TYPE(cmd, t) ((cmd)-data[1] |= ((t) 28))
@@ -133,9 +132,6 @@ static void free_dev_data(struct iommu_dev_data *dev_data)
list_del(dev_data-dev_data_list);
spin_unlock_irqrestore(dev_data_list_lock, flags);
- if (dev_data-group)
- iommu_group_put(dev_data-group);
-
kfree(dev_data);
}
@@ -264,107 +260,10 @@ static bool check_device(struct device *dev)
return true;
}
-static struct pci_bus *find_hosted_bus(struct pci_bus *bus)
-{
- while (!bus-self) {
- if (!pci_is_root_bus(bus))
- bus = bus-parent;
- else
- return ERR_PTR(-ENODEV);
- }
-
- return bus;
-}
-
-#define REQ_ACS_FLAGS (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
-
-static struct pci_dev *get_isolation_root(struct pci_dev *pdev)
-{
- struct pci_dev *dma_pdev = pdev;
-
- /* Account for quirked devices */
- swap_pci_ref(dma_pdev, pci_get_dma_source(dma_pdev));
-
- /*
-* If it's a multifunction device that does not support our
-* required ACS flags, add to the same group as lowest numbered
-* function that also does not suport the required ACS flags.
-*/
- if (dma_pdev-multifunction
- !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
- u8 i, slot = PCI_SLOT(dma_pdev-devfn);
-
- for (i = 0; i 8; i++) {
- struct pci_dev *tmp;
-
- tmp = pci_get_slot(dma_pdev-bus, PCI_DEVFN(slot, i));
- if (!tmp)
- continue;
-
- if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
- swap_pci_ref(dma_pdev, tmp);
- break;
- }
- pci_dev_put(tmp);
- }
- }
-
- /*
-* Devices on the root bus go through the iommu. If that's not us,
-* find the next upstream device and test ACS up to the root bus.
-* Finding the next device may require skipping virtual buses.
-*/
- while (!pci_is_root_bus(dma_pdev-bus)) {
- struct pci_bus *bus = find_hosted_bus(dma_pdev-bus);
- if (IS_ERR(bus))
- break;
-
- if (pci_acs_path_enabled(bus-self, NULL, REQ_ACS_FLAGS))
- break;
-
- swap_pci_ref(dma_pdev, pci_dev_get(bus-self));
- }
-
- return dma_pdev;
-}
-
-static int use_pdev_iommu_group(struct pci_dev *pdev, struct device *dev)
-{
- struct iommu_group *group = iommu_group_get(pdev-dev);
- int ret;
-
- if (!group) {
- group = iommu_group_alloc();
- if (IS_ERR(group))
- return PTR_ERR(group);
-
- WARN_ON(pdev-dev != dev);
- }
-
- ret = iommu_group_add_device(group, dev);
- iommu_group_put(group);
- return ret;
-}
-
-static int use_dev_data_iommu_group(struct iommu_dev_data *dev_data,
- struct device *dev)
-{
- if (!dev_data-group) {
- struct iommu_group *group = iommu_group_alloc();
- if (IS_ERR(group))
- return PTR_ERR(group);
-
- dev_data-group = group;
- }
-
- return iommu_group_add_device(dev_data-group, dev);
-}
-
static int init_iommu_group(struct device *dev)
{
- struct iommu_dev_data *dev_data;
struct iommu_group *group;
- struct pci_dev *dma_pdev;
+ struct pci_dev *pdev;
int ret;
group = iommu_group_get(dev);
@@ -373,58 +272,21 @@ static int init_iommu_group(struct device *dev)
return 0;
}
- dev_data = find_dev_data(get_device_id(dev));
- if (!dev_data)
- return -ENOMEM;
-
- if (dev_data-alias_data) {
-
[PATCH 03/13] PCI: quirk dma_func_alias for Ricoh devices
The existing quirk for these devices doesn't really solve the problem,
re-implement it using the DMA alias iterator. We'll come back later
and remove the existing quirk and dma_source interface.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e729206..a458c6b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -,6 +,22 @@ int pci_dev_specific_reset(struct pci_dev *dev, int
probe)
return -ENOTTY;
}
+static void quirk_dma_func0_alias(struct pci_dev *dev)
+{
+ if (PCI_SLOT(dev-devfn) != 0)
+ dev-dma_func_alias |= (1 0);
+}
+
+/*
+ * https://bugzilla.redhat.com/show_bug.cgi?id=605888
+ *
+ * Some Ricoh devices use function 0 as the PCIe requester ID for DMA.
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe822, quirk_dma_func0_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe230, quirk_dma_func0_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
+
static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
{
if (!PCI_FUNC(dev-devfn))
--
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: [perf] more perf_fuzzer memory corruption
On Thu, 1 May 2014, Vince Weaver wrote: On Thu, 1 May 2014, Peter Zijlstra wrote: But yes please! OK, sorry for the delay, had forgotten to re-enable -pg for perf in the makefile when I applied your patch so had to re-build the kernel. The trace is here: www.eece.maine.edu/~vweaver/junk/pzbug.out.bz2 No analysis so hopefully it's good, I've got an event to go to in a few minutes. The messages: [ 634.846367] [ cut here ] [ 634.851477] WARNING: CPU: 6 PID: 2915 at kernel/events/core.c:3232 __free_event+0x93/0xa0() So we are on the right track: perf_fuzzer-2915 [006] 634.846280: bprint: _free_event: freeing with 0 refs; ptr=0x0x8800cef05000 [ 634.935276] CPU: 6 PID: 2915 Comm: perf_fuzzer Not tainted 3.15.0-rc1+ #94 [ 634.942754] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 [ 634.950728] 0009 8801174b7b78 81649bf0 [ 634.958795] 8801174b7bb0 810646ad 8800cef05000 [ 634.966855] 8800cd47be10 880036c7b388 8800cef052a0 8801174b7bc0 And the corrupted element: [ 635.995839] Slab corruption (Tainted: GW): kmalloc-2048 start=8800cef05000, len=2048 The same address. Heading out now and postponing the chase for tomorrow morning. Thanks, tglx -- 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: [RFC PATCH 0/3] mtd: nand: add randomizer support
On Thu, May 01, 2014 at 03:09:49AM +0200, Boris BREZILLON wrote: Hello, This series is a proposal to add support for randomizers (either software or hardware) to NAND flash controller drivers. FWIW, I think the term for reversibly combining a PRBS with data is 'scrambling', it is often used in communication systems for similar reasons - probabilisticly increasing transition density. randomizing is something else entirely :) BTW, there are security concerns here. The scrambler PRBS must not be predictable by the user, otherwise they can write data that undoes the scramble and defeat it, ie deliberately writing the last 2k of a 4k write block as all 0's after scrambling could cause the first 2k to be lost. That feels like something that could be scary .. Jason -- 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: [3.15rc1] BUG at mm/filemap.c:202!
On Wed, Apr 16, 2014 at 10:40 PM, Hugh Dickins hu...@google.com wrote: On Tue, 15 Apr 2014, Dave Jones wrote: kernel BUG at mm/filemap.c:202! invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: tun fuse bnep rfcomm nfnetlink llc2 af_key ipt_ULOG can_raw can_bcm scsi_transport_iscsi nfc caif_socket caif af_802154 ieee802154 phonet af_r xrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm xfs libcrc32c snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel snd_hda_controller snd_hda_codec e 1000e btusb bluetooth microcode pcspkr serio_raw snd_hwdep snd_seq snd_seq_device snd_pcm 6lowpan_iphc usb_debug rfkill ptp pps_core shpchp snd_timer snd soundcore CPU: 3 PID: 14244 Comm: trinity-main Not tainted 3.15.0-rc1+ #188 task: 8801be2c50a0 ti: 8801d683 task.ti: 8801d683 RIP: 0010:[9915b4d5] [9915b4d5] __delete_from_page_cache+0x315/0x320 RSP: 0018:8801d6831b10 EFLAGS: 00010046 RAX: RBX: 0003 RCX: 001d RDX: 012a RSI: 99a9a1c0 RDI: 99a6dad5 RBP: 8801d6831b60 R08: 005d R09: 8801b0361530 R10: 8801d6831b28 R11: R12: ea000734d440 R13: 880241235008 R14: R15: 880241235010 FS: 7f81925cf740() GS:88024460() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00630058 CR3: 19c0e000 CR4: 001407e0 DR0: 00df3000 DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Stack: 880241235020 880241235038 8801b0361530 8801b0361640 1da16adc ea000734d440 880241235020 005d 8801d6831b88 9915b51d Call Trace: [9915b51d] delete_from_page_cache+0x3d/0x70 [9916ab7b] truncate_inode_page+0x5b/0x90 [991759ab] shmem_undo_range+0x30b/0x780 [990a99e5] ? local_clock+0x25/0x30 [99175e34] shmem_truncate_range+0x14/0x30 [99175f1d] shmem_evict_inode+0xcd/0x150 [991e46e7] evict+0xa7/0x170 [991e5005] iput+0xf5/0x180 [991df390] dentry_kill+0x210/0x250 [991df43c] dput+0x6c/0x110 [991c8c19] __fput+0x189/0x200 [991c8cde] fput+0xe/0x10 [990900b4] task_work_run+0xb4/0xe0 [9906ea92] do_exit+0x302/0xb80 [99349843] ? __this_cpu_preempt_check+0x13/0x20 [9907038c] do_group_exit+0x4c/0xc0 [99070414] SyS_exit_group+0x14/0x20 [9975a964] tracesys+0xdd/0xe2 Code: 4c 89 30 e9 80 fe ff ff 48 8b 75 c0 4c 89 ff e8 e2 8e 1c 00 84 c0 0f 85 6c fe ff ff e9 4f fe ff ff 0f 1f 44 00 00 e8 4e 85 5e 00 0f 0b e8 84 1d f1 ff 0f : 202 BUG_ON(page_mapped(page)); I've been wrestling with this report, but made no progress; maybe if I set down a few thoughts, someone can help us forward. It is reasonable to assume (but unreasonable to hold on too tightly to the assumption) that this is related to Dave's contemporaneous report of BUG: Bad rss-counter state mm:88023fc73c00 idx:0 val:5 I don't know if they both occurred in the same session; but whether or not they did, the BUG_ON(page_mapped(page)) from inode eviction implies that not every pte mapping a shmem file page had been located when its last mapper exited; and the rss-counter message implies that there were five pte mappings of file(s) which could not be located when their mapper exited. It is also reasonable to assume (but unreasonable to hold on too tightly to the assumption) that this is another manifestation of the same unsolved mm/filemap.c:202 that Sasha reported on rc5-next a month ago, https://lkml.org/lkml/2014/3/7/298 Now that one occurred, not while evicting a shmem inode, but while punching a hole in it with madvise(,,MADV_REMOVE). At the time I set it aside to consider when improving shmem_fallocate(), but now it looks more like a precursor of Dave's. One way this could happen is if we have racing tasks setting up ptes without the necessary locking, one placing its pte on top of another's, so page_mapcount goes up by 2 but comes down by 1 later. But I failed to find anywhere in the code in danger of doing that. Another way it could happen is if a vma is removed from i_mmap tree and i_mmap_nonlinear list, without zap_pte_range() having zapped all of its ptes; but I don't see where that could happen either. Sasha's came before shmem participated in Kirill's filemap_map_pages fault-around; but his pte_same/pte_none checking under ptl there looks correct anyway. I've not found any recent change likely to blame. Help! Using a
Re: [PATCH v3] rwsem: Support optimistic spinning
On Wed, 2014-04-30 at 20:21 -0700, Davidlohr Bueso wrote:
+
+static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
+{
+ struct task_struct *owner;
+ bool on_cpu = true;
+
+ if (need_resched())
+ return 0;
+
+ rcu_read_lock();
+ owner = ACCESS_ONCE(sem-owner);
+ if (owner)
+ on_cpu = owner-on_cpu;
+ rcu_read_unlock();
+
+ /*
+ * If lock-owner is not set, the mutex owner may have
+ * just acquired it and not set the owner yet or the mutex
Nitpick. Change the above 2 mutex in comment to rwsem.
+ * has been released.
+ */
+ return on_cpu;
+}
+
Tim
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board
On Thu, May 01, 2014 at 08:54:14AM -0700, Doug Anderson wrote: This is exactly the thing (expected clock parenting) we agreed could be put in the device tree I think. ...but I don't know that anyone proposed exactly how that would work. There's patches been posted by (IIRC) Sylvester Nawrocki for this which I think Mike was basically happy with - I don't immediately see them in -next though, but I may be looking in the wrong place. signature.asc Description: Digital signature
Re: [PATCH 1/5] ARM: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
On 05/01/2014 12:07 AM, Brian Norris wrote: On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote: I guess you could also just see if arm-soc (a...@kernel.org) will take this patch, and deal with any merge conflicts that arise when they merge all the sub-arch defconfig changes. I CC'd them to find out if they think that's a better idea. I'm preparing a split patch series and should send v2 shortly. A few of the unaccounted platforms + the multi-platform are lumped together for direct inclusion in arm-soc (?). What is this a...@kernel.org you speak of? My Google-fu doesn't turn up a separate arm-soc email / mailing list, and it's not in MAINTAINERS. It's the email address of the ARM SoC maintainers (Arnd, Olof, Kevin). All the ARM sub-architecture maintainers send their pull requests there, which all get aggregated and forwarded to Linus. They also take some patches directly, for cross-sub-architecture stuff like multi_v7_defconfig, or small amounts of bug-fixes after the main pull requests are sent. -- 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: [BUG] kmemleak on __radix_tree_preload
On Fri, Apr 25, 2014 at 10:45:40AM +0900, Jaegeuk Kim wrote:
2. Bug
This is one of the results, but all the results indicate
__radix_tree_preload.
unreferenced object 0x88002ae2a238 (size 576):
comm fsstress, pid 25019, jiffies 4295651360 (age 2276.104s)
hex dump (first 32 bytes):
01 00 00 00 81 ff ff ff 00 00 00 00 00 00 00 00
40 7d 37 81 ff ff ff ff 50 a2 e2 2a 00 88 ff ff @}7.P..*
backtrace:
[8170e546] kmemleak_alloc+0x26/0x50
[8119feac] kmem_cache_alloc+0xdc/0x190
[81378709] __radix_tree_preload+0x49/0xc0
[813787a1] radix_tree_maybe_preload+0x21/0x30
[8114bbbc] add_to_page_cache_lru+0x3c/0xc0
[8114c778] grab_cache_page_write_begin+0x98/0xf0
[a02d3151] f2fs_write_begin+0xa1/0x370 [f2fs]
[8114af47] generic_perform_write+0xc7/0x1e0
[8114d230] __generic_file_aio_write+0x1d0/0x400
[8114d4c0] generic_file_aio_write+0x60/0xe0
[811b281a] do_sync_write+0x5a/0x90
[811b3575] vfs_write+0xc5/0x1f0
[811b3a92] SyS_write+0x52/0xb0
[81730912] system_call_fastpath+0x16/0x1b
[] 0x
Do all the backtraces look like the above (coming from
add_to_page_cache_lru)?
There were some changes in lib/radix-tree.c since 3.14, maybe you could
try reverting them and see if the leaks still appear (cc'ing Johannes).
It could also be a false positive.
An issue with debugging such cases is that the preloading is common for
multiple radix trees, so the actual radix_tree_node_alloc() could be on
a different path. You could give the patch below a try to see what
backtrace you get (it updates backtrace in radix_tree_node_alloc()).
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index a7563ec4ea7b..b772418bf064 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -142,6 +142,7 @@ kmemleak_alloc_percpu- notify of a percpu memory
block allocation
kmemleak_free - notify of a memory block freeing
kmemleak_free_part - notify of a partial memory block freeing
kmemleak_free_percpu- notify of a percpu memory block freeing
+kmemleak_update_trace - update object allocation stack trace
kmemleak_not_leak - mark an object as not a leak
kmemleak_ignore - do not scan or report an object as leak
kmemleak_scan_area - add scan areas inside a memory block
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 5bb424659c04..057e95971014 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -30,6 +30,7 @@ extern void kmemleak_alloc_percpu(const void __percpu *ptr,
size_t size) __ref;
extern void kmemleak_free(const void *ptr) __ref;
extern void kmemleak_free_part(const void *ptr, size_t size) __ref;
extern void kmemleak_free_percpu(const void __percpu *ptr) __ref;
+extern void kmemleak_update_trace(const void *ptr) __ref;
extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
@@ -83,6 +84,9 @@ static inline void kmemleak_free_recursive(const void *ptr,
unsigned long flags)
static inline void kmemleak_free_percpu(const void __percpu *ptr)
{
}
+static inline void kmemleak_update_trace(const void *ptr)
+{
+}
static inline void kmemleak_not_leak(const void *ptr)
{
}
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 9599aa72d7a0..5297f8e09096 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -27,6 +27,7 @@
#include linux/radix-tree.h
#include linux/percpu.h
#include linux/slab.h
+#include linux/kmemleak.h
#include linux/notifier.h
#include linux/cpu.h
#include linux/string.h
@@ -200,6 +201,11 @@ radix_tree_node_alloc(struct radix_tree_root *root)
rtp-nodes[rtp-nr - 1] = NULL;
rtp-nr--;
}
+ /*
+* Update the allocation stack trace as this is more useful
+* for debugging.
+*/
+ kmemleak_update_trace(ret);
}
if (ret == NULL)
ret = kmem_cache_alloc(radix_tree_node_cachep, gfp_mask);
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 3a36e2b16cba..61a64ed2fbef 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -990,6 +990,40 @@ void __ref kmemleak_free_percpu(const void __percpu *ptr)
EXPORT_SYMBOL_GPL(kmemleak_free_percpu);
/**
+ * kmemleak_update_trace - update object allocation stack trace
+ * @ptr: pointer to beginning of the object
+ *
+ * Override the object allocation stack trace for cases where the actual
+ * allocation place is not always useful.
+ */
+void __ref kmemleak_update_trace(const void *ptr)
+{
+ struct kmemleak_object *object;
+ unsigned long flags;
+
+ pr_debug(%s(0x%p)\n, __func__, ptr);
+
+ if (!kmemleak_enabled || IS_ERR_OR_NULL(ptr))
+
[PATCH] uprobes: fix scratch register selection for rip-relative fixups
Before this patch, instructions such as div, mul,
shifts with count in CL, cmpxchg are mishandled.
This patch adds vex prefix handling. In particular,
it avoids colliding with register operand encoded
in vex. field.
Since we need to avoid two possible register operands,
the selection of scratch register needs to be from at least
three registers.
After looking through a lot of CPU docs, it looks like
the safest choice is SI,DI,BX. Selecting BX needs care
to not collide with implicit use of BX by cmpxchg8b.
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC: Ingo Molnar mi...@kernel.org
CC: Oleg Nesterov o...@redhat.com
---
arch/x86/kernel/uprobes.c | 154 ++
1 file changed, 116 insertions(+), 38 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index c41bb4b..6cb53d1 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -41,8 +41,10 @@
/* Instruction will modify TF, don't change it */
#define UPROBE_FIX_SETF0x04
-#define UPROBE_FIX_RIP_AX 0x08
-#define UPROBE_FIX_RIP_CX 0x10
+#define UPROBE_FIX_RIP_SI 0x08
+#define UPROBE_FIX_RIP_DI 0x10
+#define UPROBE_FIX_RIP_BX 0x20
+#define UPROBE_FIX_RIP_ALL 0x38
#defineUPROBE_TRAP_NR UINT_MAX
@@ -51,6 +53,8 @@
#define OPCODE2(insn) ((insn)-opcode.bytes[1])
#define OPCODE3(insn) ((insn)-opcode.bytes[2])
#define MODRM_REG(insn)X86_MODRM_REG((insn)-modrm.value)
+#define VEX2_(insn)X86_VEX_V((insn)-vex_prefix.bytes[1])
+#define VEX3_(insn)X86_VEX_V((insn)-vex_prefix.bytes[2])
#define W(row, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf)\
(((b0##UL 0x0)|(b1##UL 0x1)|(b2##UL 0x2)|(b3##UL 0x3) | \
@@ -274,63 +278,137 @@ static inline bool is_64bit_mm(struct mm_struct *mm)
static void riprel_analyze(struct arch_uprobe *auprobe, struct insn *insn)
{
u8 *cursor;
+ u8 can_use_regs;
u8 reg;
+ int reg2;
if (!insn_rip_relative(insn))
return;
/*
-* insn_rip_relative() would have decoded rex_prefix, modrm.
+* insn_rip_relative() would have decoded rex_prefix,
+* vex_prefix, modrm.
* Clear REX.b bit (extension of MODRM.rm field):
-* we want to encode rax/rcx, not r8/r9.
+* we want to encode low numbered reg, not r8+.
*/
if (insn-rex_prefix.nbytes) {
cursor = auprobe-insn + insn_offset_rex_prefix(insn);
- *cursor = 0xfe;/* Clearing REX.B bit */
+ /* REX byte has 0100wrxb layout, clearing REX.b bit */
+ *cursor = 0xfe;
+ }
+ /* Similar treatment for VEX3 prefix */
+ /* TODO: add XOP/EVEX treatment when insn decoder supports them */
+ if (insn-vex_prefix.nbytes == 3) {
+ /*
+* vex2: c5rLpp (has no b bit)
+* vex3/xop: c4/8f rxbm wLpp
+* evex: 62rxbR00mm.w1pp.zllBVaaa
+* (evex will need setting of both b and x since
+* in non-sib encoding evex.x is 4th bit of MODRM.rm)
+* Setting VEX3.b (setting because it has inverted meaning):
+*/
+ cursor = auprobe-insn + insn_offset_vex_prefix(insn) + 1;
+ *cursor |= 0x20;
}
/*
+* Convert from rip-relative addressing
+* to register-relative addressing via a scratch register.
+*
+* This is tricky since there are insns with modrm byte
+* which also use registers not encoded in modrm byte:
+* [i]div/[i]mul: implicitly use dx:ax
+* shift ops: implicitly use cx
+* cmpxchg: implicitly uses ax
+* cmpxchg8/16b: implicitly uses dx:ax and bx:cx
+* Encoding: 0f c7/1 modrm
+* The code below thinks that reg=1 (cx), chooses si as scratch.
+* mulx: implicitly uses dx: mulx r/m,r1,r2: r1:r2 = dx * r/m
+* First appeared in Haswell (BMI2 insn). It is vex-encoded.
+* Example where none of bx,cx,dx can be used as scratch reg:
+* c4 e2 63 f6 0d disp32 mulx disp32(%rip),%ebx,%ecx
+* [v]pcmpistri: implicitly uses cx, xmm0
+* [v]pcmpistrm: implicitly uses xmm0
+* [v]pcmpestri: implicitly uses ax, dx, cx, xmm0
+* [v]pcmpestrm: implicitly uses ax, dx, xmm0
+* Evil SSE4.2 string comparison ops from hell.
+* maskmovq/[v]maskmovdqu: implicitly uses (ds:rdi) as destination.
+* Encoding: 0f f7 modrm, 66 0f f7 modrm, vex-encoded: c5 f9 f7 modrm.
+* Store op1, byte-masked by op2 msb's in each byte, to (ds:rdi).
+* AMD says it has no
Re: [PATCH 2/2] Hexagon: Delete stale barrier.h
On Thu, May 1, 2014 at 9:10 AM, Guenter Roeck li...@roeck-us.net wrote: Hexagon build is still broken with 3.15-rc3 and with the latest upstream. This patch fixes the (build) problem. Would be great if the arch maintainer could apply this (or a similar) patch and send it to Linus. I took it directly, since you compile-tested it. Linus -- 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: [perf] more perf_fuzzer memory corruption
On Thu, 1 May 2014, Thomas Gleixner wrote: Heading out now and postponing the chase for tomorrow morning. Some decoding of the trace. One thing that's possibly unrelated, but on both this and the previous bug the main thread was doing a perf_poll while the bug is triggered. I guess in theory that could mess up the ref count, although in both cases the poll() call started after the event was closed so I wouldn't think it'd be able to poll on a closed fd. Allocated: ...-2508 [002] 634.721037: kmalloc: (perf_event_alloc+0x5a) call_site=81139b4a ptr=0x8800cef05000 bytes_req=1272 bytes_alloc=2048 gfp_flags=GFP_KERNEL|GFP_ZERO This time it's PERF_COUNT_SW_PAGE_FAULTS_MAJ but with inherit enabled: ...-2508 [002] 634.721193: bprint: SYSC_perf_event_open: Opened: 1 6 0 1 ...-2508 [002] 634.721193: sys_exit: NR 298 = 3 __perf_event_task_sched in We are added to the CPU1 swevent hlist for the last time (and never deleted, hence the bug): ...-2508 [001] 634.838474: function: __perf_event_task_sched_in ...-2508 [001] 634.838490: bprint: perf_swevent_add: VMW add_rcu: 0x8800cef05000 Event fd closed in parent: ...-2508 [001] 634.839922: sys_enter:NR 3 (3, 7523dc8c, 0, 22, 7f420cf6210c, 7f420cf62120) ...-2508 [001] 634.839924: sys_exit: NR 3 = 0 Kill the child: ...-2508 [001] 634.845994: sys_enter:NR 62 (b63, 9, 7, 1, 7f420cf620f8, 7f420cf62120) Event released: perf_fuzzer-2915 [006] 634.846247: function: perf_release perf_fuzzer-2915 [006] 634.846248: bprint: put_event: put ref: 0; ptr=0x0x8800cef05000 other=0x(nil) perf_fuzzer-2915 [006] 634.846252: function: perf_group_detach perf_fuzzer-2915 [006] 634.846253: function: perf_event__header_size perf_fuzzer-2915 [006] 634.846253: function: perf_remove_from_context __perf_event_task_sched out on CPU1. If not closed would have been deleted from the swevent_hlist around here: ...-2508 [001] 634.846265: function: __perf_event_task_sched_out ...-2508 [001] 634.846270: bprint: perf_swevent_del: VMW del_rcu: 0x8800cf1b8800 Event freed: perf_fuzzer-2915 [006] 634.846280: bprint: _free_event: freeing with 0 refs; ptr=0x0x8800cef05000 perf_fuzzer-2915 [006] 634.846282: function: sw_perf_event_destroy Grace period expire: idle-0 [006] 635.138983: kfree: (free_event_rcu+0x2f) call_site=81130c3f ptr=0x8800cef05000 -- 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/
pull request: wireless 2014-05-01
Dave,
Please pull the following batch of fixes intended for the 3.15 stream!
For the Bluetooth bits, Gustavo says:
Some fixes for 3.15. There is a revert for the intel driver, a new
device id, and two important SSP fixes from Johan.
On top of that...
Ben Hutchings gives us a fix for an unbalanced irq enable in an
rtl8192cu error path.
Colin Ian King provides an rtlwifi fix for an uninitialized variable.
Felix Fietkau brings a pair of ath9k fixes, one that corrects a
hardware initialization value and another that removes an (unnecessary)
flag that was being used in a way that led to a software tx queue
hang in ath9k.
Gertjan van Wingerde pushes a MAINTAINERS change to remove himself
from the rt2x00 maintainer team.
Hans de Goede fixes a brcmfmac firmware load hang.
Larry Finger changes rtlwifi to use the correct queue for V0 traffic
on rtl8192se.
Rajkumar Manoharan corrects a race in ath9k driver initialization.
Stanislaw Gruszka fixes an rt2x00 bug in which disabling beaconing
once on USB devices led to permanently disabling beaconing for those
devices.
Tim Harvey provides fixes for a pair of ath9k issues that can lead
to soft lockups in that driver.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 22041fb05b66387b2854f789d1e1f55c7d07b4f4:
hyperv: Properly handle checksum offload (2014-04-30 16:12:23 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 812e4dafa42c18bb5d2f810dc1dcf57284a15717:
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
(2014-05-01 11:23:21 -0400)
Ben Hutchings (1):
rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()
Colin Ian King (1):
rtlwifi: rtl8188ee: initialize packet_beacon
Felix Fietkau (2):
ath9k_hw: do not lower ANI setting below default on AR913x
ath9k: remove tid-paused flag
Gertjan van Wingerde (1):
rt2x00: Remove myself as maintainer.
Hans de Goede (1):
brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to
BCMA_IOCTL
Johan Hedberg (2):
Bluetooth: Fix triggering BR/EDR L2CAP Connect too early
Bluetooth: Fix redundant encryption request for reauthentication
John W. Linville (2):
Merge branch 'for-upstream' of
git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into
for-davem
Larry Finger (1):
rtlwifi: rtl8192se: Fix regression due to commit 1bf4bbb
Marcel Holtmann (1):
Revert Bluetooth: Enable autosuspend for Intel Bluetooth device
Mohammed Habibulla (1):
Bluetooth: Add support for Lite-on [04ca:3007]
Rajkumar Manoharan (1):
ath9k: fix race in setting ATH_OP_INVALID
Stanislaw Gruszka (1):
rt2x00: fix beaconing on USB
Tim Harvey (2):
ath9k: fix possible hang on flush
ath9k: add a recv budget
MAINTAINERS| 1 -
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 5 ++---
drivers/net/wireless/ath/ath9k/ahb.c | 4
drivers/net/wireless/ath/ath9k/ani.c | 6 ++
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/debug_sta.c | 5 ++---
drivers/net/wireless/ath/ath9k/init.c | 3 +++
drivers/net/wireless/ath/ath9k/pci.c | 5 -
drivers/net/wireless/ath/ath9k/recv.c | 9 ++---
drivers/net/wireless/ath/ath9k/xmit.c | 14 +-
drivers/net/wireless/brcm80211/brcmfmac/chip.c | 5 +++--
drivers/net/wireless/rt2x00/rt2x00mac.c| 22 --
drivers/net/wireless/rtlwifi/rtl8188ee/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c| 2 +-
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 6 ++
net/bluetooth/hci_conn.c | 9 ++---
net/bluetooth/hci_event.c | 6 ++
18 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1241a73cc230..db5971f401ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7277,7 +7277,6 @@ F:drivers/video/aty/aty128fb.c
RALINK RT2X00 WIRELESS LAN DRIVER
P: rt2x00 project
M: Ivo van Doorn ivdo...@gmail.com
-M: Gertjan van Wingerde gwinge...@gmail.com
M: Helmut Schaa helmut.sc...@googlemail.com
L: linux-wirel...@vger.kernel.org
L: us...@rt2x00.serialmonkey.com (moderated for non-subscribers)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index be571fef185d..a83b57e57b63 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -82,6 +82,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3004) },
{
Re: [PATCH v4 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Hi Vivek,
Please see my comments inline.
On 30.04.2014 07:19, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Changes from v3:
- Calling usb_phy_shutdown() when exynos_ohci_phy_enable() is failing.
- Made exynos_ohci_phy_disable() return void, since its return value
did not serve any purpose.
- Calling clk_disable_unprepare() in exynos_ohci_resume() when
exynos_ohci_phy_enable() is failed.
.../devicetree/bindings/usb/exynos-usb.txt | 19 +++
drivers/usb/host/ohci-exynos.c | 128 +---
2 files changed, 132 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..a90c973 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+ One phy per port. Each port should have following entries:
+ - reg: port number on OHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings, specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings, specifying name of phy
+used by the port.
I think you don't need this property for this binding, as the PHYs are
being requested by indices (in fact only index 0 is used).
Example:
usb@1212 {
@@ -47,6 +56,16 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
Ditto.
+ status = disabled;
+ };
+
};
DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 05f00e3..f90bf9a 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -33,28 +34,122 @@ static struct hc_driver __read_mostly
exynos_ohci_hc_driver;
#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)-priv)
+#define PHY_NUMBER 3
nit: A blank line would be nice here to separate from the struct below.
By the way, doesn't the number of PHY ports depend on platform? Of
course right now the driver supports only Exynos = 4210 SoCs with the
generic PHY interface, so it might be changed in further patches.
struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
-static void exynos_ohci_phy_enable(struct device *dev)
+static int exynos_ohci_get_phy(struct device *dev,
+ struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci-phy)) {
+ ret = PTR_ERR(exynos_ohci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(dev, Failed to get usb2 phy\n);
+ exynos_ohci-phy = NULL;
I think you should keep this an ERR_PTR() and just use IS_ERR() check
further in the driver instead of checking for NULL.
+ ret = 0;
Do you need to set ret to 0 here? The code for getting generic PHYs will
either leave it unchanged when there are no port nodes defined or
overwrite it with value returned by of_property_read_u32(). In the first
case, an error code should be returned, not zero, as the driver was
unable to get any PHY.
+ } else if (ret == -EPROBE_DEFER) {
I think you could merge this case with the else clause below, as most
driver do. Moreover, since the only thing done after the fail_phy label
is
Re: [PATCH v10 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework
Hi Vivek,
I believe the same comments as for the patch for ohci-exynos apply for
this patch as well.
Best regards,
Tomasz
On 30.04.2014 07:19, Vivek Gautam wrote:
From: Kamil Debski k.deb...@samsung.com
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Changes from v9:
- Calling usb_phy_shutdown() when exynos_ehci_phy_enable() is failing.
- Made exynos_ehci_phy_disable() return void, since its return value
did not serve any purpose.
- Calling clk_disable_unprepare() in exynos_ehci_resume() when
exynos_ehci_phy_enable() is failed.
.../devicetree/bindings/usb/exynos-usb.txt | 18 +++
drivers/usb/host/ehci-exynos.c | 144 +---
2 files changed, 142 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index a90c973..126a7a9 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+ One phy per port. Each port should have following entries:
+ - reg: port number on EHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings; specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
};
OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 4d763dc..931cfc8 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
@@ -42,14 +43,119 @@
static const char hcd_name[] = ehci-exynos;
static struct hc_driver __read_mostly exynos_ehci_hc_driver;
+#define PHY_NUMBER 3
struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
+static int exynos_ehci_get_phy(struct device *dev,
+ struct exynos_ehci_hcd *exynos_ehci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ehci-phy)) {
+ ret = PTR_ERR(exynos_ehci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(dev, Failed to get usb2 phy\n);
+ exynos_ehci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+ } else {
+ exynos_ehci-otg = exynos_ehci-phy-otg;
+ }
+
+ for_each_available_child_of_node(dev-of_node, child) {
+ ret = of_property_read_u32(child, reg, phy_number);
+ if (ret) {
+ dev_err(dev, Failed to parse device tree\n);
+
Re: [RFC PATCH 2/3] of: mtd: add NAND randomizer mode retrieval
On 01/05/2014 15:16, Grant Likely wrote: On Thu, 1 May 2014 03:09:51 +0200, Boris BREZILLON b.brezillon@gmail.com wrote: Signed-off-by: Boris BREZILLON b.brezillon@gmail.com --- No commit message? Immediate NAK. Please, make sure you write a description for each and every patch. This is not optional. Future readers want to know what this patch solves and any other information you can provide without having to read the diff. My bad. I just sent a commit I forgot to rework to add a proper commit message. I'll add a commit message describing the different options for the nand-rnd-mode property and update the nand DT bindings documentation. Best Regards, Boris -- 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: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline
On Thu, Apr 17, 2014 at 12:40 AM, Clemens Ladisch clem...@ladisch.de wrote: poma wrote: Sound whispers, ??? WARNING: CPU: 3 PID: 900 at lib/dma-debug.c:593 debug_dma_assert_idle+0x159/0x1d0() snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped cacheline [cln=0x03014000] ... Mapped at: [c074ec12] debug_dma_alloc_coherent+0x22/0x70 Coherent means touching DMA mappings is allowed. Why does dma-debug complain about that? Right, but coherency does not follow copy-on-write. The check is there to catch cases where a page is COW'd while an active dma mapping on the source page is present. Sure, the write is coherent, but due to the COW it's going to the wrong page, so you are potentially missing data in the new mapping. See how NET_DMA inspired this check: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/dma/Kconfig?id=77873803363c -- 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 04/12] ARM: tegra: add MTD_SPI_NOR (new dependency for M25P80)
On 05/01/2014 12:26 AM, Brian Norris wrote: This defconfig contains the CONFIG_M25P80 symbol, which is now dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy the new dependency. Squashed into Tegra's for-3.16/defconfig branch. -- 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 05/12] ARM: lpc32xx: add MTD_SPI_NOR (new dependency for M25P80)
On 01/05/14 08:26, Brian Norris wrote: This defconfig contains the CONFIG_M25P80 symbol, which is now dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy the new dependency. Can't the CONFIG_M25P80 declare its dependency on CONFIG_MTD_SPI_NOR itself, or put CONFIG_M25P80 etc. into a submenu under CONFIG_MTD_SPI_NOR? At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol. Signed-off-by: Brian Norris computersforpe...@gmail.com Cc: Roland Stigge sti...@antcom.de Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/configs/lpc32xx_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig index 398a367ffce8..2de54c35fb47 100644 --- a/arch/arm/configs/lpc32xx_defconfig +++ b/arch/arm/configs/lpc32xx_defconfig @@ -53,12 +53,12 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_FW_LOADER is not set CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_SLC_LPC32XX=y CONFIG_MTD_NAND_MLC_LPC32XX=y +CONFIG_MTD_SPI_NOR=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=y CONFIG_BLK_DEV_RAM=y -- 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: [RFC PATCH 0/3] mtd: nand: add randomizer support
On 01/05/2014 18:34, Jason Gunthorpe wrote: On Thu, May 01, 2014 at 03:09:49AM +0200, Boris BREZILLON wrote: Hello, This series is a proposal to add support for randomizers (either software or hardware) to NAND flash controller drivers. FWIW, I think the term for reversibly combining a PRBS with data is 'scrambling', it is often used in communication systems for similar reasons - probabilisticly increasing transition density. randomizing is something else entirely :) I totally agree with you, this is not a randomizer but rather a scrambler. The reason I chose the randomizer word is that all the documents I read are talking about randomizers. But, other than I don't have any concern about changing all references to randomizer into scrambler ;-). BTW, there are security concerns here. The scrambler PRBS must not be predictable by the user, otherwise they can write data that undoes the scramble and defeat it, ie deliberately writing the last 2k of a 4k write block as all 0's after scrambling could cause the first 2k to be lost. That feels like something that could be scary .. AFAICT, the scramblers/randomizers used in NAND applications are all predictable, which means the scrambler state does not depend on the last data being scrambled. For example, the sunxi HW scrambler is using a Fibonacci LFSR [1]. Do you have any example of non predictable scrambler that are used to scramble NAND data ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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] ARM: tegra: add Tegra Note 7 device tree
On 05/01/2014 01:10 AM, Alexandre Courbot wrote:
Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
and a 720p panel.
The following features are enabled by this device tree: UART, eMMC, USB
(needs external power), PMIC, backlight, DSI panel, keys.
SD card, HDMI, charger, self-powered USB, audio, wifi, bluetooth are not
yet supported but might be by future patches (likely in that order).
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts
b/arch/arm/boot/dts/tegra114-tn7.dts
+ chosen {
+ /* TN7's bootloader's arguments need to be overridden */
+ bootargs = console=ttyS0,115200n8 console=tty1 gpt cma=128M
fbcon=rotate:2;
Do we still need the cma argument at all now? The default is now 64M in
tegra_defconfig, and 128M seems quite large.
+ host1x@5000 {
+ hdmi@5428 {
+ status = okay;
+
+ hdmi-supply = vdd_5v0_hdmi;
+ vdd-supply = vdd_3v3_hdmi;
+ pll-supply = vdd_1v05_pll;
+
+ nvidia,ddc-i2c-bus = hdmi_ddc;
+ nvidia,hpd-gpio =
+ gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH;
+ };
If HDMI doesn't work yet (per commit description), should we leave it
out of the DT for now?
+ serial@70006300 {
+ status = okay;
+ };
Is there actually an accessible UART on the board? I guess this is for
people lucky enough to have internal boards with the debug connector. If
so, this is probably fine.
--
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: [ANNOUNCE] 3.14-rt1
On Wed, 2014-04-30 at 11:48 -0400, Steven Rostedt wrote: On Wed, 30 Apr 2014 17:15:57 +0200 Mike Galbraith umgwanakikb...@gmail.com wrote: On Wed, 2014-04-30 at 11:11 -0400, Steven Rostedt wrote: Another little bug. This hunk of patches/stomp-machine-raw-lock.patch should be while (atomic_read(done.nr_todo)) @@ -647,7 +671,7 @@ int stop_machine_from_inactive_cpu(int ( ret = multi_cpu_stop(msdata); /* Busy wait for completion. */ - while (!completion_done(done.completion)) + while (!atomic_read(done.nr_todo)) ^--- that ! needs to go away I don't see this in the code. That is, there is no completion_done() in stop_machine_from_inactive_cpu(). It is already an atomic_read(). Yes, but it should read while (atomic_read(done.nr_todo)) Ah, this would have been better if you had sent a patch. I misread what you talked about. Yes, this was the culprit of my failures. After removing the '!', it worked. Hah! I knew you were just hiding, you sneaky little SOB ;-) [50661.070049] smpboot: Booting Node 0 Processor 15 APIC 0x36 [50661.142381] kvm: enabling virtualization on CPU15 [50661.142397] BUG: unable to handle kernel NULL pointer dereference at (null) [50661.142417] IP: [810922f1] wake_up_process+0x1/0x40 [50661.142420] PGD 0 [50661.142422] Oops: [#1] PREEMPT SMP [50661.142470] Modules linked in: nfsd(F) lockd(F) nfs_acl(F) auth_rpcgss(F) sunrpc(F) autofs4(F) binfmt_misc(F) edd(F) af_packet(F) bridge(F) stp(F) llc(F) cpufreq_conservative(F) cpufreq_ondemand(F) cpufreq_userspace(F) cpufreq_powersave(F) pcc_cpufreq(F) fuse(F) loop(F) md_mod(F) dm_mod(F) iTCO_wdt(F) iTCO_vendor_support(F) gpio_ich(F) vhost_net(F) macvtap(F) macvlan(F) vhost(F) tun(F) i7core_edac(F) netxen_nic(F) kvm_intel(F) joydev(F) shpchp(F) edac_core(F) hid_generic(F) kvm(F) ipmi_si(F) sr_mod(F) ipmi_msghandler(F) bnx2(F) cdrom(F) sg(F) hpilo(F) hpwdt(F) ehci_pci(F) lpc_ich(F) mfd_core(F) acpi_power_meter(F) pcspkr(F) button(F) ext4(F) jbd2(F) mbcache(F) crc16(F) usbhid(F) uhci_hcd(F) ehci_hcd(F) usbcore(F) sd_mod(F) usb_common(F) thermal(F) processor(F) scsi_dh_rdac(F) scsi_dh_alua(F) scsi_dh_emc(F) [50661.142475] scsi_dh_hp_sw(F) scsi_dh(F) ata_generic(F) ata_piix(F) libata(F) cciss(F) hpsa(F) scsi_mod(F) [50661.142479] CPU: 39 PID: 283 Comm: migration/39 Tainted: GF 3.14.2-rt1 #667 [50661.142481] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 [50661.142482] task: 880274515bb0 ti: 88027454e000 task.ti: 88027454e000 [50661.142486] RIP: 0010:[810922f1] [810922f1] wake_up_process+0x1/0x40 [50661.142487] RSP: 0018:88027454fda8 EFLAGS: 00010002 [50661.142488] RAX: 8001 RBX: 880275581eb8 RCX: [50661.142488] RDX: 81aacec0 RSI: 0100 RDI: [50661.142489] RBP: 8802772ee9b0 R08: R09: 81aacec0 [50661.142490] R10: R11: 8103d640 R12: 810f26c0 [50661.142490] R13: 880275581e88 R14: 8802772ee9b8 R15: 88027454e010 [50661.142492] FS: () GS:8802772e() knlGS: [50661.142493] CS: 0010 DS: ES: CR0: 8005003b [50661.142494] CR2: CR3: 01a0f000 CR4: 07e0 [50661.142494] Stack: [50661.142505] 880275581eb8 810f2555 880274515bb0 0005 [50661.142508] 0001 0001 0140 0001 [50661.142512] 880274515bb0 88027454e000 8802772f4020 0005 [50661.142512] Call Trace: [50661.142526] [810f2555] ? cpu_stopper_thread+0x125/0x1a0 [50661.142530] [8108ba2d] ? smpboot_thread_fn+0x23d/0x320 [50661.142533] [8108b7f0] ? smpboot_create_threads+0x70/0x70 [50661.142535] [8108b7f0] ? smpboot_create_threads+0x70/0x70 [50661.142543] [81083c32] ? kthread+0xd2/0xe0 [50661.142545] [81083b60] ? kthreadd+0x330/0x330 [50661.142553] [815337cc] ? ret_from_fork+0x7c/0xb0 [50661.142555] [81083b60] ? kthreadd+0x330/0x330 [50661.142568] Code: fd ff ff 0f 1f 80 00 00 00 00 31 d2 e9 09 fd ff ff 66 0f 1f 84 00 00 00 00 00 ba 08 00 00 00 be 0f 00 00 00 e9 f1 fc ff ff 90 53 48 8b 07 48 89 fb a8 0c 75 08 48 8b 47 08 a8 0c 74 11 be ba 06 [50661.142570] RIP [810922f1] wake_up_process+0x1/0x40 [50661.142570] RSP 88027454fda8 [50661.142571] CR2: -- 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 v3 1/9] mtd: nand: define struct nand_timings
Hi Brian, On 30/04/2014 19:51, Brian Norris wrote: Hi Boris, On Wed, Mar 12, 2014 at 07:07:36PM +0100, Boris BREZILLON wrote: + +/** + * struct nand_sdr_timings - SDR NAND chip timings + * + * This struct defines the timing requirements of a SDR NAND chip. + * These informations can be found in every NAND datasheets and the timings + * meaning are described in the ONFI specifications: + * www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf (chapter 4.15 Timing Can you remove the unicode U+200E character? Sure + * Parameters) Please document the units for these fields here. It looks like you're using picoseconds. I'll add field units (which are indeed picoseconds) to this comment. Best Regards, Boris -- 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] rwsem: Comments to explain the meaning of the rwsem's count field
It takes me a while to understand how rwsem's count field mainifest itself in different scenarios. I'm adding comments to provide a quick reference on the the rwsem's count field for each scenario where readers and writers are contending/holding the lock. Hopefully it will be useful for future maintenance of the code and for people to get up to speed on how the logic in the code works. Signed-off-by: Tim Chen tim.c.c...@linux.intel.com --- kernel/locking/rwsem-xadd.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c index 1d66e08..305c15f 100644 --- a/kernel/locking/rwsem-xadd.c +++ b/kernel/locking/rwsem-xadd.c @@ -12,6 +12,28 @@ #include linux/export.h /* + * Meaning of the rw_semaphore's count field: + * (32 bit case illustrated, similar for 64 bit) + * + * (listed in decreasing order) + * 0x000X X readers active, no writer waiting (X*ACTIVE_BIAS) + * 0x rwsem is unlocked, and no one is waiting for the lock + * 0x000X X readers active, writer and/or reader waiting. + *(X*ACTIVE_BIAS + WAITING_BIAS) + * 0x0001 (1) one writer active, nobody queued. (ACTIVE_WRITE_BIAS) + *or + *(2) one reader active, writer(s) queued. + *(WAITING_BIAS + ACTIVE_BIAS) + * 0x There are writers or readers queued but none active + *(WAITING_BIAS), a writer can try to grab the lock and + *take itself off wait list if awake. Writer who has just + *completed its task seeing this count will try to + *wake people up from wait list. + * 0xfffe0001 Writer active, readers/writer queued + *(ACTIVE_WRITE_BIAS + WAITING_BIAS) + */ + +/* * Initialize an rwsem: */ void __init_rwsem(struct rw_semaphore *sem, const char *name, -- 1.7.11.7 -- 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] parisc,metag: Do not hardcode maximum userspace stack size
+ +config MAX_STACK_SIZE_MB + int Maximum user stack size (MB) + default 80 + range 8 256 if METAG + range 8 2048 + depends on STACK_GROWSUP + help + This is the maximum stack size in Megabytes in the VM layout of user + processes when the stack grows upwards (currently only on parisc and + metag arch). The stack will be located at the highest memory address + minus the given value, unless the RLIMIT_STACK hard limit is changed + to a smaller value in which case that is used. + + A sane initial value is 80 MB. There's one final issue with this: placement of the stack only really matters on 32 bits. We have three expanding memory areas: stack, heap and maps. On 64 bits these are placed well separated from each other on 64 bits, so an artificial limit like this doesn't matter. Also, even on 32 bits, I can't help feeling we could simply layout the binary better ... the problem is we have three upward growing regions: stack, maps and heap. However, if you look at the current standard elf layout for downward growing stacks, the maps grow up from the bottom until it hits the mapped binary, the heap grows up from the mapped binary and the stack grows down from the top. You run out of memory when the stack and heap cross or when the maps hits the binary. Obviously with three upwardly growing regions, it's problematic, but we could do something like make the maps grow down (can't, unfortunately, make the heap grow down since sbrk depends on the upward behaviour). James -- 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 -V1 22/22] ext4: Add Ext4 compat richacl feature flag
On May 1, 2014, at 9:48 AM, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
wrote:
Andreas Dilger adil...@dilger.ca writes:
On Apr 27, 2014, at 10:14 AM, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
This feature flag can be used to enable richacl on
the file system. Once enabled the acl mount option
will enable richacl instead of posix acl
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6f9e6fadac04..2a0221652d79 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1274,6 +1274,30 @@ static ext4_fsblk_t get_sb_block(void **data)
return sb_block;
}
+static void enable_acl(struct super_block *sb)
+{
+#if !defined(CONFIG_EXT4_FS_POSIX_ACL) !defined(CONFIG_EXT4_FS_RICHACL)
+ return;
+#endif
+ if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
+ sb-s_flags |= MS_RICHACL;
+ sb-s_flags = ~MS_POSIXACL;
+ } else {
+ sb-s_flags |= MS_POSIXACL;
+ sb-s_flags = ~MS_RICHACL;
+ }
This should put the #ifdef around the code that is being enabled/disabled,
otherwise it just becomes dead code:
static int enable_acl(struct super_block *sb)
{
if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
#if defined(CONFIG_EXT4_FS_RICHACL)
sb-s_flags |= MS_RICHACL;
sb-s_flags = ~MS_POSIXACL;
#else
return -EOPNOTSUPP;
#endif
} else {
#if defined(CONFIG_EXT4_FS_POSIX_ACL)
sb-s_flags |= MS_POSIXACL;
sb-s_flags = ~MS_RICHACL;
#else
return -EOPNOTSUPP;
#endif
}
return 0;
}
That is too much #ifdef with no real benefit ?
The benefit is that if neither CONFIG_EXT4_FS_RICHACL nor
CONFIG_EXT4_FS_POSIX_ACL are defined there isn't unreachable code
after return at the start of the function. Some static code
analysis tools will complain about this.
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v2 08/12] ARM: marvell: add MTD_SPI_NOR (new dependency for M25P80)
On Apr 30, Brian Norris wrote: These defconfigs contain the CONFIG_M25P80 symbol, which is now dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy the new dependency. At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol. Signed-off-by: Brian Norris computersforpe...@gmail.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: Jason Cooper ja...@lakedaemon.net Acked-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com And tested the SPI is now selected (and works on Armada XP GP) using mvebu_v7_defconfig. Thanks a lot for taking care of this, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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: [RFC PATCH 0/3] mtd: nand: add randomizer support
On Thu, May 01, 2014 at 07:31:13PM +0200, Boris BREZILLON wrote: I totally agree with you, this is not a randomizer but rather a scrambler. The reason I chose the randomizer word is that all the documents I read are talking about randomizers. But, other than I don't have any concern about changing all references to randomizer into scrambler ;-). If nobody else says anything, Scrambler is at least consistent with Wikipedia.. and 'descrambler' sounds better than 'unrandomizer' :) BTW, there are security concerns here. The scrambler PRBS must not be predictable by the user, otherwise they can write data that undoes the scramble and defeat it, ie deliberately writing the last 2k of a 4k write block as all 0's after scrambling could cause the first 2k to be lost. That feels like something that could be scary .. AFAICT, the scramblers/randomizers used in NAND applications are all predictable, which means the scrambler state does not depend on the last data being scrambled. Right, I'm not surprised storage would use a synchronous scrambler, self-synchronizing scramblers make the most sense for communication.. However, with a synchronous scrambler the security concern boils down to how robust and unpredictable is the PRBS. For instance, re-using the same PRBS seed and staring point for every block is probably a bad idea. At the very least I would think the block number should be included in the per-block seed of the PRBS. And also a per-parition/device global seed.. I suspect even a properly seeded LFSR is sufficent, but by no means have I studied this :) For example, the sunxi HW scrambler is using a Fibonacci LFSR [1]. Do you have any example of non predictable scrambler that are used to scramble NAND data ? The benifit here is that the scrambled data is completely private to the driver and flash chip. So any attack on the scrambler would have to use the driver as some kind of oracle to search for synchornization. Eg running through the full keyspace of an N-Bit LFSR by writing an anti-scrambled block, reading it back and checking if it is corrupted. This is why per-block randomization of the PRBS is very important - if the attacker has only filesytems access then they don't know the block number and now have to attack the filesystem block allocator as well as the LFSR block-independent seed to generate an anti-scrambler data pattern. But that is just an off the cuff feeling. It would be smart to study it further :) Regards, Jason -- 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: [PATCHv3 resend 1/2] dt/bindings: Add the DT binding documentation for endianness
On Apr 30, 2014, at 1:52 AM, Xiubo Li li.xi...@freescale.com wrote:
Signed-off-by: Xiubo Li li.xi...@freescale.com
---
.../devicetree/bindings/endianness/endianness.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/endianness/endianness.txt
diff --git a/Documentation/devicetree/bindings/endianness/endianness.txt
b/Documentation/devicetree/bindings/endianness/endianness.txt
new file mode 100644
index 000..49458a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/endianness/endianness.txt
@@ -0,0 +1,47 @@
+Device-Tree binding for device endianness
+
+The endianness mode of CPU Device scenarios:
+IndexCPU Device Endianess flag for DT bool property
+
+1LELE -
+2LEBE 'big-endian{,-*}'
+3BEBE -
+4BELE 'little-endian{,-*}'
+
+For one device driver, which will run in different scenarios above
+on different SoCs using the devicetree, we need one way to simplify
+this.
+
+Required properties:
+- {big,little}-endian{,-*}: this is one boolean property.
+
what is the {,-*} all about?
+Examples:
+Scenario 1 : CPU in LE mode device in LE mode.
+dev: dev@40031000 {
+ compatible = name;
+ reg = 0x40031000 0x1000;
+ ...
+};
+
+Scenario 2 : CPU in LE mode device in BE mode.
+dev: dev@40031000 {
+ compatible = name;
+ reg = 0x40031000 0x1000;
+ ...
+ big-endian{,-*};
+};
+
+Scenario 3 : CPU in BE mode device in BE mode.
+dev: dev@40031000 {
+ compatible = name;
+ reg = 0x40031000 0x1000;
+ ...
+};
+
+Scenario 4 : CPU in BE mode device in LE mode.
+dev: dev@40031000 {
+ compatible = name;
+ reg = 0x40031000 0x1000;
+ ...
+ little-endian{,-*};
+};
--
1.8.4
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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] PCI/shpchp: fix a bus speed issue on hotplug
On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum marce...@redhat.com wrote: When a board is added, the shpchp driver checks if there is a mismatch between the bridge's adapter and the bus speed. If there is, it sets the subordinate speed (if there is no device on it). However, it takes the reference of the board speed from the primary bus and not from the subordinate. If the primary bus is PCI and not PCIX/PCIe, its speed is not updated and remains 0xff. As a result hotplug fails with error: Speed of bus ff and adapter 0 mismatch. It'd be cool to have a bugzilla for this with lspci and dmesg output. I'll also have to check the other hotplug drivers for similar issues, unless you've already done that. Fixed that by checking the speed against the subordinate bus. Signed-off-by: Marcel Apfelbaum marce...@redhat.com Acked-by: Michael S. Tsirkin m...@redhat.com --- drivers/pci/hotplug/shpchp_ctrl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/shpchp_ctrl.c b/drivers/pci/hotplug/shpchp_ctrl.c index 5849927..6efc2ec 100644 --- a/drivers/pci/hotplug/shpchp_ctrl.c +++ b/drivers/pci/hotplug/shpchp_ctrl.c @@ -282,8 +282,8 @@ static int board_added(struct slot *p_slot) return WRONG_BUS_FREQUENCY; } - bsp = ctrl-pci_dev-bus-cur_bus_speed; - msp = ctrl-pci_dev-bus-max_bus_speed; + bsp = ctrl-pci_dev-subordinate-cur_bus_speed; + msp = ctrl-pci_dev-subordinate-max_bus_speed; /* Check if there are other slots or devices on the same bus */ if (!list_empty(ctrl-pci_dev-subordinate-devices)) -- 1.8.3.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/
Aw: Re: [PATCH] parisc,metag: Do not hardcode maximum userspace stack size
Hi James,
I'd like to take this patch and submit upstream for v3.15, and mark for
stable.
Would that be okay with you?
[...]
How does the v2 below look?
Your patch looks good.
Thanks for cleaning it up and moving the config option to the better place.
I just tested it on parisc and it works as expected.
I'm absolutely fine if you push your version of the patch through the metag git
tree upstream.
Thanks!
Helge
From c34f0ec062ae1a2c9fca3eddbc705f6b0faf97ca Mon Sep 17 00:00:00 2001
From: Helge Deller del...@gmx.de
Date: Wed, 30 Apr 2014 23:26:02 +0200
Subject: [PATCH v2] parisc,metag: Do not hardcode maximum userspace stack
size
This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB, but make it configurable via a config option.
The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memoy layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.
This patch makes the stack size configurable and uses 80MB as default
value which has been in use during the last few years on parisc and
which didn't showed any problems yet.
This also fixes a BUG on metag if the RLIMIT_STACK hard limit is
increased beyond a safe value by root. E.g. when starting a process
after running ulimit -H -s unlimited it will then attempt to use a
stack size of the maximum 1GB which is far too big for metag's limited
user virtual address space (stack_top is usually 0x3000):
BUG: failure at fs/exec.c:589/shift_arg_pages()!
Signed-off-by: Helge Deller del...@gmx.de
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: linux-par...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: John David Anglin dave.ang...@bell.net
Cc: sta...@vger.kernel.org
---
v2 (James Hogan):
- updated description to mention BUG on metag.
- added custom range limit for METAG.
- moved Kconfig symbol to mm/Kconfig and reworded.
- fixed matag typo.
---
arch/parisc/kernel/sys_parisc.c | 6 +++---
fs/exec.c | 6 +++---
mm/Kconfig | 15 +++
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 31ffa9b55322..9f040261151e 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -72,10 +72,10 @@ static unsigned long mmap_upper_limit(void)
{
unsigned long stack_base;
- /* Limit stack size to 1GB - see setup_arg_pages() in fs/exec.c */
+ /* Limit stack size - see setup_arg_pages() in fs/exec.c */
stack_base = rlimit_max(RLIMIT_STACK);
- if (stack_base (1 30))
- stack_base = 1 30;
+ if (stack_base CONFIG_MAX_STACK_SIZE_MB*1024*1024)
+ stack_base = CONFIG_MAX_STACK_SIZE_MB*1024*1024;
return PAGE_ALIGN(STACK_TOP - stack_base);
}
diff --git a/fs/exec.c b/fs/exec.c
index 476f3ebf437e..994108cc60f3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -657,10 +657,10 @@ int setup_arg_pages(struct linux_binprm *bprm,
unsigned long rlim_stack;
#ifdef CONFIG_STACK_GROWSUP
- /* Limit stack size to 1GB */
+ /* Limit stack size */
stack_base = rlimit_max(RLIMIT_STACK);
- if (stack_base (1 30))
- stack_base = 1 30;
+ if (stack_base CONFIG_MAX_STACK_SIZE_MB*1024*1024)
+ stack_base = CONFIG_MAX_STACK_SIZE_MB*1024*1024;
/* Make sure we didn't let the argument array grow too large. */
if (vma-vm_end - vma-vm_start stack_base)
diff --git a/mm/Kconfig b/mm/Kconfig
index ebe5880c29d6..e80075979530 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -581,3 +581,18 @@ config PGTABLE_MAPPING
config GENERIC_EARLY_IOREMAP
bool
+
+config MAX_STACK_SIZE_MB
+ int Maximum user stack size (MB)
+ default 80
+ range 8 256 if METAG
+ range 8 2048
+ depends on STACK_GROWSUP
+ help
+ This is the maximum stack size in Megabytes in the VM layout of user
+ processes when the stack grows upwards (currently only on parisc and
+ metag arch). The stack will be located at the highest memory address
+ minus the given value, unless the RLIMIT_STACK hard limit is changed
+ to a smaller value in which case that is used.
+
+ A sane initial value is 80 MB.
--
--
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] PCI/shpchp: fix a bus speed issue on hotplug
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote: On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum marce...@redhat.com wrote: When a board is added, the shpchp driver checks if there is a mismatch between the bridge's adapter and the bus speed. If there is, it sets the subordinate speed (if there is no device on it). However, it takes the reference of the board speed from the primary bus and not from the subordinate. If the primary bus is PCI and not PCIX/PCIe, its speed is not updated and remains 0xff. As a result hotplug fails with error: Speed of bus ff and adapter 0 mismatch. It'd be cool to have a bugzilla for this with lspci and dmesg output. I'll also have to check the other hotplug drivers for similar issues, unless you've already done that. I'll open a BZ with the details, sure. I didn't check the other hotplug drivers, but I do plan to look into PCIe driver as part of QEMU's PCIe hotplug feature. Thanks, Marcel Fixed that by checking the speed against the subordinate bus. Signed-off-by: Marcel Apfelbaum marce...@redhat.com Acked-by: Michael S. Tsirkin m...@redhat.com --- drivers/pci/hotplug/shpchp_ctrl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/shpchp_ctrl.c b/drivers/pci/hotplug/shpchp_ctrl.c index 5849927..6efc2ec 100644 --- a/drivers/pci/hotplug/shpchp_ctrl.c +++ b/drivers/pci/hotplug/shpchp_ctrl.c @@ -282,8 +282,8 @@ static int board_added(struct slot *p_slot) return WRONG_BUS_FREQUENCY; } - bsp = ctrl-pci_dev-bus-cur_bus_speed; - msp = ctrl-pci_dev-bus-max_bus_speed; + bsp = ctrl-pci_dev-subordinate-cur_bus_speed; + msp = ctrl-pci_dev-subordinate-max_bus_speed; /* Check if there are other slots or devices on the same bus */ if (!list_empty(ctrl-pci_dev-subordinate-devices)) -- 1.8.3.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/
Re: [PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
Lee, Doug,
I've bisected a boot failure on Tegra Dalmore (which has a tps65090)
down to this patch. It started in -next 0501, so I guess Lee might
have pushed some patches out now even though the commit date is a
little while back?
The commit is:
commit 60e91b51b515b20f85697fcd397911fdb97bbdca
Author: Doug Anderson diand...@chromium.org
AuthorDate: Wed Apr 16 16:12:28 2014 -0700
Commit: Lee Jones lee.jo...@linaro.org
CommitDate: Wed Apr 23 12:34:01 2014 +0100
regulator: tps65090: Allow setting the overcurrent wait time
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Simon Glass s...@chromium.org
Acked-by: Michael Spang sp...@chromium.org
Acked-by: Sean Paul seanp...@chromium.org
Acked-by: Mark Brown broo...@kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
Panic is line 309:
303 for (num = 0; num TPS65090_REGULATOR_MAX; num++) {
304 tps_pdata = tps65090_pdata-reg_pdata[num];
305
306 ri = pmic[num];
307 ri-dev = pdev-dev;
308 ri-desc = tps65090_regulator_desc[num];
309 ri-overcurrent_wait_valid =
tps_pdata-overcurrent_wait_valid;
310 ri-overcurrent_wait = tps_pdata-overcurrent_wait;
so it looks like tps_pdata is NULL. Should likely be a check for it?
-Olof
On Wed, Apr 23, 2014 at 8:48 AM, Doug Anderson diand...@chromium.org wrote:
Lee,
On Wed, Apr 23, 2014 at 4:51 AM, Lee Jones lee.jo...@linaro.org wrote:
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
Changes in v3:
- Fixed kernel-doc notation for return
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- Now set overcurrent at probe time since it doesn't change.
.../devicetree/bindings/regulator/tps65090.txt | 4 ++
drivers/regulator/tps65090-regulator.c | 56
++
include/linux/mfd/tps65090.h | 5 ++
3 files changed, 65 insertions(+)
Applied, thanks.
U, Mark said that he had already applied this patch to his tree (I
mentioned it in my recent summary and you can see it in this thread
too). I don't see it on git.kernel.org though
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=for-next
I'm worried this will cause a merge conflict if you both apply it.
-Doug
--
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: linux-next: manual merge of the pm tree with the mips tree
On Thursday, May 01, 2014 12:09:32 PM Stephen Rothwell wrote: --Signature=_Thu__1_May_2014_12_09_32_+1000_d7zY1SkU6vg6nEQn Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Rafael, Today's linux-next merge of the pm tree got a conflict in arch/mips/loongson/lemote-2f/clock.c between commit a68ce6507a45 (MIPS/loongson2_cpufreq: Fix CPU clock rate setting) from the mips tree and commit 4966ee4037fe (mips: lemote 2f: Use cpufreq_for_each_entry macro for iteration) from the pm tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: [rfc][patch] perf,tools: Remove test_attr_* muck from perf.h
On Thu, May 01, 2014 at 10:27:30AM +0200, Peter Zijlstra wrote: Hi, I occasionally build the odd program against raw perf and use perf.h for this. Now I find that no longer works because of: 52502bf201a85 (perf tests: Add framework for automated perf_event_attr tests) So revert the hunk touching on perf.h. But but but, then you'll brake attr tests Also, it seems to be for snake shit only, and snakes stink, except on a plane :-) wanna get to lwn quotes page, huh? ;) any details about the breakage? maybe we could find some way to make you happy and keep the snake shit in place jirka -- 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 0/4] acerhdf/thermal: adding new models and appropriate governor
Hi all, Peter Feuerer writes: This patch series is intended to: * Introduce manual mode support (Patch 1 2), which is needed to control the fan of a few new models. * Add an appropriate thermal governor (Patch 3 4). Manipulating and fiddling around with the step-wise governor has been a very fragile thing in the past and as it broke again, I used the opportunity to add a two point thermal governor which implements the actual fan handling required by acerhdf and puts from my point of view things straight. Please test/review the patches and send me your comments. Further comments on the patch series? Otherwise I'll create another series containing the improvement to Javi's finding and we could get it committed? @Rui: what do you think about the bang bang governor? [...] -- kind regards, --peter; -- 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: [RFC PATCH 0/3] mtd: nand: add randomizer support
Hi Boris, On Thu, May 01, 2014 at 03:09:49AM +0200, Boris BREZILLON wrote: Hello, This series is a proposal to add support for randomizers (either software or hardware) to NAND flash controller drivers. Thanks for providing this! I'll need these features soon and I'm happy to see them coming into the nand controller framework. Antoine The last patch is the sunxi HW randomizer implementation and is just given as an example (it won't apply on the MTD tree, because it depends on other stuff not yet posted on the MTD ML, but if you want a full overview of the NAND Flash controller driver you can take a look at this series [2]). I can also provide a software implementation based on LFSR (Left Feedback Shift Register) algorithm, thought I haven't tested it yet, hence why it's not part of this series. Let me know if you're interested in this implementation. This series depends on the per-partition ECC series [1], because I need the randomizer seed to be different depending on the partition (for the same reason I needed ECC config to be different for each partition: the bootrom config might not fit the NAND chip requirements). I'd like to have feedback from both MTD maintainers and driver developers who might need to implement (or use) a randomizer in their system, so feel free to comment on this series. Best Regards, Boris [1] https://lkml.org/lkml/2014/2/12/627 [2] https://groups.google.com/forum/#!msg/linux-sunxi/s3lBb01I0Js/z2NoCFJ83g4J Boris BREZILLON (3): mtd: nand: introduce a randomizer layer in the NAND framework of: mtd: add NAND randomizer mode retrieval mtd: nand: add sunxi randomizer support drivers/mtd/nand/nand_base.c | 278 ++- drivers/mtd/nand/sunxi_nand.c | 507 +- drivers/of/of_mtd.c | 35 +++ include/linux/mtd/nand.h | 98 include/linux/of_mtd.h| 6 + 5 files changed, 858 insertions(+), 66 deletions(-) -- 1.8.3.2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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/
[GIT PULL] parisc updates for v3.15
Hi Linus, please pull the latest parisc architecture fixes for kernel 3.15 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.15-2 There are two fixes in this patchset: - Drop the architecture-specifc value for_STK_LIM_MAX to fix stack related problems with GNU make. - Make mmap() behave similiar to other architectures: If a file hasn't been mapped yet, we can now map it at any given page-aligned address. Thanks, Helge Helge Deller (2): parisc: Use generic uapi/asm/resource.h file mm,parisc: keep track of last mmap'ed address John David Anglin (1): parisc: remove _STK_LIM_MAX override arch/parisc/Kconfig | 3 +++ arch/parisc/include/uapi/asm/Kbuild | 3 ++- arch/parisc/include/uapi/asm/resource.h | 7 --- arch/parisc/kernel/sys_parisc.c | 8 include/linux/fs.h | 3 +++ mm/mmap.c | 7 ++- 6 files changed, 18 insertions(+), 13 deletions(-) delete mode 100644 arch/parisc/include/uapi/asm/resource.h -- 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] rwsem: Comments to explain the meaning of the rwsem's count field
On Thu, 2014-05-01 at 10:50 -0700, Tim Chen wrote: It takes me a while to understand how rwsem's count field mainifest itself in different scenarios. I'm adding comments to provide a quick reference on the the rwsem's count field for each scenario where readers and writers are contending/holding the lock. Hopefully it will be useful for future maintenance of the code and for people to get up to speed on how the logic in the code works. Agreed, this is nice to have. I'm planning on sending a minor set of patches for rwsem once the optistic spinning stuff is taken. To simplify things, I can take this in the series and resend along with the others. Thanks, Davidlohr -- 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/2] regulator: s5m8767: Allow GPIO 0 to be used as external control
On Wed, Apr 30, 2014 at 10:40:41AM +0200, Krzysztof Kozlowski wrote: GPIO 0 is a valid GPIO so allow using it as external control for regulator. Applied, thanks. This is only safe because we don't have any actual users of platform data - if we do have users of platform data then things get a bit more tricky since the expectation with platform data is that zero is the default/do nothing case. Really if this is an issue it is better to fix things so that GPIO 0 doesn't get used for anything, with DT there's no need to do that since the numbers are all dynamic but it does get a little more tricky in the platform data case sadly. signature.asc Description: Digital signature
Re: [PATCH 2/2] regulator: s2mps11: Allow GPIO 0 to be used as external control on S2MPS14
On Wed, Apr 30, 2014 at 10:40:42AM +0200, Krzysztof Kozlowski wrote: GPIO 0 is a valid GPIO so allow using it as external control for S2MPS14 regulators. Applied, thanks. signature.asc Description: Digital signature
Re: [BUG] kmemleak on __radix_tree_preload
On Thu, May 01, 2014 at 06:06:10PM +0100, Catalin Marinas wrote: On Fri, Apr 25, 2014 at 10:45:40AM +0900, Jaegeuk Kim wrote: 2. Bug This is one of the results, but all the results indicate __radix_tree_preload. unreferenced object 0x88002ae2a238 (size 576): comm fsstress, pid 25019, jiffies 4295651360 (age 2276.104s) hex dump (first 32 bytes): 01 00 00 00 81 ff ff ff 00 00 00 00 00 00 00 00 40 7d 37 81 ff ff ff ff 50 a2 e2 2a 00 88 ff ff @}7.P..* backtrace: [8170e546] kmemleak_alloc+0x26/0x50 [8119feac] kmem_cache_alloc+0xdc/0x190 [81378709] __radix_tree_preload+0x49/0xc0 [813787a1] radix_tree_maybe_preload+0x21/0x30 [8114bbbc] add_to_page_cache_lru+0x3c/0xc0 [8114c778] grab_cache_page_write_begin+0x98/0xf0 [a02d3151] f2fs_write_begin+0xa1/0x370 [f2fs] [8114af47] generic_perform_write+0xc7/0x1e0 [8114d230] __generic_file_aio_write+0x1d0/0x400 [8114d4c0] generic_file_aio_write+0x60/0xe0 [811b281a] do_sync_write+0x5a/0x90 [811b3575] vfs_write+0xc5/0x1f0 [811b3a92] SyS_write+0x52/0xb0 [81730912] system_call_fastpath+0x16/0x1b [] 0x Do all the backtraces look like the above (coming from add_to_page_cache_lru)? There were some changes in lib/radix-tree.c since 3.14, maybe you could try reverting them and see if the leaks still appear (cc'ing Johannes). It could also be a false positive. An issue with debugging such cases is that the preloading is common for multiple radix trees, so the actual radix_tree_node_alloc() could be on a different path. You could give the patch below a try to see what backtrace you get (it updates backtrace in radix_tree_node_alloc()). That patch makes a lot of sense to me. I applied it locally but I am unable to reproduce this with page cache heavy workloads. Jaegeuk? -- 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] mtd: Fix warning in access_ok() parameter passing
On m68k, where access_ok() doesn't cast the address parameter:
drivers/mtd/mtdchar.c: In function 'mtdchar_write_ioctl':
drivers/mtd/mtdchar.c:575:4: warning: passing argument 2 of 'access_ok' makes
pointer from integer without a cast [enabled by default]
arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but
argument is of type '__u64'
drivers/mtd/mtdchar.c:576:4: warning: passing argument 2 of 'access_ok' makes
pointer from integer without a cast [enabled by default]
arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but
argument is of type '__u64'
The address parameter of access_ok() is really a userspace pointer.
On most architectures, access_ok() is a macro that casts the address
parameter, hiding issues in its users.
Move around and use the existing usr_data and usr_oob temporary variables
to kill the warnings. Add a few consts, and make more use of the
temporaries while we're at it.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/mtd/mtdchar.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 7d4e7b9da3a1..a0f54e80670c 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -568,13 +568,18 @@ static int mtdchar_write_ioctl(struct mtd_info *mtd,
{
struct mtd_write_req req;
struct mtd_oob_ops ops;
- void __user *usr_data, *usr_oob;
+ const void __user *usr_data, *usr_oob;
int ret;
- if (copy_from_user(req, argp, sizeof(req)) ||
- !access_ok(VERIFY_READ, req.usr_data, req.len) ||
- !access_ok(VERIFY_READ, req.usr_oob, req.ooblen))
+ if (copy_from_user(req, argp, sizeof(req)))
return -EFAULT;
+
+ usr_data = (const void __user *)(uintptr_t)req.usr_data;
+ usr_oob = (const void __user *)(uintptr_t)req.usr_oob;
+ if (!access_ok(VERIFY_READ, usr_data, req.len) ||
+ !access_ok(VERIFY_READ, usr_oob, req.ooblen))
+ return -EFAULT;
+
if (!mtd-_write_oob)
return -EOPNOTSUPP;
@@ -583,10 +588,7 @@ static int mtdchar_write_ioctl(struct mtd_info *mtd,
ops.ooblen = (size_t)req.ooblen;
ops.ooboffs = 0;
- usr_data = (void __user *)(uintptr_t)req.usr_data;
- usr_oob = (void __user *)(uintptr_t)req.usr_oob;
-
- if (req.usr_data) {
+ if (usr_data) {
ops.datbuf = memdup_user(usr_data, ops.len);
if (IS_ERR(ops.datbuf))
return PTR_ERR(ops.datbuf);
@@ -594,7 +596,7 @@ static int mtdchar_write_ioctl(struct mtd_info *mtd,
ops.datbuf = NULL;
}
- if (req.usr_oob) {
+ if (usr_oob) {
ops.oobbuf = memdup_user(usr_oob, ops.ooblen);
if (IS_ERR(ops.oobbuf)) {
kfree(ops.datbuf);
--
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: [PATCHv2 8/9] ASoC: omap: rx51: Add DT support
On Mon, Apr 28, 2014 at 04:07:26PM +0200, Sebastian Reichel wrote: This patch adds device tree support to the Nokia N900 audio driver and adds documentation for the DT binding. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 08/15] ASoC: TTC DKB audio needs I2C
On Tue, Apr 29, 2014 at 07:18:29PM +0800, Xia Kaixu wrote: From: Arnd Bergmann a...@arndb.de The missing dependency can lead to build errors, so make it explicit in Kconfig. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] cpufreq: intel_pstate: Change the calculation of next pstate
On 04/29/2014 02:52 PM, Rafael J. Wysocki wrote: On Tuesday, April 29, 2014 07:34:46 PM Stratos Karafotis wrote: On 29/04/2014 07:58 πμ, Viresh Kumar wrote: Cc'd Dirk, On 28 April 2014 03:42, Stratos Karafotis strat...@semaphore.gr wrote: Currently the driver calculates the next pstate proportional to core_busy factor and reverse proportional to current pstate. Change the above method and calculate the next pstate independently of current pstate. We must mention why the change is required. Hi Viresh, Actually, I can't say that it's required. :) I just believe that calculation of next p-state should be independent from current one. In my opinion we can't scale the load across different p-states, because it's not always equivalent. For example suppose a load of 100% because of a tight for loop in the current p-state. It will be also a 100% load in any other p-state. It will be wrong if we scale the load in the calculation formula according to the current p-state. I included the test results in the change log to point out an improvement because of this patch. I will enrich more the change log as you suggested. Please do so. Also, we need to take your patch to our power lab and see if we can reproduce your results in other workloads. And I'm waiting for the intel_pstate developer Dirk Brandewie to comment. Sorry I just returned from dealing with a family emergency and am digging out of my inbox. I will run this patch through some tests. 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: [ANNOUNCE] 3.14-rt1
On Thu, 01 May 2014 19:36:18 +0200 Mike Galbraith umgwanakikb...@gmail.com wrote: On Wed, 2014-04-30 at 11:48 -0400, Steven Rostedt wrote: On Wed, 30 Apr 2014 17:15:57 +0200 Mike Galbraith umgwanakikb...@gmail.com wrote: On Wed, 2014-04-30 at 11:11 -0400, Steven Rostedt wrote: Another little bug. This hunk of patches/stomp-machine-raw-lock.patch should be while (atomic_read(done.nr_todo)) @@ -647,7 +671,7 @@ int stop_machine_from_inactive_cpu(int ( ret = multi_cpu_stop(msdata); /* Busy wait for completion. */ - while (!completion_done(done.completion)) + while (!atomic_read(done.nr_todo)) ^--- that ! needs to go away I don't see this in the code. That is, there is no completion_done() in stop_machine_from_inactive_cpu(). It is already an atomic_read(). Yes, but it should read while (atomic_read(done.nr_todo)) Ah, this would have been better if you had sent a patch. I misread what you talked about. Yes, this was the culprit of my failures. After removing the '!', it worked. Hah! I knew you were just hiding, you sneaky little SOB ;-) What's this from? A new bug that had all the patches applied? Or was this without one of the patches? -- Steve [50661.070049] smpboot: Booting Node 0 Processor 15 APIC 0x36 [50661.142381] kvm: enabling virtualization on CPU15 [50661.142397] BUG: unable to handle kernel NULL pointer dereference at (null) [50661.142417] IP: [810922f1] wake_up_process+0x1/0x40 [50661.142420] PGD 0 [50661.142422] Oops: [#1] PREEMPT SMP [50661.142470] Modules linked in: nfsd(F) lockd(F) nfs_acl(F) auth_rpcgss(F) sunrpc(F) autofs4(F) binfmt_misc(F) edd(F) af_packet(F) bridge(F) stp(F) llc(F) cpufreq_conservative(F) cpufreq_ondemand(F) cpufreq_userspace(F) cpufreq_powersave(F) pcc_cpufreq(F) fuse(F) loop(F) md_mod(F) dm_mod(F) iTCO_wdt(F) iTCO_vendor_support(F) gpio_ich(F) vhost_net(F) macvtap(F) macvlan(F) vhost(F) tun(F) i7core_edac(F) netxen_nic(F) kvm_intel(F) joydev(F) shpchp(F) edac_core(F) hid_generic(F) kvm(F) ipmi_si(F) sr_mod(F) ipmi_msghandler(F) bnx2(F) cdrom(F) sg(F) hpilo(F) hpwdt(F) ehci_pci(F) lpc_ich(F) mfd_core(F) acpi_power_meter(F) pcspkr(F) button(F) ext4(F) jbd2(F) mbcache(F) crc16(F) usbhid(F) uhci_hcd(F) ehci_hcd(F) usbcore(F) sd_mod(F) usb_common(F) thermal(F) processor(F) scsi_dh_rdac(F) scsi_dh_alua(F) scsi_dh_emc(F) [50661.142475] scsi_dh_hp_sw(F) scsi_dh(F) ata_generic(F) ata_piix(F) libata(F) cciss(F) hpsa(F) scsi_mod(F) [50661.142479] CPU: 39 PID: 283 Comm: migration/39 Tainted: GF 3.14.2-rt1 #667 [50661.142481] Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 [50661.142482] task: 880274515bb0 ti: 88027454e000 task.ti: 88027454e000 [50661.142486] RIP: 0010:[810922f1] [810922f1] wake_up_process+0x1/0x40 [50661.142487] RSP: 0018:88027454fda8 EFLAGS: 00010002 [50661.142488] RAX: 8001 RBX: 880275581eb8 RCX: [50661.142488] RDX: 81aacec0 RSI: 0100 RDI: [50661.142489] RBP: 8802772ee9b0 R08: R09: 81aacec0 [50661.142490] R10: R11: 8103d640 R12: 810f26c0 [50661.142490] R13: 880275581e88 R14: 8802772ee9b8 R15: 88027454e010 [50661.142492] FS: () GS:8802772e() knlGS: [50661.142493] CS: 0010 DS: ES: CR0: 8005003b [50661.142494] CR2: CR3: 01a0f000 CR4: 07e0 [50661.142494] Stack: [50661.142505] 880275581eb8 810f2555 880274515bb0 0005 [50661.142508] 0001 0001 0140 0001 [50661.142512] 880274515bb0 88027454e000 8802772f4020 0005 [50661.142512] Call Trace: [50661.142526] [810f2555] ? cpu_stopper_thread+0x125/0x1a0 [50661.142530] [8108ba2d] ? smpboot_thread_fn+0x23d/0x320 [50661.142533] [8108b7f0] ? smpboot_create_threads+0x70/0x70 [50661.142535] [8108b7f0] ? smpboot_create_threads+0x70/0x70 [50661.142543] [81083c32] ? kthread+0xd2/0xe0 [50661.142545] [81083b60] ? kthreadd+0x330/0x330 [50661.142553] [815337cc] ? ret_from_fork+0x7c/0xb0 [50661.142555] [81083b60] ? kthreadd+0x330/0x330 [50661.142568] Code: fd ff ff 0f 1f 80 00 00 00 00 31 d2 e9 09 fd ff ff 66 0f 1f 84 00 00 00 00 00 ba 08 00 00 00 be 0f 00 00 00 e9 f1 fc ff ff 90 53 48 8b 07 48 89 fb a8 0c 75 08 48 8b 47 08 a8 0c 74 11 be ba 06 [50661.142570] RIP [810922f1] wake_up_process+0x1/0x40 [50661.142570] RSP 88027454fda8 [50661.142571] CR2: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCHv2 7/9] ASoC: omap: rx51: Add some error messages
On Mon, Apr 28, 2014 at 04:07:25PM +0200, Sebastian Reichel wrote: Add more error messages making it easier to identify problems. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCHv2 9/9] DTS: OMAP3-N900: Add sound support
On Mon, Apr 28, 2014 at 04:07:27PM +0200, Sebastian Reichel wrote: This patch adds support for the Nokia N900's sound system. Reviewed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH 07/15] ASoC: UDA1380 needs I2C
On Tue, Apr 29, 2014 at 07:18:28PM +0800, Xia Kaixu wrote: From: Arnd Bergmann a...@arndb.de The UDA1380 driver needs I2C to be enabled, so SND_SOC_SAMSUNG_H1940_UDA1380 and SND_SOC_SAMSUNG_RX1950_UDA1380 also require this. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH part2 5/6] regulator: max14577: Implement SUSPEND mode for MAX77836 LDO-s
On Wed, Apr 23, 2014 at 04:50:39PM +0200, Krzysztof Kozlowski wrote: This patch adds support for mode REGULATOR_MODE_STANDBY (and NORMAL) to LDO regulators by implementing the set_mode() and get_mode() operations. However the necessary regulator constraints (valid modes) are not parsed by of_regulator_match() so the driver adds them manually to the regulator init_data. No, that's not the idea here. The reason that the modes need to be explicitly enabled is that there's an element of board design in determining if a given mode can satisfy the required current demand for the board with sufficient quality (usually the lower power modes have both a lower maximum current and poorer regulation accuracy especially as the current rises). Doing it unconditionally isn't in general reliable. The reason that the modes aren't supported by DT is that defining a binding is hard - it's not clear what exactly a mode means since it's basically a Linux internal thing. We probably need to explicitly add definitions of the modes to the bindings for individual devices unfortunately (ie, saying mode X maps to Y in the datasheet, possibly using the datasheet modes in the binding for ease of use and having that translation in the driver). Ideally we'd be able to have the automatic mode setting working for devices but in practice nobody wants to publish the numbers and working out how much the board needs can also be hard so that isn't really practical. signature.asc Description: Digital signature
Re: [perf] more perf_fuzzer memory corruption
OK, humor me a bit here. I'm looking at the buggy trace and comparing against a good trace where the bug doesn't happen. It is a rance condition of sorts, because it's just a 10us or so interleaving of calls that causes the bug to happen or not. In the good trace: [parent] __perf_event_task_sched_out (and hence perf_swevent_del) [child] perf_release In the buggy trace: [child] perf_release [parent] __perf_event_task_sched_out (perf_swevent_del never happens) perf_swevent_del calls hlist_del_rcu(event-hlist_entry) to remove the event from the swevent hlist. Now in theory perf_release() calls sw_perf_event_destroy() which you would think would also call the above. Instead it does swevent_hlist_put_cpu(event, cpu); which does all kinds of weird hash stuff that I don't follow. Should the above two be equivelent? Is it reference counting in there with if (!--swhash-hlist_refcount) causing the issue? Anyway I'm tired of staring at traces for the moment. Vince -- 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: [PATCHv2 5/9] ASoC: omap: rx51: omap_mcbsp_st_add_controls: add id parameter
On Mon, Apr 28, 2014 at 04:07:23PM +0200, Sebastian Reichel wrote: This is a preparation for DT based booting where the McBSP id is set to -1 for all McBSP instances. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 06/15] ASoC: RX-51 audio needs I2C
On Tue, Apr 29, 2014 at 07:18:27PM +0800, Xia Kaixu wrote: From: Arnd Bergmann a...@arndb.de The codec requires I2C to be enabled, so any other option that selects it should also depend on I2C. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/3] regulator: ltc3589: Add DT binding documentation
On Tue, Apr 29, 2014 at 06:37:09PM +0200, Philipp Zabel wrote: This patch adds the device tree binding documentation for Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-port regulators. This is all good apart from the vendor prefix change thing. signature.asc Description: Digital signature
Re: [PATCHv2 6/9] ASoC: omap: rx51: get GPIO numbers via gpiod API
On Mon, Apr 28, 2014 at 04:07:24PM +0200, Sebastian Reichel wrote: Update the driver to get GPIO numbers from the devm gpiod API instead of requesting hardcoded GPIO numbers. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 3/3] regulator: Add LTC3589 support
On Tue, Apr 29, 2014 at 06:37:10PM +0200, Philipp Zabel wrote:
This patch adds support for the Linear Technology LTC3589, LTC3589-1,
and LTC3589-2 8-output I2C voltage regulator ICs.
One small nit in addition to the vendor prefix thing:
+static const int ltc3589_12_ldo4[] = {
+ 120, 180, 250, 320,
+};
This could use regulator_map_voltage_ascend(), though for all practical
purposes the table is so small it makes no meaningful difference.
signature.asc
Description: Digital signature
Re: [PATCHv2 4/9] ASoC: Allow Aux Codecs to be specified using DT
On Mon, Apr 28, 2014 at 04:07:22PM +0200, Sebastian Reichel wrote: This patch adds support for specifying auxiliary codecs and codec configuration via device tree phandles. Applied, thanks. signature.asc Description: Digital signature
[PATCH] i2c: davinci: Add block read functionality for IPMI
Intelligent Plaform Management Interface (IPMI) requires I2C driver
to support block read, where the first byte received from slave is
the length of following data:-
Added length check if the read type is block read (I2C_M_RECV_LEN)
Send NACK/STOP bits before last byte is received
Signed-off-by: Garrett Ding g-d...@ti.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Tested-by: Garrett Ding g-d...@ti.com
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Wolfram Sang w...@the-dreams.de
CC: Santosh Shilimkar santosh.shilim...@ti.com
---
Tested on a customer board based on K2HK SoC
drivers/i2c/busses/i2c-davinci.c | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 389bc68..cd97920 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -97,6 +97,10 @@
#define DAVINCI_I2C_IMR_NACK BIT(1)
#define DAVINCI_I2C_IMR_AL BIT(0)
+/* capabilities */
+#define I2C_CAPABILITIES (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | \
+I2C_FUNC_SMBUS_READ_BLOCK_DATA)
+
struct davinci_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -318,7 +322,13 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
davinci_i2c_write_reg(dev, DAVINCI_I2C_SAR_REG, msg-addr);
dev-buf = msg-buf;
- dev-buf_len = msg-len;
+
+/* if first received byte is length, set buf_len = 0x as flag */
+ if (msg-flags I2C_M_RECV_LEN)
+ dev-buf_len = 0x;
+ else
+ dev-buf_len = msg-len;
+
dev-stop = stop;
davinci_i2c_write_reg(dev, DAVINCI_I2C_CNT_REG, dev-buf_len);
@@ -456,7 +466,7 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
static u32 i2c_davinci_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+ return I2C_CAPABILITIES;
}
static void terminate_read(struct davinci_i2c_dev *dev)
@@ -528,10 +538,32 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void
*dev_id)
case DAVINCI_I2C_IVR_RDR:
if (dev-buf_len) {
- *dev-buf++ =
- davinci_i2c_read_reg(dev,
-DAVINCI_I2C_DRR_REG);
+ *dev-buf++ = davinci_i2c_read_reg(dev,
+ DAVINCI_I2C_DRR_REG);
+ /*
+* check if the first received byte is message
+* length, i.e, I2C_M_RECV_LEN
+*/
+ if (dev-buf_len == 0x)
+ dev-buf_len = *(dev-buf - 1) + 1;
+
dev-buf_len--;
+ /*
+* send NACK/STOP bits BEFORE last byte is
+* received
+*/
+ if (dev-buf_len == 1) {
+ w = davinci_i2c_read_reg(dev,
+ DAVINCI_I2C_MDR_REG);
+ w |= DAVINCI_I2C_MDR_NACK;
+ davinci_i2c_write_reg(dev,
+ DAVINCI_I2C_MDR_REG, w);
+
+ w |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev,
+ DAVINCI_I2C_MDR_REG, w);
+ }
+
if (dev-buf_len)
continue;
--
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 v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
On Thu, May 01, 2014 at 11:17:58AM -0700, Olof Johansson wrote: so it looks like tps_pdata is NULL. Should likely be a check for it? Yes, just about to post a fix. signature.asc Description: Digital signature
Re: [PATCHv4] uprobes: simplify rip-relative handling
Thanks, I hope that Jim's ack still applies to this version.
On 05/01, Denys Vlasenko wrote:
v4: Changed arch_uprobe_xol_was_trapped() comment to reflect new logic.
Hmm. I guess you meant arch_uprobe_post_xol()... please see below.
static int default_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs
*regs)
{
struct uprobe_task *utask = current-utask;
- long correction = (long)(utask-vaddr - utask-xol_vaddr);
- riprel_post_xol(auprobe, regs, correction);
+ riprel_post_xol(auprobe, regs);
if (auprobe-def.fixups UPROBE_FIX_IP) {
+ long correction = (long)(utask-vaddr - utask-xol_vaddr);
Can't resist, I'll remove this pointless cast ;)
* If the original instruction was a rip-relative instruction such as
* movl %edx,0x(%rip), we have instead executed an equivalent
- * instruction using a scratch register -- e.g., movl %edx,(%rax).
- * We need to restore the contents of the scratch register and adjust
- * the ip, keeping in mind that the instruction we executed is 4 bytes
- * shorter than the original instruction (since we squeezed out the offset
- * field). (FIX_RIP_AX or FIX_RIP_CX)
+ * instruction using a scratch register -- e.g., movl %edx,0x(%rax).
+ * We need to restore the contents of the scratch register
+ * (FIX_RIP_AX or FIX_RIP_CX).
*/
int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
Perhaps it makes sense to move this part of the comment above
default_post_xol_op() which actually does this...
I won't insist, I do not really care because I almost never read the comments
anyway ;)
Oleg.
--
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] regulator: tps65090: Fix tps65090 crash on Tegra Dalmore
The patch (60e91b5 regulator: tps65090: Allow setting the overcurrent
wait time) introduced a crash on Tegra Dalmore. On Dalmore the device
tree doesn't have an entry for all of the FETs so it leaves tps_pdata
NULL in some cases. Add a check for NULL like the rest of the code
does.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/regulator/tps65090-regulator.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca04e9f..fbe0bf5 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -306,8 +306,11 @@ static int tps65090_regulator_probe(struct platform_device
*pdev)
ri = pmic[num];
ri-dev = pdev-dev;
ri-desc = tps65090_regulator_desc[num];
- ri-overcurrent_wait_valid = tps_pdata-overcurrent_wait_valid;
- ri-overcurrent_wait = tps_pdata-overcurrent_wait;
+ if (tps_pdata) {
+ ri-overcurrent_wait_valid =
+ tps_pdata-overcurrent_wait_valid;
+ ri-overcurrent_wait = tps_pdata-overcurrent_wait;
+ }
/*
* TPS5090 DCDC support the control from external digital input.
--
1.9.1.423.g4596e3a
--
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 v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
Mark, On Thu, May 1, 2014 at 11:49 AM, Mark Brown broo...@kernel.org wrote: On Thu, May 01, 2014 at 11:17:58AM -0700, Olof Johansson wrote: so it looks like tps_pdata is NULL. Should likely be a check for it? Yes, just about to post a fix. Doh, was working on it at the same time. https://patchwork.kernel.org/patch/4099981/ Sorry for the bug. :( Thanks for the report! -Doug -- 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] random: Add initialized variable to proc
On Thu, May 1, 2014 at 8:35 AM, Andy Lutomirski l...@amacapital.net wrote: On Thu, May 1, 2014 at 8:05 AM, ty...@mit.edu wrote: On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote: Giving the guest a seed would be highly useful, though. There are a number of ways to do that; changing the boot protocol is probably only useful if Qemu itself bouts the kernel as opposed to an in-VM bootloader. So how about simply passing a memory address and an optional offset on the boot command line? That way the hypervisor can drop the seed in some convenient real memory location, and the kernel can just copy it someplace safe, or in the case of kernel ASLR, the relocator can use it to seed its CRNG, and then after it relocates the kernel, it can crank the CRNG to pass a seed to the kernel's urandom driver. That way, we don't have to do something which is ACPI or DT dependent. Maybe there will be embedded architectures where using DT might be more convenient, but this would probably be simplest for KVM/qumu-based VM's, I would think. One problem with passing a seed in memory like this is that it provides no benefit if the guest reboots without restarting the hypervisor. Using an MSR or something avoids that issue. Passing an address in I/O space that can be read to synchronously obtain a seed would work, but it could still be messy to get the address to propagate through the booatloader and the reboot process. A CPUID leaf or an MSR advertised by a CPUID leaf has another advantage: it's easy to use in the ASLR code -- I don't think there's a real IDT, so there's nothing like rdmsr_safe available. It also avoids doing anything complicated with the boot process to allow the same seed to be used for ASLR and random.c; it can just be invoked twice on boot. Here are two easyish ways to do it: a. Add a new CPUID leaf KVM_CPUID_URANDOM = 0x4002. The existence of the leaf is signaled by KVM_CPUID_SIGNATURE.eax = 0x4002. Reading the leaf either gives all zeros to indicate that it's unsupported or disabled or it gives 256 bits of urandom-style data in rax,rbx,rcx,edx. 32-bit callers will have trouble extracting more than 128 of those 256 bits, but that should be fine. b. Add a new MSR_KVM_URANDOM and indicate support using KVM_FEATURE_URANDOM. The is cleaner, since it matches existing practice, but it's awkward to return more than 64 bits at a time from rdmsr. 128 bits is straightforward by cheating and using the high bits in rax and rdx, but that's kind of gross. Clobbering any more registers is awful, and passing a pointer into wrmsr seems overcomplicated. There's also the hypercall interface, but it looks like hyperv support can interfere with it, and I'm not sure whether the guest needs to cooperate with whatever the magical vmcall patching code is doing. What's the right forum for this? This thread is probably not it. --Andy -- 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 05/10] clk: versatile: Split config options for sp810 and vexpress_osc
Quoting Pawel Moll (2014-04-28 10:57:52) Move the Kconfig entry for Versatile ( Express) clock drivers into a separate file and add individual options for sp810 and vexpress_osc drivers, as they are optional in some configurations and may have separate dependencies. Cc: Mike Turquette mturque...@linaro.org Signed-off-by: Pawel Moll pawel.m...@arm.com Acked-by: Mike Turquette mturque...@linaro.org --- drivers/clk/Kconfig| 9 + drivers/clk/versatile/Kconfig | 26 ++ drivers/clk/versatile/Makefile | 5 +++-- 3 files changed, 30 insertions(+), 10 deletions(-) create mode 100644 drivers/clk/versatile/Kconfig diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 6f56d3a..4fdfd6c 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -30,14 +30,7 @@ config COMMON_CLK_WM831X Supports the clocking subsystem of the WM831x/2x series of PMICs from Wolfson Microlectronics. -config COMMON_CLK_VERSATILE - bool Clock driver for ARM Reference designs - depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 - ---help--- - Supports clocking on ARM Reference designs: - - Integrator/AP and Integrator/CP - - RealView PB1176, EB, PB11MP and PBX - - Versatile Express +source drivers/clk/versatile/Kconfig config COMMON_CLK_MAX77686 tristate Clock driver for Maxim 77686 MFD diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig new file mode 100644 index 000..1530c93 --- /dev/null +++ b/drivers/clk/versatile/Kconfig @@ -0,0 +1,26 @@ +config COMMON_CLK_VERSATILE + bool Clock driver for ARM Reference designs + depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 + ---help--- + Supports clocking on ARM Reference designs: + - Integrator/AP and Integrator/CP + - RealView PB1176, EB, PB11MP and PBX + - Versatile Express + +config CLK_SP810 + bool Clock driver for ARM SP810 System Controller + depends on COMMON_CLK_VERSATILE + default y if ARCH_VEXPRESS + ---help--- + Supports clock muxing (REFCLK/TIMCLK to TIMERCLKEN0-3) capabilities + of the ARM SP810 System Controller cell. + +config CLK_VEXPRESS_OSC + bool Clock driver for Versatile Express OSC clock generators + depends on COMMON_CLK_VERSATILE + depends on VEXPRESS_CONFIG + default y if ARCH_VEXPRESS + ---help--- + Simple regmap-based driver driving clock generators on Versatile + Express platforms hidden behind its configuration infrastructure, + commonly known as OSCs. diff --git a/drivers/clk/versatile/Makefile b/drivers/clk/versatile/Makefile index c16ca78..fd449f9 100644 --- a/drivers/clk/versatile/Makefile +++ b/drivers/clk/versatile/Makefile @@ -3,5 +3,6 @@ obj-$(CONFIG_ICST) += clk-icst.o obj-$(CONFIG_ARCH_INTEGRATOR) += clk-integrator.o obj-$(CONFIG_INTEGRATOR_IMPD1) += clk-impd1.o obj-$(CONFIG_ARCH_REALVIEW)+= clk-realview.o -obj-$(CONFIG_ARCH_VEXPRESS)+= clk-vexpress.o clk-sp810.o -obj-$(CONFIG_VEXPRESS_CONFIG) += clk-vexpress-osc.o +obj-$(CONFIG_ARCH_VEXPRESS)+= clk-vexpress.o +obj-$(CONFIG_CLK_SP810)+= clk-sp810.o +obj-$(CONFIG_CLK_VEXPRESS_OSC) += clk-vexpress-osc.o -- 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] watchdog: print all locks on a softlock
If the CPU hits a softlockup this patch will also have it print the information about all locks being held on the system. This might help determine if a lock is being held too long leading to this problem. Signed-off-by: Eric Paris epa...@redhat.com Cc: Frederic Weisbecker fweis...@gmail.com Cc: Andrew Morton a...@linux-foundation.org Cc: Don Zickus dzic...@redhat.com Cc: Michal Hocko mho...@suse.cz Cc: Ben Zhang be...@chromium.org --- kernel/watchdog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 516203e..a027240 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -322,6 +322,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer) current-comm, task_pid_nr(current)); print_modules(); print_irqtrace_events(current); + debug_show_all_locks(); if (regs) show_regs(regs); else -- 1.9.0 -- 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] PCI/shpchp: fix a bus speed issue on hotplug
On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote: On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote: On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum marce...@redhat.com wrote: When a board is added, the shpchp driver checks if there is a mismatch between the bridge's adapter and the bus speed. If there is, it sets the subordinate speed (if there is no device on it). However, it takes the reference of the board speed from the primary bus and not from the subordinate. If the primary bus is PCI and not PCIX/PCIe, its speed is not updated and remains 0xff. As a result hotplug fails with error: Speed of bus ff and adapter 0 mismatch. It'd be cool to have a bugzilla for this with lspci and dmesg output. I'll also have to check the other hotplug drivers for similar issues, unless you've already done that. I'll open a BZ with the details, sure. Done: https://bugzilla.kernel.org/show_bug.cgi?id=75251 If you need further details, please let me know. Thanks, Marcel I didn't check the other hotplug drivers, but I do plan to look into PCIe driver as part of QEMU's PCIe hotplug feature. Thanks, Marcel Fixed that by checking the speed against the subordinate bus. Signed-off-by: Marcel Apfelbaum marce...@redhat.com Acked-by: Michael S. Tsirkin m...@redhat.com --- drivers/pci/hotplug/shpchp_ctrl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/shpchp_ctrl.c b/drivers/pci/hotplug/shpchp_ctrl.c index 5849927..6efc2ec 100644 --- a/drivers/pci/hotplug/shpchp_ctrl.c +++ b/drivers/pci/hotplug/shpchp_ctrl.c @@ -282,8 +282,8 @@ static int board_added(struct slot *p_slot) return WRONG_BUS_FREQUENCY; } - bsp = ctrl-pci_dev-bus-cur_bus_speed; - msp = ctrl-pci_dev-bus-max_bus_speed; + bsp = ctrl-pci_dev-subordinate-cur_bus_speed; + msp = ctrl-pci_dev-subordinate-max_bus_speed; /* Check if there are other slots or devices on the same bus */ if (!list_empty(ctrl-pci_dev-subordinate-devices)) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] regulator: tps65090: Check for pdata before dereferencing
From: Mark Brown broo...@linaro.org
The per-regulator pdata is optional so we need to check that it's there
before dereferencing it. This wasn't done in regulator: tps65090: Allow
setting the overcurrent wait time, fix that.
Reported-by: Olof Johansson o...@lixom.net
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/regulator/tps65090-regulator.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca04e9f..fbe0bf5 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -306,8 +306,11 @@ static int tps65090_regulator_probe(struct platform_device
*pdev)
ri = pmic[num];
ri-dev = pdev-dev;
ri-desc = tps65090_regulator_desc[num];
- ri-overcurrent_wait_valid = tps_pdata-overcurrent_wait_valid;
- ri-overcurrent_wait = tps_pdata-overcurrent_wait;
+ if (tps_pdata) {
+ ri-overcurrent_wait_valid =
+ tps_pdata-overcurrent_wait_valid;
+ ri-overcurrent_wait = tps_pdata-overcurrent_wait;
+ }
/*
* TPS5090 DCDC support the control from external digital input.
--
1.9.2
--
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 v1] serial: uart: add hw flow control support configuration
-Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Tuesday, April 29, 2014 6:28 PM To: Karicheri, Muralidharan Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-ser...@vger.kernel.org; devicet...@vger.kernel.org; Rob Herring; Ian Campbell; Kumar Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh Subject: Re: [PATCH v1] serial: uart: add hw flow control support configuration Hi, On Tue, Apr 29, 2014 at 06:22:02PM +0100, Murali Karicheri wrote: 8250 uart driver currently supports only software assisted hw flow control. The software assisted hw flow control maintains a hw_stopped flag in the tty structure to stop and start transmission and use modem status interrupt for the event to drive the handshake signals. This is not needed if hw has flow control capabilities. This patch adds a DT attribute for enabling hw flow control for a uart port. Also skip stop and start if this flag is present in flag field of the port structure. Signed-off-by: Murali Karicheri m-kariche...@ti.com CC: Rob Herring robh...@kernel.org CC: Pawel Moll pawel.m...@arm.com CC: Mark Rutland mark.rutl...@arm.com CC: Ian Campbell ijc+devicet...@hellion.org.uk CC: Kumar Gala ga...@codeaurora.org CC: Randy Dunlap rdun...@infradead.org CC: Greg Kroah-Hartman gre...@linuxfoundation.org CC: Jiri Slaby jsl...@suse.cz CC: Santosh Shilimkar santosh.shilim...@ti.com --- - Fixed brackets around port-flags UPF_HARD_FLOW as per comments .../devicetree/bindings/serial/of-serial.txt |2 ++ drivers/tty/serial/8250/8250_core.c|6 -- drivers/tty/serial/of_serial.c |4 drivers/tty/serial/serial_core.c | 12 +--- 4 files changed, 19 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt index 1928a3e..123de01 100644 --- a/Documentation/devicetree/bindings/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/serial/of-serial.txt @@ -37,6 +37,8 @@ Optional properties: - auto-flow-control: one way to enable automatic flow control support. The driver is allowed to detect support for the capability even without this property. +- hw-flow-control: this enables pure hw flow control and no software + intervention needed. From the wording of the commit message, I believe this would be better worded something like: - hw-flow-control: the hardware has flow control capability. While the OS needs to know that flow control is present if it wishes to make use of it, whether or not the OS does so is not a matter for the binding. It might also be better worded as has-hw-flow-control, which would make that distinction clearer. Otherwise this looks fine to me. Fine. Will re-send with rewording as has-hw-flow-control: the hardware has flow control capability. Murali Thanks, Mark. -- 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/
