Re: sleeping while atomic in dwc3_gadget_start
On Wed, Jun 26, 2013 at 02:52:56PM -0700, Stephen Boyd wrote:
> Hi,
>
> I'm getting the folllowing BUG message on bootup with 3.10-rc5
>
> BUG: sleeping function called from invalid context at mm/slub.c:926
> in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc5-gee3e35b-09316-ge78f3b35
> #643
> [] (unwind_backtrace+0x0/0x120) from []
> (show_stack+0x10/0x14)
> [] (show_stack+0x10/0x14) from []
> (kmem_cache_alloc_trace+0x3c/0x210)
> [] (kmem_cache_alloc_trace+0x3c/0x210) from []
> (request_threaded_irq+0x88/0x11c)
> [] (request_threaded_irq+0x88/0x11c) from []
> (dwc3_gadget_start+0x198/0x200)
> [] (dwc3_gadget_start+0x198/0x200) from []
> (udc_bind_to_driver+0x70/0xd8)
> [] (udc_bind_to_driver+0x70/0xd8) from []
> (usb_gadget_probe_driver+0x8c/0xb8)
>
> and I suspect this problem was introduced in commit 8698e2acf
> (usb: dwc3: gadget: introduce and use enable/disable irq
> methods). Is there a fix for this problem? Can we just move the
> irq request outside the spinlock?
nice :-)
how about this ?
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index b5e5b35..a8e6b8b 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1508,6 +1508,15 @@ static int dwc3_gadget_start(struct usb_gadget *g,
int irq;
u32 reg;
+ irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
+ IRQF_SHARED | IRQF_ONESHOT, "dwc3", dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
+ irq, ret);
+ goto err0;
+ }
+
spin_lock_irqsave(&dwc->lock, flags);
if (dwc->gadget_driver) {
@@ -1515,7 +1524,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
dwc->gadget.name,
dwc->gadget_driver->driver.name);
ret = -EBUSY;
- goto err0;
+ goto err1;
}
dwc->gadget_driver = driver;
@@ -1551,41 +1560,33 @@ static int dwc3_gadget_start(struct usb_gadget *g,
ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
- goto err0;
+ goto err1;
}
dep = dwc->eps[1];
ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
- goto err1;
+ goto err2;
}
/* begin to receive SETUP packets */
dwc->ep0state = EP0_SETUP_PHASE;
dwc3_ep0_out_start(dwc);
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
- ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
- IRQF_SHARED | IRQF_ONESHOT, "dwc3", dwc);
- if (ret) {
- dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
- irq, ret);
- goto err1;
- }
-
dwc3_gadget_enable_irq(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
return 0;
-err1:
+err2:
__dwc3_gadget_ep_disable(dwc->eps[0]);
-err0:
+err1:
spin_unlock_irqrestore(&dwc->lock, flags);
+err0:
return ret;
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline
On 06/27/2013 03:04 AM, Tejun Heo wrote: > Hey, > > On Wed, Jun 26, 2013 at 11:58:48PM +0530, Srivatsa S. Bhat wrote: >> Yes, we were discussing hot-unplug latency for use-cases such as >> suspend/resume. We didn't want to make those operations slower in the >> process of removing stop_machine() from hotplug. > > Can you please explain why tho? Sure. > How much would it help in terms of > power-saving? Or are there other issues in taking longer to shut down > cpus? > Basically, power-management techniques (like suspend/resume as used on smartphones etc) are implemented using a controlling algorithm which controls the aggressiveness of power-management depending on the load on the system. Today, the cpuidle subsystem in Linux handles cpuidle transitions using that technique, so I'll explain using that as an example. Similar strategies are used for suspend/resume also. For every cpuidle state, we have atleast 2 parameters that determine how usable it is - 1. exit latency 2. target residency. The exit latency captures the amount of time it takes to come out of the power-saving state, from the time you asked it to come out. This is an estimate of how "deep" the power-saving state is. The deeper it is, the longer it takes to come out. (And of course, deeper states give higher power-savings). The target residency is a value which represents the break-even for that state. It tells us how long we should stay in that idle state (at a minimum) before we ask it to come out, to actually get some good power-savings out of that state. (Note that entry and exit to an idle state itself consumes some power, so there won't be any power-savings if we keep entering and exiting a deep state without staying in that state long enough). Once the idle states are characterized like this, the cpuidle subsystem uses a cpuidle "governor" to actually decide which of the states to enter, given an idle period of time. The governor keeps track of the load on the system and predicts the length of the next idle period, and based on that prediction, it selects the idle state whose characteristics (exit latency/target residency) match the predicted idle time closely. So as we can see, the "deeper" the idle state, the lower its chance of getting used during regular workload runs, because it is deemed too costly. So entry/exit latency of an idle state is a very important aspect which determines how often you can use that state. Ideally we want states which are "deep" in the sense that they give huge power-savings, but "light" in the sense that their entry/exit latencies are low. Such states give us the best benefits, since we can use them aggressively. Now a similar argument applies for suspend/resume (on smartphones etc). Suspend/resume already gives good power-savings. But if we make it slower, the chances of using it profitably begins to reduce. That's why, IMHO, its important to keep a check on the latency of CPU hotplug and reduce it if possible. And that becomes even more important as systems keep sporting more and more CPUs. Regards, Srivatsa S. Bhat -- 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] spi: s3c64xx: add missing check for polling mode
After the patch "spi/s3c64xx: Fix non-dmaengine usage" with commit id 563b444e33810f3120838620c990480304e24e63 submitted by Mark Brown, the spi device detection in polling mode breaks. This revealed the missing check for polling during dma prepare. This patch adds the missing check. Signed-off-by: Girish K S --- drivers/spi/spi-s3c64xx.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c index d170cc0..ea82baa 100644 --- a/drivers/spi/spi-s3c64xx.c +++ b/drivers/spi/spi-s3c64xx.c @@ -434,6 +434,9 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master *spi) dma_cap_mask_t mask; int ret; + if (is_polling(sdd)) + return 0; + dma_cap_zero(mask); dma_cap_set(DMA_SLAVE, mask); -- 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 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
On 2013/6/27 14:34, Tomi Valkeinen wrote: > On 27/06/13 04:51, Yijing Wang wrote: >> On 2013/6/26 21:15, Tomi Valkeinen wrote: > >>> I couldn't find the rest of this series, and I'm not familiar with PCI. >>> So: is this patch and "aty128fb: use pdev->pm_cap instead of >>> pci_find_capability(..,PCI_CAP_ID_PM)" safe to apply for fbdev-3.11 >>> without anything else? I.e. has the PCI core changes been merged in 3.10 >>> or ealier? >> >> Hi Tomi, >>Thanks for your reply. Yes, it's safe, because PCI core has been use >> pdev->pm_cap to save >> the pm capability offset already. And PCI core changes related this pm init >> code has been merged >> long long ago(since year 2008). This series changes just to simplifier >> driver code about pm code. >> It's not necessary to access pci device register to get pm cap again, >> drivers can use pci device pm_cap >> member. and this series had no changes in PCI core. The rest of this series >> like for bnx2, bnx2x etc has >> been tested and accepted by other subsystems. > > Ok, thanks. I'll apply the two patches to my fbdev-3.11 branch. > > Tomi > > Thanks very much! -- Thanks! Yijing -- 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] x86/mce: Update MCE severity condition check
On Wed, Jun 26, 2013 at 11:10:52PM +0200, Borislav Petkov wrote: > Date: Wed, 26 Jun 2013 23:10:52 +0200 > From: Borislav Petkov > To: "Luck, Tony" > Cc: "linux-kernel@vger.kernel.org" , Chen > Gong , "Naveen N. Rao" > > Subject: Re: [PATCH] x86/mce: Update MCE severity condition check > User-Agent: Mutt/1.5.21 (2010-09-15) > > On Wed, Jun 26, 2013 at 09:00:10PM +, Luck, Tony wrote: > > > And this obviously is the case for the hardware too, I assume, not only > > > the SDM? > > > > Yes - we have a magic process which reconfigures all deployed silicon > > whenever > > a new SDM is published :-) > > Haha, I wouldn't wonder if your silicon dudes come up with > reprogrammable fuses someday :-) If so, it must be a catastrophe and the guys who wrote SDM have a big trouble ... ;-) signature.asc Description: Digital signature
Re: [PATCH] m68knommu: Mark config_BSP() __init
On Thu, Jun 27, 2013 at 1:08 AM, Greg Ungerer wrote:
> On 26/06/13 05:40, Geert Uytterhoeven wrote:
>>
>> Some instances of config_BSP() lack an __init annotation.
>>
>> Signed-off-by: Geert Uytterhoeven
>
>
> Acked-by: Greg Ungerer
>
> Looks good. Are you going to push it via your tree, or do you want
> me too?
As it's m68nommu, perhaps through your tree? Unless you don't have time to
handle it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/8] vfio: add external user support
Hi Alexy,
On Thu, 27 Jun 2013 15:02:31 +1000 Alexey Kardashevskiy wrote:
>
> index c488da5..54192b2 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1370,6 +1370,59 @@ static const struct file_operations vfio_device_fops =
> {
> };
>
> /**
> + * External user API, exported by symbols to be linked dynamically.
> + */
> +
> +/* Allows an external user (for example, KVM) to lock an IOMMU group */
> +static int vfio_group_add_external_user(struct file *filep)
> +{
> + struct vfio_group *group = filep->private_data;
> +
> + if (filep->f_op != &vfio_group_fops)
> + return -EINVAL;
> +
> + if (!atomic_inc_not_zero(&group->container_users))
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vfio_group_add_external_user);
You cannot EXPORT a static symbol ... The same through the rest of the
file.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpzMgEcoJa6w.pgp
Description: PGP signature
Re: [PATCH 1/2] media: davinci: vpif: capture: add V4L2-async support
On Thu June 27 2013 08:13:40 Prabhakar Lad wrote:
> Hi Hans,
>
> Thanks for the review.
>
> On Thu, Jun 27, 2013 at 11:27 AM, Hans Verkuil wrote:
> > On Tue June 25 2013 17:17:34 Prabhakar Lad wrote:
> >> From: "Lad, Prabhakar"
> >>
> >> Add support for asynchronous subdevice probing, using the v4l2-async API.
> >> The legacy synchronous mode is still supported too, which allows to
> >> gradually update drivers and platforms.
> >>
> >> Signed-off-by: Prabhakar Lad
> >> Cc: Guennadi Liakhovetski
> >> Cc: Hans Verkuil
> >> Cc: Laurent Pinchart
> >> Cc: Sakari Ailus
> >> Cc: Mauro Carvalho Chehab
> >> ---
> >> drivers/media/platform/davinci/vpif_capture.c | 151
> >> +
> >> drivers/media/platform/davinci/vpif_capture.h |2 +
> >> include/media/davinci/vpif_types.h|2 +
> >> 3 files changed, 107 insertions(+), 48 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> >> b/drivers/media/platform/davinci/vpif_capture.c
> >> index 5514175..b11d7a7 100644
> >> --- a/drivers/media/platform/davinci/vpif_capture.c
> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
> >> @@ -1979,6 +1979,76 @@ vpif_init_free_channel_objects:
> >> return err;
> >> }
> >>
> >> +static int vpif_async_bound(struct v4l2_async_notifier *notifier,
> >> + struct v4l2_subdev *subdev,
> >> + struct v4l2_async_subdev *asd)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; i < vpif_obj.config->subdev_count; i++)
> >> + if (!strcmp(vpif_obj.config->subdev_info[i].name,
> >> + subdev->name)) {
> >
> > Since the subdev name is now prefixed with the i2c bus identifier instead of
> > just the chip name, does this code still work? Shouldn't it be 'strstr'
> > instead
> > of strcmp? Ditto for vpif_display and possibly others where the same
> > mechanism might be used.
> >
> This is because the DA850-EVM has two tvp514x devices and assigning
> the tvp514x device to appropriate channel is important, In this case strstr()
> wont work so I used strcmp instead to match it appropriately.
>
> Yes the code still works tested on DA850-EVM, with this patch [1].
>
> [1]
> http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/commitdiff/c906a89762541361158cf73e9494fa2f1ff8ba02
Ah, OK. That's what I wanted to verify!
Regards,
Hans
>
> Regards,
> --Prabhakar Lad
>
--
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 net-next 3/5] inetpeer: use generic union inet_addr
Signed-off-by: Cong Wang
---
include/net/inetpeer.h | 29 +--
net/ipv4/inetpeer.c| 35 +++---
net/ipv4/tcp_metrics.c | 92
3 files changed, 68 insertions(+), 88 deletions(-)
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 53f464d..7ec33fb 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -13,24 +13,13 @@
#include
#include
#include
+#include
#include
-struct inetpeer_addr_base {
- union {
- __be32 a4;
- __be32 a6[4];
- };
-};
-
-struct inetpeer_addr {
- struct inetpeer_addr_base addr;
- __u16 family;
-};
-
struct inet_peer {
/* group together avl_left,avl_right,v4daddr to speedup lookups */
struct inet_peer __rcu *avl_left, *avl_right;
- struct inetpeer_addrdaddr;
+ union inet_addr daddr;
__u32 avl_height;
u32 metrics[RTAX_MAX];
@@ -133,17 +122,17 @@ static inline bool inet_metrics_new(const struct
inet_peer *p)
/* can be called with or without local BH being disabled */
struct inet_peer *inet_getpeer(struct inet_peer_base *base,
- const struct inetpeer_addr *daddr,
+ const union inet_addr *daddr,
int create);
static inline struct inet_peer *inet_getpeer_v4(struct inet_peer_base *base,
__be32 v4daddr,
int create)
{
- struct inetpeer_addr daddr;
+ union inet_addr daddr;
- daddr.addr.a4 = v4daddr;
- daddr.family = AF_INET;
+ daddr.sin.sin_addr.s_addr = v4daddr;
+ daddr.sa.sa_family = AF_INET;
return inet_getpeer(base, &daddr, create);
}
@@ -151,10 +140,10 @@ static inline struct inet_peer *inet_getpeer_v6(struct
inet_peer_base *base,
const struct in6_addr *v6daddr,
int create)
{
- struct inetpeer_addr daddr;
+ union inet_addr daddr;
- *(struct in6_addr *)daddr.addr.a6 = *v6daddr;
- daddr.family = AF_INET6;
+ daddr.sin6.sin6_addr = *v6daddr;
+ daddr.sa.sa_family = AF_INET6;
return inet_getpeer(base, &daddr, create);
}
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 000e3d2..94a9ba7 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -197,17 +197,24 @@ void __init inet_initpeers(void)
INIT_DEFERRABLE_WORK(&gc_work, inetpeer_gc_worker);
}
-static int addr_compare(const struct inetpeer_addr *a,
- const struct inetpeer_addr *b)
+static int addr_compare(const union inet_addr *a,
+ const union inet_addr *b)
{
- int i, n = (a->family == AF_INET ? 1 : 4);
+ int i;
- for (i = 0; i < n; i++) {
- if (a->addr.a6[i] == b->addr.a6[i])
- continue;
- if ((__force u32)a->addr.a6[i] < (__force u32)b->addr.a6[i])
+ if (a->sa.sa_family == AF_INET) {
+ if (a->sin.sin_addr.s_addr == b->sin.sin_addr.s_addr)
+ return 0;
+ if ((__force u32)a->sin.sin_addr.s_addr < (__force
u32)b->sin.sin_addr.s_addr)
return -1;
- return 1;
+ } else {
+ for (i = 0; i < 4; i++) {
+ if (a->sin6.sin6_addr.s6_addr32[i] ==
b->sin6.sin6_addr.s6_addr32[i])
+ continue;
+ if ((__force u32)a->sin6.sin6_addr.s6_addr32[i] <
(__force u32)b->sin6.sin6_addr.s6_addr32[i])
+ return -1;
+ return 1;
+ }
}
return 0;
@@ -248,7 +255,7 @@ static int addr_compare(const struct inetpeer_addr *a,
* But every pointer we follow is guaranteed to be valid thanks to RCU.
* We exit from this function if number of links exceeds PEER_MAXDEPTH
*/
-static struct inet_peer *lookup_rcu(const struct inetpeer_addr *daddr,
+static struct inet_peer *lookup_rcu(const union inet_addr *daddr,
struct inet_peer_base *base)
{
struct inet_peer *u = rcu_dereference(base->root);
@@ -457,7 +464,7 @@ static int inet_peer_gc(struct inet_peer_base *base,
}
struct inet_peer *inet_getpeer(struct inet_peer_base *base,
- const struct inetpeer_addr *daddr,
+ const union inet_addr *daddr,
int create)
{
struct inet_peer __rcu **stack[PEER_MAXDEPTH], ***stackptr;
@@ -465,7 +472,7 @@ struct inet_peer *inet_getpeer(struct inet_peer_base *base,
unsigned int sequence;
int invalidated, gccnt = 0;
- flush_
[PATCH] arch: cris: mm: add a code block for variable declaration
Need a code block for variable declaration, or can not pass compiling
by old C compiler.
The new C compiler will report the warning (with allmodconfig):
arch/cris/mm/fault.c: In function ‘do_page_fault’:
arch/cris/mm/fault.c:228:3: warning: ISO C90 forbids mixed declarations and
code [-Wdeclaration-after-statement]
Signed-off-by: Chen Gang
---
arch/cris/mm/fault.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/cris/mm/fault.c b/arch/cris/mm/fault.c
index 73312ab..919ab17c 100644
--- a/arch/cris/mm/fault.c
+++ b/arch/cris/mm/fault.c
@@ -225,8 +225,10 @@ retry:
show_registers(regs);
#ifdef CONFIG_NO_SEGFAULT_TERMINATION
- DECLARE_WAIT_QUEUE_HEAD(wq);
- wait_event_interruptible(wq, 0 == 1);
+ {
+ DECLARE_WAIT_QUEUE_HEAD(wq);
+ wait_event_interruptible(wq, 0 == 1);
+ }
#else
info.si_signo = SIGSEGV;
info.si_errno = 0;
--
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/
[RFC Patch net-next 4/5] sunrpc: use generic union inet_addr
Signed-off-by: Cong Wang
---
include/linux/sunrpc/addr.h | 119 +++
include/net/inet_addr.h | 56
2 files changed, 64 insertions(+), 111 deletions(-)
diff --git a/include/linux/sunrpc/addr.h b/include/linux/sunrpc/addr.h
index 07d8e53..4c3602e 100644
--- a/include/linux/sunrpc/addr.h
+++ b/include/linux/sunrpc/addr.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
size_t rpc_ntop(const struct sockaddr *, char *, const size_t);
size_t rpc_pton(struct net *, const char *, const size_t,
@@ -21,137 +22,33 @@ size_t rpc_uaddr2sockaddr(struct net *, const
char *, const size_t,
static inline unsigned short rpc_get_port(const struct sockaddr *sap)
{
- switch (sap->sa_family) {
- case AF_INET:
- return ntohs(((struct sockaddr_in *)sap)->sin_port);
- case AF_INET6:
- return ntohs(((struct sockaddr_in6 *)sap)->sin6_port);
- }
- return 0;
+ return inet_addr_get_port((const union inet_addr *)sap);
}
static inline void rpc_set_port(struct sockaddr *sap,
const unsigned short port)
{
- switch (sap->sa_family) {
- case AF_INET:
- ((struct sockaddr_in *)sap)->sin_port = htons(port);
- break;
- case AF_INET6:
- ((struct sockaddr_in6 *)sap)->sin6_port = htons(port);
- break;
- }
+ inet_addr_set_port((union inet_addr *)sap, port);
}
#define IPV6_SCOPE_DELIMITER '%'
#define IPV6_SCOPE_ID_LEN sizeof("%nn")
-static inline bool __rpc_cmp_addr4(const struct sockaddr *sap1,
- const struct sockaddr *sap2)
-{
- const struct sockaddr_in *sin1 = (const struct sockaddr_in *)sap1;
- const struct sockaddr_in *sin2 = (const struct sockaddr_in *)sap2;
-
- return sin1->sin_addr.s_addr == sin2->sin_addr.s_addr;
-}
-
-static inline bool __rpc_copy_addr4(struct sockaddr *dst,
- const struct sockaddr *src)
-{
- const struct sockaddr_in *ssin = (struct sockaddr_in *) src;
- struct sockaddr_in *dsin = (struct sockaddr_in *) dst;
-
- dsin->sin_family = ssin->sin_family;
- dsin->sin_addr.s_addr = ssin->sin_addr.s_addr;
- return true;
-}
-
-#if IS_ENABLED(CONFIG_IPV6)
-static inline bool __rpc_cmp_addr6(const struct sockaddr *sap1,
- const struct sockaddr *sap2)
-{
- const struct sockaddr_in6 *sin1 = (const struct sockaddr_in6 *)sap1;
- const struct sockaddr_in6 *sin2 = (const struct sockaddr_in6 *)sap2;
-
- if (!ipv6_addr_equal(&sin1->sin6_addr, &sin2->sin6_addr))
- return false;
- else if (ipv6_addr_type(&sin1->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- return sin1->sin6_scope_id == sin2->sin6_scope_id;
-
- return true;
-}
-
-static inline bool __rpc_copy_addr6(struct sockaddr *dst,
- const struct sockaddr *src)
-{
- const struct sockaddr_in6 *ssin6 = (const struct sockaddr_in6 *) src;
- struct sockaddr_in6 *dsin6 = (struct sockaddr_in6 *) dst;
-
- dsin6->sin6_family = ssin6->sin6_family;
- dsin6->sin6_addr = ssin6->sin6_addr;
- dsin6->sin6_scope_id = ssin6->sin6_scope_id;
- return true;
-}
-#else /* !(IS_ENABLED(CONFIG_IPV6) */
-static inline bool __rpc_cmp_addr6(const struct sockaddr *sap1,
- const struct sockaddr *sap2)
-{
- return false;
-}
-
-static inline bool __rpc_copy_addr6(struct sockaddr *dst,
- const struct sockaddr *src)
-{
- return false;
-}
-#endif /* !(IS_ENABLED(CONFIG_IPV6) */
-
-/**
- * rpc_cmp_addr - compare the address portion of two sockaddrs.
- * @sap1: first sockaddr
- * @sap2: second sockaddr
- *
- * Just compares the family and address portion. Ignores port, but
- * compares the scope if it's a link-local address.
- *
- * Returns true if the addrs are equal, false if they aren't.
- */
static inline bool rpc_cmp_addr(const struct sockaddr *sap1,
const struct sockaddr *sap2)
{
- if (sap1->sa_family == sap2->sa_family) {
- switch (sap1->sa_family) {
- case AF_INET:
- return __rpc_cmp_addr4(sap1, sap2);
- case AF_INET6:
- return __rpc_cmp_addr6(sap1, sap2);
- }
- }
- return false;
+ return inet_addr_equal((const union inet_addr *)sap1,
+ (const union inet_addr *)sap2);
}
-/**
- * rpc_copy_addr - copy the address portion of one sockaddr to another
- * @dst: destination sockaddr
- * @src: source sockaddr
- *
- * Just copies the address portion and family. Ignores port, scope, etc.
- * Caller is responsible for making certain that dst is large enough to hold
- *
[RFC Patch net-next 5/5] nfs,cifs: abstract generic inet_addr_equal_strict()
Signed-off-by: Cong Wang
---
fs/cifs/connect.c | 38 -
fs/dlm/lowcomms.c | 24 ++-
fs/nfs/client.c| 94 ++-
fs/nfs/nfs4filelayoutdev.c | 37 ++---
fs/nfs/super.c | 31 +-
include/net/inet_addr.h| 32 +-
6 files changed, 55 insertions(+), 201 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index e3bc39b..ca6bcf82 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include "cifspdu.h"
@@ -1886,17 +1887,10 @@ srcip_matches(struct sockaddr *srcaddr, struct sockaddr
*rhs)
{
switch (srcaddr->sa_family) {
case AF_UNSPEC:
- return (rhs->sa_family == AF_UNSPEC);
- case AF_INET: {
- struct sockaddr_in *saddr4 = (struct sockaddr_in *)srcaddr;
- struct sockaddr_in *vaddr4 = (struct sockaddr_in *)rhs;
- return (saddr4->sin_addr.s_addr == vaddr4->sin_addr.s_addr);
- }
- case AF_INET6: {
- struct sockaddr_in6 *saddr6 = (struct sockaddr_in6 *)srcaddr;
- struct sockaddr_in6 *vaddr6 = (struct sockaddr_in6 *)rhs;
- return ipv6_addr_equal(&saddr6->sin6_addr, &vaddr6->sin6_addr);
- }
+ case AF_INET:
+ case AF_INET6:
+ return inet_addr_equal((union inet_addr *)srcaddr,
+ (union inet_addr *)rhs);
default:
WARN_ON(1);
return false; /* don't expect to be here */
@@ -1943,24 +1937,10 @@ match_address(struct TCP_Server_Info *server, struct
sockaddr *addr,
struct sockaddr *srcaddr)
{
switch (addr->sa_family) {
- case AF_INET: {
- struct sockaddr_in *addr4 = (struct sockaddr_in *)addr;
- struct sockaddr_in *srv_addr4 =
- (struct sockaddr_in *)&server->dstaddr;
-
- if (addr4->sin_addr.s_addr != srv_addr4->sin_addr.s_addr)
- return false;
- break;
- }
- case AF_INET6: {
- struct sockaddr_in6 *addr6 = (struct sockaddr_in6 *)addr;
- struct sockaddr_in6 *srv_addr6 =
- (struct sockaddr_in6 *)&server->dstaddr;
-
- if (!ipv6_addr_equal(&addr6->sin6_addr,
-&srv_addr6->sin6_addr))
- return false;
- if (addr6->sin6_scope_id != srv_addr6->sin6_scope_id)
+ case AF_INET:
+ case AF_INET6:
+ if (!inet_addr_equal((union inet_addr *)addr,
+(union inet_addr *)&server->dstaddr))
return false;
break;
}
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index d0ccd2f..c27e36e 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include "dlm_internal.h"
#include "lowcomms.h"
@@ -285,28 +286,13 @@ static struct dlm_node_addr *find_node_addr(int nodeid)
static int addr_compare(struct sockaddr_storage *x, struct sockaddr_storage *y)
{
switch (x->ss_family) {
- case AF_INET: {
- struct sockaddr_in *sinx = (struct sockaddr_in *)x;
- struct sockaddr_in *siny = (struct sockaddr_in *)y;
- if (sinx->sin_addr.s_addr != siny->sin_addr.s_addr)
- return 0;
- if (sinx->sin_port != siny->sin_port)
- return 0;
- break;
- }
- case AF_INET6: {
- struct sockaddr_in6 *sinx = (struct sockaddr_in6 *)x;
- struct sockaddr_in6 *siny = (struct sockaddr_in6 *)y;
- if (!ipv6_addr_equal(&sinx->sin6_addr, &siny->sin6_addr))
- return 0;
- if (sinx->sin6_port != siny->sin6_port)
- return 0;
- break;
- }
+ case AF_INET:
+ case AF_INET6:
+ return inet_addr_equal_strict((union inet_addr *)x,
+ (union inet_addr *)y);
default:
return 0;
}
- return 1;
}
static int nodeid_to_addr(int nodeid, struct sockaddr_storage *sas_out,
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index c513b0c..69a7561 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -283,75 +284,6 @@ void nfs_put_client(struct nfs_client *clp)
}
EXPORT_SYMBOL_GPL(nfs_put_client);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-/*
- * Test if two ip6 socket addresses refer to the same socket by
- * comparing relevant fields. The padding bytes specifically, are not
- * compared. sin6_flowin
[RFC Patch net-next 1/5] net: introduce generic union inet_addr
Cc: Daniel Borkmann
Signed-off-by: Cong Wang
---
Documentation/printk-formats.txt |9 +
drivers/net/netconsole.c | 22 ++---
include/linux/netpoll.h |9 +-
include/net/inet_addr.h | 62 ++
lib/vsprintf.c | 18 ++-
net/core/netpoll.c | 52 ++-
6 files changed, 122 insertions(+), 50 deletions(-)
create mode 100644 include/net/inet_addr.h
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 3af5ae6..26ff336 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -121,6 +121,15 @@ IPv6 addresses:
print a compressed IPv6 address as described by
http://tools.ietf.org/html/rfc5952
+Generic IP addresses:
+
+ %pIg
+ %pig
+
+ For printing genernic IP address, which has union inet_addr type.
+ The 'Ig' specifier is same with 'I4' (for IPv4 addresses) or 'I6'
+ (for IPv6 address), 'ig' is same with 'i4' or 'i6'.
+
UUID/GUID addresses:
%pUb00010203-0405-0607-0809-0a0b0c0d0e0f
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 1d1d0a1..02d7389 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -269,18 +269,12 @@ static ssize_t show_remote_port(struct netconsole_target
*nt, char *buf)
static ssize_t show_local_ip(struct netconsole_target *nt, char *buf)
{
- if (nt->np.ipv6)
- return snprintf(buf, PAGE_SIZE, "%pI6c\n",
&nt->np.local_ip.in6);
- else
- return snprintf(buf, PAGE_SIZE, "%pI4\n", &nt->np.local_ip);
+ return snprintf(buf, PAGE_SIZE, "%pIg\n", &nt->np.local_ip);
}
static ssize_t show_remote_ip(struct netconsole_target *nt, char *buf)
{
- if (nt->np.ipv6)
- return snprintf(buf, PAGE_SIZE, "%pI6c\n",
&nt->np.remote_ip.in6);
- else
- return snprintf(buf, PAGE_SIZE, "%pI4\n", &nt->np.remote_ip);
+ return snprintf(buf, PAGE_SIZE, "%pIg\n", &nt->np.remote_ip);
}
static ssize_t show_local_mac(struct netconsole_target *nt, char *buf)
@@ -418,17 +412,19 @@ static ssize_t store_local_ip(struct netconsole_target
*nt,
if (strnchr(buf, count, ':')) {
const char *end;
- if (in6_pton(buf, count, nt->np.local_ip.in6.s6_addr, -1, &end)
> 0) {
+ if (in6_pton(buf, count,
nt->np.local_ip.sin6.sin6_addr.s6_addr, -1, &end) > 0) {
if (*end && *end != '\n') {
printk(KERN_ERR "netconsole: invalid IPv6
address at: <%c>\n", *end);
return -EINVAL;
}
+ nt->np.local_ip.sa.sa_family = AF_INET6;
nt->np.ipv6 = true;
} else
return -EINVAL;
} else {
if (!nt->np.ipv6) {
- nt->np.local_ip.ip = in_aton(buf);
+ nt->np.local_ip.sin.sin_addr.s_addr = in_aton(buf);
+ nt->np.local_ip.sa.sa_family = AF_INET;
} else
return -EINVAL;
}
@@ -449,17 +445,19 @@ static ssize_t store_remote_ip(struct netconsole_target
*nt,
if (strnchr(buf, count, ':')) {
const char *end;
- if (in6_pton(buf, count, nt->np.remote_ip.in6.s6_addr, -1,
&end) > 0) {
+ if (in6_pton(buf, count,
nt->np.remote_ip.sin6.sin6_addr.s6_addr, -1, &end) > 0) {
if (*end && *end != '\n') {
printk(KERN_ERR "netconsole: invalid IPv6
address at: <%c>\n", *end);
return -EINVAL;
}
+ nt->np.remote_ip.sa.sa_family = AF_INET6;
nt->np.ipv6 = true;
} else
return -EINVAL;
} else {
if (!nt->np.ipv6) {
- nt->np.remote_ip.ip = in_aton(buf);
+ nt->np.remote_ip.sin.sin_addr.s_addr = in_aton(buf);
+ nt->np.remote_ip.sa.sa_family = AF_INET;
} else
return -EINVAL;
}
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index f3c7c24..3884834 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -11,14 +11,7 @@
#include
#include
#include
-
-union inet_addr {
- __u32 all[4];
- __be32 ip;
- __be32 ip6[4];
- struct in_addr in;
- struct in6_addr in6;
-};
+#include
struct netpoll {
struct net_device *dev;
diff --git a/include/net/inet_addr.h b/include/net/inet_addr.h
new file mode 100644
index 000..66a16fe
--- /dev/null
+++ b/include/net/inet_addr.h
@@ -0,0 +1,62 @@
+#ifndef _INET_ADDR_H
+#define _INET_ADDR_H
+
[RFC Patch net-next 2/5] net: introduce generic inet_pton()
Signed-off-by: Cong Wang
---
include/net/inet_addr.h | 20
net/core/netpoll.c | 24 ++--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/net/inet_addr.h b/include/net/inet_addr.h
index 66a16fe..1379287 100644
--- a/include/net/inet_addr.h
+++ b/include/net/inet_addr.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
union inet_addr {
@@ -59,4 +60,23 @@ static inline bool inet_addr_multicast(const union inet_addr
*ipa)
}
#endif
+static inline int inet_pton(const char *str, union inet_addr *addr)
+{
+ const char *end;
+
+ if (!strchr(str, ':') &&
+ in4_pton(str, -1, (void *)addr, -1, &end) > 0) {
+ if (!*end)
+ return 0;
+ }
+ if (in6_pton(str, -1, addr->sin6.sin6_addr.s6_addr, -1, &end) > 0) {
+#if IS_ENABLED(CONFIG_IPV6)
+ if (!*end)
+ return 1;
+#else
+ return -1;
+#endif
+ }
+ return -1;
+}
#endif
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c300358..6631b5e 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -907,26 +907,6 @@ void netpoll_print_options(struct netpoll *np)
}
EXPORT_SYMBOL(netpoll_print_options);
-static int netpoll_parse_ip_addr(const char *str, union inet_addr *addr)
-{
- const char *end;
-
- if (!strchr(str, ':') &&
- in4_pton(str, -1, (void *)addr, -1, &end) > 0) {
- if (!*end)
- return 0;
- }
- if (in6_pton(str, -1, addr->sin6.sin6_addr.s6_addr, -1, &end) > 0) {
-#if IS_ENABLED(CONFIG_IPV6)
- if (!*end)
- return 1;
-#else
- return -1;
-#endif
- }
- return -1;
-}
-
int netpoll_parse_options(struct netpoll *np, char *opt)
{
char *cur=opt, *delim;
@@ -946,7 +926,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
if ((delim = strchr(cur, '/')) == NULL)
goto parse_failed;
*delim = 0;
- ipv6 = netpoll_parse_ip_addr(cur, &np->local_ip);
+ ipv6 = inet_pton(cur, &np->local_ip);
if (ipv6 < 0)
goto parse_failed;
else
@@ -982,7 +962,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
if ((delim = strchr(cur, '/')) == NULL)
goto parse_failed;
*delim = 0;
- ipv6 = netpoll_parse_ip_addr(cur, &np->remote_ip);
+ ipv6 = inet_pton(cur, &np->remote_ip);
if (ipv6 < 0)
goto parse_failed;
else if (np->ipv6 != (bool)ipv6)
--
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] Optimize wait_sb_inodes()
On Thu, Jun 27, 2013 at 02:18:17PM +0900, OGAWA Hirofumi wrote: > Dave Chinner writes: > > >> Optimizing wait_sb_inodes() might help lock contention, but it doesn't > >> help unnecessary wait/check. > > > > You have your own wait code, that doesn't make what the VFS does > > unnecesary. Quite frankly, I don't trust individual filesystems to > > get it right - there's a long history of filesystem specific data > > sync problems (including in XFS), and the best way to avoid that is > > to ensure the VFS gets it right for you. > > > > Indeed, we've gone from having sooper special secret sauce data sync > > code in XFS to using the VFS over the past few years, and the result > > is that it is now more reliable and faster than when we were trying > > to be smart and do it all ourselves. We got to where we are by > > fixing the problems in the VFS rather than continuing to try to work > > around them. > > I guess you are assuming FS which is using data=writeback or such. No, I'm not asumming anything about the filesystem. Indeed, many filesystems don't work like ext4 data=writeback/ordered, and to assume that they do at the VFS level is completely wrong. I'm saying that the VFS - which is tracking all the inodes with dirty data, and is starting IO on them - needs to also provide correct and efficient "wait for all inodes under IO" behaviour. it currently provides "correct", but it's not efficient. > > >> Since some FSes know about current > >> in-flight I/O already in those internal, so I think, those FSes can be > >> done it here, or are already doing in ->sync_fs(). > > > > Sure, do your internal checks in ->sync_fs(), but if > > wait_sb_inodes() does not have any lock contention and very little > > overhead, then why do you need to avoid it? This wait has to be done > > somewhere between sync_inodes_sb() dispatching all the IO and > > ->sync_fs completing, so what's the problem with hving the VFS do > > that *for everyone* efficiently? > > Are you saying the vfs should track all in-flight I/O with some sort of > transactional way? The VFs doesn't need to know a thing about filesystem transactions. > Otherwise, vfs can't know the data is whether after sync point or before > sync point, and have to wait or not. FS is using the behavior like > data=journal has tracking of those already, and can reuse it. The VFS writeback code already differentiates between data written during a sync operation and that dirtied after a sync operation. Perhaps you should look at the tagging for WB_SYNC_ALL writeback that write_cache_pages does But, anyway, we don't have to do that on the waiting side of things. All we need to do is add the inode to a "under IO" list on the bdi when the mapping is initially tagged with pages under writeback, and remove it from that list during IO completion when the mapping is no longer tagged as having pages under writeback. wait_sb_inodes() just needs to walk that list and wait on each inode to complete IO. It doesn't require *any awareness* of the underlying filesystem implementation or how the IO is actually issued - if there's IO in progress at the time wait_sb_inodes() is called, then it waits for it. > > Fix the root cause of the problem - the sub-optimal VFS code. > > Hacking around it specifically for out-of-tree code is not the way > > things get done around here... > > I'm thinking the root cause is vfs can't have knowledge of FS internal, > e.g. FS is handling data transactional way, or not. If the filesystem has transactional data/metadata that the VFS is not tracking, then that is what the ->sync_fs call is for. i.e. so the filesystem can then do what ever extra writeback/waiting it needs to do that the VFS is unaware of. We already cater for what Tux3 needs in the VFS - all you've done is found an inefficient algorithm that needs fixing. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] Delay initializing of large sections of memory
On Tue, Jun 25, 2013 at 11:58 AM, Mike Travis wrote: > experimenting as soon as I can. Our 32TB system is being > brought back to 16TB (we found a number of problems as we > get closer and closer to the 64TB limit), but that's still > a significant size. Hi, Mike, Can you post e820 memory map on system that have 32TiB or more? Is there one range size more than 16TiB? like [16TiB, 32TiB)... Thanks Yinghai -- 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: regression caused by commit 8357b48549e17b3e4e402c7f977b65708922e60f
Hi, On Thu, 27 Jun 2013 09:14:19 +0300 Felipe Balbi wrote: > > after commit 8357b48549e17b3e4e402c7f977b65708922e60f, > omap2plus_defconfig doesn't 'hold' the answer to USB Gadget Drivers > anymore. Everytime I run oldconfig, it asks me again and again what USB > Gadget Drivers should be (M/y/?). > > That's certainly not expected considering it wasn't like that before. That commit has been reverted in today's kbuild tree and thus in today's linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp66XGYfZUyB.pgp Description: PGP signature
Re: [PATCH] usb: dwc3: core: continue probe even if usb3 phy is not available
Hi, On Thu, Jun 27, 2013 at 08:14:16AM +0200, Michael Grzeschik wrote: > > > right, but in DT you will define both instances and each instance will > > > have a seaparate snps,maximum_speed attribute :-) > > > > > > I'm now considering if we should make maximum_speed a generic attribute, > > > Kishon ? Alex ? Alan ? > > > > > > anyone else needs such thing ? > > > > We have a force-full-speed attibute for chipidea on the way. This > > maximum_speed looks like a more generic alternative. Michael, what say > > you? > > The maximum_speed attribute sounds more reasonable. I will change my > patch to it. thanks, perhaps we can add a generic helper in udc-core or usb-common ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
On 27/06/13 04:51, Yijing Wang wrote: > On 2013/6/26 21:15, Tomi Valkeinen wrote: >> I couldn't find the rest of this series, and I'm not familiar with PCI. >> So: is this patch and "aty128fb: use pdev->pm_cap instead of >> pci_find_capability(..,PCI_CAP_ID_PM)" safe to apply for fbdev-3.11 >> without anything else? I.e. has the PCI core changes been merged in 3.10 >> or ealier? > > Hi Tomi, >Thanks for your reply. Yes, it's safe, because PCI core has been use > pdev->pm_cap to save > the pm capability offset already. And PCI core changes related this pm init > code has been merged > long long ago(since year 2008). This series changes just to simplifier driver > code about pm code. > It's not necessary to access pci device register to get pm cap again, drivers > can use pci device pm_cap > member. and this series had no changes in PCI core. The rest of this series > like for bnx2, bnx2x etc has > been tested and accepted by other subsystems. Ok, thanks. I'll apply the two patches to my fbdev-3.11 branch. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote: > On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett wrote: > > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote: > >> The fixed virtual address scheme currently being looked at for x86_64 to > >> make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit > >> because the address space isn't big enough. For ARM, given that we've > >> much more opportunity to work with the vendors, can we just avoid > >> transitioning to a virtual address map and always just install a > >> physical mapping before doing efi calls? > > > > We can probably get away with that now, but it does risk us ending up > > with some firmware that expects to run in physical mode (boards designed > > for Linux) and some firmware that expects to run in virtual mode (boards > > designed for Windows). The degree of lockdown in the Windows ecosystem > > at present means it's not a real problem at the moment, but if that ever > > changes we're going to risk incompatibility. > > What is the problem trying to be avoided by not using the virtual map? > Is it passing the virtual mapping data from one kernel to the next > when kexecing? Or something else? Where to begin ... SetVirtualAddressMap() is one massive hack job ... just look at the tiano core implementation. Basically it has a fixed idea of where all the pointers are and it tries to convert them all to the new address space. The problem we see in x86 is that this conversion process isn't exhaustive due to implementation cockups, so the post virtual address map image occasionally tries to access unconverted pointers via the old physical address and oopses the kernel. The problem for kexec is that SetVirtualAddressMap isn't idempotent. In fact by API fiat it can only ever be called once for the entire lifetime of the UEFI bios, which could be many kernels in a kexec situation. So, somehow the subsequent kernels have to know not to call it, plus, obviously, the virtual address map of the previous kernel has to work in the next because it can't set up a new one. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework
On Thu, 27 Jun 2013 09:32:56 +0530, Viresh Kumar wrote: > On 26 June 2013 19:28, Lukasz Majewski wrote: > > On Wed, 26 Jun 2013 16:35:32 +0530, Viresh Kumar wrote: > >> This patch is still few generations back :) > > > > But this is v2 version of boost patches. > > My mistake > > > Please also review: > > [PATCH v4 4/7] > > [PATCH v4 5/7] > > [PATCH v4 6/7] > > [PATCH v4 7/7] - disable boost at thermal framework > > don't worry I will review everything. I went home after reviewing half > of the patches. Ok, Thanks. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] watchdog: dw_wdt: add a devicetree binding
On 26 June 2013 23:35, Heiko Stübner wrote: > The dw_wdt does not use any platform-specific data, so no new properties > need to be introduced. The dw-apb-wdt naming follows other designware > components in the kernel and is also written like this in documentation > describing the component. > > Signed-off-by: Heiko Stuebner > --- > .../devicetree/bindings/watchdog/snps-dw-apb-wdt.txt | 18 > ++ > drivers/watchdog/dw_wdt.c| 10 ++ > 2 files changed, 28 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/watchdog/snps-dw-apb-wdt.txt > > diff --git a/Documentation/devicetree/bindings/watchdog/snps-dw-apb-wdt.txt > b/Documentation/devicetree/bindings/watchdog/snps-dw-apb-wdt.txt > new file mode 100644 > index 000..c20cdd1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/watchdog/snps-dw-apb-wdt.txt > @@ -0,0 +1,18 @@ > +* Synosis DesignWare APB Watchdog Probably should be Synopsis? -- With warm regards, Sachin -- 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: [v3.10-rc2] iwlwifi regression
On Wed, Jun 26, 2013 at 6:37 PM, Sedat Dilek wrote: > On Wed, Jun 26, 2013 at 6:16 PM, Jörg Otte wrote: >> 2013/5/25 Jörg Otte : >>> If iwlwifi/iwldvm are built into the kernel (no loadable modules) >>> following error is written to console and syslog since v3.10-rc: >>> >>> iwlwifi :08:00.0: failed to load module iwldvm (error -38), is >>> dynamic loading enabled? >>> >>> reverting >>> commit 1618b2b02a3a0ee7a6863fed4b0d22e697e7e97c >>> Author: Johannes Berg >>> Date: Thu Apr 4 10:35:23 2013 +0200 >>> iwlwifi: print warning on request_module failure >>> >>> fixes the problem for me. >>> >>> Jörg >>> >>> I'm not subscribed,please CC me in answeres >> >> We have rc-7 now and it's still not fixed. What is the problem? >> > > The patch is pending in wireless.git and is not in mainline, right. > AFAICS there was a recent pull request... so should be in rc8. > > commit 8edf3fd6eb0649b0f19363baf23bca39c6fbdba4 > "iwlwifi: don't print module loading error if not modular" > > - Sedat - > > http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=8edf3fd6eb0649b0f19363baf23bca39c6fbdba4 > Hi Jörg, the fix you are waiting for hit mainline several minutes ago. Regards, - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=98b6ed0f2bf4abfb759206aa70690636372bdee7 >> Thanks, Jörg >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 3.10-rc7
This is a set of seven bug fixes. Several fcoe fixes for locking
problems, initiator issues and a VLAN API change, all of which could
eventually lead to data corruption, one fix for a qla2xxx locking
problem which could lead to multiple completions of the same request
(and subsequent data corruption) and a use after free in the ipr driver.
Plus one minor MAINTAINERS file update for a mailing list change.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Krishna Mohan (1):
libfcoe: Fix Conflicting FCFs issue in the fabric
Mark Rustad (1):
libfc: Correct check for initiator role
Neil Horman (2):
MAINTAINERS: Fix fcoe mailing list
libfc: extend ex_lock to protect all of fc_seq_send
Robert Love (1):
fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs
gurinder.sherg...@hp.com (1):
qla2xxx: Fix for locking issue between driver ISR and mailbox routines
wenxi...@linux.vnet.ibm.com (1):
ipr: Avoid target_destroy accessing memory after it was freed
And the diffstat:
MAINTAINERS | 2 +-
drivers/scsi/fcoe/fcoe.c | 7 +--
drivers/scsi/fcoe/fcoe_ctlr.c | 15 +--
drivers/scsi/ipr.c| 16
drivers/scsi/ipr.h| 6 +++---
drivers/scsi/libfc/fc_exch.c | 37 -
drivers/scsi/libfc/fc_rport.c | 2 +-
drivers/scsi/qla2xxx/qla_inline.h | 11 +++
drivers/scsi/qla2xxx/qla_isr.c| 27 ---
drivers/scsi/qla2xxx/qla_mbx.c| 2 --
drivers/scsi/qla2xxx/qla_mr.c | 10 ++
drivers/scsi/qla2xxx/qla_nx.c | 26 ++
12 files changed, 66 insertions(+), 95 deletions(-)
Full diff is below
James
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 5be702c..ad7e322 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3220,7 +3220,7 @@ F:lib/fault-inject.c
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
M: Robert Love
-L: de...@open-fcoe.org
+L: fcoe-de...@open-fcoe.org
W: www.Open-FCoE.org
S: Supported
F: drivers/scsi/libfc/
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 292b24f..32ae6c6 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1656,9 +1656,12 @@ static int fcoe_xmit(struct fc_lport *lport, struct
fc_frame *fp)
if (fcoe->netdev->priv_flags & IFF_802_1Q_VLAN &&
fcoe->realdev->features & NETIF_F_HW_VLAN_CTAG_TX) {
- skb->vlan_tci = VLAN_TAG_PRESENT |
- vlan_dev_vlan_id(fcoe->netdev);
+ /* must set skb->dev before calling vlan_put_tag */
skb->dev = fcoe->realdev;
+ skb = __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
+vlan_dev_vlan_id(fcoe->netdev));
+ if (!skb)
+ return -ENOMEM;
} else
skb->dev = fcoe->netdev;
diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c b/drivers/scsi/fcoe/fcoe_ctlr.c
index cd743c5..795843d 100644
--- a/drivers/scsi/fcoe/fcoe_ctlr.c
+++ b/drivers/scsi/fcoe/fcoe_ctlr.c
@@ -1548,9 +1548,6 @@ static struct fcoe_fcf *fcoe_ctlr_select(struct fcoe_ctlr
*fip)
{
struct fcoe_fcf *fcf;
struct fcoe_fcf *best = fip->sel_fcf;
- struct fcoe_fcf *first;
-
- first = list_first_entry(&fip->fcfs, struct fcoe_fcf, list);
list_for_each_entry(fcf, &fip->fcfs, list) {
LIBFCOE_FIP_DBG(fip, "consider FCF fab %16.16llx "
@@ -1568,17 +1565,15 @@ static struct fcoe_fcf *fcoe_ctlr_select(struct
fcoe_ctlr *fip)
"" : "un");
continue;
}
- if (fcf->fabric_name != first->fabric_name ||
- fcf->vfid != first->vfid ||
- fcf->fc_map != first->fc_map) {
+ if (!best || fcf->pri < best->pri || best->flogi_sent)
+ best = fcf;
+ if (fcf->fabric_name != best->fabric_name ||
+ fcf->vfid != best->vfid ||
+ fcf->fc_map != best->fc_map) {
LIBFCOE_FIP_DBG(fip, "Conflicting fabric, VFID, "
"or FC-MAP\n");
return NULL;
}
- if (fcf->flogi_sent)
- continue;
- if (!best || fcf->pri < best->pri || best->flogi_sent)
- best = fcf;
}
fip->sel_fcf = best;
if (best) {
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 82a3c1e..6c4cedb 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -8980,19 +8980,6 @@ static int ipr_alloc_mem(struct ipr_ioa_cfg *ioa_cfg)
if (!ioa_cfg->res_entries)
goto out;
- if (ioa_cfg->sis64) {
-
Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett wrote: > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote: >> The fixed virtual address scheme currently being looked at for x86_64 to >> make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit >> because the address space isn't big enough. For ARM, given that we've >> much more opportunity to work with the vendors, can we just avoid >> transitioning to a virtual address map and always just install a >> physical mapping before doing efi calls? > > We can probably get away with that now, but it does risk us ending up > with some firmware that expects to run in physical mode (boards designed > for Linux) and some firmware that expects to run in virtual mode (boards > designed for Windows). The degree of lockdown in the Windows ecosystem > at present means it's not a real problem at the moment, but if that ever > changes we're going to risk incompatibility. What is the problem trying to be avoided by not using the virtual map? Is it passing the virtual mapping data from one kernel to the next when kexecing? Or something else? g. -- 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] proc: Document that /proc//task//children really is per-thread
On Wed, Jun 26, 2013 at 02:05:01PM -0700, Andy Lutomirski wrote: > I was surprised to discover that a process can have a parent that isn't > a thread group leader. (The usual ppid interfaces hide this, but the > children list exposes it.) > > Signed-off-by: Andy Lutomirski Looks good to me, thanks! Acked-by: Cyrill Gorcunov -- 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/
regression caused by commit 8357b48549e17b3e4e402c7f977b65708922e60f
on written to .config # Reverting that patch alone on linux-next helps: $ git show commit ddbf0162837ce7ada497f9bf2143f20c73e96c20 Author: Stephen Rothwell Date: Wed Jun 26 17:57:47 2013 +1000 Add linux-next specific files for 20130626 Signed-off-by: Stephen Rothwell $ git revert 8357b48549e17b3e4e402c7f977b65708922e60f $ make -j18 O=/home/build/arm ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y CROSS_COMPILE="ccache arm-linux-" omap2plus_defconfig GEN /home/build/arm/Makefile HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ make -j18 O=/home/build/arm ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y CROSS_COMPILE="ccache arm-linux-" oldconfig GEN /home/build/arm/Makefile scripts/kconfig/conf --oldconfig Kconfig # # configuration written to .config # $ make -j18 O=/home/build/arm ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y CROSS_COMPILE="ccache arm-linux-" oldconfig GEN /home/build/arm/Makefile scripts/kconfig/conf --oldconfig Kconfig # # configuration written to .config # Here's bisection log: 8357b48549e17b3e4e402c7f977b65708922e60f is the first bad commit commit 8357b48549e17b3e4e402c7f977b65708922e60f Author: Yann E. MORIN Date: Tue Jun 18 19:35:29 2013 +0200 kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG Currently, randconfig does randomise choice entries, unless KCONFIG_ALLCONFIG is specified. For example, given those two files (Thomas' test-case): ---8<--- Config.test.in config OPTIONA bool "Option A" choice prompt "This is a choice" config CHOICE_OPTIONA bool "Choice Option A" config CHOICE_OPTIONB bool "Choice Option B" endchoice config OPTIONB bool "Option B" ---8<--- Config.test.in ---8<--- config.defaults CONFIG_OPTIONA=y ---8<--- config.defaults And running: ./scripts/kconfig/conf --randconfig Config.test.in does properly randomise the two choice symbols (and the two booleans). However, running: KCONFIG_ALLCONFIG=config.defaults \ ./scripts/kconfig/conf --randconfig Config.test.in does *not* reandomise the two choice entries, and only CHOICE_OPTIONA will ever be selected. (OPTIONA will always be set (expected), and OPTIONB will be be properly randomised (expected).) This patch defers setting that a choice has a value until a symbol for that choice is indeed set, so that choices are properly randomised when KCONFIG_ALLCONFIG is set, but not if a symbol for that choice is set. Reported-by: Thomas Petazzoni Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Michal Marek Cc: Sam Ravnborg Cc: Sedat Dilek Cc: Arnd Bergmann Cc: Stephen Rothwell --- Changes v3 -> v4 - fix previous issue where some choices would not be set, which would cause silentoldconfig to ask for them and was then breaking this workflow (as reported by Arnd and Sedat): KCONFIG_ALLCONFIG=foo.defconfig make randconfig make silentoldconfig /dev/null 2>&1 make silentoldconfig /dev/null 2>&1 || break done which did not break at all. - change done in v3 (below) is already fixed by a previous patch Changes v2 -> v3 - ensure only one symbol is set in a choice Changes v1 -> v2: - further postpone setting that a choice has a value until one is indeed set - do not print symbols that are part of an invisible choice :04 04 cf18e4740ade73c191d8905f35b2c97abdf4bfcf be417fef0c309c2301b671ca8c19ca5b27ce8486 M scripts $ git bisect log git bisect start # good: [9e895ace5d82df8929b16f58e9f515f6d54ab82d] Linux 3.10-rc7 git bisect good 9e895ace5d82df8929b16f58e9f515f6d54ab82d # bad: [ddbf0162837ce7ada497f9bf2143f20c73e96c20] Add linux-next specific files for 20130626 git bisect bad ddbf0162837ce7ada497f9bf2143f20c73e96c20 # bad: [68f1af44fb82f16925e50ef4f15998c9933759a2] Merge remote-tracking branch 'md/for-next' git bisect bad 68f1af44fb82f16925e50ef4f15998c9933759a2 # bad: [dcef7c4c971c7f299f097cc78776b4845a7f5bb2] Merge remote-tracking branch 'slave-dma/next' git bisect bad dcef7c4c971c7f299f097cc78776b4845a7f5bb2 # good: [5fafb18bbf542079abfaf91bf405a9ede33c511a] Merge remote-tracking branch 'vfs/for-next' git bisect good 5fafb18bbf542079abfaf91bf405a9ede33c511a # good: [563709c0f179278edfa4518e9b53ae3054d1cb36] Merge remote-tracking branch 'v4l-dvb/master' git bisect good 563709c0f179278edfa4518e9b53ae3054d1cb36 # bad: [1e701aae3f0cb
Re: [PATCH 1/2] media: davinci: vpif: capture: add V4L2-async support
Hi Hans,
Thanks for the review.
On Thu, Jun 27, 2013 at 11:27 AM, Hans Verkuil wrote:
> On Tue June 25 2013 17:17:34 Prabhakar Lad wrote:
>> From: "Lad, Prabhakar"
>>
>> Add support for asynchronous subdevice probing, using the v4l2-async API.
>> The legacy synchronous mode is still supported too, which allows to
>> gradually update drivers and platforms.
>>
>> Signed-off-by: Prabhakar Lad
>> Cc: Guennadi Liakhovetski
>> Cc: Hans Verkuil
>> Cc: Laurent Pinchart
>> Cc: Sakari Ailus
>> Cc: Mauro Carvalho Chehab
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 151
>> +
>> drivers/media/platform/davinci/vpif_capture.h |2 +
>> include/media/davinci/vpif_types.h|2 +
>> 3 files changed, 107 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> b/drivers/media/platform/davinci/vpif_capture.c
>> index 5514175..b11d7a7 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -1979,6 +1979,76 @@ vpif_init_free_channel_objects:
>> return err;
>> }
>>
>> +static int vpif_async_bound(struct v4l2_async_notifier *notifier,
>> + struct v4l2_subdev *subdev,
>> + struct v4l2_async_subdev *asd)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < vpif_obj.config->subdev_count; i++)
>> + if (!strcmp(vpif_obj.config->subdev_info[i].name,
>> + subdev->name)) {
>
> Since the subdev name is now prefixed with the i2c bus identifier instead of
> just the chip name, does this code still work? Shouldn't it be 'strstr'
> instead
> of strcmp? Ditto for vpif_display and possibly others where the same
> mechanism might be used.
>
This is because the DA850-EVM has two tvp514x devices and assigning
the tvp514x device to appropriate channel is important, In this case strstr()
wont work so I used strcmp instead to match it appropriately.
Yes the code still works tested on DA850-EVM, with this patch [1].
[1]
http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/commitdiff/c906a89762541361158cf73e9494fa2f1ff8ba02
Regards,
--Prabhakar Lad
--
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] usb: dwc3: core: continue probe even if usb3 phy is not available
On Wed, Jun 26, 2013 at 03:46:45PM +0300, Alexander Shishkin wrote:
> Felipe Balbi writes:
>
> > On Wed, Jun 26, 2013 at 05:37:19PM +0530, George Cherian wrote:
> >> On 6/26/2013 3:46 PM, Felipe Balbi wrote:
> >> >Hi,
> >> >
> >> >On Wed, Jun 26, 2013 at 02:59:14PM +0530, George Cherian wrote:
> >> >>There can be configurations in which DWC3 is hoooked up only to USB2 PHY.
> >> >>In such cases we should not return -EPROBE_DEFER, rather continue probe
> >> >>even if there is no USB3 PHY.
> >> >>
> >> >>Signed-off-by: George Cherian
> >> >>---
> >> >> drivers/usb/dwc3/core.c | 31 ---
> >> >> 1 file changed, 24 insertions(+), 7 deletions(-)
> >> >>
> >> >>diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> >> >>index c35d49d..d5e6f3e 100644
> >> >>--- a/drivers/usb/dwc3/core.c
> >> >>+++ b/drivers/usb/dwc3/core.c
> >> >>@@ -100,7 +100,9 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
> >> >> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> >> >> usb_phy_init(dwc->usb2_phy);
> >> >>-usb_phy_init(dwc->usb3_phy);
> >> >>+
> >> >>+if (dwc->usb3_phy)
> >> >>+usb_phy_init(dwc->usb3_phy);
> >> >I would feel more comfortable if you would move our maximum_speed module
> >> >parameter to DT with a property such as:
> >> >
> >> >snps,maximum_speed = "highspeed";
> >> >
> >> >then on driver you could:
> >> okay
> >> >ret = of_property_read_string(np, "snps,maximum_speed", &maximum_speed);
> >> >if (ret < 0)
> >> > bailout();
> >> >
> >> >if (strncmp(maximum_speed, "superspeed", 10) == 0) {
> >> > /* grab USB3 PHY, return EPROBE_DEFER if not found */
> >> > grab_usb3_phy();
> >> >}
> >> >
> >> >if ((strncmp(maximum_speed, "highspeed", 9) == 0) ||
> >> > (strncmp(maximum_speed, "fullspeed", 9) == 0) ||
> >> > (strncmp(maximum_speed, "lowspeed", 8) == 0)) {
> >> > /* grab USB2 PHY, return EPROBE_DEFER if not found */
> >> > grab_usb2_phy();
> >> >}
> >> >
> >> >this way, we depend solely on setting maximum_speed to highspeed for
> >> >AM437x :-)
> >> In dra7xx one instance is superspeed and one instance highspeed.
> >
> > right, but in DT you will define both instances and each instance will
> > have a seaparate snps,maximum_speed attribute :-)
> >
> > I'm now considering if we should make maximum_speed a generic attribute,
> > Kishon ? Alex ? Alan ?
> >
> > anyone else needs such thing ?
>
> We have a force-full-speed attibute for chipidea on the way. This
> maximum_speed looks like a more generic alternative. Michael, what say
> you?
The maximum_speed attribute sounds more reasonable. I will change my
patch to it.
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: fcoe pull request for 3.9-rc
On Tue, 2013-06-25 at 20:55 +, Love, Robert W wrote: > The following changes since commit 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82: > >Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-06-25 > 09:08:07 -1000) > > are available in the git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git > tags/critical_fix_for_3.9 This is simple and I can review from the attached patch, so I'll take it this time. But, please, next time follow proper process. That means the individual patches should go over the SCSI mailing list for review *before* they're sent in a pull request. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH TRIVIAL] sched: Fix typo in struct sched_avg member description
Remove extra 'for' from the description about member of
struct sched_avg.
Signed-off-by: Kamalesh Babulal
---
include/linux/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..a9a0ae5 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -924,7 +924,7 @@ struct load_weight {
struct sched_avg {
/*
* These sums represent an infinite geometric series and so are bound
-* above by 1024/(1-y). Thus we only need a u32 to store them for for
all
+* above by 1024/(1-y). Thus we only need a u32 to store them for all
* choices of y < 1-2^(-32)*1024.
*/
u32 runnable_avg_sum, runnable_avg_period;
--
1.7.11.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 2/8] clocksource: sun4i: Add clocksource and sched clock drivers
Hi Maxime,
On Wed, Jun 26, 2013 at 11:16:55PM +0200, Maxime Ripard wrote:
> The A10 and the A13 has a 64 bits free running counter that we can use
> as a clocksource and a sched clock, that were both not used yet on these
> platforms.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/clocksource/sun4i_timer.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/clocksource/sun4i_timer.c
> b/drivers/clocksource/sun4i_timer.c
> index bdf34d9..1d2eaa0 100644
> --- a/drivers/clocksource/sun4i_timer.c
> +++ b/drivers/clocksource/sun4i_timer.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include
In the tip.git tree (and -next) this header is moved to
in 38ff87f77a (sched_clock: Make ARM's sched_clock generic for all
architectures).
> +
> #define TIMER_IRQ_EN_REG 0x00
> #define TIMER_IRQ_EN(val)BIT(val)
> #define TIMER_IRQ_ST_REG 0x04
> @@ -34,6 +36,11 @@
> #define TIMER_CNTVAL_REG(val)(0x10 * val + 0x18)
>
> #define TIMER_SCAL 16
> +#define TIMER_CNT64_CTL_REG 0xa0
> +#define TIMER_CNT64_CTL_CLR BIT(0)
> +#define TIMER_CNT64_CTL_RL BIT(1)
> +#define TIMER_CNT64_LOW_REG 0xa4
> +#define TIMER_CNT64_HIGH_REG 0xa8
>
> static void __iomem *timer_base;
>
> @@ -96,6 +103,20 @@ static struct irqaction sun4i_timer_irq = {
> .dev_id = &sun4i_clockevent,
> };
>
> +static u32 sun4i_timer_sched_read(void)
You commit message mentions "64 bits free running counter", but this one only
returns 32 bit.
baruch
> +{
> + u32 reg = readl(timer_base + TIMER_CNT64_CTL_REG);
> + writel(reg | TIMER_CNT64_CTL_RL, timer_base + TIMER_CNT64_CTL_REG);
> + while (readl(timer_base + TIMER_CNT64_CTL_REG) & TIMER_CNT64_CTL_REG);
> +
> + return readl(timer_base + TIMER_CNT64_LOW_REG);
> +}
> +
> +static cycle_t sun4i_timer_clksrc_read(struct clocksource *c)
> +{
> + return sun4i_timer_sched_read();
> +}
> +
> static void __init sun4i_timer_init(struct device_node *node)
> {
> unsigned long rate = 0;
> @@ -117,6 +138,12 @@ static void __init sun4i_timer_init(struct device_node
> *node)
>
> rate = clk_get_rate(clk);
>
> + writel(TIMER_CNT64_CTL_CLR, timer_base + TIMER_CNT64_CTL_REG);
> + setup_sched_clock(sun4i_timer_sched_read, 32, clk_get_rate(clk));
> + clocksource_mmio_init(timer_base + TIMER_CNT64_LOW_REG, node->name,
> + clk_get_rate(clk), 300, 32,
> + sun4i_timer_clksrc_read);
> +
> writel(rate / (TIMER_SCAL * HZ),
> timer_base + TIMER_INTVAL_REG(0));
>
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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] media: davinci: vpif: capture: add V4L2-async support
On Tue June 25 2013 17:17:34 Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> Add support for asynchronous subdevice probing, using the v4l2-async API.
> The legacy synchronous mode is still supported too, which allows to
> gradually update drivers and platforms.
>
> Signed-off-by: Prabhakar Lad
> Cc: Guennadi Liakhovetski
> Cc: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> ---
> drivers/media/platform/davinci/vpif_capture.c | 151
> +
> drivers/media/platform/davinci/vpif_capture.h |2 +
> include/media/davinci/vpif_types.h|2 +
> 3 files changed, 107 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c
> index 5514175..b11d7a7 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -1979,6 +1979,76 @@ vpif_init_free_channel_objects:
> return err;
> }
>
> +static int vpif_async_bound(struct v4l2_async_notifier *notifier,
> + struct v4l2_subdev *subdev,
> + struct v4l2_async_subdev *asd)
> +{
> + int i;
> +
> + for (i = 0; i < vpif_obj.config->subdev_count; i++)
> + if (!strcmp(vpif_obj.config->subdev_info[i].name,
> + subdev->name)) {
Since the subdev name is now prefixed with the i2c bus identifier instead of
just the chip name, does this code still work? Shouldn't it be 'strstr' instead
of strcmp? Ditto for vpif_display and possibly others where the same
mechanism might be used.
Regards,
Hans
> + vpif_obj.sd[i] = subdev;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int vpif_probe_complete(void)
> +{
> + struct common_obj *common;
> + struct channel_obj *ch;
> + int i, j, err, k;
> +
> + for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
> + ch = vpif_obj.dev[j];
> + ch->channel_id = j;
> + common = &(ch->common[VPIF_VIDEO_INDEX]);
> + spin_lock_init(&common->irqlock);
> + mutex_init(&common->lock);
> + ch->video_dev->lock = &common->lock;
> + /* Initialize prio member of channel object */
> + v4l2_prio_init(&ch->prio);
> + video_set_drvdata(ch->video_dev, ch);
> +
> + /* select input 0 */
> + err = vpif_set_input(vpif_obj.config, ch, 0);
> + if (err)
> + goto probe_out;
> +
> + err = video_register_device(ch->video_dev,
> + VFL_TYPE_GRABBER, (j ? 1 : 0));
> + if (err)
> + goto probe_out;
> + }
> +
> + v4l2_info(&vpif_obj.v4l2_dev, "VPIF capture driver initialized\n");
> + return 0;
> +
> +probe_out:
> + for (k = 0; k < j; k++) {
> + /* Get the pointer to the channel object */
> + ch = vpif_obj.dev[k];
> + /* Unregister video device */
> + video_unregister_device(ch->video_dev);
> + }
> + kfree(vpif_obj.sd);
> + for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> + ch = vpif_obj.dev[i];
> + /* Note: does nothing if ch->video_dev == NULL */
> + video_device_release(ch->video_dev);
> + }
> + v4l2_device_unregister(&vpif_obj.v4l2_dev);
> +
> + return err;
> +}
> +
> +static int vpif_async_complete(struct v4l2_async_notifier *notifier)
> +{
> + return vpif_probe_complete();
> +}
> +
> /**
> * vpif_probe : This function probes the vpif capture driver
> * @pdev: platform device pointer
> @@ -1989,12 +2059,10 @@ vpif_init_free_channel_objects:
> static __init int vpif_probe(struct platform_device *pdev)
> {
> struct vpif_subdev_info *subdevdata;
> - struct vpif_capture_config *config;
> - int i, j, k, err;
> + int i, j, err;
> int res_idx = 0;
> struct i2c_adapter *i2c_adap;
> struct channel_obj *ch;
> - struct common_obj *common;
> struct video_device *vfd;
> struct resource *res;
> int subdev_count;
> @@ -2068,10 +2136,9 @@ static __init int vpif_probe(struct platform_device
> *pdev)
> }
> }
>
> - i2c_adap = i2c_get_adapter(1);
> - config = pdev->dev.platform_data;
> + vpif_obj.config = pdev->dev.platform_data;
>
> - subdev_count = config->subdev_count;
> + subdev_count = vpif_obj.config->subdev_count;
> vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
> GFP_KERNEL);
> if (vpif_obj.sd == NULL) {
> @@ -2080,54 +2147,42 @@ static __init int vpif_probe(struct platform_device
> *pdev)
> goto vpif_sd_error;
> }
>
> - for (i = 0; i < subdev_count; i++) {
> - subdevdata = &config->subdev_info[i];
>
[PATCH TRIVIAL] sched/fair: Fix typo describing flags in enqueue_entity
Fix spelling of 'calling' in description of se flags in enqueue_entity().
Signed-off-by: Kamalesh Babulal
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c0ac2c3..04517bb 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1730,7 +1730,7 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity
*se, int flags)
{
/*
* Update the normalized vruntime before updating min_vruntime
-* through callig update_curr().
+* through calling update_curr().
*/
if (!(flags & ENQUEUE_WAKEUP) || (flags & ENQUEUE_WAKING))
se->vruntime += cfs_rq->min_vruntime;
--
1.7.11.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] Optimize wait_sb_inodes()
Hi Dave, On Wed, Jun 26, 2013 at 9:47 PM, Dave Chinner wrote: > You have your own wait code, that doesn't make what the VFS does > unnecesary. Quite frankly, I don't trust individual filesystems to > get it right - there's a long history of filesystem specific data > sync problems (including in XFS), and the best way to avoid that is > to ensure the VFS gets it right for you. I agree that some of the methods Tux3 uses to implement data integrity, sync and friends may be worth lifting up to core, or better, to a library, but we will all be better served if such methods are given time to mature first. After all, that basically describes the entire evolution of the VFS: new concepts start in a filesystem, prove themselves useful, then may be lifted up to be shared. It is important to get the order right: prove first, then lift. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] perf, persistent: Kernel updates for perf tool integration
Hi Robert, On Wed, 26 Jun 2013 14:44:24 +0200, Robert Richter wrote: > On 26.06.13 13:45:38, Ingo Molnar wrote: >> [ How about to additional logic: attr.persistent=1 && attr.config==0 means >> a new persistent event is created straight away - no ioctl is needed to >> detach it explicitly. ] > > That's correct. We could also do the following: > > To connect to an existing event: > > attr.type= && attr.config== > > (This might be harder to implement except the persistent event pmu > type will be fix, PERF_TYPE_PERSISTENT=6.) > > To create a new persistent event: > > attr.persistent=1 && attr= How about using 2 bits for perfsistent flag, 1 for connecting to an existing one, 2 for creating new one. >> > * The persistent event is opened with the syscall, the process gets a >> >new fd of the event. >> > * The process attaches to the event buffer with mmap. >> >> Yes. And gets the pre-existing event and mmap buffer. > > That's what I mean. > > A problem here is that mmap'ed buffer size (number of pages) must be > be equal to the pre-existing buffer size and thus to be known somehow. What about also exporting the buffer size via sysfs pmu directory? Thanks, Namhyung -- 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: cgroup: status-quo and userland efforts
On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote: > Hello, Tim. > > On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote: > > I really want to understand why this is SO IMPORTANT that you have to > > break userspace compatibility? I mean, isn't Linux supposed to be the > > OS with the stable kernel interface? I've seen Linus rant time and > > time again about this - why is it OK now? > > What the hell are you talking about? Nobody is breaking userland > interface. A new version of interface is being phased in and the old > one will stay there for the foreseeable future. It will be phased out > eventually but that's gonna take a long time and it will have to be > something hardly noticeable. Of course new features will only be > available with the new interface and there will be efforts to nudge > people away from the old one but the existing interface will keep > working it does. I can understand some alarm. When I saw the below I started frothing at the face and howling at the moon, and I don't even use the things much. http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html Hierarchy layout aside, that "private property" bit says that the folks who currently own and use the cgroups interface will lose direct access to it. I can imagine folks who have become dependent upon an on the fly management agents of their own design becoming a tad alarmed. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc_thread
2013/6/27, Jaegeuk Kim : > Hi, > > 2013-06-26 (수), 14:10 +0900, Namjae Jeon: >> 2013/6/25, Jaegeuk Kim : >> >> > - any priority scheme for cleaning? >> >> Could you plz tell me a little more detail ? >> > >> > I meant, as well as the GC times, user also gives a kind of status >> > like: >> > LONG_IDLE, SHORT_IDLE, something like that. >> > Therefore, how about using this information to select a victim >> > selection >> > policy between cost-benefit and greedy algorithms? >> currently we will provide the option of updating the time values from >> the ‘sysfs’ interface, and the GC policy is selected by default from >> GC thread based upon the gc type, BG or FG. >> So, do you mean we should provide an option to select the default GC >> policy for the user using ‘sysfs’ interface? Like, if the user sets >> “LONG_IDLE” – we choose Cost Benefit and in case of SHORT_IDLE >> “Greedy” ? Please elaborate more on this. > > Yes, exact. > For example, if an user configures a small period of GC interval but > gives LONG_IDLE, we can choose cost-benefit. > But, if SHORT_IDLE is given with a long GC period, we need to choose > greedy. > How do you think? Hi. Jaegeuk. Looks reasonable to me. I will provide a policy attribute for f2fs sysfs with values, LONG_IDLE and SHORT_IDLE with gc time. Thanks :) > Thanks, > > -- > Jaegeuk Kim > Samsung > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic in skb_copy_bits
On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote: > Hi, > > When we do fail over test with iscsi + multipath by reset the switches > on OVM(2.6.39) we hit the panic: > > BUG: unable to handle kernel paging request at 88006d9e8d48 > IP: [] memcpy+0xb/0x120 > PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0 > Oops: [#1] SMP > CPU 7 > Modules linked in: dm_nfs tun nfs fscache auth_rpcgss nfs_acl xen_blkback > xen_netback xen_gntdev xen_evtchn lockd sunrpc bridge stp llc bonding > be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core > ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 mdio > dm_round_robin dm_multipath libiscsi_tcp libiscsi scsi_transport_iscsi xenfs > xen_privcmd video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler > parport_pc lp parport ixgbe dca sr_mod cdrom bnx2 radeon ttm drm_kms_helper > drm snd_seq_dummy i2c_algo_bit i2c_core snd_seq_oss snd_seq_midi_event > snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss serio_raw snd_pcm snd_timer > snd soundcore snd_page_alloc iTCO_wdt pcspkr iTCO_vendor_support pata_acpi > dcdbas i5k_amb ata_generic hwmon floppy ghes i5000_edac edac_core hed > dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage lpfc > scsi_transport_fc scsi_tgt ata_piix sg shpchp mptsas mptscsih mptbase > scsi_transport_sas sd_mod crc_t10dif ext3 j! > bd mbcache > > > Pid: 0, comm: swapper Tainted: GW 2.6.39-300.32.1.el5uek #1 Dell > Inc. PowerEdge 2950/0DP246 > RIP: e030:[] [] memcpy+0xb/0x120 > RSP: e02b:8801003c3d58 EFLAGS: 00010246 > RAX: 880076b9e280 RBX: 8800714d2c00 RCX: 0057 > RDX: RSI: 88006d9e8d48 RDI: 880076b9e280 > RBP: 8801003c3dc0 R08: 000bf723 R09: > R10: R11: 000a R12: 0034 > R13: 0034 R14: 02b8 R15: 05a8 > FS: 7fc1e852a6e0() GS:8801003c() knlGS: > CS: e033 DS: 002b ES: 002b CR0: 8005003b > CR2: 88006d9e8d48 CR3: 6370b000 CR4: 2660 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process swapper (pid: 0, threadinfo 880077ac, task 880077abe240) > Stack: > 8142db21 880076b9e280 8800637097f0 > 02ec 02b8 880077ac > 8800637097f0 880066c9a7c0 fdb4 024c > Call Trace: > > [] ? skb_copy_bits+0x1c1/0x2e0 > [] skb_copy+0xf3/0x120 > [] neigh_timer_handler+0x1ac/0x350 > [] ? account_idle_ticks+0xe/0x10 > [] ? neigh_alloc+0x180/0x180 > [] call_timer_fn+0x4a/0x110 > [] ? neigh_alloc+0x180/0x180 > [] run_timer_softirq+0x13a/0x220 > [] __do_softirq+0xb9/0x1d0 > [] ? handle_percpu_irq+0x48/0x70 > [] call_softirq+0x1c/0x30 > [] do_softirq+0x65/0xa0 > [] irq_exit+0xab/0xc0 > [] xen_evtchn_do_upcall+0x35/0x50 > [] xen_do_hypervisor_callback+0x1e/0x30 > > [] ? xen_hypercall_sched_op+0xa/0x20 > [] ? xen_hypercall_sched_op+0xa/0x20 > [] ? xen_safe_halt+0x10/0x20 > [] ? default_idle+0x5b/0x170 > [] ? cpu_idle+0xc6/0xf0 > [] ? xen_irq_enable_direct_reloc+0x4/0x4 > [] ? cpu_bringup_and_idle+0xe/0x10 > Code: 01 c6 43 4c 04 19 c0 4c 8b 65 f0 4c 8b 6d f8 83 e0 fc 83 c0 08 88 43 4d > 48 8b 5d e8 c9 c3 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 48 a5 89 d1 f3 > a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c > RIP [] memcpy+0xb/0x120 > RSP > CR2: 88006d9e8d48 > > Reviewed vmcore I found the skb->users is 1 at the moment, checked network > neighbour > history I found skb_get() be replaced by skb_copy by commit 7e36763b2c: > > commit 7e36763b2c204d59de4e88087f84a2c0c8421f25 > Author: Frank Blaschka > Date: Mon Mar 3 12:16:04 2008 -0800 > > [NET]: Fix race in generic address resolution. > > neigh_update sends skb from neigh->arp_queue while neigh_timer_handler > has increased skbs refcount and calls solicit with the > skb. neigh_timer_handler should not increase skbs refcount but make a > copy of the skb and do solicit with the copy. > > Signed-off-by: Frank Blaschka > Signed-off-by: David S. Miller > > So can you please give some details of the race? per vmcore seems like the > skb data > be freed, I suspected skb_get() lost at somewhere? > I reverted above commit the panic not occurred during our testing. > > Any input will appreciate! Well, fact is that your crash is happening in skb_copy(). Frank patch is OK. I suspect using skb_clone() would work too, so if these skb were fclone ready, chance of an GFP_ATOMIC allocation error would be smaller. So something is providing a wrong skb at the very beginning.
Re: perf tools: Introduce new -P/--parent-deep report option
Hi Arnaldo, On Wed, 26 Jun 2013 11:58:53 -0300, Arnaldo Carvalho de Melo wrote: > Hi Jiri, > > About the patch below, can't this be solved by using a regex > instead of a simple substring search instead of adding a new command > line option? ??? IIUC he reused parent_regex for this. And I think we can have the same effect by using -G and -p option together without this new option. Thanks, Namhyung > > - Arnaldo > > commit 5b42ff035ec784c5c42c4a6bb9e7fada882f097e > Author: Jiri Olsa > Date: Tue Jun 18 18:31:50 2013 +0200 > > perf tools: Introduce new -P/--parent-deep report option > > Introducing new -P/--parent-deep report option. It does the > same as '-p' but it force the deep search of the callchain > and looks for the deepest possible match. > > The -p option searches for the first match of the parent > pattern in the callchain. > > $ perf report -i perf.data.delete -p perf_session__delete -s parent > > + 99.51% [other] > + 0.46% perf_session__delete_dead_threads > + 0.03% perf_session__delete > + 0.00% perf_session__delete_threads > > so we got multiple 'different' matches instancies, while > they all belong under perf_session__delete function: > > $ perf report -i perf.data.delete -P perf_session__delete -s parent > > + 99.51% [other] > + 0.49% perf_session__delete > > NOTE the 'p' vs 'P' difference in above commands above. -- 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 06/19] perf ftrace: Add support for --pid option
On Wed, 26 Jun 2013 11:12:19 -0600, David Ahern wrote:
> On 6/26/13 1:14 AM, Namhyung Kim wrote:
>> @@ -196,6 +222,8 @@ int cmd_ftrace(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>> const struct option ftrace_options[] = {
>> OPT_STRING('t', "tracer", &ftrace.tracer, "tracer",
>> "tracer to use"),
>> +OPT_STRING('p', "pid", &ftrace.target.tid, "pid",
>> + "trace on existing process id"),
>> OPT_INCR('v', "verbose", &verbose,
>> "be more verbose"),
>> OPT_END()
>
> You are calling it pid but assigning it as a tid which is inconsistent
> with other perf commands. e.g., perf-record allows a list of pids (-p)
> or tids (-t). Why not support that in perf-ftrace? And that leads to
> the comment about consistency of options across perf commands: -t is
> used here for tracer type to use.
Sorry, I should've mentioned it.
The pid filtering in ftrace is done via set_ftrace_pid file under the
tracing debugfs directory. IIRC It only supports process filtering not
thread filtering by iterating all threads in the kernel code. So --tid
option cannot be implemented as other perf commands.
So I chose not to and assigned -t option to --tracer.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc_thread
Hi, 2013-06-26 (수), 14:10 +0900, Namjae Jeon: > 2013/6/25, Jaegeuk Kim : > >> > - any priority scheme for cleaning? > >> Could you plz tell me a little more detail ? > > > > I meant, as well as the GC times, user also gives a kind of status like: > > LONG_IDLE, SHORT_IDLE, something like that. > > Therefore, how about using this information to select a victim selection > > policy between cost-benefit and greedy algorithms? > currently we will provide the option of updating the time values from > the ‘sysfs’ interface, and the GC policy is selected by default from > GC thread based upon the gc type, BG or FG. > So, do you mean we should provide an option to select the default GC > policy for the user using ‘sysfs’ interface? Like, if the user sets > “LONG_IDLE” – we choose Cost Benefit and in case of SHORT_IDLE > “Greedy” ? Please elaborate more on this. Yes, exact. For example, if an user configures a small period of GC interval but gives LONG_IDLE, we can choose cost-benefit. But, if SHORT_IDLE is given with a long GC period, we need to choose greedy. How do you think? Thanks, -- Jaegeuk Kim Samsung -- 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] Optimize wait_sb_inodes()
Dave Chinner writes: >> Optimizing wait_sb_inodes() might help lock contention, but it doesn't >> help unnecessary wait/check. > > You have your own wait code, that doesn't make what the VFS does > unnecesary. Quite frankly, I don't trust individual filesystems to > get it right - there's a long history of filesystem specific data > sync problems (including in XFS), and the best way to avoid that is > to ensure the VFS gets it right for you. > > Indeed, we've gone from having sooper special secret sauce data sync > code in XFS to using the VFS over the past few years, and the result > is that it is now more reliable and faster than when we were trying > to be smart and do it all ourselves. We got to where we are by > fixing the problems in the VFS rather than continuing to try to work > around them. I guess you are assuming FS which is using data=writeback or such. >> Since some FSes know about current >> in-flight I/O already in those internal, so I think, those FSes can be >> done it here, or are already doing in ->sync_fs(). > > Sure, do your internal checks in ->sync_fs(), but if > wait_sb_inodes() does not have any lock contention and very little > overhead, then why do you need to avoid it? This wait has to be done > somewhere between sync_inodes_sb() dispatching all the IO and > ->sync_fs completing, so what's the problem with hving the VFS do > that *for everyone* efficiently? Are you saying the vfs should track all in-flight I/O with some sort of transactional way? Otherwise, vfs can't know the data is whether after sync point or before sync point, and have to wait or not. FS is using the behavior like data=journal has tracking of those already, and can reuse it. > Fix the root cause of the problem - the sub-optimal VFS code. > Hacking around it specifically for out-of-tree code is not the way > things get done around here... I'm thinking the root cause is vfs can't have knowledge of FS internal, e.g. FS is handling data transactional way, or not. Thanks. -- OGAWA Hirofumi -- 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:
Hi， dears I have found many RetransSegs of tcp by /proc/net/snmp, but I can't capture these packet on local system by tcpdump. What could be the reason? Droped by qdisc level or device driver? How to confirm that? I also find patch "[PATCH] tcp: reflect SYN queue_mapping into SYNACK packets" provided by Eirc, how to confirm this? Thanks very much! -- 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/8] KVM: PPC: reserve a capability number for multitce support
Signed-off-by: Alexey Kardashevskiy
---
include/uapi/linux/kvm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index d88c8ee..970b1f5 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -666,6 +666,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_MPIC 90
#define KVM_CAP_PPC_RTAS 91
#define KVM_CAP_IRQ_XICS 92
+#define KVM_CAP_SPAPR_MULTITCE 93
#ifdef KVM_CAP_IRQ_ROUTING
--
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 3/8] vfio: add external user support
VFIO is designed to be used via ioctls on file descriptors
returned by VFIO.
However in some situations support for an external user is required.
The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
use the existing VFIO groups for exclusive access in real/virtual mode
in the host kernel to avoid passing map/unmap requests to the user
space which would made things pretty slow.
The proposed protocol includes:
1. do normal VFIO init stuff such as opening a new container, attaching
group(s) to it, setting an IOMMU driver for a container. When IOMMU is
set for a container, all groups in it are considered ready to use by
an external user.
2. pass a fd of the group we want to accelerate to KVM. KVM calls
vfio_group_iommu_id_from_file() to verify if the group is initialized
and IOMMU is set for it. The current TCE IOMMU driver marks the whole
IOMMU table as busy when IOMMU is set for a container what this prevents
other DMA users from allocating from it so it is safe to pass the group
to the user space.
3. KVM increases the container users counter via
vfio_group_add_external_user(). This prevents the VFIO group from
being disposed prior to exiting KVM.
4. When KVM is finished and doing cleanup, it releases the group file
and decrements the container users counter. Everything gets released.
5. KVM also keeps the group file as otherwise its fd might have been
closed at the moment of KVM finish so vfio_group_del_external_user()
call will not be possible.
The "vfio: Limit group opens" patch is also required for the consistency.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index c488da5..54192b2 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1370,6 +1370,59 @@ static const struct file_operations vfio_device_fops = {
};
/**
+ * External user API, exported by symbols to be linked dynamically.
+ */
+
+/* Allows an external user (for example, KVM) to lock an IOMMU group */
+static int vfio_group_add_external_user(struct file *filep)
+{
+ struct vfio_group *group = filep->private_data;
+
+ if (filep->f_op != &vfio_group_fops)
+ return -EINVAL;
+
+ if (!atomic_inc_not_zero(&group->container_users))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_group_add_external_user);
+
+/* Allows an external user (for example, KVM) to unlock an IOMMU group */
+static void vfio_group_del_external_user(struct file *filep)
+{
+ struct vfio_group *group = filep->private_data;
+
+ BUG_ON(filep->f_op != &vfio_group_fops);
+
+ vfio_group_try_dissolve_container(group);
+}
+EXPORT_SYMBOL_GPL(vfio_group_del_external_user);
+
+/*
+ * Checks if a group for the specified file can be used by
+ * an external user and returns the IOMMU ID if external use is possible.
+ */
+static int vfio_group_iommu_id_from_file(struct file *filep)
+{
+ int ret;
+ struct vfio_group *group = filep->private_data;
+
+ if (WARN_ON(filep->f_op != &vfio_group_fops))
+ return -EINVAL;
+
+ if (0 == atomic_read(&group->container_users) ||
+ !group->container->iommu_driver ||
+ !vfio_group_viable(group))
+ return -EINVAL;
+
+ ret = iommu_group_id(group->iommu_group);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_group_iommu_id_from_file);
+
+/**
* Module/class support
*/
static char *vfio_devnode(struct device *dev, umode_t *mode)
--
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 05/19] perf tools: Introduce new 'ftrace' tool
Hi David,
On Wed, 26 Jun 2013 11:10:34 -0600, David Ahern wrote:
> On 6/26/13 1:14 AM, Namhyung Kim wrote:
>> +const char * const ftrace_usage[] = {
>> +"perf ftrace [] []",
>> +"perf ftrace [] -- []",
>> +NULL
>> +};
>> +const struct option ftrace_options[] = {
>> +OPT_STRING('t', "tracer", &ftrace.tracer, "tracer",
>> + "tracer to use"),
>
> How does a user know what is a valid tracer string?
The helpline should look like (at least):
"tracer to use: function_graph or function"
I'll update it in the next spin.
Thanks,
Namhyung
--
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 8/8] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
This adds special support for huge pages (16MB). The reference
counting cannot be easily done for such pages in real mode (when
MMU is off) so we added a list of huge pages. It is populated in
virtual mode and get_page is called just once per a huge page.
Real mode handlers check if the requested page is huge and in the list,
then no reference counting is done, otherwise an exit to virtual mode
happens. The list is released at KVM exit. At the moment the fastest
card available for tests uses up to 9 huge pages so walking through this
list is not very expensive. However this can change and we may want
to optimize this.
Signed-off-by: Paul Mackerras
Signed-off-by: Alexey Kardashevskiy
---
Changes:
2013/06/27:
* list of huge pages replaces with hashtable for better performance
* spinlock removed from real mode and only protects insertion of new
huge [ages descriptors into the hashtable
2013/06/05:
* fixed compile error when CONFIG_IOMMU_API=n
2013/05/20:
* the real mode handler now searches for a huge page by gpa (used to be pte)
* the virtual mode handler prints warning if it is called twice for the same
huge page as the real mode handler is expected to fail just once - when a huge
page is not in the list yet.
* the huge page is refcounted twice - when added to the hugepage list and
when used in the virtual mode hcall handler (can be optimized but it will
make the patch less nice).
---
arch/powerpc/include/asm/kvm_host.h | 25 +
arch/powerpc/kvm/book3s_64_vio.c| 95 +--
arch/powerpc/kvm/book3s_64_vio_hv.c | 24 +++--
3 files changed, 138 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 716ab18..0ad6189 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -182,9 +183,33 @@ struct kvmppc_spapr_tce_table {
u32 window_size;
struct iommu_group *grp;/* used for IOMMU groups */
struct file *vfio_filp; /* used for IOMMU groups */
+ DECLARE_HASHTABLE(hash_tab, ilog2(64)); /* used for IOMMU groups */
+ spinlock_t hugepages_write_lock;/* used for IOMMU groups */
struct page *pages[0];
};
+/*
+ * The KVM guest can be backed with 16MB pages.
+ * In this case, we cannot do page counting from the real mode
+ * as the compound pages are used - they are linked in a list
+ * with pointers as virtual addresses which are inaccessible
+ * in real mode.
+ *
+ * The code below keeps a 16MB pages list and uses page struct
+ * in real mode if it is already locked in RAM and inserted into
+ * the list or switches to the virtual mode where it can be
+ * handled in a usual manner.
+ */
+#define KVMPPC_HUGEPAGE_HASH(gpa) hash_32(gpa >> 24, 32)
+
+struct kvmppc_iommu_hugepage {
+ struct hlist_node hash_node;
+ unsigned long gpa; /* Guest physical address */
+ unsigned long hpa; /* Host physical address */
+ struct page *page; /* page struct of the very first subpage */
+ unsigned long size; /* Huge page size (always 16MB at the moment) */
+};
+
struct kvmppc_linear_info {
void*base_virt;
unsigned longbase_pfn;
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index a5d0195..6cedfe9 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -47,6 +47,78 @@
#define TCES_PER_PAGE (PAGE_SIZE / sizeof(u64))
#define ERROR_ADDR ((void *)~(unsigned long)0x0)
+#ifdef CONFIG_IOMMU_API
+/* Adds a new huge page descriptor to the hashtable */
+static long kvmppc_iommu_hugepage_try_add(
+ struct kvmppc_spapr_tce_table *tt,
+ pte_t pte, unsigned long hva, unsigned long gpa,
+ unsigned long pg_size)
+{
+ long ret = 0;
+ struct kvmppc_iommu_hugepage *hp;
+ struct page *pg;
+ unsigned key = KVMPPC_HUGEPAGE_HASH(gpa);
+
+ spin_lock(&tt->hugepages_write_lock);
+ hash_for_each_possible_rcu(tt->hash_tab, hp, hash_node, key) {
+ if (KVMPPC_HUGEPAGE_HASH(hp->gpa) != key)
+ continue;
+ if ((gpa < hp->gpa) || (gpa >= hp->gpa + hp->size))
+ continue;
+ goto unlock_exit;
+ }
+
+ hva = hva & ~(pg_size - 1);
+ ret = get_user_pages_fast(hva, 1, true/*write*/, &pg);
+ if ((ret != 1) || !pg) {
+ ret = -EFAULT;
+ goto unlock_exit;
+ }
+ ret = 0;
+
+ hp = kzalloc(sizeof(*hp), GFP_KERNEL);
+ if (!hp) {
+ ret = -ENOMEM;
+ goto unlock_exit;
+ }
+
+ hp->page = pg;
+ hp->gpa = gpa & ~(pg_size - 1);
+ hp->hpa = (pte_pfn(pte) << PAGE_SHIFT);
+ hp->size = pg_size;
+
+
[PATCH 5/8] powerpc: Prepare to support kernel handling of IOMMU map/unmap
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where each packet needs to be mapped/unmapped) we chose
to implement that as a "fast" hypercall directly in "real
mode" (processor still in the guest context but MMU off).
To be able to do that, we need to provide some facilities to
access the struct page count within that real mode environment as things
like the sparsemem vmemmap mappings aren't accessible.
This adds an API to increment/decrement page counter as
get_user_pages API used for user mode mapping does not work
in the real mode.
CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.
Reviewed-by: Paul Mackerras
Cc: David Gibson
Signed-off-by: Paul Mackerras
Signed-off-by: Alexey Kardashevskiy
---
Changes:
2013/06/27:
* realmode_get_page() fixed to use get_page_unless_zero(). If failed,
the call will be passed from real to virtual mode and safely handled.
* added comment to PageCompound() in include/linux/page-flags.h.
2013/05/20:
* PageTail() is replaced by PageCompound() in order to have the same checks
for whether the page is huge in realmode_get_page() and realmode_put_page()
---
arch/powerpc/include/asm/pgtable-ppc64.h |4 ++
arch/powerpc/mm/init_64.c| 78 +-
include/linux/page-flags.h |4 +-
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index e3d55f6f..7b46e5f 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -376,6 +376,10 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t
*pgdir, unsigned long ea,
}
#endif /* !CONFIG_HUGETLB_PAGE */
+struct page *realmode_pfn_to_page(unsigned long pfn);
+int realmode_get_page(struct page *page);
+int realmode_put_page(struct page *page);
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index a90b9c4..7031be3 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -297,5 +297,81 @@ void vmemmap_free(unsigned long start, unsigned long end)
{
}
-#endif /* CONFIG_SPARSEMEM_VMEMMAP */
+/*
+ * We do not have access to the sparsemem vmemmap, so we fallback to
+ * walking the list of sparsemem blocks which we already maintain for
+ * the sake of crashdump. In the long run, we might want to maintain
+ * a tree if performance of that linear walk becomes a problem.
+ *
+ * Any of realmode_ functions can fail due to:
+ * 1) As real sparsemem blocks do not lay in RAM continously (they
+ * are in virtual address space which is not available in the real mode),
+ * the requested page struct can be split between blocks so get_page/put_page
+ * may fail.
+ * 2) When huge pages are used, the get_page/put_page API will fail
+ * in real mode as the linked addresses in the page struct are virtual
+ * too.
+ * When 1) or 2) takes place, the API returns an error code to cause
+ * an exit to kernel virtual mode where the operation will be completed.
+ */
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+ struct vmemmap_backing *vmem_back;
+ struct page *page;
+ unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
+ unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
+
+ for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back->list) {
+ if (pg_va < vmem_back->virt_addr)
+ continue;
+ /* Check that page struct is not split between real pages */
+ if ((pg_va + sizeof(struct page)) >
+ (vmem_back->virt_addr + page_size))
+ return NULL;
+
+ page = (struct page *) (vmem_back->phys + pg_va -
+ vmem_back->virt_addr);
+ return page;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
+
+#elif defined(CONFIG_FLATMEM)
+
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+ struct page *page = pfn_to_page(pfn);
+ return page;
+}
+EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
+
+#endif /* CONFIG_SPARSEMEM_VMEMMAP/CONFIG_FLATMEM */
+
+#if defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_FLATMEM)
+int realmode_get_page(struct page *page)
+{
+ if (PageCompound(page))
+ return -EAGAIN;
+
+ if (!get_page_unless_zero(page))
+ return -EAGAIN;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(realmode_get_page);
+
+int realmode_put_page(struct page *page)
+{
+ if (PageCompound(page))
+ return -EAGAIN;
+
+ if (!atomic_add_unless(&page->_count, -1, 1))
+
[PATCH 7/8] KVM: PPC: Add support for IOMMU in-kernel handling
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests without passing them to QEMU, which saves time
on switching to QEMU and back.
Both real and virtual modes are supported. First the kernel tries to
handle a TCE request in the real mode, if failed it passes it to
the virtual mode to complete the operation. If it a virtual mode
handler fails, a request is passed to the user mode.
This adds a new KVM_CAP_SPAPR_TCE_IOMMU ioctl to associate
a virtual PCI bus ID (LIOBN) with an IOMMU group which enables
in-kernel handling of IOMMU map/unmap. The external user API support
in VFIO is required.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras
Signed-off-by: Alexey Kardashevskiy
---
Changes:
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
on a page
* The only reason to pass the request to user mode now is when the user mode
did not register TCE table in the kernel, in all other cases the virtual mode
handler is expected to do the job
---
Documentation/virtual/kvm/api.txt | 26
arch/powerpc/include/asm/kvm_host.h |4 +
arch/powerpc/include/asm/kvm_ppc.h |2 +
arch/powerpc/include/uapi/asm/kvm.h |8 +
arch/powerpc/kvm/book3s_64_vio.c| 294 ++-
arch/powerpc/kvm/book3s_64_vio_hv.c | 165
arch/powerpc/kvm/powerpc.c | 12 ++
7 files changed, 509 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 762c703..01b0dc2 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2387,6 +2387,32 @@ slows operations a lot.
Unlike other capabilities of this section, this one is always enabled.
+4.87 KVM_CREATE_SPAPR_TCE_IOMMU
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_create_spapr_tce_iommu (in)
+Returns: 0 on success, -1 on error
+
+struct kvm_create_spapr_tce_iommu {
+ __u64 liobn;
+ __u32 iommu_id;
+ __u32 flags;
+};
+
+This creates a link between IOMMU group and a hardware TCE (translation
+control entry) table. This link lets the host kernel know what IOMMU
+group (i.e. TCE table) to use for the LIOBN number passed with
+H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE hypercalls.
+
+In response to a TCE hypercall, the kernel looks for a TCE table descriptor
+in the list and handles the hypercall in real or virtual modes if
+the descriptor is found. Otherwise the hypercall is passed to the user mode.
+
+No flag is supported at the moment.
+
+
5. The kvm_run structure
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 3bf407b..716ab18 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -180,6 +180,8 @@ struct kvmppc_spapr_tce_table {
struct kvm *kvm;
u64 liobn;
u32 window_size;
+ struct iommu_group *grp;/* used for IOMMU groups */
+ struct file *vfio_filp; /* used for IOMMU groups */
struct page *pages[0];
};
@@ -611,6 +613,8 @@ struct kvm_vcpu_arch {
u64 busy_preempt;
unsigned long *tce_tmp;/* TCE cache for TCE_PUT_INDIRECT hcall */
+ unsigned long tce_tmp_num; /* Number of handled TCEs in the cache */
+ unsigned long tce_reason; /* The reason of switching to the virtmode */
#endif
};
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index e852921b..934e01d 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -133,6 +133,8 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
+extern long kvm_vm_ioctl_create_spapr_tce_iommu(struct kvm *kvm,
+ struct kvm_create_spapr_tce_iommu *args);
extern struct kvmppc_spapr_tce_table *kvmppc_find_tce_table(
struct kvm_vcpu *vcpu, unsigned long liobn);
extern long kvmppc_emulated_validate_tce(unsigned long tce);
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
ind
[PATCH 4/8] hashtable: add hash_for_each_possible_rcu_notrace()
This adds hash_for_each_possible_rcu_notrace() which is basically a notrace clone of hash_for_each_possible_rcu() which cannot be used in real mode due to its tracing/debugging capability. Signed-off-by: Alexey Kardashevskiy --- include/linux/hashtable.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h index a9df51f..af8b169 100644 --- a/include/linux/hashtable.h +++ b/include/linux/hashtable.h @@ -174,6 +174,21 @@ static inline void hash_del_rcu(struct hlist_node *node) member) /** + * hash_for_each_possible_rcu_notrace - iterate over all possible objects hashing + * to the same bucket in an rcu enabled hashtable in a rcu enabled hashtable + * @name: hashtable to iterate + * @obj: the type * to use as a loop cursor for each entry + * @member: the name of the hlist_node within the struct + * @key: the key of the objects to iterate over + * + * This is the same as hash_for_each_possible_rcu() except that it does + * not do any RCU debugging or tracing. + */ +#define hash_for_each_possible_rcu_notrace(name, obj, member, key) \ + hlist_for_each_entry_rcu_notrace(obj, &name[hash_min(key, HASH_BITS(name))],\ + member) + +/** * hash_for_each_possible_safe - iterate over all possible objects hashing to the * same bucket safe against removals * @name: hashtable to iterate -- 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 2/8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
Signed-off-by: Alexey Kardashevskiy
---
include/uapi/linux/kvm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 970b1f5..0865c01 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_PPC_RTAS 91
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_SPAPR_MULTITCE 93
+#define KVM_CAP_SPAPR_TCE_IOMMU 94
#ifdef KVM_CAP_IRQ_ROUTING
@@ -923,6 +924,7 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_PPC_ALLOC_HTAB */
#define KVM_PPC_ALLOCATE_HTAB_IOWR(KVMIO, 0xa7, __u32)
#define KVM_CREATE_SPAPR_TCE _IOW(KVMIO, 0xa8, struct
kvm_create_spapr_tce)
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, struct
kvm_create_spapr_tce_iommu)
/* Available with KVM_CAP_RMA */
#define KVM_ALLOCATE_RMA _IOR(KVMIO, 0xa9, struct kvm_allocate_rma)
/* Available with KVM_CAP_PPC_HTAB_FD */
--
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 6/8] KVM: PPC: Add support for multiple-TCE hcalls
This adds real mode handlers for the H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO
devices or emulated PCI. These calls allow adding multiple entries
(up to 512) into the TCE table in one call which saves time on
transition to/from real mode.
This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs
(copied from user and verified) before writing the whole list into
the TCE table. This cache will be utilized more in the upcoming
VFIO/IOMMU support to continue TCE list processing in the virtual
mode in the case if the real mode handler failed for some reason.
This adds a guest physical to host real address converter
and calls the existing H_PUT_TCE handler. The converting function
is going to be fully utilized by upcoming VFIO supporting patches.
This also implements the KVM_CAP_PPC_MULTITCE capability,
so in order to support the functionality of this patch, QEMU
needs to query for this capability and set the "hcall-multi-tce"
hypertas property only if the capability is present, otherwise
there will be serious performance degradation.
Signed-off-by: Paul Mackerras
Signed-off-by: Alexey Kardashevskiy
---
Changelog:
2013/06/27:
* fixed clear of BUSY bit in kvmppc_lookup_pte()
* H_PUT_TCE_INDIRECT does realmode_get_page() now
* KVM_CAP_SPAPR_MULTITCE now depends on CONFIG_PPC_BOOK3S_64
* updated doc
2013/06/05:
* fixed mistype about IBMVIO in the commit message
* updated doc and moved it to another section
* changed capability number
2013/05/21:
* added kvm_vcpu_arch::tce_tmp
* removed cleanup if put_indirect failed, instead we do not even start
writing to TCE table if we cannot get TCEs from the user and they are
invalid
* kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce
and kvmppc_emulated_validate_tce (for the previous item)
* fixed bug with failthrough for H_IPI
* removed all get_user() from real mode handlers
* kvmppc_lookup_pte() added (instead of making lookup_linux_pte public)
---
Documentation/virtual/kvm/api.txt | 25 +++
arch/powerpc/include/asm/kvm_host.h |2 +
arch/powerpc/include/asm/kvm_ppc.h | 16 +-
arch/powerpc/kvm/book3s_64_vio.c| 123 ++
arch/powerpc/kvm/book3s_64_vio_hv.c | 270 +++
arch/powerpc/kvm/book3s_hv.c| 41 -
arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 +
arch/powerpc/kvm/book3s_pr_papr.c | 37 -
arch/powerpc/kvm/powerpc.c |3 +
9 files changed, 490 insertions(+), 33 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 6365fef..762c703 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2362,6 +2362,31 @@ calls by the guest for that service will be passed to
userspace to be
handled.
+4.86 KVM_CAP_PPC_MULTITCE
+
+Capability: KVM_CAP_PPC_MULTITCE
+Architectures: ppc
+Type: vm
+
+This capability means the kernel is capable of handling hypercalls
+H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
+space. This significanly accelerates DMA operations for PPC KVM guests.
+The user space should expect that its handlers for these hypercalls
+are not going to be called.
+
+In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
+the user space might have to advertise it for the guest. For example,
+IBM pSeries guest starts using them if "hcall-multi-tce" is present in
+the "ibm,hypertas-functions" device-tree property.
+
+Without this capability, only H_PUT_TCE is handled by the kernel and
+therefore the use of H_PUT_TCE_INDIRECT and H_STUFF_TCE is not recommended
+unless the capability is present as passing hypercalls to the userspace
+slows operations a lot.
+
+Unlike other capabilities of this section, this one is always enabled.
+
+
5. The kvm_run structure
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af326cd..3bf407b 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -609,6 +609,8 @@ struct kvm_vcpu_arch {
spinlock_t tbacct_lock;
u64 busy_stolen;
u64 busy_preempt;
+
+ unsigned long *tce_tmp;/* TCE cache for TCE_PUT_INDIRECT hcall */
#endif
};
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index a5287fe..e852921b 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -133,8 +133,20 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
-extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
-unsigned long ioba, unsigned long tce);
+extern struct kvmppc_spapr_tce_table *kvmppc_find_tce_table(
+ struct kvm_vcpu *vcpu, unsigned long liobn);
+ex
[PATCH 0/8 v4] KVM: PPC: IOMMU in-kernel handling
The changes are: 1. rebased on v3.10-rc7 2. removed spinlocks from real mode 3. added security checks between KVM and VFIO MOre details in the individual patch comments. Alexey Kardashevskiy (8): KVM: PPC: reserve a capability number for multitce support KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO vfio: add external user support hashtable: add hash_for_each_possible_rcu_notrace() powerpc: Prepare to support kernel handling of IOMMU map/unmap KVM: PPC: Add support for multiple-TCE hcalls KVM: PPC: Add support for IOMMU in-kernel handling KVM: PPC: Add hugepage support for IOMMU in-kernel handling Documentation/virtual/kvm/api.txt| 51 +++ arch/powerpc/include/asm/kvm_host.h | 31 ++ arch/powerpc/include/asm/kvm_ppc.h | 18 +- arch/powerpc/include/asm/pgtable-ppc64.h |4 + arch/powerpc/include/uapi/asm/kvm.h |8 + arch/powerpc/kvm/book3s_64_vio.c | 506 +- arch/powerpc/kvm/book3s_64_vio_hv.c | 439 -- arch/powerpc/kvm/book3s_hv.c | 41 ++- arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 + arch/powerpc/kvm/book3s_pr_papr.c| 37 ++- arch/powerpc/kvm/powerpc.c | 15 + arch/powerpc/mm/init_64.c| 78 - drivers/vfio/vfio.c | 53 include/linux/hashtable.h| 15 + include/linux/page-flags.h |4 +- include/uapi/linux/kvm.h |3 + 16 files changed, 1279 insertions(+), 30 deletions(-) -- 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] perf report: Add option to collapse undesired parts of call graph
On Wed, 26 Jun 2013 18:25:01 -0400, Greg Price wrote:
> Hi Namhyung,
>
> Thanks for the detailed review!
>
>
> On Wed, Jun 26, 2013 at 10:28:56AM +0900, Namhyung Kim wrote:
>> On Sat, 22 Jun 2013 23:17:20 -0400, Greg Price wrote:
>> > For example, in an application with an expensive function
>> > implemented with deeply nested recursive calls, the default
>> > call-graph presentation is dominated by the different callchains
>> > within that function. By treating the function as a black box,
>> > we can collect the callchains leading into the function and
>> > compactly identify what to blame for expensive calls.
>> >
>> > For example, in this report the callers of garbage_collect() are
>>
>> s/callers/callees/ ?
>
> No, 'callers' is right. This report is made without -G/--inverted, so
> the trees are rooted at the inmost callees (the actual values of the
> IP) and each node's children are its callers, rather than vice versa.
> Here we want to see who is making these expensive calls to
> garbage_collect, but the answer to this question is obscured because
> the relevant callchains are separated according to which internal
> helper functions to garbage_collect were on the stack.
>
>
>> And it'd be better it shows more lines after garbage_collect so that one
>> can see its callers also to understand what it does more clearly.
>
> If you mean the commit message, the 'after' example that follows shows
> this. In the actual output (without the 'grep -m10' I've used here)
> the patch doesn't affect those lines, and plenty more are in fact shown.
>
> I could make the 'before' example longer too, and then we'd see what
> the callers were in the callchains that look like
> gc_mark <- mark_keyvalue <- st_foreach <- gc_mark_children
> <- rb_gc_mark <- rb_vm_mark <- gc_mark_children <- gc_marks
> <- garbage_collect <- (the rest of a callchain).
> But the callchains that have something else instead of that particular
> sequence of eight helper functions (gc_mark called by ... called by
> gc_marks) inside garbage_collect won't be included -- they're shown
> in other places in the tree. So it's actually precisely by using this
> option that it's possible to see the callers completely, rather than
> scattered across many places.
Okay, I can see your point now. Thanks for the explanation.
>> [SNIP]
>> > @@ -1211,8 +1214,13 @@ static int machine__resolve_callchain_sample(struct
>> > machine *machine,
>> > MAP__FUNCTION, ip, &al, NULL);
>> >if (al.sym != NULL) {
>> >if (sort__has_parent && !*parent &&
>> > - symbol__match_parent_regex(al.sym))
>> > + symbol__match_regex(al.sym, &parent_regex))
>> >*parent = al.sym;
>> > + else if (have_blackbox && root_al &&
>> > + symbol__match_regex(al.sym, &blackbox_regex)) {
>> > + *root_al = al;
>> > + callchain_cursor_reset(&callchain_cursor);
>>
>> Okay, this is where the magic happens. :)
>
> Indeed! :)
>
>> So it overwrites the original 'al' in process_sample_event() to
>> blackboxed symbol and drop the callchain. Wouldn't it deserve a
>> comment? :)
>
> I could do that. Perhaps something like
> /* ignore the callchain we had so far, i.e. this symbol's callees */
> Sound like what you had in mind?
More important thing is, I think, it updates the original al (root_al)
so that the perf will see the new symbol as if it was sampled in the
first place and it will collect all of its callers in one place.
>
>
>> > + }
>> >if (!symbol_conf.use_callchain)
>> >break;
>> pp
>> This is unrelated to this patch, but why is this line needed? I guess
>> this check should be done before calling this function.
>
> Hmm. We actually can get into this function when
> !symbol_conf.use_callchain, if we're using say --sort=parent. But I'm
> still somewhat puzzled, because in that case it looks like we'll break
> the loop after the first address with a symbol, even if we didn't find
> the 'parent' there, which seems like it wouldn't serve the purpose.
Right, that's what I want to say.
We already have the check before calling this function so breaking the
loop after checking only first callchain node looks strange. If we
don't want to see callchains but only parents, it should either check
every callchain nodes or fail out as an unsupported operation IMHO.
Thanks,
Namhyung
> Probably I'm still missing something.
>
> FWIW, this logic has worked essentially the same way since v2.6.31-rc4~3^2~63.
>
> Cheers,
> Greg
--
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/13] cpufreq: make sure frequency transitions are serialized
On 27 June 2013 03:27, Rafael J. Wysocki wrote:
> Well, now, seeing that the locking around this seems to be kind of haphazard,
> I'm wondering what prevents two different threads from doing CPUFREQ_PRECHANGE
> concurrently in such a way that thread A will check transition_ongoing
> and thread B will check transition_ongoing and then both will set it if it
> was 'false' before. And then one of them will trigger the WARN() in
> CPUFREQ_POSTCHANGE.
>
> Is there any protection in place and if so then how does it work?
cpufreq_notify_transition() is called from driver->target() which is
called from __cpufreq_driver_target(). __cpufreq_driver_target()
is called directly by governors and cpufreq_driver_target() otherwise.
cpufreq_driver_target() implements proper locking and so it is fine.
__cpufreq_driver_target() is called from governors. From governors
it is is serialized in the sense two threads wouldn't call it at the same
time.
And so I thought this will work. But I just found a mistake in my code.
For multi-socket platforms with clock domains for sockets/clusters,
a single instance of transition_ongoing isn't enough and so this must
be embedded in struct cpufreq_policy.
Below patch must get this fixed (Attached).
-x-x-
From: Viresh Kumar
Date: Wed, 19 Jun 2013 10:16:55 +0530
Subject: [PATCH] cpufreq: make sure frequency transitions are serialized
Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.
This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.
This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 14 ++
include/linux/cpufreq.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2d53f47..75715f1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -264,6 +264,12 @@ void __cpufreq_notify_transition(struct
cpufreq_policy *policy,
switch (state) {
case CPUFREQ_PRECHANGE:
+ if (WARN(policy->transition_ongoing,
+ "In middle of another frequency transition\n"))
+ return;
+
+ policy->transition_ongoing = true;
+
/* detect if the driver reported a value as "old frequency"
* which is not equal to what the cpufreq core thinks is
* "old frequency".
@@ -283,6 +289,12 @@ void __cpufreq_notify_transition(struct
cpufreq_policy *policy,
break;
case CPUFREQ_POSTCHANGE:
+ if (WARN(!policy->transition_ongoing,
+ "No frequency transition in progress\n"))
+ return;
+
+ policy->transition_ongoing = false;
+
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
(unsigned long)freqs->cpu);
@@ -1458,6 +1470,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
if (cpufreq_disabled())
return -ENODEV;
+ if (policy->transition_ongoing)
+ return -EBUSY;
/* Make sure that target_freq is within supported range */
if (target_freq > policy->max)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..8c13a45 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -115,6 +115,7 @@ struct cpufreq_policy {
struct kobject kobj;
struct completion kobj_unregister;
+ booltransition_ongoing; /* Tracks transition status
*/
};
#define CPUFREQ_ADJUST (0)
0001-cpufreq-make-sure-frequency-transitions-are-serializ.patch
Description: Binary data
[PATCH v3] powerpc: Rework iommu_table locks
The locks in arch/powerpc/kernel/iommu.c were initally added to protect
iommu_table::it_map so the patch just makes things consistent.
Specifically, it does:
1. add missing locks for it_map access during iommu_take_ownership/
iommu_release_ownership execution where the entire it_map is marked
busy/free in order to avoid allocation from it by some broken
driver on the host.
2. remove locks from functions being called by VFIO. The whole table
is given to the user space so it is responsible now for races.
Signed-off-by: Alexey Kardashevskiy
---
This is actually v3 of [PATCH v2] powerpc/vfio: Add missing locks for
take/release TCE table ownership
---
arch/powerpc/kernel/iommu.c | 40 ++--
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b20ff17..1391ddd 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -975,9 +975,6 @@ EXPORT_SYMBOL_GPL(iommu_tce_put_param_check);
unsigned long iommu_clear_tce(struct iommu_table *tbl, unsigned long entry)
{
unsigned long oldtce;
- struct iommu_pool *pool = get_pool(tbl, entry);
-
- spin_lock(&(pool->lock));
oldtce = ppc_md.tce_get(tbl, entry);
if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ))
@@ -985,8 +982,6 @@ unsigned long iommu_clear_tce(struct iommu_table *tbl,
unsigned long entry)
else
oldtce = 0;
- spin_unlock(&(pool->lock));
-
return oldtce;
}
EXPORT_SYMBOL_GPL(iommu_clear_tce);
@@ -1024,17 +1019,12 @@ int iommu_tce_build(struct iommu_table *tbl, unsigned
long entry,
{
int ret = -EBUSY;
unsigned long oldtce;
- struct iommu_pool *pool = get_pool(tbl, entry);
-
- spin_lock(&(pool->lock));
oldtce = ppc_md.tce_get(tbl, entry);
/* Add new entry if it is not busy */
if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
ret = ppc_md.tce_build(tbl, entry, 1, hwaddr, direction, NULL);
- spin_unlock(&(pool->lock));
-
/* if (unlikely(ret))
pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx
ret=%d\n",
__func__, hwaddr, entry << IOMMU_PAGE_SHIFT,
@@ -1076,32 +1066,54 @@ EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
int iommu_take_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl->it_size + 7) >> 3;
+ unsigned long i, flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&tbl->large_pool.lock, flags);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(&tbl->pools[i].lock);
if (tbl->it_offset == 0)
clear_bit(0, tbl->it_map);
if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
pr_err("iommu_tce: it_map is not empty");
- return -EBUSY;
+ ret = -EBUSY;
+ } else {
+ memset(tbl->it_map, 0xff, sz);
}
- memset(tbl->it_map, 0xff, sz);
- iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(&tbl->pools[i].lock);
+ spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
- return 0;
+ if (!ret)
+ iommu_clear_tces_and_put_pages(tbl, tbl->it_offset,
tbl->it_size);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_take_ownership);
void iommu_release_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl->it_size + 7) >> 3;
+ unsigned long i, flags;
iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
+
+ spin_lock_irqsave(&tbl->large_pool.lock, flags);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(&tbl->pools[i].lock);
+
memset(tbl->it_map, 0, sz);
/* Restore bit#0 set by iommu_init_table() */
if (tbl->it_offset == 0)
set_bit(0, tbl->it_map);
+
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(&tbl->pools[i].lock);
+ spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
--
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 1/3] drivers: mtd: spinand: Add generic spinand frameowrk and micron driver.
Hi Kamlakant, On Wednesday 26 June 2013 08:52 PM, Kamlakant Patel wrote: On Wed, Jun 26, 2013 at 01:11:10PM +0530, Sourav Poddar wrote: From: Mona Anonuevo This patch adds support for a generic spinand framework(spinand_mtd.c). This frameowrk can be used for other spi based flash devices also. The idea is to have a common model under drivers/mtd, as also present for other no spi devices(there is a generic framework and device part simply attaches itself to it.) The generic frework will be used later by me for a SPI based spansion S25FL256 device. The patch also contains a micron driver attaching itself to generic framework. Signed-off-by: Mona Anonuevo Signed-off-by: Tuan Nguyen Signed-off-by: Sourav Poddar [I picked this as a standalone patch, can split it into generic and device part based on community feedback.] drivers/mtd/Kconfig |2 + drivers/mtd/Makefile |2 + drivers/mtd/spinand/Kconfig | 24 ++ drivers/mtd/spinand/Makefile | 10 + drivers/mtd/spinand/spinand_lld.c | 776 + drivers/mtd/spinand/spinand_mtd.c | 690 + include/linux/mtd/spinand.h | 155 7 files changed, 1659 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spinand/Kconfig create mode 100644 drivers/mtd/spinand/Makefile create mode 100644 drivers/mtd/spinand/spinand_lld.c create mode 100644 drivers/mtd/spinand/spinand_mtd.c create mode 100644 include/linux/mtd/spinand.h I am working on Micron SPINAND(Micron MT29F1G01ZACH). I tried this patch, but it's not working. It is throwing following error message while mounting: [ 260.232000] jffs2: cannot read OOB for EB at , requested 8 bytes, read 0 bytes, error -22 mount: mounting /dev/mtdblock5 on /mnt/ failed: Input/output error I am working on it to fix into the driver, will send an updated patch with the fix. Thanks for replying on this. Since, this patch is already posted, I think it will be better if you post the delta fix on top of this patch. Thanks, Kamlakant Patel -- 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] arch: m32r: include: asm: add "dma-mapping-common.h"
Need add generic "dma-mapping-common.h", or compiling may fail. The related error (with allmodconfig): CC [M] net/irda/irlan/irlan_eth.o drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: drivers/media/v4l2-core/videobuf2-dma-contig.c:202:2: error: implicit declaration of function ‘dma_mmap_coherent’ [-Werror=implicit-function-declaration] drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’: drivers/media/v4l2-core/videobuf2-dma-contig.c:385:2: error: implicit declaration of function ‘dma_get_sgtable’ [-Werror=implicit-function-declaration] Signed-off-by: Chen Gang --- arch/m32r/include/asm/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/m32r/include/asm/Kbuild b/arch/m32r/include/asm/Kbuild index bebdc36..fecca22 100644 --- a/arch/m32r/include/asm/Kbuild +++ b/arch/m32r/include/asm/Kbuild @@ -1,5 +1,6 @@ generic-y += clkdev.h +generic-y += dma-mapping-common.h generic-y += exec.h generic-y += module.h generic-y += trace_clock.h -- 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] Optimize wait_sb_inodes()
On Thu, Jun 27, 2013 at 09:14:07AM +0900, OGAWA Hirofumi wrote: > Dave Chinner writes: > > >> On another view, wait_sb_inodes() would (arguably) be necessary for > >> legacy FSes. But, for example, if data=journal on ext*, wait_sb_inodes() > >> would be more than useless, because ext* can be done it by own > >> transaction list (and more efficient way). > >> > >> Likewise, on tux3, the state is same with data=journal. > >> > >> Also, even if data=ordered, ext* might be able to check in-flight I/O by > >> ordered data list (with some new additional check, I'm not sure). > > > > Why would you bother solving this problem differently in every > > single filesystem? It's solvable at the VFS by tracking inodes that > > are no longer dirty but still under writeback on the BDI. Then > > converting wait_sb_inodes() to walk all the dirty and writeback > > inodes would be sufficient for data integrity purposes, and it would > > be done under the bdi writeback lock, not the inode_sb_list_lock > > > > Alternatively, splitting up the inode sb list and lock (say via the > > per-node list_lru structures in -mm and -next that are being added > > for exactly this purpose) would also significantly reduce lock > > contention on both the create/evict fast paths and the > > wait_sb_inodes() walk that is currently done > > > > So I think that you should address the problem properly at the VFS > > level so everyone benefits, not push interfaces that allow > > filesystem specific hacks to work around VFS level deficiencies... > > Optimizing wait_sb_inodes() might help lock contention, but it doesn't > help unnecessary wait/check. You have your own wait code, that doesn't make what the VFS does unnecesary. Quite frankly, I don't trust individual filesystems to get it right - there's a long history of filesystem specific data sync problems (including in XFS), and the best way to avoid that is to ensure the VFS gets it right for you. Indeed, we've gone from having sooper special secret sauce data sync code in XFS to using the VFS over the past few years, and the result is that it is now more reliable and faster than when we were trying to be smart and do it all ourselves. We got to where we are by fixing the problems in the VFS rather than continuing to try to work around them. > Since some FSes know about current > in-flight I/O already in those internal, so I think, those FSes can be > done it here, or are already doing in ->sync_fs(). Sure, do your internal checks in ->sync_fs(), but if wait_sb_inodes() does not have any lock contention and very little overhead, then why do you need to avoid it? This wait has to be done somewhere between sync_inodes_sb() dispatching all the IO and ->sync_fs completing, so what's the problem with hving the VFS do that *for everyone* efficiently? Fix the root cause of the problem - the sub-optimal VFS code. Hacking around it specifically for out-of-tree code is not the way things get done around here... Cheers, Dave. -- Dave Chinner da...@fromorbit.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 3/6 v5] powerpc: export debug registers save function for KVM
Hi, On Wed, 26 Jun 2013 11:12:23 +0530 Bharat Bhushan wrote: > > diff --git a/arch/powerpc/include/asm/switch_to.h > b/arch/powerpc/include/asm/switch_to.h > index 200d763..50b357f 100644 > --- a/arch/powerpc/include/asm/switch_to.h > +++ b/arch/powerpc/include/asm/switch_to.h > @@ -30,6 +30,10 @@ extern void enable_kernel_spe(void); > extern void giveup_spe(struct task_struct *); > extern void load_up_spe(struct task_struct *); > > +#ifdef CONFIG_PPC_ADV_DEBUG_REGS > +extern void switch_booke_debug_regs(struct thread_struct *new_thread); > +#endif We usually don't bother guarding function declarations. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp3l_I6D3s2s.pgp Description: PGP signature
Re: [PATCH v3] staging: usbip: replace pr_warning() with dev_warn().
On Thu, 2013-06-27 at 10:05 +0530, navin patidar wrote:
> dev_warn() is preferred over pr_warning().
[]
> diff --git a/drivers/staging/usbip/usbip_event.c
> b/drivers/staging/usbip/usbip_event.c
[]
> @@ -85,7 +87,20 @@ int usbip_start_eh(struct usbip_device *ud)
>
> ud->eh = kthread_run(event_handler_loop, ud, "usbip_eh");
> if (IS_ERR(ud->eh)) {
> - pr_warning("Unable to start control thread\n");
> + struct device dev;
Don't put a struct device on stack,
just use a struct device *
> + if (ud->side == USBIP_STUB) {
> + struct stub_device *sdev;
> +
> + sdev = container_of(ud, struct stub_device, ud);
> + dev = sdev->udev->dev;
dev = &sdev->udev->dev;
> + } else {
> + struct vhci_device *vdev;
> +
> + vdev = container_of(ud, struct vhci_device, ud);
> + dev = vdev->udev->dev;
dev = &vdev->udev->dev;
though maybe
dev = &container_of(udev, struct vhci_device,
ud)->udev->dev;
would work too.
> + }
> + dev_warn(&dev, "Unable to start control thread\n");
dev_warn(dev, ...)
--
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] arch: m32r: include: asm: add ioread*_rep() and iowrite*_rep()
Hello Maintainers:
If the related 4 patches for io.h pass your checking, it seems OK to
merge them into one patch, the diff like below:
diff begin--
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4010f1f..5506d86 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -67,6 +67,7 @@ static inline void __iomem *ioremap(unsigned long offset,
unsigned long size)
extern void iounmap(volatile void __iomem *addr);
#define ioremap_nocache(off,size) ioremap(off,size)
+#define ioremap_wc ioremap_nocache
/*
* IO bus memory addresses are also 1:1 with the physical address
@@ -162,12 +163,30 @@ static inline void _writel(unsigned long l, unsigned long
addr)
#define __raw_writew writew
#define __raw_writel writel
-#define ioread8 read
+#define ioread8 readb
#define ioread16 readw
+#define ioread16be(addr)__be16_to_cpu(__raw_readw(addr))
#define ioread32 readl
+#define ioread32be(addr)__be32_to_cpu(__raw_readl(addr))
#define iowrite8 writeb
#define iowrite16 writew
+#define iowrite16be(v, addr)__raw_writew(__cpu_to_be16(v), addr)
#define iowrite32 writel
+#define iowrite32be(v, addr)__raw_writel(__cpu_to_be32(v), addr)
+
+#define ioread8_rep(p, dst, count) \
+ insb((unsigned long) (p), (dst), (count))
+#define ioread16_rep(p, dst, count) \
+ insw((unsigned long) (p), (dst), (count))
+#define ioread32_rep(p, dst, count) \
+ insl((unsigned long) (p), (dst), (count))
+
+#define iowrite8_rep(p, src, count) \
+ outsb((unsigned long) (p), (src), (count))
+#define iowrite16_rep(p, src, count) \
+ outsw((unsigned long) (p), (src), (count))
+#define iowrite32_rep(p, src, count) \
+ outsl((unsigned long) (p), (src), (count))
#define mmiowb()
diff end
Thanks.
On 06/27/2013 12:37 PM, Chen Gang wrote:
> add generic ioread*_rep() and iowrite*_rep(), or compiling failed.
>
> The related error (with allmodconfig):
>
> CC [M] drivers/mtd/nand/nand_base.o
> drivers/mtd/nand/nand_base.c: In function ‘nand_write_buf’:
> drivers/mtd/nand/nand_base.c:216:2: error: implicit declaration of function
> ‘iowrite8_rep’ [-Werror=implicit-function-declaration]
> drivers/mtd/nand/nand_base.c: In function ‘nand_read_buf’:
> drivers/mtd/nand/nand_base.c:231:2: error: implicit declaration of function
> ‘ioread8_rep’ [-Werror=implicit-function-declaration]
> drivers/mtd/nand/nand_base.c: In function ‘nand_write_buf16’:
> drivers/mtd/nand/nand_base.c:247:2: error: implicit declaration of function
> ‘iowrite16_rep’ [-Werror=implicit-function-declaration]
> drivers/mtd/nand/nand_base.c: In function ‘nand_read_buf16’:
> drivers/mtd/nand/nand_base.c:263:2: error: implicit declaration of function
> ‘ioread16_rep’ [-Werror=implicit-function-declaration]
>
>
> Signed-off-by: Chen Gang
> ---
> arch/m32r/include/asm/io.h | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
> index 4010f1f..167d6ed 100644
> --- a/arch/m32r/include/asm/io.h
> +++ b/arch/m32r/include/asm/io.h
> @@ -169,6 +169,20 @@ static inline void _writel(unsigned long l, unsigned
> long addr)
> #define iowrite16 writew
> #define iowrite32 writel
>
> +#define ioread8_rep(p, dst, count) \
> + insb((unsigned long) (p), (dst), (count))
> +#define ioread16_rep(p, dst, count) \
> + insw((unsigned long) (p), (dst), (count))
> +#define ioread32_rep(p, dst, count) \
> + insl((unsigned long) (p), (dst), (count))
> +
> +#define iowrite8_rep(p, src, count) \
> + outsb((unsigned long) (p), (src), (count))
> +#define iowrite16_rep(p, src, count) \
> + outsw((unsigned long) (p), (src), (count))
> +#define iowrite32_rep(p, src, count) \
> + outsl((unsigned long) (p), (src), (count))
> +
> #define mmiowb()
>
> #define flush_write_buffers() do { } while (0) /* M32R_FIXME */
>
--
Chen Gang
--
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] arch: m32r: include: asm: add ioread*_rep() and iowrite*_rep()
add generic ioread*_rep() and iowrite*_rep(), or compiling failed.
The related error (with allmodconfig):
CC [M] drivers/mtd/nand/nand_base.o
drivers/mtd/nand/nand_base.c: In function ‘nand_write_buf’:
drivers/mtd/nand/nand_base.c:216:2: error: implicit declaration of function
‘iowrite8_rep’ [-Werror=implicit-function-declaration]
drivers/mtd/nand/nand_base.c: In function ‘nand_read_buf’:
drivers/mtd/nand/nand_base.c:231:2: error: implicit declaration of function
‘ioread8_rep’ [-Werror=implicit-function-declaration]
drivers/mtd/nand/nand_base.c: In function ‘nand_write_buf16’:
drivers/mtd/nand/nand_base.c:247:2: error: implicit declaration of function
‘iowrite16_rep’ [-Werror=implicit-function-declaration]
drivers/mtd/nand/nand_base.c: In function ‘nand_read_buf16’:
drivers/mtd/nand/nand_base.c:263:2: error: implicit declaration of function
‘ioread16_rep’ [-Werror=implicit-function-declaration]
Signed-off-by: Chen Gang
---
arch/m32r/include/asm/io.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4010f1f..167d6ed 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -169,6 +169,20 @@ static inline void _writel(unsigned long l, unsigned long
addr)
#define iowrite16 writew
#define iowrite32 writel
+#define ioread8_rep(p, dst, count) \
+ insb((unsigned long) (p), (dst), (count))
+#define ioread16_rep(p, dst, count) \
+ insw((unsigned long) (p), (dst), (count))
+#define ioread32_rep(p, dst, count) \
+ insl((unsigned long) (p), (dst), (count))
+
+#define iowrite8_rep(p, src, count) \
+ outsb((unsigned long) (p), (src), (count))
+#define iowrite16_rep(p, src, count) \
+ outsw((unsigned long) (p), (src), (count))
+#define iowrite32_rep(p, src, count) \
+ outsl((unsigned long) (p), (src), (count))
+
#define mmiowb()
#define flush_write_buffers() do { } while (0) /* M32R_FIXME */
--
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 3/4] regulators: Add TPS659038 documentation under Palmas
Hello Grant, > -Original Message- > From: J, KEERTHY > Sent: Thursday, June 20, 2013 4:36 PM > To: linux-o...@vger.kernel.org; grant.lik...@secretlab.ca > Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; > sa...@linux.intel.com; swar...@nvidia.com; linux- > ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org; g...@slimlogic.co.uk > Subject: [PATCH 3/4] regulators: Add TPS659038 documentation under > Palmas > > Add TPS659038 documentation under Palmas. > Could you please pull this one? > Signed-off-by: J Keerthy > Acked-by: Mark Brown > --- > .../devicetree/bindings/regulator/palmas-pmic.txt |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/regulator/palmas- > pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt > index d5a3086..5115cd7 100644 > --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt > +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt > @@ -7,6 +7,7 @@ Required properties: >ti,twl6037-pmic >ti,tps65913-pmic >ti,tps65914-pmic > + ti,tps659038-pmic > and also the generic series names >ti,palmas-pmic > - interrupt-parent : The parent interrupt controller which is palmas. > -- > 1.7.5.4 Regards, Keerthy -- 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] staging: usbip: replace pr_warning() with dev_warn().
dev_warn() is preferred over pr_warning().
container_of() is used to get usb_driver pointer from usbip_device container
(stub_device or vhci_device), to get device structure required for dev_warn().
Signed-off-by: navin patidar
---
drivers/staging/usbip/usbip_event.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/usbip_event.c
b/drivers/staging/usbip/usbip_event.c
index 82123be..eca14b7 100644
--- a/drivers/staging/usbip/usbip_event.c
+++ b/drivers/staging/usbip/usbip_event.c
@@ -21,6 +21,8 @@
#include
#include "usbip_common.h"
+#include "stub.h"
+#include "vhci.h"
static int event_handler(struct usbip_device *ud)
{
@@ -85,7 +87,20 @@ int usbip_start_eh(struct usbip_device *ud)
ud->eh = kthread_run(event_handler_loop, ud, "usbip_eh");
if (IS_ERR(ud->eh)) {
- pr_warning("Unable to start control thread\n");
+ struct device dev;
+
+ if (ud->side == USBIP_STUB) {
+ struct stub_device *sdev;
+
+ sdev = container_of(ud, struct stub_device, ud);
+ dev = sdev->udev->dev;
+ } else {
+ struct vhci_device *vdev;
+
+ vdev = container_of(ud, struct vhci_device, ud);
+ dev = vdev->udev->dev;
+ }
+ dev_warn(&dev, "Unable to start control thread\n");
return PTR_ERR(ud->eh);
}
--
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 1/4] MFD: Add TPS659038 documentation under Palmas
Hi Grant, > -Original Message- > From: J, KEERTHY > Sent: Monday, June 24, 2013 6:26 PM > To: grant.lik...@secretlab.ca > Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; > swar...@nvidia.com; linux-kernel@vger.kernel.org; linux- > d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; > g...@slimlogic.co.uk; J, KEERTHY; linux-o...@vger.kernel.org > Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas > > Hello Grant, > > > -Original Message- > > From: J, KEERTHY > > Sent: Thursday, June 20, 2013 4:35 PM > > To: linux-o...@vger.kernel.org; grant.lik...@secretlab.ca > > Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; > > sa...@linux.intel.com; swar...@nvidia.com; linux- > > ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- > > disc...@lists.ozlabs.org; g...@slimlogic.co.uk > > Subject: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas > > > > Add TPS659038 documentation under Palmas. > > > > Could you pull this Please? A gentle ping on this. > > > Signed-off-by: J Keerthy > > Acked-by: Samuel Ortiz > > --- > > Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt > > b/Documentation/devicetree/bindings/mfd/palmas.txt > > index 7bcd59c..89cb773 100644 > > --- a/Documentation/devicetree/bindings/mfd/palmas.txt > > +++ b/Documentation/devicetree/bindings/mfd/palmas.txt > > @@ -5,6 +5,7 @@ twl6035 (palmas) > > twl6037 (palmas) > > tps65913 (palmas) > > tps65914 (palmas) > > +tps659038 > > > > Required properties: > > - compatible : Should be from the list @@ -14,6 +15,7 @@ Required > > properties: > >ti,tps65913 > >ti,tps65914 > >ti,tps80036 > > + ti,tps659038 > > and also the generic series names > >ti,palmas > > - interrupt-controller : palmas has its own internal IRQs > > -- > > 1.7.5.4 > > Regards, > Keerthy Regards, Keerthy -- 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/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of J, KEERTHY
> Sent: Tuesday, June 25, 2013 3:51 PM
> To: sa...@linux.intel.com
> Cc: broo...@kernel.org; ldewan...@nvidia.com;
> grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk;
> linux-o...@vger.kernel.org
> Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
>
> Hi Samuel,
>
> > -Original Message-
> > From: J, KEERTHY
> > Sent: Friday, June 21, 2013 2:38 PM
> > To: sa...@linux.intel.com
> > Cc: broo...@kernel.org; ldewan...@nvidia.com;
> > grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> > ker...@vger.kernel.org; linux-...@vger.kernel.org;
> g...@slimlogic.co.uk;
> > linux-o...@vger.kernel.org
> > Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
> >
> > Hi Samuel,
> >
> > > -Original Message-
> > > From: J, KEERTHY
> > > Sent: Thursday, June 20, 2013 4:32 PM
> > > To: linux-o...@vger.kernel.org; sa...@linux.intel.com
> > > Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
> > > grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> > > ker...@vger.kernel.org; linux-...@vger.kernel.org;
> > > g...@slimlogic.co.uk
> > > Subject: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
> > >
> > > Add TPS659038 support.
> > >
> >
> > Could you pull this one too?
>
> A gentle ping on this.
Since the previous patch was applied by you
Even this patch needs to be taken by you.
Could you please pull this?
>
> >
> > > Signed-off-by: J Keerthy
> > > Acked-by: Mark Brown
> > > ---
> > > drivers/regulator/palmas-regulator.c |1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/regulator/palmas-regulator.c
> > > b/drivers/regulator/palmas-regulator.c
> > > index 1ae1e83..d0c8785 100644
> > > --- a/drivers/regulator/palmas-regulator.c
> > > +++ b/drivers/regulator/palmas-regulator.c
> > > @@ -1054,6 +1054,7 @@ static struct of_device_id
> > of_palmas_match_tbl[]
> > > = {
> > > { .compatible = "ti,tps65913-pmic", },
> > > { .compatible = "ti,tps65914-pmic", },
> > > { .compatible = "ti,tps80036-pmic", },
> > > + { .compatible = "ti,tps659038-pmic", },
> > > { /* end */ }
> > > };
> > >
> > > --
> > > 1.7.5.4
> >
> > Regards,
> > Keerthy
>
> Regards,
> Keerthy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html
Regards,
Keerthy
--
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] perf tools: Fixup for removing -f option in perf record
From: Namhyung Kim
The commit bf3da4014a0c ("perf record: Remove -f/--force option") got
rid of -f option from perf record. But this option was used
internally by various sub-commands so they wouldn't work anymore.
Also update the example document not to use -f option.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/examples.txt | 4 ++--
tools/perf/builtin-kmem.c | 2 +-
tools/perf/builtin-lock.c | 2 +-
tools/perf/builtin-sched.c| 1 -
tools/perf/builtin-timechart.c| 4 ++--
5 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/examples.txt
b/tools/perf/Documentation/examples.txt
index 77f952762426..a4e392156488 100644
--- a/tools/perf/Documentation/examples.txt
+++ b/tools/perf/Documentation/examples.txt
@@ -66,7 +66,7 @@ Furthermore, these tracepoints can be used to sample the
workload as
well. For example the page allocations done by a 'git gc' can be
captured the following way:
- titan:~/git> perf record -f -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
@@ -120,7 +120,7 @@ Furthermore, call-graph sampling can be done too, of page
allocations - to see precisely what kind of page allocations there
are:
- titan:~/git> perf record -f -g -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -g -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 46878daca5cc..0259502638b4 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -708,7 +708,7 @@ static int parse_line_opt(const struct option *opt
__maybe_unused,
static int __cmd_record(int argc, const char **argv)
{
const char * const record_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "kmem:kmalloc",
"-e", "kmem:kmalloc_node",
"-e", "kmem:kfree",
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 425830069749..76543a4a7a30 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -878,7 +878,7 @@ static int __cmd_report(void)
static int __cmd_record(int argc, const char **argv)
{
const char *record_args[] = {
- "record", "-R", "-f", "-m", "1024", "-c", "1",
+ "record", "-R", "-m", "1024", "-c", "1",
};
unsigned int rec_argc, i, j;
const char **rec_argv;
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 2da2a6ca22bf..fed9ae432c16 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1632,7 +1632,6 @@ static int __cmd_record(int argc, const char **argv)
"record",
"-a",
"-R",
- "-f",
"-m", "1024",
"-c", "1",
"-e", "sched:sched_switch",
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index ab4cf232b852..4536a92b18f3 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1005,7 +1005,7 @@ static int __cmd_record(int argc, const char **argv)
{
#ifdef SUPPORT_OLD_POWER_EVENTS
const char * const record_old_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "power:power_start",
"-e", "power:power_end",
"-e", "power:power_frequency",
@@ -1014,7 +1014,7 @@ static int __cmd_record(int argc, const char **argv)
};
#endif
const char * const record_new_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "power:cpu_frequency",
"-e", "power:cpu_idle",
"-e", "sched:sched_wakeup",
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the net-next tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/wireless/nl80211.c between merge commits from the net-next tree and
commit 86e8cf98de3e ("nl80211: use small state buffer for wiphy_dump")
from the wireless-next tree.
I think I fixed it up (see below, please check) and can carry the fix as
necessary (no action is required). I think that my fix means that that
commit 86e8cf98de3e is missing the extra "rtnl_unlock();", right?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/wireless/nl80211.c
index e545023,7dc3343..000
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -1520,47 -1562,23 +1562,25 @@@ static int nl80211_dump_wiphy_parse(str
static int nl80211_dump_wiphy(struct sk_buff *skb, struct netlink_callback
*cb)
{
int idx = 0, ret;
- int start = cb->args[0];
+ struct nl80211_dump_wiphy_state *state = (void *)cb->args[0];
struct cfg80211_registered_device *dev;
- s64 filter_wiphy = -1;
- bool split = false;
- struct nlattr **tb;
- int res;
-
- /* will be zeroed in nlmsg_parse() */
- tb = kmalloc(sizeof(*tb) * (NL80211_ATTR_MAX + 1), GFP_KERNEL);
- if (!tb)
- return -ENOMEM;
rtnl_lock();
-
- res = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
- tb, NL80211_ATTR_MAX, nl80211_policy);
- if (res == 0) {
- split = tb[NL80211_ATTR_SPLIT_WIPHY_DUMP];
- if (tb[NL80211_ATTR_WIPHY])
- filter_wiphy = nla_get_u32(tb[NL80211_ATTR_WIPHY]);
- if (tb[NL80211_ATTR_WDEV])
- filter_wiphy = nla_get_u64(tb[NL80211_ATTR_WDEV]) >> 32;
- if (tb[NL80211_ATTR_IFINDEX]) {
- struct net_device *netdev;
- int ifidx = nla_get_u32(tb[NL80211_ATTR_IFINDEX]);
-
- netdev = dev_get_by_index(sock_net(skb->sk), ifidx);
- if (!netdev) {
- rtnl_unlock();
- kfree(tb);
- return -ENODEV;
- }
- if (netdev->ieee80211_ptr) {
- dev = wiphy_to_dev(
- netdev->ieee80211_ptr->wiphy);
- filter_wiphy = dev->wiphy_idx;
- }
- dev_put(netdev);
+ if (!state) {
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
++ if (!state) {
++ rtnl_unlock();
+ return -ENOMEM;
+ }
+ state->filter_wiphy = -1;
+ ret = nl80211_dump_wiphy_parse(skb, cb, state);
+ if (ret) {
+ kfree(state);
+ rtnl_unlock();
+ return ret;
+ }
+ cb->args[0] = (long)state;
}
- kfree(tb);
list_for_each_entry(dev, &cfg80211_rdev_list, list) {
if (!net_eq(wiphy_net(&dev->wiphy), sock_net(skb->sk)))
pgpwRGxv7SYZ8.pgp
Description: PGP signature
[PATCH 2/2] f2fs: fix to recover i_size from roll-forward
If user requests many data writes and fsync together, the last updated i_size
should be stored to the inode block consistently.
But, previous write_end just marks the inode as dirty and doesn't update its
metadata into its inode block.
After that, fsync just writes the inode block with newly updated data index
excluding inode metadata updates.
So, this patch introduces write_end in which updates inode block too when the
i_size is changed.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6d4a743..e88f46f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -701,6 +701,27 @@ err:
return err;
}
+static int f2fs_write_end(struct file *file,
+ struct address_space *mapping,
+ loff_t pos, unsigned len, unsigned copied,
+ struct page *page, void *fsdata)
+{
+ struct inode *inode = page->mapping->host;
+
+ SetPageUptodate(page);
+ set_page_dirty(page);
+
+ if (pos + copied > i_size_read(inode)) {
+ i_size_write(inode, pos + copied);
+ mark_inode_dirty(inode);
+ update_inode_page(inode);
+ }
+
+ unlock_page(page);
+ page_cache_release(page);
+ return copied;
+}
+
static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
const struct iovec *iov, loff_t offset, unsigned long nr_segs)
{
@@ -757,7 +778,7 @@ const struct address_space_operations f2fs_dblock_aops = {
.writepage = f2fs_write_data_page,
.writepages = f2fs_write_data_pages,
.write_begin= f2fs_write_begin,
- .write_end = nobh_write_end,
+ .write_end = f2fs_write_end,
.set_page_dirty = f2fs_set_data_page_dirty,
.invalidatepage = f2fs_invalidate_data_page,
.releasepage= f2fs_release_data_page,
--
1.8.3.1.437.g0dbd812
--
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/2] f2fs: remove reusing any prefree segments
This patch removes check_prefree_segments initially designed to enhance the
performance by narrowing the range of LBA usage across the whole block device.
When allocating a new segment, previous f2fs tries to find proper prefree
segments, and then, if finds a segment, it reuses the segment for further
data or node block allocation.
However, I found that this was totally wrong approach since the prefree segments
have several data or node blocks that will be used by the roll-forward mechanism
operated after sudden-power-off.
Let's assume the following scenario.
/* write 8MB with fsync */
for (i = 0; i < 2048; i++) {
offset = i * 4096;
write(fd, offset, 4KB);
fsync(fd);
}
In this case, naive segment allocation sequence will be like:
data segment: x, x+1, x+2, x+3
node segment: y, y+1, y+2, y+3.
But, if we can reuse prefree segments, the sequence can be like:
data segment: x, x+1, y, y+1
node segment: y, y+1, y+2, y+3.
Because, y, y+1, and y+2 became prefree segments one by one, and those are
reused by data allocation.
After conducting this workload, we should consider how to recover the latest
inode with its data.
If we reuse the prefree segments such as y or y+1, we lost the old node blocks
so that f2fs even cannot start roll-forward recovery.
Therefore, I suggest that we should remove reusing prefree segments.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 56 +--
1 file changed, 1 insertion(+), 55 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 3ac4d29..a86d125 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -309,56 +309,6 @@ static void write_sum_page(struct f2fs_sb_info *sbi,
f2fs_put_page(page, 1);
}
-static unsigned int check_prefree_segments(struct f2fs_sb_info *sbi, int type)
-{
- struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
- unsigned long *prefree_segmap = dirty_i->dirty_segmap[PRE];
- unsigned int segno;
- unsigned int ofs = 0;
-
- /*
-* If there is not enough reserved sections,
-* we should not reuse prefree segments.
-*/
- if (has_not_enough_free_secs(sbi, 0))
- return NULL_SEGNO;
-
- /*
-* NODE page should not reuse prefree segment,
-* since those information is used for SPOR.
-*/
- if (IS_NODESEG(type))
- return NULL_SEGNO;
-next:
- segno = find_next_bit(prefree_segmap, TOTAL_SEGS(sbi), ofs);
- ofs += sbi->segs_per_sec;
-
- if (segno < TOTAL_SEGS(sbi)) {
- int i;
-
- /* skip intermediate segments in a section */
- if (segno % sbi->segs_per_sec)
- goto next;
-
- /* skip if the section is currently used */
- if (sec_usage_check(sbi, GET_SECNO(sbi, segno)))
- goto next;
-
- /* skip if whole section is not prefree */
- for (i = 1; i < sbi->segs_per_sec; i++)
- if (!test_bit(segno + i, prefree_segmap))
- goto next;
-
- /* skip if whole section was not free at the last checkpoint */
- for (i = 0; i < sbi->segs_per_sec; i++)
- if (get_seg_entry(sbi, segno + i)->ckpt_valid_blocks)
- goto next;
-
- return segno;
- }
- return NULL_SEGNO;
-}
-
static int is_next_segment_free(struct f2fs_sb_info *sbi, int type)
{
struct curseg_info *curseg = CURSEG_I(sbi, type);
@@ -597,11 +547,7 @@ static void allocate_segment_by_default(struct
f2fs_sb_info *sbi,
goto out;
}
- curseg->next_segno = check_prefree_segments(sbi, type);
-
- if (curseg->next_segno != NULL_SEGNO)
- change_curseg(sbi, type, false);
- else if (type == CURSEG_WARM_NODE)
+ if (type == CURSEG_WARM_NODE)
new_curseg(sbi, type, false);
else if (curseg->alloc_type == LFS && is_next_segment_free(sbi, type))
new_curseg(sbi, type, false);
--
1.8.3.1.437.g0dbd812
--
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] include/asm-generic/pci.h: include generic "pci-dma-compat.h"
If an architecture need "generic pci.h", it also need generic "pci-dma-
compat.h", so recommend to include it in asm-generic directly.
And now, for arm64 and m32r, may cause compiling error about it.
The related error (with allmodconfig):
drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_exit’:
drivers/media/usb/b2c2/flexcop-usb.c:393:3: error: implicit declaration of
function ‘pci_free_consistent’ [-Werror=implicit-function-declaration]
drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_init’:
drivers/media/usb/b2c2/flexcop-usb.c:410:2: error: implicit declaration of
function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration]
drivers/media/usb/b2c2/flexcop-usb.c:410:21: warning: assignment makes
pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
Signed-off-by: Chen Gang
---
include/asm-generic/pci.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
index e80a049..64e2a15 100644
--- a/include/asm-generic/pci.h
+++ b/include/asm-generic/pci.h
@@ -6,6 +6,8 @@
#ifndef _ASM_GENERIC_PCI_H
#define _ASM_GENERIC_PCI_H
+#include
+
static inline struct resource *
pcibios_select_root(struct pci_dev *pdev, struct resource *res)
{
--
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 v2 3/3] cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework
On 26 June 2013 19:28, Lukasz Majewski wrote: > On Wed, 26 Jun 2013 16:35:32 +0530, Viresh Kumar wrote: >> This patch is still few generations back :) > > But this is v2 version of boost patches. My mistake > Please also review: > [PATCH v4 4/7] > [PATCH v4 5/7] > [PATCH v4 6/7] > [PATCH v4 7/7] - disable boost at thermal framework don't worry I will review everything. I went home after reviewing half of the patches. -- 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] xen: reuse the same pirq allocated when driver load first time
On 2013-06-27 02:08, Stefano Stabellini wrote:
On Wed, 26 Jun 2013, Zhenzhong Duan wrote:
On 2013-06-26 01:51, Stefano Stabellini wrote:
On Tue, 25 Jun 2013, DuanZhenzhong wrote:
Stefano Stabellini wrote:
Trimming some of the people in CC
On Mon, 24 Jun 2013, Zhenzhong Duan wrote:
On 2013-06-20 22:21, Stefano Stabellini wrote:
On Thu, 20 Jun 2013, Zhenzhong Duan wrote:
On 2013-06-05 20:50, Stefano Stabellini wrote:
On Wed, 5 Jun 2013, Zhenzhong Duan wrote:
Stefano Stabellini wrote:
On Tue, 21 May 2013, Stefano Stabellini wrote:
On Tue, 21 May 2013, Konrad Rzeszutek Wilk wrote:
Looking at the hypervisor code I couldn't see anything
obviously
wrong.
I think the culprit is "physdev_unmap_pirq":
if ( is_hvm_domain(d) )
{
spin_lock(&d->event_lock);
gdprintk(XENLOG_WARNING,"d%d, pirq: %d is %x %s,
irq:
%d\n",
d->domain_id, pirq, domain_pirq_to_emuirq(d,
pirq),
domain_pirq_to_emuirq(d, pirq) == IRQ_UNBOUND ?
"unbound" :
"",
domain_pirq_to_irq(d, pirq));
if
( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
ret = unmap_domain_pirq_emuirq(d, pirq);
spin_unlock(&d->event_lock);
if ( domid == DOMID_SELF || ret )
goto free_domain;
It always tells me unbound:
(XEN) physdev.c:237:d14 14, pirq: 54 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 53 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 52 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 51 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 50 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(a bit older debug code, so the 'unbound' does not show up
here).
Which means that the call to unmap_domain_pirq_emuirq does not
happen.
The checks in unmap_domain_pirq_emuirq also look to be depend
on the code being IRQ_UNBOUND.
In other words, all of that code looks to only clear things
when
they are !IRQ_UNBOUND.
But the other logic (IRQ_UNBOUND) looks to be missing a
removal
in the radix tree:
if ( emuirq != IRQ_PT )
radix_tree_delete(&d->arch.hvm_domain.emuirq_pirq,
emuirq);
And
I think that is what is causing the leak - the radix tree
needs to be pruned? Or perhaps the allocate_pirq should check
the radix tree for IRQ_UNBOUND ones and re-use them?
I think that you are looking in the wrong place.
The issue is that QEMU doesn't call pt_msi_disable in
pt_msgctrl_reg_write if (!val & PCI_MSI_FLAGS_ENABLE).
The code above is correct as is because it is trying to handle
emulated
IRQs and MSIs, not real passthrough MSIs. They latter are not
added to
that radix tree, see physdev_hvm_map_pirq and
physdev_map_pirq.
This patch fixes the issue, I have only tested MSI
(MSI-X
completely
untested).
diff --git a/hw/pass-through.c b/hw/pass-through.c
index 304c438..079e465 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3866,7 +3866,11 @@ static int pt_msgctrl_reg_write(struct
pt_dev
*ptdev,
ptdev->msi->flags |= PCI_MSI_FLAGS_ENABLE;
}
else
-ptdev->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+{
+if (ptdev->msi->flags & PT_MSI_MAPPED) {
+pt_msi_disable(ptdev);
+}
+}
/* pass through MSI_ENABLE bit when no MSI-INTx
translation
*/
if (!ptdev->msi_trans_en) {
@@ -4013,6 +4017,8 @@ static int pt_msixctrl_reg_write(struct
pt_dev
*ptdev,
pt_disable_msi_translate(ptdev);
}
pt_msix_update(ptdev);
+} else if (!(*value & PCI_MSIX_ENABLE) &&
ptdev->msix->enabled) {
+pt_msix_delete(ptdev);
Hi Stefano,
I made a test with this patch, os reboot when driver reload.
If
use
pt_msix_disable
instead of pt_msix_delete, driver could be reloaded.
But I still see some error in qemu.log and xen console. Seems
four
IRQs
are not freed
when unmap.
--first load---
pt_msix_update_one: pt_msix_update_one requested pirq = 103
pt_msix_update_one: Update msix entry 0 with pirq 67 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 102
pt_msix_update_one: Update msix entry 1 with pirq 66 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 101
pt_msix_update_one: Update msix entry 2 with pirq 65 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 100
pt_msix_update_one: Update msix entry 3 with pirq 64 gvec 0
- first unload---
pt_msix_disable: Unbind msix with pirq 67, gvec 0
pt_msix_disable: Unmap msix with pirq 67
pt_msix_disable: Error: Unmapping of MSI-X failed. [00:04.0]
pt_msix_disable
Re: [RFC][PATCH RT 1/6] rt,rcu: Have rcu_read_lock_sched() use locks for PREEMPT_RT
On Wed, 2013-06-26 at 15:28 -0400, Steven Rostedt wrote:
> @@ -2491,6 +2491,31 @@ static inline int rcu_blocking_is_gp(voi
> return ret;
> }
>
> +#ifdef CONFIG_PREEMPT_RT_FULL
> +DEFINE_LOCAL_IRQ_LOCK(rcu_sched_lock);
> +/*
> + * Real-time allows for synchronize sched to sleep but not migrate.
> + * This is done via the local locks. When calling synchronize_sched(),
> + * all the local locks need to be taken and released. This will ensure
> + * that all users of rcu_read_lock_sched() will be out of their critical
> + * sections at the completion of this function. synchronize_sched() will
> + * still perform the normal RCU sched operations to synchronize with
> + * locations that use disabling preemption or interrupts.
> + */
> +static void rcu_synchronize_sched_rt(void)
> +{
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + spin_lock(&per_cpu(rcu_sched_lock, cpu).lock);
> + spin_unlock(&per_cpu(rcu_sched_lock, cpu).lock);
> + }
> +}
Does that have to be possible vs online?
-Mike
--
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/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/freescale/fec_main.c between commits 32bc9b46d840
("fec: Add support to restart autonegotiate") and d13919301d9a ("net:
fec: Fix build for MCF5272") from the net tree and commit 38ae92dc215e
("ec: Add support for reading RMON registers") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/freescale/fec_main.c
index d48099f,ed6180e..000
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@@ -1444,13 -1443,121 +1451,122 @@@ static int fec_enet_set_pauseparam(stru
return 0;
}
- #endif /* !defined(CONFIG_M5272) */
-#ifndef CONFIG_M5272
+ static const struct fec_stat {
+ char name[ETH_GSTRING_LEN];
+ u16 offset;
+ } fec_stats[] = {
+ /* RMON TX */
+ { "tx_dropped", RMON_T_DROP },
+ { "tx_packets", RMON_T_PACKETS },
+ { "tx_broadcast", RMON_T_BC_PKT },
+ { "tx_multicast", RMON_T_MC_PKT },
+ { "tx_crc_errors", RMON_T_CRC_ALIGN },
+ { "tx_undersize", RMON_T_UNDERSIZE },
+ { "tx_oversize", RMON_T_OVERSIZE },
+ { "tx_fragment", RMON_T_FRAG },
+ { "tx_jabber", RMON_T_JAB },
+ { "tx_collision", RMON_T_COL },
+ { "tx_64byte", RMON_T_P64 },
+ { "tx_65to127byte", RMON_T_P65TO127 },
+ { "tx_128to255byte", RMON_T_P128TO255 },
+ { "tx_256to511byte", RMON_T_P256TO511 },
+ { "tx_512to1023byte", RMON_T_P512TO1023 },
+ { "tx_1024to2047byte", RMON_T_P1024TO2047 },
+ { "tx_GTE2048byte", RMON_T_P_GTE2048 },
+ { "tx_octets", RMON_T_OCTETS },
+
+ /* IEEE TX */
+ { "IEEE_tx_drop", IEEE_T_DROP },
+ { "IEEE_tx_frame_ok", IEEE_T_FRAME_OK },
+ { "IEEE_tx_1col", IEEE_T_1COL },
+ { "IEEE_tx_mcol", IEEE_T_MCOL },
+ { "IEEE_tx_def", IEEE_T_DEF },
+ { "IEEE_tx_lcol", IEEE_T_LCOL },
+ { "IEEE_tx_excol", IEEE_T_EXCOL },
+ { "IEEE_tx_macerr", IEEE_T_MACERR },
+ { "IEEE_tx_cserr", IEEE_T_CSERR },
+ { "IEEE_tx_sqe", IEEE_T_SQE },
+ { "IEEE_tx_fdxfc", IEEE_T_FDXFC },
+ { "IEEE_tx_octets_ok", IEEE_T_OCTETS_OK },
+
+ /* RMON RX */
+ { "rx_packets", RMON_R_PACKETS },
+ { "rx_broadcast", RMON_R_BC_PKT },
+ { "rx_multicast", RMON_R_MC_PKT },
+ { "rx_crc_errors", RMON_R_CRC_ALIGN },
+ { "rx_undersize", RMON_R_UNDERSIZE },
+ { "rx_oversize", RMON_R_OVERSIZE },
+ { "rx_fragment", RMON_R_FRAG },
+ { "rx_jabber", RMON_R_JAB },
+ { "rx_64byte", RMON_R_P64 },
+ { "rx_65to127byte", RMON_R_P65TO127 },
+ { "rx_128to255byte", RMON_R_P128TO255 },
+ { "rx_256to511byte", RMON_R_P256TO511 },
+ { "rx_512to1023byte", RMON_R_P512TO1023 },
+ { "rx_1024to2047byte", RMON_R_P1024TO2047 },
+ { "rx_GTE2048byte", RMON_R_P_GTE2048 },
+ { "rx_octets", RMON_R_OCTETS },
+
+ /* IEEE RX */
+ { "IEEE_rx_drop", IEEE_R_DROP },
+ { "IEEE_rx_frame_ok", IEEE_R_FRAME_OK },
+ { "IEEE_rx_crc", IEEE_R_CRC },
+ { "IEEE_rx_align", IEEE_R_ALIGN },
+ { "IEEE_rx_macerr", IEEE_R_MACERR },
+ { "IEEE_rx_fdxfc", IEEE_R_FDXFC },
+ { "IEEE_rx_octets_ok", IEEE_R_OCTETS_OK },
+ };
+
+ static void fec_enet_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+ {
+ struct fec_enet_private *fep = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(fec_stats); i++)
+ data[i] = readl(fep->hwp + fec_stats[i].offset);
+ }
+
+ static void fec_enet_get_strings(struct net_device *netdev,
+ u32 stringset, u8 *data)
+ {
+ int i;
+ switch (stringset) {
+ case ETH_SS_STATS:
+ for (i = 0; i < ARRAY_SIZE(fec_stats); i++)
+ memcpy(data + i * ETH_GSTRING_LEN,
+ fec_stats[i].name, ETH_GSTRING_LEN);
+ break;
+ }
+ }
+
+ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
+ {
+ switch (sset) {
+ case ETH_SS_STATS:
+ return ARRAY_SIZE(fec_stats);
+ default:
+ return -EOPNOTSUPP;
+ }
+ }
+ #endif
+
+ static int fec_enet_nway_reset(struct net_device *dev)
+ {
+ struct fec_enet_private *fep = netdev_priv(dev);
+ struct phy_device *phydev = fep->phy_dev;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return genphy_restart_aneg(phydev);
+ }
static const struct ethtool_ops fec_enet_ethtool_ops = {
+#if !defined(CONFIG_M5272)
.get_pauseparam = fec_enet_get_pauseparam,
.set_pauseparam = fec_enet_set_pauseparam,
+#endif
.get_settings = fec_enet_get_settings,
.set_settings = fec_enet_set_settings,
.get_drvin
Re: [PATCH 15/15] perf, tools: Add perf stat --transaction v3
> OK. I'm still confused by that one sorry. In the patch you do: > > + else if (perf_evsel__cmp(counter, nth_evsel(T_CYCLES_IN_TX_CP))) > + update_stats(&runtime_cycles_in_txcp_stats[0], count[0]); > > But then I don't see where you use runtime_cycles_in_txcp_stats ? You're right that variable is not needed. I'll remove it. It only needs the in_tx stat. intx-cp is still output, but directly by abs_printout, without going through a variable. > > > > But I don't think we have anything equivalent. > > > > But you have cycles-t and tx-start? > > We have: > - cycles > - cycles in transactional state > - cycles spent in successful transactions > > So your cycles-t is "cycles in transactional state". > > We would calculate cycles wasted in aborts with: > > "cycles in transactional" - "cycles in successful transactions" > > Which I think is what you're describing above with cycles-ct. Yes, that should be equivalent. That should be easy to check for and handle: check for that event and switch the formula around. I'll leave that to you as I don't have any way to test it. > Does "tx-start" just count the number of transactions begun? Does it > count nested transactions? Just begun without nesting (TSX flattens all transactions) -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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] arch: arm64: include: asm: add pci.h to pass compiling
On 06/27/2013 10:05 AM, Chen Gang wrote: > On 06/27/2013 08:30 AM, Chen Gang wrote: >> On 06/26/2013 10:07 PM, Catalin Marinas wrote: >>> On Wed, Jun 26, 2013 at 04:26:41AM +0100, Chen Gang wrote: > Need add pci.h for compiling, the related error (with allmodconfig): > > drivers/media/usb/b2c2/flexcop-usb.c: In function > ‘flexcop_usb_transfer_exit’: > drivers/media/usb/b2c2/flexcop-usb.c:393:3: error: implicit declaration > of function ‘pci_free_consistent’ [-Werror=implicit-function-declaration] > drivers/media/usb/b2c2/flexcop-usb.c: In function > ‘flexcop_usb_transfer_init’: > drivers/media/usb/b2c2/flexcop-usb.c:410:2: error: implicit declaration > of function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration] > drivers/media/usb/b2c2/flexcop-usb.c:410:21: warning: assignment makes > pointer from integer without a cast [enabled by default] > cc1: some warnings being treated as errors > > Signed-off-by: Chen Gang > --- > arch/arm64/include/asm/pci.h | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) > create mode 100644 arch/arm64/include/asm/pci.h > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h > new file mode 100644 > index 000..2ed467f > --- /dev/null > +++ b/arch/arm64/include/asm/pci.h > @@ -0,0 +1,11 @@ > +#ifndef ASMARM64_PCI_H > +#define ASMARM64_PCI_H > + > +#ifdef __KERNEL__ > + > +#include > +#include > + > +#endif /* __KERNEL__ */ > + > +#endif >>> I wonder whether it makes sense to include pci-dma-compat.h in >>> asm-generic/pci.h, I don't see why one would want the generic pci.h but >>> not the generic pci-dma-compat.h (cc'ing Arnd). >> > For m32r, it also face the same issue. So I need send related patch to asm-generic instead of arm64. > For m32r, it needs generic pci.h but not the generic pci-dma-compat.h. > > I am just compiling it with allmodconfig to see whether it will can > cause issue too, if so I will send the patch for asm-generic. :-) > > And, sorry for the original reply below is incorrect. > >> I think, it will let architecture guys easier to add their own >> pci-dma-compat.h (although they still need generic pci_dma_compat.h, and >> generic pci.h, too). >> >> e.g. one architecture want include generic pci-dma-compat.h firstly, >> then define its own features in its own pci-dma-compat.h. >> >> Thanks. >> > > -- Chen Gang -- 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/2] DMA: EDMA: Add comments for A-sync case calculations
A-sync case in EDMA driver is tricky and not so obvious.
Document the reasons for the calculations and the scenarious
they are used.
Signed-off-by: Joel Fernandes
---
drivers/dma/edma.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e008ed2..a1d9f3785 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -284,8 +284,24 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
*/
if (burst == 1) {
edesc->absync = false;
+ /*
+* For the A-sync case, bcnt and ccnt are the remainder
+* and quotient respectively of the division of:
+* (sg_dma_len(sg) / acnt) by (SZ_64K -1). This is so
+* that in case bcnt over flows, we have ccnt to use.
+* Note: In A-sync tranfer only, bcntrld is used, but it
+* only applies for sg_dma_len(sg) >= SZ_64K.
+* In this case, the best way adopted is- bccnt for the
+* first frame will be the remainder below. Then for
+* every successive frame, bcnt will be SZ_64K-1. This
+* is assured as bcntrld = 0x in end of function.
+*/
ccnt = sg_dma_len(sg) / acnt / (SZ_64K - 1);
bcnt = sg_dma_len(sg) / acnt - ccnt * (SZ_64K - 1);
+ /*
+* If bcnt is non-zero, we have a remainder and hence an
+* extra frame to transfer, so increment ccnt.
+*/
if (bcnt)
ccnt++;
else
@@ -343,6 +359,12 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
edesc->pset[i].a_b_cnt = bcnt << 16 | acnt;
edesc->pset[i].ccnt = ccnt;
+ /*
+* Only time when (bcntrld) auto reload is required is for
+* A-sync case, and in this case, a requirement of reload value
+* of SZ_64K-1 only is assured. 'link' is initially set to NULL
+* and then later will be populated by edma_execute.
+*/
edesc->pset[i].link_bcntrld = 0x;
}
--
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] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
Build EDMA in by default to avoid fewer people stepping on their toes with broken DMA on drivers needing EDMA. Signed-off-by: Joel Fernandes --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index abbe319..7e00deb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -236,6 +236,7 @@ CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y CONFIG_RTC_DRV_OMAP=y CONFIG_DMADEVICES=y +CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -- 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 0/2] DMA: EDMA: Config and comments
Minor patches remaining after EDMA series was posted. First patch adds the TI_EDMA option which people can forget to add and can result in failure without any informative errors of why DMA is not working. There was a discussion on avoiding Kconfig and putting this in the defconfig instead. Second patch adds comments to the EDMA code for the calculations in the A-sync case. From my experience, this code is not-so-obvious. Hopefully this makes the life of readers of the code a little better. Joel Fernandes (2): ARM: configs: Enable TI_EDMA in omap2plus_defconfig DMA: EDMA: Add comments for A-sync case calculations arch/arm/configs/omap2plus_defconfig |1 + drivers/dma/edma.c | 22 ++ 2 files changed, 23 insertions(+) -- 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: cgroup: status-quo and userland efforts
On Wed, Jun 26, 2013 at 6:04 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 26, 2013 at 05:06:02PM -0700, Tim Hockin wrote:
>> The first assertion, as I understood, was that (eventually) cgroupfs
>> will not allow split hierarchies - that unified hierarchy would be the
>> only mode. Is that not the case?
>
> No, unified hierarchy would be an optional thing for quite a while.
>
>> The second assertion, as I understood, was that (eventually) cgroupfs
>> would not support granting access to some cgroup control files to
>> users (through chown/chmod). Is that not the case?
>
> Again, it'll be an opt-in thing. The hierarchy controller would be
> able to notice that and issue warnings if it wants to.
>
>> Hmm, so what exactly is changing then? If, as you say here, the
>> existing interfaces will keep working - what is changing?
>
> New interface is being added and new features will be added only for
> the new interface. The old one will eventually be deprecated and
> removed, but that *years* away.
OK, then what I don't know is what is the new interface? A new cgroupfs?
>> As I said, it's controlled delegated access. And we have some patches
>> that we carry to prevent some of these DoS situations.
>
> I don't know. You can probably hack around some of the most serious
> problems but the whole thing isn't built for proper delgation and
> that's not the direction the upstream kernel is headed at the moment.
>
>> I actually can not speak to the details of the default IO problem, as
>> it happened before I really got involved. But just think through it.
>> If one half of the split has 5 processes running and the other half
>> has 200, the processes in the 200 set each get FAR less spindle time
>> than those in the 5 set. That is NOT the semantic we need. We're
>> trying to offer ~equal access for users of the non-DTF class of jobs.
>>
>> This is not the tail doing the wagging. This is your assertion that
>> something should work, when it just doesn't. We have two, totally
>> orthogonal classes of applications on two totally disjoint sets of
>> resources. Conjoining them is the wrong answer.
>
> As I've said multiple times, there sure are things that you cannot
> achieve without orthogonal multiple hierarchies, but given the options
> we have at hands, compromising inside a unified hierarchy seems like
> the best trade-off. Please take a step back from the immediate detail
> and think of the general hierarchical organization of workloads. If
> DTF / non-DTF is a fundamental part of your workload classfication,
> that should go above.
DTF and CPU and cpuset all have "default" groups for some tasks (and
not others) in our world today. DTF actually has default, prio, and
"normal". I was simplifying before. I really wish it were as simple
as you think it is. But if it were, do you think I'd still be
arguing?
> I don't really understand your example anyway because you can classify
> by DTF / non-DTF first and then just propagate cpuset settings along.
> You won't lose anything that way, right?
This really doesn't scale when I have thousands of jobs running.
Being able to disable at some levels on some controllers probably
helps some, but I can't say for sure without knowing the new interface
> Again, in general, you might not be able to achieve *exactly* what
> you've been doing, but, an acceptable compromise should be possible
> and not doing so leads to complete mess.
We tried it in unified hierarchy. We had our Top People on the
problem. The best we could get was bad enough that we embarked on a
LITERAL 2 year transition to make it better.
>> > But I don't follow the conclusion here. For short term workaround,
>> > sure, but having that dictate the whole architecture decision seems
>> > completely backwards to me.
>>
>> My point is that the orthogonality of resources is intrinsic. Letting
>> "it's hard to make it work" dictate the architecture is what's
>> backwards.
>
> No, it's not "it's hard to make it work". It's more "it's
> fundamentally broken". You can't identify a resource to be belonging
> to a cgroup independent of who's looking at the resource.
What if you could ensure that for a given TID (or PID if required) in
dir X of controller C, all of the other TIDs in that cgroup were in
the same group, but maybe not the same sub-path, under every
controller? This gives you what it sounds like you wanted elsewhere -
a container abstraction.
In other words, define a container as a set of cgroups, one under each
each active controller type. A TID enters the container atomically,
joining all of the cgroups or none of the cgroups.
container C1 = { /cgroup/cpu/foo, /cgroup/memory/bar,
/cgroup/io/default/foo/bar, /cgroup/cpuset/
This is an abstraction that we maintain in userspace (more or less)
and we do actually have headaches from split hierarchies here
(handling partial failures, non-atomic joins, etc)
>> I'm not sure what "differing level of granularities" means? But that
>
Re: [PATCH V3 0/5] Drivers: scsi: storvsc
On Wed, 2013-06-26 at 12:58 +, KY Srinivasan wrote: > > > -Original Message- > > From: KY Srinivasan > > Sent: Monday, June 17, 2013 9:32 AM > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; > > h...@infradead.org; linux-s...@vger.kernel.org > > Subject: RE: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > > -Original Message- > > > From: KY Srinivasan > > > Sent: Tuesday, June 11, 2013 9:02 AM > > > To: KY Srinivasan; gre...@linuxfoundation.org; > > > linux-kernel@vger.kernel.org; > > > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; > > > h...@infradead.org; linux-s...@vger.kernel.org > > > Subject: RE: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > > > > > > -Original Message- > > > > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > > > > Sent: Tuesday, June 04, 2013 3:05 PM > > > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > > de...@linuxdriverproject.org; oher...@suse.com; > > jbottom...@parallels.com; > > > > h...@infradead.org; linux-s...@vger.kernel.org > > > > Cc: KY Srinivasan > > > > Subject: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > This set adds multi-channel support as well synthetic Fibre Channel > > > > support > > > > to storvsc. The multi-channel support depends on infrastructure in the > > VMBUS > > > > driver. Greg has already checked in the relevant patches to VMBUS. > > > > > > > > I had posted an earlier version of this patch-set that included the > > > > VMBUS > > > > related changes. I have since separated the VMBUS chages and these have > > > > already been > > > > checked in. > > > > > > > > In this version, based on comments from James, the timeout is no longer > > > > a > > > > module > > > > parameter. > > > > > > James, > > > > > > I think I have addressed all the comments that you had; if not, please > > > let me > > > know. > > > > Ping. > > James, > > Let me know if I should re-send the patches. Just FYI, my workflow involves using imap flags to tag stuff for actions and then using a set of date sorted evolution search folders to translate the flags into work queues. The search folders are by flag and thread, so a side effect of the way evolution does date ordering is that it's ordered by the most recent last, so the date it takes for thread ordering is the most recent email in the thread. Originally, I thought of this as an annyoing evolution bug because I wanted the folder ordered by date of the patch submission. However, later I came to appreciate that it meant currently actively discussed patches moved down in my workqueue automatically, so now I quite like it as a feature. It does mean, however, that the net effect of sending very frequent pings about a patch set is to cause that patch set to move down in my work queue and, unfortunately, even coming from a domain that habitually breaks threading doesn't save you because evolution helpfully has a set of heuristic rules to rethread outlook breakage. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Seungwon, I didn't get the same result..In my case, it's working fine. But as Bing's result, i will check more and share the result. Best Regards, Jaehoon Chung On 06/26/2013 10:53 AM, Seungwon Jeon wrote: > Hi Jaehoon, > Do you have the same result? > Could you share the result? > > Thanks, > Seungwon Jeon > On Tuesday, June 25 2013, Bing Zhao wrote: >>> I think the proposal on the table is to take Seungwon's patches >>> instead of mine. Assuming they solve your problems, I'm OK with that. >>> I think he was requesting testing the first of his two patches alone >>> and then both of his two patches together. >> >> Test #1: Swungwon's patch #1 alone [1] >> Test #2: Swungwon's patch #2 alone [1] >> Test #3: Swungwon's patch #1 and #2 [1] >> Test #4: Doug's original patch [2] >> >> Test #1 and #3: it doesn't work; system reboots due to kernel hung_task >> Test #2 and #4: it works; instead of hung_task driver gets CRC error (which >> is expected) >> >> Thanks, >> Bing >> >> [1] https://lkml.org/lkml/2013/4/8/316 >> [2] https://lkml.org/lkml/2013/3/15/583 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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] Transparent on-demand memory setup initialization embedded in the (GFP) buddy allocator
On Wednesday, June 26, 2013 9:30:02 PM UTC+8, Andrew Morton wrote: > > On Wed, 26 Jun 2013 11:22:48 +0200 Ingo Molnar wrote: > > > except that on 32 TB > > systems we don't spend ~2 hours initializing 8,589,934,592 page heads. > > That's about a million a second which is crazy slow - even my prehistoric desktop > is 100x faster than that. > > Where's all this time actually being spent? The complexity of a directory-lookup architecture to make the (intrinsically unscalable) cache-coherency protocol scalable gives you a ~1us roundtrip to remote NUMA nodes. Probably a lot of time is spent in some memsets, and RMW cycles which are setting page bits, which are intrinsically synchronous, so the initialising core can't get to 12 or so outstanding memory transactions. Since EFI memory ranges have a flag to state if they are zerod (which may be a fair assumption for memory on non-bootstrap processor NUMA nodes), we can probably collapse the RMWs to just writes. A normal write will require a coherency cycle, then a fetch and a writeback when it's evicted from the cache. For this purpose, non-temporal writes would eliminate the cache line fetch and give a massive increase in bandwidth. We wouldn't even need a store-fence as the initialising core is the only one online. Daniel -- Daniel J Blueman Principal Software Engineer, Numascale Asia -- 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] ARM: dts: add AM33XX MMC support
From: Matt Porter
Adds AM33XX MMC support for am335x-bone, am335x-evm, and am335x-evmsk.
Also added is the DMA binding definitions based on the generic DMA
request binding.
The HWMOD data removal was breaking MMC so some new properties like reg,
interrupt etc were added.
Changes to DTS:
Interrupt and reg added by: Joel Fernandes
Compatible added by Balaji TK
ti,needs-special-hs-handling added by Gururaja Hebbar
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
Signed-off-by: Joel Fernandes
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +-
arch/arm/boot/dts/am335x-bone.dts |7
arch/arm/boot/dts/am335x-evm.dts |7
arch/arm/boot/dts/am335x-evmsk.dts |7
arch/arm/boot/dts/am33xx.dtsi | 38
5 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..8c8908a 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+dmas: List of DMA specifiers with the controller specific format
+as described in the generic DMA client binding. A tx and rx
+specifier is required.
+dma-names: List of DMA request names. These strings correspond
+1:1 with the DMA specifiers listed in dmas. The string naming is
+to be "rx" and "tx" for RX and TX DMA requests, respectively.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +51,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5302f79..80bff9c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
@@ -136,3 +138,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..62af561 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f67c360..8904b88 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b4fda12..8ab566f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -229,6 +229,44 @@
status = "disabled";
};
+ mmc1: mmc@4806 {
+ compatible = "ti,omap4-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ ti,needs-special-hs-handling;
+ dma
[PATCH] arch: m32r: include: asm: add ioread*be() and iowrite*be()
Add generic ioread*be() and iowrite*be(), or compiling fails. The related error (with allmodconfig): drivers/ipack/ipack.c: In function ‘ipack_device_read_id’: drivers/ipack/ipack.c:376:3: error: implicit declaration of function ‘ioread16be’ [-Werror=implicit-function-declaration] Signed-off-by: Chen Gang --- arch/m32r/include/asm/io.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h index 4010f1f..9f9b609 100644 --- a/arch/m32r/include/asm/io.h +++ b/arch/m32r/include/asm/io.h @@ -164,10 +164,14 @@ static inline void _writel(unsigned long l, unsigned long addr) #define ioread8 read #define ioread16 readw +#define ioread16be(addr) __be16_to_cpu(__raw_readw(addr)) #define ioread32 readl +#define ioread32be(addr) __be32_to_cpu(__raw_readl(addr)) #define iowrite8 writeb #define iowrite16 writew +#define iowrite16be(v, addr) __raw_writew(__cpu_to_be16(v), addr) #define iowrite32 writel +#define iowrite32be(v, addr) __raw_writel(__cpu_to_be32(v), addr) #define mmiowb() -- 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 3/5] Drivers: scsi: storvsc: Implement multi-channel support
On Tue, 2013-06-04 at 12:05 -0700, K. Y. Srinivasan wrote:
> Implement multi-channel support for the storage devices.
This doesn't compile:
CC [M] drivers/scsi/storvsc_drv.o
drivers/scsi/storvsc_drv.c: In function ‘handle_sc_creation’:
drivers/scsi/storvsc_drv.c:763:35: error: ‘struct vmbus_channel’ has no
member named ‘primary_channel’
drivers/scsi/storvsc_drv.c: In function ‘handle_multichannel_storage’:
drivers/scsi/storvsc_drv.c:805:2: error: implicit declaration of
function
‘vmbus_set_sc_create_callback’ [-Werror=implicit-function-declaration]
drivers/scsi/storvsc_drv.c:812:2: error: implicit declaration of
function
‘vmbus_are_subchannels_present’ [-Werror=implicit-function-declaration]
drivers/scsi/storvsc_drv.c: In function ‘storvsc_on_channel_callback’:
drivers/scsi/storvsc_drv.c:1223:13: error: ‘struct vmbus_channel’ has no
member named ‘primary_channel’
drivers/scsi/storvsc_drv.c:1224:19: error: ‘struct vmbus_channel’ has no
member named ‘primary_channel’
drivers/scsi/storvsc_drv.c: In function ‘storvsc_do_io’:
drivers/scsi/storvsc_drv.c:1341:2: error: implicit declaration of
function
‘vmbus_get_outgoing_channel’ [-Werror=implicit-function-declaration]
drivers/scsi/storvsc_drv.c:1341:19: warning: assignment makes pointer
from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[2]: *** [drivers/scsi/storvsc_drv.o] Error 1
I assume this is a cross tree dependency? What's the relevant branch I
need?
James
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 15/15] perf, tools: Add perf stat --transaction v3
On Wed, Jun 19, 2013 at 04:46:21PM +0200, Andi Kleen wrote: > > This hard coded list isn't going to work for us on powerpc. > > > > We don't have HLE, so we won't ever have an event for el-start. > > > > I don't quite grok what the cycles-ct is about, checkpointed cycles? > > The counter is check pointed on a transaction start, and set back to > the checkpoint when an abort happens. This allows to count the cycles > wasted in aborts, when you subtract from cycles-t. OK. I'm still confused by that one sorry. In the patch you do: + else if (perf_evsel__cmp(counter, nth_evsel(T_CYCLES_IN_TX_CP))) + update_stats(&runtime_cycles_in_txcp_stats[0], count[0]); But then I don't see where you use runtime_cycles_in_txcp_stats ? > > But I don't think we have anything equivalent. > > But you have cycles-t and tx-start? We have: - cycles - cycles in transactional state - cycles spent in successful transactions So your cycles-t is "cycles in transactional state". We would calculate cycles wasted in aborts with: "cycles in transactional" - "cycles in successful transactions" Which I think is what you're describing above with cycles-ct. Does "tx-start" just count the number of transactions begun? Does it count nested transactions? We have one counter for non-nested transactions and one for nested, but I think we could just count the non-nested as "tx-start", that's probably of most interest. > > I guess the simplest option is to make it a per-arch list inside the > > perf tool? > > I'm not sure that would be acceptable to the perf maintainers. > Although I'm just guessing, I haven't heard any comments on > this patch recently. Yeah sure. Although I agree with the desire to make the perf tool work similarly across architectures, I think as we add more of these detailed analysis tools we are eventually going to come across something that can't be handled generically. But I guess we'll see. cheers -- 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] vmpressure: implement strict mode
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an application might want
to release 10% of its cache on level low, 50% on medium and 100% on
critical. To do this, an application has to register a different
eventfd for each pressure level. However, fd low is always going to
be notified and and all fds are going to be notified on level critical.
Strict mode solves this problem by strictly notifiying an eventfd
for the pressure level it registered for. This new mode is optional,
by default we still notify eventfds on higher levels too.
Signed-off-by: Luiz Capitulino
---
o v2
- Improve documentation
- Use a bit to store mode instead of a bool
- Minor changelog changes
Documentation/cgroups/memory.txt | 26 ++
mm/vmpressure.c | 26 --
2 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ddf4f93..412872b 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -791,6 +791,22 @@ way to trigger. Applications should do whatever they can
to help the
system. It might be too late to consult with vmstat or any other
statistics, so it's advisable to take an immediate action.
+Applications can also choose between two notification modes when
+registering an eventfd for memory pressure events:
+
+When in "non-strict" mode, an eventfd is notified for the specific level
+it's registered for and higher levels. For example, an eventfd registered
+for low level is also going to be notified on medium and critical levels.
+This mode makes sense for applications interested on monitoring reclaim
+activity or implementing simple load-balacing logic. The non-strict mode
+is the default notification mode.
+
+When in "strict" mode, an eventfd is strictly notified for the pressure
+level it's registered for. For example, an eventfd registered for the low
+level event is not going to be notified when memory pressure gets into
+medium or critical levels. This allows for more complex logic based on
+the actual pressure level the system is experiencing.
+
The events are propagated upward until the event is handled, i.e. the
events are not pass-through. Here is what this means: for example you have
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
@@ -807,12 +823,14 @@ register a notification, an application must:
- create an eventfd using eventfd(2);
- open memory.pressure_level;
-- write string like " "
+- write string like " [strict]"
to cgroup.event_control.
-Application will be notified through eventfd when memory pressure is at
-the specific level (or higher). Read/write operations to
-memory.pressure_level are no implemented.
+Applications will be notified through eventfd when memory pressure is at
+the specific level or higher. If strict is passed, then applications
+will only be notified when memory pressure reaches the specified level.
+
+Read/write operations to memory.pressure_level are no implemented.
Test:
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index 736a601..ba5c17e 100644
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -138,8 +138,16 @@ struct vmpressure_event {
struct eventfd_ctx *efd;
enum vmpressure_levels level;
struct list_head node;
+ unsigned int mode;
};
+#define VMPRESSURE_MODE_STRICT 1
+
+static inline bool vmpressure_mode_is_strict(const struct vmpressure_event *ev)
+{
+ return ev->mode & VMPRESSURE_MODE_STRICT;
+}
+
static bool vmpressure_event(struct vmpressure *vmpr,
unsigned long scanned, unsigned long reclaimed)
{
@@ -153,6 +161,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
list_for_each_entry(ev, &vmpr->events, node) {
if (level >= ev->level) {
+ /* strict mode ensures level == ev->level */
+ if (vmpressure_mode_is_strict(ev) && level != ev->level)
+ continue;
eventfd_signal(ev->efd, 1);
signalled = true;
}
@@ -292,7 +303,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg,
int prio)
* infrastructure, so that the notifications will be delivered to the
* @eventfd. The @args parameter is a string that denotes pressure level
* threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
- * "critical").
+ * "critical") and optionally a different operating mode (i.e. "strict")
*
* This function should not be used directly, just pass it to (struct
* cftype).register_event, and then cgroup core will handle everything by
@@ -303,22 +314,33 @@ int vmpressure_register_event(struct cgroup *cg, struct
cftype *cft,
{
struct vmpressure *vmpr = cg_to_vm
linux-next: manual merge of the pm tree with the pci tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in MAINTAINERS
between commit 15fd830dd310 ("MAINTAINERS: Add ACPI folks for
ACPI-related things under drivers/pci") from the pci tree and commit
994b942fb4eb ("ACPI: Update MAINTAINERS file to include
Documentation/acpi") from the pm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc MAINTAINERS
index 6f30491,04a5fef..000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -247,9 -242,8 +247,11 @@@ F:drivers/acpi
F:drivers/pnp/pnpacpi/
F:include/linux/acpi.h
F:include/acpi/
+F:drivers/pci/*acpi*
+F:drivers/pci/*/*acpi*
+F:drivers/pci/*/*/*acpi*
+ F:Documentation/acpi
+ F:Documentation/ABI/testing/sysfs-bus-acpi
ACPI FAN DRIVER
M:Zhang Rui
pgpCYvEe2lwZJ.pgp
Description: PGP signature
Re: frequent softlockups with 3.10rc6.
On Wed, 2013-06-26 at 16:00 -0400, Dave Jones wrote:
> On Wed, Jun 26, 2013 at 03:52:15PM -0400, Steven Rostedt wrote:
> Yeah, that's what I meant by "this patch".
> To reduce ambiguity, I mean the one below.. There wasn't another patch
> that I missed right ?
>
On other patch, but I've found issues with the patch I sent you. This
seems to pass my initial tests, and I'm working to get this into 3.11.
This is still a beta patch.
-- Steve
Index: linux-trace.git/kernel/trace/trace.c
===
--- linux-trace.git.orig/kernel/trace/trace.c
+++ linux-trace.git/kernel/trace/trace.c
@@ -217,7 +217,13 @@ cycle_t ftrace_now(int cpu)
int tracing_is_enabled(void)
{
- return tracing_is_on();
+ /*
+* For quick access (irqsoff uses this in fast path), just
+* return the mirror variable of the state of the ring buffer.
+* It's a little racy, but we don't really care.
+*/
+ smp_rmb();
+ return !global_trace.buffer_disabled;
}
/*
@@ -330,6 +336,23 @@ unsigned long trace_flags = TRACE_ITER_P
TRACE_ITER_GRAPH_TIME | TRACE_ITER_RECORD_CMD | TRACE_ITER_OVERWRITE |
TRACE_ITER_IRQ_INFO | TRACE_ITER_MARKERS | TRACE_ITER_FUNCTION;
+void tracer_tracing_on(struct trace_array *tr)
+{
+ if (tr->trace_buffer.buffer)
+ ring_buffer_record_on(tr->trace_buffer.buffer);
+ /*
+* This flag is looked at when buffers haven't been allocated
+* yet, or by some tracers (like irqsoff), that just want to
+* know if the ring buffer has been disabled, but it can handle
+* races of where it gets disabled but we still do a record.
+* As the check is in the fast path of the tracers, it is more
+* important to be fast than accurate.
+*/
+ tr->buffer_disabled = 0;
+ /* Make the flag seen by readers */
+ smp_wmb();
+}
+
/**
* tracing_on - enable tracing buffers
*
@@ -338,15 +361,7 @@ unsigned long trace_flags = TRACE_ITER_P
*/
void tracing_on(void)
{
- if (global_trace.trace_buffer.buffer)
- ring_buffer_record_on(global_trace.trace_buffer.buffer);
- /*
-* This flag is only looked at when buffers haven't been
-* allocated yet. We don't really care about the race
-* between setting this flag and actually turning
-* on the buffer.
-*/
- global_trace.buffer_disabled = 0;
+ tracer_tracing_on(&global_trace);
}
EXPORT_SYMBOL_GPL(tracing_on);
@@ -540,6 +555,23 @@ void tracing_snapshot_alloc(void)
EXPORT_SYMBOL_GPL(tracing_snapshot_alloc);
#endif /* CONFIG_TRACER_SNAPSHOT */
+void tracer_tracing_off(struct trace_array *tr)
+{
+ if (tr->trace_buffer.buffer)
+ ring_buffer_record_off(tr->trace_buffer.buffer);
+ /*
+* This flag is looked at when buffers haven't been allocated
+* yet, or by some tracers (like irqsoff), that just want to
+* know if the ring buffer has been disabled, but it can handle
+* races of where it gets disabled but we still do a record.
+* As the check is in the fast path of the tracers, it is more
+* important to be fast than accurate.
+*/
+ tr->buffer_disabled = 1;
+ /* Make the flag seen by readers */
+ smp_wmb();
+}
+
/**
* tracing_off - turn off tracing buffers
*
@@ -550,26 +582,23 @@ EXPORT_SYMBOL_GPL(tracing_snapshot_alloc
*/
void tracing_off(void)
{
- if (global_trace.trace_buffer.buffer)
- ring_buffer_record_off(global_trace.trace_buffer.buffer);
- /*
-* This flag is only looked at when buffers haven't been
-* allocated yet. We don't really care about the race
-* between setting this flag and actually turning
-* on the buffer.
-*/
- global_trace.buffer_disabled = 1;
+ tracer_tracing_off(&global_trace);
}
EXPORT_SYMBOL_GPL(tracing_off);
+int tracer_tracing_is_on(struct trace_array *tr)
+{
+ if (tr->trace_buffer.buffer)
+ return ring_buffer_record_is_on(tr->trace_buffer.buffer);
+ return !tr->buffer_disabled;
+}
+
/**
* tracing_is_on - show state of ring buffers enabled
*/
int tracing_is_on(void)
{
- if (global_trace.trace_buffer.buffer)
- return
ring_buffer_record_is_on(global_trace.trace_buffer.buffer);
- return !global_trace.buffer_disabled;
+ return tracer_tracing_is_on(&global_trace);
}
EXPORT_SYMBOL_GPL(tracing_is_on);
@@ -3939,7 +3968,7 @@ static int tracing_wait_pipe(struct file
*
* iter->pos will be 0 if we haven't read anything.
*/
- if (!tracing_is_enabled() && iter->pos)
+ if (!tracing_is_on() && iter->pos)
break;
}
@@ -5612,15 +5641,10 @@ rb_simple_read(struct file *filp, char _
size_t cnt, loff_t *ppos)
{
[PATCH] arch: m32r: include: asm: use 'readb' instead of 'read'
Need use 'readb' instead of 'read', it is a typo issue which found by compiler. The related error (with allmodconfig): drivers/i2c/busses/i2c-ocores.c: In function ‘oc_getreg_8’: drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of function ‘read’ [-Werror=implicit-function-declaration] Signed-off-by: Chen Gang --- arch/m32r/include/asm/io.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h index 4010f1f..343ae4c 100644 --- a/arch/m32r/include/asm/io.h +++ b/arch/m32r/include/asm/io.h @@ -162,7 +162,7 @@ static inline void _writel(unsigned long l, unsigned long addr) #define __raw_writew writew #define __raw_writel writel -#define ioread8 read +#define ioread8 readb #define ioread16 readw #define ioread32 readl #define iowrite8 writeb -- 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/
kernel panic in skb_copy_bits
Hi, When we do fail over test with iscsi + multipath by reset the switches on OVM(2.6.39) we hit the panic: BUG: unable to handle kernel paging request at 88006d9e8d48 IP: [] memcpy+0xb/0x120 PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0 Oops: [#1] SMP CPU 7 Modules linked in: dm_nfs tun nfs fscache auth_rpcgss nfs_acl xen_blkback xen_netback xen_gntdev xen_evtchn lockd sunrpc bridge stp llc bonding be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 mdio dm_round_robin dm_multipath libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ixgbe dca sr_mod cdrom bnx2 radeon ttm drm_kms_helper drm snd_seq_dummy i2c_algo_bit i2c_core snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss serio_raw snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt pcspkr iTCO_vendor_support pata_acpi dcdbas i5k_amb ata_generic hwmon floppy ghes i5000_edac edac_core hed dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage lpfc scsi_transport_fc scsi_tgt ata_piix sg shpchp mptsas mptscsih mptbase scsi_transport_sas sd_mod crc_t10dif ext3 j! bd mbcache Pid: 0, comm: swapper Tainted: GW 2.6.39-300.32.1.el5uek #1 Dell Inc. PowerEdge 2950/0DP246 RIP: e030:[] [] memcpy+0xb/0x120 RSP: e02b:8801003c3d58 EFLAGS: 00010246 RAX: 880076b9e280 RBX: 8800714d2c00 RCX: 0057 RDX: RSI: 88006d9e8d48 RDI: 880076b9e280 RBP: 8801003c3dc0 R08: 000bf723 R09: R10: R11: 000a R12: 0034 R13: 0034 R14: 02b8 R15: 05a8 FS: 7fc1e852a6e0() GS:8801003c() knlGS: CS: e033 DS: 002b ES: 002b CR0: 8005003b CR2: 88006d9e8d48 CR3: 6370b000 CR4: 2660 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 0, threadinfo 880077ac, task 880077abe240) Stack: 8142db21 880076b9e280 8800637097f0 02ec 02b8 880077ac 8800637097f0 880066c9a7c0 fdb4 024c Call Trace: [] ? skb_copy_bits+0x1c1/0x2e0 [] skb_copy+0xf3/0x120 [] neigh_timer_handler+0x1ac/0x350 [] ? account_idle_ticks+0xe/0x10 [] ? neigh_alloc+0x180/0x180 [] call_timer_fn+0x4a/0x110 [] ? neigh_alloc+0x180/0x180 [] run_timer_softirq+0x13a/0x220 [] __do_softirq+0xb9/0x1d0 [] ? handle_percpu_irq+0x48/0x70 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0xab/0xc0 [] xen_evtchn_do_upcall+0x35/0x50 [] xen_do_hypervisor_callback+0x1e/0x30 [] ? xen_hypercall_sched_op+0xa/0x20 [] ? xen_hypercall_sched_op+0xa/0x20 [] ? xen_safe_halt+0x10/0x20 [] ? default_idle+0x5b/0x170 [] ? cpu_idle+0xc6/0xf0 [] ? xen_irq_enable_direct_reloc+0x4/0x4 [] ? cpu_bringup_and_idle+0xe/0x10 Code: 01 c6 43 4c 04 19 c0 4c 8b 65 f0 4c 8b 6d f8 83 e0 fc 83 c0 08 88 43 4d 48 8b 5d e8 c9 c3 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c RIP [] memcpy+0xb/0x120 RSP CR2: 88006d9e8d48 Reviewed vmcore I found the skb->users is 1 at the moment, checked network neighbour history I found skb_get() be replaced by skb_copy by commit 7e36763b2c: commit 7e36763b2c204d59de4e88087f84a2c0c8421f25 Author: Frank Blaschka Date: Mon Mar 3 12:16:04 2008 -0800 [NET]: Fix race in generic address resolution. neigh_update sends skb from neigh->arp_queue while neigh_timer_handler has increased skbs refcount and calls solicit with the skb. neigh_timer_handler should not increase skbs refcount but make a copy of the skb and do solicit with the copy. Signed-off-by: Frank Blaschka Signed-off-by: David S. Miller So can you please give some details of the race? per vmcore seems like the skb data be freed, I suspected skb_get() lost at somewhere? I reverted above commit the panic not occurred during our testing. Any input will appreciate! Best Regards, Joe -- 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] arch: s390: kernel: scan all present cpu forcely.
The architectures which may support 'hotpluggable', can scan all cpus
during subsys_initcall(). the upper caller will skip the return value.
It also can initialize hotpluggable flag of all cpus in time, no matter
whether any cpus fail or not.
Signed-off-by: Chen Gang
---
arch/s390/kernel/smp.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index d386c4e..75a118f 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -1064,8 +1064,9 @@ static int __init s390_smp_init(void)
#endif
for_each_present_cpu(cpu) {
rc = smp_add_present_cpu(cpu);
- if (rc)
- return rc;
+ if (unlikely(rc))
+ printk(KERN_WARNING "%s: add cpu %d failed (%d)\n",
+ __func__, cpu, rc);
}
return 0;
}
--
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] ARC: [TB10x] Updates for irqchip driver
On 06/26/2013 07:31 PM, Christian Ruppert wrote: > Device tree and Kconfig updates for irqchip driver. > > Signed-off-by: Christian Ruppert Applied to ARC for-next Thx, -Vineet -- 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] arch: m32r: include: asm: add generic ioremap_wc() definition
Add generic ioremap_wc() definition, or compiling failed. The related error (with allmodconfig): drivers/gpu/drm/drm_bufs.c: In function ‘drm_addmap_core’: drivers/gpu/drm/drm_bufs.c:219:5: error: implicit declaration of function ‘ioremap_wc’ [-Werror=implicit-function-declaration] drivers/gpu/drm/drm_bufs.c:219:17: warning: assignment makes pointer from integer without a cast [enabled by default] Signed-off-by: Chen Gang --- arch/m32r/include/asm/io.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h index 4010f1f..f9f4fb6 100644 --- a/arch/m32r/include/asm/io.h +++ b/arch/m32r/include/asm/io.h @@ -67,6 +67,7 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size) extern void iounmap(volatile void __iomem *addr); #define ioremap_nocache(off,size) ioremap(off,size) +#define ioremap_wc ioremap_nocache /* * IO bus memory addresses are also 1:1 with the physical address -- 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: frequent softlockups with 3.10rc6.
Hello,
On Wed, Jun 26, 2013 at 06:06:45PM -0700, Eric W. Biederman wrote:
> Just based on the last trace and your observation that it seems to be
> vfs/block layer related I am going to mildly suggest that Jens and Tejun
> might have a clue. Tejun made a transformation of the threads used for
> writeback from a custom thread pool to the generic mechanism. So it
> seems worth asking the question could it have been in Jens block merge
> of 4de13d7aa8f4d02f4dc99d4609575659f92b3c5a.
If workqueue was suffering deadlock or starvation, it'd lock up in a
lot more boring places, unless it's somehow completely messing up blk
softirq completion logic.
Given the wide variety of places, it's likely something lower level.
Maybe something is raising an interrupt and then its softirq raises it
again right away so that it evades the screaming irq detection but
still live-locks the CPU? It'd definitely be interesting to watch the
interrupt and softirq counters. Something like the following may
help.
Thanks.
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 05039e3..21d4e82 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -261,6 +261,49 @@ static void watchdog_interrupt_count(void)
static int watchdog_nmi_enable(unsigned int cpu);
static void watchdog_nmi_disable(unsigned int cpu);
+#include
+#include
+#include
+static void dump_irqs(void)
+{
+ static u64 hirq_sums[NR_IRQS];
+ static u64 sirq_sums[NR_SOFTIRQS];
+ int i, cpu;
+
+ for (i = 0; i < nr_irqs; i++) {
+ struct irq_desc *desc = irq_to_desc(i);
+ u64 sum = 0;
+
+ if (!desc)
+ continue;
+
+ for_each_online_cpu(cpu)
+ sum += kstat_irqs_cpu(i, cpu);
+ if (sum == hirq_sums[i])
+ continue;
+
+ printk("XXX HIRQ %2d %8s : sum_delta=%8llu on_this_cpu=%8u\n",
+ i, desc->action ? desc->action->name : "",
+ sum - hirq_sums[i],
+ kstat_irqs_cpu(i, smp_processor_id()));
+ hirq_sums[i] = sum;
+ }
+
+ for (i = 0; i < NR_SOFTIRQS; i++) {
+ u64 sum = 0;
+
+ for_each_online_cpu(cpu)
+ sum += kstat_softirqs_cpu(i, cpu);
+ if (sum == sirq_sums[i])
+ continue;
+
+ printk("XXX SIRQ %2d %8s : sum_delta=%8llu on_this_cpu=%8u\n",
+ i, softirq_to_name[i], sum - sirq_sums[i],
+ kstat_softirqs_cpu(i, smp_processor_id()));
+ sirq_sums[i] = sum;
+ }
+}
+
/* watchdog kicker functions */
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
{
@@ -301,6 +344,8 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
*/
duration = is_softlockup(touch_ts);
if (unlikely(duration)) {
+ static int warned_on_cpu = -1;
+
/*
* If a virtual machine is stopped by the host it can look to
* the watchdog like a soft lockup, check to see if the host
@@ -309,10 +354,14 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
if (kvm_check_and_clear_guest_paused())
return HRTIMER_RESTART;
- /* only warn once */
- if (__this_cpu_read(soft_watchdog_warn) == true)
+ /* let's follow the first cpu */
+ if (warned_on_cpu >= 0 && warned_on_cpu != smp_processor_id())
return HRTIMER_RESTART;
+ /* only warn once */
+ //if (__this_cpu_read(soft_watchdog_warn) == true)
+ // return HRTIMER_RESTART;
+
printk(KERN_EMERG "BUG: soft lockup - CPU#%d stuck for %us!
[%s:%d]\n",
smp_processor_id(), duration,
current->comm, task_pid_nr(current));
@@ -323,6 +372,8 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
else
dump_stack();
+ dump_irqs();
+
if (softlockup_panic)
panic("softlockup: hung tasks");
__this_cpu_write(soft_watchdog_warn, true);
--
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] TTY: memory leakage in tty_buffer_find()
On Wed, 2013-06-26 at 08:43 -0400, Peter Hurley wrote:
> On 06/26/2013 04:51 AM, channing wrote:
> >
> > In tty_buffer_find(), it scans all tty buffers in
> > free buffer queue, if it finds matched one,
> > tty->buf.free will point to matched one's next buffer,
> > so tty buffers that ahead of matched one are removed
> > from free queue, they will never be used but they
> > are not released, then memory leak happen.
>
> Actually, the whole scan loop is wrong: only tty buffers of
> size 256 are added to the free list.
>
Agree that currently all tty buffers of free list are with size
of 256, but are we sure that the scan loop in tty_buffer_find()
is wrong and should abandon? From the purpose of tty_buffer_find(),
I understand it shall scan the free list, but now it doesn't make
sense because tty_buffer_free() makes all the free list buffers
with size of 256:
tty_buffer_free()
{
if (b->size >= 512)
kfree(b);
}
I don't know why it's 512? looks like a hard configuration?
Can we make it configurable instead of a fixed value?
I understand, although no memory leak, there is logic mess between
tty_buffer_find() and tty_buffer_free(), either one shall make
change to keep accordance?
which one to make change might depends on original purpose of
creating the free list. I tried to find the history of tty_buffer_free(),
but "512" is here since 2.6.32.61, I didn't find older version.
> So this can't leak because a buffer will never be found
> mid-list.
>
> Greg has a patch series from me that reduces this but it's not
> yet in next.
>
> Regards,
> Peter Hurley
>
--
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/
