Re: sem_otime trashing
On Sat, 2013-06-01 at 21:02 +0200, Manfred Spraul wrote: > Hi Rik, > > I finally managed to get EFI boot, i.e. I'm now able to test on my i3 > (2core+HT). > > With semscale (i.e.: just overhead, perform semop=0 operations), the > scalability from 1 to 2 cores is good, but not linear: > # semscale 10 | grep "interleave 2" > > Cpus 1, interleave 2 delay 0: 35502103 in 10 secs > > Cpus 2, interleave 2 delay 0: 53990954 in 10 secs > --- > +53% when adding the 2nd core > (interleave 2 to force to use different cores) > > Did you consider moving sem_otime into the individual semaphores? > I did that (gross patch attached), and the performance is significantly > better: > > # semscale 10 | grep "interleave 2" > Cpus 1, interleave 2 delay 0: 35585634 in 10 secs > Cpus 2, interleave 2 delay 0: 70410230 in 10 secs > --- > +99% scalability when adding the 2nd core > > Unfortunately I won't be able to read my mails next week, but the effect > was too significant not to share it immediately. 64 core box. Previous numbers: vogelweide:/abuild/mike/:[0]# uname -r 3.8.13-rt9-rtm vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64 cpus 64, threads: 256, semaphores: 64, test duration: 30 secs total operations: 33553800, ops/sec 1118460 New numbers: vogelweide:/abuild/mike/:[0]# !./semop-multi ./semop-multi 256 64 cpus 64, threads: 256, semaphores: 64, test duration: 30 secs total operations: 129474934, ops/sec 4315831 But, box rcu stalled on me. It's looking like the scalability patches are a bit racy rcu wise in an -rt kernel (oh dear). So, build as plain old PREEMPT again, eliminate -rt funnies. Previous numbers: vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64 cpus 64, threads: 256, semaphores: 64, test duration: 30 secs total operations: 22053968, ops/sec 735132 vogelweide:/abuild/mike/:[0]# ./osim 64 256 100 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 3907 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 1.858765 seconds for 1000192 loops per loop execution time: 1.858 usec New numbers: vogelweide:/abuild/mike/:[0]# !./semop ./semop-multi 256 64 cpus 64, threads: 256, semaphores: 64, test duration: 30 secs total operations: 45521478, ops/sec 1517382 vogelweide:/abuild/mike/:[0]# !./osim ./osim 64 256 100 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 3907 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 0.350682 seconds for 1000192 loops per loop execution time: 0.350 usec (1.8->0.3?.. box, you ain't a race horse, you're a plow horse) vogelweide:/abuild/mike/:[0]# ./osim 64 256 100 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 3907 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 0.276405 seconds for 1000192 loops per loop execution time: 0.276 usec vogelweide:/abuild/mike/:[0]# ./osim 64 256 100 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 3907 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 0.370041 seconds for 1000192 loops per loop execution time: 0.369 usec vogelweide:/abuild/mike/:[0]# ./osim 64 256 100 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 3907 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 0.502396 seconds for 1000192 loops per loop execution time: 0.502 usec (runtime) vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 39063 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 3.354423 seconds for 1128 loops per loop execution time: 0.335 usec vogelweide:/abuild/mike/:[0]# ./osim 64 256 1 0 0 osim osim: using a semaphore array with 64 semaphores. osim: using 256 tasks. osim: each thread loops 390625 times osim: each thread busyloops 0 loops outside and 0 loops inside. total execution time: 41.180479 seconds for 1 loops per loop execution time: 0.411 usec Box likes your idea. -- 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] video: simplefb: add mode parsing function
On 05/31/2013 11:12 PM, Olof Johansson wrote: > On Mon, May 27, 2013 at 10:13:09PM -0600, Stephen Warren wrote: >> On 05/26/2013 09:53 PM, Alexandre Courbot wrote: >>> The naming scheme of simplefb's mode is precise enough to allow building >>> the mode structure from it instead of using a static list of modes. This >>> patch introduces a function that does this. In case exotic modes that >>> cannot be represented from their name alone are needed, the static list >>> of modes is still available as a backup. ... >> As such, we should either: >> >> a) Just add new entries into the format array that already exists in the >> driver. Given David's response, this might be simplest. > > I think so too. Is this even needed? Do we have any users of the newer formats > or is it just someone trying to feature-creep this driver to make the "simple" > part of the name inaccurate? :) Alex is working on board support for a new NVIDIA board, where IIRC the bootloader sets up some 32-bit ARGB format for the panel. -- 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] video: simplefb: add mode parsing function
On Sat, Jun 1, 2013 at 10:07 PM, Stephen Warren wrote: > On 05/31/2013 11:12 PM, Olof Johansson wrote: >> On Mon, May 27, 2013 at 10:13:09PM -0600, Stephen Warren wrote: >>> On 05/26/2013 09:53 PM, Alexandre Courbot wrote: The naming scheme of simplefb's mode is precise enough to allow building the mode structure from it instead of using a static list of modes. This patch introduces a function that does this. In case exotic modes that cannot be represented from their name alone are needed, the static list of modes is still available as a backup. > ... >>> As such, we should either: >>> >>> a) Just add new entries into the format array that already exists in the >>> driver. Given David's response, this might be simplest. >> >> I think so too. Is this even needed? Do we have any users of the newer >> formats >> or is it just someone trying to feature-creep this driver to make the >> "simple" >> part of the name inaccurate? :) > > Alex is working on board support for a new NVIDIA board, where IIRC the > bootloader sets up some 32-bit ARGB format for the panel. Ah, ok. Let's just implement that one format too then. :) -Olof -- 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] perf gtk/hists: Display callchain overhead also
Hi Ingo, On Tue, May 28, 2013 at 5:48 PM, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > >> Em Wed, May 22, 2013 at 05:27:36PM +0900, Namhyung Kim escreveu: >> > From: Namhyung Kim >> > >> > Add a new column for showing callchain overhead. I feel like it's >> > more natural than having those overhead next to a first child in a >> > same column. >> >> Callchains in GTK, great! Some observations tho: >> >> All those leaves with 0.00% looks ugly/not needed, right? >> >> I took a screenshot and put at: >> >> http://vger.kernel.org/~acme/perf-gtk-callchains.png > > Looks really nice! Thanks! :) > > I'm wondering, would it be hard to add alternating lightgrey+white > background colors to make the entries striped and for the horizontal > structure to thus stand out better? > > The 'qgit' tool does that for example, to alternate git commit log > entries. > > (Extra points for striping only where the line actually begins.) It should be easy, I'll add 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/
Re: [PATCH] netdev: Cocci spatch "ptr_ret.spatch"
From: Thomas Meyer Date: Sat, 01 Jun 2013 11:59:11 +0200 > > Signed-off-by: Thomas Meyer This obscure reference to the cocci path you used to find/fix this problem is insufficient in detail for a commit log message. You must explain exactly what the problem is, and how you fixed it, in full sentences. You must make your commit header lin subject more appropriate as well. -- 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 1/3] PCI/AER: Fix incorrect return from aer_hest_parse()
[+cc Bob for ACPI HEST spec questions]
On Thu, May 30, 2013 at 8:39 AM, Betty Dall wrote:
> The function aer_hest_parse() is called to determine if the given
> PCI device is firmware first or not. The code loops through each
> section of the HEST table to look for a match. The bug is that
> the function always returns whether the last HEST section is firmware
> first. The fix stops the iteration once the info.firmware_first
> variable is set. This is similar to how the function aer_hest_parse_aff()
> stops the iteration.
>
> Signed-off-by: Betty Dall
> ---
>
> drivers/pci/pcie/aer/aerdrv_acpi.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/drivers/pci/pcie/aer/aerdrv_acpi.c
> b/drivers/pci/pcie/aer/aerdrv_acpi.c
> index 5194a7d..39b8671 100644
> --- a/drivers/pci/pcie/aer/aerdrv_acpi.c
> +++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
> @@ -42,6 +42,9 @@ static int aer_hest_parse(struct acpi_hest_header
> *hest_hdr, void *data)
> u8 bridge = 0;
> int ff = 0;
>
> + if (info->firmware_first)
> + return 0;
> +
> switch (hest_hdr->type) {
> case ACPI_HEST_TYPE_AER_ROOT_PORT:
> pcie_type = PCI_EXP_TYPE_ROOT_PORT;
Not related directly to your patch, Betty, but I can't figure out why
the ACPI spec defines the HEST structures for PCIe as it does. I'm
looking at ACPI 5.0, sec 18.3.2.3 - 18.3.2.5.
1) The PCIe Root Port, PCIe Device, and PCIe/PCI-X Bridge structures
all include Bus, Device, and Function fields. But there's no Segment.
The current Linux code (hest_match_pci()) assumes HEST records can
only apply to PCI domain 0. Is Linux missing something, or is the
HEST really this limited?
2) Doesn't the fact that the HEST structures include a bus number mean
that the OS cannot reassign bus numbers? I guess maybe we could still
reassign them if we kept track of the mapping back to the original
values.
3) It's interesting that the only choices seem to be "global" or "list
every device." There's no "apply to this device and the subtree under
it," so I guess if you want HEST to apply to hot-added devices,
"global" is the only thing that makes sense?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] frontswap: fix incorrect zeroing and allocation size for frontswap_map
The bitmap accessed by bitops must have enough size to hold the required
numbers of bits rounded up to a multiple of BITS_PER_LONG. And the bitmap
must not be zeroed by memset() if the number of bits cleared is not
a multiple of BITS_PER_LONG.
This fixes incorrect zeroing and allocation size for frontswap_map.
The incorrect zeroing part doesn't cause any problem because
frontswap_map is freed just after zeroing. But the wrongly calculated
allocation size may cause the problem.
For 32bit systems, the allocation size of frontswap_map is about twice as
large as required size. For 64bit systems, the allocation size is smaller
than requeired if the number of bits is not a multiple of BITS_PER_LONG.
Signed-off-by: Akinobu Mita
Cc: Konrad Rzeszutek Wilk
---
mm/frontswap.c | 2 +-
mm/swapfile.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/frontswap.c b/mm/frontswap.c
index 538367e..1b24bdc 100644
--- a/mm/frontswap.c
+++ b/mm/frontswap.c
@@ -319,7 +319,7 @@ void __frontswap_invalidate_area(unsigned type)
return;
frontswap_ops->invalidate_area(type);
atomic_set(>frontswap_pages, 0);
- memset(sis->frontswap_map, 0, sis->max / sizeof(long));
+ bitmap_zero(sis->frontswap_map, sis->max);
}
clear_bit(type, need_init);
}
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 6c340d9..746af55b 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2116,7 +2116,7 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile,
int, swap_flags)
}
/* frontswap enabled? set up bit-per-page map for frontswap */
if (frontswap_enabled)
- frontswap_map = vzalloc(maxpages / sizeof(long));
+ frontswap_map = vzalloc(BITS_TO_LONGS(maxpages) * sizeof(long));
if (p->bdev) {
if (blk_queue_nonrot(bdev_get_queue(p->bdev))) {
--
1.8.1.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] usb: musb: use the new %pa format specifier for dma_addr_t
On Sun, 2013-06-02 at 01:06 +0200, Emil Goode wrote:
> Maybe there should be another format specifier %da and Randy's
> clarifying comment
maybe %pad but I think the whole thing isn't much necessary.
It seems there are a grand total of 3 uses of %pa today.
Maybe:
---
Documentation/printk-formats.txt | 7 +++
lib/vsprintf.c | 19 +++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 3af5ae6..fa48403 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -63,6 +63,13 @@ Physical addresses:
resource_size_t) which can vary based on build options, regardless of
the width of the CPU data path. Passed by reference.
+dma_addr_t addresses:
+
+ %pad0x01234567 or 0x0123456789abcdef
+
+ For printing a dma_addr_t type which can vary based on build options,
+ regardless of the width of the CPU data path. Passed by reference.
+
Raw buffer as a hex string:
%*ph00 01 02 ... 3f
%*phC 00:01:02: ... :3f
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7d84676..b6b8390 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1039,6 +1039,7 @@ int kptr_restrict __read_mostly;
*The maximum supported length is 64 bytes of the input. Consider
*to use print_hex_dump() for the larger input.
* - 'a' For a phys_addr_t type and its derivative types (passed by reference)
+ * - 'ad' For a dma_addr_t type
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -1129,12 +1130,22 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr,
return netdev_feature_string(buf, end, ptr, spec);
}
break;
- case 'a':
+ case 'a': {
+ unsigned long long val;
spec.flags |= SPECIAL | SMALL | ZEROPAD;
- spec.field_width = sizeof(phys_addr_t) * 2 + 2;
spec.base = 16;
- return number(buf, end,
- (unsigned long long) *((phys_addr_t *)ptr), spec);
+ switch (fmt[1]) {
+ case 'd':
+ spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+ val = (unsigned long long)*((dma_addr_t *)ptr);
+ break;
+ default:
+ spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+ val = (unsigned long long)*((phys_addr_t *)ptr);
+ break;
+ }
+ return number(buf, end, val, spec);
+ }
}
spec.flags |= SMALL;
if (spec.field_width == -1) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] backlight: Convert from Legacy pm ops to dev_pm_ops
Convert drivers/video/backlight/class to use dev_pm_ops for power
management and remove Legacy PM ops hooks. With this change, backlight
class registers suspend/resume callbacks via class->pm (dev_pm_ops)
instead of Legacy class->suspend/resume. When __device_suspend() runs
call-backs, it will find class->pm ops for the backlight class.
Signed-off-by: Shuah Khan
Cc: Shuah Khan
---
v2: Updated changelog to correct device class.
v3: Updated changelog to correct device class.
drivers/video/backlight/backlight.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index c74e7aa..0ffb251 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct
device *dev,
static struct class *backlight_class;
-static int backlight_suspend(struct device *dev, pm_message_t state)
+static int backlight_suspend(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
+backlight_resume);
+
static void bl_device_release(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
}
backlight_class->dev_attrs = bl_device_attributes;
- backlight_class->suspend = backlight_suspend;
- backlight_class->resume = backlight_resume;
+ backlight_class->pm = _class_dev_pm_ops;
return 0;
}
--
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] usb: musb: use the new %pa format specifier for dma_addr_t
Hello Joe and Randy, Maybe there should be another format specifier %da and Randy's clarifying comment can be added there to the documentation? Best regards, Emil Goode On Sat, Jun 01, 2013 at 03:16:00PM -0700, Joe Perches wrote: > On Sat, 2013-06-01 at 14:56 -0700, Randy Dunlap wrote: > > It's a bit of a shame that this > > comment was deleted from include/asm-generic/types.h in commit > > 3e50594e8e72932ad4cfcb0b3cbdf58fc3bce416: > > > > -/* > > - * DMA addresses may be very different from physical addresses > > - * and pointers. i386 and powerpc may have 64 bit DMA on 32 bit > > - * systems, while sparc64 uses 32 bit DMA addresses for 64 bit > > - * physical addresses. > > - * This default defines dma_addr_t to have the same size as > > - * phys_addr_t, which is the most common way. > > - * Do not define the dma64_addr_t type, which never really > > - * worked. > > - */ > > Hey Randy. > > You could always put it back. > > -- 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: musb: Fix format specifier warning
On Sat, Jun 1, 2013 at 8:11 PM, Emil Goode wrote: > Thank's for your pointers. > I will send a patch that applies on top of Felipe's patch. I guess there is not much sense to do that since Felipe applied your patch already. Just keep in mind the hint for future changes. -- With Best Regards, Andy Shevchenko -- 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] cw1200: fix some obvious mistakes
I got compile errors with the cw1200, which has lead me to take a
closer look. It seems the driver still has a number of issues,
and this addresses some of them and marks others as FIXME:
* The cw1200_sagrad.c file should not be there, hardcoding
hardware configuration in .c files has been obsolete since
Linux-2.4, so we should just remove it. Most of that file
was already commented out since it does not compile.
* Move the parts of cw1200_sagrad.c that actually got used into
cw1200_sdio.c, because it doesn't build otherwise.
* Make the platform_data for the sdio driver private to
cw1200_sdio.c. The platform that was referenced here is
going to use device tree based probing only in the future,
which means the platform data has to go away anyway.
* Move the platform_data for the spi driver to
include/linux/platform_data/net-cw1200.h where all other
drivers have their platform_data.
* Add comments about passing GPIO numbers in platform_data:
You should not use IORESOURCE_IO, which is for legacy ISA
I/O ports on PCs, not for GPIOs.
It may actually be easier to remove the sdio driver entirely,
since it clearly doesn't work and requires a lot of cleanup.
Signed-off-by: Arnd Bergmann
Cc: Solomon Peachy
Cc: John W. Linville
Cc: Wei Yongjun
Cc: Dmitry Tarnyagin
Cc: Ajitpal Singh
Cc: linux-wirel...@vger.kernel.org
---
drivers/net/wireless/cw1200/Kconfig| 8 --
drivers/net/wireless/cw1200/Makefile | 2 -
drivers/net/wireless/cw1200/cw1200_sagrad.c| 145 -
drivers/net/wireless/cw1200/cw1200_sdio.c | 72 --
drivers/net/wireless/cw1200/cw1200_spi.c | 2 +-
.../net-cw1200.h} | 20 +--
6 files changed, 62 insertions(+), 187 deletions(-)
delete mode 100644 drivers/net/wireless/cw1200/cw1200_sagrad.c
rename include/linux/{cw1200_platform.h => platform_data/net-cw1200.h} (53%)
diff --git a/drivers/net/wireless/cw1200/Kconfig
b/drivers/net/wireless/cw1200/Kconfig
index 13e3611..c3142d4 100644
--- a/drivers/net/wireless/cw1200/Kconfig
+++ b/drivers/net/wireless/cw1200/Kconfig
@@ -20,14 +20,6 @@ config CW1200_WLAN_SPI
help
Enables support for the CW1200 connected via a SPI bus.
-config CW1200_WLAN_SAGRAD
- tristate "Support Sagrad SG901-1091/1098 modules"
- depends on CW1200_WLAN_SDIO
- help
- This provides the platform data glue to support the
- Sagrad SG901-1091/1098 modules in their standard SDIO EVK.
- It also includes example SPI platform data.
-
menu "Driver debug features"
depends on CW1200 && DEBUG_FS
diff --git a/drivers/net/wireless/cw1200/Makefile
b/drivers/net/wireless/cw1200/Makefile
index 1aa3682..bc6cbf9 100644
--- a/drivers/net/wireless/cw1200/Makefile
+++ b/drivers/net/wireless/cw1200/Makefile
@@ -16,9 +16,7 @@ cw1200_core-$(CONFIG_PM) += pm.o
cw1200_wlan_sdio-y := cw1200_sdio.o
cw1200_wlan_spi-y := cw1200_spi.o
-cw1200_wlan_sagrad-y := cw1200_sagrad.o
obj-$(CONFIG_CW1200) += cw1200_core.o
obj-$(CONFIG_CW1200_WLAN_SDIO) += cw1200_wlan_sdio.o
obj-$(CONFIG_CW1200_WLAN_SPI) += cw1200_wlan_spi.o
-obj-$(CONFIG_CW1200_WLAN_SAGRAD) += cw1200_wlan_sagrad.o
diff --git a/drivers/net/wireless/cw1200/cw1200_sagrad.c
b/drivers/net/wireless/cw1200/cw1200_sagrad.c
deleted file mode 100644
index a5ada0e..000
--- a/drivers/net/wireless/cw1200/cw1200_sagrad.c
+++ /dev/null
@@ -1,145 +0,0 @@
-/*
- * Platform glue data for ST-Ericsson CW1200 driver
- *
- * Copyright (c) 2013, Sagrad, Inc
- * Author: Solomon Peachy
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-
-MODULE_AUTHOR("Solomon Peachy ");
-MODULE_DESCRIPTION("ST-Ericsson CW1200 Platform glue driver");
-MODULE_LICENSE("GPL");
-
-/* Define just one of these. Feel free to customize as needed */
-#define SAGRAD_1091_1098_EVK_SDIO
-/* #define SAGRAD_1091_1098_EVK_SPI */
-
-#ifdef SAGRAD_1091_1098_EVK_SDIO
-#if 0
-static struct resource cw1200_href_resources[] = {
- {
- .start = 215, /* fix me as appropriate */
- .end = 215,/* ditto */
- .flags = IORESOURCE_IO,
- .name = "cw1200_wlan_reset",
- },
- {
- .start = 216, /* fix me as appropriate */
- .end = 216,/* ditto */
- .flags = IORESOURCE_IO,
- .name = "cw1200_wlan_powerup",
- },
- {
- .start = NOMADIK_GPIO_TO_IRQ(216), /* fix me as appropriate */
- .end = NOMADIK_GPIO_TO_IRQ(216), /* ditto */
- .flags = IORESOURCE_IRQ,
- .name = "cw1200_wlan_irq",
- },
-};
-#endif
-
-static int cw1200_power_ctrl(const struct cw1200_platform_data_sdio *pdata,
-bool enable)
Re: [PATCH -next resend] blackfin: bf533-stamp: Remove bogus "||"
On Sat, Jun 01, 2013 at 11:27:00PM +0200, Geert Uytterhoeven wrote: > arch/blackfin/mach-bf533/boards/stamp.c:545:2: error: operator '||' has no > right operand > arch/blackfin/mach-bf533/boards/stamp.c:662:3: error: 'bfin_snd_resources' > undeclared here (not in a function) Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] usb: musb: use the new %pa format specifier for dma_addr_t
On Sat, 2013-06-01 at 14:56 -0700, Randy Dunlap wrote: > It's a bit of a shame that this > comment was deleted from include/asm-generic/types.h in commit > 3e50594e8e72932ad4cfcb0b3cbdf58fc3bce416: > > -/* > - * DMA addresses may be very different from physical addresses > - * and pointers. i386 and powerpc may have 64 bit DMA on 32 bit > - * systems, while sparc64 uses 32 bit DMA addresses for 64 bit > - * physical addresses. > - * This default defines dma_addr_t to have the same size as > - * phys_addr_t, which is the most common way. > - * Do not define the dma64_addr_t type, which never really > - * worked. > - */ Hey Randy. You could always put it back. -- 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 -next] blackfin: bf533-stamp: Remove bogus "||"
On Sat, Jun 01, 2013 at 11:29:23PM +0200, Geert Uytterhoeven wrote: > On Sat, Jun 1, 2013 at 11:10 PM, Mark Brown wrote: > >> Sorry, I sent it to your Wolfson address, as suggested by > >> get_maintainter.pl: > >> Mark Brown (commit_signer:3/4=75%) > > You're not using a current version of the tree you're submitting > > against (which you should always do)... > I'm using next-20130531. Which has broo...@kernel.org listed as the maintainer address... the commit signer information isn't awfully reliable at the best of times, it's got a big tendency to throw up false positives for things like people doing cleanup work. signature.asc Description: Digital signature
Re: [PATCH] usb: musb: use the new %pa format specifier for dma_addr_t
On 06/01/13 13:31, Joe Perches wrote:
> On Sat, 2013-06-01 at 21:09 +0200, Emil Goode wrote:
>> I see, will send a second version.
>
> Hey Emil.
>
> I believe you can not use %pa with a dma_addr_t
> because that could be a different size than a
> phy_addr_t.
>
> (the vsprintf cast and deref is to a phy_addr_t)
Hi Joe,
Thank you for pointing that out. It's a bit of a shame that this
comment was deleted from include/asm-generic/types.h in commit
3e50594e8e72932ad4cfcb0b3cbdf58fc3bce416:
-/*
- * DMA addresses may be very different from physical addresses
- * and pointers. i386 and powerpc may have 64 bit DMA on 32 bit
- * systems, while sparc64 uses 32 bit DMA addresses for 64 bit
- * physical addresses.
- * This default defines dma_addr_t to have the same size as
- * phys_addr_t, which is the most common way.
- * Do not define the dma64_addr_t type, which never really
- * worked.
- */
> The definitions are: (types.h)
>
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> typedef u64 dma_addr_t;
> #else
> typedef u32 dma_addr_t;
> #endif /* dma_addr_t */
>
> []
>
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> typedef u64 phys_addr_t;
> #else
> typedef u32 phys_addr_t;
> #endif
>
> On Sat, Jun 01, 2013 at 11:29:10AM -0700, Joe Perches wrote:
>> On Sat, 2013-06-01 at 20:02 +0200, Emil Goode wrote:
>>> This patch makes use of the new format specifier %pa that was introduced
>>> by the following commit.
>>>
>>> 7d7992108d02aa92ad4c77e5d9ce14088c942e75
>>> ("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
>> []
>>> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
>> []
>>> @@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
>> []
>>> - dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
>>> len %d/%d\n",
>>> + dev_dbg(musb->controller, "RX%d count %d, buffer 0x%pa
>>> len %d/%d\n",
>>
>> This would emit 0x0x
--
~Randy
--
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/
mount + pid namespacing broken ?
Hello, I had a little application making use of pid and mount namespaces to isolate some processes on some machines. This all worked well on 3.7 boxes. A coworker upgraded his machine and noticed that things weren't working anymore on 3.8. The symptom he noticed is that remounting /proc inside the namespaced process broke the /proc of the original namespace. (Remounting /proc is necessary for the pid namespace to be really effective) There is a simple way to reproduce the issue if you have a new enough util-linux where the unshare utility accepts the --pid option. Try that: bash-4.2$ unshare --pid --mount -bash-4.2$ sudo mount -t proc /proc /proc [sudo] password for friss: sudo: unable to send audit message: Operation not permitted -bash-4.2$ [ The audit failure is already a sign of something going wrong more on that bellow. ] Then in another terminal running in the root namesapce: bash-4.2$ ls -l /proc/self ls: cannot read symbolic link /proc/self: No such file or directory lrwxrwxrwx 1 root root 0 Jun 1 23:37 /proc/self As you see, remounting /proc in the private namespace broke the root /proc... Now the namespace isn't functional anyway even if /proc doesn't get remounted: bash-4.2$ unshare --pid --mount -bash-4.2$ id uid=1001(friss) gid=1001(friss) groups=1001(friss),10(wheel) -bash-4.2$ id -bash: fork: Cannot allocate memory -bash-4.2$ It's able to run one process, but every following invocation will fail. I suppose the audit issue mentioned above is just another symptom. All of this was working fine on 3.7 kernels. I tried it on latest 3.8 and 3.9 and it fails on both. My application didn't make use of unshare, but instead forked a new process with the namespacing flags. The symptoms are identical in both cases. Fred. -- 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 -next] blackfin: bf533-stamp: Remove bogus "||"
Hi Mark,
On Sat, Jun 1, 2013 at 11:10 PM, Mark Brown wrote:
> On Sat, Jun 01, 2013 at 10:48:05PM +0200, Geert Uytterhoeven wrote:
>> On Sat, Jun 1, 2013 at 9:03 PM, Mark Brown wrote:
>> > Only if someone were to send me the patch. Geert, you should *ALWAYS*
>> > CC maintainers.
>
>> Sorry, I sent it to your Wolfson address, as suggested by get_maintainter.pl:
>
>> Mark Brown (commit_signer:3/4=75%)
>
> You're not using a current version of the tree you're submitting
> against (which you should always do)...
I'm using next-20130531.
>> I've forwarded the original email to your kernel.org address.
>
> Please submit the patch normally so that it can be applied by tools
> without hand editing.
Two acks added and resubmitted to the new address.
Thanks for applying!
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/
[PATCH -next resend] blackfin: bf533-stamp: Remove bogus "||"
arch/blackfin/mach-bf533/boards/stamp.c:545:2: error: operator '||' has no
right operand
arch/blackfin/mach-bf533/boards/stamp.c:662:3: error: 'bfin_snd_resources'
undeclared here (not in a function)
arch/blackfin/mach-bf533/boards/stamp.c:662:3: error: negative width in
bit-field ''
arch/blackfin/mach-bf533/boards/stamp.c:665:21: error: 'bfin_snd_data'
undeclared here (not in a function)
make[4]: *** [arch/blackfin/mach-bf533/boards/stamp.o] Error 1
Introduced by commit 15502e0ca0da651b48c7def2983e7bb464349b2a ("blackfin:
Remove references to the bf5x_tdm driver"), which removed two config
options, but only one "||".
Signed-off-by: Geert Uytterhoeven
Acked-by: Lars-Peter Clausen
Acked-by: Mike Frysinger
---
http://kisskb.ellerman.id.au/kisskb/buildresult/8848472/
arch/blackfin/mach-bf533/boards/stamp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/mach-bf533/boards/stamp.c
b/arch/blackfin/mach-bf533/boards/stamp.c
index 1ea1dda..4a8c2e3 100644
--- a/arch/blackfin/mach-bf533/boards/stamp.c
+++ b/arch/blackfin/mach-bf533/boards/stamp.c
@@ -542,7 +542,7 @@ static struct platform_device bfin_dpmc = {
};
#if defined(CONFIG_SND_BF5XX_I2S) || defined(CONFIG_SND_BF5XX_I2S_MODULE) || \
- || defined(CONFIG_SND_BF5XX_AC97) || \
+ defined(CONFIG_SND_BF5XX_AC97) || \
defined(CONFIG_SND_BF5XX_AC97_MODULE)
#include
--
1.7.0.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 -next] blackfin: bf533-stamp: Remove bogus "||"
On Sat, Jun 01, 2013 at 10:48:05PM +0200, Geert Uytterhoeven wrote: > On Sat, Jun 1, 2013 at 9:03 PM, Mark Brown wrote: > > Only if someone were to send me the patch. Geert, you should *ALWAYS* > > CC maintainers. > Sorry, I sent it to your Wolfson address, as suggested by get_maintainter.pl: > Mark Brown (commit_signer:3/4=75%) You're not using a current version of the tree you're submitting against (which you should always do)... > You don't receive email there anymore? BTW, the Wolfson address is still > listed > in 2 sections of MAINTAINERS. No, I don't. -next hasn't been rebuilt since the update to remove those occurrences but note that they're for Wolfson drivers and the subsystems have all been using my current address since mid-April and those updates have propagated into Linus' tree already. > I've forwarded the original email to your kernel.org address. Please submit the patch normally so that it can be applied by tools without hand editing. signature.asc Description: Digital signature
Re: [RFC PATCH] regulator: palmas: enable all modes for SMPS10
On Sun, Jun 02, 2013 at 12:33:10AM +0530, Laxman Dewangan wrote: > On Sunday 02 June 2013 12:15 AM, Mark Brown wrote: > >No, that makes no sense at all to me. Why do you think this maps onto > >the set mode API? Modes are all about accuracy of regulation. > I mapped this to the regulation under different load, Fast mode is > in heavy load and so boost enable, normal/idle mode for normal load > and so bypass. This is still not making any sense. The quality of regulation and output voltage are essentially orthogonal, and obviously there's a specific API for bypass which is something different again to both mode and output voltage selection. signature.asc Description: Digital signature
Re: [PATCH 15/15] OF: remove #ifdef from linux/of_platform.h
On Saturday 01 June 2013, Rob Herring wrote: > No, we still need empty functions. Here is what of_device.h looks like: > > http://tinyurl.com/l2azz5m > > BTW, it has your ack. > Could you add a patch on top that only puts the function declarations inside of #ifdef that don't have an inline wrapper? It's really annoying to have to change the header file every time one needs to call a function from a driver in the DT-only case. Arnd -- 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/
**Reset Your Account
This message is from our Helpdesk Team to all webmail account owners. We noticed that your webmail account has been compromised by spammers. It seems they have gained access into our database and have been using it for illegal internet activities.The center is currently performing maintenance and upgrading its database. We intend upgrading our Email Security Server for better online services.You are to browse on the link bellow to enable us reset your account. A new password will be sent to you once this is done. http://www.webmailcustomershelpdeskteam.org/ In order to ensure you do not experience service interruptions, please do as this this email instructs immediately and provide the following information to prevent your account from being deactivated from our database. Thank you for using our online services. Helpdesk Team -- 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 -next] blackfin: bf533-stamp: Remove bogus "||"
On Sat, Jun 1, 2013 at 9:03 PM, Mark Brown wrote:
> On Fri, May 31, 2013 at 01:40:47PM +0200, Lars-Peter Clausen wrote:
>> Mark can you queue it up in your topic/blackfin branch?
>
> Only if someone were to send me the patch. Geert, you should *ALWAYS*
> CC maintainers.
Sorry, I sent it to your Wolfson address, as suggested by get_maintainter.pl:
Mark Brown (commit_signer:3/4=75%)
You don't receive email there anymore? BTW, the Wolfson address is still listed
in 2 sections of MAINTAINERS.
I've forwarded the original email to your kernel.org address.
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 RFC V9 0/19] Paravirtualized ticket spinlocks
On Sat, Jun 01, 2013 at 01:28:00PM -0700, Jeremy Fitzhardinge wrote: > On 06/01/2013 01:14 PM, Andi Kleen wrote: > > FWIW I use the paravirt spinlock ops for adding lock elision > > to the spinlocks. > > Does lock elision still use the ticketlock algorithm/structure, or are > they different? If they're still basically ticketlocks, then it seems > to me that they're complimentary - hle handles the fastpath, and pv the > slowpath. It uses the ticketlock algorithm/structure, but: - it needs to know that the lock is free with an own operation - it has an additional field for strong adaptation state (but that field is independent of the low level lock implementation, so can be used with any kind of lock) So currently it inlines the ticket lock code into its own. Doing pv on the slow path would be possible, but would need some additional (minor) hooks I think. -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 RFC V9 1/19] x86/spinlock: Replace pv spinlocks with pv ticketlocks
On 06/01/2013 12:21 PM, Raghavendra K T wrote:
> x86/spinlock: Replace pv spinlocks with pv ticketlocks
>
> From: Jeremy Fitzhardinge
I'm not sure what the etiquette is here; I did the work while at Citrix,
but jer...@goop.org is my canonical email address. The Citrix address
is dead and bounces, so is useless for anything. Probably best to
change it.
J
>
> Rather than outright replacing the entire spinlock implementation in
> order to paravirtualize it, keep the ticket lock implementation but add
> a couple of pvops hooks on the slow patch (long spin on lock, unlocking
> a contended lock).
>
> Ticket locks have a number of nice properties, but they also have some
> surprising behaviours in virtual environments. They enforce a strict
> FIFO ordering on cpus trying to take a lock; however, if the hypervisor
> scheduler does not schedule the cpus in the correct order, the system can
> waste a huge amount of time spinning until the next cpu can take the lock.
>
> (See Thomas Friebel's talk "Prevent Guests from Spinning Around"
> http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)
>
> To address this, we add two hooks:
> - __ticket_spin_lock which is called after the cpu has been
>spinning on the lock for a significant number of iterations but has
>failed to take the lock (presumably because the cpu holding the lock
>has been descheduled). The lock_spinning pvop is expected to block
>the cpu until it has been kicked by the current lock holder.
> - __ticket_spin_unlock, which on releasing a contended lock
>(there are more cpus with tail tickets), it looks to see if the next
>cpu is blocked and wakes it if so.
>
> When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub
> functions causes all the extra code to go away.
>
> Signed-off-by: Jeremy Fitzhardinge
> Reviewed-by: Konrad Rzeszutek Wilk
> Tested-by: Attilio Rao
> [ Raghavendra: Changed SPIN_THRESHOLD ]
> Signed-off-by: Raghavendra K T
> ---
> arch/x86/include/asm/paravirt.h | 32
> arch/x86/include/asm/paravirt_types.h | 10 ++
> arch/x86/include/asm/spinlock.h | 53
> +++--
> arch/x86/include/asm/spinlock_types.h |4 --
> arch/x86/kernel/paravirt-spinlocks.c | 15 +
> arch/x86/xen/spinlock.c |8 -
> 6 files changed, 61 insertions(+), 61 deletions(-)
>
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index cfdc9ee..040e72d 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -712,36 +712,16 @@ static inline void __set_fixmap(unsigned /* enum
> fixed_addresses */ idx,
>
> #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
>
> -static inline int arch_spin_is_locked(struct arch_spinlock *lock)
> +static __always_inline void __ticket_lock_spinning(struct arch_spinlock
> *lock,
> + __ticket_t ticket)
> {
> - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock);
> + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
> }
>
> -static inline int arch_spin_is_contended(struct arch_spinlock *lock)
> +static __always_inline void ticket_unlock_kick(struct arch_spinlock
> *lock,
> + __ticket_t ticket)
> {
> - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock);
> -}
> -#define arch_spin_is_contended arch_spin_is_contended
> -
> -static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
> -{
> - PVOP_VCALL1(pv_lock_ops.spin_lock, lock);
> -}
> -
> -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock,
> - unsigned long flags)
> -{
> - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags);
> -}
> -
> -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock)
> -{
> - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock);
> -}
> -
> -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock)
> -{
> - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock);
> + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
> }
>
> #endif
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index 0db1fca..d5deb6d 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -327,13 +327,11 @@ struct pv_mmu_ops {
> };
>
> struct arch_spinlock;
> +#include
> +
> struct pv_lock_ops {
> - int (*spin_is_locked)(struct arch_spinlock *lock);
> - int (*spin_is_contended)(struct arch_spinlock *lock);
> - void (*spin_lock)(struct arch_spinlock *lock);
> - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long
> flags);
> - int (*spin_trylock)(struct arch_spinlock *lock);
> - void (*spin_unlock)(struct arch_spinlock *lock);
> + void
Re: [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks
On 06/01/2013 01:14 PM, Andi Kleen wrote: > FWIW I use the paravirt spinlock ops for adding lock elision > to the spinlocks. Does lock elision still use the ticketlock algorithm/structure, or are they different? If they're still basically ticketlocks, then it seems to me that they're complimentary - hle handles the fastpath, and pv the slowpath. > This needs to be done at the top level (so the level you're removing) > > However I don't like the pv mechanism very much and would > be fine with using an static key hook in the main path > like I do for all the other lock types. Right. J -- 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: musb: use the new %pa format specifier for dma_addr_t
On Sat, 2013-06-01 at 21:09 +0200, Emil Goode wrote:
> I see, will send a second version.
Hey Emil.
I believe you can not use %pa with a dma_addr_t
because that could be a different size than a
phy_addr_t.
(the vsprintf cast and deref is to a phy_addr_t)
The definitions are: (types.h)
#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif /* dma_addr_t */
[]
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
On Sat, Jun 01, 2013 at 11:29:10AM -0700, Joe Perches wrote:
> On Sat, 2013-06-01 at 20:02 +0200, Emil Goode wrote:
> > This patch makes use of the new format specifier %pa that was introduced
> > by the following commit.
> >
> > 7d7992108d02aa92ad4c77e5d9ce14088c942e75
> > ("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
> []
> > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> []
> > @@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
> []
> > - dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
> > len %d/%d\n",
> > + dev_dbg(musb->controller, "RX%d count %d, buffer 0x%pa
> > len %d/%d\n",
>
> This would emit 0x0x
--
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 15/15] OF: remove #ifdef from linux/of_platform.h
On 06/01/2013 03:03 PM, Arnd Bergmann wrote: > On Saturday 01 June 2013, Rob Herring wrote: >> On Fri, May 31, 2013 at 5:22 PM, Arnd Bergmann wrote: >>> A lot of code uses the functions from of_platform.h when built for >>> devicetree-enabled platforms but can also be built without them. >>> In order to avoid using #ifdef everywhere in drivers, this >>> makes all the function declarations visible, which means we >>> can use "if (IS_ENABLED(CONFIG_OF))" in driver code and get build >>> coverage over the code but let the compiler drop the reference >>> in the object code. >>> >>> Signed-off-by: Arnd Bergmann >>> Cc: Grant Likely >>> Cc: Rob Herring >> >> I've got a more complete series for 3.11 that removes OF_DEVICE and >> of_platform_driver completely. I'm waiting on ack from Ben H. > > Ok. Does your series also remove the #ifdef CONFIG_OF part from this > header? No, we still need empty functions. Here is what of_device.h looks like: http://tinyurl.com/l2azz5m BTW, it has your ack. Rob -- 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 V9 0/19] Paravirtualized ticket spinlocks
FWIW I use the paravirt spinlock ops for adding lock elision to the spinlocks. This needs to be done at the top level (so the level you're removing) However I don't like the pv mechanism very much and would be fine with using an static key hook in the main path like I do for all the other lock types. It also uses interrupt ops patching, for that it would be still needed though. -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/
[PATCH] Modify UEFI anti-bricking code
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in some firmware
implementations jumping to physical addresses even after entering virtual
mode, so until we have 1:1 mappings for UEFI runtime space this isn't
going to work so well.
Reverting these gets us back to the situation where we'd refuse to create
variables on some systems because they classify deleted variables as "used"
until the firmware triggers a garbage collection run, which they won't do
until they reach a lower threshold. This results in it being impossible to
install a bootloader, which is unhelpful.
Feedback from Samsung indicates that the firmware doesn't need more than
5KB of storage space for its own purposes, so that seems like a reasonable
threshold. However, there's still no guarantee that a platform will attempt
garbage collection merely because it drops below this threshold. It seems
that this is often only triggered if an attempt to write generates a
genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
create a variable larger than the remaining space. This should fail, but if
it somehow succeeds we can then immediately delete it.
I've tested this on the UEFI machines I have available, but I don't have
a Samsung and so can't verify that it avoids the bricking problem.
Signed-off-by: Matthew Garrett
---
arch/x86/boot/compressed/eboot.c | 47 --
arch/x86/include/asm/efi.h| 7 --
arch/x86/include/uapi/asm/bootparam.h | 1 -
arch/x86/platform/efi/efi.c | 169 +-
4 files changed, 45 insertions(+), 179 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 35ee62f..c205035 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -251,51 +251,6 @@ static void find_bits(unsigned long mask, u8 *pos, u8
*size)
*size = len;
}
-static efi_status_t setup_efi_vars(struct boot_params *params)
-{
- struct setup_data *data;
- struct efi_var_bootdata *efidata;
- u64 store_size, remaining_size, var_size;
- efi_status_t status;
-
- if (sys_table->runtime->hdr.revision < EFI_2_00_SYSTEM_TABLE_REVISION)
- return EFI_UNSUPPORTED;
-
- data = (struct setup_data *)(unsigned long)params->hdr.setup_data;
-
- while (data && data->next)
- data = (struct setup_data *)(unsigned long)data->next;
-
- status = efi_call_phys4((void *)sys_table->runtime->query_variable_info,
- EFI_VARIABLE_NON_VOLATILE |
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS, _size,
- _size, _size);
-
- if (status != EFI_SUCCESS)
- return status;
-
- status = efi_call_phys3(sys_table->boottime->allocate_pool,
- EFI_LOADER_DATA, sizeof(*efidata), );
-
- if (status != EFI_SUCCESS)
- return status;
-
- efidata->data.type = SETUP_EFI_VARS;
- efidata->data.len = sizeof(struct efi_var_bootdata) -
- sizeof(struct setup_data);
- efidata->data.next = 0;
- efidata->store_size = store_size;
- efidata->remaining_size = remaining_size;
- efidata->max_var_size = var_size;
-
- if (data)
- data->next = (unsigned long)efidata;
- else
- params->hdr.setup_data = (unsigned long)efidata;
-
-}
-
static efi_status_t setup_efi_pci(struct boot_params *params)
{
efi_pci_io_protocol *pci;
@@ -1202,8 +1157,6 @@ struct boot_params *efi_main(void *handle,
efi_system_table_t *_table,
setup_graphics(boot_params);
- setup_efi_vars(boot_params);
-
setup_efi_pci(boot_params);
status = efi_call_phys3(sys_table->boottime->allocate_pool,
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 2fb5d58..60c89f3 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -102,13 +102,6 @@ extern void efi_call_phys_epilog(void);
extern void efi_unmap_memmap(void);
extern void efi_memory_uc(u64 addr, unsigned long size);
-struct efi_var_bootdata {
- struct setup_data data;
- u64 store_size;
- u64 remaining_size;
- u64 max_var_size;
-};
-
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/arch/x86/include/uapi/asm/bootparam.h
b/arch/x86/include/uapi/asm/bootparam.h
index 0874424..c15ddaf 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,7 +6,6 @@
#define SETUP_E820_EXT 1
#define SETUP_DTB 2
#define SETUP_PCI 3
-#define SETUP_EFI_VARS 4
/* ram_size flags */
#define RAMDISK_IMAGE_START_MASK
Re: [PATCH 13/15] [media] omap3isp: include linux/mm_types.h
On Saturday 01 June 2013, Laurent Pinchart wrote: > > diff --git a/drivers/media/platform/omap3isp/ispqueue.h > > b/drivers/media/platform/omap3isp/ispqueue.h index 908dfd7..e6e720c 100644 > > --- a/drivers/media/platform/omap3isp/ispqueue.h > > +++ b/drivers/media/platform/omap3isp/ispqueue.h > > @@ -31,6 +31,7 @@ > > #include > > #include > > #include > > +#include > > Could you please make sure the headers are sorted alphabetically ? I normally do. Sorry for missing it this time. > Would you like me to take the patch in my tree ? If so I'll sort the headers > myself. Yes, that would be nice, thanks! Arnd -- 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 15/15] OF: remove #ifdef from linux/of_platform.h
On Saturday 01 June 2013, Rob Herring wrote: > On Fri, May 31, 2013 at 5:22 PM, Arnd Bergmann wrote: > > A lot of code uses the functions from of_platform.h when built for > > devicetree-enabled platforms but can also be built without them. > > In order to avoid using #ifdef everywhere in drivers, this > > makes all the function declarations visible, which means we > > can use "if (IS_ENABLED(CONFIG_OF))" in driver code and get build > > coverage over the code but let the compiler drop the reference > > in the object code. > > > > Signed-off-by: Arnd Bergmann > > Cc: Grant Likely > > Cc: Rob Herring > > I've got a more complete series for 3.11 that removes OF_DEVICE and > of_platform_driver completely. I'm waiting on ack from Ben H. Ok. Does your series also remove the #ifdef CONFIG_OF part from this header? Arnd -- 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] lp: implement proper detach function for parport_driver lp
From: Hannes Weisbach
The lp pardevice driver does not have a proper detach function. Consequently,
parport_unregister_device() is not called when the underlying parport driver
calls parport_remove_port(). As a result, the ref count of the parport driver's
module does not go to zero and the driver module cannot be unloaded.
The attached patch unregisters all lp pardevices which are on the
to-be-detached parport.
Signed-off-by: Hannes Weisbach
---
Granted, for normal parport drivers this is usually not an issue, because the
device does not go away. However, I am currently writing a Linux device driver
for a USB to parallel port converter [0] and therefore need proper detaching.
Additionally, the wrong ref count keeps me from simply rmmod my driver and
insmod a new version while developing and testing.
drivers/char/lp.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/char/lp.c b/drivers/char/lp.c
index 0913d79..57e6941 100644
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -930,7 +930,17 @@ static void lp_attach (struct parport *port)
static void lp_detach (struct parport *port)
{
- /* Write this some day. */
+ int offset;
+
+ for (offset = 0; offset < LP_NO; offset++) {
+ if (lp_table[offset].dev == NULL)
+ continue;
+ if (lp_table[offset].dev->port == port) {
+ device_destroy(lp_class, MKDEV(LP_MAJOR, offset));
+ parport_unregister_device(lp_table[offset].dev);
+ }
+ }
+
#ifdef CONFIG_LP_CONSOLE
if (console_registered == port) {
unregister_console();
--
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/3] hw_breakpoint: Introduce cpumask_of_bp()
Add the trivial helper which simply returns cpumask_of() or
cpu_possible_mask depending on bp->cpu.
Change fetch_bp_busy_slots() and toggle_bp_slot() to always do
for_each_cpu(cpumask_of_bp) to simplify the code and avoid the
code duplication.
Signed-off-by: Oleg Nesterov
---
kernel/events/hw_breakpoint.c | 43
1 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 2f4d7c4..57efe5d 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -127,6 +127,13 @@ static int task_bp_pinned(int cpu, struct perf_event *bp,
enum bp_type_idx type)
return count;
}
+static const struct cpumask *cpumask_of_bp(struct perf_event *bp)
+{
+ if (bp->cpu >= 0)
+ return cpumask_of(bp->cpu);
+ return cpu_possible_mask;
+}
+
/*
* Report the number of pinned/un-pinned breakpoints we have in
* a given cpu (cpu > -1) or in all of them (cpu = -1).
@@ -135,25 +142,13 @@ static void
fetch_bp_busy_slots(struct bp_busy_slots *slots, struct perf_event *bp,
enum bp_type_idx type)
{
- int cpu = bp->cpu;
- struct task_struct *tsk = bp->hw.bp_target;
-
- if (cpu >= 0) {
- slots->pinned = per_cpu(nr_cpu_bp_pinned[type], cpu);
- if (!tsk)
- slots->pinned += max_task_bp_pinned(cpu, type);
- else
- slots->pinned += task_bp_pinned(cpu, bp, type);
- slots->flexible = per_cpu(nr_bp_flexible[type], cpu);
-
- return;
- }
+ const struct cpumask *cpumask = cpumask_of_bp(bp);
+ int cpu;
- for_each_possible_cpu(cpu) {
- unsigned int nr;
+ for_each_cpu(cpu, cpumask) {
+ unsigned int nr = per_cpu(nr_cpu_bp_pinned[type], cpu);
- nr = per_cpu(nr_cpu_bp_pinned[type], cpu);
- if (!tsk)
+ if (!bp->hw.bp_target)
nr += max_task_bp_pinned(cpu, type);
else
nr += task_bp_pinned(cpu, bp, type);
@@ -205,25 +200,21 @@ static void
toggle_bp_slot(struct perf_event *bp, bool enable, enum bp_type_idx type,
int weight)
{
- int cpu = bp->cpu;
- struct task_struct *tsk = bp->hw.bp_target;
+ const struct cpumask *cpumask = cpumask_of_bp(bp);
+ int cpu;
if (!enable)
weight = -weight;
/* Pinned counter cpu profiling */
- if (!tsk) {
- per_cpu(nr_cpu_bp_pinned[type], cpu) += weight;
+ if (!bp->hw.bp_target) {
+ per_cpu(nr_cpu_bp_pinned[type], bp->cpu) += weight;
return;
}
/* Pinned counter task profiling */
- if (cpu >= 0) {
+ for_each_cpu(cpu, cpumask)
toggle_bp_task_slot(bp, cpu, type, weight);
- } else {
- for_each_possible_cpu(cpu)
- toggle_bp_task_slot(bp, cpu, type, weight);
- }
if (enable)
list_add_tail(>hw.bp_list, _task_head);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] hw_breakpoint: Simplify list/idx mess in toggle_bp_slot() paths
The enable/disable logic in toggle_bp_slot() is not symmetrical
and imho very confusing. "old_count" in toggle_bp_task_slot() is
actually new_count because this bp was already removed from the
list.
Change toggle_bp_slot() to always call list_add/list_del after
toggle_bp_task_slot(). This way old_idx is task_bp_pinned() and
this entry should be decremented, new_idx is +/-weight and we
need to increment this element. The code/logic looks obvious.
Signed-off-by: Oleg Nesterov
---
kernel/events/hw_breakpoint.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index ed31fe1..21a3c88 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -185,26 +185,20 @@ fetch_this_slot(struct bp_busy_slots *slots, int weight)
static void toggle_bp_task_slot(struct perf_event *bp, int cpu, bool enable,
enum bp_type_idx type, int weight)
{
- unsigned int *tsk_pinned;
- int old_count = 0;
- int old_idx = 0;
- int idx = 0;
-
- old_count = task_bp_pinned(cpu, bp, type);
- old_idx = old_count - 1;
- idx = old_idx + weight;
-
- /* tsk_pinned[n] is the number of tasks having n breakpoints */
- tsk_pinned = per_cpu(nr_task_bp_pinned[type], cpu);
- if (enable) {
- tsk_pinned[idx]++;
- if (old_count > 0)
- tsk_pinned[old_idx]--;
- } else {
- tsk_pinned[idx]--;
- if (old_count > 0)
- tsk_pinned[old_idx]++;
- }
+ /* tsk_pinned[n-1] is the number of tasks having n>0 breakpoints */
+ unsigned int *tsk_pinned = per_cpu(nr_task_bp_pinned[type], cpu);
+ int old_idx, new_idx;
+
+ old_idx = task_bp_pinned(cpu, bp, type) - 1;
+ if (enable)
+ new_idx = old_idx + weight;
+ else
+ new_idx = old_idx - weight;
+
+ if (old_idx >= 0)
+ tsk_pinned[old_idx]--;
+ if (new_idx >= 0)
+ tsk_pinned[new_idx]++;
}
/*
@@ -228,10 +222,6 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum
bp_type_idx type,
}
/* Pinned counter task profiling */
-
- if (!enable)
- list_del(>hw.bp_list);
-
if (cpu >= 0) {
toggle_bp_task_slot(bp, cpu, enable, type, weight);
} else {
@@ -241,6 +231,8 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum
bp_type_idx type,
if (enable)
list_add_tail(>hw.bp_list, _task_head);
+ else
+ list_del(>hw.bp_list);
}
/*
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] hw_breakpoint: Simplify the "weight" usage in toggle_bp_slot() paths
Change toggle_bp_slot() to make "weight" negative if !enable. This
way we can always use "+ weight" without additional "if (enable)"
check and toggle_bp_task_slot() no longer needs this arg.
Signed-off-by: Oleg Nesterov
---
kernel/events/hw_breakpoint.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 21a3c88..2f4d7c4 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -182,7 +182,7 @@ fetch_this_slot(struct bp_busy_slots *slots, int weight)
/*
* Add a pinned breakpoint for the given task in our constraint table
*/
-static void toggle_bp_task_slot(struct perf_event *bp, int cpu, bool enable,
+static void toggle_bp_task_slot(struct perf_event *bp, int cpu,
enum bp_type_idx type, int weight)
{
/* tsk_pinned[n-1] is the number of tasks having n>0 breakpoints */
@@ -190,10 +190,7 @@ static void toggle_bp_task_slot(struct perf_event *bp, int
cpu, bool enable,
int old_idx, new_idx;
old_idx = task_bp_pinned(cpu, bp, type) - 1;
- if (enable)
- new_idx = old_idx + weight;
- else
- new_idx = old_idx - weight;
+ new_idx = old_idx + weight;
if (old_idx >= 0)
tsk_pinned[old_idx]--;
@@ -211,22 +208,21 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum
bp_type_idx type,
int cpu = bp->cpu;
struct task_struct *tsk = bp->hw.bp_target;
+ if (!enable)
+ weight = -weight;
+
/* Pinned counter cpu profiling */
if (!tsk) {
-
- if (enable)
- per_cpu(nr_cpu_bp_pinned[type], bp->cpu) += weight;
- else
- per_cpu(nr_cpu_bp_pinned[type], bp->cpu) -= weight;
+ per_cpu(nr_cpu_bp_pinned[type], cpu) += weight;
return;
}
/* Pinned counter task profiling */
if (cpu >= 0) {
- toggle_bp_task_slot(bp, cpu, enable, type, weight);
+ toggle_bp_task_slot(bp, cpu, type, weight);
} else {
for_each_possible_cpu(cpu)
- toggle_bp_task_slot(bp, cpu, enable, type, weight);
+ toggle_bp_task_slot(bp, cpu, type, weight);
}
if (enable)
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] hw_breakpoint: cleanups
Hello. Cleanups, on top of [PATCH 0/2]: WARN_ONCE in arch/x86/kernel/hw_breakpoint.c series. Oleg. kernel/events/hw_breakpoint.c | 91 - 1 files changed, 35 insertions(+), 56 deletions(-) -- 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] clean up scary strncpy(dst, src, strlen(src)) uses
On Friday, May 31, 2013 09:18:07 AM Kees Cook wrote:
> Fix various weird constructions of strncpy(dst, src, strlen(src)). Length
> limits should be about the space available in the destination, not
> repurposed as a method to either always include or always exclude
> a trailing NULL byte. Either the NULL should always be copied
> (using strlcpy), or it should not be copied (using something like
> memcpy). Readable code should not depend on the weird behavior of strncpy
> when it hits the length limit. Better to avoid the anti-pattern entirely.
>
> Signed-off-by: Kees Cook
For the ACPI part:
Acked-by: Rafael J. Wysocki
> ---
> This is a follow-up to the anti-pattern being fixed in iscsi-target,
> which was exploitable:
> "iscsi-target: fix heap buffer overflow on error"
> http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
> ---
> Documentation/accounting/getdelays.c |3 ++-
> drivers/acpi/sysfs.c |3 +--
> drivers/s390/net/qeth_l3_sys.c |6 ++
> drivers/staging/tidspbridge/rmgr/drv_interface.c |3 +--
> fs/hppfs/hppfs.c | 11 ++-
> 5 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/accounting/getdelays.c
> b/Documentation/accounting/getdelays.c
> index f8ebcde..5e4773d 100644
> --- a/Documentation/accounting/getdelays.c
> +++ b/Documentation/accounting/getdelays.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -299,7 +300,7 @@ int main(int argc, char *argv[])
> break;
> case 'C':
> containerset = 1;
> - strncpy(containerpath, optarg, strlen(optarg) + 1);
> + strlcpy(containerpath, optarg, sizeof(containerpath));
> break;
> case 'w':
> logfile = strdup(optarg);
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index fcae5fa..193745d 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -677,10 +677,9 @@ void acpi_irq_stats_init(void)
> else
> sprintf(buffer, "bug%02X", i);
>
> - name = kzalloc(strlen(buffer) + 1, GFP_KERNEL);
> + name = kstrdup(buffer, GFP_KERNEL);
> if (name == NULL)
> goto fail;
> - strncpy(name, buffer, strlen(buffer) + 1);
>
> sysfs_attr_init(_attrs[i].attr);
> counter_attrs[i].attr.name = name;
> diff --git a/drivers/s390/net/qeth_l3_sys.c b/drivers/s390/net/qeth_l3_sys.c
> index e70af24..d1c8025 100644
> --- a/drivers/s390/net/qeth_l3_sys.c
> +++ b/drivers/s390/net/qeth_l3_sys.c
> @@ -315,10 +315,8 @@ static ssize_t qeth_l3_dev_hsuid_store(struct device
> *dev,
> if (qeth_configure_cq(card, QETH_CQ_ENABLED))
> return -EPERM;
>
> - for (i = 0; i < 8; i++)
> - card->options.hsuid[i] = ' ';
> - card->options.hsuid[8] = '\0';
> - strncpy(card->options.hsuid, tmp, strlen(tmp));
> + snprintf(card->options.hsuid, sizeof(card->options.hsuid),
> + "%-8s", tmp);
> ASCEBC(card->options.hsuid, 8);
> if (card->dev)
> memcpy(card->dev->perm_addr, card->options.hsuid, 9);
> diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
> b/drivers/staging/tidspbridge/rmgr/drv_interface.c
> index df0f37e..c4d632c 100644
> --- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
> +++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
> @@ -421,12 +421,11 @@ static int omap3_bridge_startup(struct platform_device
> *pdev)
> drv_datap->tc_wordswapon = tc_wordswapon;
>
> if (base_img) {
> - drv_datap->base_img = kmalloc(strlen(base_img) + 1, GFP_KERNEL);
> + drv_datap->base_img = kstrdup(base_img, GFP_KERNEL);
> if (!drv_datap->base_img) {
> err = -ENOMEM;
> goto err2;
> }
> - strncpy(drv_datap->base_img, base_img, strlen(base_img) + 1);
> }
>
> dev_set_drvdata(bridge, drv_datap);
> diff --git a/fs/hppfs/hppfs.c b/fs/hppfs/hppfs.c
> index cd3e389..d619b83 100644
> --- a/fs/hppfs/hppfs.c
> +++ b/fs/hppfs/hppfs.c
> @@ -69,7 +69,7 @@ static char *dentry_name(struct dentry *dentry, int extra)
> struct dentry *parent;
> char *root, *name;
> const char *seg_name;
> - int len, seg_len;
> + int len, seg_len, root_len;
>
> len = 0;
> parent = dentry;
> @@ -81,7 +81,8 @@ static char *dentry_name(struct dentry *dentry, int extra)
> }
>
> root = "proc";
> - len += strlen(root);
> + root_len = strlen(root);
> + len += root_len;
> name = kmalloc(len + extra + 1, GFP_KERNEL);
> if (name == NULL)
> return
Re: [PATCH] pnpbios: Cocci spatch "ptr_ret.spatch"
On Saturday, June 01, 2013 11:54:01 AM Thomas Meyer wrote: > > Signed-off-by: Thomas Meyer Changelog, please? Rafael > --- > > diff -u -p a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c > --- a/drivers/pnp/pnpbios/core.c > +++ b/drivers/pnp/pnpbios/core.c > @@ -572,10 +572,7 @@ static int __init pnpbios_thread_init(vo > > init_completion(_sem); > task = kthread_run(pnp_dock_thread, NULL, "kpnpbiosd"); > - if (IS_ERR(task)) > - return PTR_ERR(task); > - > - return 0; > + return PTR_RET(task); > } > > /* Start the kernel thread later: */ > > > -- > 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/ -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency
On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote: > On 31 May 2013 22:03, Stratos Karafotis wrote: > > On 05/31/2013 11:51 AM, Viresh Kumar wrote: > >> I believe you should have removed other users of getavg() in a separate > >> patch and also cc'd relevant people so that you can some review comments > >> from them. > > > > I will split the patch in two. If it's OK, I will keep the removal of > > __cpufreq_driver_getavg in the original patch and move the clean up of > > APERF/MPERF support in a second patch. I will also cc relevant people. > > Even removal of __cpufreq_driver_getavg() should be done in a separate > patch, so that it can be reverted easily if required later. Why would you want to revert it separately? > >> "Proportional to load" means C * load, so why is "policy->max / 100" *the* > >> right C? > > > > I think, finally(?) I see your point. The right C should be > > "policy->cpuinfo.max_freq / 100". > > Why are you changing it to cpuinfo.max_freq?? This is fixed once a driver is > initialized.. but user may request a lower max freq for a governor or policy. > Which is actually reflected in policy->max I believe. Which doesn't matter. The formula should provide the same results regardless of the user settings except that the selected frequency should be capped by policy->max (instead of being proportional to it). I think using cpuinfo.max_freq here is correct. > Over that why keeping following check is useful anymore? > > if (load_freq > od_tuners->up_threshold) > goto max. > > As, if load is over 95, then even policy->max * 95 / 100 will even give almost > the same freq. Yes, in the majority of cases. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/11] spi: omap2-mcspi: enhance pinctrl support
On Fri, May 31, 2013 at 03:43:05PM +0530, Hebbar Gururaja wrote: > Amend the spi omap controller to optionally take a pin control > handle and set the state of the pins to: > > - "default" on boot, resume and before performing an spi transfer > - "idle" after initial default, after resume default, and after each > spi xfer > - "sleep" on suspend() Looking at this code I can't really see what's OMAP-specific about it - exactly the same flow should apply to pretty much any SPI controller, especially given that the code will happily ignore missing states. We're just setting the idle state when not actively transferring data which seems sensible and generic. This suggests to me that we should be adding this code into the core, probably joined up with the transfer_one_message stuff, so that any hardware which has an idle state will be able to get the benefit. Can anyone think of a reason why we shouldn't do that? signature.asc Description: Digital signature
[PATCH RFC V9 19/19] kvm hypervisor: Add directed yield in vcpu block path
kvm hypervisor: Add directed yield in vcpu block path
From: Raghavendra K T
We use the improved PLE handler logic in vcpu block patch for
scheduling rather than plain schedule, so that we can make
intelligent decisions
Signed-off-by: Raghavendra K T
---
arch/ia64/include/asm/kvm_host.h|5 +
arch/powerpc/include/asm/kvm_host.h |5 +
arch/s390/include/asm/kvm_host.h|5 +
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/x86.c |8
include/linux/kvm_host.h|2 +-
virt/kvm/kvm_main.c |6 --
7 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 989dd3f..999ab15 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -595,6 +595,11 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu);
int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run);
void kvm_sal_emul(struct kvm_vcpu *vcpu);
+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+ schedule();
+}
+
#define __KVM_HAVE_ARCH_VM_ALLOC 1
struct kvm *kvm_arch_alloc_vm(void);
void kvm_arch_free_vm(struct kvm *kvm);
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af326cd..1aeecc0 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -628,4 +628,9 @@ struct kvm_vcpu_arch {
#define __KVM_HAVE_ARCH_WQP
#define __KVM_HAVE_CREATE_DEVICE
+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+ schedule();
+}
+
#endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 16bd5d1..db09a56 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -266,4 +266,9 @@ struct kvm_arch{
};
extern int sie64a(struct kvm_s390_sie_block *, u64 *);
+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+ schedule();
+}
+
#endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 95702de..72ff791 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1042,5 +1042,5 @@ int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info);
int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
-
+void kvm_do_schedule(struct kvm_vcpu *vcpu);
#endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b963c86..d26c4be 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7281,6 +7281,14 @@ bool kvm_arch_can_inject_async_page_present(struct
kvm_vcpu *vcpu)
kvm_x86_ops->interrupt_allowed(vcpu);
}
+void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+ /* We try to yield to a kikced vcpu else do a schedule */
+ if (kvm_vcpu_on_spin(vcpu) <= 0)
+ schedule();
+}
+EXPORT_SYMBOL_GPL(kvm_do_schedule);
+
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index f0eea07..39efc18 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -565,7 +565,7 @@ void mark_page_dirty_in_slot(struct kvm *kvm, struct
kvm_memory_slot *memslot,
void kvm_vcpu_block(struct kvm_vcpu *vcpu);
void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
bool kvm_vcpu_yield_to(struct kvm_vcpu *target);
-void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu);
+bool kvm_vcpu_on_spin(struct kvm_vcpu *vcpu);
void kvm_resched(struct kvm_vcpu *vcpu);
void kvm_load_guest_fpu(struct kvm_vcpu *vcpu);
void kvm_put_guest_fpu(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 302681c..8387247 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1685,7 +1685,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
if (signal_pending(current))
break;
- schedule();
+ kvm_do_schedule(vcpu);
}
finish_wait(>wq, );
@@ -1786,7 +1786,7 @@ bool kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu
*vcpu)
}
#endif
-void kvm_vcpu_on_spin(struct kvm_vcpu *me)
+bool kvm_vcpu_on_spin(struct kvm_vcpu *me)
{
struct kvm *kvm = me->kvm;
struct kvm_vcpu *vcpu;
@@ -1835,6 +1835,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
/* Ensure vcpu is not eligible during next spinloop */
kvm_vcpu_set_dy_eligible(me, false);
+
+ return yielded;
}
EXPORT_SYMBOL_GPL(kvm_vcpu_on_spin);
--
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 RFC V9 14/19] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
From: Raghavendra K T
During migration, any vcpu that got kicked but did not become runnable
(still in halted state) should be runnable after migration.
Signed-off-by: Raghavendra K T
---
arch/x86/kvm/x86.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f8bea30..92a9932 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6243,7 +6243,12 @@ int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu
*vcpu,
struct kvm_mp_state *mp_state)
{
kvm_apic_accept_events(vcpu);
- mp_state->mp_state = vcpu->arch.mp_state;
+ if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED &&
+ vcpu->arch.pv.pv_unhalted)
+ mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
+ else
+ mp_state->mp_state = vcpu->arch.mp_state;
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC V9 11/19] xen/pvticketlock: Allow interrupts to be enabled while blocking
xen/pvticketlock: Allow interrupts to be enabled while blocking
From: Jeremy Fitzhardinge
If interrupts were enabled when taking the spinlock, we can leave them
enabled while blocking to get the lock.
If we can enable interrupts while waiting for the lock to become
available, and we take an interrupt before entering the poll,
and the handler takes a spinlock which ends up going into
the slow state (invalidating the per-cpu "lock" and "want" values),
then when the interrupt handler returns the event channel will
remain pending so the poll will return immediately, causing it to
return out to the main spinlock loop.
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Raghavendra K T
---
arch/x86/xen/spinlock.c | 46 --
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index a3b22e6..5e78ee9 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -140,7 +140,20 @@ static void xen_lock_spinning(struct arch_spinlock *lock,
__ticket_t want)
* partially setup state.
*/
local_irq_save(flags);
-
+ /*
+* We don't really care if we're overwriting some other
+* (lock,want) pair, as that would mean that we're currently
+* in an interrupt context, and the outer context had
+* interrupts enabled. That has already kicked the VCPU out
+* of xen_poll_irq(), so it will just return spuriously and
+* retry with newly setup (lock,want).
+*
+* The ordering protocol on this is that the "lock" pointer
+* may only be set non-NULL if the "want" ticket is correct.
+* If we're updating "want", we must first clear "lock".
+*/
+ w->lock = NULL;
+ smp_wmb();
w->want = want;
smp_wmb();
w->lock = lock;
@@ -155,24 +168,43 @@ static void xen_lock_spinning(struct arch_spinlock *lock,
__ticket_t want)
/* Only check lock once pending cleared */
barrier();
- /* Mark entry to slowpath before doing the pickup test to make
- sure we don't deadlock with an unlocker. */
+ /*
+* Mark entry to slowpath before doing the pickup test to make
+* sure we don't deadlock with an unlocker.
+*/
__ticket_enter_slowpath(lock);
- /* check again make sure it didn't become free while
- we weren't looking */
+ /*
+* check again make sure it didn't become free while
+* we weren't looking
+*/
if (ACCESS_ONCE(lock->tickets.head) == want) {
add_stats(TAKEN_SLOW_PICKUP, 1);
goto out;
}
+
+ /* Allow interrupts while blocked */
+ local_irq_restore(flags);
+
+ /*
+* If an interrupt happens here, it will leave the wakeup irq
+* pending, which will cause xen_poll_irq() to return
+* immediately.
+*/
+
/* Block until irq becomes pending (or perhaps a spurious wakeup) */
xen_poll_irq(irq);
add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq));
+
+ local_irq_save(flags);
+
kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
out:
cpumask_clear_cpu(cpu, _cpus);
w->lock = NULL;
+
local_irq_restore(flags);
+
spin_time_accum_blocked(start);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
@@ -186,7 +218,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock,
__ticket_t next)
for_each_cpu(cpu, _cpus) {
const struct xen_lock_waiting *w = _cpu(lock_waiting, cpu);
- if (w->lock == lock && w->want == next) {
+ /* Make sure we read lock before want */
+ if (ACCESS_ONCE(w->lock) == lock &&
+ ACCESS_ONCE(w->want) == next) {
add_stats(RELEASED_SLOW_KICKED, 1);
xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
}
--
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 RFC V9 15/19] kvm guest : Add configuration support to enable debug information for KVM Guests
kvm guest : Add configuration support to enable debug information for KVM Guests From: Srivatsa Vaddagiri Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/Kconfig |9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 80fcc4b..f8ff42d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -646,6 +646,15 @@ config KVM_GUEST underlying device model, the host provides the guest with timing infrastructure such as time of day, and system time +config KVM_DEBUG_FS + bool "Enable debug information for KVM Guests in debugfs" + depends on KVM_GUEST && DEBUG_FS + default n + ---help--- + This option enables collection of various statistics for KVM guest. + Statistics are displayed in debugfs filesystem. Enabling this option + may incur significant overhead. + source "arch/x86/lguest/Kconfig" config PARAVIRT_TIME_ACCOUNTING -- 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 RFC V9 17/19] kvm hypervisor : Simplify kvm_for_each_vcpu with kvm_irq_delivery_to_apic
Simplify kvm_for_each_vcpu with kvm_irq_delivery_to_apic
From: Raghavendra K T
Note that we are using APIC_DM_REMRD which has reserved usage.
In future if APIC_DM_REMRD usage is standardized, then we should
find some other way or go back to old method.
Suggested-by: Gleb Natapov
Signed-off-by: Raghavendra K T
---
arch/x86/kvm/lapic.c |5 -
arch/x86/kvm/x86.c | 25 ++---
2 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index e1adbb4..3f5f82e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -706,7 +706,10 @@ out:
break;
case APIC_DM_REMRD:
- apic_debug("Ignoring delivery mode 3\n");
+ result = 1;
+ vcpu->arch.pv.pv_unhalted = 1;
+ kvm_make_request(KVM_REQ_EVENT, vcpu);
+ kvm_vcpu_kick(vcpu);
break;
case APIC_DM_SMI:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 92a9932..b963c86 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5456,27 +5456,14 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
*/
static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
{
- struct kvm_vcpu *vcpu = NULL;
- int i;
+ struct kvm_lapic_irq lapic_irq;
- kvm_for_each_vcpu(i, vcpu, kvm) {
- if (!kvm_apic_present(vcpu))
- continue;
+ lapic_irq.shorthand = 0;
+ lapic_irq.dest_mode = 0;
+ lapic_irq.dest_id = apicid;
- if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
- break;
- }
- if (vcpu) {
- /*
-* Setting unhalt flag here can result in spurious runnable
-* state when unhalt reset does not happen in vcpu_block.
-* But that is harmless since that should soon result in halt.
-*/
- vcpu->arch.pv.pv_unhalted = true;
- /* We need everybody see unhalt before vcpu unblocks */
- smp_wmb();
- kvm_vcpu_kick(vcpu);
- }
+ lapic_irq.delivery_mode = APIC_DM_REMRD;
+ kvm_irq_delivery_to_apic(kvm, 0, _irq, NULL);
}
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
--
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 RFC V9 16/19] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
From: Srivatsa Vaddagiri
During smp_boot_cpus paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
support for pv-ticketlocks is registered via pv_lock_ops.
Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Suzuki Poulose
[Raghu: check_zero race fix, enum for kvm_contention_stat
jumplabel related changes ]
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/kvm_para.h | 14 ++
arch/x86/kernel/kvm.c | 256 +++
2 files changed, 268 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 695399f..427afcb 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,10 +118,20 @@ void kvm_async_pf_task_wait(u32 token);
void kvm_async_pf_task_wake(u32 token);
u32 kvm_read_and_reset_pf_reason(void);
extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
#define kvm_async_pf_task_wait(T) do {} while(0)
#define kvm_async_pf_task_wake(T) do {} while(0)
+
static inline u32 kvm_read_and_reset_pf_reason(void)
{
return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index cd6d9a5..2715b92 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -419,6 +420,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
+ kvm_spinlock_init();
}
static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -523,3 +525,257 @@ static __init int activate_jump_labels(void)
return 0;
}
arch_initcall(activate_jump_labels);
+
+/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
+void kvm_kick_cpu(int cpu)
+{
+ int apicid;
+
+ apicid = per_cpu(x86_cpu_to_apicid, cpu);
+ kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+ TAKEN_SLOW,
+ TAKEN_SLOW_PICKUP,
+ RELEASED_SLOW,
+ RELEASED_SLOW_KICKED,
+ NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS 30
+
+static struct kvm_spinlock_stats
+{
+ u32 contention_stats[NR_CONTENTION_STATS];
+ u32 histo_spin_blocked[HISTO_BUCKETS+1];
+ u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+ u8 ret;
+ u8 old;
+
+ old = ACCESS_ONCE(zero_stats);
+ if (unlikely(old)) {
+ ret = cmpxchg(_stats, old, 0);
+ /* This ensures only one fellow resets the stat */
+ if (ret == old)
+ memset(_stats, 0, sizeof(spinlock_stats));
+ }
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+ check_zero();
+ spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+ return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+ unsigned index;
+
+ index = ilog2(delta);
+ check_zero();
+
+ if (index < HISTO_BUCKETS)
+ array[index]++;
+ else
+ array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+ u32 delta;
+
+ delta = sched_clock() - start;
+ __spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+ spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+ d_kvm_debug = debugfs_create_dir("kvm", NULL);
+ if (!d_kvm_debug)
+ printk(KERN_WARNING "Could not create 'kvm' debugfs
directory\n");
+
+ return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+ struct dentry *d_kvm;
+
+ d_kvm = kvm_init_debugfs();
+ if (d_kvm == NULL)
+ return -ENOMEM;
+
+ d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+ debugfs_create_u8("zero_stats", 0644, d_spin_debug, _stats);
+
+ debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+ _stats.contention_stats[TAKEN_SLOW]);
+ debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
+ _stats.contention_stats[TAKEN_SLOW_PICKUP]);
+
+ debugfs_create_u32("released_slow",
[PATCH RFC V9 12/19] xen: Enable PV ticketlocks on HVM Xen
xen: Enable PV ticketlocks on HVM Xen From: Stefano Stabellini Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/smp.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index dcdc91c..8d2abf7 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -682,4 +682,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } -- 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 RFC V9 18/19] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock
Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock From: Raghavendra K T KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual spinlock enabled guest. KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled in guest. Thanks Vatsa for rewriting KVM_HC_KICK_CPU Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Raghavendra K T --- Documentation/virtual/kvm/cpuid.txt |4 Documentation/virtual/kvm/hypercalls.txt | 13 + 2 files changed, 17 insertions(+) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 83afe65..654f43c 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -43,6 +43,10 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by || || writing to msr 0x4b564d02 -- +KVM_FEATURE_PV_UNHALT || 6 || guest checks this feature bit + || || before enabling paravirtualized + || || spinlock support. +-- KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side || || per-cpu warps are expected in || || kvmclock. diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt index ea113b5..2a4da11 100644 --- a/Documentation/virtual/kvm/hypercalls.txt +++ b/Documentation/virtual/kvm/hypercalls.txt @@ -64,3 +64,16 @@ Purpose: To enable communication between the hypervisor and guest there is a shared page that contains parts of supervisor visible register state. The guest can map this shared page to access its supervisor register through memory using this hypercall. + +5. KVM_HC_KICK_CPU + +Architecture: x86 +Status: active +Purpose: Hypercall used to wakeup a vcpu from HLT state +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest +kernel mode for an event to occur (ex: a spinlock to become available) can +execute HLT instruction once it has busy-waited for more than a threshold +time-interval. Execution of HLT instruction would cause the hypervisor to put +the vcpu to sleep until occurence of an appropriate event. Another vcpu of the +same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, +specifying APIC ID of the vcpu to be wokenup. -- 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 RFC V9 10/19] x86/ticketlock: Add slowpath logic
x86/ticketlock: Add slowpath logic
From: Jeremy Fitzhardinge
Maintain a flag in the LSB of the ticket lock tail which indicates
whether anyone is in the lock slowpath and may need kicking when
the current holder unlocks. The flags are set when the first locker
enters the slowpath, and cleared when unlocking to an empty queue (ie,
no contention).
In the specific implementation of lock_spinning(), make sure to set
the slowpath flags on the lock just before blocking. We must do
this before the last-chance pickup test to prevent a deadlock
with the unlocker:
UnlockerLocker
test for lock pickup
-> fail
unlock
test slowpath
-> false
set slowpath flags
block
Whereas this works in any ordering:
UnlockerLocker
set slowpath flags
test for lock pickup
-> fail
block
unlock
test slowpath
-> true, kick
If the unlocker finds that the lock has the slowpath flag set but it is
actually uncontended (ie, head == tail, so nobody is waiting), then it
clears the slowpath flag.
The unlock code uses a locked add to update the head counter. This also
acts as a full memory barrier so that its safe to subsequently
read back the slowflag state, knowing that the updated lock is visible
to the other CPUs. If it were an unlocked add, then the flag read may
just be forwarded from the store buffer before it was visible to the other
CPUs, which could result in a deadlock.
Unfortunately this means we need to do a locked instruction when
unlocking with PV ticketlocks. However, if PV ticketlocks are not
enabled, then the old non-locked "add" is the only unlocking code.
Note: this code relies on gcc making sure that unlikely() code is out of
line of the fastpath, which only happens when OPTIMIZE_SIZE=n. If it
doesn't the generated code isn't too bad, but its definitely suboptimal.
Thanks to Srivatsa Vaddagiri for providing a bugfix to the original
version of this change, which has been folded in.
Thanks to Stephan Diestelhorst for commenting on some code which relied
on an inaccurate reading of the x86 memory ordering rules.
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Srivatsa Vaddagiri
Reviewed-by: Konrad Rzeszutek Wilk
Cc: Stephan Diestelhorst
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/paravirt.h |2 -
arch/x86/include/asm/spinlock.h | 86 -
arch/x86/include/asm/spinlock_types.h |2 +
arch/x86/kernel/paravirt-spinlocks.c |3 +
arch/x86/xen/spinlock.c |6 ++
5 files changed, 74 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 7131e12c..401f350 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -718,7 +718,7 @@ static __always_inline void __ticket_lock_spinning(struct
arch_spinlock *lock,
PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
}
-static __always_inline void ticket_unlock_kick(struct arch_spinlock *lock,
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
__ticket_t ticket)
{
PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 04a5cd5..d68883d 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -1,11 +1,14 @@
#ifndef _ASM_X86_SPINLOCK_H
#define _ASM_X86_SPINLOCK_H
+#include
#include
#include
#include
#include
#include
+#include
+
/*
* Your basic SMP spinlocks, allowing only a single CPU anywhere
*
@@ -37,32 +40,28 @@
/* How long a lock should spin before we consider blocking */
#define SPIN_THRESHOLD (1 << 15)
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
+extern struct static_key paravirt_ticketlocks_enabled;
+static __always_inline bool static_key_false(struct static_key *key);
-static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
- __ticket_t ticket)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
{
+ set_bit(0, (volatile unsigned long *)>tickets.tail);
}
-static __always_inline void ticket_unlock_kick(struct arch_spinlock *lock,
-__ticket_t ticket)
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+ __ticket_t ticket)
{
}
-
-#endif /* CONFIG_PARAVIRT_SPINLOCKS */
-
-
-/*
- * If a spinlock has someone waiting on it,
[PATCH RFC V9 13/19] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
From: Srivatsa Vaddagiri
kvm_hc_kick_cpu allows the calling vcpu to kick another vcpu out of halt state.
the presence of these hypercalls is indicated to guest via
kvm_feature_pv_unhalt.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Suzuki Poulose
[Raghu: Apic related changes, folding pvunhalted into vcpu_runnable]
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/kvm_host.h |5 +
arch/x86/include/uapi/asm/kvm_para.h |1 +
arch/x86/kvm/cpuid.c |3 ++-
arch/x86/kvm/x86.c | 37 ++
include/uapi/linux/kvm_para.h|1 +
5 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..95702de 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -503,6 +503,11 @@ struct kvm_vcpu_arch {
* instruction.
*/
bool write_fault_to_shadow_pgtable;
+
+ /* pv related host specific info */
+ struct {
+ bool pv_unhalted;
+ } pv;
};
struct kvm_lpage_info {
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 06fdbd9..94dc8ca 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -23,6 +23,7 @@
#define KVM_FEATURE_ASYNC_PF 4
#define KVM_FEATURE_STEAL_TIME 5
#define KVM_FEATURE_PV_EOI 6
+#define KVM_FEATURE_PV_UNHALT 7
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a20ecb5..b110fe6 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -413,7 +413,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32
function,
(1 << KVM_FEATURE_CLOCKSOURCE2) |
(1 << KVM_FEATURE_ASYNC_PF) |
(1 << KVM_FEATURE_PV_EOI) |
-(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+(1 << KVM_FEATURE_PV_UNHALT);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..f8bea30 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5449,6 +5449,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
return 1;
}
+/*
+ * kvm_pv_kick_cpu_op: Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+ struct kvm_vcpu *vcpu = NULL;
+ int i;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (!kvm_apic_present(vcpu))
+ continue;
+
+ if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+ break;
+ }
+ if (vcpu) {
+ /*
+* Setting unhalt flag here can result in spurious runnable
+* state when unhalt reset does not happen in vcpu_block.
+* But that is harmless since that should soon result in halt.
+*/
+ vcpu->arch.pv.pv_unhalted = true;
+ /* We need everybody see unhalt before vcpu unblocks */
+ smp_wmb();
+ kvm_vcpu_kick(vcpu);
+ }
+}
+
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
@@ -5482,6 +5512,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_VAPIC_POLL_IRQ:
ret = 0;
break;
+ case KVM_HC_KICK_CPU:
+ kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+ ret = 0;
+ break;
default:
ret = -KVM_ENOSYS;
break;
@@ -5909,6 +5943,7 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
kvm_apic_accept_events(vcpu);
switch(vcpu->arch.mp_state) {
case KVM_MP_STATE_HALTED:
+ vcpu->arch.pv.pv_unhalted = false;
vcpu->arch.mp_state =
KVM_MP_STATE_RUNNABLE;
case KVM_MP_STATE_RUNNABLE:
@@ -6729,6 +6764,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
BUG_ON(vcpu->kvm == NULL);
kvm = vcpu->kvm;
+ vcpu->arch.pv.pv_unhalted = false;
vcpu->arch.emulate_ctxt.ops = _ops;
if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu))
vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
@@ -7065,6 +7101,7 @@ int
[PATCH RFC V9 5/19] xen/pvticketlock: Xen implementation for PV ticket locks
xen/pvticketlock: Xen implementation for PV ticket locks
From: Jeremy Fitzhardinge
Replace the old Xen implementation of PV spinlocks with and implementation
of xen_lock_spinning and xen_unlock_kick.
xen_lock_spinning simply registers the cpu in its entry in lock_waiting,
adds itself to the waiting_cpus set, and blocks on an event channel
until the channel becomes pending.
xen_unlock_kick searches the cpus in waiting_cpus looking for the one
which next wants this lock with the next ticket, if any. If found,
it kicks it by making its event channel pending, which wakes it up.
We need to make sure interrupts are disabled while we're relying on the
contents of the per-cpu lock_waiting values, otherwise an interrupt
handler could come in, try to take some other lock, block, and overwrite
our values.
Raghu: use function + enum instead of macro, cmpxchg for zero status reset
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Raghavendra K T
---
arch/x86/xen/spinlock.c | 347 +++
1 file changed, 78 insertions(+), 269 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index d6481a9..860e190 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -16,45 +16,44 @@
#include "xen-ops.h"
#include "debugfs.h"
-#ifdef CONFIG_XEN_DEBUG_FS
-static struct xen_spinlock_stats
-{
- u64 taken;
- u32 taken_slow;
- u32 taken_slow_nested;
- u32 taken_slow_pickup;
- u32 taken_slow_spurious;
- u32 taken_slow_irqenable;
+enum xen_contention_stat {
+ TAKEN_SLOW,
+ TAKEN_SLOW_PICKUP,
+ TAKEN_SLOW_SPURIOUS,
+ RELEASED_SLOW,
+ RELEASED_SLOW_KICKED,
+ NR_CONTENTION_STATS
+};
- u64 released;
- u32 released_slow;
- u32 released_slow_kicked;
+#ifdef CONFIG_XEN_DEBUG_FS
#define HISTO_BUCKETS 30
- u32 histo_spin_total[HISTO_BUCKETS+1];
- u32 histo_spin_spinning[HISTO_BUCKETS+1];
+static struct xen_spinlock_stats
+{
+ u32 contention_stats[NR_CONTENTION_STATS];
u32 histo_spin_blocked[HISTO_BUCKETS+1];
-
- u64 time_total;
- u64 time_spinning;
u64 time_blocked;
} spinlock_stats;
static u8 zero_stats;
-static unsigned lock_timeout = 1 << 10;
-#define TIMEOUT lock_timeout
-
static inline void check_zero(void)
{
- if (unlikely(zero_stats)) {
- memset(_stats, 0, sizeof(spinlock_stats));
- zero_stats = 0;
+ u8 ret;
+ u8 old = ACCESS_ONCE(zero_stats);
+ if (unlikely(old)) {
+ ret = cmpxchg(_stats, old, 0);
+ /* This ensures only one fellow resets the stat */
+ if (ret == old)
+ memset(_stats, 0, sizeof(spinlock_stats));
}
}
-#define ADD_STATS(elem, val) \
- do { check_zero(); spinlock_stats.elem += (val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+ check_zero();
+ spinlock_stats.contention_stats[var] += val;
+}
static inline u64 spin_time_start(void)
{
@@ -73,22 +72,6 @@ static void __spin_time_accum(u64 delta, u32 *array)
array[HISTO_BUCKETS]++;
}
-static inline void spin_time_accum_spinning(u64 start)
-{
- u32 delta = xen_clocksource_read() - start;
-
- __spin_time_accum(delta, spinlock_stats.histo_spin_spinning);
- spinlock_stats.time_spinning += delta;
-}
-
-static inline void spin_time_accum_total(u64 start)
-{
- u32 delta = xen_clocksource_read() - start;
-
- __spin_time_accum(delta, spinlock_stats.histo_spin_total);
- spinlock_stats.time_total += delta;
-}
-
static inline void spin_time_accum_blocked(u64 start)
{
u32 delta = xen_clocksource_read() - start;
@@ -98,19 +81,15 @@ static inline void spin_time_accum_blocked(u64 start)
}
#else /* !CONFIG_XEN_DEBUG_FS */
#define TIMEOUT(1 << 10)
-#define ADD_STATS(elem, val) do { (void)(val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+}
static inline u64 spin_time_start(void)
{
return 0;
}
-static inline void spin_time_accum_total(u64 start)
-{
-}
-static inline void spin_time_accum_spinning(u64 start)
-{
-}
static inline void spin_time_accum_blocked(u64 start)
{
}
@@ -133,229 +112,82 @@ typedef u16 xen_spinners_t;
asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
#endif
-struct xen_spinlock {
- unsigned char lock; /* 0 -> free; 1 -> locked */
- xen_spinners_t spinners;/* count of waiting cpus */
+struct xen_lock_waiting {
+ struct arch_spinlock *lock;
+ __ticket_t want;
};
static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting);
+static cpumask_t waiting_cpus;
-#if 0
-static int xen_spin_is_locked(struct arch_spinlock *lock)
-{
-
[PATCH RFC V9 8/19] x86/pvticketlock: When paravirtualizing ticket locks, increment by 2
x86/pvticketlock: When paravirtualizing ticket locks, increment by 2
From: Jeremy Fitzhardinge
Increment ticket head/tails by 2 rather than 1 to leave the LSB free
to store a "is in slowpath state" bit. This halves the number
of possible CPUs for a given ticket size, but this shouldn't matter
in practice - kernels built for 32k+ CPU systems are probably
specially built for the hardware rather than a generic distro
kernel.
Signed-off-by: Jeremy Fitzhardinge
Tested-by: Attilio Rao
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/spinlock.h | 10 +-
arch/x86/include/asm/spinlock_types.h | 10 +-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 7442410..04a5cd5 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -78,7 +78,7 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
*/
static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
{
- register struct __raw_tickets inc = { .tail = 1 };
+ register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
inc = xadd(>tickets, inc);
@@ -104,7 +104,7 @@ static __always_inline int
arch_spin_trylock(arch_spinlock_t *lock)
if (old.tickets.head != old.tickets.tail)
return 0;
- new.head_tail = old.head_tail + (1 << TICKET_SHIFT);
+ new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT);
/* cmpxchg is a full barrier, so nothing can move before it */
return cmpxchg(>head_tail, old.head_tail, new.head_tail) ==
old.head_tail;
@@ -112,9 +112,9 @@ static __always_inline int
arch_spin_trylock(arch_spinlock_t *lock)
static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- __ticket_t next = lock->tickets.head + 1;
+ __ticket_t next = lock->tickets.head + TICKET_LOCK_INC;
- __add(>tickets.head, 1, UNLOCK_LOCK_PREFIX);
+ __add(>tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
__ticket_unlock_kick(lock, next);
}
@@ -129,7 +129,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t
*lock)
{
struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
- return (__ticket_t)(tmp.tail - tmp.head) > 1;
+ return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC;
}
#define arch_spin_is_contended arch_spin_is_contended
diff --git a/arch/x86/include/asm/spinlock_types.h
b/arch/x86/include/asm/spinlock_types.h
index 83fd3c7..e96fcbd 100644
--- a/arch/x86/include/asm/spinlock_types.h
+++ b/arch/x86/include/asm/spinlock_types.h
@@ -3,7 +3,13 @@
#include
-#if (CONFIG_NR_CPUS < 256)
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#define __TICKET_LOCK_INC 2
+#else
+#define __TICKET_LOCK_INC 1
+#endif
+
+#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC))
typedef u8 __ticket_t;
typedef u16 __ticketpair_t;
#else
@@ -11,6 +17,8 @@ typedef u16 __ticket_t;
typedef u32 __ticketpair_t;
#endif
+#define TICKET_LOCK_INC((__ticket_t)__TICKET_LOCK_INC)
+
#define TICKET_SHIFT (sizeof(__ticket_t) * 8)
typedef struct arch_spinlock {
--
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 RFC V9 4/19] xen: Defer spinlock setup until boot CPU setup
xen: Defer spinlock setup until boot CPU setup
From: Jeremy Fitzhardinge
There's no need to do it at very early init, and doing it there
makes it impossible to use the jump_label machinery.
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Raghavendra K T
---
arch/x86/xen/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8ff3799..dcdc91c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -246,6 +246,7 @@ static void __init xen_smp_prepare_boot_cpu(void)
xen_filter_cpu_maps();
xen_setup_vcpu_info_placement();
+ xen_init_spinlocks();
}
static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
@@ -647,7 +648,6 @@ void __init xen_smp_init(void)
{
smp_ops = xen_smp_ops;
xen_fill_possible_map();
- xen_init_spinlocks();
}
static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
--
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 RFC V9 7/19] x86/pvticketlock: Use callee-save for lock_spinning
x86/pvticketlock: Use callee-save for lock_spinning
From: Jeremy Fitzhardinge
Although the lock_spinning calls in the spinlock code are on the
uncommon path, their presence can cause the compiler to generate many
more register save/restores in the function pre/postamble, which is in
the fast path. To avoid this, convert it to using the pvops callee-save
calling convention, which defers all the save/restores until the actual
function is called, keeping the fastpath clean.
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Tested-by: Attilio Rao
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/paravirt.h |2 +-
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86/kernel/paravirt-spinlocks.c |2 +-
arch/x86/xen/spinlock.c |3 ++-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 040e72d..7131e12c 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -715,7 +715,7 @@ static inline void __set_fixmap(unsigned /* enum
fixed_addresses */ idx,
static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
__ticket_t ticket)
{
- PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
+ PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
}
static __always_inline void ticket_unlock_kick(struct arch_spinlock *lock,
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index d5deb6d..350d017 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -330,7 +330,7 @@ struct arch_spinlock;
#include
struct pv_lock_ops {
- void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+ struct paravirt_callee_save lock_spinning;
void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
};
diff --git a/arch/x86/kernel/paravirt-spinlocks.c
b/arch/x86/kernel/paravirt-spinlocks.c
index c2e010e..4251c1d 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -9,7 +9,7 @@
struct pv_lock_ops pv_lock_ops = {
#ifdef CONFIG_SMP
- .lock_spinning = paravirt_nop,
+ .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop),
.unlock_kick = paravirt_nop,
#endif
};
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 3de6805..5502fda 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -171,6 +171,7 @@ out:
local_irq_restore(flags);
spin_time_accum_blocked(start);
}
+PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning);
static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next)
{
@@ -254,7 +255,7 @@ void __init xen_init_spinlocks(void)
return;
}
- pv_lock_ops.lock_spinning = xen_lock_spinning;
+ pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning);
pv_lock_ops.unlock_kick = xen_unlock_kick;
}
--
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 RFC V9 9/19] Split out rate limiting from jump_label.h
Split jumplabel ratelimit
From: Andrew Jones
Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting
for jump label disabling. The changes were made in the jump label code
in order to be more widely available and to keep things tidier. This is
all fine, except now jump_label.h includes linux/workqueue.h, which
makes it impossible to include jump_label.h from anything that
workqueue.h needs. For example, it's now impossible to include
jump_label.h from asm/spinlock.h, which is done in proposed
pv-ticketlock patches. This patch splits out the rate limiting related
changes from jump_label.h into a new file, jump_label_ratelimit.h, to
resolve the issue.
Signed-off-by: Andrew Jones
Signed-off-by: Raghavendra K T
---
include/linux/jump_label.h | 26 +-
include/linux/jump_label_ratelimit.h | 34 ++
include/linux/perf_event.h |1 +
kernel/jump_label.c |1 +
4 files changed, 37 insertions(+), 25 deletions(-)
create mode 100644 include/linux/jump_label_ratelimit.h
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 0976fc4..53cdf89 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,7 +48,6 @@
#include
#include
-#include
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
@@ -61,12 +60,6 @@ struct static_key {
#endif
};
-struct static_key_deferred {
- struct static_key key;
- unsigned long timeout;
- struct delayed_work work;
-};
-
# include
# define HAVE_JUMP_LABEL
#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -119,10 +112,7 @@ extern void arch_jump_label_transform_static(struct
jump_entry *entry,
extern int jump_label_text_reserved(void *start, void *end);
extern void static_key_slow_inc(struct static_key *key);
extern void static_key_slow_dec(struct static_key *key);
-extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
extern void jump_label_apply_nops(struct module *mod);
-extern void
-jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
#define STATIC_KEY_INIT_TRUE ((struct static_key) \
{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
@@ -141,10 +131,6 @@ static __always_inline void jump_label_init(void)
{
}
-struct static_key_deferred {
- struct static_key key;
-};
-
static __always_inline bool static_key_false(struct static_key *key)
{
if (unlikely(atomic_read(>enabled)) > 0)
@@ -169,11 +155,6 @@ static inline void static_key_slow_dec(struct static_key
*key)
atomic_dec(>enabled);
}
-static inline void static_key_slow_dec_deferred(struct static_key_deferred
*key)
-{
- static_key_slow_dec(>key);
-}
-
static inline int jump_label_text_reserved(void *start, void *end)
{
return 0;
@@ -187,12 +168,6 @@ static inline int jump_label_apply_nops(struct module *mod)
return 0;
}
-static inline void
-jump_label_rate_limit(struct static_key_deferred *key,
- unsigned long rl)
-{
-}
-
#define STATIC_KEY_INIT_TRUE ((struct static_key) \
{ .enabled = ATOMIC_INIT(1) })
#define STATIC_KEY_INIT_FALSE ((struct static_key) \
@@ -203,6 +178,7 @@ jump_label_rate_limit(struct static_key_deferred *key,
#define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
#define jump_label_enabled static_key_enabled
+static inline int atomic_read(const atomic_t *v);
static inline bool static_key_enabled(struct static_key *key)
{
return (atomic_read(>enabled) > 0);
diff --git a/include/linux/jump_label_ratelimit.h
b/include/linux/jump_label_ratelimit.h
new file mode 100644
index 000..1137883
--- /dev/null
+++ b/include/linux/jump_label_ratelimit.h
@@ -0,0 +1,34 @@
+#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H
+#define _LINUX_JUMP_LABEL_RATELIMIT_H
+
+#include
+#include
+
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+struct static_key_deferred {
+ struct static_key key;
+ unsigned long timeout;
+ struct delayed_work work;
+};
+#endif
+
+#ifdef HAVE_JUMP_LABEL
+extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void
+jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
+
+#else /* !HAVE_JUMP_LABEL */
+struct static_key_deferred {
+ struct static_key key;
+};
+static inline void static_key_slow_dec_deferred(struct static_key_deferred
*key)
+{
+ static_key_slow_dec(>key);
+}
+static inline void
+jump_label_rate_limit(struct static_key_deferred *key,
+ unsigned long rl)
+{
+}
+#endif /* HAVE_JUMP_LABEL */
+#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f463a46..a8eac60 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -48,6 +48,7 @@ struct perf_guest_info_callbacks {
#include
#include
#include
+#include
#include
#include
#include
diff --git
[PATCH RFC V9 6/19] xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks
xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks
From: Jeremy Fitzhardinge
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Raghavendra K T
---
arch/x86/xen/spinlock.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 860e190..3de6805 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -238,6 +238,8 @@ void xen_uninit_lock_cpu(int cpu)
per_cpu(lock_kicker_irq, cpu) = -1;
}
+static bool xen_pvspin __initdata = true;
+
void __init xen_init_spinlocks(void)
{
/*
@@ -247,10 +249,22 @@ void __init xen_init_spinlocks(void)
if (xen_hvm_domain())
return;
+ if (!xen_pvspin) {
+ printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+ return;
+ }
+
pv_lock_ops.lock_spinning = xen_lock_spinning;
pv_lock_ops.unlock_kick = xen_unlock_kick;
}
+static __init int xen_parse_nopvspin(char *arg)
+{
+ xen_pvspin = false;
+ return 0;
+}
+early_param("xen_nopvspin", xen_parse_nopvspin);
+
#ifdef CONFIG_XEN_DEBUG_FS
static struct dentry *d_spin_debug;
--
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] usb: musb: use the new %pa format specifier for dma_addr_t
This patch makes use of the new format specifier %pa that was introduced
by the following commit.
7d7992108d02aa92ad4c77e5d9ce14088c942e75
("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
The addition of urb->transfer_dma and urb->actual_length is also done a
few lines below. I have moved this code up and pass the variable buf to
dev_dbg.
Signed-off-by: Emil Goode
---
v2: Remove 0x from string as it will print as 0x0x
This applies on top of commit 43d5ad743c6f
("usb: musb: host: fix build warning")
I also added braces to the else statement for consistency.
(Didn't want to send a separate patch for that)
drivers/usb/musb/musb_host.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index a9695f5..ee7730a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
dma_addr_t buf;
rx_count = musb_readw(epio, MUSB_RXCOUNT);
+ buf = urb->transfer_dma + urb->actual_length;
- dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
len %d/%d\n",
+ dev_dbg(musb->controller, "RX%d count %d, buffer %pa
len %d/%d\n",
epnum, rx_count,
- (unsigned long long) urb->transfer_dma
- + urb->actual_length,
- qh->offset,
+ , qh->offset,
urb->transfer_buffer_length);
c = musb->dma_controller;
@@ -1785,14 +1784,13 @@ void musb_host_rx(struct musb *musb, u8 epnum)
rx_count, d->length);
length = d->length;
- } else
+ } else {
length = rx_count;
+ }
d->status = d_status;
buf = urb->transfer_dma + d->offset;
} else {
length = rx_count;
- buf = urb->transfer_dma +
- urb->actual_length;
}
dma->desired_mode = 0;
--
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 RFC V9 3/19] x86/ticketlock: Collapse a layer of functions
x86/ticketlock: Collapse a layer of functions
From: Jeremy Fitzhardinge
Now that the paravirtualization layer doesn't exist at the spinlock
level any more, we can collapse the __ticket_ functions into the arch_
functions.
Signed-off-by: Jeremy Fitzhardinge
Tested-by: Attilio Rao
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/spinlock.h | 35 +--
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 4d54244..7442410 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -76,7 +76,7 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
* in the high part, because a wide xadd increment of the low part would carry
* up and contaminate the high part.
*/
-static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock)
+static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
{
register struct __raw_tickets inc = { .tail = 1 };
@@ -96,7 +96,7 @@ static __always_inline void __ticket_spin_lock(struct
arch_spinlock *lock)
out: barrier(); /* make sure nothing creeps before the lock is taken */
}
-static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
+static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
{
arch_spinlock_t old, new;
@@ -110,7 +110,7 @@ static __always_inline int
__ticket_spin_trylock(arch_spinlock_t *lock)
return cmpxchg(>head_tail, old.head_tail, new.head_tail) ==
old.head_tail;
}
-static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
+static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
{
__ticket_t next = lock->tickets.head + 1;
@@ -118,46 +118,21 @@ static __always_inline void
__ticket_spin_unlock(arch_spinlock_t *lock)
__ticket_unlock_kick(lock, next);
}
-static inline int __ticket_spin_is_locked(arch_spinlock_t *lock)
+static inline int arch_spin_is_locked(arch_spinlock_t *lock)
{
struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
return tmp.tail != tmp.head;
}
-static inline int __ticket_spin_is_contended(arch_spinlock_t *lock)
+static inline int arch_spin_is_contended(arch_spinlock_t *lock)
{
struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
return (__ticket_t)(tmp.tail - tmp.head) > 1;
}
-
-static inline int arch_spin_is_locked(arch_spinlock_t *lock)
-{
- return __ticket_spin_is_locked(lock);
-}
-
-static inline int arch_spin_is_contended(arch_spinlock_t *lock)
-{
- return __ticket_spin_is_contended(lock);
-}
#define arch_spin_is_contended arch_spin_is_contended
-static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
-{
- __ticket_spin_lock(lock);
-}
-
-static __always_inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
- return __ticket_spin_trylock(lock);
-}
-
-static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
- __ticket_spin_unlock(lock);
-}
-
static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
unsigned long flags)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC V9 2/19] x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks
x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks From: Raghavendra K T The code size expands somewhat, and its better to just call a function rather than inline it. Thanks Jeremy for original version of ARCH_NOINLINE_SPIN_UNLOCK config patch, which is simplified. Suggested-by: Linus Torvalds Signed-off-by: Raghavendra K T --- arch/x86/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 685692c..80fcc4b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -621,6 +621,7 @@ config PARAVIRT_DEBUG config PARAVIRT_SPINLOCKS bool "Paravirtualization layer for spinlocks" depends on PARAVIRT && SMP + select UNINLINE_SPIN_UNLOCK ---help--- Paravirtualized spinlocks allow a pvops backend to replace the spinlock implementation with something virtualization-friendly -- 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 RFC V9 1/19] x86/spinlock: Replace pv spinlocks with pv ticketlocks
x86/spinlock: Replace pv spinlocks with pv ticketlocks
From: Jeremy Fitzhardinge
Rather than outright replacing the entire spinlock implementation in
order to paravirtualize it, keep the ticket lock implementation but add
a couple of pvops hooks on the slow patch (long spin on lock, unlocking
a contended lock).
Ticket locks have a number of nice properties, but they also have some
surprising behaviours in virtual environments. They enforce a strict
FIFO ordering on cpus trying to take a lock; however, if the hypervisor
scheduler does not schedule the cpus in the correct order, the system can
waste a huge amount of time spinning until the next cpu can take the lock.
(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)
To address this, we add two hooks:
- __ticket_spin_lock which is called after the cpu has been
spinning on the lock for a significant number of iterations but has
failed to take the lock (presumably because the cpu holding the lock
has been descheduled). The lock_spinning pvop is expected to block
the cpu until it has been kicked by the current lock holder.
- __ticket_spin_unlock, which on releasing a contended lock
(there are more cpus with tail tickets), it looks to see if the next
cpu is blocked and wakes it if so.
When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub
functions causes all the extra code to go away.
Signed-off-by: Jeremy Fitzhardinge
Reviewed-by: Konrad Rzeszutek Wilk
Tested-by: Attilio Rao
[ Raghavendra: Changed SPIN_THRESHOLD ]
Signed-off-by: Raghavendra K T
---
arch/x86/include/asm/paravirt.h | 32
arch/x86/include/asm/paravirt_types.h | 10 ++
arch/x86/include/asm/spinlock.h | 53 +++--
arch/x86/include/asm/spinlock_types.h |4 --
arch/x86/kernel/paravirt-spinlocks.c | 15 +
arch/x86/xen/spinlock.c |8 -
6 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index cfdc9ee..040e72d 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -712,36 +712,16 @@ static inline void __set_fixmap(unsigned /* enum
fixed_addresses */ idx,
#if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
-static inline int arch_spin_is_locked(struct arch_spinlock *lock)
+static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
+ __ticket_t ticket)
{
- return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock);
+ PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket);
}
-static inline int arch_spin_is_contended(struct arch_spinlock *lock)
+static __always_inline void ticket_unlock_kick(struct arch_spinlock *lock,
+ __ticket_t ticket)
{
- return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock);
-}
-#define arch_spin_is_contended arch_spin_is_contended
-
-static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
-{
- PVOP_VCALL1(pv_lock_ops.spin_lock, lock);
-}
-
-static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock,
- unsigned long flags)
-{
- PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags);
-}
-
-static __always_inline int arch_spin_trylock(struct arch_spinlock *lock)
-{
- return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock);
-}
-
-static __always_inline void arch_spin_unlock(struct arch_spinlock *lock)
-{
- PVOP_VCALL1(pv_lock_ops.spin_unlock, lock);
+ PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
}
#endif
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 0db1fca..d5deb6d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -327,13 +327,11 @@ struct pv_mmu_ops {
};
struct arch_spinlock;
+#include
+
struct pv_lock_ops {
- int (*spin_is_locked)(struct arch_spinlock *lock);
- int (*spin_is_contended)(struct arch_spinlock *lock);
- void (*spin_lock)(struct arch_spinlock *lock);
- void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long
flags);
- int (*spin_trylock)(struct arch_spinlock *lock);
- void (*spin_unlock)(struct arch_spinlock *lock);
+ void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket);
+ void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
};
/* This contains all the paravirt structures: we get a convenient
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 33692ea..4d54244 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -34,6 +34,35 @@
# define UNLOCK_LOCK_PREFIX
#endif
+/* How long a
[PATCH RFC V9 0/19] Paravirtualized ticket spinlocks
This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism. The series provides
implementation for both Xen and KVM.
Changes in V9:
- Changed spin_threshold to 32k to avoid excess halt exits that are
causing undercommit degradation (after PLE handler improvement).
- Added kvm_irq_delivery_to_apic (suggested by Gleb)
- Optimized halt exit path to use PLE handler
V8 of PVspinlock was posted last year. After Avi's suggestions to look
at PLE handler's improvements, various optimizations in PLE handling
have been tried.
With this series we see that we could get little more improvements on top
of that.
Ticket locks have an inherent problem in a virtualized case, because
the vCPUs are scheduled rather than running concurrently (ignoring
gang scheduled vCPUs). This can result in catastrophic performance
collapses when the vCPU scheduler doesn't schedule the correct "next"
vCPU, and ends up scheduling a vCPU which burns its entire timeslice
spinning. (Note that this is not the same problem as lock-holder
preemption, which this series also addresses; that's also a problem,
but not catastrophic).
(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)
Currently we deal with this by having PV spinlocks, which adds a layer
of indirection in front of all the spinlock functions, and defining a
completely new implementation for Xen (and for other pvops users, but
there are none at present).
PV ticketlocks keeps the existing ticketlock implemenentation
(fastpath) as-is, but adds a couple of pvops for the slow paths:
- If a CPU has been waiting for a spinlock for SPIN_THRESHOLD
iterations, then call out to the __ticket_lock_spinning() pvop,
which allows a backend to block the vCPU rather than spinning. This
pvop can set the lock into "slowpath state".
- When releasing a lock, if it is in "slowpath state", the call
__ticket_unlock_kick() to kick the next vCPU in line awake. If the
lock is no longer in contention, it also clears the slowpath flag.
The "slowpath state" is stored in the LSB of the within the lock tail
ticket. This has the effect of reducing the max number of CPUs by
half (so, a "small ticket" can deal with 128 CPUs, and "large ticket"
32768).
For KVM, one hypercall is introduced in hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.
Overall, it results in a large reduction in code, it makes the native
and virtualized cases closer, and it removes a layer of indirection
around all the spinlock functions.
The fast path (taking an uncontended lock which isn't in "slowpath"
state) is optimal, identical to the non-paravirtualized case.
The inner part of ticket lock code becomes:
inc = xadd(>tickets, inc);
inc.tail &= ~TICKET_SLOWPATH_FLAG;
if (likely(inc.head == inc.tail))
goto out;
for (;;) {
unsigned count = SPIN_THRESHOLD;
do {
if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
goto out;
cpu_relax();
} while (--count);
__ticket_lock_spinning(lock, inc.tail);
}
out:barrier();
which results in:
push %rbp
mov%rsp,%rbp
mov$0x200,%eax
lock xadd %ax,(%rdi)
movzbl %ah,%edx
cmp%al,%dl
jne1f # Slowpath if lock in contention
pop%rbp
retq
### SLOWPATH START
1: and$-2,%edx
movzbl %dl,%esi
2: mov$0x800,%eax
jmp4f
3: pause
sub$0x1,%eax
je 5f
4: movzbl (%rdi),%ecx
cmp%cl,%dl
jne3b
pop%rbp
retq
5: callq *__ticket_lock_spinning
jmp2b
### SLOWPATH END
with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where
the fastpath case is straight through (taking the lock without
contention), and the spin loop is out of line:
push %rbp
mov%rsp,%rbp
mov$0x100,%eax
lock xadd %ax,(%rdi)
movzbl %ah,%edx
cmp%al,%dl
jne1f
pop%rbp
retq
### SLOWPATH START
1: pause
movzbl (%rdi),%eax
cmp%dl,%al
jne1b
pop%rbp
retq
### SLOWPATH END
The unlock code is complicated by the need to both add to the lock's
"head" and fetch the slowpath flag from "tail". This version of the
patch uses a locked add to do this, followed by a test to see if the
slowflag is set. The lock prefix acts as a full memory barrier, so we
can be sure that other CPUs will have seen the unlock before we read
the flag (without the barrier the read could be fetched from the
store queue
Re: [PATCH] regmap: regcache-rbtree: Fixed node range check on sync
On Fri, May 31, 2013 at 04:45:13PM +0200, Maarten ter Huurne wrote: > A node starting before the minimum register is no reason to reject it, > since its end could be in range. The check for the end already exists > two lines lower, so we can just remove the incorrect check. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] usb: musb: use the new %pa format specifier for dma_addr_t
I see, will send a second version.
Thank's
Emil
On Sat, Jun 01, 2013 at 11:29:10AM -0700, Joe Perches wrote:
> On Sat, 2013-06-01 at 20:02 +0200, Emil Goode wrote:
> > This patch makes use of the new format specifier %pa that was introduced
> > by the following commit.
> >
> > 7d7992108d02aa92ad4c77e5d9ce14088c942e75
> > ("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
> []
> > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> []
> > @@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
> []
> > - dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
> > len %d/%d\n",
> > + dev_dbg(musb->controller, "RX%d count %d, buffer 0x%pa
> > len %d/%d\n",
>
> This would emit 0x0x
>
> When you use %pa, don't add 0x
>
>
--
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] regmap: regcache-flat: Implemented sync operation
On Fri, May 31, 2013 at 04:36:15PM +0200, Maarten ter Huurne wrote: > > Signed-off-by: Maarten ter Huurne This should probably just go into regcache.c as a default sync operation based on doing reads rather than being open coded - it's not meanigfully using any features of the cache data structure really. signature.asc Description: Digital signature
Re: [PATCH -next] blackfin: bf533-stamp: Remove bogus "||"
On Fri, May 31, 2013 at 01:40:47PM +0200, Lars-Peter Clausen wrote: > Mark can you queue it up in your topic/blackfin branch? Only if someone were to send me the patch. Geert, you should *ALWAYS* CC maintainers. signature.asc Description: Digital signature
sem_otime trashing
Hi Rik,
I finally managed to get EFI boot, i.e. I'm now able to test on my i3
(2core+HT).
With semscale (i.e.: just overhead, perform semop=0 operations), the
scalability from 1 to 2 cores is good, but not linear:
# semscale 10 | grep "interleave 2"
Cpus 1, interleave 2 delay 0: 35502103 in 10 secs
Cpus 2, interleave 2 delay 0: 53990954 in 10 secs
---
+53% when adding the 2nd core
(interleave 2 to force to use different cores)
Did you consider moving sem_otime into the individual semaphores?
I did that (gross patch attached), and the performance is significantly
better:
# semscale 10 | grep "interleave 2"
Cpus 1, interleave 2 delay 0: 35585634 in 10 secs
Cpus 2, interleave 2 delay 0: 70410230 in 10 secs
---
+99% scalability when adding the 2nd core
Unfortunately I won't be able to read my mails next week, but the effect
was too significant not to share it immediately.
--
Manfred
diff --git a/Makefile b/Makefile
index 73e20db..42137ab 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 10
SUBLEVEL = 0
-EXTRAVERSION = -rc3
+EXTRAVERSION = -rc3-otime
NAME = Unicycling Gorilla
# *DOCUMENTATION*
diff --git a/include/linux/sem.h b/include/linux/sem.h
index 55e17f6..976ce3a 100644
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@ -12,7 +12,6 @@ struct task_struct;
struct sem_array {
struct kern_ipc_permcacheline_aligned_in_smp
sem_perm; /* permissions .. see ipc.h */
- time_t sem_otime; /* last semop time */
time_t sem_ctime; /* last change time */
struct sem *sem_base; /* ptr to first semaphore in
array */
struct list_headpending_alter; /* pending operations */
diff --git a/ipc/sem.c b/ipc/sem.c
index 1dbb2fa..e5f000f 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -92,6 +92,7 @@
/* One semaphore structure for each semaphore in the system. */
struct sem {
+ charfiller[64];
int semval; /* current value */
int sempid; /* pid of last operation */
spinlock_t lock; /* spinlock for fine-grained semtimedop */
@@ -99,7 +100,8 @@ struct sem {
/* that alter the semaphore */
struct list_head pending_const; /* pending single-sop operations */
/* that do not alter the semaphore*/
-};
+ time_t sem_otime; /* candidate for sem_otime */
+} cacheline_aligned_in_smp;
/* One queue for each sleeping process in the system. */
struct sem_queue {
@@ -919,8 +921,14 @@ static void do_smart_update(struct sem_array *sma, struct
sembuf *sops, int nsop
}
}
}
- if (otime)
- sma->sem_otime = get_seconds();
+ if (otime) {
+ if (sops == NULL) {
+ sma->sem_base[0].sem_otime = get_seconds();
+ } else {
+ sma->sem_base[sops[0].sem_num].sem_otime =
+ get_seconds();
+ }
+ }
}
@@ -1066,6 +1074,21 @@ static unsigned long copy_semid_to_user(void __user
*buf, struct semid64_ds *in,
}
}
+static time_t get_semotime(struct sem_array *sma)
+{
+ int i;
+ time_t res;
+
+ res = sma->sem_base[0].sem_otime;
+ for (i = 1; i < sma->sem_nsems; i++) {
+ time_t to = sma->sem_base[i].sem_otime;
+
+ if (to > res)
+ res = to;
+ }
+ return res;
+}
+
static int semctl_nolock(struct ipc_namespace *ns, int semid,
int cmd, int version, void __user *p)
{
@@ -1139,9 +1162,9 @@ static int semctl_nolock(struct ipc_namespace *ns, int
semid,
goto out_unlock;
kernel_to_ipc64_perm(>sem_perm, _perm);
- tbuf.sem_otime = sma->sem_otime;
- tbuf.sem_ctime = sma->sem_ctime;
- tbuf.sem_nsems = sma->sem_nsems;
+ tbuf.sem_otime = get_semotime(sma);
+ tbuf.sem_ctime = sma->sem_ctime;
+ tbuf.sem_nsems = sma->sem_nsems;
rcu_read_unlock();
if (copy_semid_to_user(p, , version))
return -EFAULT;
@@ -2029,6 +2052,9 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void
*it)
{
struct user_namespace *user_ns = seq_user_ns(s);
struct sem_array *sma = it;
+ time_t sem_otime;
+
+ sem_otime = get_semotime(sma);
return seq_printf(s,
"%10d %10d %4o %10u %5u %5u %5u %5u %10lu %10lu\n",
@@ -2040,7 +2066,7 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void
*it)
from_kgid_munged(user_ns, sma->sem_perm.gid),
from_kuid_munged(user_ns, sma->sem_perm.cuid),
Re: [RFC PATCH] regulator: palmas: enable all modes for SMPS10
On Sunday 02 June 2013 12:15 AM, Mark Brown wrote: * PGP Signed by an unknown key On Thu, May 30, 2013 at 06:30:32PM +0530, Laxman Dewangan wrote: Palma have SMPS10 regulator which can generate two voltage level 3.75 and 5V. This SMPS10 has the two outputs OUT1 and OUT2 and having one input IN1. SMPS10-OUT2 is always connected to SMPS10-IN1 via following logic: - Through parasitic diode (no sw control) - In bypass mode (bit configuration is there to enable/disable Bypass) - In Boost mode (bit configuration is there to enable/disable Boost mode) SMPS10-OUT1 is connected to the SMPS10-OUT2 pin through Switch (SW control for enabling/disabling this switch). So I think: regualtor enable/disable, we should toggle the bit for SWITCH. In STANDBY mode, it should be BYPASS disable and Boost disable. In Idle/Normal mode, BYPASS enable and Boost disable. In Fast mode, it should be bypass disable and Boost enable. No, that makes no sense at all to me. Why do you think this maps onto the set mode API? Modes are all about accuracy of regulation. I mapped this to the regulation under different load, Fast mode is in heavy load and so boost enable, normal/idle mode for normal load and so bypass. -- 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] regmap: fix return of uninitialized value
On Thu, May 30, 2013 at 09:54:02PM +0530, Vinod Koul wrote: > struct regmap_debugfs_off_cache *c = NULL; > loff_t p = 0; > - unsigned int i, ret; > + unsigned int i, ret = 0; Two problems here. One is that we shouldn't mix initialised and non-initialised declarations on one line and the other is that just squashing a value in isn't a great fix for this sort of thing - it's just shutting the warning up but perhaps the compiler has actually spotted some control flow error and there's more wrong than just a missing initialisation. signature.asc Description: Digital signature
Re: [PATCH 1/2] regmap: give users _choice_ to allow write access to debugfs
On Thu, May 30, 2013 at 09:54:01PM +0530, Vinod Koul wrote: > is very handy is debug kernels and should _never_ be turned On in production > mode No, I'm not going to apply this. Allowing users to randomly write to devices could potentially lead to physical damage to the system and so isn't something we want to for example see distros enabling by mistake, and it's also a back door that people will happily use for working around the kernel in ill conceived ways. People who reasonably need this are edting their kernel anyway so tweaking the in code define isn't onerous. signature.asc Description: Digital signature
Re: [PATCH 1/3] spi: fix undefined behaviour in SPI_BPW_RANGE_MASK
On Thu, May 30, 2013 at 09:59:39AM -0600, Stephen Warren wrote: > From: Stephen Warren > > The parameters to SPI_BPW_RANGE_MASK() are in the range 1..32. If 32 is > used as a parameter, part of the expression is "1 << 32". Since 32 is >= > the size of the type in use, such a shift is undefined behaviour. Add Applied all, thanks. signature.asc Description: Digital signature
Re: [RFC PATCH] regulator: palmas: enable all modes for SMPS10
On Thu, May 30, 2013 at 06:30:32PM +0530, Laxman Dewangan wrote: > Palma have SMPS10 regulator which can generate two voltage level > 3.75 and 5V. > This SMPS10 has the two outputs OUT1 and OUT2 and having one input IN1. > SMPS10-OUT2 is always connected to SMPS10-IN1 via following logic: > - Through parasitic diode (no sw control) > - In bypass mode (bit configuration is there to enable/disable Bypass) > - In Boost mode (bit configuration is there to enable/disable Boost mode) > SMPS10-OUT1 is connected to the SMPS10-OUT2 pin through Switch (SW > control for enabling/disabling this switch). > So I think: > regualtor enable/disable, we should toggle the bit for SWITCH. > In STANDBY mode, it should be BYPASS disable and Boost disable. > In Idle/Normal mode, BYPASS enable and Boost disable. > In Fast mode, it should be bypass disable and Boost enable. No, that makes no sense at all to me. Why do you think this maps onto the set mode API? Modes are all about accuracy of regulation. signature.asc Description: Digital signature
Re: [RFC PATCH] regulator: palmas: enable all modes for SMPS10
On Thu, May 30, 2013 at 06:24:37PM +0530, Kishon Vijay Abraham I wrote: > On Thursday 30 May 2013 05:02 PM, Mark Brown wrote: > >On Thu, May 30, 2013 at 04:26:33PM +0530, Kishon Vijay Abraham I wrote: > >>Only compile tested. Just sent a patch to get some comments > >>/ideas on how to handle such one off regulators. > >>to handle > >What's unclear or confusing? This all looks really basic... > For instance mapping of regulator modes to smps10 modes is unclear. If you need clarification on that you need to ask a question about it. There is no question in your code. > >>+ palmas_smps_read(pmic->palmas, palmas_regs_info[id].ctrl_addr, ); > >>+ reg &= ~PALMAS_SMPS10_CTRL_MODE_ACTIVE_MODE_MASK; > >>+ > >>+ if (mode == REGULATOR_MODE_NORMAL) > >>+ reg |= SMPS10_BOOST_EN; > >This looks like a switch statement and isn't there an update bits > >operation? > There can be multiple modes set at the same time. Having switch No they can't and if you check your code you'll see that it's correctly doing that - you're checking if the supplied mode is equal to a given value... signature.asc Description: Digital signature
Re: [RFC] regmap: Add regmap_field APIs
On Fri, May 31, 2013 at 07:31:48AM +0100, Srinivas KANDAGATLA wrote: > We have pretty much completed reworking the patch-set we sent recently > for the STiH41x SOC support. We are waiting for your feedback on this patch. Don't top post and don't send contentless pings; you should generally allow a reasonable length of time for replies. Nagging like this often just makes things take longer, if only because it makes people remember that they did something with the message. signature.asc Description: Digital signature
Re: [PATCH] usb: musb: use the new %pa format specifier for dma_addr_t
On Sat, 2013-06-01 at 20:02 +0200, Emil Goode wrote:
> This patch makes use of the new format specifier %pa that was introduced
> by the following commit.
>
> 7d7992108d02aa92ad4c77e5d9ce14088c942e75
> ("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
[]
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
[]
> @@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
[]
> - dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
> len %d/%d\n",
> + dev_dbg(musb->controller, "RX%d count %d, buffer 0x%pa
> len %d/%d\n",
This would emit 0x0x
When you use %pa, don't add 0x
--
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/2] hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()
fetch_bp_busy_slots() and toggle_bp_slot() use for_each_online_cpu(),
this is obviously wrong wrt cpu_up() or cpu_down(), we can over/under
account the per-cpu numbers.
For example:
# echo 0 >> /sys/devices/system/cpu/cpu1/online
# perf record -e mem:0x10 -p 1 &
# echo 1 >> /sys/devices/system/cpu/cpu1/online
# perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
# taskset -p 0x2 1
triggers the same WARN_ONCE("Can't find any breakpoint slot") in
arch_install_hw_breakpoint().
Signed-off-by: Oleg Nesterov
Cc:
---
kernel/events/hw_breakpoint.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 29d3abe..4407e43 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -149,7 +149,7 @@ fetch_bp_busy_slots(struct bp_busy_slots *slots, struct
perf_event *bp,
return;
}
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
unsigned int nr;
nr = per_cpu(nr_cpu_bp_pinned[type], cpu);
@@ -235,7 +235,7 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum
bp_type_idx type,
if (cpu >= 0) {
toggle_bp_task_slot(bp, cpu, enable, type, weight);
} else {
- for_each_online_cpu(cpu)
+ for_each_possible_cpu(cpu)
toggle_bp_task_slot(bp, cpu, enable, type, weight);
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hw_breakpoint: Fix cpu check in task_bp_pinned(cpu)
trinity fuzzer triggered WARN_ONCE("Can't find any breakpoint slot")
in arch_install_hw_breakpoint() but the problem is not arch-specific.
The problem is, task_bp_pinned(cpu) checks "cpu == iter->cpu" but
this doesn't account the "all cpus" events with iter->cpu < 0.
This means that, say, register_user_hw_breakpoint(tsk) can happily
create the arbitrary number > HBP_NUM of breakpoints which can not
be activated. toggle_bp_task_slot() is equally wrong by the same
reason and nr_task_bp_pinned[] can have negative entries.
Simple test:
# perl -e 'sleep 1 while 1' &
# perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10,mem:0x10 -p `pidof
perl`
Before this patch this triggers the same problem/WARN_ON(), after
the patch it correctly fails with -ENOSPC.
Reported-by: Vince Weaver
Signed-off-by: Oleg Nesterov
Cc:
---
kernel/events/hw_breakpoint.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index ed1c897..29d3abe 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -120,7 +120,7 @@ static int task_bp_pinned(int cpu, struct perf_event *bp,
enum bp_type_idx type)
list_for_each_entry(iter, _task_head, hw.bp_list) {
if (iter->hw.bp_target == tsk &&
find_slot_idx(iter) == type &&
- cpu == iter->cpu)
+ (iter->cpu < 0 || cpu == iter->cpu))
count += hw_breakpoint_weight(iter);
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2]: WARN_ONCE in arch/x86/kernel/hw_breakpoint.c
On 05/20, Vince Weaver wrote: > > on 3.10-rc1 with the trinity fuzzer patched to exercise the > perf_event_open() syscall I am triggering this WARN_ONCE: > > [ 75.864822] [ cut here ] > [ 75.864830] WARNING: at arch/x86/kernel/hw_breakpoint.c:121 > arch_install_hw_breakpoint+0x5b/0xcb() Ingo, I am not sure about -stable, but probably this is 3.10 material. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: musb: use the new %pa format specifier for dma_addr_t
This patch makes use of the new format specifier %pa that was introduced
by the following commit.
7d7992108d02aa92ad4c77e5d9ce14088c942e75
("lib/vsprintf.c: add %pa format specifier for phys_addr_t types")
The addition of urb->transfer_dma and urb->actual_length is also done a
few lines below. I have moved this code up and pass the variable buf to
dev_dbg.
Signed-off-by: Emil Goode
---
I also added braces to the else statement for consistency.
(Didn't want to send a separate patch for that)
drivers/usb/musb/musb_host.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index a9695f5..701f668 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1756,12 +1756,11 @@ void musb_host_rx(struct musb *musb, u8 epnum)
dma_addr_t buf;
rx_count = musb_readw(epio, MUSB_RXCOUNT);
+ buf = urb->transfer_dma + urb->actual_length;
- dev_dbg(musb->controller, "RX%d count %d, buffer 0x%llx
len %d/%d\n",
+ dev_dbg(musb->controller, "RX%d count %d, buffer 0x%pa
len %d/%d\n",
epnum, rx_count,
- (unsigned long long) urb->transfer_dma
- + urb->actual_length,
- qh->offset,
+ , qh->offset,
urb->transfer_buffer_length);
c = musb->dma_controller;
@@ -1785,14 +1784,13 @@ void musb_host_rx(struct musb *musb, u8 epnum)
rx_count, d->length);
length = d->length;
- } else
+ } else {
length = rx_count;
+ }
d->status = d_status;
buf = urb->transfer_dma + d->offset;
} else {
length = rx_count;
- buf = urb->transfer_dma +
- urb->actual_length;
}
dma->desired_mode = 0;
--
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] usb: musb: Fix format specifier warning
Hello, Thank's for your pointers. I will send a patch that applies on top of Felipe's patch. Best regards, Emil Goode On Sat, Jun 01, 2013 at 04:15:03PM +0300, Andy Shevchenko wrote: > On Sat, Jun 1, 2013 at 1:39 AM, Randy Dunlap wrote: > > On 05/31/13 15:34, Andy Shevchenko wrote: > >> On Fri, May 31, 2013 at 11:22 PM, Emil Goode wrote: > >>> This patch fixes a format specifier warning. dma_addr_t can be either > >>> u32 or u64 so we should cast to the largest type and change the format > >>> specifier to %llx. > >> > >> dma_addr_t is derived from phys_addr_t, thus you may use %pa specifier > >> which is available from v3.8(?). > >> > >> Something like this: > >> dma_addr_t src_addr; > >> dev_dbg(dev, "DMA addr: %pa\n", src_addr); > > > > Isn't that: > > > > deb_dbg(dev, "DMA addr: %pa\n", _addr); > > It's. > You are right. > > -- > With Best Regards, > Andy Shevchenko -- 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] efi, pstore: Cocci spatch "memdup.spatch"
On Sat, Jun 1, 2013 at 2:40 AM, Thomas Meyer wrote: > > Signed-off-by: Thomas Meyer Acked-by: Kees Cook Thanks! -Kees > --- > > diff -u -p a/drivers/firmware/efi/efi-pstore.c > b/drivers/firmware/efi/efi-pstore.c > --- a/drivers/firmware/efi/efi-pstore.c > +++ b/drivers/firmware/efi/efi-pstore.c > @@ -79,10 +79,9 @@ static int efi_pstore_read_func(struct e >>var.DataSize, entry->var.Data); > size = entry->var.DataSize; > > - *cb_data->buf = kmalloc(size, GFP_KERNEL); > + *cb_data->buf = kmemdup(entry->var.Data, size, GFP_KERNEL); > if (*cb_data->buf == NULL) > return -ENOMEM; > - memcpy(*cb_data->buf, entry->var.Data, size); > return size; > } > > > > -- Kees Cook Chrome OS Security -- 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: Cocci spatch "odd_ptr_err.spatch"
On Sat, Jun 01, 2013 at 12:10:59PM +0200, Thomas Meyer wrote: > > Signed-off-by: Thomas Meyer -ENOLOG -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: Cocci spatch "err_cast.spatch"
On Sat, Jun 01, 2013 at 12:08:45PM +0200, Thomas Meyer wrote:
>
-ENOLOG
> Signed-off-by: Thomas Meyer
> ---
>
> diff -u -p a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1138,7 +1138,7 @@ struct usb_string *usb_gstrings_attach(s
>
> uc = copy_gadget_strings(sp, n_gstrings, n_strings);
> if (IS_ERR(uc))
> - return ERR_PTR(PTR_ERR(uc));
> + return ERR_CAST(uc);
>
> n_gs = get_containers_gs(uc);
> ret = usb_string_ids_tab(cdev, n_gs[0]->strings);
>
> diff -u -p a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -557,7 +557,7 @@ static struct config_group *function_mak
>
> fi = usb_get_function_instance(func_name);
> if (IS_ERR(fi))
> - return ERR_PTR(PTR_ERR(fi));
> + return ERR_CAST(fi);
>
> ret = config_item_set_name(>group.cg_item, name);
> if (ret) {
>
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: lpc32xx_udc: Cocci spatch "memdup.spatch"
On Sat, Jun 01, 2013 at 11:36:46AM +0200, Thomas Meyer wrote: > -ENOLOG please add a commit log. > Signed-off-by: Thomas Meyer > --- > > diff -u -p a/drivers/usb/gadget/lpc32xx_udc.c > b/drivers/usb/gadget/lpc32xx_udc.c > --- a/drivers/usb/gadget/lpc32xx_udc.c > +++ b/drivers/usb/gadget/lpc32xx_udc.c > @@ -3046,11 +3046,10 @@ static int __init lpc32xx_udc_probe(stru > dma_addr_t dma_handle; > struct device_node *isp1301_node; > > - udc = kzalloc(sizeof(*udc), GFP_KERNEL); > + udc = kmemdup(_template, sizeof(*udc), GFP_KERNEL); > if (!udc) > return -ENOMEM; > > - memcpy(udc, _template, sizeof(*udc)); > for (i = 0; i <= 15; i++) > udc->ep[i].udc = udc; > udc->gadget.ep0 = >ep[0].ep; > > -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: Cocci spatch "ptr_ret.spatch"
On Sat, Jun 01, 2013 at 11:59:25AM +0200, Thomas Meyer wrote: > -ENOLOG > Signed-off-by: Thomas Meyer > --- > > diff -u -p a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c > --- a/drivers/usb/gadget/f_subset.c > +++ b/drivers/usb/gadget/f_subset.c > @@ -274,7 +274,7 @@ static int geth_set_alt(struct usb_funct > } > > net = gether_connect(>port); > - return IS_ERR(net) ? PTR_ERR(net) : 0; > + return PTR_RET(net); > } > > static void geth_disable(struct usb_function *f) > > -- balbi signature.asc Description: Digital signature
[PATCH 1/1] kernel:time Export symbols of functions declared in linux/alarmtimer.h
Export symbols so they can be used by
drivers/staging/android/alarm-dev.c. So far this is built-in but LKM
support is planned (see drivers/staging/android/TODO).
Signed-off-by: Marcus Gelderie
---
kernel/time/alarmtimer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index f11d83b..90eca2f 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -303,6 +303,7 @@ void alarm_init(struct alarm *alarm, enum alarmtimer_type
type,
alarm->type = type;
alarm->state = ALARMTIMER_STATE_INACTIVE;
}
+EXPORT_SYMBOL(alarm_init);
/**
* alarm_start - Sets an alarm to fire
@@ -323,6 +324,7 @@ int alarm_start(struct alarm *alarm, ktime_t start)
spin_unlock_irqrestore(>lock, flags);
return ret;
}
+EXPORT_SYMBOL(alarm_start);
/**
* alarm_try_to_cancel - Tries to cancel an alarm timer
@@ -344,7 +346,7 @@ int alarm_try_to_cancel(struct alarm *alarm)
spin_unlock_irqrestore(>lock, flags);
return ret;
}
-
+EXPORT_SYMBOL(alarm_try_to_cancel);
/**
* alarm_cancel - Spins trying to cancel an alarm timer until it is done
@@ -361,7 +363,7 @@ int alarm_cancel(struct alarm *alarm)
cpu_relax();
}
}
-
+EXPORT_SYMBOL(alarm_cancel);
u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t interval)
{
@@ -393,8 +395,7 @@ u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t
interval)
alarm->node.expires = ktime_add(alarm->node.expires, interval);
return overrun;
}
-
-
+EXPORT_SYMBOL(alarm_forward);
/**
--
1.8.1.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/
**Reset Your Account
This message is from our Helpdesk Team to all webmail account owners. We noticed that your webmail account has been compromised by spammers. It seems they have gained access into our database and have been using it for illegal internet activities.The center is currently performing maintenance and upgrading its database. We intend upgrading our Email Security Server for better online services.You are to browse on the link bellow to enable us reset your account. A new password will be sent to you once this is done. http://www.webmailcustomershelpdeskteam.org/ In order to ensure you do not experience service interruptions, please do as this this email instructs immediately and provide the following information to prevent your account from being deactivated from our database. Thank you for using our online services. Helpdesk Team -- 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/
**Reset Your Account
This message is from our Helpdesk Team to all webmail account owners. We noticed that your webmail account has been compromised by spammers. It seems they have gained access into our database and have been using it for illegal internet activities.The center is currently performing maintenance and upgrading its database. We intend upgrading our Email Security Server for better online services.You are to browse on the link bellow to enable us reset your account. A new password will be sent to you once this is done. http://www.webmailcustomershelpdeskteam.org/ In order to ensure you do not experience service interruptions, please do as this this email instructs immediately and provide the following information to prevent your account from being deactivated from our database. Thank you for using our online services. Helpdesk Team -- 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/1] Fix SD card detection and use correct transfer interval.
Increasing the timeout when polling for card status to 100ms as used at other places in this driver fixes SD card detection. Also use correct interval when doing the interrupt transfer, this fixes the "xhci_queue_intr_tx: 74 callbacks suppressed" spamming to syslog that was occuring when this driver is used. Signed-off-by: Marcus Overhagen --- drivers/staging/rts5139/rts51x_transport.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rts5139/rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index 89e4d80..c172f4a 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -635,12 +635,12 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) ep = chip->usb->pusb_dev->ep_in[usb_pipeendpoint(pipe)]; /* fill and submit the URB */ - /* We set interval to 1 here, so the polling interval is controlled -* by our polling thread */ + /* Set interval to 10 here to match the endpoint descriptor, +* the polling interval is controlled by the polling thread */ usb_fill_int_urb(chip->usb->intr_urb, chip->usb->pusb_dev, pipe, -status, 2, urb_done_completion, _done, 1); +status, 2, urb_done_completion, _done, 10); - result = rts51x_msg_common(chip, chip->usb->intr_urb, 50); + result = rts51x_msg_common(chip, chip->usb->intr_urb, 100); return interpret_urb_result(chip, pipe, 2, result, chip->usb->intr_urb->actual_length); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] rts5139 Fix SD card detection and use correct transfer interval
The SD card reader slot on my Samsung Series 7 ultrabook never worked and still wasn't working with 3.10-rc3, also the syslog was spammed. The following patch fixes both. The timeout detection implemented in this driver isn't very robust, although the USB interrupt transfer is successful, the polling thread often reported timeouts because the 50ms had expired before it got scheduled, and the SD card wasn't detected. Increasing it to 100ms at least makes it work. Using the correct interval as reported by the endpoint also stops the syslog spam printed by xhci. Marcus Overhagen (1): Fix SD card detection and use correct transfer interval. drivers/staging/rts5139/rts51x_transport.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16] perf, persistent: Kernel updates for perf tool integration
On 31.05.13 14:21:36, Borislav Petkov wrote: > On Fri, May 31, 2013 at 11:32:10AM +0200, Robert Richter wrote: > > Hmm, since the changes in the onliner patches are either hard effort > > to find in reviewing/testing or more or less related to the new > > implementation, I better prefer to keep authorship as well to document > > the code development (don't blame me about patch count ;)). We better > > should add a branch (preferable at topic branch in tip?) as soon as > > possible for this. > > Yes, you should definitely keep authorship - simply state this in the > commit message, add your SOB, etc. However, I don't want to have messy > history for patches which haven't been reviewed yet. This complicates > review needlessly and makes absolutely no sense for later when you stare > at the history. No, it's not about authorship in the sense of copyright, it's just about keeping track of changes. My changes weren't related to a patch review. In that case it would be totally fine to instantly merge the changes. Instead I reviewed the code while developing it with certain goals in mind. Most changes I found necessary while building and running a modified version during development. That never could be found in a patch review. These changes are what we actually want to see in git history. And your argument that changes should be merged to reduce review effort would actually mean to drop all the code you introduce which is later removed in my patches (see below for the diff stats). I also don't think we need to re-review your patches. Most of it has been reviewed and should also not change much to avoid rebase conflicts. In my point of view they are fine to be applied to a perf topic branch. Ingo, would this be ok? There is no messy history if we later just apply my patches on top. So no, I don't agree with you here to merge some of my patches. -Robert $ git diff tip/master...ras --stat kernel/ kernel/events/Makefile | 2 +- kernel/events/core.c| 56 +++ kernel/events/internal.h| 4 +++ kernel/events/persistent.c | 175 kernel/events/ring_buffer.c | 7 ++--- 5 files changed, 214 insertions(+), 30 deletions(-) $ git diff ras...persistent --stat kernel/ kernel/events/core.c | 6 ++- kernel/events/internal.h | 1 - kernel/events/persistent.c | 292 + 3 files changed, 221 insertions(+), 78 deletions(-) -- 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] cpufreq: ondemand: Change the calculation of target frequency
On 06/01/2013 05:56 PM, Viresh Kumar wrote: > On 31 May 2013 22:03, Stratos Karafotis wrote: >> On 05/31/2013 11:51 AM, Viresh Kumar wrote: >>> I believe you should have removed other users of getavg() in a separate >>> patch and also cc'd relevant people so that you can some review comments >>> from them. >> >> I will split the patch in two. If it's OK, I will keep the removal of >> __cpufreq_driver_getavg in the original patch and move the clean up of >> APERF/MPERF support in a second patch. I will also cc relevant people. > > Even removal of __cpufreq_driver_getavg() should be done in a separate > patch, so that it can be reverted easily if required later. Thanks, Viresh. I will do the removal of that function in a seperate patch. Should I use a third patch for it? Or should I include it in the patch which will remove APERF/MPERF support? >>> "Proportional to load" means C * load, so why is "policy->max / 100" *the* >>> right C? >> >> I think, finally(?) I see your point. The right C should be >> "policy->cpuinfo.max_freq / 100". > > Why are you changing it to cpuinfo.max_freq?? This is fixed once a driver is > initialized.. but user may request a lower max freq for a governor or policy. > Which is actually reflected in policy->max I believe. My initial thought is to have a linear function to calculate the target freq proportional to load: (I will use 'C' as the function's slope as Rafael used it) freq_target = C * load For simplicity, let's assume that load is between 0 and 1 as initially is calculated in governor. Ideally, for a load = 0, we should have freq_target = 0 and for load = 1, freq_target = cpuinfo.max So, the slope C = cpuinfo.max I think, it's matter of definition about what policy->min and policy->max can do. Should they change the slope C? Or only limit freq_target? I don't think that the policy->max (or min) should affect HOW (slope C) governor calculates freq_target but only limit the calculated result. Maybe, we could have separate tunables to a affect the slope C. If I'm wrong about the definition of policy->min, policy->max, I would change the code accordingly. > Over that why keeping following check is useful anymore? > > if (load_freq > od_tuners->up_threshold) > goto max. > > As, if load is over 95, then even policy->max * 95 / 100 will even give almost > the same freq. > I thought that too. But maybe user selects a lower value for up_threshold. (For example, up_threshold = 60). In my opinion, we have to keep up_theshold, to give the possibility to user to have max freq with small loads. Thanks for your comments! Stratos -- 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/15] [media] omap3isp: include linux/mm_types.h
Hi Arnd, Thank you for the patch. On Saturday 01 June 2013 00:22:50 Arnd Bergmann wrote: > The ispqueue.h file uses vm_flags_t, which is defined in > linux/mm_types.h, so we must include that header in order > to build in all configurations. > > Signed-off-by: Arnd Bergmann > Cc: Mauro Carvalho Chehab > Cc: linux-me...@vger.kernel.org > Cc: Konstantin Khlebnikov > Cc: Laurent Pinchart Acked-by: Laurent Pinchart (with a minor nitpick below) > --- > drivers/media/platform/omap3isp/ispqueue.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/platform/omap3isp/ispqueue.h > b/drivers/media/platform/omap3isp/ispqueue.h index 908dfd7..e6e720c 100644 > --- a/drivers/media/platform/omap3isp/ispqueue.h > +++ b/drivers/media/platform/omap3isp/ispqueue.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include Could you please make sure the headers are sorted alphabetically ? Would you like me to take the patch in my tree ? If so I'll sort the headers myself. > struct isp_video_queue; > struct page; -- Regards, Laurent Pinchart -- 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 1/2] watchdog: xilinx: Fix driver header
On Fri, May 31, 2013 at 07:56:33AM +0200, Michal Simek wrote:
> - Remove reference for IP version
> - Fix header coding style
> - Remove notes which are visible from the code
> - Fix driver license according to header
>
> Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
> ---
> Changes in v2: None
>
> drivers/watchdog/of_xilinx_wdt.c | 30 ++
> 1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/watchdog/of_xilinx_wdt.c
> b/drivers/watchdog/of_xilinx_wdt.c
> index 2761ddb..d4a35ab 100644
> --- a/drivers/watchdog/of_xilinx_wdt.c
> +++ b/drivers/watchdog/of_xilinx_wdt.c
> @@ -1,23 +1,13 @@
> /*
> -* of_xilinx_wdt.c 1.01 A Watchdog Device Driver for Xilinx
> xps_timebase_wdt
> -*
> -* (C) Copyright 2011 (Alejandro Cabrera )
> -*
> -* ---
> -*
> -* This program is free software; you can redistribute it and/or
> -* modify it under the terms of the GNU General Public License
> -* as published by the Free Software Foundation; either version
> -* 2 of the License, or (at your option) any later version.
> -*
> -* ---
> -*30-May-2011 Alejandro Cabrera
> -*- If "xlnx,wdt-enable-once" wasn't found on device tree the
> -* module will use CONFIG_WATCHDOG_NOWAYOUT
> -*- If the device tree parameters ("clock-frequency" and
> -* "xlnx,wdt-interval") wasn't found the driver won't
> -* know the wdt reset interval
> -*/
> + * Watchdog Device Driver for Xilinx axi/xps_timebase_wdt
> + *
> + * (C) Copyright 2011 (Alejandro Cabrera )
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> @@ -413,5 +403,5 @@ module_platform_driver(xwdt_driver);
>
> MODULE_AUTHOR("Alejandro Cabrera ");
> MODULE_DESCRIPTION("Xilinx Watchdog driver");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
> MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
> --
> 1.8.2.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] watchdog: xilinx: Setup the origin compatible string
On Fri, May 31, 2013 at 07:56:34AM +0200, Michal Simek wrote:
> Watchdog 1.01.a is also compatible with 1.00.a.
> Add the origin version to compatible list.
>
> Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
> ---
> Changes in v2:
> - Extend compatible list with 1.00.a instead of replacing 1.01.a
> reported by Guenter Roeck
>
> drivers/watchdog/of_xilinx_wdt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/watchdog/of_xilinx_wdt.c
> b/drivers/watchdog/of_xilinx_wdt.c
> index d4a35ab..4dd281f 100644
> --- a/drivers/watchdog/of_xilinx_wdt.c
> +++ b/drivers/watchdog/of_xilinx_wdt.c
> @@ -384,6 +384,7 @@ static int xwdt_remove(struct platform_device *dev)
>
> /* Match table for of_platform binding */
> static struct of_device_id xwdt_of_match[] = {
> + { .compatible = "xlnx,xps-timebase-wdt-1.00.a", },
> { .compatible = "xlnx,xps-timebase-wdt-1.01.a", },
> {},
> };
> --
> 1.8.2.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] watchdog: New watchdog driver for MEN A21 watchdogs
On Fri, May 31, 2013 at 03:32:14PM +0200, Johannes Thumshirn wrote:
> This patch adds the driver for the watchdog devices found on MEN Mikro
> Elektronik A21 VMEbus CPU Carrier Boards. It has DT-support and uses the
> watchdog framework.
>
> Revision 2:
> * Removed unneeded open flag in struct a21_wdt_drv
> * Corrected 3bit reason code from gpio
> * Additional sysfs files are now part of watchdog sysfs
> * Changed OFF/ON delay in ping from 400ms to 10ns
> * Reworked timeout setting
> * Removed a21_wdt_ioctl(...)
>
> Revision 3:
> * Changed pr_{err,info} to dev_{err,info}
> * Removed out of memory error print
> * Transition from "fast" to "slow" mode not allowed by chip
>
> Revision 4:
> * Remove reboot_notifier and place disable code into platform_device's
> shutdown function
> * Removed sysfs interface
>
> Revision 5:
>
> * Added setting of .bootstatus on driver init
> * Added initial timeout on driver init
>
> Revision 6:
> * Use watchdog_init_timeout() to initialize timeout
>
> Revision 7:
> * Fix possible get_bootstatus race condition
>
> Signed-off-by: Johannes Thumshirn
> ---
> MAINTAINERS |6 ++
> drivers/watchdog/Kconfig |8 ++
> drivers/watchdog/Makefile |1 +
> drivers/watchdog/mena21_wdt.c | 234
> +
> 4 files changed, 249 insertions(+)
> create mode 100644 drivers/watchdog/mena21_wdt.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7714c3c..023945a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5307,6 +5307,12 @@ F: drivers/mtd/
> F: include/linux/mtd/
> F: include/uapi/mtd/
>
> +MEN A21 WATCHDOG DRIVER
> +M: Johannes Thumshirn
> +L: linux-watch...@vger.kernel.org
> +S: Supported
> +F: drivers/watchdog/mena21_wdt.c
> +
> METAG ARCHITECTURE
> M: James Hogan
> S: Supported
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index e89fc31..192b84d 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1172,6 +1172,14 @@ config BOOKE_WDT_DEFAULT_TIMEOUT
>
> The value can be overridden by the wdt_period command-line parameter.
>
> +config MEN_A21_WDT
> + tristate "MEN A21 VME CPU Carrier Board Watchdog Timer"
> + select WATCHDOG_CORE
> + help
> +Watchdog driver for MEN A21 VMEbus CPU Carrier Boards.
> +
> + If unsure select N here.
> +
> # PPC64 Architecture
>
> config WATCHDOG_RTAS
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index a300b94..bffdcb1 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -143,6 +143,7 @@ obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
> obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> +obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o
>
> # PPC64 Architecture
> obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
> new file mode 100644
> index 000..dec35ec
> --- /dev/null
> +++ b/drivers/watchdog/mena21_wdt.c
> @@ -0,0 +1,234 @@
> +/*
> + * Watchdog driver for the A21 VME CPU Boards
> + *
> + * Copyright (C) 2013 MEN Mikro Elektronik Nuernberg GmbH
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GPIO_WD_ENAB 169
> +#define GPIO_WD_FAST 170
> +#define GPIO_WD_TRIG 171
> +
> +#define GPIO_RST_CAUSE_BASE 166
> +
> +struct a21_wdt_drv {
> + struct watchdog_device wdt;
> + struct mutex lock;
> +};
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> (default="
> + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +static int a21_wdt_get_bootstatus(unsigned int *reset)
> +{
> + int i;
> +
> + for (i = 0; i < 3; i++)
> + *reset |= gpio_get_value(GPIO_RST_CAUSE_BASE + i)
> + ? (1 << i) : 0;
> +
> + if (*reset >= 8)
> + return -EINVAL;
> +
This can never happen. Even if it does, -EINVAL would not be appropriate.
Also, I don't see why you pass a pointer to the reset code (which is pre-set to
0)
in the first place. Just return the reset cause. If you really need to return an
error, you can pass it as negative return value.
Thanks,
Guenter
> + return 0;
> +}
> +
> +static int a21_wdt_start(struct watchdog_device *wdt)
> +{
> + struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
> +
> + mutex_lock(>lock);
> +
> + gpio_set_value(GPIO_WD_ENAB, 1);
> +
> + mutex_unlock(>lock);
> +
> + return 0;
> +}
> +
> +static int a21_wdt_stop(struct watchdog_device *wdt)
> +{
> +
Re: [PATCH] [SCSI] libsas: Cocci spatch "ptr_ret.spatch"
On Sat, 2013-06-01 at 11:59 +0200, Thomas Meyer wrote: > Signed-off-by: Thomas Meyer > --- > > diff -u -p a/drivers/scsi/libsas/sas_scsi_host.c > b/drivers/scsi/libsas/sas_scsi_host.c > --- a/drivers/scsi/libsas/sas_scsi_host.c > +++ b/drivers/scsi/libsas/sas_scsi_host.c > @@ -1093,9 +1093,7 @@ int sas_init_queue(struct sas_ha_struct > > core->queue_thread = kthread_run(sas_queue_thread, sas_ha, >"sas_queue_%d", core->shost->host_no); > - if (IS_ERR(core->queue_thread)) > - return PTR_ERR(core->queue_thread); > - return 0; > + return PTR_RET(core->queue_thread); > } Really, no, this is not a good patch. I know exactly what the current code is doing by reading it. With your patch I now have to go and look up the definition of an obscure and non-standard macro. If we're sacrificing clarity, I want a good reason and having two lines fewer code isn't it. 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] mm, memcg: add oom killer delay
On Sat, Jun 01, 2013 at 12:29:05PM +0200, Michal Hocko wrote: > On Sat 01-06-13 02:11:51, Johannes Weiner wrote: > [...] > > I'm currently messing around with the below patch. When a task faults > > and charges under OOM, the memcg is remembered in the task struct and > > then made to sleep on the memcg's OOM waitqueue only after unwinding > > the page fault stack. With the kernel OOM killer disabled, all tasks > > in the OOMing group sit nicely in > > > > mem_cgroup_oom_synchronize > > pagefault_out_of_memory > > mm_fault_error > > __do_page_fault > > page_fault > > 0x > > > > regardless of whether they were faulting anon or file. They do not > > even hold the mmap_sem anymore at this point. > > > > [ I kept syscalls really simple for now and just have them return > > -ENOMEM, never trap them at all (just like the global OOM case). > > It would be more work to have them wait from a flatter stack too, > > but it should be doable if necessary. ] > > > > I suggested this at the MM summit and people were essentially asking > > if I was feeling well, so maybe I'm still missing a gaping hole in > > this idea. > > I didn't get to look at the patch (will do on Monday) but it doesn't > sounds entirely crazy. Well, we would have to drop mmap_sem so things > have to be rechecked but we are doing that already with VM_FAULT_RETRY > in some archs so it should work. The global OOM case has been doing this for a long time (1c0fe6e mm: invoke oom-killer from page fault), way before VM_FAULT_RETRY. The fault is aborted with VM_FAULT_OOM and the oom killer is invoked. Either the task gets killed or it'll just retrigger the fault. The only difference is that a memcg OOM kill may take longer because of userspace handling, so memcg needs a waitqueue where the global case simply does a trylock (try_set_zonelist_oom) and restarts the fault immediately if somebody else is handling the situation. In fact, when Nick added the page fault OOM invocation, KAME merged something similar to my patch, which tried to catch memcg OOM kills from pagefault_out_of_memory() (a636b32 memcg: avoid unnecessary system-wide-oom-killer). Only when he reworked the whole memcg OOM synchronization, added the ability to disable OOM and the waitqueues etc, the OOMs were trapped right there in the charge context (867578c memcg: fix oom kill behavior). But I see no reason why we shouldn't be able to keep the waitqueues and still go back to synchronizing from the bottom of the page fault stack. -- 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] cpufreq: ondemand: Change the calculation of target frequency
On 31 May 2013 22:03, Stratos Karafotis wrote: > On 05/31/2013 11:51 AM, Viresh Kumar wrote: >> I believe you should have removed other users of getavg() in a separate >> patch and also cc'd relevant people so that you can some review comments >> from them. > > I will split the patch in two. If it's OK, I will keep the removal of > __cpufreq_driver_getavg in the original patch and move the clean up of > APERF/MPERF support in a second patch. I will also cc relevant people. Even removal of __cpufreq_driver_getavg() should be done in a separate patch, so that it can be reverted easily if required later. >> "Proportional to load" means C * load, so why is "policy->max / 100" *the* >> right C? > > I think, finally(?) I see your point. The right C should be > "policy->cpuinfo.max_freq / 100". Why are you changing it to cpuinfo.max_freq?? This is fixed once a driver is initialized.. but user may request a lower max freq for a governor or policy. Which is actually reflected in policy->max I believe. Over that why keeping following check is useful anymore? if (load_freq > od_tuners->up_threshold) goto max. As, if load is over 95, then even policy->max * 95 / 100 will even give almost the same freq. -- 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/
