Re: [PATCH 3/7] mfd: db8500-prcmu: Ensure AB8500 platform data is passed through MFD Core
Hi Lee, On Fri, Jul 27, 2012 at 01:38:50PM +0100, Lee Jones wrote: When booting via platform code the AB8500 platform data is now passed in though the DB8500. However, if pdata_size is not set it will not be subsequently passed onto subordinate devices. This patch correctly populates pdata_size. Signed-off-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/db8500-prcmu.c |1 + 1 file changed, 1 insertion(+) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 4/7] mfd: ab8500-core: Apply the AB8500 CODEC's compatible string to its MFD cell
Hi Lee, On Fri, Jul 27, 2012 at 01:38:51PM +0100, Lee Jones wrote: Provide a compatible string for the AB8500 CODEC to aid in configuration property look-up from its associated Device Tree node. Signed-off-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/ab8500-core.c |1 + 1 file changed, 1 insertion(+) Applied as well. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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] n_tty: Don't lose characters when PARMRK is enabled
When PARMRK is set and large transfers of characters that will get
marked are being received, n_tty could drop data silently (i.e.
without reporting any error to the client). This is because
characters have the potential to take up to three bytes in the line
discipline (when they get marked with parity or framing errors), but
the amount of free space reported to tty_buffer flush_to_ldisc (via
tty-receive_room) is based on the pre-marked data size.
With this patch, the n_tty layer will no longer assume that each byte
will only take up one byte in the line discipline. Instead, it will
make an overly conservative estimate that each byte will take up
three bytes in the line discipline when PARMRK is set.
Signed-off-by: Jaeden Amero jaeden.am...@ni.com
---
drivers/tty/n_tty.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index
101790cea4ae45622c0628bf1833012087f9c7c5..e2473cf26d058d1de7059323fbe7a8f29fe0f74e
100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -92,10 +92,18 @@ static inline int tty_put_user(struct tty_struct *tty,
unsigned char x,
static void n_tty_set_room(struct tty_struct *tty)
{
- /* tty-read_cnt is not read locked ? */
- int left = N_TTY_BUF_SIZE - tty-read_cnt - 1;
+ int left;
int old_left;
+ /* tty-read_cnt is not read locked ? */
+ if (I_PARMRK(tty)) {
+ /* Multiply read_cnt by 3, since each byte might take up to
+* three times as many spaces when PARMRK is set (depending on
+* its flags, e.g. parity error). */
+ left = N_TTY_BUF_SIZE - tty-read_cnt * 3 - 1;
+ } else
+ left = N_TTY_BUF_SIZE - tty-read_cnt - 1;
+
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
--
1.7.11.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: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls
On Fri, 27 Jul 2012, Ian Campbell wrote:
Should this comment be by 'privcmd_call'?
When we add a 5 argument hypercall I suppose we'll see the required
push/pop of r4 added to this macro too.
For performance and simplicity I would add a second macro that push/pop
r4, only required for hypercalls with more than 4 arguments.
For clarity / documentation purposes it might actually be worthwhile to
define all of HYPERCALL{0,1,2,3,4} even if the {0,1,2,3} cases are all
just:
#define HYPERCALL0(x) HYPERCALL_SIMPLE(x)
I agree
+#define HYPERCALL(hypercall) \
+ENTRY(HYPERVISOR_##hypercall)\
+ mov r12, #__HYPERVISOR_##hypercall; \
+ xen_hvc;
\
+ mov pc, lr;
\
+ENDPROC(HYPERVISOR_##hypercall)
+
+.text
+
+HYPERCALL(xen_version);
+HYPERCALL(console_io);
+HYPERCALL(grant_table_op);
+HYPERCALL(sched_op);
+HYPERCALL(event_channel_op);
+HYPERCALL(hvm_op);
+HYPERCALL(memory_op);
+HYPERCALL(physdev_op);
+
+ENTRY(privcmd_call)
+ stmdb sp!, {r4}
+ mov r12, r0
+ mov r0, r1
+ mov r1, r2
+ mov r2, r3
+ ldr r3, [sp, #8]
+ ldr r4, [sp, #4]
+ xen_hvc
+ pop {r4}
Why not ldmdb for symmetry?
Yep, I can do that.
Actually it is just ldm or ldmia
--
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: [Xen-devel] [PATCH 03/24] xen/arm: page.h definitions
On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 26, 2012 at 04:33:45PM +0100, Stefano Stabellini wrote:
ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.
Nice, so no dealing with the P2M at all in the guest?
Nope ;-)
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
arch/arm/include/asm/xen/page.h | 77
+++
1 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/xen/page.h
diff --git a/arch/arm/include/asm/xen/page.h
b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 000..6cfe9a1
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,77 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include asm/page.h
+#include linux/pfn.h
+#include linux/types.h
+#include asm/pgtable.h
+#include xen/interface/grant_table.h
I don't if it makes such a difference, but putting the headers in sorted
order is sometimes nicer than just randomly.. But that might be just
me liking an orderly world nowadays :-)
I can do that
+
+#define pfn_to_mfn(pfn)(pfn)
+#define phys_to_machine_mapping_valid (1)
+#define mfn_to_pfn(mfn)(mfn)
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m)
PAGE_SHIFT))
+
+#define pte_mfnpte_pfn
+#define mfn_ptepfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+ phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+ phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x) ((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x) ((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+ unsigned offset = phys.paddr ~PAGE_MASK;
+ return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+ unsigned offset = machine.maddr ~PAGE_MASK;
+ return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT - MACHINE conversion */
+#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+ /* XXX: assuming it is mapped in the kernel 1:1 */
+ return virt_to_machine(vaddr);
+}
+
+/* XXX: this shouldn't be here */
So why is it here?
lookup_address shouldn't be here because it is an x86-only interface.
However both gntdev.c and xenbus_client.c call it (in PV only code paths
that are never taken in a PV on HVM guest), so in order to compile them
I have to define lookup_address.
+static inline pte_t *lookup_address(unsigned long address, unsigned int
*level)
+{
+ BUG();
+ return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+ struct gnttab_map_grant_ref *kmap_op)
+{
+ return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+ return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long
mfn)
+{
+ BUG();
+ return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_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/
[RFC patch] vm: clear swap entry before copying pte
If swap entry is cleared, we can see the reason that copying pte is interrupted. If due to page table lock held long enough, no need to increase swap count. Signed-off-by: Hillf Danton dhi...@gmail.com --- --- a/mm/memory.c Fri Jul 27 21:33:32 2012 +++ b/mm/memory.c Fri Jul 27 21:35:24 2012 @@ -971,6 +971,7 @@ again: if (add_swap_count_continuation(entry, GFP_KERNEL) 0) return -ENOMEM; progress = 0; + entry.val = 0; } if (addr != end) goto again; -- -- 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 v2] regmap: Don't lock in regmap_reinit_cache()
When bus-fast_io is set, the locking here is done with spinlocks.
This is currently true for the regmap-mmio bus implementation.
While holding a spinlock we can't go to sleep, various operations
like removing the debugfs entries or re-initializing the cache will
sleep, therefore, shift the locking up to the user.
Signed-off-by: Dimitris Papastamos d...@opensource.wolfsonmicro.com
---
V2, removed the change id that was automatically.
drivers/base/regmap/regmap.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index c241ae2..52069d2 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -659,13 +659,12 @@ EXPORT_SYMBOL_GPL(devm_regmap_init);
* new cache. This can be used to restore the cache to defaults or to
* update the cache configuration to reflect runtime discovery of the
* hardware.
+ *
+ * No explicit locking is done here, the user needs to ensure that
+ * this function will not race with other calls to regmap.
*/
int regmap_reinit_cache(struct regmap *map, const struct regmap_config *config)
{
- int ret;
-
- map-lock(map);
-
regcache_exit(map);
regmap_debugfs_exit(map);
@@ -681,11 +680,7 @@ int regmap_reinit_cache(struct regmap *map, const struct
regmap_config *config)
map-cache_bypass = false;
map-cache_only = false;
- ret = regcache_init(map, config);
-
- map-unlock(map);
-
- return ret;
+ return regcache_init(map, config);
}
EXPORT_SYMBOL_GPL(regmap_reinit_cache);
--
1.7.11.3
--
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: [Ksummit-2012-discuss] ARM mini-summit
On 07/13/12 10:18, Tony Lindgren wrote: * Kukjin Kim kgene@samsung.com [120712 15:13]: +1 same here, I'm interested in ARM mini-summit :) Yeah me too! +1 very interested and we have lot's of stuff to discuss -- Regards, Igor. -- 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 v2] regmap: Add regmap dummy driver
Add a pseudo-driver for debugging and stress-testing the
regmap/regcache APIs. A standard set of tools for working
with this driver (mainly sh scripts) will be put in a repo
at https://github.com/quantumdream/regmap-tools
Some of these tests will require one to build with
REGMAP_ALLOW_WRITE_DEBUGFS defined.
Signed-off-by: Dimitris Papastamos d...@opensource.wolfsonmicro.com
---
This is an initial implementation of the regdummy driver for regmap.
This is mainly useful for debugging/stress-testing regcache as it
removes the need for real hardware and can be done in an emulated
environment very easily.
There'll be incremental patches adding more features such as,
support for configurable volatile/readable/etc. registers via
debugfs entries.
v2 updates:
- Factored out the access to the MMIO region into a separate
function.
- Removed bogus Change-Id
drivers/base/regmap/Kconfig| 8 +
drivers/base/regmap/Makefile | 1 +
drivers/base/regmap/regmap-dummy.c | 609 +
3 files changed, 618 insertions(+)
create mode 100644 drivers/base/regmap/regmap-dummy.c
diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index 6be390b..5a1ab02 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -20,3 +20,11 @@ config REGMAP_MMIO
config REGMAP_IRQ
bool
+
+config REGMAP_DUMMY
+ tristate
+ select REGMAP_MMIO
+ help
+ Say Y or M if you want to add the regdummy driver for regmap.
+ This is a pseudo-driver used for debugging and stress-testing
+ the regmap/regcache APIs.
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 5e75d1b..c5d70f1 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o
obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o
+obj-$(CONFIG_REGMAP_DUMMY) += regmap-dummy.o
diff --git a/drivers/base/regmap/regmap-dummy.c
b/drivers/base/regmap/regmap-dummy.c
new file mode 100644
index 000..078e090
--- /dev/null
+++ b/drivers/base/regmap/regmap-dummy.c
@@ -0,0 +1,609 @@
+/*
+ * Register map access API - Dummy regmap driver
+ *
+ * Copyright 2012 Wolfson Microelectronics PLC.
+ *
+ * Author: Dimitris Papastamos d...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/uaccess.h
+#include linux/platform_device.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/debugfs.h
+#include linux/mutex.h
+#include linux/regmap.h
+
+#define DEFAULT_REGS_SIZE 1024
+
+struct regdummy_dev {
+ struct device *dev;
+ struct mutex lock;
+
+ /* Set when regdummy defaults have been modified.
+* This is useful to know so we don't reinit the
+* cache if there is no reason to do so. */
+ unsigned int dirty:1;
+
+ void *regs;
+ unsigned int regs_size;
+ unsigned int regs_size_new;
+
+ struct regmap *map;
+ struct regmap_config *config;
+ struct reg_default *regdef;
+};
+
+static struct dentry *regdummy_debugfs_root;
+
+/* Default volatile register callback, this should
+ * normally be configured by the user via a debugfs
+ * entry */
+static bool regdummy_volatile_reg(struct device *dev,
+ unsigned int reg)
+{
+ return false;
+}
+
+/* Default readable register callback, this should
+ * normally be configured by the user via a debugfs
+ * entry */
+static bool regdummy_readable_reg(struct device *dev,
+ unsigned int reg)
+{
+ return true;
+}
+
+/* Default precious register callback, this should
+ * normally be configured by the user via a debugfs
+ * entry */
+static bool regdummy_precious_reg(struct device *dev,
+ unsigned int reg)
+{
+ return false;
+}
+
+/* Calculate the length of a fixed format */
+static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
+{
+ snprintf(buf, buf_size, %x, max_val);
+ return strlen(buf);
+}
+
+static ssize_t regdummy_defaults_read_file(struct file *file, char __user
*user_buf,
+ size_t count, loff_t *ppos)
+{
+ int reg_len, val_len, tot_len;
+ size_t buf_pos = 0;
+ loff_t p = 0;
+ ssize_t ret;
+ int i;
+ struct regdummy_dev *rdevp = file-private_data;
+ struct regmap_config *config;
+ struct reg_default *regdef;
+ unsigned int val;
+ unsigned int j;
+ unsigned int regdef_num;
+ char *buf;
+
+ if (*ppos 0 || !count)
+ return -EINVAL;
+
+
Re: [PATCH 02/24] xen/arm: hypercalls
On Fri, 27 Jul 2012, Christopher Covington wrote: On 07/27/2012 05:19 AM, Ian Campbell wrote: On Thu, 2012-07-26 at 20:19 +0100, Christopher Covington wrote: Hi Stefano, On 07/26/2012 11:33 AM, Stefano Stabellini wrote: Use r12 to pass the hypercall number to the hypervisor. We need a register to pass the hypercall number because we might not know it at compile time and HVC only takes an immediate argument. You're not going to JIT assemble the appropriate HVC instruction? Darn. ;-) I admit having spent few hours thinking about how to implement a self-modifying function able to change the ISS at run time. Fortunately few hours later I was struck by common sense and I decided to follow a different direction ;-) The maximum currently defined hypercall number is 55, although there are some small gaps so there's actually more like 45 in total. It seems like it'd be reasonable to take the approach that seems to be favored for MRC/MCR instructions, using a function containing switch statement that chooses between several inline assembly instructions based off an enum passed to the function. See for example arch_timer_reg_read in arch/arm/kernel/arch_timer.c. I don't think it is feasible with this number of hypercalls, even accepting that in many cases the number will be a constant so gcc can likely optimise almost all of it away. Is there something wrong with the r12 based approach? Only that you're defining a custom interface for something that there is a potentially more standard interface for. I just wanted to double check that all the ways of using the potentially more standard interface had been explored and found to be unreasonable. Yep, thanks for helping us reviewing the code. -- 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] tcp: perform DMA to userspace only if there is a task waiting for it
Back in 2006, commit 1a2449a87b ([I/OAT]: TCP recv offload to I/OAT)
added support for receive offloading to IOAT dma engine if available.
The code in tcp_rcv_established() tries to perform early DMA copy if
applicable. It however does so without checking whether the userspace task
is actually expecting the data in the buffer.
This is not a problem under normal circumstances, but there is a corner
case where this doesn't work -- and that's when MSG_TRUNC flag to
recvmsg() is used.
If the IOAT dma engine is not used, the code properly checks whether there
is a valid ucopy.task and the socket is owned by userspace, but misses the
check in the dmaengine case.
This problem can be observed in real trivially -- for example 'tbench' is
a good reproducer, as it makes a heavy use of MSG_TRUNC. On systems
utilizing IOAT, you will soon find tbench waiting indefinitely in
sk_wait_data(), as the data have already been early-copied in
tcp_rcv_established() using dma engine.
This patch introduces the same check we are performing in the simple iovec
copy case to the IOAT case as well. It fixes the indefinite
recvmsg(MSG_TRUNC) hangs.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
net/ipv4/tcp_input.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 3e07a64..f8059f9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5475,7 +5475,10 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff
*skb,
if (tp-copied_seq == tp-rcv_nxt
len - tcp_header_len = tp-ucopy.len) {
#ifdef CONFIG_NET_DMA
- if (tcp_dma_try_early_copy(sk, skb,
tcp_header_len)) {
+ if (tp-ucopy.task == current
+ sock_owned_by_user(sk)
+ tcp_dma_try_early_copy(sk,
+ skb, tcp_header_len)) {
copied_early = 1;
eaten = 1;
}
--
Jiri Kosina
SUSE Labs
--
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/
[1/3][PATCH][v2] Adding documentation for TDM
From: Sandeep Singh sand...@freescale.com tdm-summary.txt contains general description about TDM. tdm-framework.txt contains specific description of TDM framework. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- Changes since v1: Incorporated Laight's comments. -Removed reference to unused config. Documentation/tdm/tdm-framework.txt | 258 +++ Documentation/tdm/tdm-summary.txt | 103 ++ 2 files changed, 361 insertions(+), 0 deletions(-) create mode 100644 Documentation/tdm/tdm-framework.txt create mode 100644 Documentation/tdm/tdm-summary.txt diff --git a/Documentation/tdm/tdm-framework.txt b/Documentation/tdm/tdm-framework.txt new file mode 100644 index 000..f96189a --- /dev/null +++ b/Documentation/tdm/tdm-framework.txt @@ -0,0 +1,258 @@ +This document gives an overview of TDM framework and its interface with low +level drivers and upper level users/clients. + +Terminology: + +1. TDM: Time Division Multiplexing. +2. TDM channel: The channel is the smallest entity on which all the TDM read/ + write operations will occur. Technically each channel maps to a set of + consecutive time slots on the physical TDM frame. The channels will be + dynamically created and destroyed using tdm_open_channel and + tdm_close_channel. +3. TDM adapter or Adapter: Refers to an instance of TDM controller/device on + the system. +4. TDM frame: Is a set of TDM channels which is transmitted sequentially over + time. The frame start is identified by a frame sync signal that is briefly + asserted at the beginning of each frame. + +X--TDM Frame 0-X--TDM Frame 1-X +||||||||||||||| +| 0 | 1 | 2 | 3 | 4 | ...| n | 0 | 1 | 2 | 3 | 4 | ...| n |... +||||||||||||||| + +ch 0 ch 0 + +4. TDM client: Application/driver which registers with TDM framework to use TDM + device. +5. TDM port: It can be seen as a virtual device exposed to a client. At a time + TDM port can work in one of the follwing configurations: + full/fractional/E1/T1/raw. + +TDM modes + +A TDM device can operate in one of the following modes: +1. Single port full mode - Single user/no interleaving +2. Single port channelised mode (raw, E1, T1)- many users using different + channels +3. Single port fractional mode - +4. Multi port mode - multiple users using different ports in different + configurations. + +All the above configurations differ in number of TDM client they support, +number of TDM channels and number of TDM ports. + +Currently we are supporting only single port channelised mode. Hence all the +explanations below refer to channelised mode of TDM. This framework can be +easily extended to support other modes. + +Single port Channelised Mode +== +In single port channelised mode there can be only one port and each channel +can have only one time slot.The number of active channels can be less than +the maximum supported channels/slots. + +X--TDM Frame 0-X--TDM Frame 1-X +||||||||||||||| +| 0 | 1 | 2 | 3 | 4 | ...| n | 0 | 1 | 2 | 3 | 4 | ...| n |... +||||||||||||||| +--- +ch 0 ch1ch 0 +client0 client1 + +TDM Subsystem Overview + + +|---| +|user mode TDM clients | +|---| + || +--- + tdm-dev.c || + || + || || + client register | kernel mode TDM clients| + || || + || || + || || + || client register + || || + \/ \/ + __ + | | + | client interface | + || + | TDM Subsystem Framework | + | (tdm-core.c) | + || + | -buffer handling
[3/3][PATCH][v2] Added TDM device support and Freescale Starlite driver
From: Sandeep Singh sand...@freescale.com Freescale TDM controller consists of a TDM module supporting 128 channels running at up to 50 Mbps with 8-bit and 16-bit word size. The TDM bus connects gluelessly to most T1/E1 frames as well as to common buses such as the H.110, SCAS, and MVIP. TDM also supports an I2S mode. The TDM module operates in independent or shared mode when receiving or transmitting data. This controller is available on MPC8315, P1010, P1020, P1022 and P1024 Freescale SOCs. The driver registers itself with the TDM Framework provides TDM functionality to the client modules. In its present form this driver supports only channelised mode. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- Based on: git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git Branch: master Checkpatch: passed First patch version was RFC Changes from RFC: - Enabling Tx FIFO for TDM - Removed unused variables. - PMUXCR has been removed as it is taken care by u-boot Incorporated Timur's comments: - Improved Copyright statement. - Removed unused function. - Introduced read after each write to register - Used spin_event_timeout for polling - Removed unused spinlock - Moved all macros and structures from header file to tdm_fsl.c - Rectified cosmetic problems. drivers/tdm/Kconfig |3 - drivers/tdm/Makefile |2 +- drivers/tdm/device/Kconfig | 15 + drivers/tdm/device/Makefile |9 + drivers/tdm/device/tdm_fsl.c | 1186 ++ 5 files changed, 1211 insertions(+), 4 deletions(-) create mode 100644 drivers/tdm/device/Kconfig create mode 100644 drivers/tdm/device/Makefile create mode 100644 drivers/tdm/device/tdm_fsl.c diff --git a/drivers/tdm/Kconfig b/drivers/tdm/Kconfig index 0b0fda8..69b8987 100644 --- a/drivers/tdm/Kconfig +++ b/drivers/tdm/Kconfig @@ -13,6 +13,3 @@ menuconfig TDM This TDM support can also be built as a module. If so, the module will be called tdm-core. -if TDM - -endif # TDM diff --git a/drivers/tdm/Makefile b/drivers/tdm/Makefile index 84e2cb9..a605b3d 100644 --- a/drivers/tdm/Makefile +++ b/drivers/tdm/Makefile @@ -2,4 +2,4 @@ # Makefile for the TDM core. # -obj-$(CONFIG_TDM) += tdm-core.o +obj-$(CONFIG_TDM) += tdm-core.o device/ diff --git a/drivers/tdm/device/Kconfig b/drivers/tdm/device/Kconfig new file mode 100644 index 000..9fd1b06 --- /dev/null +++ b/drivers/tdm/device/Kconfig @@ -0,0 +1,15 @@ +# +# TDM device configuration +# + +menu TDM Device support + +config TDM_FSL +tristate Driver for Freescale TDM controller +depends on FSL_SOC +---help--- + This is a driver for Freescale TDM controller. The controller + is found in various Freescale SOCs viz MPC8315, P1020. The TDM driver + basically multiplexes and demultiplexes data from different channels. + The TDM can interface SLIC kind of devices. +endmenu diff --git a/drivers/tdm/device/Makefile b/drivers/tdm/device/Makefile new file mode 100644 index 000..4156d7f --- /dev/null +++ b/drivers/tdm/device/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the TDM device drivers. +# + +obj-y += tdm_fsl.o + +#ifeq ($(CONFIG_TDM_DEBUG_BUS),y) +#EXTRA_CFLAGS += -DDEBUG +#endif diff --git a/drivers/tdm/device/tdm_fsl.c b/drivers/tdm/device/tdm_fsl.c new file mode 100644 index 000..040b0ea --- /dev/null +++ b/drivers/tdm/device/tdm_fsl.c @@ -0,0 +1,1186 @@ +/* + * Copyright 2007-2012 Freescale Semiconductor, Inc, All rights reserved. + * + * TDM driver for Freescale TDM controller. + * This driver can interface with SLIC device to run VOIP kind of + * applications. + * + * Author: P. V. Suresh p...@freescale.com + * Hemant Agrawal hem...@freescale.com + * Rajesh Gumasta rajesh.guma...@freescale.com + * + * Modifier: Sandeep Kr. Singh sand...@freescale.com + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + * + * 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, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* + * Note that this is a complete rewrite of P.V. Suresh's driver code. + * But we have used so much of his original code and ideas that it seems + * only fair to recognize him as co-author -- Rajesh Hemant + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/sched.h
[2/3][PATCH][v2] TDM Framework
From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Beneath, the framework layer can house different types of TDM drivers to handle various TDM devices, the hardware intricacies of the devices being completely taken care by TDM drivers. This framework layer will allow any type of TDM device to hook with it. For example Freescale controller as on MPC8315, UCC based TDM controller, etc The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer management. In future this Framework will be extended to provide Interface for Line control devices also. For example SLIC, E1/T1 Framers etc. Presently the framework supports only Single Port channelised mode. Also the configurability options are limited which will be extended later on. Only kernel mode TDM clients are supported currently. Support for User mode clients will be added later. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Hemant Agrawal hem...@freescale.com Signed-off-by: Rajesh Gumasta rajesh.guma...@freescale.com --- Based on: git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git Branch: master Checkpatch: passed Changes since v1: Incorporated Timur's comments: - Removed unnecessary includes - Comment format and error prints are more homogenous now. - Removed unnecessary declarations. - Corrected return code value - Called missing module_put() Changes since RFC: - Since all read/write operations are in TDM are channel based, polling on TDM channel for data instead of TDM port before going for read/write. - Also corrected a faulty error leg - Removed unused function tdm_port_get_wait_queue. Incorporated Scott's comments: - Removed TDM_CORE_DEBUG. - Added sysfs knob to change use_latest_tdm_data at runtime. - Works more silently now (lesser prints). - Cosmetic errors rectified. - Removed unused function tdm_init. - Removed unused variables. - Removed unnecessary typecast and NULL check. - Removed #include device/tdm_fsl.h. Incorporated Timur's comments: - Handled errors. - Used dev_err instead of pr_err - Removed extern from function declaration. drivers/Kconfig |1 + drivers/Makefile|1 + drivers/tdm/Kconfig | 18 + drivers/tdm/Makefile|5 + drivers/tdm/tdm-core.c | 1087 +++ include/linux/mod_devicetable.h | 11 + include/linux/tdm.h | 389 ++ 7 files changed, 1512 insertions(+), 0 deletions(-) create mode 100644 drivers/tdm/Kconfig create mode 100644 drivers/tdm/Makefile create mode 100644 drivers/tdm/tdm-core.c create mode 100644 include/linux/tdm.h diff --git a/drivers/Kconfig b/drivers/Kconfig index 5afe5d1..abd6c83 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -136,4 +136,5 @@ source drivers/virt/Kconfig source drivers/devfreq/Kconfig +source drivers/tdm/Kconfig endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 1b31421..7cb88e3 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -104,6 +104,7 @@ obj-$(CONFIG_INFINIBAND)+= infiniband/ obj-$(CONFIG_SGI_SN) += sn/ obj-y += firmware/ obj-$(CONFIG_CRYPTO) += crypto/ +obj-$(CONFIG_TDM) += tdm/ obj-$(CONFIG_SUPERH) += sh/ obj-$(CONFIG_ARCH_SHMOBILE)+= sh/ ifndef CONFIG_ARCH_USES_GETTIMEOFFSET diff --git a/drivers/tdm/Kconfig b/drivers/tdm/Kconfig new file mode 100644 index 000..0b0fda8 --- /dev/null +++ b/drivers/tdm/Kconfig @@ -0,0 +1,18 @@ +# +# TDM subsystem configuration +# + +menuconfig TDM + tristate TDM support + ---help--- + More information is contained in the directory file:Documentation/tdm/, + especially in the file called summary there. + If you want TDM support, you should say Y here and also to the + specific driver for your bus adapter(s) below. + + This TDM support can also be built as a module. If so, the module + will be called tdm-core. + +if TDM + +endif # TDM diff --git a/drivers/tdm/Makefile b/drivers/tdm/Makefile new file mode 100644 index 000..84e2cb9 --- /dev/null +++ b/drivers/tdm/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the TDM core. +# + +obj-$(CONFIG_TDM) += tdm-core.o diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file mode 100644 index 000..c633190 --- /dev/null +++
Re: [Xen-devel] [PATCH 17/24] xen: allow privcmd for HVM guests
On Fri, 27 Jul 2012, Jan Beulich wrote:
On 26.07.12 at 17:33, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
In order for privcmd mmap to work correctly, xen_remap_domain_mfn_range
needs to be implemented for HVM guests.
If it is not, mmap is going to fail later on.
Somehow, for me at least, this description doesn't connect to the
actual change.
We can remove the return -ENOSYS from privcmd_mmap but the actual mmap
is still not going to work unless xen_remap_domain_mfn_range is
implemented correctly.
The x86 implementation of xen_remap_domain_mfn_range is PV only so it is
not going to work for HVM or auto_translated_physmap guests.
As a result mmap_batch_fn is going to fail.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
drivers/xen/privcmd.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..85226cb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -380,10 +380,6 @@ static struct vm_operations_struct privcmd_vm_ops = {
static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
- /* Unsupported for auto-translate guests. */
- if (xen_feature(XENFEAT_auto_translated_physmap))
- return -ENOSYS;
-
Is this safe on x86?
It is safe in the sense that is not going to crash dom0 or the
hypervisor, but it is not going to work.
Actually in order for it to be safe we need this additional change:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3a73785..885a223 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2310,6 +2310,9 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long range;
int err = 0;
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return -EINVAL;
+
prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
BUG_ON(!((vma-vm_flags (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
--
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: [2/3][PATCH][v2] TDM Framework
From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Please don't use TLAs (Three Letter Acronyms) like TDM without explaining the clearly and up front. It makes it hard for anyone else who doens't know your code to look it over without having to spend lots of time poking around to figure it out from either context or somewhere else. John -- 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 3/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
dma_buf[offset] = value has been met, accounting for wraparound.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/Makefile |2 -
drivers/base/dma-bikeshed-fence.c | 44 +
include/linux/dma-bikeshed-fence.h | 92
3 files changed, 137 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/dma-bikeshed-fence.c
create mode 100644 include/linux/dma-bikeshed-fence.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6e9f217..1e7723b 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-bikeshed-fence.c
b/drivers/base/dma-bikeshed-fence.c
new file mode 100644
index 000..fa063e8
--- /dev/null
+++ b/drivers/base/dma-bikeshed-fence.c
@@ -0,0 +1,44 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include linux/dma-bikeshed-fence.h
+
+static int enable_signaling(struct dma_fence *fence)
+{
+ struct dma_bikeshed_fence *bikeshed_fence = to_bikeshed_fence(fence);
+ return bikeshed_fence-enable_signaling(bikeshed_fence);
+}
+
+static void bikeshed_release(struct dma_fence *fence)
+{
+ struct dma_bikeshed_fence *f = to_bikeshed_fence(fence);
+
+ if (f-release)
+ f-release(f);
+ dma_buf_put(f-sync_buf);
+}
+
+struct dma_fence_ops dma_bikeshed_fence_ops = {
+ .enable_signaling = enable_signaling,
+ .release = bikeshed_release
+};
+EXPORT_SYMBOL_GPL(dma_bikeshed_fence_ops);
diff --git a/include/linux/dma-bikeshed-fence.h
b/include/linux/dma-bikeshed-fence.h
new file mode 100644
index 000..4f19801
--- /dev/null
+++ b/include/linux/dma-bikeshed-fence.h
@@ -0,0 +1,92 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __DMA_BIKESHED_FENCE_H__
+#define __DMA_BIKESHED_FENCE_H__
+
+#include linux/types.h
+#include linux/dma-fence.h
+#include linux/dma-buf.h
+
+struct dma_bikeshed_fence {
+ struct dma_fence base;
+
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+ uint32_t seqno;
+
+ int (*enable_signaling)(struct dma_bikeshed_fence *fence);
+ void (*release)(struct dma_bikeshed_fence *fence);
+};
+
+/*
+ * TODO does it make sense to be able to enable dma-fence without dma-buf,
+ * or visa versa?
+ */
+#ifdef CONFIG_DMA_SHARED_BUFFER
+
+extern struct dma_fence_ops dma_bikeshed_fence_ops;
+
+static inline bool is_bikeshed_fence(struct dma_fence *fence)
+{
+ return fence-ops == dma_bikeshed_fence_ops;
+}
+
+static
[RFC PATCH 2/3] dma-buf-mgr: multiple dma-buf synchronization (v2)
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com dma-buf-mgr handles the case of reserving single or multiple dma-bufs while trying to prevent deadlocks from buffers being reserved simultaneously. For this to happen extra functions have been introduced: + dma_buf_reserve() + dma_buf_unreserve() + dma_buf_wait_unreserved() Reserve a single buffer, optionally with a sequence to indicate this is part of a multi-dmabuf reservation. This function will return -EDEADLK and return immediately if reserving would cause a deadlock. In case a single buffer is being reserved, no sequence is needed, otherwise please use the dmabufmgr calls. If you want to attach a exclusive dma-fence, you have to wait until all shared fences have signalled completion. If there are none, or if a shared fence has to be attached, wait until last exclusive fence has signalled completion. The new fence has to be attached before unreserving the buffer, and in exclusive mode all previous fences will have be removed from the buffer, and unreffed when done with it. dmabufmgr methods: + dmabufmgr_reserve_buffers() This function takes a linked list of dmabufmgr_validate's, each one requires the following members to be set by the caller: - validate-head, list head - validate-bo, must be set to the dma-buf to reserve. - validate-shared, set to true if opened in shared mode. - validate-priv, can be used by the caller to identify this buffer. This function will then set the following members on succesful completion: - validate-num_fences, amount of valid fences to wait on before this buffer can be accessed. This can be 0. - validate-fences[0...num_fences-1] fences to wait on + dmabufmgr_backoff_reservation() This can be used when the caller encounters an error between reservation and usage. No new fence will be attached and all reservations will be undone without side effects. + dmabufmgr_fence_buffer_objects Upon successful completion a new fence will have to be attached. This function releases old fences and attaches the new one. + dmabufmgr_wait_completed_cpu A simple cpu waiter convenience function. Waits until all fences have signalled completion before returning. --- drivers/base/Makefile |3 - drivers/base/dma-buf-mgr.c | 230 +++ drivers/base/dma-buf.c | 113 + drivers/base/dma-fence.c|1 include/linux/dma-buf-mgr.h | 97 ++ include/linux/dma-buf.h | 31 ++ include/linux/dma-fence.h |2 7 files changed, 475 insertions(+), 2 deletions(-) create mode 100644 drivers/base/dma-buf-mgr.c create mode 100644 include/linux/dma-buf-mgr.h diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 1e7723b..819281a 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -10,7 +10,8 @@ obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-buf-mgr.o \ + dma-bikeshed-fence.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER)+= firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf-mgr.c b/drivers/base/dma-buf-mgr.c new file mode 100644 index 000..71b5f96 --- /dev/null +++ b/drivers/base/dma-buf-mgr.c @@ -0,0 +1,230 @@ +/* + * Copyright (C) 2012 Canonical Ltd + * + * Based on ttm_bo.c which bears the following copyright notice, + * but is dual licensed: + * + * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA + * All Rights Reserved. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the + * Software), to deal in the Software without restriction, including + * without limitation the rights to use, copy, modify, merge, publish, + * distribute, sub license, and/or sell copies of the Software, and to + * permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portions + * of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE + * USE OR OTHER DEALINGS IN THE SOFTWARE. + * + **/
[RFC PATCH 1/3] dma-fence: dma-buf synchronization (v5)
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence.
+ dma_fence_signal()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.
The one pending on the fence can add an async callback (and optionally
cancel it.. for example, to recover from GPU hangs):
+ dma_fence_add_callback()
+ dma_fence_cancel_callback()
Or wait synchronously (optionally with timeout or from atomic context):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence-ops == bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, fence_buf, offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
---
drivers/base/Makefile |2
drivers/base/dma-fence.c | 317 +
include/linux/dma-fence.h | 123 +
3 files changed, 441 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/dma-fence.c
create mode 100644 include/linux/dma-fence.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..6e9f217 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
new file mode 100644
index 000..6798dc4
--- /dev/null
+++ b/drivers/base/dma-fence.c
@@ -0,0 +1,317 @@
+/*
+ * Fence mechanism for dma-buf to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark
Re: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls
On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabellini wrote: +/** + * hypercall.h + * + * Linux-specific hypervisor handling. + * + * Stefano Stabellini stefano.stabell...@eu.citrix.com, Citrix, 2012 + * + * 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; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the Software), to deal in the Software without Erm, is that an additional restriction on the GPL which prevents me from shipping this code on a CD and charging for the act of creating the CD and shipping it? That would technically make the above statement incompatible with the GPL. -- 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] fs/direct-io.c: Set bi_rw when alloc bio.
majianpeng majianp...@gmail.com writes: When exec bio_alloc, the bi_rw is zero.But after calling bio_add_page, it will use bi_rw. Fox example, in functiion __bio_add_page,it will call merge_bvec_fn(). The merge_bvec_fn of raid456 will use the bi_rw to judge the merge. if ((bvm-bi_rw 1) == WRITE) return biovec-bv_len; /* always allow writes to be mergeable */ Signed-off-by: Jianpeng Ma majianp...@gmail.com Good catch. How did you find this? Did you experience data corruption as a result of this oversight, reduced performance due to missed merge opportunities, or did you just notice it in reviewing the code? Reviewed-by: Jeff Moyer jmo...@redhat.com There are many place like this in kernel.If you think this patch ok, i will correct those. --- fs/direct-io.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index 1faf4cb..77f0bbf 100644 --- a/fs/direct-io.c +++ b/fs/direct-io.c @@ -349,6 +349,7 @@ dio_bio_alloc(struct dio *dio, struct dio_submit *sdio, bio-bi_bdev = bdev; bio-bi_sector = first_sector; + bio-bi_rw = dio-rw; if (dio-is_async) bio-bi_end_io = dio_bio_end_aio; else -- 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 13/24] xen/arm: get privilege status
On Fri, 27 Jul 2012, Ian Campbell wrote: On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote: Use Xen features to figure out if we are privileged. XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- arch/arm/xen/enlighten.c |7 +++ include/xen/interface/features.h |3 +++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index dc68074..2e013cf 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -2,6 +2,7 @@ #include xen/interface/xen.h #include xen/interface/memory.h #include xen/platform_pci.h +#include xen/features.h #include asm/xen/hypervisor.h #include asm/xen/hypercall.h #include linux/module.h @@ -58,6 +59,12 @@ int __init xen_guest_init(void) } xen_domain_type = XEN_HVM_DOMAIN; + xen_setup_features(); + if (xen_feature(XENFEAT_dom0)) + xen_start_info-flags |= SIF_INITDOMAIN|SIF_PRIVILEGED; + else + xen_start_info-flags = ~(SIF_INITDOMAIN|SIF_PRIVILEGED); What happens here on platforms prior to hypervisor changeset 23735? It wouldn't work. Considering that we are certainly not going to backport ARM support to Xen 4.1, and that both ARM and XENFEAT_dom0 will be present in Xen 4.2, do we really need to support the Xen unstable changesets between ARM was introduced and XENFEAT_dom0 appeared? -- 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] NTFS code doesn't sanitize folder names sufficiently
On Thu, 2012-07-26 at 20:18 +0200, Marian Beermann wrote: Hello everyone, today I noticed some very odd behaviour, which could lead people to believe a loss of data, because it is possible to create directories with backslashes in them. I am currently running kernel 3.5. To completly reproduce the problem to the full extend you'll need a Windows computer, but to see whats wrong Linux completly suffices :-) On a Linux computer 1. Create a directory named TestA on an NTFS partition 2. Create a subdirectory of TestA named TestB 3. Create a third directory alongside TestA named TestA\TestB (the fundamental problem is this: backslashes in directory names) If you're writing new directories to an NTFS partition, it's very probable that you're not actually using the in-kernel NTFS driver at all. It's more likely that you have the userspace (FUSE) NTFS driver instead: http://www.tuxera.com/community/ntfs-3g-download/ In fact, they have a FAQ about it the issue that you're seeing: http://www.tuxera.com/community/ntfs-3g-faq/#posixfilenames2 You use the 'windows_names' mount option to disable creating file and directory names that confuse windows. Linux itself (and most native Linux programs) has no issues with directory names containing the '\' character, of course; the only characters that you cannot use are '/' and ASCII NUL, 0x00. -- Calvin Walton calvin.wal...@kepstin.ca -- 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: [GIT PULL] New TPM driver and features
Hi, On Thu, Jul 26, 2012 at 02:46:25PM -0700, H. Peter Anvin wrote: On 07/26/2012 07:31 AM, Kent Yoder wrote: hw_random: add support for the TPM chip as a hardware RNG source Could you clarify this? rngd (the user of /dev/hw_random) already has support for the TPM... is this fundamentally different (e.g. can it coexist with tcsd being in use at the same time)? These can coexist at the same time since /dev/tpm0 is only opened once from user-space (from tcsd) and this hwrng driver comes in through the kernel. There would be some amount of contention with the tpm, but its not likely to be noticable - grabbing rng data doesn't require any state in the tpm, like an auth session or key loading. Since the rngd support for the tpm requires trousers, this patch will be useful in places where you don't want to have to deploy the full TSS, like embedded and early boot. Kent -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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 13/24] xen/arm: get privilege status
On Fri, 2012-07-27 at 15:25 +0100, Stefano Stabellini wrote: On Fri, 27 Jul 2012, Ian Campbell wrote: On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote: Use Xen features to figure out if we are privileged. XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- arch/arm/xen/enlighten.c |7 +++ include/xen/interface/features.h |3 +++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index dc68074..2e013cf 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -2,6 +2,7 @@ #include xen/interface/xen.h #include xen/interface/memory.h #include xen/platform_pci.h +#include xen/features.h #include asm/xen/hypervisor.h #include asm/xen/hypercall.h #include linux/module.h @@ -58,6 +59,12 @@ int __init xen_guest_init(void) } xen_domain_type = XEN_HVM_DOMAIN; + xen_setup_features(); + if (xen_feature(XENFEAT_dom0)) + xen_start_info-flags |= SIF_INITDOMAIN|SIF_PRIVILEGED; + else + xen_start_info-flags = ~(SIF_INITDOMAIN|SIF_PRIVILEGED); What happens here on platforms prior to hypervisor changeset 23735? It wouldn't work. Considering that we are certainly not going to backport ARM support to Xen 4.1, and that both ARM and XENFEAT_dom0 will be present in Xen 4.2, do we really need to support the Xen unstable changesets between ARM was introduced and XENFEAT_dom0 appeared? Sorry, I missed the arm in the path. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/watchdog.c : fix smp_processor_id() warning
On Fri, Jul 27, 2012 at 08:38:21AM +0800, Ming Lei wrote: On Fri, Jul 27, 2012 at 3:43 AM, Don Zickus dzic...@redhat.com wrote: On Wed, Jul 25, 2012 at 12:39:45PM +0800, Ming Lei wrote: Use raw_smp_processor_id in lockup_detector_bootcpu_resume() because it is enough when non-boot CPUs are offline. This patch fixes the following warning when DEBUG_PREEMPT is enabled. Is this patched on top of linux-next? Yes. The warning is introduced by the commit below: 7fb860ff90ae970cf62cf676dfc1addcf8415674 (NMI watchdog: fix for lockup detector breakage on resume) Ok, so I can respin this to give my SoB, if Andrew wants. But at the same time this patch will become obsolete (or broken) with tglx's hotplug infrastructure changes. Not sure what to do here. Andrew? Cheers, Don -- 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: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls
On Fri, 27 Jul 2012, Russell King - ARM Linux wrote: On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabellini wrote: +/** + * hypercall.h + * + * Linux-specific hypervisor handling. + * + * Stefano Stabellini stefano.stabell...@eu.citrix.com, Citrix, 2012 + * + * 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; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the Software), to deal in the Software without Erm, is that an additional restriction on the GPL which prevents me from shipping this code on a CD and charging for the act of creating the CD and shipping it? That would technically make the above statement incompatible with the GPL. IMNAL but this is just an alternative, less strict, MIT license for this file, same as the x86 counterpart (arch/x86/include/asm/xen/hypercall.h). The intent is to allow other operating systems, the BSDs for example, to be able to use it if they want to. Actually, given that the ARM implementation is not inline, I should remember to add this copyright header to the assembly source file too. -- 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: [net-next RFC V5 3/5] virtio: intorduce an API to set affinity for a virtqueue
Il 05/07/2012 12:29, Jason Wang ha scritto: Sometimes, virtio device need to configure irq affiniry hint to maximize the performance. Instead of just exposing the irq of a virtqueue, this patch introduce an API to set the affinity for a virtqueue. The api is best-effort, the affinity hint may not be set as expected due to platform support, irq sharing or irq type. Currently, only pci method were implemented and we set the affinity according to: - if device uses INTX, we just ignore the request - if device has per vq vector, we force the affinity hint - if the virtqueues share MSI, make the affinity OR over all affinities requested Signed-off-by: Jason Wang jasow...@redhat.com Hmm, I don't see any benefit from this patch, I need to use irq_set_affinity (which however is not exported) to actually bind IRQs to CPUs. Example: with irq_set_affinity_hint: 43: 89 107 100 97 PCI-MSI-edge virtio0-request 44: 178 195 268 199 PCI-MSI-edge virtio0-request 45: 97 100 97 155 PCI-MSI-edge virtio0-request 46: 234 261 213 218 PCI-MSI-edge virtio0-request with irq_set_affinity: 43: 721001 PCI-MSI-edge virtio0-request 44:0 74601 PCI-MSI-edge virtio0-request 45:00 6580 PCI-MSI-edge virtio0-request 46:001 547 PCI-MSI-edge virtio0-request I gathered these quickly after boot, but real benchmarks show the same behavior, and performance gets actually worse with virtio-scsi multiqueue+irq_set_affinity_hint than with irq_set_affinity. I also tried adding IRQ_NO_BALANCING, but the only effect is that I cannot set the affinity The queue steering algorithm I use in virtio-scsi is extremely simple and based on your tx code. See how my nice pinning is destroyed: # taskset -c 0 dd if=/dev/sda bs=1M count=1000 of=/dev/null iflag=direct # cat /proc/interrupts 43: 2690 2709 2691 2696 PCI-MSI-edge virtio0-request 44: 109 122 199 124 PCI-MSI-edge virtio0-request 45: 170 183 170 237 PCI-MSI-edge virtio0-request 46: 143 166 125 125 PCI-MSI-edge virtio0-request All my requests come from CPU#0 and thus go to the first virtqueue, but the interrupts are serviced all over the place. Did you set the affinity manually in your experiments, or perhaps there is a difference between scsi and networking... (interrupt mitigation?) Paolo -- 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: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls
On Fri, 2012-07-27 at 15:21 +0100, Russell King - ARM Linux wrote: On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabellini wrote: +/** + * hypercall.h + * + * Linux-specific hypervisor handling. + * + * Stefano Stabellini stefano.stabell...@eu.citrix.com, Citrix, 2012 + * + * 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; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the Software), to deal in the Software without Erm, is that an additional restriction on the GPL which prevents me from shipping this code on a CD and charging for the act of creating the CD and shipping it? That would technically make the above statement incompatible with the GPL. There's an or in there. The non-GPL alternative license is the standard one applied by upstream Xen to the interface headers: http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/xen/include/public/COPYING It's the X11/MIT license IIRC, which the FSF say is GPL compatible. http://www.gnu.org/licenses/license-list.html#X11License The same license is used a few other places in the kernel, e.g. the DRM code. Ian. -- 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] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and code clean up
On 07/27/2012 04:32 PM, Peter Zijlstra wrote:
On Fri, 2012-07-27 at 09:47 +0800, Alex Shi wrote:
From 610515185d8a98c14c7c339c25381bc96cd99d93 Mon Sep 17 00:00:00 2001
From: Alex Shi alex@intel.com
Date: Thu, 26 Jul 2012 08:55:34 +0800
Subject: [PATCH 1/3] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and
code clean up
Since power saving code was removed from sched now, the implement
code is out of service in this function, and even pollute other logical.
like, 'want_sd' never has chance to be set '0', that remove the effect
of SD_WAKE_AFFINE here.
So, clean up the obsolete code and some other unnecessary code.
Signed-off-by: Alex Shi alex@intel.com
I think your code leaves an unused definition of SD_PREFER_LOCAL around.
I had thought it maybe useful in power saving recovery. But you are right.
It is better to remove them and alignment code now.
===
From 5eba8f31207e54ca6cbd481cfc23f149a0554b2a Mon Sep 17 00:00:00 2001
From: Alex Shi alex@intel.com
Date: Thu, 26 Jul 2012 08:55:34 +0800
Subject: [PATCH 1/3] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and
code clean up
Since power saving code was removed from sched now, the implement
code is out of service in this function, and even pollute other logical.
like, 'want_sd' never has chance to be set '0', that remove the effect
of SD_WAKE_AFFINE here.
So, clean up the obsolete code, like SD_PREFER_LOCAL.
Signed-off-by: Alex Shi alex@intel.com
---
include/linux/sched.h|1 -
include/linux/topology.h |2 --
kernel/sched/core.c |1 -
kernel/sched/fair.c | 32 +++-
4 files changed, 3 insertions(+), 33 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d77877d..1a1e3e45 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -855,7 +855,6 @@ enum cpu_idle_type {
#define SD_BALANCE_FORK0x0008 /* Balance on fork, clone */
#define SD_BALANCE_WAKE0x0010 /* Balance on wakeup */
#define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU */
-#define SD_PREFER_LOCAL0x0040 /* Prefer to keep tasks local
to this domain */
#define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power */
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing
instance */
diff --git a/include/linux/topology.h b/include/linux/topology.h
index fec12d6..d3cf0d6 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -129,7 +129,6 @@ int arch_update_cpu_topology(void);
| 1*SD_BALANCE_FORK \
| 0*SD_BALANCE_WAKE \
| 1*SD_WAKE_AFFINE \
- | 0*SD_PREFER_LOCAL \
| 0*SD_SHARE_CPUPOWER \
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE\
@@ -160,7 +159,6 @@ int arch_update_cpu_topology(void);
| 1*SD_BALANCE_FORK \
| 0*SD_BALANCE_WAKE \
| 1*SD_WAKE_AFFINE \
- | 0*SD_PREFER_LOCAL \
| 0*SD_SHARE_CPUPOWER \
| 0*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 82ad284..7dbb6c1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6582,7 +6582,6 @@ sd_numa_init(struct sched_domain_topology_level *tl, int
cpu)
| 0*SD_BALANCE_FORK
| 0*SD_BALANCE_WAKE
| 0*SD_WAKE_AFFINE
- | 0*SD_PREFER_LOCAL
| 0*SD_SHARE_CPUPOWER
| 0*SD_SHARE_PKG_RESOURCES
| 1*SD_SERIALIZE
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 22321db..53fd8db 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2686,7 +2686,6 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
int prev_cpu = task_cpu(p);
int new_cpu = cpu;
int want_affine = 0;
- int want_sd = 1;
int sync = wake_flags WF_SYNC;
if (p-nr_cpus_allowed == 1)
@@ -2704,48 +2703,23 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
continue;
/*
-
Re: Direct I/O bug in kernel
On Wed, Jul 25, 2012 at 1:28 AM, Victor Meyerson calculuspeng...@yahoo.com wrote: Still different checksums and I used the same random-file from my first test. Then try the fix at https://lkml.org/lkml/2012/7/27/54 Good Weekend Hillf -- 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 07/24] xen/arm: Xen detection and shared_info page mapping
On Fri, 27 Jul 2012, Ian Campbell wrote:
On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote:
Check for a /xen node in the device tree, if it is present set
xen_domain_type to XEN_HVM_DOMAIN and continue initialization.
Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
arch/arm/xen/enlighten.c | 56
++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d27c2a6..8c923af 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
#include asm/xen/hypervisor.h
#include asm/xen/hypercall.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
struct start_info _xen_start_info;
struct start_info *xen_start_info = _xen_start_info;
@@ -33,3 +36,56 @@ int xen_remap_domain_mfn_range(struct vm_area_struct
*vma,
return -ENOSYS;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * == Xen Device Tree format ==
+ * - /xen node;
+ * - compatible arm,xen;
+ * - one interrupt for Xen event notifications;
+ * - one memory region to map the grant_table.
+ */
+static int __init xen_guest_init(void)
+{
+ int cpu;
+ struct xen_add_to_physmap xatp;
+ static struct shared_info *shared_info_page = 0;
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, arm,xen);
+ if (!node) {
+ pr_info(No Xen support\n);
+ return 0;
+ }
This should either only print in the success case (to avoid spamming
everyone) or we need a little bit of infrastructure like on x86 so that
we print exactly one of:
Booting natively on bearmetal
Booting paravirtualised on %s, hypervisor-name
This function is only going to be called once (actually it might be
called twice with the change introduced by xen/arm: Introduce
xen_guest_init).
I thought that it would be an acceptible level of verbosity for pr_info.
Maybe I should just turn the pr_info into pr_debug?
+ xen_domain_type = XEN_HVM_DOMAIN;
+
+ if (!shared_info_page)
+ shared_info_page = (struct shared_info *)
+ get_zeroed_page(GFP_KERNEL);
+ if (!shared_info_page) {
+ pr_err(not enough memory);
+ return -ENOMEM;
+ }
+ xatp.domid = DOMID_SELF;
+ xatp.idx = 0;
+ xatp.space = XENMAPSPACE_shared_info;
+ xatp.gpfn = __pa(shared_info_page) PAGE_SHIFT;
+ if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, xatp))
+ BUG();
+
+ HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+ /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+* page, we use it in the event channel upcall and in some pvclock
+* related functions. We don't need the vcpu_info placement
+* optimizations because we don't use any pv_mmu or pv_irq op on
+* HVM.
+* When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
+* online but xen_hvm_init_shared_info is run at resume time too and
+* in that case multiple vcpus might be online. */
+ for_each_online_cpu(cpu) {
+ per_cpu(xen_vcpu, cpu) =
+ HYPERVISOR_shared_info-vcpu_info[cpu];
On ARM the shared info contains exactly 1 CPU (the boot CPU). The guest
is required to use VCPUOP_register_vcpu_info to place vcpu info for
secondary CPUs as they are brought up.
OK
--
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] tpm: Move tpm_get_random api into the TPM device driver
On Thu, Jul 26, 2012 at 03:12:19PM -0700, H. Peter Anvin wrote: On 06/07/2012 11:47 AM, Kent Yoder wrote: Move the tpm_get_random api from the trusted keys code into the TPM device driver itself so that other callers can make use of it. Also, change the api slightly so that the number of bytes read is returned in the call, since the TPM command can potentially return fewer bytes than requested. Signed-off-by: Kent Yoder k...@linux.vnet.ibm.com +int tpm_get_random(u32 chip_num, u8 *out, size_t *max) /* ... */ case Opt_new: -ret = my_get_random(payload-key, payload-key_len); +ret = tpm_get_random(TPM_ANY_NUM, payload-key, + payload-key_len); payload-key_len is unsigned int, not size_t; this causes an overwrite of blob_len on 64-bit platforms. Good catch. Thanks, Kent -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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 07/24] xen/arm: Xen detection and shared_info page mapping
On Fri, 2012-07-27 at 15:48 +0100, Stefano Stabellini wrote:
On Fri, 27 Jul 2012, Ian Campbell wrote:
On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote:
Check for a /xen node in the device tree, if it is present set
xen_domain_type to XEN_HVM_DOMAIN and continue initialization.
Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
arch/arm/xen/enlighten.c | 56
++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d27c2a6..8c923af 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
#include asm/xen/hypervisor.h
#include asm/xen/hypercall.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
struct start_info _xen_start_info;
struct start_info *xen_start_info = _xen_start_info;
@@ -33,3 +36,56 @@ int xen_remap_domain_mfn_range(struct vm_area_struct
*vma,
return -ENOSYS;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * == Xen Device Tree format ==
+ * - /xen node;
+ * - compatible arm,xen;
+ * - one interrupt for Xen event notifications;
+ * - one memory region to map the grant_table.
+ */
+static int __init xen_guest_init(void)
+{
+ int cpu;
+ struct xen_add_to_physmap xatp;
+ static struct shared_info *shared_info_page = 0;
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, arm,xen);
+ if (!node) {
+ pr_info(No Xen support\n);
+ return 0;
+ }
This should either only print in the success case (to avoid spamming
everyone) or we need a little bit of infrastructure like on x86 so that
we print exactly one of:
Booting natively on bearmetal
Booting paravirtualised on %s, hypervisor-name
This function is only going to be called once (actually it might be
called twice with the change introduced by xen/arm: Introduce
xen_guest_init).
Once (or twice), per boot, per ARM system running Linux in the world...
Ian.
--
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: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
+static DEFINE_MUTEX(tdm_core_lock);
+static DEFINE_IDR(tdm_adapter_idr);
+/* List of TDM adapters registered with TDM framework */
+LIST_HEAD(adapter_list);
+
+/* List of TDM clients registered with TDM framework */
+LIST_HEAD(driver_list);
These two are far too generic to be public. Have you checked your code
with sparse? I think not.
+
+/*
+ * In case the previous data is not fetched by the client driver, the
+ * de-interleaving function will discard the old data and rewrite the
+ * new data
+ */
+
+static int use_latest_tdm_data = 1;
+
+/* Data structures required for sysfs */
+static struct tdm_sysfs attr = {
+ .attr.name = use_latest_data,
+ .attr.mode = 0664,
+ .cmd_type = TDM_LATEST_DATA,
+};
+
+static struct attribute *tdm_attr[] = {
+ attr.attr,
+ NULL
+};
+
+const struct sysfs_ops tdm_ops = {
+ .show = tdm_show_sysfs,
+ .store = tdm_store_sysfs,
+};
Again, lack of static.
+
+static struct kobj_type tdm_type = {
+ .sysfs_ops = tdm_ops,
+ .default_attrs = tdm_attr,
+};
+
+/* tries to match client driver with the adapter */
+static int tdm_device_match(struct tdm_driver *driver, struct tdm_adapter
*adap)
+{
+ /* match on an id table if there is one */
+ if (driver-id_table driver-id_table-name[0]) {
+ if (!(strcmp(driver-id_table-name, adap-name)))
+ return (int)driver-id_table;
Casting a pointer to 'int' is not a good thing to do. Please fix this.
+ }
+ return 0;
+}
+
+static int tdm_attach_driver_adap(struct tdm_driver *driver,
+ struct tdm_adapter *adap)
+{
+ int ret = 0;
+ /* if driver is already attached to any other adapter, return*/
+ if (driver-adapter (driver-adapter != adap))
Additional parens not required.
+ return 0;
+
+ driver-adapter = adap;
+
+ if (driver-attach_adapter) {
+ ret = driver-attach_adapter(adap);
+ if (ret 0) {
+ pr_err(tdm: attach_adapter failed for driver [%s]
+ err:%d\n, driver-name, ret);
+ return ret;
+ }
+ }
+ adap-drv_count++;
+
+ if (!adap-tasklet_conf) {
+ tdm_sysfs_init();
+ tasklet_init(adap-tdm_data_tasklet, tdm_data_tasklet_fn,
+ (unsigned long)adap);
Why not init this tasklet when the struct tdm_adapter is first created?
Why do you need to wait, and then have state tracking for this?
+ adap-tasklet_conf = 1;
+ }
+
+ return ret;
+}
+
+/* Detach client driver and adapter */
+static int tdm_detach_driver_adap(struct tdm_driver *driver,
+ struct tdm_adapter *adap)
+{
+ int res = 0;
+
+ if (!driver-adapter || (driver-adapter != adap))
Additional parens not required.
+ return 0;
+
+ adap-drv_count--;
+
+ /* If no more driver is registed with the adapter*/
+ if (!adap-drv_count adap-tasklet_conf) {
+ tasklet_disable(adap-tdm_data_tasklet);
+ tasklet_kill(adap-tdm_data_tasklet);
+ adap-tasklet_conf = 0;
+ }
+
+ if (driver-detach_adapter) {
+ if (driver-detach_adapter(adap))
+ pr_err(tdm: detach_adapter failed for driver [%s]\n,
+ driver-name);
+ }
+
+ driver-adapter = NULL;
+ return res;
+}
+
+/* TDM adapter Registration/De-registration with TDM framework */
+
+static int tdm_register_adapter(struct tdm_adapter *adap)
+{
+ int res = 0;
+ struct tdm_driver *driver, *next;
+
+ mutex_init(adap-adap_lock);
+ INIT_LIST_HEAD(adap-myports);
+ spin_lock_init(adap-portlist_lock);
+
+ adap-drv_count = 0;
+ adap-tasklet_conf = 0;
+
+ list_add_tail(adap-list, adapter_list);
What protects this list?
+
+ /* initialization of driver by framework in default configuration */
+ init_config_adapter(adap);
+
+ /* Notify drivers */
+ pr_info(adapter [%s] registered\n, adap-name);
+ mutex_lock(tdm_core_lock);
+ list_for_each_entry_safe(driver, next, driver_list, list) {
+ if (tdm_device_match(driver, adap)) {
+ res = tdm_attach_driver_adap(driver, adap);
+ if (res == 0) {
+ pr_info(tdm: Driver(ID=%d) is
+ attached with Adapter %s(ID
+ = %d)\n, driver-id,
+ adap-name, adap-id);
+ } else {
+ pr_err(tdm: Driver(ID=%d) is unable
+ to attach with Adapter %s(ID =
%d)\n,
+
Re: [PATCH 1/2] tpm: Move tpm_get_random api into the TPM device driver
On Thu, Jul 26, 2012 at 05:10:44PM -0700, H. Peter Anvin wrote: On 06/07/2012 11:47 AM, Kent Yoder wrote: Move the tpm_get_random api from the trusted keys code into the TPM device driver itself so that other callers can make use of it. Also, change the api slightly so that the number of bytes read is returned in the call, since the TPM command can potentially return fewer bytes than requested. Signed-off-by: Kent Yoder k...@linux.vnet.ibm.com I see a second problem with this patch: you don't seem to handle the case where you get a short return anywhere in your code. Presumably this should either be considered an error condition, or you need to create a private wrapper which can loop and make additional requests. As it is if you get a short return you simply proceed as if you had gotten what you requested, since this was not an error mode supported by the old code. Right, I did notice this but didn't think I was creating a regression so I left it. I'll add both a loop and then error out if that fails. Thanks, Kent -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls
On Fri, Jul 27, 2012 at 03:39:31PM +0100, Ian Campbell wrote: On Fri, 2012-07-27 at 15:21 +0100, Russell King - ARM Linux wrote: On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabellini wrote: +/** + * hypercall.h + * + * Linux-specific hypervisor handling. + * + * Stefano Stabellini stefano.stabell...@eu.citrix.com, Citrix, 2012 + * + * 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; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the Software), to deal in the Software without Erm, is that an additional restriction on the GPL which prevents me from shipping this code on a CD and charging for the act of creating the CD and shipping it? That would technically make the above statement incompatible with the GPL. There's an or in there. The non-GPL alternative license is the standard one applied by upstream Xen to the interface headers: http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/xen/include/public/COPYING It's the X11/MIT license IIRC, which the FSF say is GPL compatible. http://www.gnu.org/licenses/license-list.html#X11License The same license is used a few other places in the kernel, e.g. the DRM code. Ok, but be aware that you won't be able to take code from the Linux kernel and place it in a file marked with that license header (because the code authors haven't given permission for it to be placed under any other license other than GPLv2.) -- 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: [GIT PULL] New TPM driver and features
On 07/27/2012 07:29 AM, Kent Yoder wrote: Hi, On Thu, Jul 26, 2012 at 02:46:25PM -0700, H. Peter Anvin wrote: On 07/26/2012 07:31 AM, Kent Yoder wrote: hw_random: add support for the TPM chip as a hardware RNG source Could you clarify this? rngd (the user of /dev/hw_random) already has support for the TPM... is this fundamentally different (e.g. can it coexist with tcsd being in use at the same time)? These can coexist at the same time since /dev/tpm0 is only opened once from user-space (from tcsd) and this hwrng driver comes in through the kernel. There would be some amount of contention with the tpm, but its not likely to be noticable - grabbing rng data doesn't require any state in the tpm, like an auth session or key loading. Since the rngd support for the tpm requires trousers, this patch will be useful in places where you don't want to have to deploy the full TSS, like embedded and early boot. Actually the rngd support for the TPM *conflicts* with trousers... I was looking at adding trousers support when I stumbled over your patch. Your patch is better, because it solves the handover problem (rngd should normally be started as early as possible.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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] tpm: Move tpm_get_random api into the TPM device driver
On 07/27/2012 07:49 AM, Kent Yoder wrote: case Opt_new: - ret = my_get_random(payload-key, payload-key_len); + ret = tpm_get_random(TPM_ANY_NUM, payload-key, +payload-key_len); payload-key_len is unsigned int, not size_t; this causes an overwrite of blob_len on 64-bit platforms. Good catch. It generated a compiler warning, so that one was trivial to spot. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: [ 39/40] cpuset: mm: reduce large amounts of memory barrier related damage v3
On Thu, Jul 26, 2012 at 02:29:57PM -0700, Greg Kroah-Hartman wrote: From: Greg KH gre...@linuxfoundation.org 3.0-stable review patch. If anyone has any objections, please let me know. -- From: Mel Gorman mgor...@suse.de commit cc9a6c8776615f9c194ccf0b63a0aa5628235545 upstream. Stable note: Not tracked in Bugzilla. [get|put]_mems_allowed() is extremely expensive and severely impacted page allocator performance. This is part of a series of patches that reduce page allocator overhead. Commit c0ff7453bb5c (cpuset,mm: fix no node to alloc memory when changing cpuset's mems) wins a super prize for the largest number of memory barriers entered into fast paths for one commit. [get|put]_mems_allowed is incredibly heavy with pairs of full memory barriers inserted into a number of hot paths. This was detected while investigating at large page allocator slowdown introduced some time after 2.6.32. The largest portion of this overhead was shown by oprofile to be at an mfence introduced by this commit into the page allocator hot path. For extra style points, the commit introduced the use of yield() in an implementation of what looks like a spinning mutex. This patch replaces the full memory barriers on both read and write sides with a sequence counter with just read barriers on the fast path side. This is much cheaper on some architectures, including x86. The main bulk of the patch is the retry logic if the nodemask changes in a manner that can cause a false failure. While updating the nodemask, a check is made to see if a false failure is a risk. If it is, the sequence number gets bumped and parallel allocators will briefly stall while the nodemask update takes place. In a page fault test microbenchmark, oprofile samples from __alloc_pages_nodemask went from 4.53% of all samples to 1.15%. The actual results were 3.3.0-rc3 3.3.0-rc3 rc3-vanillanobarrier-v2r1 Clients 1 UserTime 0.07 ( 0.00%) 0.08 (-14.19%) Clients 2 UserTime 0.07 ( 0.00%) 0.07 ( 2.72%) Clients 4 UserTime 0.08 ( 0.00%) 0.07 ( 3.29%) Clients 1 SysTime0.70 ( 0.00%) 0.65 ( 6.65%) Clients 2 SysTime0.85 ( 0.00%) 0.82 ( 3.65%) Clients 4 SysTime1.41 ( 0.00%) 1.41 ( 0.32%) Clients 1 WallTime 0.77 ( 0.00%) 0.74 ( 4.19%) Clients 2 WallTime 0.47 ( 0.00%) 0.45 ( 3.73%) Clients 4 WallTime 0.38 ( 0.00%) 0.37 ( 1.58%) Clients 1 Flt/sec/cpu 497620.28 ( 0.00%) 520294.53 ( 4.56%) Clients 2 Flt/sec/cpu 414639.05 ( 0.00%) 429882.01 ( 3.68%) Clients 4 Flt/sec/cpu 257959.16 ( 0.00%) 258761.48 ( 0.31%) Clients 1 Flt/sec 495161.39 ( 0.00%) 517292.87 ( 4.47%) Clients 2 Flt/sec 820325.95 ( 0.00%) 850289.77 ( 3.65%) Clients 4 Flt/sec 1020068.93 ( 0.00%) 1022674.06 ( 0.26%) MMTests Statistics: duration Sys Time Running Test (seconds) 135.68132.17 User+Sys Time Running Test (seconds) 164.2160.13 Total Elapsed Time (seconds)123.46120.87 The overall improvement is small but the System CPU time is much improved and roughly in correlation to what oprofile reported (these performance figures are without profiling so skew is expected). The actual number of page faults is noticeably improved. For benchmarks like kernel builds, the overall benefit is marginal but the system CPU time is slightly reduced. To test the actual bug the commit fixed I opened two terminals. The first ran within a cpuset and continually ran a small program that faulted 100M of anonymous data. In a second window, the nodemask of the cpuset was continually randomised in a loop. Without the commit, the program would fail every so often (usually within 10 seconds) and obviously with the commit everything worked fine. With this patch applied, it also worked fine so the fix should be functionally equivalent. Signed-off-by: Mel Gorman mgor...@suse.de Cc: Miao Xie mi...@cn.fujitsu.com Cc: David Rientjes rient...@google.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Christoph Lameter c...@linux.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Mel Gorman mgor...@suse.de Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- include/linux/cpuset.h| 49 ++ include/linux/init_task.h |8 +++ include/linux/sched.h |2 - kernel/cpuset.c | 43 +++- kernel/fork.c |3 ++ mm/filemap.c | 11 ++ mm/hugetlb.c | 15 ++ mm/mempolicy.c| 28
Re: [PATCH 1/4] EFI: Stash ROMs if they're not in the PCI BAR
On Thu, Jul 26, 2012 at 06:02:46PM -0400, Matthew Garrett wrote: + rom-data.next = NULL; Noticed today that I'm getting an assignment makes integer from pointer without a cast warning from this line. -- 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 3/4] PCI: Add support for non-BAR ROMs
On Thu, Jul 26, 2012 at 06:02:48PM -0400, Matthew Garrett wrote: + return phys_to_virt(pdev-rom); This line is giving me a makes integer from pointer without a cast warning. -- 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: [ 39/40] cpuset: mm: reduce large amounts of memory barrier related damage v3
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1457,6 +1457,7 @@ static struct page *get_any_partial(stru
struct zone *zone;
enum zone_type high_zoneidx = gfp_zone(flags);
struct page *page;
+ unsigned int cpuset_mems_cookie;
/*
* The defrag ratio allows a configuration of the tradeoffs between
@@ -1480,22 +1481,32 @@ static struct page *get_any_partial(stru
get_cycles() % 1024 s-remote_node_defrag_ratio)
return NULL;
- get_mems_allowed();
- zonelist = node_zonelist(slab_node(current-mempolicy), flags);
- for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
- struct kmem_cache_node *n;
+ do {
+ cpuset_mems_cookie = get_mems_allowed();
+ zonelist = node_zonelist(slab_node(current-mempolicy), flags);
+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
+ struct kmem_cache_node *n;
- n = get_node(s, zone_to_nid(zone));
+ n = get_node(s, zone_to_nid(zone));
- if (n cpuset_zone_allowed_hardwall(zone, flags)
- n-nr_partial s-min_partial) {
- page = get_partial_node(n);
- if (page) {
- put_mems_allowed();
- return page;
+ if (n cpuset_zone_allowed_hardwall(zone, flags)
+ n-nr_partial s-min_partial) {
+ page = get_partial_node(n);
+ if (page) {
+ /*
+* Return the object even if
+* put_mems_allowed indicated that
+* the cpuset mems_allowed was
+* updated in parallel. It's a
+* harmless race between the alloc
+* and the cpuset update.
+*/
+ put_mems_allowed(cpuset_mems_cookie);
+ return page;
+ }
}
}
- }
+ } while (!put_mems_allowed(cpuset_mems_cookie));
put_mems_allowed();
This doesn't build on 3.0, the backport left the stray put_mems_allowed
above:
linux-stable/mm/slub.c: In function 'get_any_partial':
linux-stable/mm/slub.c:1510:2: error: too few arguments to function
'put_mems_allowed'
linux-stable/include/linux/cpuset.h:108:20: note: declared here
That line should have been deleted and tests were based on slab. My
apologies.
---8---
cpuset: mm: Reduce large amounts of memory barrier related damage fix
linux-stable/mm/slub.c: In function 'get_any_partial':
linux-stable/mm/slub.c:1510:2: error: too few arguments to function
'put_mems_allowed'
linux-stable/include/linux/cpuset.h:108:20: note: declared here
Reported-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
Signed-off-by: Mel Gorman mgor...@suse.de
diff --git a/mm/slub.c b/mm/slub.c
index 00ccf2c..ae6e80e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1507,7 +1507,6 @@ static struct page *get_any_partial(struct kmem_cache *s,
gfp_t flags)
}
}
} while (!put_mems_allowed(cpuset_mems_cookie));
- put_mems_allowed();
#endif
return NULL;
}
--
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 4/7] bridge: call NETDEV_RELEASE notifier in br_del_if()
When a bridge interface deletes its underlying ports, it should notify netconsole too, like what bonding interface does. Cc: David S. Miller da...@davemloft.net Signed-off-by: Cong Wang amw...@redhat.com --- net/bridge/br_if.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index e1144e1..d243914 100644 --- a/net/bridge/br_if.c +++ b/net/bridge/br_if.c @@ -427,6 +427,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev) if (!p || p-br != br) return -EINVAL; + call_netdevice_notifiers(NETDEV_RELEASE, br-dev); del_nbp(p); spin_lock_bh(br-lock); -- 1.7.7.6 -- 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 3/7] netconsole: do not release spin_lock before calling __netpoll_cleanup
With the previous patch applied, __netpoll_cleanup() is non-block now,
so we don't need to release the spin_lock before calling it.
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Cong Wang amw...@redhat.com
---
drivers/net/netconsole.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index f9347ea..f0ad56c 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -640,12 +640,7 @@ static int netconsole_netdev_event(struct notifier_block
*this,
* rtnl_lock already held
*/
if (nt-np.dev) {
- spin_unlock_irqrestore(
- target_list_lock,
- flags);
__netpoll_cleanup(nt-np);
- spin_lock_irqsave(target_list_lock,
- flags);
dev_put(nt-np.dev);
nt-np.dev = NULL;
netconsole_target_put(nt);
--
1.7.7.6
--
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 1/7] netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()
slave_enable_netpoll() and __netpoll_setup() may be called
with read_lock() held, so should use GFP_ATOMIC to allocate
memory.
Cc: David S. Miller da...@davemloft.net
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Cong Wang amw...@redhat.com
---
drivers/net/bonding/bond_main.c |2 +-
net/core/netpoll.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6fae5f3..ab773d4 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1235,7 +1235,7 @@ static inline int slave_enable_netpoll(struct slave
*slave)
struct netpoll *np;
int err = 0;
- np = kzalloc(sizeof(*np), GFP_KERNEL);
+ np = kzalloc(sizeof(*np), GFP_ATOMIC);
err = -ENOMEM;
if (!np)
goto out;
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index b4c90e4..c78a966 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -734,7 +734,7 @@ int __netpoll_setup(struct netpoll *np, struct net_device
*ndev)
}
if (!ndev-npinfo) {
- npinfo = kmalloc(sizeof(*npinfo), GFP_KERNEL);
+ npinfo = kmalloc(sizeof(*npinfo), GFP_ATOMIC);
if (!npinfo) {
err = -ENOMEM;
goto out;
--
1.7.7.6
--
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 5/7] netpoll: take rcu_read_lock_bh() in netpoll_rx()
In __netpoll_rx(), it dereferences -npinfo without rcu_dereference_bh(),
this patch fixes it by using the 'npinfo' passed from netpoll_rx()
where it is already dereferenced with rcu_dereference_bh().
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Cong Wang amw...@redhat.com
---
include/linux/netpoll.h |4 ++--
net/core/netpoll.c |3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 5011d74..36f938c 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -52,7 +52,7 @@ void netpoll_set_trap(int trap);
void __netpoll_cleanup(struct netpoll *np);
void __netpoll_free_rcu(struct netpoll *np);
void netpoll_cleanup(struct netpoll *np);
-int __netpoll_rx(struct sk_buff *skb);
+int __netpoll_rx(struct sk_buff *skb, struct netpoll_info *npinfo);
void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
struct net_device *dev);
static inline void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
@@ -77,7 +77,7 @@ static inline bool netpoll_rx(struct sk_buff *skb)
spin_lock(npinfo-rx_lock);
/* check rx_flags again with the lock held */
- if (npinfo-rx_flags __netpoll_rx(skb))
+ if (npinfo-rx_flags __netpoll_rx(skb, npinfo))
ret = true;
spin_unlock(npinfo-rx_lock);
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 19dddef..3965fdb 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -543,13 +543,12 @@ static void arp_reply(struct sk_buff *skb)
spin_unlock_irqrestore(npinfo-rx_lock, flags);
}
-int __netpoll_rx(struct sk_buff *skb)
+int __netpoll_rx(struct sk_buff *skb, struct netpoll_info *npinfo)
{
int proto, len, ulen;
int hits = 0;
const struct iphdr *iph;
struct udphdr *uh;
- struct netpoll_info *npinfo = skb-dev-npinfo;
struct netpoll *np, *tmp;
if (list_empty(npinfo-rx_np))
--
1.7.7.6
--
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: [2/3][PATCH][v2] TDM Framework
sand...@freescale.com sand...@freescale.com : [...] The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer management. In future this Framework will be extended to provide Interface for Line control devices also. For example SLIC, E1/T1 Framers etc. Presently the framework supports only Single Port channelised mode. Also the configurability options are limited which will be extended later on. Only kernel mode TDM clients are supported currently. Support for User mode clients will be added later. 1. You should send some kernel mode TDM clients. Without those the framework is pretty useless. 2. It would probably make sense to Cc: netdev and serial. There may be some kernel client network integration from the start. 3. Where is the userspace configuration interface ? [...] Based on: git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git $ git clone git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git Cloning into 'galak-powerpc'... fatal: Unable to look up git.am.freescale.net (port 9418) (No address associated with hostname) -- Ueimor -- 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 7/7] netpoll: take rcu_read_lock_bh() in netpoll_send_skb_on_dev()
This patch fixes several problems in the call path of
netpoll_send_skb_on_dev():
1. We already disable IRQ's before calling netpoll_send_skb_on_dev(),
so we don't need to disable IRQ's again.
2. All the callees of netpoll_send_skb_on_dev() should use
rcu_dereference_bh() to dereference -npinfo.
3. Rename arp_reply() to netpoll_arp_reply(), the former is too generic.
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Cong Wang amw...@redhat.com
---
net/core/netpoll.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3965fdb..d6e192b 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -54,7 +54,7 @@ static atomic_t trapped;
MAX_UDP_CHUNK)
static void zap_completion_queue(void);
-static void arp_reply(struct sk_buff *skb);
+static void netpoll_arp_reply(struct sk_buff *skb, struct netpoll_info
*npinfo);
static unsigned int carrier_timeout = 4;
module_param(carrier_timeout, uint, 0644);
@@ -170,7 +170,8 @@ static void poll_napi(struct net_device *dev)
list_for_each_entry(napi, dev-napi_list, dev_list) {
if (napi-poll_owner != smp_processor_id()
spin_trylock(napi-poll_lock)) {
- budget = poll_one_napi(dev-npinfo, napi, budget);
+ budget = poll_one_napi(rcu_dereference_bh(dev-npinfo),
+ napi, budget);
spin_unlock(napi-poll_lock);
if (!budget)
@@ -185,13 +186,14 @@ static void service_arp_queue(struct netpoll_info *npi)
struct sk_buff *skb;
while ((skb = skb_dequeue(npi-arp_tx)))
- arp_reply(skb);
+ netpoll_arp_reply(skb, npi);
}
}
static void netpoll_poll_dev(struct net_device *dev)
{
const struct net_device_ops *ops;
+ struct netpoll_info *ni = rcu_dereference_bh(dev-npinfo);
if (!dev || !netif_running(dev))
return;
@@ -206,17 +208,18 @@ static void netpoll_poll_dev(struct net_device *dev)
poll_napi(dev);
if (dev-flags IFF_SLAVE) {
- if (dev-npinfo) {
+ if (ni) {
struct net_device *bond_dev = dev-master;
struct sk_buff *skb;
- while ((skb = skb_dequeue(dev-npinfo-arp_tx))) {
+ struct netpoll_info *bond_ni =
rcu_dereference_bh(bond_dev-npinfo);
+ while ((skb = skb_dequeue(ni-arp_tx))) {
skb-dev = bond_dev;
- skb_queue_tail(bond_dev-npinfo-arp_tx, skb);
+ skb_queue_tail(bond_ni-arp_tx, skb);
}
}
}
- service_arp_queue(dev-npinfo);
+ service_arp_queue(ni);
zap_completion_queue();
}
@@ -302,6 +305,7 @@ static int netpoll_owner_active(struct net_device *dev)
return 0;
}
+/* call with IRQ disabled */
void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
struct net_device *dev)
{
@@ -309,8 +313,11 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct
sk_buff *skb,
unsigned long tries;
const struct net_device_ops *ops = dev-netdev_ops;
/* It is up to the caller to keep npinfo alive. */
- struct netpoll_info *npinfo = np-dev-npinfo;
+ struct netpoll_info *npinfo;
+
+ WARN_ON_ONCE(!irqs_disabled());
+ npinfo = rcu_dereference_bh(np-dev-npinfo);
if (!npinfo || !netif_running(dev) || !netif_device_present(dev)) {
__kfree_skb(skb);
return;
@@ -319,11 +326,9 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct
sk_buff *skb,
/* don't get messages out of order, and no recursion */
if (skb_queue_len(npinfo-txq) == 0 !netpoll_owner_active(dev)) {
struct netdev_queue *txq;
- unsigned long flags;
txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
- local_irq_save(flags);
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
tries 0; --tries) {
@@ -347,10 +352,9 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct
sk_buff *skb,
}
WARN_ONCE(!irqs_disabled(),
- netpoll_send_skb(): %s enabled interrupts in poll
(%pF)\n,
+ netpoll_send_skb_on_dev(): %s enabled interrupts in
poll (%pF)\n,
dev-name, ops-ndo_start_xmit);
- local_irq_restore(flags);
}
if (status != NETDEV_TX_OK) {
@@ -423,9 +427,8 @@ void netpoll_send_udp(struct netpoll *np, const char *msg,
int len)
}
EXPORT_SYMBOL(netpoll_send_udp);
[PATCH 6/7] netpoll: use netpoll_rx_on() in netpoll_rx()
The logic of the code is same, just call netpoll_rx_on().
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Cong Wang amw...@redhat.com
---
include/linux/netpoll.h | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 36f938c..f654fa3 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -63,6 +63,13 @@ static inline void netpoll_send_skb(struct netpoll *np,
struct sk_buff *skb)
#ifdef CONFIG_NETPOLL
+static inline int netpoll_rx_on(struct sk_buff *skb)
+{
+ struct netpoll_info *npinfo = rcu_dereference_bh(skb-dev-npinfo);
+
+ return npinfo (!list_empty(npinfo-rx_np) || npinfo-rx_flags);
+}
+
static inline bool netpoll_rx(struct sk_buff *skb)
{
struct netpoll_info *npinfo;
@@ -70,11 +77,11 @@ static inline bool netpoll_rx(struct sk_buff *skb)
bool ret = false;
local_irq_save(flags);
- npinfo = rcu_dereference_bh(skb-dev-npinfo);
- if (!npinfo || (list_empty(npinfo-rx_np) !npinfo-rx_flags))
+ if (!netpoll_rx_on(skb))
goto out;
+ npinfo = rcu_dereference_bh(skb-dev-npinfo);
spin_lock(npinfo-rx_lock);
/* check rx_flags again with the lock held */
if (npinfo-rx_flags __netpoll_rx(skb, npinfo))
@@ -86,13 +93,6 @@ out:
return ret;
}
-static inline int netpoll_rx_on(struct sk_buff *skb)
-{
- struct netpoll_info *npinfo = rcu_dereference_bh(skb-dev-npinfo);
-
- return npinfo (!list_empty(npinfo-rx_np) || npinfo-rx_flags);
-}
-
static inline int netpoll_receive_skb(struct sk_buff *skb)
{
if (!list_empty(skb-dev-napi_list))
--
1.7.7.6
--
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 2/7] netpoll: make __netpoll_cleanup non-block
Like the previous patch, slave_disable_netpoll() and __netpoll_cleanup()
may be called with read_lock() held too, so we should make them
non-block, by moving the cleanup and kfree() to call_rcu_bh() callbacks.
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Cong Wang amw...@redhat.com
---
drivers/net/bonding/bond_main.c |4 +--
include/linux/netpoll.h |3 ++
net/8021q/vlan_dev.c|6 +
net/bridge/br_device.c |6 +
net/core/netpoll.c | 42 +-
5 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ab773d4..9907889 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1257,9 +1257,7 @@ static inline void slave_disable_netpoll(struct slave
*slave)
return;
slave-np = NULL;
- synchronize_rcu_bh();
- __netpoll_cleanup(np);
- kfree(np);
+ __netpoll_free_rcu(np);
}
static inline bool slave_dev_support_netpoll(struct net_device *slave_dev)
{
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 28f5389..5011d74 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -23,6 +23,7 @@ struct netpoll {
u8 remote_mac[ETH_ALEN];
struct list_head rx; /* rx_np list element */
+ struct rcu_head rcu;
};
struct netpoll_info {
@@ -38,6 +39,7 @@ struct netpoll_info {
struct delayed_work tx_work;
struct netpoll *netpoll;
+ struct rcu_head rcu;
};
void netpoll_send_udp(struct netpoll *np, const char *msg, int len);
@@ -48,6 +50,7 @@ int netpoll_setup(struct netpoll *np);
int netpoll_trap(void);
void netpoll_set_trap(int trap);
void __netpoll_cleanup(struct netpoll *np);
+void __netpoll_free_rcu(struct netpoll *np);
void netpoll_cleanup(struct netpoll *np);
int __netpoll_rx(struct sk_buff *skb);
void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 73a2a83..43e14a2 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -703,11 +703,7 @@ static void vlan_dev_netpoll_cleanup(struct net_device
*dev)
info-netpoll = NULL;
-/* Wait for transmitting packets to finish before freeing. */
-synchronize_rcu_bh();
-
-__netpoll_cleanup(netpoll);
-kfree(netpoll);
+ __netpoll_free_rcu(netpoll);
}
#endif /* CONFIG_NET_POLL_CONTROLLER */
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 3334845..bb6a5dd 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -267,11 +267,7 @@ void br_netpoll_disable(struct net_bridge_port *p)
p-np = NULL;
- /* Wait for transmitting packets to finish before freeing. */
- synchronize_rcu_bh();
-
- __netpoll_cleanup(np);
- kfree(np);
+ __netpoll_free_rcu(np);
}
#endif
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c78a966..19dddef 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -878,6 +878,24 @@ static int __init netpoll_init(void)
}
core_initcall(netpoll_init);
+static void rcu_cleanup_netpoll_info(struct rcu_head *rcu_head)
+{
+ struct netpoll_info *npinfo =
+ container_of(rcu_head, struct netpoll_info, rcu);
+
+ skb_queue_purge(npinfo-arp_tx);
+ skb_queue_purge(npinfo-txq);
+
+ /* we can't call cancel_delayed_work_sync here, as we are in softirq*/
+ cancel_delayed_work(npinfo-tx_work);
+
+ /* clean after last, unfinished work */
+ __skb_queue_purge(npinfo-txq);
+ /* now cancel it again */
+ cancel_delayed_work(npinfo-tx_work);
+ kfree(npinfo);
+}
+
void __netpoll_cleanup(struct netpoll *np)
{
struct netpoll_info *npinfo;
@@ -903,20 +921,24 @@ void __netpoll_cleanup(struct netpoll *np)
ops-ndo_netpoll_cleanup(np-dev);
RCU_INIT_POINTER(np-dev-npinfo, NULL);
+ call_rcu_bh(npinfo-rcu, rcu_cleanup_netpoll_info);
+ }
+}
+EXPORT_SYMBOL_GPL(__netpoll_cleanup);
- /* avoid racing with NAPI reading npinfo */
- synchronize_rcu_bh();
+static void rcu_cleanup_netpoll(struct rcu_head *rcu_head)
+{
+ struct netpoll *np = container_of(rcu_head, struct netpoll, rcu);
- skb_queue_purge(npinfo-arp_tx);
- skb_queue_purge(npinfo-txq);
- cancel_delayed_work_sync(npinfo-tx_work);
+ __netpoll_cleanup(np);
+ kfree(np);
+}
- /* clean after last, unfinished work */
- __skb_queue_purge(npinfo-txq);
- kfree(npinfo);
- }
+void __netpoll_free_rcu(struct netpoll *np)
+{
+ call_rcu_bh(np-rcu, rcu_cleanup_netpoll);
}
-EXPORT_SYMBOL_GPL(__netpoll_cleanup);
+EXPORT_SYMBOL_GPL(__netpoll_free_rcu);
void netpoll_cleanup(struct netpoll *np)
{
--
[RFC PATCH 0/5] cputime: Generic virtual based cputime accounting
So,
This is a proposition to handle the cputime accounting without the
tick to prepare for stopping the tick further idle.
I have managed to reuse and generalize the kernel/user boundary
hooks used by RCU. This way we can minimize the changes in archs
that don't support virtual cputime and we can also switch between
vtime and tick based accounting to minimize the overhead depending
on the tick behaviour.
This is based on top of rcu/idle branch in Paul's tree and my
vtime consolidation series: https://lkml.org/lkml/2012/6/20/762
(still waiting to be picked btw).
You, adventurer, can pull from:
git://github.com/fweisbec/linux-dynticks.git
vtime/generic
Frederic Weisbecker (5):
user_hooks: New user hooks subsystem
cputime: Don't allow virtual and irq finegrained cputime accounting
simultaneously
cputime: Allow dynamic switch between tick/virtual based cputime
accounting
cputime: Rename account_system_vtime to account_vtime
cputime: Generic on-demand virtual cputime accounting
arch/Kconfig | 10 +-
arch/ia64/include/asm/cputime.h |5 +
arch/ia64/kernel/time.c |6 +-
arch/powerpc/include/asm/cputime.h |5 +
arch/powerpc/kernel/time.c | 10 +-
arch/s390/include/asm/cputime.h |5 +
arch/s390/kernel/vtime.c |6 +-
arch/x86/Kconfig |2 +-
arch/x86/include/asm/{rcu.h = user_hooks.h} | 12 +-
arch/x86/kernel/ptrace.c |6 +-
arch/x86/kernel/signal.c |5 +-
arch/x86/kernel/traps.c |2 +-
arch/x86/mm/fault.c |2 +-
include/asm-generic/cputime.h|7 +
include/linux/hardirq.h |8 +-
include/linux/kernel_stat.h | 13 ++
include/linux/kvm_host.h |4 +-
include/linux/rcupdate.h |2 -
include/linux/sched.h| 13 +--
include/linux/user_hooks.h | 36 ++
init/Kconfig | 35 --
kernel/Makefile |1 +
kernel/fork.c|3 +-
kernel/rcutree.c | 42 +---
kernel/sched/core.c |9 +-
kernel/sched/cputime.c | 159 +
kernel/softirq.c |6 +-
kernel/time/tick-sched.c | 28 ++---
kernel/user_hooks.c | 56 +
29 files changed, 348 insertions(+), 150 deletions(-)
rename arch/x86/include/asm/{rcu.h = user_hooks.h} (56%)
create mode 100644 include/linux/user_hooks.h
create mode 100644 kernel/user_hooks.c
--
1.7.5.4
--
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 1/5] user_hooks: New user hooks subsystem
Create a new subsystem that handles the hooks on kernel/user
boundaries currently used by RCU for its userspace extended
quiescent state.
We need to pull this up from RCU into this new level of indirection
because these hooks are also going to be used to implement an on
demand generic virtual cputime accounting. A necessary step to
shutdown the tick while still accounting the cputime.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Alessio Igor Bogani abog...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Avi Kivity a...@redhat.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Christoph Lameter c...@linux.com
Cc: Geoff Levand ge...@infradead.org
Cc: Gilad Ben Yossef gi...@benyossef.com
Cc: Hakan Akkan hakanak...@gmail.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Kevin Hilman khil...@ti.com
Cc: Max Krasnyansky m...@qualcomm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Sven-Thorsten Dietrich thebigcorporat...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
---
arch/Kconfig | 10 ++--
arch/x86/Kconfig |2 +-
arch/x86/include/asm/{rcu.h = user_hooks.h} | 12 +++---
arch/x86/kernel/ptrace.c |6 +-
arch/x86/kernel/signal.c |5 +-
arch/x86/kernel/traps.c |2 +-
arch/x86/mm/fault.c |2 +-
include/linux/rcupdate.h |2 -
include/linux/sched.h|8
include/linux/user_hooks.h | 18
init/Kconfig | 24 +++
kernel/Makefile |1 +
kernel/rcutree.c | 42 +--
kernel/sched/core.c |9 ++--
kernel/user_hooks.c | 56 ++
15 files changed, 117 insertions(+), 82 deletions(-)
rename arch/x86/include/asm/{rcu.h = user_hooks.h} (56%)
create mode 100644 include/linux/user_hooks.h
create mode 100644 kernel/user_hooks.c
diff --git a/arch/Kconfig b/arch/Kconfig
index d891c62..b8b987c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -277,14 +277,14 @@ config SECCOMP_FILTER
config HAVE_VIRT_CPU_ACCOUNTING
bool
-config HAVE_RCU_USER_QS
+config HAVE_USER_HOOKS
bool
help
Provide kernel entry/exit hooks necessary for userspace
RCU extended quiescent state. Syscalls need to be wrapped inside
- rcu_user_exit()-rcu_user_enter() through the slow path using
- TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
- are already protected inside rcu_irq_enter/rcu_irq_exit() but
- preemption or signal handling on irq exit still need to be protected.
+ user_exit()-user_enter() through the slow path using TIF_NOHZ flag.
+ Exceptions handlers must be wrapped as well. Irqs are already
+ protected inside rcu_irq_enter/rcu_irq_exit() but preemption or
+ signal handling on irq exit still need to be protected.
source kernel/gcov/Kconfig
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 38dfcc2..ee2ca37 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -95,7 +95,7 @@ config X86
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
- select HAVE_RCU_USER_QS if X86_64
+ select HAVE_USER_HOOKS if X86_64
config INSTRUCTION_DECODER
def_bool (KPROBES || PERF_EVENTS || UPROBES)
diff --git a/arch/x86/include/asm/rcu.h b/arch/x86/include/asm/user_hooks.h
similarity index 56%
rename from arch/x86/include/asm/rcu.h
rename to arch/x86/include/asm/user_hooks.h
index 439815b..b5d10ef 100644
--- a/arch/x86/include/asm/rcu.h
+++ b/arch/x86/include/asm/user_hooks.h
@@ -1,19 +1,19 @@
-#ifndef _ASM_X86_RCU_H
-#define _ASM_X86_RCU_H
+#ifndef _ASM_X86_USER_HOOKS_H
+#define _ASM_X86_USER_HOOKS_H
-#include linux/rcupdate.h
+#include linux/user_hooks.h
#include asm/ptrace.h
static inline void exception_enter(struct pt_regs *regs)
{
- rcu_user_exit();
+ user_exit();
}
static inline void exception_exit(struct pt_regs *regs)
{
-#ifdef CONFIG_RCU_USER_QS
+#ifdef CONFIG_USER_HOOKS
if (user_mode(regs))
- rcu_user_enter();
+ user_enter();
#endif
}
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 9f94f8e..a8137b3 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -21,7 +21,7 @@
#include linux/signal.h
#include linux/perf_event.h
#include linux/hw_breakpoint.h
-#include linux/rcupdate.h
+#include linux/user_hooks.h
#include asm/uaccess.h
#include asm/pgtable.h
@@ -1464,7 +1464,7 @@ long syscall_trace_enter(struct pt_regs *regs)
{
[PATCH 2/5] cputime: Don't allow virtual and irq finegrained cputime accounting simultaneously
We may soon be able to run both at the same time. But we need to rework a bit the irq finegrained accounting before that. Just do a mutual exclusion for now. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Alessio Igor Bogani abog...@kernel.org Cc: Andrew Morton a...@linux-foundation.org Cc: Avi Kivity a...@redhat.com Cc: Chris Metcalf cmetc...@tilera.com Cc: Christoph Lameter c...@linux.com Cc: Geoff Levand ge...@infradead.org Cc: Gilad Ben Yossef gi...@benyossef.com Cc: Hakan Akkan hakanak...@gmail.com Cc: H. Peter Anvin h...@zytor.com Cc: Ingo Molnar mi...@kernel.org Cc: Kevin Hilman khil...@ti.com Cc: Max Krasnyansky m...@qualcomm.com Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Peter Zijlstra pet...@infradead.org Cc: Stephen Hemminger shemmin...@vyatta.com Cc: Steven Rostedt rost...@goodmis.org Cc: Sven-Thorsten Dietrich thebigcorporat...@gmail.com Cc: Thomas Gleixner t...@linutronix.de --- init/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 3348b85..21da9b7 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -269,7 +269,7 @@ config POSIX_MQUEUE_SYSCTL config VIRT_CPU_ACCOUNTING bool Deterministic task and CPU time accounting - depends on HAVE_VIRT_CPU_ACCOUNTING + depends on HAVE_VIRT_CPU_ACCOUNTING !IRQ_TIME_ACCOUNTING default y if PPC64 help Select this option to enable more accurate task and CPU time -- 1.7.5.4 -- 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 4/5] cputime: Rename account_system_vtime to account_vtime
account_system_vtime() can be called from random places:
hard/softirq entry/exit, kvm guest entry/exit, and even
context switches on powerpc.
Rename it to the even more generic account_vtime() name,
this reflect well that we are in a random place in the
kernel where we have either system, idle or user time
to account.
This way we can reuse the system version and expand it
with other domains such as user or idle to prepare
for the user hooks based virtual cputime accounting that
knows better when to flush the time for which domain of
execution.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Alessio Igor Bogani abog...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Avi Kivity a...@redhat.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Christoph Lameter c...@linux.com
Cc: Geoff Levand ge...@infradead.org
Cc: Gilad Ben Yossef gi...@benyossef.com
Cc: Hakan Akkan hakanak...@gmail.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Kevin Hilman khil...@ti.com
Cc: Max Krasnyansky m...@qualcomm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Sven-Thorsten Dietrich thebigcorporat...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
---
arch/ia64/kernel/time.c|4 ++--
arch/powerpc/kernel/time.c |8
arch/s390/kernel/vtime.c |4 ++--
include/linux/hardirq.h|8
include/linux/kvm_host.h |4 ++--
kernel/sched/cputime.c |8
kernel/softirq.c |6 +++---
7 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 7afcf93..03de550 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -116,7 +116,7 @@ void account_switch_vtime(struct task_struct *prev)
* Account time for a transition between system, hard irq or soft irq state.
* Note that this function is called with interrupts enabled.
*/
-void account_system_vtime(struct task_struct *tsk)
+void account_vtime(struct task_struct *tsk)
{
struct thread_info *ti = task_thread_info(tsk);
unsigned long flags;
@@ -138,7 +138,7 @@ void account_system_vtime(struct task_struct *tsk)
local_irq_restore(flags);
}
-EXPORT_SYMBOL_GPL(account_system_vtime);
+EXPORT_SYMBOL_GPL(account_vtime);
/*
* Called from the timer interrupt handler to charge accumulated user time
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 3f1918a..fba763d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -291,7 +291,7 @@ static inline u64 calculate_stolen_time(u64 stop_tb)
* Account time for a transition between system, hard irq
* or soft irq state.
*/
-void account_system_vtime(struct task_struct *tsk)
+void account_vtime(struct task_struct *tsk)
{
u64 now, nowscaled, delta, deltascaled;
unsigned long flags;
@@ -343,14 +343,14 @@ void account_system_vtime(struct task_struct *tsk)
}
local_irq_restore(flags);
}
-EXPORT_SYMBOL_GPL(account_system_vtime);
+EXPORT_SYMBOL_GPL(account_vtime);
/*
* Transfer the user and system times accumulated in the paca
* by the exception entry and exit code to the generic process
* user and system time records.
* Must be called with interrupts disabled.
- * Assumes that account_system_vtime() has been called recently
+ * Assumes that account_vtime() has been called recently
* (i.e. since the last entry from usermode) so that
* get_paca()-user_time_scaled is up to date.
*/
@@ -368,7 +368,7 @@ void account_process_tick_vtime(struct task_struct *tsk,
int user_tick)
void account_switch_vtime(struct task_struct *prev)
{
- account_system_vtime(prev);
+ account_vtime(prev);
account_process_tick(prev, 0);
}
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index 29f20fc..95f8105 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -108,7 +108,7 @@ void account_process_tick_vtime(struct task_struct *tsk,
int user_tick)
* Update process times based on virtual cpu times stored by entry.S
* to the lowcore fields user_timer, system_timer steal_clock.
*/
-void account_system_vtime(struct task_struct *tsk)
+void account_vtime(struct task_struct *tsk)
{
struct thread_info *ti = task_thread_info(tsk);
__u64 timer, system;
@@ -122,7 +122,7 @@ void account_system_vtime(struct task_struct *tsk)
ti-system_timer = S390_lowcore.system_timer;
account_system_time(tsk, 0, system, system);
}
-EXPORT_SYMBOL_GPL(account_system_vtime);
+EXPORT_SYMBOL_GPL(account_vtime);
void __kprobes vtime_stop_cpu(void)
{
diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
index bb7f309..6432e33 100644
--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@ -132,11 +132,11 @@ extern void synchronize_irq(unsigned int irq);
struct
[PATCH 5/5] cputime: Generic on-demand virtual cputime accounting
If we want to stop the tick further idle, we need to be
able to account the cputime without using the tick.
Virtual based cputime accounting solves that problem by
hooking into kernel/user boundaries.
However implementing CONFIG_VIRT_CPU_ACCOUNTING requires
to set low level hooks and involves more overhead. But
we already have a generic user hooks subsystem that is
required for RCU needs by archs which will want to
shut down the tick outside idle.
This patch implements a generic virtual based cputime
accounting that relies on these generic user hooks.
There are some upsides of doing this:
- This requires no arch code to implement CONFIG_VIRT_CPU_ACCOUNTING
if user hooks are already built (already necessary for RCU in full
tickless mode).
- We can rely on the generic user hooks subsystem to dynamically
(de)activate the hooks, so that we can switch anytime between virtual
and tick based accounting. This way we don't have the overhead
of the virtual accounting when the tick is running periodically.
And a few downsides:
- It relies on jiffies and the hooks are set in high level code. This
results in less precise cputime accounting than with a true native
virtual based cputime accounting which hooks on low level code and use
a cpu hardware clock. Precision is not the goal of this though.
- There is probably more overhead than a native virtual based cputime
accounting. But this relies on hooks that are already set anyway.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Alessio Igor Bogani abog...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Avi Kivity a...@redhat.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Christoph Lameter c...@linux.com
Cc: Geoff Levand ge...@infradead.org
Cc: Gilad Ben Yossef gi...@benyossef.com
Cc: Hakan Akkan hakanak...@gmail.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Kevin Hilman khil...@ti.com
Cc: Max Krasnyansky m...@qualcomm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Sven-Thorsten Dietrich thebigcorporat...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
---
include/asm-generic/cputime.h |2 +
include/linux/kernel_stat.h | 12 -
include/linux/user_hooks.h| 18 +++
init/Kconfig | 11 -
kernel/sched/cputime.c| 112 +
kernel/user_hooks.c | 10 ++--
6 files changed, 158 insertions(+), 7 deletions(-)
diff --git a/include/asm-generic/cputime.h b/include/asm-generic/cputime.h
index 212c8bb..2a78aa7 100644
--- a/include/asm-generic/cputime.h
+++ b/include/asm-generic/cputime.h
@@ -66,9 +66,11 @@ typedef u64 __nocast cputime64_t;
#define cputime64_to_clock_t(__ct) \
jiffies_64_to_clock_t(cputime64_to_jiffies64(__ct))
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_GEN
static inline bool accounting_vtime(void)
{
return false;
}
+#endif
#endif
diff --git a/include/linux/kernel_stat.h b/include/linux/kernel_stat.h
index 1270b86..6e509a9 100644
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -130,13 +130,23 @@ extern void account_process_tick(struct task_struct *,
int user);
extern void account_steal_ticks(unsigned long ticks);
extern void account_idle_ticks(unsigned long ticks);
+
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
extern void account_switch_vtime(struct task_struct *prev);
-extern bool account_process_tick_vtime(struct task_struct *p, int user_tick);
+extern void account_process_tick_vtime(struct task_struct *p, int user_tick);
#else
static inline void account_switch_vtime(struct task_struct *prev) { }
static inline void account_process_tick_vtime(struct task_struct *p,
int user_tick) { }
#endif
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
+void account_system_vtime(struct task_struct *tsk);
+void account_user_vtime(struct task_struct *tsk);
+bool accounting_vtime(void);
+#else
+static inline void account_system_vtime(struct task_struct *tsk) { }
+static inline void account_user_vtime(struct task_struct *tsk) { }
+#endif
+
#endif /* _LINUX_KERNEL_STAT_H */
diff --git a/include/linux/user_hooks.h b/include/linux/user_hooks.h
index 720292d..07385f1 100644
--- a/include/linux/user_hooks.h
+++ b/include/linux/user_hooks.h
@@ -3,6 +3,24 @@
#ifdef CONFIG_USER_HOOKS
#include linux/sched.h
+#include linux/percpu.h
+
+struct user_hooks {
+ bool hooking;
+ bool in_user;
+};
+
+DECLARE_PER_CPU(struct user_hooks, user_hooks);
+
+static inline bool in_user(void)
+{
+ return __get_cpu_var(user_hooks).in_user;
+}
+
+static inline bool user_hooks_hooking(void)
+{
+ return __get_cpu_var(user_hooks).hooking;
+}
extern void user_enter(void);
extern void user_exit(void);
diff --git a/init/Kconfig b/init/Kconfig
index 21da9b7..b0ed659 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@
[PATCH 3/5] cputime: Allow dynamic switch between tick/virtual based cputime accounting
Allow to dynamically switch between tick and virtual based cputime accounting.
This way we can provide a kind of on-demand virtual based cputime
accounting. In this mode, the kernel will rely on the user hooks
subsystem to dynamically hook on kernel boundaries.
This is in preparation for beeing able to stop the timer tick further
idle. Doing so will depend on CONFIG_VIRT_CPU_ACCOUNTING which makes
it possible to account the cputime without the tick by hooking on
kernel/user boundaries.
Depending whether the tick is stopped or not, we can switch between
tick and vtime based accounting anytime in order to minimize the
overhead associated to user hooks.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Alessio Igor Bogani abog...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Avi Kivity a...@redhat.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Christoph Lameter c...@linux.com
Cc: Geoff Levand ge...@infradead.org
Cc: Gilad Ben Yossef gi...@benyossef.com
Cc: Hakan Akkan hakanak...@gmail.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Kevin Hilman khil...@ti.com
Cc: Max Krasnyansky m...@qualcomm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Sven-Thorsten Dietrich thebigcorporat...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
---
arch/ia64/include/asm/cputime.h|5
arch/ia64/kernel/time.c|2 +-
arch/powerpc/include/asm/cputime.h |5
arch/powerpc/kernel/time.c |2 +-
arch/s390/include/asm/cputime.h|5
arch/s390/kernel/vtime.c |2 +-
include/asm-generic/cputime.h |5
include/linux/kernel_stat.h|3 ++
include/linux/sched.h |5 +---
kernel/fork.c |3 +-
kernel/sched/cputime.c | 39 +++
kernel/time/tick-sched.c | 28 -
12 files changed, 58 insertions(+), 46 deletions(-)
diff --git a/arch/ia64/include/asm/cputime.h b/arch/ia64/include/asm/cputime.h
index 3deac95..9532b9c 100644
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@ -103,5 +103,10 @@ static inline void cputime_to_timeval(const cputime_t ct,
struct timeval *val)
#define cputime64_to_clock_t(__ct) \
cputime_to_clock_t((__force cputime_t)__ct)
+static inline bool accounting_vtime(void)
+{
+ return true;
+}
+
#endif /* CONFIG_VIRT_CPU_ACCOUNTING */
#endif /* __IA64_CPUTIME_H */
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 6247197..7afcf93 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -144,7 +144,7 @@ EXPORT_SYMBOL_GPL(account_system_vtime);
* Called from the timer interrupt handler to charge accumulated user time
* to the current process. Must be called with interrupts disabled.
*/
-void account_process_tick(struct task_struct *p, int user_tick)
+void account_process_tick_vtime(struct task_struct *p, int user_tick)
{
struct thread_info *ti = task_thread_info(p);
cputime_t delta_utime;
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index 487d46f..901e0ac 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -228,6 +228,11 @@ static inline cputime_t clock_t_to_cputime(const unsigned
long clk)
#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
+static inline bool accounting_vtime(void)
+{
+ return true;
+}
+
#endif /* __KERNEL__ */
#endif /* CONFIG_VIRT_CPU_ACCOUNTING */
#endif /* __POWERPC_CPUTIME_H */
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 49da7f0..3f1918a 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -354,7 +354,7 @@ EXPORT_SYMBOL_GPL(account_system_vtime);
* (i.e. since the last entry from usermode) so that
* get_paca()-user_time_scaled is up to date.
*/
-void account_process_tick(struct task_struct *tsk, int user_tick)
+void account_process_tick_vtime(struct task_struct *tsk, int user_tick)
{
cputime_t utime, utimescaled;
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index 718374d..05ffda7 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -188,4 +188,9 @@ static inline int s390_nohz_delay(int cpu)
#define arch_needs_cpu(cpu) s390_nohz_delay(cpu)
+static inline bool accounting_vtime(void)
+{
+ return true;
+}
+
#endif /* _S390_CPUTIME_H */
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index 506e9bd..29f20fc 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -99,7 +99,7 @@ void account_switch_vtime(struct task_struct *prev)
S390_lowcore.system_timer = ti-system_timer;
}
-void account_process_tick(struct
Re: [PATCH] ivtv: Declare MODULE_FIRMWARE usage
On 07/26/2012 04:21 PM, Andy Walls wrote: On Thu, 2012-07-26 at 12:26 -0600, Tim Gardner wrote: Cc: Andy Walls awa...@md.metrocast.net Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: ivtv-de...@ivtvdriver.org Cc: linux-me...@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/ivtv/ivtv-firmware.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/video/ivtv/ivtv-firmware.c b/drivers/media/video/ivtv/ivtv-firmware.c index 02c5ade..6ec7705 100644 --- a/drivers/media/video/ivtv/ivtv-firmware.c +++ b/drivers/media/video/ivtv/ivtv-firmware.c @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where) return res; } + +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME); +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME); +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME); Only the PVR-350, based on the iTVC-15/CX23415 chip, needs the CX2341X_FIRM_DEC_FILENAME and IVTV_DECODE_INIT_MPEG_FILENAME. (And even in the case of that card, not having the IVTV_DECODE_INIT_MPEG_FILENAME file is non-fatal.) I would not want anything in user-space or kernel space preventing the ivtv module from loading, if some of those files don't exist. Regards, Andy MODULE_FIRMWARE is informational only and has no runtime impact. rtg -- Tim Gardner tim.gard...@canonical.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 0/3] add new API to sysfs and device core code
On Fri, Jul 27, 2012 at 12:02:40PM +0800, Bryan Wu wrote: Send out a uevent when create file in sysfs, which is required by userspace application such udev in Android There is no such thing as udev in Android the last time I looked. Has this changed? -- 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 4/7] bridge: call NETDEV_RELEASE notifier in br_del_if()
On Fri, 27 Jul 2012 23:38:01 +0800 Cong Wang amw...@redhat.com wrote: When a bridge interface deletes its underlying ports, it should notify netconsole too, like what bonding interface does. Cc: David S. Miller da...@davemloft.net Signed-off-by: Cong Wang amw...@redhat.com --- net/bridge/br_if.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index e1144e1..d243914 100644 --- a/net/bridge/br_if.c +++ b/net/bridge/br_if.c @@ -427,6 +427,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev) if (!p || p-br != br) return -EINVAL; + call_netdevice_notifiers(NETDEV_RELEASE, br-dev); del_nbp(p); spin_lock_bh(br-lock); Since you can have multiple ports attached to the bridge, this doesn't seem correct. Don't you want the netconsole to keep going on the other ports of the bridge? What exactly is the problem with having netconsole persist? -- 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/3] sysfs: introduce a sysfs_create_file_uevent new API
On Fri, Jul 27, 2012 at 12:02:41PM +0800, Bryan Wu wrote: Send a uevent notification whenever a new sysfs file is created to allow userspace processes such as udev to modify permissions on the new files. This makes no sense, why not just call kobject_uevent after creating the file when needed? Wrapping it up in a single function call doesn't add any benefit that I can see, can you? This new API function helps to do this. Signed-off-by: Bryan Wu bryan...@canonical.com --- fs/sysfs/file.c | 28 include/linux/sysfs.h | 13 + 2 files changed, 41 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index 00012e3..5a22d13 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -576,6 +576,34 @@ int sysfs_create_file(struct kobject * kobj, const struct attribute * attr) } +/** + * sysfs_create_file_uevent - create an attribute file for an object + and send a uevent to userspace. kerneldoc needs to be on one line for function names, right? greg k-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 12/24] xen/arm: Introduce xen_guest_init
On Fri, 27 Jul 2012, Ian Campbell wrote: On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote: We used to rely on a core_initcall to initialize Xen on ARM, however core_initcalls are actually called after early consoles are initialized. That means that hvc_xen.c is going to be initialized before Xen. Given the lack of a better alternative, just call a new Xen initialization function (xen_guest_init) from xen_cons_init. Can't we just arrange for this to be called super early on from setup_arch? That's got to be better than calling it from some random function which happens to get called early enough. While I agree with you that an explicit call to xen_guest_init from generic code might be better, xen_cons_init is not just a random function: it is a console_initcall and therefore we know for sure that it is going be the first one to be called. In fact if we didn't want the PV console to work so early we could just rely on a core_initcall to initialize everything and we wouldn't have any issues. In any case if the ARM maintainers agree I could add a generic hypervisor initialization call the end of setup_arch. I presume that KVM is going to want some similarly early init hooks etc and therefore ARM could benefit from the same sort of infrastructure as is in arch/x86/include/asm/hypervisor.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/
pull request: wireless 2012-07-27
commit 28ea499ac5b90f6266a24b826c6d469fc503758c
Dave,
These fixes are intended for the 3.6 stream.
Hauke Mehrtens provides a pair of bcma fixes, one to fix a build
regression on mips and another to correct a pair of missing iounmap
calls.
Thomas Huehn offers a mac80211_hwsim fix to avoid a possible
use-after-free bug.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 6ee127b7dd63afe4d6d0a58293786bf4bf336850:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2012-07-26
18:14:11 -0700)
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 28ea499ac5b90f6266a24b826c6d469fc503758c:
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
(2012-07-27 11:15:03 -0400)
Hauke Mehrtens (2):
bcma: fix regression in interrupt assignment on mips
bcma: add missing iounmap on error path
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into
for-davem
Thomas Huehn (1):
mac80211_hwsim: fix possible race condition in usage of info-control.sta
control.vif
drivers/bcma/driver_mips.c|6 +++---
drivers/bcma/scan.c | 15 ++-
drivers/net/wireless/mac80211_hwsim.c |5 -
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index b013b04..cc65b45 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -131,7 +131,7 @@ static void bcma_core_mips_set_irq(struct bcma_device *dev,
unsigned int irq)
/* backplane irq line is in use, find out who uses
* it and set user to irq 0
*/
- list_for_each_entry_reverse(core, bus-cores, list) {
+ list_for_each_entry(core, bus-cores, list) {
if ((1 bcma_core_mips_irqflag(core)) ==
oldirqflag) {
bcma_core_mips_set_irq(core, 0);
@@ -161,7 +161,7 @@ static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
{
struct bcma_device *core;
- list_for_each_entry_reverse(core, bus-cores, list) {
+ list_for_each_entry(core, bus-cores, list) {
bcma_core_mips_print_irq(core, bcma_core_mips_irq(core));
}
}
@@ -224,7 +224,7 @@ void bcma_core_mips_init(struct bcma_drv_mips *mcore)
mcore-assigned_irqs = 1;
/* Assign IRQs to all cores on the bus */
- list_for_each_entry_reverse(core, bus-cores, list) {
+ list_for_each_entry(core, bus-cores, list) {
int mips_irq;
if (core-irq)
continue;
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index 5672b13..8d0b571 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -462,8 +462,10 @@ int bcma_bus_scan(struct bcma_bus *bus)
while (eromptr eromend) {
struct bcma_device *other_core;
struct bcma_device *core = kzalloc(sizeof(*core), GFP_KERNEL);
- if (!core)
- return -ENOMEM;
+ if (!core) {
+ err = -ENOMEM;
+ goto out;
+ }
INIT_LIST_HEAD(core-list);
core-bus = bus;
@@ -478,7 +480,7 @@ int bcma_bus_scan(struct bcma_bus *bus)
} else if (err == -ESPIPE) {
break;
}
- return err;
+ goto out;
}
core-core_index = core_num++;
@@ -494,10 +496,12 @@ int bcma_bus_scan(struct bcma_bus *bus)
list_add_tail(core-list, bus-cores);
}
+ err = 0;
+out:
if (bus-hosttype == BCMA_HOSTTYPE_SOC)
iounmap(eromptr);
- return 0;
+ return err;
}
int __init bcma_bus_scan_early(struct bcma_bus *bus,
@@ -537,7 +541,7 @@ int __init bcma_bus_scan_early(struct bcma_bus *bus,
else if (err == -ESPIPE)
break;
else if (err 0)
- return err;
+ goto out;
core-core_index = core_num++;
bus-nr_cores++;
@@ -551,6 +555,7 @@ int __init bcma_bus_scan_early(struct bcma_bus *bus,
break;
}
+out:
if (bus-hosttype == BCMA_HOSTTYPE_SOC)
iounmap(eromptr);
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 643f968..0083839 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@
[GIT PULL] kmap_atomic final cleanups for 3.6
Hi, Linus, Please pull my kmap_atomic cleanup's for 3.6, git://github.com/congwang/linux.git kmap_atomic this should be the final round of cleanup, as the definitions of enum km_type finally get removed from the whole tree. The patches stay in linux-next for a long time. Thanks! Cong Wang (14): jbd2: remove the second argument of kmap_atomic frv: remove the second parameter of kmap_atomic_primary() tile: remove usage of enum km_type highmem: remove the deprecated form of kmap_atomic arm: remove km_type definitions powerpc: remove km_type definitions frv: remove km_type definitions avr32: remove km_type definitions asm-generic: remove km_type definitions um: remove km_type definitions tile: remove km_type definitions feature-removal-schedule.txt: remove kmap_atomic(page, km_type) vmalloc: remove KM_USER0 from comments pipe: remove KM_USER0 from comments Documentation/feature-removal-schedule.txt |8 - arch/arm/include/asm/kmap_types.h | 26 +- arch/avr32/include/asm/kmap_types.h| 24 +--- arch/frv/include/asm/highmem.h | 34 ++- arch/frv/include/asm/kmap_types.h | 24 +--- arch/frv/mb93090-mb00/pci-dma.c|4 +- arch/frv/mm/cache-page.c |8 +++--- arch/frv/mm/highmem.c | 20 +++--- arch/powerpc/include/asm/kmap_types.h | 31 + arch/tile/include/asm/kmap_types.h | 31 + arch/tile/mm/highmem.c |2 +- arch/um/include/asm/kmap_types.h | 18 +--- fs/jbd2/commit.c |4 +- fs/pipe.c |2 +- include/asm-generic/kmap_types.h | 34 +- include/linux/highmem.h| 41 +--- include/linux/pipe_fs_i.h |8 ++--- mm/vmalloc.c |8 + 18 files changed, 44 insertions(+), 283 deletions(-) -- 1.7.7.6 -- 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 2/4] ACPI: Update CPU hotplug messages
On Thu, Jul 26, 2012 at 8:39 PM, Toshi Kani toshi.k...@hp.com wrote:
On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani toshi.k...@hp.com wrote:
@@ -560,8 +565,7 @@ static int __cpuinit acpi_processor_add(struct
acpi_device *device)
*/
if (per_cpu(processor_device_array, pr-id) != NULL
per_cpu(processor_device_array, pr-id) != device) {
- printk(KERN_WARNING BIOS reported wrong ACPI id
- for the processor\n);
+ pr_warn(BIOS reported wrong ACPI id for the processor\n);
And this.
Changed to use dev_warn().
Is there additional information you could print here, like the pr-id?
I don't understand the data structures here, so maybe there isn't.
@@ -727,17 +731,19 @@ static void
acpi_processor_hotplug_notify(acpi_handle handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- pr_err(PREFIX Device don't exist, dropping
EJECT\n);
+ acpi_pr_err(handle,
+ Device don't exist, dropping EJECT\n);
break;
}
if (!acpi_driver_data(device)) {
- pr_err(PREFIX Driver data is NULL, dropping
EJECT\n);
+ acpi_pr_err(handle,
+ Driver data is NULL, dropping EJECT\n);
And this.
No change since it is called directly from the handler.
True, but by this point, we have a valid acpi_device *, don't we? We
called acpi_driver_data(device), which requires device to be valid.
break;
}
ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
if (!ej_event) {
- pr_err(PREFIX No memory, dropping EJECT\n);
+ acpi_pr_err(handle, No memory, dropping EJECT\n);
And this.
No change since it is called directly from the handler.
break;
}
@@ -847,7 +853,7 @@ static acpi_status acpi_processor_hotadd_init(struct
acpi_processor *pr)
* and do it when the CPU gets online the first time
* TBD: Cleanup above functions and try to do this more elegant.
*/
- printk(KERN_INFO CPU %d got hotplugged\n, pr-id);
+ pr_info(CPU %d got hotplugged\n, pr-id);
And this. The caller (acpi_processor_get_info()) has an acpi_device
*, so we should be able to use it here.
I think pr_info() is fine since it is a normal message and already has
CPU number in the message.
Is there another message that correlates the device name
(ACPI0007:xx) with the CPU number? That correlation seems useful.
My mindset is that a driver should *always* use dev_level() when
possible, but I won't belabor the point.
Bjorn
--
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 12/24] xen/arm: Introduce xen_guest_init
On Fri, 2012-07-27 at 16:54 +0100, Stefano Stabellini wrote: On Fri, 27 Jul 2012, Ian Campbell wrote: On Thu, 2012-07-26 at 16:33 +0100, Stefano Stabellini wrote: We used to rely on a core_initcall to initialize Xen on ARM, however core_initcalls are actually called after early consoles are initialized. That means that hvc_xen.c is going to be initialized before Xen. Given the lack of a better alternative, just call a new Xen initialization function (xen_guest_init) from xen_cons_init. Can't we just arrange for this to be called super early on from setup_arch? That's got to be better than calling it from some random function which happens to get called early enough. While I agree with you that an explicit call to xen_guest_init from generic code might be better, xen_cons_init is not just a random function: it is a console_initcall and therefore we know for sure that it is going be the first one to be called. Initialising something != console in a console_initcall just because it happens to be called early enough meets my definition of calling it from a random place. In fact if we didn't want the PV console to work so early we could just rely on a core_initcall to initialize everything and we wouldn't have any issues. In any case if the ARM maintainers agree I could add a generic hypervisor initialization call the end of setup_arch. I presume that KVM is going to want some similarly early init hooks etc and therefore ARM could benefit from the same sort of infrastructure as is in arch/x86/include/asm/hypervisor.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: lockdep trace from posix timers
On Tue, Jul 24, 2012 at 04:36:13PM -0400, Dave Jones wrote:
Linus tree as of 5fecc9d8f59e765c2a48379dd7c6f5cf88c7d75a
Dave
==
[ INFO: HARDIRQ-safe - HARDIRQ-unsafe lock order detected ]
3.5.0+ #122 Not tainted
--
trinity-child2/5327 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
blocked: (tasklist_lock){.+.+..}, instance: 81c05098, at:
[8109762b] posix_cpu_timer_del+0x2b/0xe0
and this task is already holding:
blocked: ((new_timer-it_lock)-rlock){-.-...}, instance:
880143bce170, at: [81093d49] __lock_timer+0x89/0x1f0
which would create a new lock dependency:
((new_timer-it_lock)-rlock){-.-...} - (tasklist_lock){.+.+..}
but this new dependency connects a HARDIRQ-irq-safe lock:
((new_timer-it_lock)-rlock){-.-...}
... which became HARDIRQ-irq-safe at:
Shall I start bisecting this ? I can trigger it very easily, but if you
can give me a set of commits to narrow down, it'll speed up the bisection.
Dave
--
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 18/24] xen/arm: compile blkfront and blkback
On Fri, 27 Jul 2012, Ian Campbell wrote: On Thu, 2012-07-26 at 16:34 +0100, Stefano Stabellini wrote: +#define XEN_IO_PROTO_ABI_ARMarm-abi I wonder if we ought to call this arm-aarch32-abi or something? So aarch64 has just been renamed to arm64 and you want to rename arm-abi to aarch32-abi? :-) I wonder if we can also take the opportunity to fix the ABI cockup for disks on ARM and make the structs the same for both 32 and 64 bit? I think it should be a separate patch, but I'll try to come up with one -- 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 RFC/RFT] i2c/busses: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y CONFIG_I2C_DESIGNWARE_PCI=y
Hi Axel, On Wed, 13 Jun 2012 20:51:37 +0800, Axel Lin wrote: This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE. Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as built-in or module, we also need to export the functions in i2c-designware-core. This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y CONFIG_I2C_DESIGNWARE_PCI=y: LD drivers/i2c/busses/built-in.o drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int': i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init': i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl': i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr': i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer': i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled': i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel': i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg': i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable': i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param': i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable': i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func': i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int': i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here make[3]: *** [drivers/i2c/busses/built-in.o] Error 1 make[2]: *** [drivers/i2c/busses] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Error 2 Signed-off-by: Axel Lin axel@gmail.com --- I don't have this hardware, just try to fix the build error I found. Good catch. I can't test it either but your patch looks sane. Wolfram, I think these drivers are mostly used on embedded platforms so it would make more sense that you (or Ben) pick it. Please let me know if you want _me_ to take it for whatever reason. I also think this patch should go to stable kernel trees 3.2 and later, as it fixes a build bug. -- Jean Delvare -- 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/5] user_hooks: New user hooks subsystem
On Fri, Jul 27, 2012 at 05:40:30PM +0200, Frederic Weisbecker wrote:
Create a new subsystem that handles the hooks on kernel/user
boundaries currently used by RCU for its userspace extended
quiescent state.
We need to pull this up from RCU into this new level of indirection
because these hooks are also going to be used to implement an on
demand generic virtual cputime accounting. A necessary step to
shutdown the tick while still accounting the cputime.
So this eliminates the case where the architecture might enter an
RCU extended quiescent state multiple times, but exit it only once?
(I am hoping that it does...)
Thanx, Paul
[ . . . ]
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 318d00e..f6a24cb 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -212,9 +212,6 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
.dynticks_nesting = DYNTICK_TASK_EXIT_IDLE,
.dynticks = ATOMIC_INIT(1),
-#if defined(CONFIG_RCU_USER_QS) !defined(CONFIG_RCU_USER_QS_FORCE)
- .ignore_user_qs = true,
-#endif
};
static int blimit = 10; /* Maximum callbacks per rcu_do_batch.
*/
@@ -448,18 +445,7 @@ EXPORT_SYMBOL_GPL(rcu_idle_enter);
*/
void rcu_user_enter(void)
{
- unsigned long flags;
- struct rcu_dynticks *rdtp;
-
- WARN_ON_ONCE(!current-mm);
-
- local_irq_save(flags);
- rdtp = __get_cpu_var(rcu_dynticks);
- if (!rdtp-ignore_user_qs !rdtp-in_user) {
- rdtp-in_user = true;
- rcu_eqs_enter(1);
- }
- local_irq_restore(flags);
+ rcu_eqs_enter(1);
}
EXPORT_SYMBOL_GPL(rcu_user_enter);
@@ -597,16 +583,7 @@ EXPORT_SYMBOL_GPL(rcu_idle_exit);
*/
void rcu_user_exit(void)
{
- unsigned long flags;
- struct rcu_dynticks *rdtp;
-
- local_irq_save(flags);
- rdtp = __get_cpu_var(rcu_dynticks);
- if (rdtp-in_user) {
- rdtp-in_user = false;
- rcu_eqs_exit(1);
- }
- local_irq_restore(flags);
+ rcu_eqs_exit(1);
}
EXPORT_SYMBOL_GPL(rcu_user_exit);
@@ -730,21 +707,6 @@ int rcu_is_cpu_idle(void)
}
EXPORT_SYMBOL(rcu_is_cpu_idle);
-#ifdef CONFIG_RCU_USER_QS
-void rcu_user_hooks_switch(struct task_struct *prev,
-struct task_struct *next)
-{
- struct rcu_dynticks *rdtp;
-
- /* Interrupts are disabled in context switch */
- rdtp = __get_cpu_var(rcu_dynticks);
- if (!rdtp-ignore_user_qs) {
- clear_tsk_thread_flag(prev, TIF_NOHZ);
- set_tsk_thread_flag(next, TIF_NOHZ);
- }
-}
-#endif /* #ifdef CONFIG_RCU_USER_QS */
-
#if defined(CONFIG_PROVE_RCU) defined(CONFIG_HOTPLUG_CPU)
/*
[ . . . ]
--
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 v3] cx18: Declare MODULE_FIRMWARE usage
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx18/cx18-av-firmware.c |2 ++
drivers/media/video/cx18/cx18-driver.c |1 +
drivers/media/video/cx18/cx18-dvb.c |6 +-
drivers/media/video/cx18/cx18-firmware.c| 10 --
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-av-firmware.c
b/drivers/media/video/cx18/cx18-av-firmware.c
index 280aa4d..a34fd08 100644
--- a/drivers/media/video/cx18/cx18-av-firmware.c
+++ b/drivers/media/video/cx18/cx18-av-firmware.c
@@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
release_firmware(fw);
return 0;
}
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
module_init(module_start);
module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-dvb.c
b/drivers/media/video/cx18/cx18-dvb.c
index f41922b..3eac59c 100644
--- a/drivers/media/video/cx18/cx18-dvb.c
+++ b/drivers/media/video/cx18/cx18-dvb.c
@@ -40,6 +40,8 @@
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+#define FWFILE dvb-cx18-mpc718-mt352.fw
+
#define CX18_REG_DMUX_NUM_PORT_0_CONTROL 0xd5a000
#define CX18_CLOCK_ENABLE2 0xc71024
#define CX18_DMUX_CLK_MASK 0x0080
@@ -135,7 +137,7 @@ static int yuan_mpc718_mt352_reqfw(struct cx18_stream
*stream,
const struct firmware **fw)
{
struct cx18 *cx = stream-cx;
- const char *fn = dvb-cx18-mpc718-mt352.fw;
+ const char *fn = FWFILE;
int ret;
ret = request_firmware(fw, fn, cx-pci_dev-dev);
@@ -603,3 +605,5 @@ static int dvb_register(struct cx18_stream *stream)
return ret;
}
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
}
+#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
+#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
+
int cx18_firmware_init(struct cx18 *cx)
{
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
- sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem, cx);
+ sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
if (sz = 0)
return sz;
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
fw_entry_addr = 0;
- sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
+ sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
fw_entry_addr);
if (sz = 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
}
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
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/
[PATCH v2 1/2] hw_random: mxc-rnga: Adapt clocks to new i.mx clock framework
Adapt clocks to the new i.mx clock framework and fix the following warning:
[ cut here ]
WARNING: at drivers/clk/clk.c:511 __clk_enable+0x9c/0xac()
Modules linked in:
Backtrace:
[800124c8] (dump_backtrace+0x0/0x10c) from [804172dc] (dump_stack+0x18/0x1c)
r7:0009 r6:01ff r5:8032cb50 r4:
[804172c4] (dump_stack+0x0/0x1c) from [80021834] (warn_slowpath_common+0x54)
[800217e0] (warn_slowpath_common+0x0/0x6c) from [80021870] (warn_slowpath_n)
r9:80581cac r8:8700a9c0 r7:805ab070 r6:8013 r5:806133d4
r4:8700a9c0
[8002184c] (warn_slowpath_null+0x0/0x2c) from [8032cb50] (__clk_enable+0x9c)
[8032cab4] (__clk_enable+0x0/0xac) from [8032cb88] (clk_enable+0x28/0x44)
r5:806133d4 r4:8700a9c0
[8032cb60] (clk_enable+0x0/0x44) from [80560f14] (mxc_rnga_probe+0x68/0x164)
r7:805ab070 r6:8706ec00 r5:80611314 r4:
[80560eac] (mxc_rnga_probe+0x0/0x164) from [8025914c] (platform_drv_probe+0)
[8025912c] (platform_drv_probe+0x0/0x24) from [80257c7c] (driver_probe_devi)
[80257bfc] (driver_probe_device+0x0/0x204) from [80257e94] (__driver_attach)
r9:80581cac r8:008e r7: r6:8706ec3c r5:805ab070
r4:8706ec08
[80257e00] (__driver_attach+0x0/0x98) from [8025642c] (bus_for_each_dev+0x6)
r7: r6:80257e00 r5:87035e98 r4:805ab070
[802563c4] (bus_for_each_dev+0x0/0x94) from [80257adc] (driver_attach+0x20/)
r7: r6:873f2380 r5:805ab338 r4:805ab070
[80257abc] (driver_attach+0x0/0x28) from [80256d50] (bus_add_driver+0x18c/0)
[80256bc4] (bus_add_driver+0x0/0x268) from [802584c4] (driver_register+0x80)
[80258444] (driver_register+0x0/0x134) from [802594f4] (platform_driver_reg)
r7: r6:805c2e00 r5:0007 r4:805ab05c
[802594a8] (platform_driver_register+0x0/0x60) from [80259528] (platform_dr)
[80259508] (platform_driver_probe+0x0/0xa4) from [80560ea0] (mod_init+0x18/)
r7: r6:805c2e00 r5:0007 r4:87034000
[80560e88] (mod_init+0x0/0x24) from [800086b4] (do_one_initcall+0x40/0x194)
[80008674] (do_one_initcall+0x0/0x194) from [8053d3f4] (kernel_init+0xfc/0x)
[8053d2f8] (kernel_init+0x0/0x1cc) from [80027190] (do_exit+0x0/0x7ec)
---[ end trace 4198eed02050f461 ]---
mxc_rnga mxc_rnga: MXC RNGA Registered
Cc: Theodore Ts'o ty...@mit.edu
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Converted a missing 'clk_disable' to 'clk_disable_unprepare'
drivers/char/hw_random/mxc-rnga.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/mxc-rnga.c
b/drivers/char/hw_random/mxc-rnga.c
index 85074de..62c7efe 100644
--- a/drivers/char/hw_random/mxc-rnga.c
+++ b/drivers/char/hw_random/mxc-rnga.c
@@ -152,14 +152,14 @@ static int __init mxc_rnga_probe(struct platform_device
*pdev)
if (rng_dev)
return -EBUSY;
- clk = clk_get(pdev-dev, rng);
+ clk = clk_get(pdev-dev, NULL);
if (IS_ERR(clk)) {
dev_err(pdev-dev, Could not get rng_clk!\n);
err = PTR_ERR(clk);
goto out;
}
- clk_enable(clk);
+ clk_prepare_enable(clk);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -201,7 +201,7 @@ err_ioremap:
release_mem_region(res-start, resource_size(res));
err_region:
- clk_disable(clk);
+ clk_disable_unprepare(clk);
clk_put(clk);
out:
@@ -212,7 +212,7 @@ static int __exit mxc_rnga_remove(struct platform_device
*pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
void __iomem *rng_base = (void __iomem *)mxc_rnga.priv;
- struct clk *clk = clk_get(pdev-dev, rng);
+ struct clk *clk = clk_get(pdev-dev, NULL);
hwrng_unregister(mxc_rnga);
@@ -220,7 +220,7 @@ static int __exit mxc_rnga_remove(struct platform_device
*pdev)
release_mem_region(res-start, resource_size(res));
- clk_disable(clk);
+ clk_disable_unprepare(clk);
clk_put(clk);
return 0;
--
1.7.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
[PATCH v2 2/2] hw_random: mxc-rnga: Access data via structure
In current driver, everytime we need to access the rng clock (,ie to enable or
disable it) a call to clk_get is done.
This is not correct and the preferred way is to provide a rng data structure
that could be used for accessing rng resources.
Cc: Theodore Ts'o ty...@mit.edu
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- No changes. Newly introduced in this version
drivers/char/hw_random/mxc-rnga.c | 108 +---
1 files changed, 51 insertions(+), 57 deletions(-)
diff --git a/drivers/char/hw_random/mxc-rnga.c
b/drivers/char/hw_random/mxc-rnga.c
index 62c7efe..f05d857 100644
--- a/drivers/char/hw_random/mxc-rnga.c
+++ b/drivers/char/hw_random/mxc-rnga.c
@@ -59,16 +59,21 @@
#define RNGA_STATUS_LAST_READ_STATUS 0x0002
#define RNGA_STATUS_SECURITY_VIOLATION 0x0001
-static struct platform_device *rng_dev;
+struct mxc_rng {
+ struct device *dev;
+ struct hwrng rng;
+ void __iomem *mem;
+ struct clk *clk;
+};
static int mxc_rnga_data_present(struct hwrng *rng, int wait)
{
- void __iomem *rng_base = (void __iomem *)rng-priv;
int i;
+ struct mxc_rng *mxc_rng = container_of(rng, struct mxc_rng, rng);
for (i = 0; i 20; i++) {
/* how many random numbers are in FIFO? [0-16] */
- int level = (__raw_readl(rng_base + RNGA_STATUS)
+ int level = (__raw_readl(mxc_rng-mem + RNGA_STATUS)
RNGA_STATUS_LEVEL_MASK) 8;
if (level || !wait)
return !!level;
@@ -81,20 +86,20 @@ static int mxc_rnga_data_read(struct hwrng *rng, u32 * data)
{
int err;
u32 ctrl;
- void __iomem *rng_base = (void __iomem *)rng-priv;
+ struct mxc_rng *mxc_rng = container_of(rng, struct mxc_rng, rng);
/* retrieve a random number from FIFO */
- *data = __raw_readl(rng_base + RNGA_OUTPUT_FIFO);
+ *data = __raw_readl(mxc_rng-mem + RNGA_OUTPUT_FIFO);
/* some error while reading this random number? */
- err = __raw_readl(rng_base + RNGA_STATUS) RNGA_STATUS_ERROR_INT;
+ err = __raw_readl(mxc_rng-mem + RNGA_STATUS) RNGA_STATUS_ERROR_INT;
/* if error: clear error interrupt, but doesn't return random number */
if (err) {
- dev_dbg(rng_dev-dev, Error while reading random number!\n);
- ctrl = __raw_readl(rng_base + RNGA_CONTROL);
+ dev_dbg(mxc_rng-dev, Error while reading random number!\n);
+ ctrl = __raw_readl(mxc_rng-mem + RNGA_CONTROL);
__raw_writel(ctrl | RNGA_CONTROL_CLEAR_INT,
- rng_base + RNGA_CONTROL);
+ mxc_rng-mem + RNGA_CONTROL);
return 0;
} else
return 4;
@@ -103,22 +108,22 @@ static int mxc_rnga_data_read(struct hwrng *rng, u32 *
data)
static int mxc_rnga_init(struct hwrng *rng)
{
u32 ctrl, osc;
- void __iomem *rng_base = (void __iomem *)rng-priv;
+ struct mxc_rng *mxc_rng = container_of(rng, struct mxc_rng, rng);
/* wake up */
- ctrl = __raw_readl(rng_base + RNGA_CONTROL);
- __raw_writel(ctrl ~RNGA_CONTROL_SLEEP, rng_base + RNGA_CONTROL);
+ ctrl = __raw_readl(mxc_rng-mem + RNGA_CONTROL);
+ __raw_writel(ctrl ~RNGA_CONTROL_SLEEP, mxc_rng-mem + RNGA_CONTROL);
/* verify if oscillator is working */
- osc = __raw_readl(rng_base + RNGA_STATUS);
+ osc = __raw_readl(mxc_rng-mem + RNGA_STATUS);
if (osc RNGA_STATUS_OSC_DEAD) {
- dev_err(rng_dev-dev, RNGA Oscillator is dead!\n);
+ dev_err(mxc_rng-dev, RNGA Oscillator is dead!\n);
return -ENODEV;
}
/* go running */
- ctrl = __raw_readl(rng_base + RNGA_CONTROL);
- __raw_writel(ctrl | RNGA_CONTROL_GO, rng_base + RNGA_CONTROL);
+ ctrl = __raw_readl(mxc_rng-mem + RNGA_CONTROL);
+ __raw_writel(ctrl | RNGA_CONTROL_GO, mxc_rng-mem + RNGA_CONTROL);
return 0;
}
@@ -126,40 +131,40 @@ static int mxc_rnga_init(struct hwrng *rng)
static void mxc_rnga_cleanup(struct hwrng *rng)
{
u32 ctrl;
- void __iomem *rng_base = (void __iomem *)rng-priv;
+ struct mxc_rng *mxc_rng = container_of(rng, struct mxc_rng, rng);
- ctrl = __raw_readl(rng_base + RNGA_CONTROL);
+ ctrl = __raw_readl(mxc_rng-mem + RNGA_CONTROL);
/* stop rnga */
- __raw_writel(ctrl ~RNGA_CONTROL_GO, rng_base + RNGA_CONTROL);
+ __raw_writel(ctrl ~RNGA_CONTROL_GO, mxc_rng-mem + RNGA_CONTROL);
}
-static struct hwrng mxc_rnga = {
- .name = mxc-rnga,
- .init = mxc_rnga_init,
- .cleanup = mxc_rnga_cleanup,
- .data_present = mxc_rnga_data_present,
- .data_read = mxc_rnga_data_read
-};
-
static int
Re: [Xen-devel] [PATCH 06/24] xen: missing includes
On Fri, 27 Jul 2012, Jan Beulich wrote: On 26.07.12 at 17:33, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -10,7 +10,10 @@ #define __XEN_PUBLIC_XEN_H__ #include asm/xen/interface.h +#include linux/types.h +#ifdef CONFIG_X86 #include asm/pvclock-abi.h +#endif Rather than hacking around this, why not clean it up: asm/pvclock-abi.h clearly isn't intended to be included here (from the perspective of the origin of xen/interface/xen.h, at least), nor is linux/types.h. Or if it is really needed to deviate from the original header in this respect, then clearly the inclusion ought to not be arch specific or be moved to an arch specific header. I think you are right: linux/types.h is not actually needed and pvclock-abi.h should probably be included by asm/xen/interface.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: [Xen-devel] [PATCH 10/24] xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
On Fri, 27 Jul 2012, Jan Beulich wrote: On 26.07.12 at 17:33, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -1,11 +1,15 @@ -obj-y += grant-table.o features.o events.o manage.o balloon.o +ifneq ($(CONFIG_ARM),y) +obj-y += manage.o balloon.o While I assume that this part (and the cpu_hotplug one below) is temporary, ... +obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o ... at least this one should imo be solved with a proper long term mechanism, i.e. the usual var-$(CONFIG_...) approach, i.e. dom0-$(CONFIG_PCI) := pci.o dom0-$(CONFIG_ACPI) := acpi.o obj-$(CONFIG_XEN_DOM0)+= $(dom0-y) That's a good suggestion, 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/
[PATCH V2 3/4] PCI: Add support for non-BAR ROMs
Platforms may provide their own mechanisms for obtaining ROMs. Add support
for using data provided by the platform in that case.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Seth Forshee seth.fors...@canonical.com
---
drivers/pci/rom.c |9 -
include/linux/pci.h |2 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 48ebdb2..f913ce3 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -126,6 +126,12 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
/* primary video rom always starts here */
start = (loff_t)0xC;
*size = 0x2; /* cover C000:0 through E000:0 */
+ /*
+* Some devices may provide ROMs via a source other than the BAR
+*/
+ } else if (pdev-rom pdev-romlen) {
+ *size = pdev-romlen;
+ return (void __iomem *)phys_to_virt(pdev-rom);
} else {
if (res-flags
(IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
@@ -219,7 +225,8 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
if (res-flags (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY))
return;
- iounmap(rom);
+ if (!pdev-rom || !pdev-romlen)
+ iounmap(rom);
/* Disable again before continuing, leave enabled if pci=rom */
if (!(res-flags (IORESOURCE_ROM_ENABLE | IORESOURCE_ROM_SHADOW)))
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6a2625c..2668bb9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -355,6 +355,8 @@ struct pci_dev {
};
struct pci_ats *ats; /* Address Translation Service */
#endif
+ void *rom; /* Physical pointer to ROM if it's not from the BAR */
+ size_t romlen; /* Length of ROM if it's not from the BAR */
};
static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
--
1.7.10.4
--
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 v2] ene_ub6250: Use macros for firmware names
Advertise firmware files using MODULE_FIRMWARE macros. Fix a debug string: SD_RDWR_PATTERN -- SD_RW_PATTERN Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-...@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/usb/storage/ene_ub6250.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers/usb/storage/ene_ub6250.c index b28f2ad..95edee5 100644 --- a/drivers/usb/storage/ene_ub6250.c +++ b/drivers/usb/storage/ene_ub6250.c @@ -29,9 +29,21 @@ #include protocol.h #include debug.h +#define SD_INIT1_FIRMWARE ene-ub6250/sd_init1.bin +#define SD_INIT2_FIRMWARE ene-ub6250/sd_init2.bin +#define SD_RW_FIRMWARE ene-ub6250/sd_rdwr.bin +#define MS_INIT_FIRMWARE ene-ub6250/ms_init.bin +#define MSP_RW_FIRMWARE ene-ub6250/msp_rdwr.bin +#define MS_RW_FIRMWARE ene-ub6250/ms_rdwr.bin + MODULE_DESCRIPTION(Driver for ENE UB6250 reader); MODULE_LICENSE(GPL); - +MODULE_FIRMWARE(SD_INIT1_FIRMWARE); +MODULE_FIRMWARE(SD_INIT2_FIRMWARE); +MODULE_FIRMWARE(SD_RW_FIRMWARE); +MODULE_FIRMWARE(MS_INIT_FIRMWARE); +MODULE_FIRMWARE(MSP_RW_FIRMWARE); +MODULE_FIRMWARE(MS_RW_FIRMWARE); /* * The table of devices @@ -1883,28 +1895,28 @@ static int ene_load_bincode(struct us_data *us, unsigned char flag) /* For SD */ case SD_INIT1_PATTERN: US_DEBUGP(SD_INIT1_PATTERN\n); - fw_name = ene-ub6250/sd_init1.bin; + fw_name = SD_INIT1_FIRMWARE; break; case SD_INIT2_PATTERN: US_DEBUGP(SD_INIT2_PATTERN\n); - fw_name = ene-ub6250/sd_init2.bin; + fw_name = SD_INIT2_FIRMWARE; break; case SD_RW_PATTERN: - US_DEBUGP(SD_RDWR_PATTERN\n); - fw_name = ene-ub6250/sd_rdwr.bin; + US_DEBUGP(SD_RW_PATTERN\n); + fw_name = SD_RW_FIRMWARE; break; /* For MS */ case MS_INIT_PATTERN: US_DEBUGP(MS_INIT_PATTERN\n); - fw_name = ene-ub6250/ms_init.bin; + fw_name = MS_INIT_FIRMWARE; break; case MSP_RW_PATTERN: US_DEBUGP(MSP_RW_PATTERN\n); - fw_name = ene-ub6250/msp_rdwr.bin; + fw_name = MSP_RW_FIRMWARE; break; case MS_RW_PATTERN: US_DEBUGP(MS_RW_PATTERN\n); - fw_name = ene-ub6250/ms_rdwr.bin; + fw_name = MS_RW_FIRMWARE; break; default: US_DEBUGP(--- Unknown PATTERN --\n); -- 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 1/2] hw_random: mxc-rnga: Adapt clocks to new i.mx clock framework
On Mon, Jul 9, 2012 at 4:41 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Uhh, that's a driver bug that should be fixed. Although right now there is no reference counting for clocks, the driver should keep the clk internally instead of simply calling clk_get whenever it needs access to a clk. Yes, I just sent a fix for 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 V2 4/4] X86: Use PCI setup data
EFI can provide PCI ROMs out of band via boot services, which may not be
available after boot. Add support for using the data handed off to us by
the boot stub or bootloader.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Seth Forshee seth.fors...@canonical.com
---
arch/x86/pci/common.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 720e973f..3d2752f 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -17,6 +17,7 @@
#include asm/io.h
#include asm/smp.h
#include asm/pci_x86.h
+#include asm/setup.h
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
@@ -608,6 +609,38 @@ unsigned int pcibios_assign_all_busses(void)
return (pci_probe PCI_ASSIGN_ALL_BUSSES) ? 1 : 0;
}
+int pcibios_add_device(struct pci_dev *dev)
+{
+ struct setup_data *data;
+ struct pci_setup_rom *rom;
+ u64 pa_data;
+
+ if (boot_params.hdr.version 0x0209)
+ return 0;
+
+ pa_data = boot_params.hdr.setup_data;
+ while (pa_data) {
+ data = phys_to_virt(pa_data);
+
+ if (data-type == SETUP_PCI) {
+ rom = (struct pci_setup_rom *)data;
+
+ if ((pci_domain_nr(dev-bus) == rom-segment)
+ (dev-bus-number == rom-bus)
+ (PCI_SLOT(dev-devfn) == rom-device)
+ (PCI_FUNC(dev-devfn) == rom-function)
+ (dev-vendor == rom-vendor)
+ (dev-device == rom-devid)) {
+ dev-rom = (void *)(pa_data +
+ offsetof(struct pci_setup_rom, romdata));
+ dev-romlen = rom-pcilen;
+ }
+ }
+ pa_data = data-next;
+ }
+ return 0;
+}
+
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
int err;
--
1.7.10.4
--
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 V2 2/4] PCI: Add pcibios_add_device
Platforms may want to provide architecture-specific functionality during
PCI enumeration. Add a pcibios_add_device() call that architectures can
override to do so.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Seth Forshee seth.fors...@canonical.com
---
drivers/pci/bus.c |5 +
drivers/pci/pci.c | 13 +
include/linux/pci.h |1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 4b0970b..e2f447e 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -166,6 +166,11 @@ int pci_bus_add_device(struct pci_dev *dev)
int retval;
pci_fixup_device(pci_fixup_final, dev);
+
+ retval = pcibios_add_device(dev);
+ if (retval)
+ return retval;
+
retval = device_add(dev-dev);
if (retval)
return retval;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f3ea977..fec3a92 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1385,6 +1385,19 @@ void pcim_pin_device(struct pci_dev *pdev)
dr-pinned = 1;
}
+/*
+ * pcibios_add_device - provide arch specific hooks when adding device dev
+ * @dev: the PCI device being added
+ *
+ * Permits the platform to provide architecture specific functionality when
+ * devices are added. This is the default implementation. Architecture
+ * implementations can override this.
+ */
+int __weak pcibios_add_device(struct pci_dev *dev)
+{
+ return 0;
+}
+
/**
* pcibios_disable_device - disable arch specific PCI resources for device dev
* @dev: the PCI device to disable
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5faa831..6a2625c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1582,6 +1582,7 @@ void pcibios_disable_device(struct pci_dev *dev);
void pcibios_set_master(struct pci_dev *dev);
int pcibios_set_pcie_reset_state(struct pci_dev *dev,
enum pcie_reset_state state);
+int pcibios_add_device(struct pci_dev *dev);
#ifdef CONFIG_PCI_MMCONFIG
extern void __init pci_mmcfg_early_init(void);
--
1.7.10.4
--
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 V2 1/4] EFI: Stash ROMs if they're not in the PCI BAR
EFI provides support for providing PCI ROMs via means other than the ROM
BAR. This support vanishes after we've exited boot services, so add support
for stashing copies of the ROMs in setup_data if they're not otherwise
available.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Seth Forshee seth.fors...@canonical.com
---
arch/x86/boot/compressed/eboot.c | 118 ++
arch/x86/include/asm/bootparam.h |1 +
arch/x86/include/asm/pci.h | 12
include/linux/efi.h | 71 +++
4 files changed, 202 insertions(+)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index d5e4044..ea674a7 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -8,6 +8,7 @@
* --- */
#include linux/efi.h
+#include linux/pci.h
#include asm/efi.h
#include asm/setup.h
#include asm/desc.h
@@ -243,6 +244,121 @@ static void find_bits(unsigned long mask, u8 *pos, u8
*size)
*size = len;
}
+static efi_status_t setup_efi_pci(struct boot_params *params)
+{
+ efi_pci_io_protocol *pci;
+ efi_status_t status;
+ void **pci_handle;
+ efi_guid_t pci_proto = EFI_PCI_IO_PROTOCOL_GUID;
+ unsigned long nr_pci, size = 0;
+ int i;
+ struct setup_data *data;
+
+ data = (struct setup_data *)params-hdr.setup_data;
+
+ while (data data-next)
+ data = (struct setup_data *)data-next;
+
+ status = efi_call_phys5(sys_table-boottime-locate_handle,
+ EFI_LOCATE_BY_PROTOCOL, pci_proto,
+ NULL, size, pci_handle);
+
+ if (status == EFI_BUFFER_TOO_SMALL) {
+ status = efi_call_phys3(sys_table-boottime-allocate_pool,
+ EFI_LOADER_DATA, size, pci_handle);
+
+ if (status != EFI_SUCCESS)
+ return status;
+
+ status = efi_call_phys5(sys_table-boottime-locate_handle,
+ EFI_LOCATE_BY_PROTOCOL, pci_proto,
+ NULL, size, pci_handle);
+ }
+
+ if (status != EFI_SUCCESS)
+ goto free_handle;
+
+ nr_pci = size / sizeof(void *);
+ for (i = 0; i nr_pci; i++) {
+ void *h = pci_handle[i];
+ uint64_t attributes;
+ struct pci_setup_rom *rom;
+
+ status = efi_call_phys3(sys_table-boottime-handle_protocol,
+ h, pci_proto, pci);
+
+ if (status != EFI_SUCCESS)
+ continue;
+
+ if (!pci)
+ continue;
+
+ status = efi_call_phys4(pci-attributes, pci,
+ EfiPciIoAttributeOperationGet, 0,
+ attributes);
+
+ if (status != EFI_SUCCESS)
+ continue;
+
+ if (!attributes EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM)
+ continue;
+
+ if (!pci-romimage || !pci-romsize)
+ continue;
+
+ size = pci-romsize + sizeof(*rom);
+
+ status = efi_call_phys3(sys_table-boottime-allocate_pool,
+ EFI_LOADER_DATA, size, rom);
+
+ if (status != EFI_SUCCESS)
+ continue;
+
+ rom-data.type = SETUP_PCI;
+ rom-data.len = size - sizeof(struct setup_data);
+ rom-data.next = 0;
+ rom-pcilen = pci-romsize;
+
+ status = efi_call_phys5(pci-pci.read, pci,
+ EfiPciIoWidthUint16, PCI_VENDOR_ID,
+ 1, (rom-vendor));
+
+ if (status != EFI_SUCCESS)
+ goto free_struct;
+
+ status = efi_call_phys5(pci-pci.read, pci,
+ EfiPciIoWidthUint16, PCI_DEVICE_ID,
+ 1, (rom-devid));
+
+ if (status != EFI_SUCCESS)
+ goto free_struct;
+
+ status = efi_call_phys5(pci-get_location, pci,
+ (rom-segment), (rom-bus),
+ (rom-device), (rom-function));
+
+ if (status != EFI_SUCCESS)
+ goto free_struct;
+
+ memcpy(rom-romdata, pci-romimage, pci-romsize);
+
+ if (data)
+ data-next = (uint64_t)rom;
+ else
+ params-hdr.setup_data = (uint64_t)rom;
+
+ data = (struct setup_data *)rom;
+
+ continue;
+free_struct:
+ efi_call_phys1(sys_table-boottime-free_pool, rom);
+ }
+
+free_handle:
+
Re: [PATCH 1/5] user_hooks: New user hooks subsystem
On Fri, Jul 27, 2012 at 09:40:54AM -0700, Paul E. McKenney wrote: On Fri, Jul 27, 2012 at 05:40:30PM +0200, Frederic Weisbecker wrote: Create a new subsystem that handles the hooks on kernel/user boundaries currently used by RCU for its userspace extended quiescent state. We need to pull this up from RCU into this new level of indirection because these hooks are also going to be used to implement an on demand generic virtual cputime accounting. A necessary step to shutdown the tick while still accounting the cputime. So this eliminates the case where the architecture might enter an RCU extended quiescent state multiple times, but exit it only once? (I am hoping that it does...) Yeah. It should handle that. -- 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] efifb: Skip DMI checks if the bootloader knows what it's doing
The majority of the DMI checks in efifb are for cases where the bootloader
has provided invalid information. However, on some machines the overrides
may do more harm than good due to configuration differences between machines
with the same machine identifier. It turns out that it's possible for the
bootloader to get the correct information on GOP-based systems, but we
can't guarantee that the kernel's being booted with one that's been updated
to do so. Add support for a capabilities flag that can be set by the
bootloader, and skip the DMI checks in that case. Additionally, set this
flag in the UEFI stub code.
Signed-off-by: Matthew Garrett m...@redhat.com
---
arch/x86/boot/compressed/eboot.c |2 ++
drivers/video/efifb.c|4 +++-
include/linux/screen_info.h |2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b71c7c8..b329312 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -495,6 +495,8 @@ static efi_status_t setup_gop(struct screen_info *si,
efi_guid_t *proto,
si-rsvd_pos = 0;
}
+ si-capabilities |= VIDEO_CAPABILITY_SKIP_QUIRKS;
+
free_handle:
efi_call_phys1(sys_table-boottime-free_pool, gop_handle);
return status;
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index b4a632a..932abaa 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -553,7 +553,9 @@ static int __init efifb_init(void)
int ret;
char *option = NULL;
- dmi_check_system(dmi_system_table);
+ if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI ||
+ !(screen_info.capabilities VIDEO_CAPABILITY_SKIP_QUIRKS))
+ dmi_check_system(dmi_system_table);
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
return -ENODEV;
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index 899fbb4..fb3c5a8 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -68,6 +68,8 @@ struct screen_info {
#define VIDEO_FLAGS_NOCURSOR (1 0) /* The video mode has no cursor set */
+#define VIDEO_CAPABILITY_SKIP_QUIRKS (1 0)
+
#ifdef __KERNEL__
extern struct screen_info screen_info;
--
1.7.10.4
--
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] Add Etron XHCI quirk to avoid warning spam
On Fri, Jul 27, 2012 at 02:40:56PM +0800, Daniel J Blueman wrote: On 27 July 2012 14:14, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Fri, Jul 27, 2012 at 12:03:44PM +0800, Daniel J Blueman wrote: When various USB3 devices with Etron XHCI controllers, we see a bunch of warnings: xhci_hcd :02:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Acknowledge the issue by adding the quirk. Signed-off-by: Daniel J Blueman dan...@quora.org [] I already have a patch in my queue for this. However, it keys off the PCI_DEVICE_ID_ASROCK_P67 PCI device ID. Do you have another Etron device with a different device ID that needs this quirk? Yes, the subsystem ID is different [1] (but Zotac program it the same as the vendor and device IDs here), however what you say suggests the problem is general to this Etron XHCI controller (1b6f:7023), as we'd suspect anyway. Thus the more general patch I posted makes better sense perhaps? I'd really like to keep this quirk specific to the particular PCI vendor and device ID. It's possible that their next chip version will have the opposite issue (short TX completion code and bad untransferred length). Your patch turned it on for all Etron hosts, so I would rather keep my version: http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=12751f75720391bb2b607acdb2537f02e313251e I also added a second patch to rate limit the messages for other hosts that have this issue but don't have the quirk turned on: http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=5de3270101d30a4a8023815f8010eef2d2d40613 Sarah Sharp -- 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] Revert hugetlb: avoid taking i_mmap_mutex in unmap_single_vma() for hugetlb
Mel Gorman mgor...@suse.de writes:
This reverts the patch hugetlb: avoid taking i_mmap_mutex in
unmap_single_vma() for hugetlb from mmotm.
This patch is possibly a mistake and blocks the merging of a hugetlb fix
where page tables can get corrupted (https://lkml.org/lkml/2012/7/24/93).
The motivation of the patch appears to be two-fold.
First, it believes that the i_mmap_mutex is to protect against list
corruption of the page-lru lock but that is not quite accurate. The
i_mmap_mutex for shared page tables is meant to protect against races
when sharing and unsharing the page tables. For example, an important
use of i_mmap_mutex is to stabilise the page_count of the PMD page
during huge_pmd_unshare.
I missed that.
Second, it is protecting against a potential deadlock when
unmap_unsingle_page is called from unmap_mapping_range(). However, hugetlbfs
should never be in this path. It has its own setattr and truncate handlers
where are the paths that use unmap_mapping_range().
I noted this in
http://article.gmane.org/gmane.linux.kernel.mm/80065
Unless Aneesh has another reason for the patch, it should be reverted
to preserve hugetlb page sharing locking.
I guess we want to take this patch as a revert patch rather than
dropping the one in -mm. That would help in documenting the i_mmap_mutex
locking details in commit message. Or may be we should add necessary
comments around the locking ?
Acked-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/memory.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index 8a989f1..22bc695 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1344,8 +1344,11 @@ static void unmap_single_vma(struct mmu_gather *tlb,
* Since no pte has actually been setup, it is
* safe to do nothing in this case.
*/
- if (vma-vm_file)
+ if (vma-vm_file) {
+
mutex_lock(vma-vm_file-f_mapping-i_mmap_mutex);
__unmap_hugepage_range(tlb, vma, start, end,
NULL);
+
mutex_unlock(vma-vm_file-f_mapping-i_mmap_mutex);
+ }
} else
unmap_page_range(tlb, vma, start, end, details);
}
--
1.7.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: [vmw_vmci 11/11] Apply the header code to make VMCI build
Hi Sam, - Original Message - From: Sam Ravnborg s...@ravnborg.org To: Andrew Stiegmann (stieg) astiegm...@vmware.com Cc: linux-kernel@vger.kernel.org, virtualizat...@lists.linux-foundation.org, pv-driv...@vmware.com, vm-crosst...@vmware.com, csch...@vmware.com, gre...@linuxfoundation.org Sent: Friday, July 27, 2012 3:34:55 AM Subject: Re: [vmw_vmci 11/11] Apply the header code to make VMCI build Hi Andrew. A few things noted in the following.. diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..af9e413 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,4 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-y += vmw_vmci/ Please use obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ like we do in the other cases. This prevents us from visiting the directory when this feature is not enabled. Ok. +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-2012, VMware, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the +# Free Software Foundation; version 2 of the License and no later version. +# +# 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, GOOD TITLE or +# NON INFRINGEMENT. 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, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# The full GNU General Public License is included in this distribution in +# the file called COPYING. +# +# Maintained by: Andrew Stiegmann pv-driv...@vmware.com +# + Lot's of boilerplate noise for such a simple file... I removed the section containing FSF address and section below it as well per Greg KH's request. + +# +# Makefile for the VMware VMCI +# + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-objs += vmci_context.o +vmw_vmci-objs += vmci_datagram.o +vmw_vmci-objs += vmci_doorbell.o +vmw_vmci-objs += vmci_driver.o +vmw_vmci-objs += vmci_event.o +vmw_vmci-objs += vmci_handle_array.o +vmw_vmci-objs += vmci_hash_table.o +vmw_vmci-objs += vmci_queue_pair.o +vmw_vmci-objs += vmci_resource.o +vmw_vmci-objs += vmci_route.o please use: vmw_vmci-y += vmci_context.o vmw_vmci-y += vmci_datagram.o vmw_vmci-y += vmci_doorbell.o This is recommended these days and allows you to enable/disable single files later using a config option. Ok. diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h + +#ifndef _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h +#include linux/vmw_vmci_defs.h Use inverse chrismas tree here. Longer include lines first, and soret alphabetically when lines are of the same length. This applies likely in many cases. +#include vmci_handle_array.h + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define CAN_BLOCK(_f) (!((_f) VMCI_QPFLAG_NONBLOCK)) +#define QP_PINNED(_f) ((_f) VMCI_QPFLAG_PINNED) Looks like poor obscufation. Use a statis inline function if you need a helper for this. These definitions are intended more as a helper to make reading the code easier. IMHO ts a lot easier to read if (CAN_BLOCK(flags)) compared to if (!(flags VMCI_QPFLAG_NONBLOCK)) Wouldn't you agree? I'm not sure something this simple warrants a static inline function but I don't see any harm in converting it over to that. + +/* + * Utilility function that checks whether two entities are allowed + * to interact. If one of them is restricted, the other one must + * be trusted. + */ +static inline bool vmci_deny_interaction(uint32_t partOne, +uint32_t partTwo) The kernel types are u32 not uint32_t - these types belongs in user-space. Ok. +++ b/include/linux/vmw_vmci_api.h +
Re: [PATCH v3 2/4] ACPI: Update CPU hotplug messages
On Fri, 2012-07-27 at 10:05 -0600, Bjorn Helgaas wrote:
On Thu, Jul 26, 2012 at 8:39 PM, Toshi Kani toshi.k...@hp.com wrote:
On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani toshi.k...@hp.com wrote:
@@ -560,8 +565,7 @@ static int __cpuinit acpi_processor_add(struct
acpi_device *device)
*/
if (per_cpu(processor_device_array, pr-id) != NULL
per_cpu(processor_device_array, pr-id) != device) {
- printk(KERN_WARNING BIOS reported wrong ACPI id
- for the processor\n);
+ pr_warn(BIOS reported wrong ACPI id for the
processor\n);
And this.
Changed to use dev_warn().
Is there additional information you could print here, like the pr-id?
I don't understand the data structures here, so maybe there isn't.
Good point. Yes, we should print pr-id so that we can check if the id
value is wrong. I will make this change later since I would likely
touch this file again. :) For now, I'd like to settle the patches
unless there is a major issue.
@@ -727,17 +731,19 @@ static void
acpi_processor_hotplug_notify(acpi_handle handle,
received
ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- pr_err(PREFIX Device don't exist, dropping
EJECT\n);
+ acpi_pr_err(handle,
+ Device don't exist, dropping EJECT\n);
break;
}
if (!acpi_driver_data(device)) {
- pr_err(PREFIX Driver data is NULL, dropping
EJECT\n);
+ acpi_pr_err(handle,
+ Driver data is NULL, dropping EJECT\n);
And this.
No change since it is called directly from the handler.
True, but by this point, we have a valid acpi_device *, don't we? We
called acpi_driver_data(device), which requires device to be valid.
Right. But we need to print ACPI device path in order to be able to
analyze from the log file. Hence, I am keeping acpi_pr_level in the
error paths of the handler itself. Any subsequent functions call
dev_level() when device is valid. In this particular case,
acpi_driver_data() does not call dev_level() when its return value is
NULL, but most other cases are changed to call dev_level().
break;
}
ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
if (!ej_event) {
- pr_err(PREFIX No memory, dropping EJECT\n);
+ acpi_pr_err(handle, No memory, dropping
EJECT\n);
And this.
No change since it is called directly from the handler.
break;
}
@@ -847,7 +853,7 @@ static acpi_status acpi_processor_hotadd_init(struct
acpi_processor *pr)
* and do it when the CPU gets online the first time
* TBD: Cleanup above functions and try to do this more elegant.
*/
- printk(KERN_INFO CPU %d got hotplugged\n, pr-id);
+ pr_info(CPU %d got hotplugged\n, pr-id);
And this. The caller (acpi_processor_get_info()) has an acpi_device
*, so we should be able to use it here.
I think pr_info() is fine since it is a normal message and already has
CPU number in the message.
Is there another message that correlates the device name
(ACPI0007:xx) with the CPU number? That correlation seems useful.
My mindset is that a driver should *always* use dev_level() when
possible, but I won't belabor the point.
That's a good point. This CPU number is used for cpu# file
under /sys/devices/system/cpu, but I do not think there is a good way to
correlate this number to the device name. This is also the case for all
CPUs launched at boot-time. At boot-time, all CPUs are launched from
the MADT table, and the code has no knowledge about processor objects.
Typically, cpu# and device instance# are same at boot-time, though. I
will think about this issue further.
Thanks,
-Toshi
Bjorn
--
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] uprobes: don't enable/disable signle step if the user did it
On 07/26/2012 07:31 PM, Oleg Nesterov wrote:
Well. I agree, this needs changes. To begin with, uprobe should avoid
user_enable_single_step() which does access_process_vm(). And I suspect
uprobes have the problems with TIF_FORCED_TF logic.
Why? Shouldn't wee keep the trap flag if the instruction on which we
placed the uprobe activates it?
But I am not sure about this patch...
On 07/26, Sebastian Andrzej Siewior wrote:
@@ -1528,7 +1528,10 @@ static void handle_swbp(struct pt_regs *regs)
utask-state = UTASK_SSTEP;
if (!pre_ssout(uprobe, regs, bp_vaddr)) {
- user_enable_single_step(current);
+ if (test_tsk_thread_flag(current, TIF_SINGLESTEP))
+ uprobe-flags |= UPROBE_USER_SSTEP;
+ else
+ user_enable_single_step(current);
This is x86 specific, TIF_SINGLESTEP is not defined on every arch.
It is not defined on every arch but I wouldn't say it is 86 specific.
From the architectures which have user_enable_single_step() defined I
see
avr32 TIF_SINGLE_STEP
m68k TIF_DELAYED_TRACE
s390 TIF_SINGLE_STEP
which means those three could rename their flag so things are
consistent. The remaining architectures are
alpha
cris
h8300
score
and they don't set a flag and it seems they change the register
directly.
@@ -1569,7 +1572,10 @@ static void handle_singlestep(struct uprobe_task *utask,
struct pt_regs *regs)
put_uprobe(uprobe);
utask-active_uprobe = NULL;
utask-state = UTASK_RUNNING;
- user_disable_single_step(current);
+ if (uprobe-flags UPROBE_USER_SSTEP)
+ uprobe-flags= ~UPROBE_USER_SSTEP;
+ else
+ user_disable_single_step(current);
This is not enough (and I am not sure this is portable).
If SINGLESTEP was set, we should send SIGTRAP here. With this patch
we return with X86_EFLAGS_TF set, gdb will be notified only after the
next insn. And if we notify gdb, there is no need to keep X86_EFLAGS_TF.
Sending SIGTRAP is, yes.
I'm afraid this needs more thinking and new arch-dependant helpers.
Oleg.
Sebastian
--
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: [Xen-devel] [PATCH 5/7] xen/p2m: Add logic to revector a P2M tree to use __va leafs.
On Fri, Jul 27, 2012 at 12:47:47PM +0100, Jan Beulich wrote: On 27.07.12 at 13:18, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote: 1) All P2M lookups instead of using the __ka address would use the __va address. This means we can safely erase from __ka space the PMD pointers that point to the PFNs for P2M array and be OK. 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. So we pick option 2). 1) looks like a decent option that requires less code. Is the problem with 1) that we might want to access the P2M before we have __va addresses ready? AIUI 1) has no easy way of subsequently accommodating support for XEN_ELF_NOTE_INIT_P2M (where you almost definitely will want/need to reclaim the originally used VA space - if nothing else, then for forward compatibility with the rest of the kernel). nods That was my thinking - this way we can boot dom0 (since the hypervisor is the only one that implements the XEN_ELF_NOTE_INIT_P2M) with large amount of memory. Granted booting with more than 500GB would require adding another layer to the P2M tree. But somehow I thought that we are limited in the hypervisor to 500GB? -- 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: [Xen-devel] [PATCH 7/7] xen/mmu: Remove from __ka space PMD entries for pagetables.
On Fri, Jul 27, 2012 at 12:31:17PM +0100, Stefano Stabellini wrote: On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote: Please first read the description in xen/mmu: Copy and revector the P2M tree. At this stage, the __ka address space (which is what the old P2M tree was using) is partially disassembled. The cleanup_highmap has removed the PMD entries from 0-16MB and anything past _brk_end up to the max_pfn_mapped (which is the end of the ramdisk). The xen_remove_p2m_tree and code around has ripped out the __ka for the old P2M array. Here we continue on doing it to where the Xen page-tables were. It is safe to do it, as the page-tables are addressed using __va. For good measure we delete anything that is within MODULES_VADDR and up to the end of the PMD. At this point the __ka only contains PMD entries for the start of the kernel up to __brk. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- arch/x86/xen/mmu.c | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 05e8492..738feca 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1241,6 +1241,26 @@ static void __init xen_pagetable_setup_done(pgd_t *base) xen_start_info-mfn_list = new_mfn_list; } } +#ifdef CONFIG_X86_64 + /* At this stage, cleanup_highmap has already cleaned __ka space +* from _brk_limit way up to the max_pfn_mapped (which is the end of +* the ramdisk). We continue on, erasing PMD entries that point to page +* tables - do note that they are accessible at this stage via __va. +* For good measure we also round up to the PMD - which means that if +* anybody is using __ka address to the initial boot-stack - and try +* to use it - they are going to crash. The xen_start_info has been +* taken care of already in xen_setup_kernel_pagetable. */ + addr = xen_start_info-pt_base; + size = roundup(xen_start_info-nr_pt_frames * PAGE_SIZE, PMD_SIZE); + + xen_cleanhighmap(addr, addr + size); + xen_start_info-pt_base = (unsigned long)__va(__pa(xen_start_info-pt_base)); + + /* This is superflous and shouldn't be neccessary, but you know what +* lets do it. The MODULES_VADDR - MODULES_END should be clear of +* anything at this stage. */ + xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1); I would stick an #ifdef CONFIG_DEBUG of some kind around it I am not really sure why, but we seem to have PMDs filed after the Xen pagetables. I thought it was the bootstack, but it just looked like we were filling up to the next PMD (so the 'roundup' right above this code should take care of that). But let me double check that - to reproduce this module loading problem I hacked the hypervisor to create a huge P2M array and I might have not seen this issue when I was doing a proper bootup of a PV guest with 220GB. -- 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: [Xen-devel] [PATCH 3/7] xen/mmu: Release the Xen provided L4 (PGD) back.
On Fri, Jul 27, 2012 at 12:37:24PM +0100, Stefano Stabellini wrote: On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote: Since we are not using it and somebody else could use it. make sense except it is almost entirely rewritten by the following patch... Yeah, I should squash them. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- arch/x86/xen/mmu.c | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index a59070b..48bdc9f 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1782,20 +1782,21 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) /* Unpin Xen-provided one */ pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd))); - /* Switch over */ - pgd = init_level4_pgt; - /* * At this stage there can be no user pgd, and no page * structure to attach it to, so make sure we just set kernel * pgd. */ xen_mc_batch(); - __xen_write_cr3(true, __pa(pgd)); + __xen_write_cr3(true, __pa(init_level4_pgt)); xen_mc_issue(PARAVIRT_LAZY_CPU); - memblock_reserve(__pa(xen_start_info-pt_base), -xen_start_info-nr_pt_frames * PAGE_SIZE); + /* Offset by one page since the original pgd is going bye bye */ + memblock_reserve(__pa(xen_start_info-pt_base + PAGE_SIZE), +(xen_start_info-nr_pt_frames * PAGE_SIZE) - PAGE_SIZE); + /* and also RW it so it can actually be used. */ + set_page_prot(pgd, PAGE_KERNEL); + clear_page(pgd); } #else /* !CONFIG_X86_64 */ static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD); -- 1.7.7.6 ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel -- 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: [Xen-devel] [PATCH 4/7] xen/mmu: Recycle the Xen provided L4, L3, and L2 pages
On Fri, Jul 27, 2012 at 12:45:38PM +0100, Stefano Stabellini wrote:
On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote:
As we are not using them. We end up only using the L1 pagetables
and grafting those to our page-tables.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/mmu.c | 38 --
1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 48bdc9f..7f54b75 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1724,6 +1724,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
{
pud_t *l3;
pmd_t *l2;
+ unsigned long addr[3];
+ unsigned long pt_base, pt_end;
+ unsigned i;
/* max_pfn_mapped is the last pfn mapped in the initial memory
* mappings. Considering that on Xen after the kernel mappings we
@@ -1731,6 +1734,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
* set max_pfn_mapped to the last real pfn mapped. */
max_pfn_mapped = PFN_DOWN(__pa(xen_start_info-mfn_list));
+ pt_base = PFN_DOWN(__pa(xen_start_info-pt_base));
+ pt_end = PFN_DOWN(__pa(xen_start_info-pt_base +
(xen_start_info-nr_pt_frames * PAGE_SIZE)));
+
/* Zap identity mapping */
init_level4_pgt[0] = __pgd(0);
@@ -1749,6 +1755,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);
+ addr[0] = (unsigned long)pgd;
+ addr[1] = (unsigned long)l2;
+ addr[2] = (unsigned long)l3;
/* Graft it onto L4[272][0]. Note that we creating an aliasing problem:
* Both L4[272][0] and L4[511][511] have entries that point to the same
* L2 (PMD) tables. Meaning that if you modify it in __va space
@@ -1791,12 +1800,29 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
__xen_write_cr3(true, __pa(init_level4_pgt));
xen_mc_issue(PARAVIRT_LAZY_CPU);
- /* Offset by one page since the original pgd is going bye bye */
- memblock_reserve(__pa(xen_start_info-pt_base + PAGE_SIZE),
-(xen_start_info-nr_pt_frames * PAGE_SIZE) -
PAGE_SIZE);
- /* and also RW it so it can actually be used. */
- set_page_prot(pgd, PAGE_KERNEL);
- clear_page(pgd);
+ /* We can't that easily rip out L3 and L2, as the Xen pagetables are
+* set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for
+* the initial domain. For guests using the toolstack, they are in:
+* [L4], [L3], [L2], [L1], [L1], order .. */
+ for (i = 0; i ARRAY_SIZE(addr); i++) {
+ unsigned j;
+ /* No idea about the order the addr are in, so just do them
twice. */
+ for (j = 0; j ARRAY_SIZE(addr); j++) {
I don't think I understand this double loop.
So with Xen toolstack, the order is L4, L3, L2, L1s.. and with
the hypervisor it is L4, L1,... but in the future the order might
be L1, L1 ..., L1, L2, L3, L4 (potentially?) so this double loop
will loop around the addresses twice to catch this in case we get
it like this.
Shouldn't we be looping on pt_base or pt_end?
So two loops - and it could be put in a seperate function. That
would make this easier to read. Yeah, let me do it that way.
Thanks!
+ if (pt_base == PFN_DOWN(__pa(addr[j]))) {
+ set_page_prot((void *)addr[j], PAGE_KERNEL);
+ clear_page((void *)addr[j]);
+ pt_base++;
+
+ }
+ if (pt_end == PFN_DOWN(__pa(addr[j]))) {
+ set_page_prot((void *)addr[j], PAGE_KERNEL);
+ clear_page((void *)addr[j]);
+ pt_end--;
+ }
+ }
+ }
+ /* Our (by three pages) smaller Xen pagetable that we are using */
+ memblock_reserve(PFN_PHYS(pt_base), (pt_end - pt_base) * PAGE_SIZE);
___
Xen-devel mailing list
xen-de...@lists.xen.org
http://lists.xen.org/xen-devel
--
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: [Xen-devel] [PATCH 2/4] xen/x86: Use memblock_reserve for sensitive areas.
On Fri, Jul 27, 2012 at 11:49:02AM +0100, Stefano Stabellini wrote:
On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote:
instead of a big memblock_reserve. This way we can be more
selective in freeing regions (and it also makes it easier
to understand where is what).
[v1: Move the auto_translate_physmap to proper line]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/enlighten.c | 38 ++
arch/x86/xen/p2m.c |5 +
arch/x86/xen/setup.c |9 -
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ff962d4..9b1afa4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -998,7 +998,44 @@ static int xen_write_msr_safe(unsigned int msr,
unsigned low, unsigned high)
return ret;
}
+static void __init xen_reserve_mfn(unsigned long mfn)
+{
+ unsigned long pfn;
+
+ if (!mfn)
+ return;
+ pfn = mfn_to_pfn(mfn);
+ if (phys_to_machine_mapping_valid(pfn))
+ memblock_reserve(PFN_PHYS(pfn), PAGE_SIZE);
+}
If the mfn is not in the m2p xen_reserve_mfn won't do anything. It is
worth writing it down in a comment.
Meaning in a printk?
+static void __init xen_reserve_internals(void)
+{
+ unsigned long size;
+
+ if (!xen_pv_domain())
+ return;
+
+ memblock_reserve(__pa(xen_start_info), PAGE_SIZE);
xen_start_info is not in the m2p, so you cannot use xen_reserve_mfn
It seems to work for me. For both the toolstack created guests
and dom0. Let me double check thought.
+ xen_reserve_mfn(PFN_DOWN(xen_start_info-shared_info));
+ xen_reserve_mfn(xen_start_info-store_mfn);
Are we sure that shared_info points to an mfn that is in the m2p (rather
than a special mfn not present in the list)?
+ if (!xen_initial_domain())
+ xen_reserve_mfn(xen_start_info-console.domU.mfn);
+
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return;
+
+ /*
+* ALIGN up to compensate for the p2m_page pointing to an array that
+* can partially filled (look in xen_build_dynamic_phys_to_machine).
+*/
+
+ size = PAGE_ALIGN(xen_start_info-nr_pages * sizeof(unsigned long));
+ memblock_reserve(__pa(xen_start_info-mfn_list), size);
I take that here you are using memblock_reserve again, rather than
xen_reserve_mfn, because the corresponding mfn is not in the m2p?
nods Well, they are - but they are ..
+ /* The pagetables are reserved in mmu.c */
+}
void xen_setup_shared_info(void)
{
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -1362,6 +1399,7 @@ asmlinkage void __init xen_start_kernel(void)
xen_raw_console_write(mapping kernel into physical memory\n);
pgd = xen_setup_kernel_pagetable(pgd, xen_start_info-nr_pages);
+ xen_reserve_internals();
/* Allocate and initialize top and mid mfn levels for p2m structure */
xen_build_mfn_list_list();
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index e4adbfb..6a2bfa4 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -388,6 +388,11 @@ void __init xen_build_dynamic_phys_to_machine(void)
}
m2p_override_init();
+
+ /* NOTE: We cannot call memblock_reserve here for the mfn_list as there
+* isn't enough pieces to make it work (for one - we are still using the
+* Xen provided pagetable). Do it later in xen_reserve_internals.
+*/
}
unsigned long get_phys_to_machine(unsigned long pfn)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a4790bf..9efca75 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -424,15 +424,6 @@ char * __init xen_memory_setup(void)
e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS,
E820_RESERVED);
- /*
-* Reserve Xen bits:
-* - mfn_list
-* - xen_start_info
-* See comment above struct start_info in xen/interface/xen.h
-*/
- memblock_reserve(__pa(xen_start_info-mfn_list),
-xen_start_info-pt_base - xen_start_info-mfn_list);
-
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), e820.nr_map);
return Xen;
--
1.7.7.6
--
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/
___
Xen-devel mailing list
xen-de...@lists.xen.org
http://lists.xen.org/xen-devel
--
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
Re: [Xen-devel] [PATCH 1/2] xen/swiotlb: If iommu=soft was not passed in on 4GB, don't turn it on.
On Fri, Jul 27, 2012 at 08:27:39AM +0100, Jan Beulich wrote:
On 26.07.12 at 22:43, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
If we boot a 64-bit guest with more than 4GB memory, the SWIOTLB
gets turned on:
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
software IO TLB [mem 0xfb43d000-0xff43cfff] (64MB) mapped at
[8800fb43d000-8800ff43cfff]
which is OK if we had PCI devices, but not if we did not. In a PV
guest the SWIOTLB ends up asking the hypervisor for precious lowmem
memory - and 64MB of it per guest. On a 32GB machine, this limits the
amount of guests that are 4GB to start due to lowmem exhaustion.
What we do is detect whether the user supplied e820_hole=1
parameter, which is used to construct an E820 that is similar to
the machine - so that the PCI regions do not overlap with RAM regions.
We check for that by looking at the E820 and seeing if it diverges
from the standard - and if so (and if iommu=soft was not turned on),
we disable the check pci_swiotlb_detect_4gb code.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/pci-swiotlb-xen.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 967633a..56f373e 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -8,6 +8,10 @@
#include xen/xen.h
#include asm/iommu_table.h
+#include asm/e820.h
+#include asm/dma.h
+#include asm/iommu.h
+
int xen_swiotlb __read_mostly;
static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -24,7 +28,19 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
};
+bool __init e820_has_acpi(void)
+{
+ int i;
+ /* Check if the user supplied the e820_hole parameter
+* which would create a machine looking E820 region. */
+ for (i = 0; i e820.nr_map; i++) {
+ if ((e820.map[i].type == E820_ACPI) ||
+ (e820.map[i].type == E820_NVS))
+ return true;
Tying this decision to the presence of ACPI regions in E820 is
problematic for two reasons imo: For one, it precludes cleaning
up this (bogus!) construct where it gets produced (PV DomU-s
really shouldn't ever see such E820 entries, they should get
converted to simple reserved entries, to wipe any notion of
ACPI presence). And second it ties you to running on systems
that actually have ACPI, whereas it is my rudimentary
understanding that systems with e.g. SFI would not have any
ACPI).
Right. The other idea was to check the XenBus for the existence
of vpci backend. But at this stage it is not up yet.
Perhaps what I should check for is the existence of two E820_RSV
and two E820_RAM regions - and that would be a normal PV guest.
Anything that is outside of that scope would be considered
a PCI PV guest?
The other thought I had was to skip this check altogether and
either do:
1). initialize SWIOTLB when xen-pcifront start up and detects
that it has devices (so later on initialization - similar to
how IA64 does it) - but I am not sure how the PCI-DMA works
with these late bloomers (especially as one could just make
xen-pcifront be a module).
2). If xen-pcifront starts and does not detect any backends
it calls swiotlb_free. But that also requires the PCI-DMA
to swap in the dma_ops, and I am not entirely sure how
that would work out.
3). Have an early_init xen-pcifront components that does a
a quick XenBus init (similar to how hvmloader checks for
DMI overwrites) and if it finds vpci then declare its
time to turn SWIOTLB on.
4). The other thing is to wrap this code with something like
this:
#ifdef CONFIG_SWIOTLB
#ifdef CONFIG_XEN_PCI_FRONTEND
if (.. blah balh) do the check as outlined in 3).
#else // PCI_FRONTEND is not present, so we won't need SWIOTLB
swiotlb = 0;
iommu = 1;
#endif
#endif
That would take care of the built-in issues.
--
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: [Xen-devel] [PATCH 1/2] xen/swiotlb: If iommu=soft was not passed in on 4GB, don't turn it on.
On Fri, Jul 27, 2012 at 12:06:27PM +0100, Stefano Stabellini wrote: On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote: If we boot a 64-bit guest with more than 4GB memory, the SWIOTLB gets turned on: PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB [mem 0xfb43d000-0xff43cfff] (64MB) mapped at [8800fb43d000-8800ff43cfff] which is OK if we had PCI devices, but not if we did not. In a PV guest the SWIOTLB ends up asking the hypervisor for precious lowmem memory - and 64MB of it per guest. On a 32GB machine, this limits the amount of guests that are 4GB to start due to lowmem exhaustion. What we do is detect whether the user supplied e820_hole=1 parameter, which is used to construct an E820 that is similar to the machine - so that the PCI regions do not overlap with RAM regions. We check for that by looking at the E820 and seeing if it diverges from the standard - and if so (and if iommu=soft was not turned on), we disable the check pci_swiotlb_detect_4gb code. What kind of paramter is it? Is it a Linux cmdline paramter? Or maybe a Xen toolstack parameter? Its a guest config option. Surely there must be a better way to let Linux know if this paramter has been turned on than looking for ACPI entries in the E820. I am all open for suggestions. The best way I can think of is to have some early_init variant of XenBus-detect-this-backend-parameter. Can one unhook an old XenBus and reset with the full-fledged XenBus init later on? -- 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/
[RESEND PATCH 3/4 v3] mm: fix return value in __alloc_contig_migrate_range()
migrate_pages() can return positive value while at the same time emptying
the list of pages it was called with. Such situation means that it went
through all the pages on the list some of which failed to be migrated.
If that happens, __alloc_contig_migrate_range()'s loop may finish without
++tries == 5 never being checked. This in turn means that at the end
of the function, ret may have a positive value, which should be treated
as an error.
This patch changes __alloc_contig_migrate_range() so that the return
statement converts positive ret value into -EBUSY error.
Signed-off-by: Joonsoo Kim js1...@gmail.com
Cc: Michal Nazarewicz min...@mina86.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Minchan Kim minc...@kernel.org
Cc: Christoph Lameter c...@linux.com
Acked-by: Christoph Lameter c...@linux.com
Acked-by: Michal Nazarewicz min...@mina86.com
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4403009..02d4519 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5673,7 +5673,6 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
}
tries = 0;
} else if (++tries == 5) {
- ret = ret 0 ? ret : -EBUSY;
break;
}
@@ -5683,7 +5682,7 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
}
putback_lru_pages(cc.migratepages);
- return ret 0 ? 0 : ret;
+ return ret = 0 ? ret : -EBUSY;
}
/*
--
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/
An Andre To Remember
An Andre To Remember July 2012 Linux lost a friend and advocate this month. Though never a household name, Andre Hedrick had a positive impact on everyone today running Linux, or using a website, with any form of IDE (ATA) or SCSI storage -- that means millions upon millions of users today. For a time, Andre interacted with practically every relevant IDE drive and controller manufacturer, as well as the T13 standards committee through which IDE changes were made. He helped ensure Linux had near-universal IDE support in a hardware era when Linux support was a second thought if at all. As the Register article[1] noted, with CPRM and other efforts, Andre worked to keep storage a more open platform than it might otherwise have been. [1] http://www.theregister.co.uk/2012/07/26/andre_hedrick/ Andre also played a role in IDE technology coalescing around the idea of a taskfile, which is IDE-speak for an RPC command issued to a disk drive, and the RPC response returned from the drive. It was very important to Andre that the kernel have a taskfile ioctl, an API enabling full programmable access to the disk drive. At the time, a more limited cmd ioctl API was the best option available, but Linux's cmd ioctl did not give users full and complete access to their own disk drive. Andre's taskfile concept was a central component of the current, rewritten-from-scratch Linux IDE driver libata. libata uses an ata_taskfile to communicate with all IDE drives, whether from a decade ago or built yesterday. The taskfile concept modernized IDE software, by forcing the industry to move away from a slow, signals-originated register API to a modern, packetized RPC messaging API, similar to where SCSI storage had already been moving. I spent many hours on the phone with Andre, circa 2003, learning all there was to know about ATA storage, while writing libata. Andre could be considered one of the grandfathers of libata, along with Alan Cox. I became friends with Andre during this time, and we talked a lot. Andre was unquestionably smart, driven and an advocate for Linux user freedom. Andre was also mentally ill. Some of those hours spent on the phone with him were not geeky discussions, but me patiently listening to paranoid thoughts about kernel developer conspiracies, and even more patiently describing how he was simply misunderstanding and misapplying the development process and/or basic code details. Andre would receive engineering feedback on some of his changes, and wonder why the engineer reviewing his changes was conspiring to shoot down his obviously-needed changes. At some point, paranoia and mental illness makes you difficult to work with, which starts a nasty feedback loop feeding further paranoia and stress. Perhaps it is the nature of intelligence itself, or just the nature of computer science, but our profession seems to have a higher than average rate of bipolar disorder and other mental illnesses. A Beautiful Mind comes to mind, as does my own purely anecdotal observations of others as a kernel developer and maintainer. Whatever the reason, Andre is not the only developer I've encountered who sees conspiracies, wheels-within-wheels in the feedback they receive. Although I was truly shocked by the news of Andre's suicide, it always seemed like Andre was continually stressed out, when I knew him. When spending long hours discussing kernel and storage industry politics over the phone with Andre, I found myself constantly advising him to relax, to take a break from computing. This is a time for grief and a time for celebration of Andre's accomplishments, but also it is a time to look around at our fellow geeks and offer our support, if similar behavioral signs appear. There is no computing project that is worth your life. Turn off the computer. Seek help. Get outside, enjoy the green grass, the birds in the trees. Talk to people you know. Talk to strangers! Drive to Wisconsin, and find out whatever it is they do there. Build a treehouse. Park on a parkway and drive on a driveway. Make a macaroni necklace. Visit a dairy. Climb a rock. Seek life. Life is so much more than code. Rest in peace Andre, Jeff Garzik friend and libata author PS. Remembering Andre website: http://hedrick4419.blogspot.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/
[RESEND PATCH 1/4 v3] mm: correct return value of migrate_pages() and migrate_huge_pages()
migrate_pages() should return number of pages not migrated or error code.
When unmap_and_move return -EAGAIN, outer loop is re-execution without
initialising nr_failed. This makes nr_failed over-counted.
So this patch correct it by initialising nr_failed in outer loop.
migrate_huge_pages() is identical case as migrate_pages()
Signed-off-by: Joonsoo Kim js1...@gmail.com
Cc: Christoph Lameter c...@linux.com
Acked-by: Christoph Lameter c...@linux.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
[Patch 2/4]: add Acked-by: Michal Nazarewicz min...@mina86.com
[Patch 3/4]: commit log is changed according to Michal Nazarewicz's suggestion.
There is no other change from v2.
Just resend as ping for Andrew.
diff --git a/mm/migrate.c b/mm/migrate.c
index be26d5c..f495c58 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -982,6 +982,7 @@ int migrate_pages(struct list_head *from,
for(pass = 0; pass 10 retry; pass++) {
retry = 0;
+ nr_failed = 0;
list_for_each_entry_safe(page, page2, from, lru) {
cond_resched();
@@ -1029,6 +1030,7 @@ int migrate_huge_pages(struct list_head *from,
for (pass = 0; pass 10 retry; pass++) {
retry = 0;
+ nr_failed = 0;
list_for_each_entry_safe(page, page2, from, lru) {
cond_resched();
--
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/
[RESEND PATCH 2/4 v3] mm: fix possible incorrect return value of migrate_pages() syscall
do_migrate_pages() can return the number of pages not migrated. Because migrate_pages() syscall return this value directly, migrate_pages() syscall may return the number of pages not migrated. In fail case in migrate_pages() syscall, we should return error value. So change err to -EBUSY Additionally, Correct comment above do_migrate_pages() Signed-off-by: Joonsoo Kim js1...@gmail.com Cc: Sasha Levin levinsasha...@gmail.com Cc: Christoph Lameter c...@linux.com Acked-by: Michal Nazarewicz min...@mina86.com diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 1d771e4..0732729 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -948,7 +948,7 @@ static int migrate_to_node(struct mm_struct *mm, int source, int dest, * Move pages between the two nodesets so as to preserve the physical * layout as much as possible. * - * Returns the number of page that could not be moved. + * Returns error or the number of pages not migrated. */ int do_migrate_pages(struct mm_struct *mm, const nodemask_t *from, const nodemask_t *to, int flags) @@ -1382,6 +1382,8 @@ SYSCALL_DEFINE4(migrate_pages, pid_t, pid, unsigned long, maxnode, err = do_migrate_pages(mm, old, new, capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE); + if (err 0) + err = -EBUSY; mmput(mm); out: -- 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/
[RESEND PATCH 4/4 v3] mm: fix possible incorrect return value of move_pages() syscall
move_pages() syscall may return success in case that do_move_page_to_node_array return positive value which means migration failed. This patch changes return value of do_move_page_to_node_array for not returning positive value. It can fix the problem. Signed-off-by: Joonsoo Kim js1...@gmail.com Cc: Brice Goglin br...@myri.com Cc: Christoph Lameter c...@linux.com Cc: Minchan Kim minc...@kernel.org diff --git a/mm/migrate.c b/mm/migrate.c index f495c58..eeaf409 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1172,7 +1172,7 @@ set_status: } up_read(mm-mmap_sem); - return err; + return err 0 ? -EBUSY : err; } /* -- 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/
