Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/28 6:24, Rafael J. Wysocki wrote: > On Friday, February 27, 2015 03:50:32 PM Thomas Voegtle wrote: >> >> Hi, >> >> I have the same problem with a Asrock Q1900B-ITX mainboard with >> a Intel Celeron J1900 onboard. >> >> I did a bisect and ended up with: >> >> 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit >> >> commit 593669c2ac0fe18baee04a3cd5539a148aa48574 >> Author: Jiang Liu >> Date: Thu Feb 5 13:44:46 2015 +0800 >> >> x86/PCI/ACPI: Use common ACPI resource interfaces to simplify >> implementation >> >> >> I can revert this quite big commit on current git head (4f671fe) with no >> problems and then everything is fine again. > > Thanks for nailing this one! > > It really wasn't supposed to make any functional difference, though, so there > must be some subtle mistake that escaped everyone in it. > > I'll have a look at that and hopefully Jiang Liu will be able to help in the > meantime too. Hi all, Sorry for slow response, just return from Chinese New Holidays:) Hi Thomas, Could you please help to provide the dmesgs before and after the revert? Thanks! Gerry > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Add PERF-FEATURES to the .gitignore file
It's an auto-generated file. Signed-off-by: Ingo Molnar diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 40399c3d97d6..68328f517a2e 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -1,6 +1,7 @@ PERF-CFLAGS PERF-GUI-VARS PERF-VERSION-FILE +PERF-FEATURES perf perf-read-vdso32 perf-read-vdsox32 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Remove annoying extra message from the features build
This message: Makefile:153: The path 'python-config' is not executable. Appears on every perf build that does not have a sufficient python environment installed. It's really just an internal detail of python configuration pass and users should not see it - and it's pretty meaningless to them in any case because the message is not very helpful. (So it's not executable. Why does that matter? What can the user do about it?) Remove the warning, the missing python feature warning is sufficient: config/Makefile:566: No python-config tool was found config/Makefile:566: Python support will not be built although even that one isn't very helpful to users: so no Python support will be built, what can the user do to fix that? Most other such warnings give package install suggestions. Signed-off-by: Ingo Molnar diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak index 7076a62d0ff7..c16ce833079c 100644 --- a/tools/perf/config/utilities.mak +++ b/tools/perf/config/utilities.mak @@ -175,6 +175,5 @@ _ge-abspath = $(if $(is-executable),$(1)) define get-executable-or-default $(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2))) endef -_ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2))) -_gea_warn = $(warning The path '$(1)' is not executable.) +_ge_attempt = $(if $(get-executable),$(get-executable),$(call _gea_err,$(2))) _gea_err = $(if $(1),$(error Please set '$(1)' appropriately)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Improve Python feature detection messages
Change the Python detection message from: config/Makefile:566: No python-config tool was found config/Makefile:566: Python support will not be built To: config/Makefile:565: No 'python-config' tool was found: disables Python support - please install python-devel/python-dev It's now a standard one-line message with a package install suggestion, and it also uses the standard language used by other feature detection messages. Signed-off-by: Ingo Molnar diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index c3570b5f3bf3..44a14bd40e96 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile disable-python = $(eval $(disable-python_code)) define disable-python_code CFLAGS += -DNO_LIBPYTHON - $(if $(1),$(warning No $(1) was found)) - $(warning Python support will not be built) + $(warning $1) NO_LIBPYTHON := 1 endef ifdef NO_LIBPYTHON - $(call disable-python) + $(call disable-python,Python support disabled by user) else ifndef PYTHON -$(call disable-python,python interpreter) +$(call disable-python,No python interpreter was found: disables Python support - please install python-devel/python-dev) else PYTHON_WORD := $(call shell-wordify,$(PYTHON)) ifndef PYTHON_CONFIG - $(call disable-python,python-config tool) + $(call disable-python,No 'python-config' tool was found: disables Python support - please install python-devel/python-dev) else PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG)) @@ -575,7 +574,7 @@ else FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS) ifneq ($(feature-libpython), 1) -$(call disable-python,Python.h (for Python 2.x)) +$(call disable-python,No 'Python.h' (for Python 2.x support) was found: disables Python support - please install python-devel/python-dev) else ifneq ($(feature-libpython-version), 1) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
Hi Jiang, >>> I have the same problem with a Asrock Q1900B-ITX mainboard with >>> a Intel Celeron J1900 onboard. >>> >>> I did a bisect and ended up with: >>> >>> 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit >>> >>> commit 593669c2ac0fe18baee04a3cd5539a148aa48574 >>> Author: Jiang Liu >>> Date: Thu Feb 5 13:44:46 2015 +0800 >>> >>> x86/PCI/ACPI: Use common ACPI resource interfaces to simplify >>> implementation >>> >>> >>> I can revert this quite big commit on current git head (4f671fe) with no >>> problems and then everything is fine again. >> >> Thanks for nailing this one! >> >> It really wasn't supposed to make any functional difference, though, so there >> must be some subtle mistake that escaped everyone in it. >> >> I'll have a look at that and hopefully Jiang Liu will be able to help in the >> meantime too. > Hi all, > Sorry for slow response, just return from Chinese New Holidays:) > Hi Thomas, > Could you please help to provide the dmesgs before and after the > revert? just grab a Minnowboard Max and test this by yourself. It has the same problem. The MAC address is ff:ff:ff:ff:ff:ff with this patch. Once I reverted it, the MAC address is correctly read again. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Improve libperl detection message
Before: Missing perl devel files. Disabling perl scripting support, consider installing perl-ExtUtils-Embed After: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev Change the message to the standard 'please install' language and adds Debian-ish package suggestion. Signed-off-by: Ingo Molnar diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index c3570b5f3bf3..2f939a04807f 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -531,7 +531,7 @@ else ifneq ($(feature-libperl), 1) CFLAGS += -DNO_LIBPERL NO_LIBPERL := 1 -msg := $(warning Missing perl devel files. Disabling perl scripting support, consider installing perl-ExtUtils-Embed); +msg := $(warning Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev); else LDFLAGS += $(PERL_EMBED_LDFLAGS) EXTLIBS += $(PERL_EMBED_LIBADD) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Invalid assignment to gate in st21nfca_get_iso14443_3_uid
Hello, While compiling Linux with -Wunused-but-set-parameter, gcc reported a warning in st21nfca_get_iso14443_3_uid function, about "gate" being set but not used [1]. By looking at the code, it is clear that "gate = uid_skb->data;" does nothing useful. The function is only called once, by st21nfca_hci_target_from_gate [2], which uses the content of the uid array which is NOT initialized by st21nfca_get_iso14443_3_uid as the source of a memcpy [3]. My understanding of the code is that "gate = uid_skb->data;" in st21nfca_get_iso14443_3_uid should be changed to "memcpy(gate, uid_skb->data, uid_skb->len);". I'm new to the NFC subsystem so I can be wrong, in which case please tell me what I missed in my analysis. Please Cc me when replying as I am not subscribed to the mailing lists. Thanks, Nicolas [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/nfc/st21nfca/st21nfca.c?id=v4.0-rc1#n575 [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/nfc/st21nfca/st21nfca.c?id=v4.0-rc1#n646 [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/nfc/st21nfca/st21nfca.c?id=v4.0-rc1#n682 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Improve libbfd detection message
Before: No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling After: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static to gain symbol demangling Change the message to the standard 'please install' language. Signed-off-by: Ingo Molnar diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index c3570b5f3bf3..0134af0d1877 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -636,7 +635,7 @@ else EXTLIBS += -liberty CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT else -msg := $(warning No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling) +msg := $(warning No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static to gain symbol demangling) CFLAGS += -DNO_DEMANGLE endif endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/25 15:10, Bjorn Helgaas wrote: > [+cc Jiang, Thomas, Lv, Rafael, linux-pci, linux-acpi] > > On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie wrote: >> Hey, >> >> just booted an old AMD rs780 box with new kernel and my ethernet >> failed to come up! >> >> Looks like the MAC addr is all ff's because the PCI bridge windows are >> messed up. >> >> I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one >> failing from the 4.0.0-rc1 time. >> >> b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in >> that tree (I have some radeon patches on top). >> >> motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached. > > Here's the dmesg diff that looks relevant to me: > > -pci_bus :00: root bus resource [io 0x-0x0cf7] > -pci_bus :00: root bus resource [io 0x0d00-0x] > -pci_bus :00: root bus resource [mem 0x000a-0x000b] > -pci_bus :00: root bus resource [mem 0x000c-0x000d] > -pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff] > -pci_bus :00: root bus resource [mem 0x7ff0-0xfebf] > +pci_bus :00: root bus resource [io 0x0cf8-0x0cff] > +pci_bus :00: root bus resource [io 0x-0x0cf7 window] > +pci_bus :00: root bus resource [io 0x0d00-0x window] > +pci_bus :00: root bus resource [mem 0x000a-0x000b window] > +pci_bus :00: root bus resource [mem 0x000c-0x000d window] > +pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff window] > > What's interesting is: > > * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think > it's wrong to include it because that's the configuration space > address/data registers, so it's consumed by the host bridge and not > produced on the downstream side. Hi Bjorn, We should ignore resources occupied by host bridge itself. Will work out a patch to fix this issue. > > * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not. This > is what's screwing up the devices. I need more information to figure out why resource [mem 0x7ff0-0xfebf] is ignored by new ACPI parser. Could you please help to forward the original dmesg attachments? Regards! Gerry > > I think all the windows should be marked as ACPI_PRODUCER in _CRS > since the space is "produced" on the downstream side of the bridge. > The [io 0x0cf8-0x0cff] region should probably be marked > ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it. But > I haven't found the code that does that yet. > > I suspect this is all related to the ACPI resource parsing rework. I > looked through that briefly, but no issues jumped out at me, so this > is just a heads-up in case it is obvious to you guys. > > Dave, it'd be useful if you could collect an acpidump so we can look > at the _CRS data in more detail. > > Bjorn > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/28 16:36, Marcel Holtmann wrote: > Hi Jiang, > I have the same problem with a Asrock Q1900B-ITX mainboard with a Intel Celeron J1900 onboard. I did a bisect and ended up with: 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit commit 593669c2ac0fe18baee04a3cd5539a148aa48574 Author: Jiang Liu Date: Thu Feb 5 13:44:46 2015 +0800 x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation I can revert this quite big commit on current git head (4f671fe) with no problems and then everything is fine again. >>> >>> Thanks for nailing this one! >>> >>> It really wasn't supposed to make any functional difference, though, so >>> there >>> must be some subtle mistake that escaped everyone in it. >>> >>> I'll have a look at that and hopefully Jiang Liu will be able to help in the >>> meantime too. >> Hi all, >> Sorry for slow response, just return from Chinese New Holidays:) >> Hi Thomas, >> Could you please help to provide the dmesgs before and after the >> revert? > > just grab a Minnowboard Max and test this by yourself. It has the same > problem. The MAC address is ff:ff:ff:ff:ff:ff with this patch. Once I > reverted it, the MAC address is correctly read again. Hi Marcel, I have no access to any Minnowboard Max board, so couldn't test it by myself. Could you please help to forward the two dmesg files you have sent to Bjorn in the original email? Thanks! Gerry > > Regards > > Marcel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: Improve libbfd detection message
Before: No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling After: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling Change the message to the standard 'please install' language and also add libiberty-dev suggestion for Ubuntu systems. Signed-off-by: Ingo Molnar -- v2: Added the 'libiberty-dev' package suggestion. diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index c3570b5f3bf3..7649cb87a03a 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -636,7 +635,7 @@ else EXTLIBS += -liberty CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT else -msg := $(warning No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling) +msg := $(warning No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling) CFLAGS += -DNO_DEMANGLE endif endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] lib/vsprintf: Add %pC{,n,r} format specifiers for clocks
Hi Joe,
On Fri, Feb 27, 2015 at 11:55 PM, Joe Perches wrote:
> On Fri, 2015-02-27 at 14:18 -0800, Andrew Morton wrote:
>> On Thu, 26 Feb 2015 12:13:03 +0100 Geert Uytterhoeven
>> wrote:
>> > Add format specifiers for printing struct clk:
>> > - '%pC' or '%pCn': name (Common Clock Framework) or address (legacy
>> > clock framework) of the clock,
>> > - '%pCr': rate of the clock.
> []
>> Seems a bit cruel to teeny systems which don't implement clock. How does
>> this look? Saves 160 bytes in each powerpc build!
>
> Does this still emit a pointer value for those systems?
> Glancing at it, does it just emit NULL?
Yes, there's a "return string(buf, end, NULL, spec);" at the end.
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] mm: cma: constify and use correct signness in mm/cma.c
Constify function parameters and use correct signness where needed.
Signed-off-by: Sasha Levin
---
include/linux/cma.h | 12 ++--
mm/cma.c| 24 ++--
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 9384ba6..f7ef093 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -16,16 +16,16 @@
struct cma;
extern unsigned long totalcma_pages;
-extern phys_addr_t cma_get_base(struct cma *cma);
-extern unsigned long cma_get_size(struct cma *cma);
+extern phys_addr_t cma_get_base(const struct cma *cma);
+extern unsigned long cma_get_size(const struct cma *cma);
extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
bool fixed, struct cma **res_cma);
-extern int cma_init_reserved_mem(phys_addr_t base,
- phys_addr_t size, int order_per_bit,
+extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
+ unsigned int order_per_bit,
struct cma **res_cma);
-extern struct page *cma_alloc(struct cma *cma, int count, unsigned int align);
-extern bool cma_release(struct cma *cma, struct page *pages, int count);
+extern struct page *cma_alloc(struct cma *cma, unsigned int count, unsigned
int align);
+extern bool cma_release(struct cma *cma, const struct page *pages, unsigned
int count);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index a85ae28..ec1a84e 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -47,24 +47,26 @@ static struct cma cma_areas[MAX_CMA_AREAS];
static unsigned cma_area_count;
static DEFINE_MUTEX(cma_mutex);
-phys_addr_t cma_get_base(struct cma *cma)
+phys_addr_t cma_get_base(const struct cma *cma)
{
return PFN_PHYS(cma->base_pfn);
}
-unsigned long cma_get_size(struct cma *cma)
+unsigned long cma_get_size(const struct cma *cma)
{
return cma->count << PAGE_SHIFT;
}
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
+static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
+ unsigned int align_order)
{
if (align_order <= cma->order_per_bit)
return 0;
return (1UL << (align_order - cma->order_per_bit)) - 1;
}
-static unsigned long cma_bitmap_aligned_offset(struct cma *cma, int
align_order)
+static unsigned long cma_bitmap_aligned_offset(const struct cma *cma,
+ unsigned int align_order)
{
unsigned int alignment;
@@ -75,18 +77,19 @@ static unsigned long cma_bitmap_aligned_offset(struct cma
*cma, int align_order)
(cma->base_pfn >> cma->order_per_bit);
}
-static unsigned long cma_bitmap_maxno(struct cma *cma)
+static unsigned long cma_bitmap_maxno(const struct cma *cma)
{
return cma->count >> cma->order_per_bit;
}
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+static unsigned long cma_bitmap_pages_to_bits(const struct cma *cma,
unsigned long pages)
{
return ALIGN(pages, 1UL << cma->order_per_bit) >> cma->order_per_bit;
}
-static void cma_clear_bitmap(struct cma *cma, unsigned long pfn, int count)
+static void cma_clear_bitmap(struct cma *cma, unsigned long pfn,
+ unsigned int count)
{
unsigned long bitmap_no, bitmap_count;
@@ -165,7 +168,8 @@ core_initcall(cma_init_reserved_areas);
* This function creates custom contiguous area from already reserved memory.
*/
int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
-int order_per_bit, struct cma **res_cma)
+ unsigned int order_per_bit,
+ struct cma **res_cma)
{
struct cma *cma;
phys_addr_t alignment;
@@ -356,7 +360,7 @@ err:
* This function allocates part of contiguous memory on specific
* contiguous memory area.
*/
-struct page *cma_alloc(struct cma *cma, int count, unsigned int align)
+struct page *cma_alloc(struct cma *cma, unsigned int count, unsigned int align)
{
unsigned long mask, offset, pfn, start = 0;
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
@@ -427,7 +431,7 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned
int align)
* It returns false when provided pages do not belong to contiguous area and
* true otherwise.
*/
-bool cma_release(struct cma *cma, struct page *pages, int count)
+bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
{
unsigned long pfn;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
RE: [f2fs-dev] [PATCH] f2fs: don't need to collect dirty sit entries and flush journal when there's no dirty sit entries
> -Original Message- > From: Wanpeng Li [mailto:wanpeng...@linux.intel.com] > Sent: Friday, February 27, 2015 4:53 PM > To: Jaegeuk Kim > Cc: linux-fsde...@vger.kernel.org; Wanpeng Li; linux-kernel@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Subject: [f2fs-dev] [PATCH] f2fs: don't need to collect dirty sit entries and > flush journal > when there's no dirty sit entries > > Don't need to collect dirty sit entries and flush sit journal to sit > entries when there's no dirty sit entries. This patch check dirty_sentries > earlier just like flush_nat_entries. > > Signed-off-by: Wanpeng Li Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] f2fs: fix max orphan inodes calculation
> -Original Message- > From: Wanpeng Li [mailto:wanpeng...@linux.intel.com] > Sent: Friday, February 27, 2015 5:38 PM > To: Jaegeuk Kim > Cc: Changman Lee; Chao Yu; linux-f2fs-de...@lists.sourceforge.net; > linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; Wanpeng Li > Subject: [PATCH v2] f2fs: fix max orphan inodes calculation > > cp_payload is introduced for sit bitmap to support large volume, and it is > just after the block of f2fs_checkpoint + nat bitmap, so the first segment > should include F2FS_CP_PACKS + NR_CURSEG_TYPE + cp_payload + orphan blocks. > However, current max orphan inodes calculation don't consider cp_payload, > this patch fix it by reducing the number of cp_payload from total blocks of > the first segment when calculate max orphan inodes. > > Signed-off-by: Wanpeng Li Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining
On Wed, Feb 18, 2015 at 11:32:07AM +0100, Maxime Ripard wrote: > The NDDB register holds the data that are needed by the read and write > commands. > > However, during a read PIO access, the datasheet specifies that after each 32 > bytes read in that register, when BCH is enabled, we have to make sure that > the > RDDREQ bit is set in the NDSR register. > > This fixes an issue that was seen on the Armada 385, and presumably other > mvebu > SoCs, when a read on a newly erased page would end up in the driver reporting > a > timeout from the NAND. > > Cc: # v3.14 > Signed-off-by: Maxime Ripard Pushed this one to linux-mtd.git. I'll try to get it out in the 4.0 cycle. I assume patch 2 (the DT addition) will go through arm-soc. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf: fix building error
Well, I've tested and it worked.
On 2015/2/28 10:49, Namhyung Kim wrote:
Hi He,
On Fri, Feb 27, 2015 at 06:05:37PM +0800, He Kuang wrote:
When build with ARCH=x86_64/i386, perf failed to compile with following
error:
tests/builtin-test.o:(.data+0x158): undefined reference to
`test__perf_time_to_tsc'
collect2: error: ld returned 1 exit status
Makefile.perf:632: recipe for target 'perf' failed
...
Which is caused commit c6e5e9fbc3ea1 ("perf tools: Fix building error
in x86_64 when dwarf unwind is on"), ARCH test in Makefile.perf
conflicts with tests/builtin-test.c's __x86_64__.
To x86/x86_64 platform, ARCH should always override to x86 while
IS_64_BIT stands for the actual architecture.
Signed-off-by: He Kuang
---
tools/perf/config/Makefile.arch | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
index ff95a68..05af152 100644
--- a/tools/perf/config/Makefile.arch
+++ b/tools/perf/config/Makefile.arch
@@ -29,3 +29,11 @@ ifeq ($(LP64), 1)
else
IS_64_BIT := 0
endif
+
+ifeq ($(ARCH), x86_64)
+ override ARCH := x86
+endif
+
+ifeq ($(ARCH), i386)
+ override ARCH := x86
+endif
It seems like we need a same sed script to be applied to ARCH then.
How about this?
diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
index ff95a68741d1..e29de6e3597d 100644
--- a/tools/perf/config/Makefile.arch
+++ b/tools/perf/config/Makefile.arch
@@ -1,28 +1,15 @@
+ifndef ARCH
+ARCH := $(shell uname -m 2>/dev/null || echo not)
+endif
-uname_M := $(shell uname -m 2>/dev/null || echo not)
-
-RAW_ARCH := $(shell echo $(uname_M) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+ARCH := $(shell echo $(ARCH) | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
-e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
-e s/tile.*/tile/ )
-# Additional ARCH settings for x86
-ifeq ($(RAW_ARCH),i386)
- ARCH ?= x86
-endif
-
-ifeq ($(RAW_ARCH),x86_64)
- ARCH ?= x86
-
- ifneq (, $(findstring m32,$(CFLAGS)))
-RAW_ARCH := x86_32
- endif
-endif
-
-ARCH ?= $(RAW_ARCH)
-
LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
ifeq ($(LP64), 1)
IS_64_BIT := 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mtd: pxa3xx-nand: handle PIO in threaded interrupt
On Fri, Feb 20, 2015 at 07:36:43PM +0100, Robert Jarzmik wrote: > Change the handling of the data stage in the driver : don't pump data in > the top-half interrupt, but rather schedule a thread for non dma cases. > > This will enable latencies in the data pumping, especially if delays are > required. Moreover platform shall be more reactive as other interrupts > can be served while pumping data. > > No throughput degradation was observed, at least on the zylonite > platform, while a slight degradation was being expected. > > Signed-off-by: Robert Jarzmik > Tested-by: Maxime Ripard > --- > Since v1: use IRQF_ONESHOT per Maxime's comment Pushed to l2-mtd.git. Thanks. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Improve feature test debuggability
Certain feature tests fail with link errors: triton:~/tip/tools/perf/config/feature-checks> make test-libbabeltrace.bin gcc -MD -o test-libbabeltrace.bin test-libbabeltrace.c # -lbabeltrace provided by /tmp/cc6dRSqd.o: In function `main': test-libbabeltrace.c:(.text+0xf): undefined reference to `bt_ctf_stream_class_get_packet_context_type' although they should already fail with a build error due to lack of a proper prototype for the function. Due to this I first tried to find which library was missing - while it was the whole feature that was missing from the .h file already. To solve this, propagate -Wall -Werror to all testcases and remove them from testcase Makefile rules that used them explicitly. A missing feature now outputs: triton:~/tip/tools/perf/config/feature-checks> make test-libbabeltrace.bin gcc -MD -Wall -Werror -o test-libbabeltrace.bin test-libbabeltrace.c # -lbabeltrace provided by test-libbabeltrace.c: In function ‘main’: test-libbabeltrace.c:6:2: error: implicit declaration of function ‘bt_ctf_stream_class_get_packet_context_type’ [-Werror=implicit-function-declaration] Signed-off-by: Ingo Molnar diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 70c9aebe9da3..8fe067864957 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -39,24 +39,24 @@ PKG_CONFIG := $(CROSS_COMPILE)pkg-config all: $(FILES) -BUILD = $(CC) $(CFLAGS) -o $(OUTPUT)$@ $(patsubst %.bin,%.c,$@) $(LDFLAGS) +BUILD = $(CC) $(CFLAGS) -Wall -Werror -o $(OUTPUT)$@ $(patsubst %.bin,%.c,$@) $(LDFLAGS) ### test-all.bin: - $(BUILD) -Werror -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lelf -laudit -I/usr/include/slang -lslang $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl -lz -lbabeltrace + $(BUILD) -fstack-protector-all -O2 -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lelf -laudit -I/usr/include/slang -lslang $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl -lz -lbabeltrace test-hello.bin: $(BUILD) test-pthread-attr-setaffinity-np.bin: - $(BUILD) -D_GNU_SOURCE -Werror -lpthread + $(BUILD) -D_GNU_SOURCE -lpthread test-stackprotector-all.bin: - $(BUILD) -Werror -fstack-protector-all + $(BUILD) -fstack-protector-all test-fortify-source.bin: - $(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2 + $(BUILD) -O2 -D_FORTIFY_SOURCE=2 test-bionic.bin: $(BUILD) @@ -119,10 +119,10 @@ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS) $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl test-liberty.bin: - $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty + $(CC) -Wall -Werror -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty test-liberty-z.bin: - $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz + $(CC) -Wall -Werror -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz test-cplus-demangle.bin: $(BUILD) -liberty @@ -140,7 +140,7 @@ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS) $(BUILD) # -lbabeltrace provided by $(FEATURE_CHECK_LDFLAGS-libbabeltrace) test-sync-compare-and-swap.bin: - $(BUILD) -Werror + $(BUILD) test-compile-32.bin: $(CC) -m32 -o $(OUTPUT)$@ test-compile.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Improve 'libbabel' feature check failure message
On Debian-ish systems libbabeltrace-dev should be suggested as a package install as well. Signed-off-by: Ingo Molnar diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 40399c3d97d6..68328f517a2e 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -707,7 +706,7 @@ endif ifndef NO_LIBBABELTRACE ifeq ($(feature-libbabeltrace), 0) -msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-devel/libbabeltrace-ctf-dev); +msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); NO_LIBBABELTRACE := 1 else CFLAGS += -DHAVE_LIBBABELTRACE_SUPPORT $(LIBBABELTRACE_CFLAGS) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] clk: Provide always-on clock support
On 28 February 2015 at 02:44, Lee Jones wrote: > Lots of platforms contain clocks which if turned off would prove fatal. > The only way to recover from these catastrophic failures is to restart > the board(s). Now, when a clock is registered with the framework it is > compared against a list of provided always-on clock names which must be > kept ungated. If it matches, we enable the existing CLK_IGNORE_UNUSED > flag, which will prevent the common clk framework from attempting to > gate it during the clk_disable_unused() procedure. > If a clock is critical on a certain board, it could be got+enabled during early boot so there is always a user. To be able to do that from DT, maybe add a new, say, CLK_ALWAYS_ON flag could be made to initialize the clock with one phantom user already. Or just reuse the CLK_IGNORE_UNUSED? -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: pxa3xx_nand: fix driver when num_cs is 0
On Sun, Feb 08, 2015 at 09:02:09PM +0100, Robert Jarzmik wrote: > As the devicetree binding doesn't require num_cs to exist or be strictly > positive, and neither does the platform data case, a bug appear when > num_cs is set to 0 and panics the kernel. > > The issue is that in alloc_nand_resource(), chip is dereferenced without > having a value assigned when num_cs == 0. > > Fix this by returning ENODEV is num_cs == 0. > > The panic seen is : > Unable to handle kernel NULL pointer dereference at virtual address 02b8 > pgd = c0004000 > [02b8] *pgd= > Internal error: Oops: 5 [#1] PREEMPT ARM > Modules linked in: > Hardware name: Marvell PXA3xx (Device Tree Support) > task: c3822aa0 ti: c3826000 task.ti: c3826000 > PC is at alloc_nand_resource+0x180/0x4a8 > LR is at alloc_nand_resource+0xa0/0x4a8 > pc : []lr : []psr: 6813 > sp : c3827d90 ip : fp : > r10: c3862200 r9 : 005e r8 : > r7 : c3865610 r6 : c3862210 r5 : c3924210 r4 : c3862200 > r3 : r2 : r1 : r0 : > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 397f Table: 80004018 DAC: 0035 > Process swapper (pid: 1, stack limit = 0xc3826198) > Stack: (0xc3827d90 to 0xc3828000) > ...zip... > [] (alloc_nand_resource) from [] > (pxa3xx_nand_probe+0x140/0x978) > [] (pxa3xx_nand_probe) from [] > (platform_drv_probe+0x48/0xa4) > [] (platform_drv_probe) from [] > (driver_probe_device+0x80/0x21c) > [] (driver_probe_device) from [] > (__driver_attach+0x8c/0x90) > [] (__driver_attach) from [] (bus_for_each_dev+0x58/0x88) > [] (bus_for_each_dev) from [] (bus_add_driver+0xd8/0x1d4) > [] (bus_add_driver) from [] (driver_register+0x78/0xf4) > [] (driver_register) from [] (do_one_initcall+0x80/0x1e4) > [] (do_one_initcall) from [] > (kernel_init_freeable+0xec/0x1b4) > [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) > [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) > Code: e503b234 e5953008 e1530001 cad1 (e59002b8) > ---[ end trace a5770060c8441895 ]--- > > Signed-off-by: Robert Jarzmik Pushed to linux-mtd.git. Thanks. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] f2fs: fix to issue small discard in real-time mode discard
Now in f2fs, we share functions and structures for batch mode and real-time mode discard. For real-time mode discard, in shared function add_discard_addrs, we will use uninitialized trim_minlen in struct cp_control to compare with length of contiguous free blocks to decide whether skipping discard fragmented freespace or not, this makes us ignore small discard sometimes. Fix it. Signed-off-by: Chao Yu --- fs/f2fs/segment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index daee4ab..fcc1cc2 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -549,7 +549,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control *cpc) end = __find_rev_next_zero_bit(dmap, max_blocks, start + 1); - if (end - start < cpc->trim_minlen) + if (force && end - start < cpc->trim_minlen) continue; __add_discard_entry(sbi, cpc, start, end); -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:perf/core] perf tools: Add feature check for libbabeltrace
* tip-bot for Jiri Olsa wrote:
> Commit-ID: 53d0a57343949b2af9b27229db534b98e5a0c4d0
> Gitweb: http://git.kernel.org/tip/53d0a57343949b2af9b27229db534b98e5a0c4d0
> Author: Jiri Olsa
> AuthorDate: Fri, 20 Feb 2015 23:16:58 +0100
> Committer: Arnaldo Carvalho de Melo
> CommitDate: Wed, 25 Feb 2015 12:42:24 -0300
>
> perf tools: Add feature check for libbabeltrace
>
> Adding feature check for babeltrace library [1], which will be used for
> perf data file CTF [2] conversion in following patches.
So this doesn't work on recent Ubuntu systems:
... libbabeltrace: [ OFF ]
triton:~/tip/tools/perf/config/feature-checks> make
test-libbabeltrace.bin
gcc -MD -Wall -Werror -o test-libbabeltrace.bin test-libbabeltrace.c
# -lbabeltrace provided by
test-libbabeltrace.c: In function ‘main’:test-libbabeltrace.c:6:2: error:
implicit declaration of function ‘bt_ctf_stream_class_get_packet_context_type’
[-Werror=implicit-function-declaration]
bt_ctf_stream_class_get_packet_context_type((void *) 0);
^
cc1: all warnings being treated as errors
Makefile:140: recipe for target 'test-libbabeltrace.bin' failed
I have all the requirements, libbabeltrace-ctf-dev and
libbabeltrace-dev installed, yet the writer.h file:
-rw-r--r-- 1 root root 5283 Oct 7 14:44
/usr/include/babeltrace/ctf-writer/writer.h
does not include a prototype for
bt_ctf_stream_class_get_packet_context_type().
If Ubuntu's writer.h is too old then either our API use should match
the ones available:
triton:~/tip/tools/perf/config/feature-checks> grep extern
/usr/include/babeltrace/ctf-writer/writer.h
extern "C" {
extern struct bt_ctf_writer *bt_ctf_writer_create(const char *path);
extern struct bt_ctf_stream *bt_ctf_writer_create_stream(
extern int bt_ctf_writer_add_environment_field(struct bt_ctf_writer *writer,
extern int bt_ctf_writer_add_clock(struct bt_ctf_writer *writer,
extern char *bt_ctf_writer_get_metadata_string(struct bt_ctf_writer *writer);
extern void bt_ctf_writer_flush_metadata(struct bt_ctf_writer *writer);
extern int bt_ctf_writer_set_byte_order(struct bt_ctf_writer *writer,
extern void bt_ctf_writer_get(struct bt_ctf_writer *writer);
extern void bt_ctf_writer_put(struct bt_ctf_writer *writer);
or CTF support should be removed from the default set of perf
features, because right now it blocks the 'all' build speedup.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] add nproc cgroup subsystem
> I wouldn't think that preventing PID exhaustion would be all that much of a > niche case, it's fully possible for it to happen without using excessive > amounts of kernel memory (think about BIG server systems with terabytes of > memory running (arguably poorly written) forking servers that handle tens of > thousands of client requests per second, each lasting multiple tens of > seconds), and not necessarily as trivial as you might think to handle sanely > (especially if you want callbacks when the limits get hit). > As far as being trivial to achieve, I'm assuming you are referring to rlimit > and PAM's limits module, both of which have their own issues. Using > pam_limits.so to limit processes isn't trivial because it requires calling > through PAM to begin with, which almost no software that isn't login related > does, and rlimits are tricky to set up properly with the granularity that > having a cgroup would provide. I just want to quickly echo my support for this statement. Process IDs aren't limited by kernel memory, they're a hard-set limit. Thus they are a resource like other global resources (open files, etc). Now, while you can argue that it is possible to limit the amount of *effective* processes you can use in a cgroup through kmemcg (by limiting the amount of memory spent in storing task_struct data) -- that isn't limiting the usage of the *actual* resource (the fact you're limiting the number of PIDs is little more than a by-product). Also, If it wasn't an actual resource then why is RLIMIT_NPROC a thing? To me, that indicates that PID limiting not an esoteric usecase and it should be possible to use the Linux kernel's home-grown accounting system to limit the number of PIDs in a cgroup. Otherwise you're stuck in a weird world where you *can* limit the number of processes in a process tree but *not* the number of processes in a cgroup. >> In general, I'm pretty strongly against adding controllers for things >> which aren't fundamental resources in the system. What's next? Open >> files? Pipe buffer? Number of flocks? Number of session leaders or >> program groups? >> > PID's are a fundamental resource, you run out and it's an only marginally > better situation than OOM, namely, if you don't already have a shell open > which has kill builtin (because you can't fork), or have some other reliable > way to terminate processes without forking, you are stuck either waiting for > the problem to resolve itself, or have to reset the system. I couldn't agree more. PIDs are a fundamental resource because there is a hard limit on the amount of PIDs you can have in any one system. Once you've exhausted that limit, there's not much you can do apart from doing the SYSRQ dance. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/10] mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
On Thu, Feb 12, 2015 at 03:53:27PM +0100, Antoine Tenart wrote: > pxa3xx_flash_ids wasn't initialized to 0, which in certain cases could > end up containing corrupted values in its members. Fix this to avoid > possible issues. > > Signed-off-by: Antoine Tenart Applied this patch to l2-mtd.git. The others are TBD still. (Haven't examined all of them too closely.) Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: lustre: fld_request.c: Remove else after return.
On Fri, Feb 27, 2015 at 11:59:21AM -0300, Alberto Pires de Oliveira Neto wrote: > Sorry, still getting the hang of it. Should I resend the patch ? better. and then your subject line should have [PATCH v2]. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf trace: Fix SIGBUS failures due to misaligned accesses
Commit-ID: 55d43bcafe78b6da33f8a49be68ef168f3cbfec9
Gitweb: http://git.kernel.org/tip/55d43bcafe78b6da33f8a49be68ef168f3cbfec9
Author: David Ahern
AuthorDate: Thu, 19 Feb 2015 15:00:22 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Feb 2015 11:59:04 -0300
perf trace: Fix SIGBUS failures due to misaligned accesses
On Sparc64 perf-trace is failing in many spots due to extended load
instructions being used on misaligned accesses.
(gdb) run trace ls
Starting program: /tmp/perf/perf trace ls
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 169460.
Program received signal SIGBUS, Bus error.
0x0014f4dc in tp_field__u64 (field=0x4cc700, sample=0x7fea098) at
builtin-trace.c:61
warning: Source file is more recent than executable.
61 TP_UINT_FIELD(64);
(gdb) bt
0 0x0014f4dc in tp_field__u64 (field=0x4cc700, sample=0x7fea098)
at builtin-trace.c:61
1 0x00156ad4 in trace__sys_exit (trace=0x7fec268, evsel=0x4cc580,
event=0xfc0104912000,
sample=0x7fea098) at builtin-trace.c:1701
2 0x00158c14 in trace__run (trace=0x7fec268, argc=1,
argv=0x7fef360) at builtin-trace.c:2160
3 0x0015b78c in cmd_trace (argc=1, argv=0x7fef360, prefix=0x0) at
builtin-trace.c:2609
4 0x00107d94 in run_builtin (p=0x4549c8, argc=2, argv=0x7fef360)
at perf.c:341
5 0x00108140 in handle_internal_command (argc=2, argv=0x7fef360)
at perf.c:400
6 0x00108308 in run_argv (argcp=0x7feef2c, argv=0x7feef20) at
perf.c:444
7 0x00108728 in main (argc=2, argv=0x7fef360) at perf.c:559
(gdb) p *sample
$1 = {ip = 4391276, pid = 169472, tid = 169472, time = 6303014583281250, addr =
0, id = 72082,
stream_id = 18446744073709551615, period = 1, weight = 0, transaction = 0,
cpu = 73, raw_size = 36,
data_src = 84410401, flags = 0, insn_len = 0, raw_data = 0xfc010491203c,
callchain = 0x0,
branch_stack = 0x0, user_regs = {abi = 0, mask = 0, regs = 0x0, cache_regs =
0x7fea098, cache_mask = 0},
intr_regs = {abi = 0, mask = 0, regs = 0x0, cache_regs = 0x7fea098,
cache_mask = 0}, user_stack = {
offset = 0, size = 0, data = 0x0}, read = {time_enabled = 0, time_running =
0, {group = {nr = 0,
values = 0x0}, one = {value = 0, id = 0
(gdb) p *field
$2 = {offset = 16, {integer = 0x14f4a8 , pointer = 0x14f4a8
}}
sample->raw_data is guaranteed to not be 8-byte aligned because it is preceded
by the size as a u3. So accessing raw data with an extended load instruction
causes
the SIGBUS. Resolve by using memcpy to a temporary variable of appropriate size.
Signed-off-by: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1424376022-140608-1-git-send-email-david.ah...@oracle.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 5cd84974..d95a8f4 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -52,7 +52,9 @@ struct tp_field {
#define TP_UINT_FIELD(bits) \
static u64 tp_field__u##bits(struct tp_field *field, struct perf_sample
*sample) \
{ \
- return *(u##bits *)(sample->raw_data + field->offset); \
+ u##bits value; \
+ memcpy(&value, sample->raw_data + field->offset, sizeof(value)); \
+ return value; \
}
TP_UINT_FIELD(8);
@@ -63,7 +65,8 @@ TP_UINT_FIELD(64);
#define TP_UINT_FIELD__SWAPPED(bits) \
static u64 tp_field__swapped_u##bits(struct tp_field *field, struct
perf_sample *sample) \
{ \
- u##bits value = *(u##bits *)(sample->raw_data + field->offset); \
+ u##bits value; \
+ memcpy(&value, sample->raw_data + field->offset, sizeof(value)); \
return bswap_##bits(value);\
}
@@ -1517,11 +1520,22 @@ static int trace__read_syscall_info(struct trace
*trace, int id)
return syscall__set_arg_fmts(sc);
}
+/*
+ * args is to be interpreted as a series of longs but we need to handle
+ * 8-byte unaligned accesses. args points to raw_data within the event
+ * and raw_data is guaranteed to be 8-byte unaligned because it is
+ * preceded by raw_size which is a u32. So we need to copy args to a temp
+ * variable to read it. Most notably this avoids extended load instructions
+ * on unaligned addresses
+ */
+
static size_t syscall__scnprintf_args(struct syscall *sc, char *bf, size_t
size,
- unsigned long *args, struct trace *trace,
+ unsigned char *args, struct trace *trace,
struct thread *thread)
{
size_t printed = 0;
+ unsigned char *p;
+ unsigned long val;
if (sc->tp_format != NULL) {
struct format_field *field;
@@ -1537,12 +1551,17 @@ static size_t syscall__scnprintf_args(struc
[tip:perf/core] perf probe: Handle strdup() failure
Commit-ID: 38ae502b1df196f712f6f5d3609afc36337b330b
Gitweb: http://git.kernel.org/tip/38ae502b1df196f712f6f5d3609afc36337b330b
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 26 Feb 2015 11:47:18 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 10:08:29 -0300
perf probe: Handle strdup() failure
We could end up returning 0 (Ok) with a NULL raw_path. Fix it.
Acked-by: Masami Hiramatsu
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Naohiro Aota
Link: http://lkml.kernel.org/n/tip-l0kcbcg5f4nnzqt01cv42...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 4a93bf4..9526cf3 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -533,7 +533,7 @@ static int get_real_path(const char *raw_path, const char
*comp_dir,
else {
if (access(raw_path, R_OK) == 0) {
*new_path = strdup(raw_path);
- return 0;
+ return *new_path ? 0 : -ENOMEM;
} else
return -errno;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf probe: Fix a precedence bug
Commit-ID: f56847c2e99810781f6941d01baff9ae223eeac3 Gitweb: http://git.kernel.org/tip/f56847c2e99810781f6941d01baff9ae223eeac3 Author: He Kuang AuthorDate: Fri, 27 Feb 2015 18:52:53 +0800 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 27 Feb 2015 10:31:09 -0300 perf probe: Fix a precedence bug The minus operator has higher precedence than ?: Add parentheses around ?: fix this. Before this patch: $ echo 'p:myprobe do_sys_open' > /sys/kernel/debug/tracing/kprobe_events $ perf probe -l -k ../vmlinux kprobes:myprobe (on do_sys_open) After this patch: $ echo 'p:myprobe do_sys_open' > /sys/kernel/debug/tracing/kprobe_events $ perf probe -l -k ../vmlinux kprobes:myprobe (on do_sys_o...@linux.git/fs/open.c) Signed-off-by: He Kuang Acked-by: Masami Hiramatsu Cc: Wang Nan Link: http://lkml.kernel.org/r/1425034373-14511-1-git-send-email-heku...@huawei.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/probe-event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c index 9526cf3..7c0e765 100644 --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -151,7 +151,7 @@ static u64 kernel_get_symbol_address_by_name(const char *name, bool reloc) sym = __find_kernel_function_by_name(name, &map); if (sym) return map->unmap_ip(map, sym->start) - - (reloc) ? 0 : map->reloc; + ((reloc) ? 0 : map->reloc); } 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/
[tip:perf/core] perf buildid-cache: Add new buildid cache if update target is not cached
Commit-ID: a50d11a10c2db86d7383c281d4e249d5393661e9
Gitweb: http://git.kernel.org/tip/a50d11a10c2db86d7383c281d4e249d5393661e9
Author: Masami Hiramatsu
AuthorDate: Thu, 26 Feb 2015 15:54:40 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 10:08:37 -0300
perf buildid-cache: Add new buildid cache if update target is not cached
Add new buildid cache if the update target file is not cached.
This can happen when an old binary is replaced by new one after caching
the old one. In this case, user sees his operation just failed.
But it does not look straight, since user just pass the binary "path",
not "build-id".
# ./perf buildid-cache --add ./perf
(update ./perf to new binary)
# ./perf buildid-cache --update ./perf
./perf wasn't in the cache
#
This patch adds given new binary to cache if the new binary is
not cached. So we'll not see the above error.
# ./perf buildid-cache --add ./perf
(update ./perf to new binary)
# ./perf buildid-cache --update ./perf
#
Signed-off-by: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Hemant Kumar
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150226065440.23912.1494.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-buildid-cache.txt | 11 ---
tools/perf/builtin-buildid-cache.c | 6 --
tools/perf/util/build-id.c | 12
tools/perf/util/build-id.h | 1 +
4 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/tools/perf/Documentation/perf-buildid-cache.txt
b/tools/perf/Documentation/perf-buildid-cache.txt
index 0294c57..cec6b57 100644
--- a/tools/perf/Documentation/perf-buildid-cache.txt
+++ b/tools/perf/Documentation/perf-buildid-cache.txt
@@ -41,9 +41,14 @@ OPTIONS
--missing=::
List missing build ids in the cache for the specified file.
-u::
---update::
- Update specified file of the cache. It can be used to update kallsyms
- kernel dso to vmlinux in order to support annotation.
+--update=::
+ Update specified file of the cache. Note that this doesn't remove
+ older entires since those may be still needed for annotating old
+ (or remote) perf.data. Only if there is already a cache which has
+ exactly same build-id, that is replaced by new one. It can be used
+ to update kallsyms and kernel dso to vmlinux in order to support
+ annotation.
+
-v::
--verbose::
Be more verbose.
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index d929d95..e7568f5 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -255,7 +255,7 @@ static int build_id_cache__update_file(const char *filename)
u8 build_id[BUILD_ID_SIZE];
char sbuild_id[BUILD_ID_SIZE * 2 + 1];
- int err;
+ int err = 0;
if (filename__read_build_id(filename, &build_id, sizeof(build_id)) < 0)
{
pr_debug("Couldn't read a build-id in %s\n", filename);
@@ -263,7 +263,9 @@ static int build_id_cache__update_file(const char *filename)
}
build_id__sprintf(build_id, sizeof(build_id), sbuild_id);
- err = build_id_cache__remove_s(sbuild_id);
+ if (build_id_cache__cached(sbuild_id))
+ err = build_id_cache__remove_s(sbuild_id);
+
if (!err)
err = build_id_cache__add_s(sbuild_id, filename, false, false);
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index adbc360..0bc33be 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -352,6 +352,18 @@ static int build_id_cache__add_b(const u8 *build_id,
size_t build_id_size,
return build_id_cache__add_s(sbuild_id, name, is_kallsyms, is_vdso);
}
+bool build_id_cache__cached(const char *sbuild_id)
+{
+ bool ret = false;
+ char *filename = build_id__filename(sbuild_id, NULL, 0);
+
+ if (filename && !access(filename, F_OK))
+ ret = true;
+ free(filename);
+
+ return ret;
+}
+
int build_id_cache__remove_s(const char *sbuild_id)
{
const size_t size = PATH_MAX;
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 31b3c63..2a09498 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -22,6 +22,7 @@ bool perf_session__read_build_ids(struct perf_session
*session, bool with_hits);
int perf_session__write_buildid_table(struct perf_session *session, int fd);
int perf_session__cache_build_ids(struct perf_session *session);
+bool build_id_cache__cached(const char *sbuild_id);
int build_id_cache__add_s(const char *sbuild_id,
const char *name, bool is_kallsyms, bool is_vdso);
int build_id_cache__remove_s(const char *sbuild_id);
--
To unsubscribe from this list:
[tip:perf/core] perf probe: Check kprobes blacklist when adding new events
Commit-ID: 9aaf5a5f479bd68699f2e6f6e5e5f1253377b6da
Gitweb: http://git.kernel.org/tip/9aaf5a5f479bd68699f2e6f6e5e5f1253377b6da
Author: Masami Hiramatsu
AuthorDate: Thu, 19 Feb 2015 23:31:13 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Feb 2015 11:59:05 -0300
perf probe: Check kprobes blacklist when adding new events
Recent linux kernel provides a blacklist of the functions which can not
be probed. perf probe can now check this blacklist before setting new
events and indicate better error message for users.
Without this patch,
# perf probe --add vmalloc_fault
Added new event:
Failed to write event: Invalid argument
Error: Failed to add events.
With this patch
# perf probe --add vmalloc_fault
Added new event:
Warning: Skipped probing on blacklisted function: vmalloc_fault
Reported-by: Arnaldo Carvalho de Melo
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150219143113.14434.5387.stgit@localhost.localdomain
Signed-off-by: Masami Hiramatsu
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 109 +-
1 file changed, 108 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 9dfbed9..662d454 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1903,6 +1903,95 @@ static struct strlist
*get_probe_trace_command_rawlist(int fd)
return sl;
}
+struct kprobe_blacklist_node {
+ struct list_head list;
+ unsigned long start;
+ unsigned long end;
+ char *symbol;
+};
+
+static void kprobe_blacklist__delete(struct list_head *blacklist)
+{
+ struct kprobe_blacklist_node *node;
+
+ while (!list_empty(blacklist)) {
+ node = list_first_entry(blacklist,
+ struct kprobe_blacklist_node, list);
+ list_del(&node->list);
+ free(node->symbol);
+ free(node);
+ }
+}
+
+static int kprobe_blacklist__load(struct list_head *blacklist)
+{
+ struct kprobe_blacklist_node *node;
+ const char *__debugfs = debugfs_find_mountpoint();
+ char buf[PATH_MAX], *p;
+ FILE *fp;
+ int ret;
+
+ if (__debugfs == NULL)
+ return -ENOTSUP;
+
+ ret = e_snprintf(buf, PATH_MAX, "%s/kprobes/blacklist", __debugfs);
+ if (ret < 0)
+ return ret;
+
+ fp = fopen(buf, "r");
+ if (!fp)
+ return -errno;
+
+ ret = 0;
+ while (fgets(buf, PATH_MAX, fp)) {
+ node = zalloc(sizeof(*node));
+ if (!node) {
+ ret = -ENOMEM;
+ break;
+ }
+ INIT_LIST_HEAD(&node->list);
+ list_add_tail(&node->list, blacklist);
+ if (sscanf(buf, "0x%lx-0x%lx", &node->start, &node->end) != 2) {
+ ret = -EINVAL;
+ break;
+ }
+ p = strchr(buf, '\t');
+ if (p) {
+ p++;
+ if (p[strlen(p) - 1] == '\n')
+ p[strlen(p) - 1] = '\0';
+ } else
+ p = (char *)"unknown";
+ node->symbol = strdup(p);
+ if (!node->symbol) {
+ ret = -ENOMEM;
+ break;
+ }
+ pr_debug2("Blacklist: 0x%lx-0x%lx, %s\n",
+ node->start, node->end, node->symbol);
+ ret++;
+ }
+ if (ret < 0)
+ kprobe_blacklist__delete(blacklist);
+ fclose(fp);
+
+ return ret;
+}
+
+static struct kprobe_blacklist_node *
+kprobe_blacklist__find_by_address(struct list_head *blacklist,
+ unsigned long address)
+{
+ struct kprobe_blacklist_node *node;
+
+ list_for_each_entry(node, blacklist, list) {
+ if (node->start <= address && address <= node->end)
+ return node;
+ }
+
+ return NULL;
+}
+
/* Show an event */
static int show_perf_probe_event(struct perf_probe_event *pev,
const char *module)
@@ -2117,6 +2206,8 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
char buf[64];
const char *event, *group;
struct strlist *namelist;
+ LIST_HEAD(blacklist);
+ struct kprobe_blacklist_node *node;
if (pev->uprobes)
fd = open_uprobe_events(true);
@@ -2134,11 +2225,25 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
pr_debug("Failed to get current event list.\n");
return -EIO;
}
+ /* Get kprobe blacklist if exists */
+ if (!pev->uprobes) {
+ ret = kprobe_blacklist__load(&blacklist);
+
ACPI regression with 3.19+
Hallo, my system won't boot with current GIT kernel (see attached screenshot). The system seems somewhat frozen (cannot ssh into it), but magic sysrq still works. I bisected the problem to commit 593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and dmesg output from previous commit, which still booted. I don't know if related, but the message "pnp 00:00: can't evaluate _CRS: 1" is also new to me. I saw it with commit 8515f9368161730655b64ddaf8b11a3d20049610, but not with c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between. I am not subscribed, so please CC if you need more info. Thanks. Regards, Prakash config_812dbd9994f122629db73205a7f7f46b430a6360.xz Description: application/xz kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz Description: application/xz
[tip:perf/core] perf data: Fix sentinel setting for data_cmds array
Commit-ID: 1f924c29b5ab2257be88a2a4075d0800573d8479
Gitweb: http://git.kernel.org/tip/1f924c29b5ab2257be88a2a4075d0800573d8479
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 19:53:46 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 10:43:18 -0300
perf data: Fix sentinel setting for data_cmds array
The recent new patch "perf tools: Add new 'perf data' command" (commit
2245bf14 in acme's git repo perf/core) has caused a building error when
compiling the source code of perf:
cc1: warnings being treated as errors
builtin-data.c:89: error: missing initializer
builtin-data.c:89: error: (near initialization for ‘data_cmds[1].summary’)
make[2]: *** [builtin-data.o] Error 1
make[2]: *** Waiting for unfinished jobs
LD bench/perf-in.o
LD tests/perf-in.o
make[1]: *** [perf-in.o] Error 2
make: *** [all] Error 2
This patch fixes the building error above.
Signed-off-by: Yunlong Song
Cc: Peter Zijlstra
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425038026-27604-1-git-send-email-yunlong.s...@huawei.com
[ .name == NULL ends the loop, use it instead of seting all fields to NULL ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-data.c b/tools/perf/builtin-data.c
index 9705ba7..155cf75 100644
--- a/tools/perf/builtin-data.c
+++ b/tools/perf/builtin-data.c
@@ -86,7 +86,7 @@ static int cmd_data_convert(int argc, const char **argv,
static struct data_cmd data_cmds[] = {
{ "convert", "converts data file between formats", cmd_data_convert },
- { NULL },
+ { .name = NULL, },
};
int cmd_data(int argc, const char **argv, const char *prefix)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf list: Sort the output of 'perf list' to view more clearly
Commit-ID: ab0e48002db818c1937f105cd18001dfdd3ce056
Gitweb: http://git.kernel.org/tip/ab0e48002db818c1937f105cd18001dfdd3ce056
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:25 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:51:44 -0300
perf list: Sort the output of 'perf list' to view more clearly
Sort the output according to ASCII character list (using strcmp), which
supports both number sequence and alphabet sequence.
Example:
Before this patch:
$ perf list
List of pre-defined events (to be used in -e):
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
cache-references [Hardware event]
cache-misses [Hardware event]
branch-instructions OR branches[Hardware event]
branch-misses [Hardware event]
bus-cycles [Hardware event]
......
jbd2:jbd2_start_commit [Tracepoint event]
jbd2:jbd2_commit_locking [Tracepoint event]
jbd2:jbd2_run_stats[Tracepoint event]
block:block_rq_issue [Tracepoint event]
block:block_bio_complete [Tracepoint event]
block:block_bio_backmerge [Tracepoint event]
block:block_getrq [Tracepoint event]
......
After this patch:
$ perf list
List of pre-defined events (to be used in -e):
branch-instructions OR branches[Hardware event]
branch-misses [Hardware event]
bus-cycles [Hardware event]
cache-misses [Hardware event]
cache-references [Hardware event]
cpu-cycles OR cycles [Hardware event]
instructions [Hardware event]
......
block:block_bio_backmerge [Tracepoint event]
block:block_bio_complete [Tracepoint event]
block:block_getrq [Tracepoint event]
block:block_rq_issue [Tracepoint event]
jbd2:jbd2_commit_locking [Tracepoint event]
jbd2:jbd2_run_stats[Tracepoint event]
jbd2:jbd2_start_commit [Tracepoint event]
......
Signed-off-by: Yunlong Song
Tested-by: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-2-git-send-email-yunlong.s...@huawei.com
[ Don't forget closedir({sys,evt}_dir) when handling errors ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 216 -
1 file changed, 193 insertions(+), 23 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 109ba5c..f6822d9 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1089,6 +1089,14 @@ static const char * const event_type_descriptors[] = {
"Hardware breakpoint",
};
+static int cmp_string(const void *a, const void *b)
+{
+ const char * const *as = a;
+ const char * const *bs = b;
+
+ return strcmp(*as, *bs);
+}
+
/*
* Print the events from /tracing/events
*/
@@ -1100,11 +1108,21 @@ void print_tracepoint_events(const char *subsys_glob,
const char *event_glob,
struct dirent *sys_next, *evt_next, sys_dirent, evt_dirent;
char evt_path[MAXPATHLEN];
char dir_path[MAXPATHLEN];
+ char **evt_list = NULL;
+ unsigned int evt_i = 0, evt_num = 0;
+ bool evt_num_known = false;
+restart:
sys_dir = opendir(tracing_events_path);
if (!sys_dir)
return;
+ if (evt_num_known) {
+ evt_list = zalloc(sizeof(char *) * evt_num);
+ if (!evt_list)
+ goto out_close_sys_dir;
+ }
+
for_each_subsystem(sys_dir, sys_dirent, sys_next) {
if (subsys_glob != NULL &&
!strglobmatch(sys_dirent.d_name, subsys_glob))
@@ -1121,19 +1139,56 @@ void print_tracepoint_events(const char *subsys_glob,
const char *event_glob,
!strglobmatch(evt_dirent.d_name, event_glob))
continue;
- if (name_only) {
- printf("%s:%s ", sys_dirent
[tip:perf/core] perf list: Allow listing events with 'tracepoint' prefix
Commit-ID: 161149513b3570ebd7fe14fc2ddc42cb46557e37
Gitweb: http://git.kernel.org/tip/161149513b3570ebd7fe14fc2ddc42cb46557e37
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:26 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:51:51 -0300
perf list: Allow listing events with 'tracepoint' prefix
If somebody happens to name an event with the beginning of 'tracepoint'
(e.g. tracepoint_foo), then it will never be showed with perf list
event_glob, thus we parse the argument 'tracepoint' more carefully for
accuracy.
Example:
Before this patch:
$ perf list tracepoint_foo:*
jbd2:jbd2_start_commit [Tracepoint event]
jbd2:jbd2_commit_locking [Tracepoint event]
jbd2:jbd2_run_stats[Tracepoint event]
block:block_rq_issue [Tracepoint event]
block:block_bio_complete [Tracepoint event]
block:block_bio_backmerge [Tracepoint event]
block:block_getrq [Tracepoint event]
......
As shown above, all of the tracepoint events are printed. In fact, the
command's real intention is to print the events of tracepoint_foo.
After this patch:
$ perf list tracepoint_foo:*
tracepoint_foo:tp_foo_enter[Tracepoint event]
tracepoint_foo:tp_foo_exit [Tracepoint event]
As shown above, only the events of tracepoint_foo are printed.
Signed-off-by: Yunlong Song
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-3-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-list.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index ad8018e..2acbcf0 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -50,9 +50,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
}
for (i = 0; i < argc; ++i) {
- if (i)
- putchar('\n');
- if (strncmp(argv[i], "tracepoint", 10) == 0)
+ if (strcmp(argv[i], "tracepoint") == 0)
print_tracepoint_events(NULL, NULL, false);
else if (strcmp(argv[i], "hw") == 0 ||
strcmp(argv[i], "hardware") == 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/
[tip:perf/core] perf list: Avoid confusion of perf output and the next command prompt
Commit-ID: ed45752061be11a40f57df4304296147dbda2da9
Gitweb: http://git.kernel.org/tip/ed45752061be11a40f57df4304296147dbda2da9
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:29 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:09 -0300
perf list: Avoid confusion of perf output and the next command prompt
Distinguish the output of 'perf list --list-opts' or 'perf --list-cmds'
with the next command prompt, which also happens in other cases (e.g.
record, report ...).
Example:
Before this patch:
$perf list --list-opts
--raw-dump $ <-- the output and the next command prompt are at
the same line
After this patch:
$perf list --list-opts
--raw-dump
$ <-- the new line
Signed-off-by: Yunlong Song
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-6-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/perf.c | 1 +
tools/perf/util/parse-options.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index f3c66b8..3df2665 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -223,6 +223,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
struct cmd_struct *p = commands+i;
printf("%s ", p->cmd);
}
+ putchar('\n');
exit(0);
} else if (!strcmp(cmd, "--debug")) {
if (*argc < 2) {
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 4ee9a86..b0ef2d8 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -508,12 +508,14 @@ int parse_options_subcommand(int argc, const char **argv,
const struct option *o
printf("--%s ", options->long_name);
options++;
}
+ putchar('\n');
exit(130);
case PARSE_OPT_LIST_SUBCMDS:
if (subcommands) {
for (int i = 0; subcommands[i]; i++)
printf("%s ", subcommands[i]);
}
+ putchar('\n');
exit(130);
default: /* PARSE_OPT_UNKNOWN */
if (ctx.argv[0][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/
[tip:perf/core] perf list: Clean up the printing functions of hardware/software events
Commit-ID: 705750f2d6e283ba2856ba8eda60dce2d405b387
Gitweb: http://git.kernel.org/tip/705750f2d6e283ba2856ba8eda60dce2d405b387
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:27 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:18 -0300
perf list: Clean up the printing functions of hardware/software events
Do not need print_events_type or __print_events_type for listing hw/sw
events, let print_symbol_events do its job instead. Moreover,
print_symbol_events can also handle event_glob and name_only.
Signed-off-by: Yunlong Song
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-4-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-list.c | 6 ++--
tools/perf/util/parse-events.c | 80 ++
tools/perf/util/parse-events.h | 11 +-
3 files changed, 17 insertions(+), 80 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 2acbcf0..8b323e0 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -54,10 +54,12 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
print_tracepoint_events(NULL, NULL, false);
else if (strcmp(argv[i], "hw") == 0 ||
strcmp(argv[i], "hardware") == 0)
- print_events_type(PERF_TYPE_HARDWARE);
+ print_symbol_events(NULL, PERF_TYPE_HARDWARE,
+ event_symbols_hw, PERF_COUNT_HW_MAX,
false);
else if (strcmp(argv[i], "sw") == 0 ||
strcmp(argv[i], "software") == 0)
- print_events_type(PERF_TYPE_SOFTWARE);
+ print_symbol_events(NULL, PERF_TYPE_SOFTWARE,
+ event_symbols_sw, PERF_COUNT_SW_MAX,
false);
else if (strcmp(argv[i], "cache") == 0 ||
strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, false);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f6822d9..fe07573 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -20,11 +20,6 @@
#define MAX_NAME_LEN 100
-struct event_symbol {
- const char *symbol;
- const char *alias;
-};
-
#ifdef PARSER_DEBUG
extern int parse_events_debug;
#endif
@@ -39,7 +34,7 @@ static struct perf_pmu_event_symbol *perf_pmu_events_list;
*/
static int perf_pmu_events_list_num;
-static struct event_symbol event_symbols_hw[PERF_COUNT_HW_MAX] = {
+struct event_symbol event_symbols_hw[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_CPU_CYCLES] = {
.symbol = "cpu-cycles",
.alias = "cycles",
@@ -82,7 +77,7 @@ static struct event_symbol
event_symbols_hw[PERF_COUNT_HW_MAX] = {
},
};
-static struct event_symbol event_symbols_sw[PERF_COUNT_SW_MAX] = {
+struct event_symbol event_symbols_sw[PERF_COUNT_SW_MAX] = {
[PERF_COUNT_SW_CPU_CLOCK] = {
.symbol = "cpu-clock",
.alias = "",
@@ -1269,75 +1264,6 @@ static bool is_event_supported(u8 type, unsigned config)
return ret;
}
-static void __print_events_type(u8 type, struct event_symbol *syms,
- unsigned max)
-{
- char name[64];
- unsigned int i, evt_i = 0, evt_num = 0;
- char **evt_list = NULL;
- bool evt_num_known = false;
-
-restart:
- if (evt_num_known) {
- evt_list = zalloc(sizeof(char *) * evt_num);
- if (!evt_list)
- goto out_enomem;
- syms -= max;
- }
-
- for (i = 0; i < max ; i++, syms++) {
- if (!is_event_supported(type, i))
- continue;
-
- if (!evt_num_known) {
- evt_num++;
- continue;
- }
-
- if (strlen(syms->alias))
- snprintf(name, sizeof(name), "%s OR %s",
-syms->symbol, syms->alias);
- else
- snprintf(name, sizeof(name), "%s", syms->symbol);
-
- evt_list[evt_i] = strdup(name);
- if (evt_list[evt_i] == NULL)
- goto out_enomem;
- evt_i++;
- }
-
- if (!evt_num_known) {
- evt_num_known = true;
- goto restart;
- }
- qsort(evt_list, evt_num, sizeof(char *), cmp_string);
- evt_i = 0;
- while (evt_i < evt_num)
- printf(" %-50s [%s]\n", evt_list[evt_i++],
event_type_descriptors[type]);
- if (evt_num)
- printf("\n");
-
-out_free:
- evt_num = evt_i;
- for (evt_i = 0; evt_i < evt_num; evt_i++)
-
[tip:perf/core] perf tools: Remove the '--(null)' long_name for --list-opts
Commit-ID: 3ef1e65c829c86ffaa94a4ed59fed5da37f9610a
Gitweb: http://git.kernel.org/tip/3ef1e65c829c86ffaa94a4ed59fed5da37f9610a
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:30 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:14 -0300
perf tools: Remove the '--(null)' long_name for --list-opts
If the long_name of a 'struct option' is defined as NULL, --list-opts
will incorrectly print '--(null)' in its output. As a result, '--(null)'
will finally appear in the case of bash completion, e.g. 'perf record
--'.
Example:
Before this patch:
$ perf record --list-opts
--event --filter --pid --tid --realtime --no-buffering --raw-samples
--all-cpus --cpu --count --output --no-inherit --freq --mmap-pages
--group --(null) --call-graph --verbose --quiet --stat --data
--timestamp --period --no-samples --no-buildid-cache --no-buildid
--cgroup --delay --uid --branch-any --branch-filter --weight
--transaction --per-thread --intr-regs
After this patch:
$ perf record --list-opts
--event --filter --pid --tid --realtime --no-buffering --raw-samples
--all-cpus --cpu --count --output --no-inherit --freq --mmap-pages
--group --call-graph --verbose --quiet --stat --data --timestamp
--period --no-samples --no-buildid-cache --no-buildid --cgroup --delay
--uid --branch-any --branch-filter --weight --transaction --per-thread
--intr-regs
Signed-off-by: Yunlong Song
Tested-by: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-7-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index b0ef2d8..1457d66 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -505,7 +505,8 @@ int parse_options_subcommand(int argc, const char **argv,
const struct option *o
break;
case PARSE_OPT_LIST_OPTS:
while (options->type != OPTION_END) {
- printf("--%s ", options->long_name);
+ if (options->long_name)
+ printf("--%s ", options->long_name);
options++;
}
putchar('\n');
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf list: Extend raw-dump to certain kind of events
Commit-ID: 5ef803ee02d67ad0b49f357cb7feb7d5e6b0015d
Gitweb: http://git.kernel.org/tip/5ef803ee02d67ad0b49f357cb7feb7d5e6b0015d
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:28 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:24 -0300
perf list: Extend raw-dump to certain kind of events
Extend 'perf list --raw-dump' to 'perf list --raw-dump [hw|sw|cache
|tracepoint|pmu|event_glob]' in order to show the raw-dump of a certain
kind of events rather than all of the events.
Example:
Before this patch:
$ perf list --raw-dump hw
branch-instructions branch-misses bus-cycles cache-misses
cache-references cpu-cycles instructions stalled-cycles-backend
stalled-cycles-frontend
alignment-faults context-switches cpu-clock cpu-migrations
emulation-faults major-faults minor-faults page-faults task-clock
...
...
writeback:writeback_thread_start writeback:writeback_thread_stop
writeback:writeback_wait_iff_congested
writeback:writeback_wake_background writeback:writeback_wake_thread
As shown above, all of the events are printed.
After this patch:
$ perf list --raw-dump hw
branch-instructions branch-misses bus-cycles cache-misses
cache-references cpu-cycles instructions stalled-cycles-backend
stalled-cycles-frontend
As shown above, only the hw events are printed.
Signed-off-by: Yunlong Song
Tested-by: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-5-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-list.txt | 6 ++
tools/perf/builtin-list.c | 21 -
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index 3e2aec9..4692d27 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -127,6 +127,12 @@ To limit the list use:
One or more types can be used at the same time, listing the events for the
types specified.
+Support raw format:
+
+. '--raw-dump', shows the raw-dump of all the events.
+. '--raw-dump [hw|sw|cache|tracepoint|pmu|event_glob]', shows the raw-dump of
+ a certain kind of events.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-top[1],
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 8b323e0..af5bd05 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -36,41 +36,36 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
setup_pager();
- if (raw_dump) {
- print_events(NULL, true);
- return 0;
- }
-
if (!raw_dump)
printf("\nList of pre-defined events (to be used in -e):\n\n");
if (argc == 0) {
- print_events(NULL, false);
+ print_events(NULL, raw_dump);
return 0;
}
for (i = 0; i < argc; ++i) {
if (strcmp(argv[i], "tracepoint") == 0)
- print_tracepoint_events(NULL, NULL, false);
+ print_tracepoint_events(NULL, NULL, raw_dump);
else if (strcmp(argv[i], "hw") == 0 ||
strcmp(argv[i], "hardware") == 0)
print_symbol_events(NULL, PERF_TYPE_HARDWARE,
- event_symbols_hw, PERF_COUNT_HW_MAX,
false);
+ event_symbols_hw, PERF_COUNT_HW_MAX,
raw_dump);
else if (strcmp(argv[i], "sw") == 0 ||
strcmp(argv[i], "software") == 0)
print_symbol_events(NULL, PERF_TYPE_SOFTWARE,
- event_symbols_sw, PERF_COUNT_SW_MAX,
false);
+ event_symbols_sw, PERF_COUNT_SW_MAX,
raw_dump);
else if (strcmp(argv[i], "cache") == 0 ||
strcmp(argv[i], "hwcache") == 0)
- print_hwcache_events(NULL, false);
+ print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
- print_pmu_events(NULL, false);
+ print_pmu_events(NULL, raw_dump);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
if (sep == NULL) {
- print_events(argv[i], false);
+ print_events(argv[i], raw_dump);
continue;
}
sep_idx = sep - argv[i];
@@ -79,7 +74,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
return -1;
s[sep_idx] = '\0';
- print_
[tip:perf/core] perf buildid-cache: Add --purge FILE to remove all caches of FILE
Commit-ID: 8d8c8e4cb3014fcc51f0e127b4316043306f5bb0
Gitweb: http://git.kernel.org/tip/8d8c8e4cb3014fcc51f0e127b4316043306f5bb0
Author: Masami Hiramatsu
AuthorDate: Fri, 27 Feb 2015 13:50:26 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:33 -0300
perf buildid-cache: Add --purge FILE to remove all caches of FILE
Add --purge FILE to remove all caches of FILE.
Since the current --remove FILE removes a cache which has
same build-id of given FILE. Since the command takes a
FILE path, it can confuse user who tries to remove cache
about FILE path.
-
# ./perf buildid-cache -v --add ./perf
Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
# (update the ./perf binary)
# ./perf buildid-cache -v --remove ./perf
Removing 305bbd1be68f66eca7e2d78db294653031edfa79 ./perf: FAIL
./perf wasn't in the cache
-
Actually, the --remove's FAIL is not shown, it just silently fails.
So, this patch adds --purge FILE action for such usecase.
perf buildid-cache --purge FILE removes all caches which has same FILE
path.
In other words, it removes all caches including old binaries.
-
# ./perf buildid-cache -v --add ./perf
Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
# (update the ./perf binary)
# ./perf buildid-cache -v --purge ./perf
Removing 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
-
BTW, if you want to purge all the caches, remove ~/.debug/* .
Signed-off-by: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Hemant Kumar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150227045026.1999.64084.stgit@localhost.localdomain
[ s/dirname/dir_name/g to fix build on fedora14, where dirname is a global ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-buildid-cache.txt | 13 ++--
tools/perf/builtin-buildid-cache.c | 48 +
tools/perf/util/build-id.c | 93 -
tools/perf/util/build-id.h | 3 +
4 files changed, 136 insertions(+), 21 deletions(-)
diff --git a/tools/perf/Documentation/perf-buildid-cache.txt
b/tools/perf/Documentation/perf-buildid-cache.txt
index cec6b57..dd07b55 100644
--- a/tools/perf/Documentation/perf-buildid-cache.txt
+++ b/tools/perf/Documentation/perf-buildid-cache.txt
@@ -12,9 +12,9 @@ SYNOPSIS
DESCRIPTION
---
-This command manages the build-id cache. It can add and remove files to/from
-the cache. In the future it should as well purge older entries, set upper
-limits for the space used by the cache, etc.
+This command manages the build-id cache. It can add, remove, update and purge
+files to/from the cache. In the future it should as well set upper limits for
+the space used by the cache, etc.
OPTIONS
---
@@ -36,7 +36,12 @@ OPTIONS
actually made.
-r::
--remove=::
-Remove specified file from the cache.
+Remove a cached binary which has same build-id of specified file
+from the cache.
+-p::
+--purge=::
+Purge all cached binaries including older caches which have specified
+ path from the cache.
-M::
--missing=::
List missing build ids in the cache for the specified file.
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index e7568f5..86f9d78 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -223,6 +223,33 @@ static int build_id_cache__remove_file(const char
*filename)
return err;
}
+static int build_id_cache__purge_path(const char *pathname)
+{
+ struct strlist *list;
+ struct str_node *pos;
+ int err;
+
+ err = build_id_cache__list_build_ids(pathname, &list);
+ if (err)
+ goto out;
+
+ strlist__for_each(pos, list) {
+ err = build_id_cache__remove_s(pos->s);
+ if (verbose)
+ pr_info("Removing %s %s: %s\n", pos->s, pathname,
+ err ? "FAIL" : "Ok");
+ if (err)
+ break;
+ }
+ strlist__delete(list);
+
+out:
+ if (verbose)
+ pr_info("Purging %s: %s\n", pathname, err ? "FAIL" : "Ok");
+
+ return err;
+}
+
static bool dso__missing_buildid_cache(struct dso *dso, int parm
__maybe_unused)
{
char filename[PATH_MAX];
@@ -285,6 +312,7 @@ int cmd_buildid_cache(int argc, const char **argv,
bool force = false;
char const *add_name_list_str = NULL,
*remove_name_list_str = NULL,
+ *purge_name_list_str = NULL,
*missing_filename = NULL,
*update_name_list_str = NULL,
*kcore_filename = NULL;
@@ -302,6 +330,8 @@ int cmd_buildid_cache(int argc, const char **argv,
"file", "kcore file to add"),
OPT_STRING('r', "remove", &remov
[tip:perf/core] perf tools: Fix the bash completion problem of ' perf --*'
Commit-ID: 7335399a6a4bead9ef8b59ce7d811fc4e99ca98c
Gitweb: http://git.kernel.org/tip/7335399a6a4bead9ef8b59ce7d811fc4e99ca98c
Author: Yunlong Song
AuthorDate: Fri, 27 Feb 2015 18:21:31 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:28 -0300
perf tools: Fix the bash completion problem of 'perf --*'
The perf-completion.sh uses a predefined string '--help --version
--exec-path --html-path --paginate --no-pager --perf-dir --work-tree
--debugfs-dir' for the bash completion of 'perf --*', which has two
problems:
Problem 1: If the options of perf are changed (see handle_options() in
perf.c), the perf-completion.sh has to be changed at the same time. If
not, the bash completion of 'perf --*' and the options which perf
really supports will be inconsistent.
Problem 2: When typing another single character after 'perf --', e.g.
'h', and hit TAB key to get the bash completion of 'perf --h', the
character 'h' disappears at once. This is not what we want, we wish the
bash completion can return '--help --html-path' and then we can
continue to choose one.
To solve this problem, we add '--list-opts' to perf, which now supports
'perf --list-opts' directly, and its result can be used in bash
completion now.
Example:
Before this patch:
$ perf --h <-- hit TAB key after character 'h'
$ perf -- <-- 'h' disappears and no required result
After this patch:
$ perf --h <-- hit TAB key after character 'h'
--help --html-path <-- the required result
Signed-off-by: Yunlong Song
Tested-by: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1425032491-20224-8-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/perf-completion.sh | 6 ++
tools/perf/perf.c | 27 +++
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index 3356984..c2595e9 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -110,13 +110,11 @@ __perf_main ()
# List perf subcommands or long options
if [ $cword -eq 1 ]; then
if [[ $cur == --* ]]; then
- __perfcomp '--help --version \
- --exec-path --html-path --paginate --no-pager \
- --perf-dir --work-tree --debugfs-dir' -- "$cur"
+ cmds=$($cmd --list-opts)
else
cmds=$($cmd --list-cmds)
- __perfcomp "$cmds" "$cur"
fi
+ __perfcomp "$cmds" "$cur"
# List possible events for -e option
elif [[ $prev == "-e" && "${words[1]}" == @(record|stat|top) ]]; then
evts=$($cmd list --raw-dump)
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 3df2665..b857fcb 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -13,6 +13,7 @@
#include "util/quote.h"
#include "util/run-command.h"
#include "util/parse-events.h"
+#include "util/parse-options.h"
#include "util/debug.h"
#include
#include
@@ -125,6 +126,23 @@ static void commit_pager_choice(void)
}
}
+struct option options[] = {
+ OPT_ARGUMENT("help", "help"),
+ OPT_ARGUMENT("version", "version"),
+ OPT_ARGUMENT("exec-path", "exec-path"),
+ OPT_ARGUMENT("html-path", "html-path"),
+ OPT_ARGUMENT("paginate", "paginate"),
+ OPT_ARGUMENT("no-pager", "no-pager"),
+ OPT_ARGUMENT("perf-dir", "perf-dir"),
+ OPT_ARGUMENT("work-tree", "work-tree"),
+ OPT_ARGUMENT("debugfs-dir", "debugfs-dir"),
+ OPT_ARGUMENT("buildid-dir", "buildid-dir"),
+ OPT_ARGUMENT("list-cmds", "list-cmds"),
+ OPT_ARGUMENT("list-opts", "list-opts"),
+ OPT_ARGUMENT("debug", "debug"),
+ OPT_END()
+};
+
static int handle_options(const char ***argv, int *argc, int *envchanged)
{
int handled = 0;
@@ -225,6 +243,15 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
}
putchar('\n');
exit(0);
+ } else if (!strcmp(cmd, "--list-opts")) {
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(options)-1; i++) {
+ struct option *p = options+i;
+ printf("--%s ", p->long_name);
+ }
+ putchar('\n');
+ exit(0);
} else if (!strcmp(cmd, "--debug")) {
if (*argc < 2) {
fprintf(stderr, "No variable specified for
--debug.\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
[tip:perf/core] perf report: Fix branch stack mode cannot be set
Commit-ID: fefd2d9619de3bf0bf02a8622e9f445c3d19cc3f
Gitweb: http://git.kernel.org/tip/fefd2d9619de3bf0bf02a8622e9f445c3d19cc3f
Author: He Kuang
AuthorDate: Sun, 15 Feb 2015 10:33:37 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:42 -0300
perf report: Fix branch stack mode cannot be set
When perf.data file is obtained using 'perf record -b', perf report
should use branch stack mode to generate output. But this function is
broken by improper comparison between boolean and constant -1.
before this patch:
$ perf report -b -i perf.data
Samples: 16 of event 'cycles', Event count (approx.): 3171896
Overhead Command Shared Object Symbol
13.59% ls [kernel.kallsyms] [k] prio_tree_remove
13.16% ls [kernel.kallsyms] [k] change_pte_range
12.09% ls [kernel.kallsyms] [k] page_fault
12.02% ls [kernel.kallsyms] [k] zap_pte_range
...
after this patch:
$ perf report -b -i perf.data
Samples: 256 of event 'cycles', Event count (approx.): 256
Overhead Command Source Shared Object Source Symbol
Target Shared Object Target Symbol
9.38% ls [unknown] [k]
[unknown] [k]
6.25% ls libc-2.19.so [.] _dl_addr
libc-2.19.so [.] _dl_addr
6.25% ls [kernel.kallsyms] [k] zap_pte_range
[kernel.kallsyms] [k] zap_pte_range
6.25% ls [kernel.kallsyms] [k] change_pte_range
[kernel.kallsyms] [k] change_pte_range
0.39% ls [kernel.kallsyms] [k] prio_tree_remove
[kernel.kallsyms] [k] prio_tree_remove
...
Signed-off-by: He Kuang
Tested-by: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1423967617-28879-1-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 0ba5f07..fb35034 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -768,7 +768,7 @@ repeat:
* 0/1 means the user chose a mode.
*/
if (((branch_mode == -1 && has_br_stack) || branch_mode == 1) &&
- branch_call_mode == -1) {
+ !branch_call_mode) {
sort__mode = SORT_MODE__BRANCH;
symbol_conf.cumulate_callchain = false;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ACPI regression with 3.19+
Hallo, my system won't boot with current GIT kernel (see attached screenshot). The system seems somewhat frozen (cannot ssh into it), but magic sysrq still works. I bisected the problem to commit 593669c2ac0fe18baee04a3cd5539a148aa48574. Attached are my config and dmesg output from previous commit, which still booted. I don't know if related, but the message "pnp 00:00: can't evaluate _CRS: 1" is also new to me. I saw it with commit 8515f9368161730655b64ddaf8b11a3d20049610, but not with c793504de3de484076e1eb96d5187af55f47945c. Didn't test commits in between. I am not subscribed, so please CC if you need more info. Thanks. Regards, Prakash PS: Sorry for posting twice, mistyped ACPI mailing list address. config_812dbd9994f122629db73205a7f7f46b430a6360.xz Description: application/xz kernel_812dbd9994f122629db73205a7f7f46b430a6360.txt.xz Description: application/xz
[tip:perf/core] perf buildid-cache: Show usage with incorrect params
Commit-ID: 0497d0a8201a38f0c95edc8a1fc0325f2f879ddb
Gitweb: http://git.kernel.org/tip/0497d0a8201a38f0c95edc8a1fc0325f2f879ddb
Author: Masami Hiramatsu
AuthorDate: Fri, 27 Feb 2015 13:50:31 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:40 -0300
perf buildid-cache: Show usage with incorrect params
Show usage if no action is specified or unexpected parameter is given.
In other words, be more user friendly.
Signed-off-by: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Hemant Kumar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150227045030.1999.44006.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-buildid-cache.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index 04466c4..d47a0cd 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -343,6 +343,11 @@ int cmd_buildid_cache(int argc, const char **argv,
argc = parse_options(argc, argv, buildid_cache_options,
buildid_cache_usage, 0);
+ if (argc || (!add_name_list_str && !kcore_filename &&
+!remove_name_list_str && !purge_name_list_str &&
+!missing_filename && !update_name_list_str))
+ usage_with_options(buildid_cache_usage, buildid_cache_options);
+
if (missing_filename) {
file.path = missing_filename;
file.force = force;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf buildid-cache: Use pr_debug instead of verbose && pr_info
Commit-ID: cc169c7c31253e80e0d504f0cd5dbb9f1e3d3ac5
Gitweb: http://git.kernel.org/tip/cc169c7c31253e80e0d504f0cd5dbb9f1e3d3ac5
Author: Masami Hiramatsu
AuthorDate: Fri, 27 Feb 2015 13:50:28 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 15:52:36 -0300
perf buildid-cache: Use pr_debug instead of verbose && pr_info
Use pr_debug instead of the combination of verbose and pr_info.
"if (verbose) pr_info(...)" is same as "pr_debug(...)", replace it.
Signed-off-by: Masami Hiramatsu
Suggested-by: Namhyung Kim
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Hemant Kumar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150227045028.1999.93137.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-buildid-cache.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index 86f9d78..04466c4 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -196,9 +196,8 @@ static int build_id_cache__add_file(const char *filename)
build_id__sprintf(build_id, sizeof(build_id), sbuild_id);
err = build_id_cache__add_s(sbuild_id, filename,
false, false);
- if (verbose)
- pr_info("Adding %s %s: %s\n", sbuild_id, filename,
- err ? "FAIL" : "Ok");
+ pr_debug("Adding %s %s: %s\n", sbuild_id, filename,
+err ? "FAIL" : "Ok");
return err;
}
@@ -216,9 +215,8 @@ static int build_id_cache__remove_file(const char *filename)
build_id__sprintf(build_id, sizeof(build_id), sbuild_id);
err = build_id_cache__remove_s(sbuild_id);
- if (verbose)
- pr_info("Removing %s %s: %s\n", sbuild_id, filename,
- err ? "FAIL" : "Ok");
+ pr_debug("Removing %s %s: %s\n", sbuild_id, filename,
+err ? "FAIL" : "Ok");
return err;
}
@@ -235,17 +233,15 @@ static int build_id_cache__purge_path(const char
*pathname)
strlist__for_each(pos, list) {
err = build_id_cache__remove_s(pos->s);
- if (verbose)
- pr_info("Removing %s %s: %s\n", pos->s, pathname,
- err ? "FAIL" : "Ok");
+ pr_debug("Removing %s %s: %s\n", pos->s, pathname,
+err ? "FAIL" : "Ok");
if (err)
break;
}
strlist__delete(list);
out:
- if (verbose)
- pr_info("Purging %s: %s\n", pathname, err ? "FAIL" : "Ok");
+ pr_debug("Purging %s: %s\n", pathname, err ? "FAIL" : "Ok");
return err;
}
@@ -296,9 +292,8 @@ static int build_id_cache__update_file(const char *filename)
if (!err)
err = build_id_cache__add_s(sbuild_id, filename, false, false);
- if (verbose)
- pr_info("Updating %s %s: %s\n", sbuild_id, filename,
- err ? "FAIL" : "Ok");
+ pr_debug("Updating %s %s: %s\n", sbuild_id, filename,
+err ? "FAIL" : "Ok");
return err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf diff: Support for different binaries
Commit-ID: 94ba462d69efeba2f97111321a9ba1aa8141da57
Gitweb: http://git.kernel.org/tip/94ba462d69efeba2f97111321a9ba1aa8141da57
Author: Kan Liang
AuthorDate: Mon, 9 Feb 2015 05:39:44 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 27 Feb 2015 10:08:38 -0300
perf diff: Support for different binaries
Currently, the perf diff only works with same binaries. That's because
it compares the symbol start address. It doesn't work if the perf.data
comes from different binaries. This patch matches the symbol names.
Actually, perf diff once intended to compare the symbol names. The
commit as below can look for a pair by name.
604c5c92972d (perf diff: Change the default sort order to "dso,symbol")
However, at that time, perf diff used a global list of dsos. That means
the binaries which has same name can only be loaded once. That's a
problem for comparing different binaries.
For example, we have an old binary and an updated binary. They very
likely have same name and most of the functions, so only dsos from old
binary will be loaded. When processing the data from updated binary,
perf still use the symbol information from old binary. That's wrong.
Then the commit as below used IP to replace symbol name.
9c443dfdd31e ("perf diff: Fix support for all --sort combinations")
>From that time, perf diff starts to compare the symbol address.
The global dsos is discarded from a patch in 2010.
a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance
from host")
However, at that time, perf diff already compared by address. So perf
diff cannot work for different binaries as well.
This patch actually rolls back the perf diff to original design. The
document is also changed, so everybody knows the original design is to
compare the symbol names.
Here are some examples:
The only difference between example_v1.c and example_v2.c is the
location of f2 and f3. There is no change in behavior, but the previous
perf diff display the wrong differential profile.
example_v1.c
noinline void f3(void)
{
volatile int i;
for (i = 0; i < 1;) {
if(i%2)
i++;
else
i++;
}
}
noinline void f2(void)
{
volatile int a = 100, b, c;
for (b = 0; b < 1; b++)
c = a * b;
}
noinline void f1(void)
{
f2();
f3();
}
int main()
{
int i;
for (i = 0; i < 10; i++)
f1();
}
example_v2.c
noinline void f2(void)
{
volatile int a = 100, b, c;
for (b = 0; b < 1; b++)
c = a * b;
}
noinline void f3(void)
{
volatile int i;
for (i = 0; i < 1;) {
if(i%2)
i++;
else
i++;
}
}
noinline void f1(void)
{
f2();
f3();
}
int main()
{
int i;
for (i = 0; i < 10; i++)
f1();
}
[lk@localhost perf_diff]$ gcc example_v1.c -o example
[lk@localhost perf_diff]$ perf record -o example_v1.data ./example
[ perf record: Woken up 4 times to write data ]
[ perf record: Captured and wrote 0.813 MB example_v1.data (~35522 samples) ]
[lk@localhost perf_diff]$ gcc example_v2.c -o example
[lk@localhost perf_diff]$ perf record -o example_v2.data ./example
[ perf record: Woken up 4 times to write data ]
[ perf record: Captured and wrote 0.824 MB example_v2.data (~36015 samples) ]
Old perf diff result:
[lk@localhost perf_diff]$ perf diff example_v1.data example_v2.data
Event 'cycles'
BaselineDelta Shared Object Symbol
... ...
[kernel.vmlinux] [k] __perf_event_task_sched_out
0.00% [kernel.vmlinux] [k] apic_timer_interrupt
[kernel.vmlinux] [k] idle_cpu
[kernel.vmlinux] [k] intel_pstate_timer_func
[kernel.vmlinux] [k] native_read_msr_safe
0.00% [kernel.vmlinux] [k] native_read_tsc
0.00% [kernel.vmlinux] [k] native_write_msr_safe
[kernel.vmlinux] [k] ntp_tick_length
0.00% [kernel.vmlinux] [k] rb_erase
0.00% [kernel.vmlinux] [k] tick_sched_timer
0.00% [kernel.vmlinux] [k] unmap_single_vma
0.00% [kernel.vmlinux] [k] update_wall_time
0.00% example [.] f1
46.24% example [.] f2
53.71% -7.55% example [.] f3
+53.81% example [.] f3
0.02% example [.] main
New perf diff result:
[lk@localhost perf_diff]$ perf diff example_v1.data example_v2.data
[kernel.vmlinux] [k] __perf_event_task_sched_out
0.00% [kernel.vmlinux] [k] apic_timer_interrupt
[kernel.vmlinux] [k] idle_cpu
[kerne
[tip:perf/core] perf probe: Fix get_real_path to free allocated memory in error path
Commit-ID: eb47cb2eb22dfacac9689708f5bd3cb0e975e290
Gitweb: http://git.kernel.org/tip/eb47cb2eb22dfacac9689708f5bd3cb0e975e290
Author: Masami Hiramatsu
AuthorDate: Thu, 26 Feb 2015 17:25:04 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Feb 2015 11:59:05 -0300
perf probe: Fix get_real_path to free allocated memory in error path
Fix get_real_path to free allocated memory when comp_dir is used for
complementing path and getting an error.
Signed-off-by: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Naohiro Aota
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20150226082504.28125.74506.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 662d454..4a93bf4 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -549,9 +549,11 @@ static int get_real_path(const char *raw_path, const char
*comp_dir,
if (access(*new_path, R_OK) == 0)
return 0;
- if (!symbol_conf.source_prefix)
+ if (!symbol_conf.source_prefix) {
/* In case of searching comp_dir, don't retry */
+ zfree(new_path);
return -errno;
+ }
switch (errno) {
case ENAMETOOLONG:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: mmp-tdma: refine dma disable and dma-pos update
On 02/23/2015 07:23 PM, Vinod Koul wrote:
On Thu, Feb 05, 2015 at 08:54:19PM +0800, Qiao Zhou wrote:
Below are the refinements.
1. Set DMA abort bit when disabling dma channel. This will clear
the remaining data in dma FIFO, to fix channel-swap issue.
2. Read DMA HW pointer when updating DMA status. Previously dma
position is calculated by adding one period size in dma interrupt.
This is inaccurate/insufficient for some high-quality audio APP.
Since interrupt bottom half handler has variable schedule delay,
it causes big error when calculating sample delay. Read the actual
HW pointer and feedback can improve the accuracy.
3. Do some minor code clean.
This fails to apply for me, care to rebase pls
Rebased. Thanks.
From b9cd9aca9c7700423276ba7fb49f267e00e63792 Mon Sep 17 00:00:00 2001
From: Qiao Zhou
Date: Sat, 28 Feb 2015 17:05:21 +0800
Subject: [PATCH v2] dma: mmp-tdma: refine dma disable and dma-pos update
Below are the refinements.
1. Set DMA abort bit when disabling dma channel. This will clear
the remaining data in dma FIFO, to fix channel-swap issue.
2. Read DMA HW pointer when updating DMA status. Previously dma
position is calculated by adding one period size in dma interrupt.
This is inaccurate/insufficient for some high-quality audio APP.
Since interrupt bottom half handler has variable schedule delay,
it causes big error when calculating sample delay. Read the actual
HW pointer and feedback can improve the accuracy.
3. Do some minor code clean.
Signed-off-by: Qiao Zhou
---
drivers/dma/mmp_tdma.c | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c
index 70c2fa9..b6f4e1f 100644
--- a/drivers/dma/mmp_tdma.c
+++ b/drivers/dma/mmp_tdma.c
@@ -110,7 +110,7 @@ struct mmp_tdma_chan {
struct tasklet_struct tasklet;
struct mmp_tdma_desc*desc_arr;
- phys_addr_t desc_arr_phys;
+ dma_addr_t desc_arr_phys;
int desc_num;
enum dma_transfer_direction dir;
dma_addr_t dev_addr;
@@ -166,9 +166,12 @@ static void mmp_tdma_enable_chan(struct
mmp_tdma_chan *tdmac)
static int mmp_tdma_disable_chan(struct dma_chan *chan)
{
struct mmp_tdma_chan *tdmac = to_mmp_tdma_chan(chan);
+ u32 tdcr;
- writel(readl(tdmac->reg_base + TDCR) & ~TDCR_CHANEN,
- tdmac->reg_base + TDCR);
+ tdcr = readl(tdmac->reg_base + TDCR);
+ tdcr |= TDCR_ABR;
+ tdcr &= ~TDCR_CHANEN;
+ writel(tdcr, tdmac->reg_base + TDCR);
tdmac->status = DMA_COMPLETE;
@@ -296,12 +299,27 @@ static int mmp_tdma_clear_chan_irq(struct
mmp_tdma_chan *tdmac)
return -EAGAIN;
}
+static size_t mmp_tdma_get_pos(struct mmp_tdma_chan *tdmac)
+{
+ size_t reg;
+
+ if (tdmac->idx == 0) {
+ reg = __raw_readl(tdmac->reg_base + TDSAR);
+ reg -= tdmac->desc_arr[0].src_addr;
+ } else if (tdmac->idx == 1) {
+ reg = __raw_readl(tdmac->reg_base + TDDAR);
+ reg -= tdmac->desc_arr[0].dst_addr;
+ } else
+ return -EINVAL;
+
+ return reg;
+}
+
static irqreturn_t mmp_tdma_chan_handler(int irq, void *dev_id)
{
struct mmp_tdma_chan *tdmac = dev_id;
if (mmp_tdma_clear_chan_irq(tdmac) == 0) {
- tdmac->pos = (tdmac->pos + tdmac->period_len) % tdmac->buf_len;
tasklet_schedule(&tdmac->tasklet);
return IRQ_HANDLED;
} else
@@ -343,7 +361,7 @@ static void mmp_tdma_free_descriptor(struct
mmp_tdma_chan *tdmac)
int size = tdmac->desc_num * sizeof(struct mmp_tdma_desc);
gpool = tdmac->pool;
- if (tdmac->desc_arr)
+ if (gpool && tdmac->desc_arr)
gen_pool_free(gpool, (unsigned long)tdmac->desc_arr,
size);
tdmac->desc_arr = NULL;
@@ -499,6 +517,7 @@ static enum dma_status mmp_tdma_tx_status(struct
dma_chan *chan,
{
struct mmp_tdma_chan *tdmac = to_mmp_tdma_chan(chan);
+ tdmac->pos = mmp_tdma_get_pos(tdmac);
dma_set_tx_state(txstate, chan->completed_cookie, chan->cookie,
tdmac->buf_len - tdmac->pos);
@@ -610,7 +629,7 @@ static int mmp_tdma_probe(struct platform_device *pdev)
int i, ret;
int irq = 0, irq_num = 0;
int chan_num = TDMA_CHANNEL_NUM;
- struct gen_pool *pool;
+ struct gen_pool *pool = NULL;
of_id = of_match_device(mmp_tdma_dt_ids, &pdev->dev);
if (of_id)
--
1.7.0.4
--
Best Regards
Qiao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board
Robert Jarzmik writes: > Hi Arnd and Greg, It's been a week, backlog ping ? > > I have this driver I'm upstreaming, which comes out of > arch/arm/mach-pxa/lubbock.c. As for the reason it is extracted, see submitted > commit [1] for reference. > > The main question is : where does it belong in the kernel ? > > The driver is : > - for the CPLDs on the Lubbock development platform, which is more or less an >old motherboard for Intel Xscale pxa255 SoC (see [2] for more details) > - these CPLDs control : >- interrupt muxing towards the SoC >- several leds >- switches read back >For the whole patch, see [4] > > Lee's position is that it doesn't belong to drivers/mfd, see [3]. > > So where should I submit it ? And more generally, where should CPLDs drivers > be > pushed in the kernel tree ? > > If there is no solution, I'll fallback through arch/arm/plat-pxa, not very > nice, > but it has to land somewhere, I don't want lubbock to remain broken. > > Cheers. > > -- > Robert > > [1] Reason of extraction / commit message > mfd: lubbock_cplds: add lubbock IO board > > Lubbock () board is the IO motherboard of the Intel PXA25x Development > Platform, which supports the Lubbock pxa25x soc board. > > Historically, this support was in arch/arm/mach-pxa/lubbock.c. When > gpio-pxa was moved to drivers/pxa, it became a driver, and its > initialization and probing happened at postcore initcall. The lubbock > code used to install the chained lubbock interrupt handler at init_irq() > time. > > The consequence of the gpio-pxa change is that the installed chained irq > handler lubbock_irq_handler() was overwritten in pxa_gpio_probe(_dt)(), > removing : > - the handler > - the falling edge detection setting of GPIO0, which revealed the >interrupt request from the lubbock IO board. > > As a fix, move the gpio0 chained handler setup to a place where we have > the guarantee that pxa_gpio_probe() was called before, so that lubbock > handler becomes the true IRQ chained handler of GPIO0, demuxing the > lubbock IO board interrupts. > > This patch moves all that handling to a mfd driver. It's only purpose > for the time being is the interrupt handling, but in the future it > should encompass all the motherboard CPLDs handling : > - leds > - switches > - hexleds > > Signed-off-by: Robert Jarzmik > > [2] Board description by Nicolas >>> The Lubbock is an ancient development board (circa 2003) using a CPLD to >>> multiplex a couple things on the board. I really doubt anyone would >>> reprogram this CPLD at this point. So I'd treat it just like another >>> interrupt controller + random peripherals that will never change. And >>> yes, maybe a more appropriate name is needed. > > [3] Lee's position >>> > I don't think this is correct either. CPLD handling would probably be >>> > slightly less out of place in drivers/misc, but perhaps a new >>> > subsystem for PLDs/CPLDs/FPGAs would be more appropriate >>> > drivers/programmables or similar maybe. >>> > > ... >>> > I'm pretty convinced that it doesn't belong in MFD now, but it doesn't >>> > mean I'm going to leave you on the curb. I'd like to help you get it >>> > into a better home. >>> > >>> > [...] >>> > > Is not only a irqchip because, as explained at the bottom of the commit >>> > > message, >>> > > quoting myself : >>> > > This patch moves all that handling to a mfd driver. It's only purpose >>> > > for the time being is the interrupt handling, but in the future it >>> > > should encompass all the motherboard CPLDs handling : >>> > >- leds >>> > >- switches >>> > >- hexleds >>> > >>> > I had a conversation about this on IRC yesterday and some good >>> > points/questions were posed. This is a difficult area, because you >>> > can program these things to do whatever you like. Depending on the >>> > 'intention' (and it is only an intention -- someone else can come >>> > along and reprogram these devices on a whim), the CPLD code could live >>> > anywhere. If you wanted to put watchdog functionality in there, then >>> > there is an argument for it to live in drivers/watchdog, etc etc. So >>> > just because the plan is to support a few (i.e. more than one) simple >>> > devices, it doesn't necessarily mean that the handling should be done >>> > in MFD. >>> > >>> > Yesterday I was asked "Are you wanting to restrict drivers in >>> > drivers/mfd to those that make use of MFD_CORE functionality?". My >>> > answer to that was "No, however; I only want devices which >>> > _intrinsically_ operate in multiple subsystems", which these >>> > programmables no not do. >>> > >>> > FYI, you're not on your own here. There is at least one of these >>> > devices in the kernel already and upon a short inspection there >>> > appears to be a number of Out-of-Tree (OoT) drivers out there which >>> > will require a
Re: [PATCH_V3 1/3] dt-bindings: dma: Add binding for jz4780-dma
On 27 February 2015 at 09:20, Zubair Lutfullah Kakakhel wrote: > Hi Alex, > > On 26/02/15 20:04, Alex Smith wrote: >> Hi Zubair, >> >> On 26 February 2015 at 12:43, Zubair Lutfullah Kakakhel >> wrote: >>> From: Alex Smith >>> >>> Add device tree bindings for the DMA controller on JZ4780 SoCs, used by >>> the dma-jz4780 driver. >>> >>> Signed-off-by: Alex Smith >>> Signed-off-by: Zubair Lutfullah Kakakhel >>> >>> --- >>> V3 -> V2 >>> Changed binding. >>> Used to be 3 DMA cells required. <&dma TX_type RX_type Reserved> >>> Now 2 DMA cells are required. <&dma Transfer_type Reserved> >>> >>> This is more common in DMA bindings. >>> And I couldn't figure any reason that 3 cells were used. >> >> There are different request type numbers for transfers to/from the >> same device (see the JZ4780 programmers manual, page 505). While only >> having the option to specify one transfer type is OK when the driver >> is using separate channels for read/writes, I recall seeing/writing >> some other drivers which use a single channel for both reads and >> writes. This would not be possible if we can only specify one transfer >> type, you'd have to have them separate. >> > > I know. I looked at the drivers and did this on purpose. > > We'd like to keep the same bindings/code for jz4740/jz4780 peripheral drivers > and dma code. > > Our jz47xx-mmc driver we had was the main culprit I found. As well as the > jz4740-i2s one. > > However, jz4740-mmc upstream driver has improved already for dma and takes > two dma channels. > And the jz4740-i2s also takes two channels. One for Tx and one for Rx. > > If we move to 3 cells for jz4780-dma. Then 'ideally' jz4740-dma would need 3 > cells too. > Or we'd have a binding nightmare everywhere. > > But when we use jz4740-mmc and jz4740-i2s, we still have to change the driver > to share one channel > or simply pass them > <&dma Tx 0 Reserved> > <&dma 0 Rx Reserved> > > Which makes the binding redundant. > > There isn't any particular reason a driver would need to share one channel > only. > The 'special' nand/nemc channels don't have a request type. Ok, fair enough. I was just thinking that the bindings shouldn't be restrictive on the way that you can set things up, but if that's the way that things are already being done for jz4740 then as you say it's better to follow that. Thanks, Alex > > Thanks, > ZubairLK > >> Thanks, >> Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm: Unexport set_memory_ro() and set_memory_rw()
Commit-ID: 6bbb614ec478961c7443086bdf7fd6784479c14a
Gitweb: http://git.kernel.org/tip/6bbb614ec478961c7443086bdf7fd6784479c14a
Author: Daniel Borkmann
AuthorDate: Fri, 27 Feb 2015 15:55:40 +0100
Committer: Ingo Molnar
CommitDate: Sat, 28 Feb 2015 10:41:59 +0100
x86/mm: Unexport set_memory_ro() and set_memory_rw()
This effectively unexports set_memory_ro() and set_memory_rw()
functions, and thus reverts:
a03352d2c1dc ("x86: export set_memory_ro and set_memory_rw").
They have been introduced for debugging purposes in e1000e, but
no module user is in mainline kernel (anymore?) and we
explicitly do not want modules to use these functions, as they
i.e. protect eBPF (interpreted & JIT'ed) images from malicious
modifications or bugs.
Outside of eBPF scope, I believe also other set_memory_*()
functions should be unexported on x86 for modules.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
Cc: Arjan van de Ven
Cc: Borislav Petkov
Cc: Bruce Allan
Cc: H. Peter Anvin
Cc: Jesse Brandeburg
Cc: Thomas Gleixner
Cc: da...@davemloft.net
Link:
http://lkml.kernel.org/r/a064393a0a5d319eebde5c761cfd743132d4f213.1425040940.git.dan...@iogearbox.net
Signed-off-by: Ingo Molnar
---
arch/x86/mm/pageattr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 536ea2f..81e8282 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1654,13 +1654,11 @@ int set_memory_ro(unsigned long addr, int numpages)
{
return change_page_attr_clear(&addr, numpages, __pgprot(_PAGE_RW), 0);
}
-EXPORT_SYMBOL_GPL(set_memory_ro);
int set_memory_rw(unsigned long addr, int numpages)
{
return change_page_attr_set(&addr, numpages, __pgprot(_PAGE_RW), 0);
}
-EXPORT_SYMBOL_GPL(set_memory_rw);
int set_memory_np(unsigned long addr, int numpages)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:locking/urgent] locking/rtmutex: Set state back to running on error
Commit-ID: 8671e69f00c2733c995d188b9f8d6f9cbb67897c
Gitweb: http://git.kernel.org/tip/8671e69f00c2733c995d188b9f8d6f9cbb67897c
Author: Sebastian Andrzej Siewior
AuthorDate: Fri, 27 Feb 2015 17:57:09 +0100
Committer: Ingo Molnar
CommitDate: Sat, 28 Feb 2015 10:47:37 +0100
locking/rtmutex: Set state back to running on error
The "usual" path is:
- rt_mutex_slowlock()
- set_current_state()
- task_blocks_on_rt_mutex() (ret 0)
- __rt_mutex_slowlock()
- sleep or not but do return with __set_current_state(TASK_RUNNING)
- back to caller.
In the early error case where task_blocks_on_rt_mutex() return
-EDEADLK we never change the task's state back to RUNNING. I
assume this is intended. Without this change after ww_mutex
using rt_mutex the selftest passes but later I get plenty of:
| bad: scheduling from the idle thread!
backtraces.
Signed-off-by: Sebastian Andrzej Siewior
Cc: Linus Torvalds
Cc: Maarten Lankhorst
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1425056229-22326-4-git-send-email-bige...@linutronix.de
Signed-off-by: Ingo Molnar
---
kernel/locking/rtmutex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index e16e554..5845068 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1193,6 +1193,7 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
ret = __rt_mutex_slowlock(lock, state, timeout, &waiter);
if (unlikely(ret)) {
+ set_current_state(TASK_RUNNING);
if (rt_mutex_has_waiters(lock))
remove_waiter(lock, &waiter);
rt_mutex_handle_deadlock(ret, chwalk, &waiter);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] mtd: various fixes caught by Coverity
Several unrelated MTD fixes inspired by Coverity Scan results. I couldn't test
all of them, but they're all pretty obvious.
Brian Norris (7):
mtd: docg3: drop dead code
mtd: onenand: drop dead code
mtd: tests: fix more potential integer overflows
mtd: nand: fixup bounds checks for nand_{lock,unlock}()
mtd: nand: denali: drop dead code
mtd: blkdevs: remove dead code
mtd: nand: fully initialize mtd_oob_ops
drivers/mtd/devices/docg3.c| 2 --
drivers/mtd/mtd_blkdevs.c | 3 ---
drivers/mtd/nand/denali.c | 3 ---
drivers/mtd/nand/nand_base.c | 12 ++--
drivers/mtd/onenand/onenand_base.c | 12 +++-
drivers/mtd/tests/oobtest.c| 2 +-
drivers/mtd/tests/speedtest.c | 2 +-
drivers/mtd/tests/stresstest.c | 4 ++--
drivers/mtd/tests/subpagetest.c| 4 ++--
drivers/mtd/tests/torturetest.c| 8
10 files changed, 19 insertions(+), 33 deletions(-)
--
2.1.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 2/7] mtd: onenand: drop dead code
'ret' is always zero, so this is all dead code.
This should quiet Coverity CID #1226739.
Signed-off-by: Brian Norris
Cc: Kyungmin Park
---
drivers/mtd/onenand/onenand_base.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 635ee0027691..43b3392ffee7 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1743,7 +1743,6 @@ static int onenand_panic_write(struct mtd_info *mtd,
loff_t to, size_t len,
struct onenand_chip *this = mtd->priv;
int column, subpage;
int written = 0;
- int ret = 0;
if (this->state == FL_PM_SUSPENDED)
return -EBUSY;
@@ -1786,15 +1785,10 @@ static int onenand_panic_write(struct mtd_info *mtd,
loff_t to, size_t len,
onenand_panic_wait(mtd);
/* In partial page write we don't update bufferram */
- onenand_update_bufferram(mtd, to, !ret && !subpage);
+ onenand_update_bufferram(mtd, to, !subpage);
if (ONENAND_IS_2PLANE(this)) {
ONENAND_SET_BUFFERRAM1(this);
- onenand_update_bufferram(mtd, to + this->writesize,
!ret && !subpage);
- }
-
- if (ret) {
- printk(KERN_ERR "%s: write failed %d\n", __func__, ret);
- break;
+ onenand_update_bufferram(mtd, to + this->writesize,
!subpage);
}
written += thislen;
@@ -1808,7 +1802,7 @@ static int onenand_panic_write(struct mtd_info *mtd,
loff_t to, size_t len,
}
*retlen = written;
- return ret;
+ return 0;
}
/**
--
2.1.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 6/7] mtd: blkdevs: remove dead code
The only exit (break) from the preceding loop is nested within a condition which yields req == NULL. This code is dead. Coverity CID #752669 Signed-off-by: Brian Norris --- drivers/mtd/mtd_blkdevs.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index d08229eb44d8..2b0c52870999 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -171,9 +171,6 @@ static void mtd_blktrans_work(struct work_struct *work) background_done = 0; } - if (req) - __blk_end_request_all(req, -EIO); - spin_unlock_irq(rq->queue_lock); } -- 2.1.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 5/7] mtd: nand: denali: drop dead code
TclsRising is always 1.
Caught by Coverity.
Signed-off-by: Brian Norris
Cc: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index f44c6061536a..09f51395f2c0 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -225,7 +225,6 @@ static void nand_onfi_timing_set(struct denali_nand_info
*denali,
uint16_t Twhr[6] = {120, 80, 80, 60, 60, 60};
uint16_t Tcs[6] = {70, 35, 25, 25, 20, 15};
- uint16_t TclsRising = 1;
uint16_t data_invalid_rhoh, data_invalid_rloh, data_invalid;
uint16_t dv_window = 0;
uint16_t en_lo, en_hi;
@@ -276,8 +275,6 @@ static void nand_onfi_timing_set(struct denali_nand_info
*denali,
re_2_re = CEIL_DIV(Trhz[mode], CLK_X);
we_2_re = CEIL_DIV(Twhr[mode], CLK_X);
cs_cnt = CEIL_DIV((Tcs[mode] - Trp[mode]), CLK_X);
- if (!TclsRising)
- cs_cnt = CEIL_DIV(Tcs[mode], CLK_X);
if (cs_cnt == 0)
cs_cnt = 1;
--
2.1.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 7/7] mtd: nand: fully initialize mtd_oob_ops
We're not initializing the ooblen field. Our users don't care, since
they check that oobbuf == NULL first, but it's good practice to zero
unused fields out.
We can drop the NULL initializations since we're memset()ing the whole
thing.
Noticed by Coverity, CID #200821, #200822
Signed-off-by: Brian Norris
---
drivers/mtd/nand/nand_base.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5488a7ad63e7..d4cec2f8a016 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -386,7 +386,7 @@ static int nand_default_block_markbad(struct mtd_info *mtd,
loff_t ofs)
uint8_t buf[2] = { 0, 0 };
int ret = 0, res, i = 0;
- ops.datbuf = NULL;
+ memset(&ops, 0, sizeof(ops));
ops.oobbuf = buf;
ops.ooboffs = chip->badblockpos;
if (chip->options & NAND_BUSWIDTH_16) {
@@ -1716,9 +1716,9 @@ static int nand_read(struct mtd_info *mtd, loff_t from,
size_t len,
int ret;
nand_get_device(mtd, FL_READING);
+ memset(&ops, 0, sizeof(ops));
ops.len = len;
ops.datbuf = buf;
- ops.oobbuf = NULL;
ops.mode = MTD_OPS_PLACE_OOB;
ret = nand_do_read_ops(mtd, from, &ops);
*retlen = ops.retlen;
@@ -2508,9 +2508,9 @@ static int panic_nand_write(struct mtd_info *mtd, loff_t
to, size_t len,
/* Grab the device */
panic_nand_get_device(chip, mtd, FL_WRITING);
+ memset(&ops, 0, sizeof(ops));
ops.len = len;
ops.datbuf = (uint8_t *)buf;
- ops.oobbuf = NULL;
ops.mode = MTD_OPS_PLACE_OOB;
ret = nand_do_write_ops(mtd, to, &ops);
@@ -2536,9 +2536,9 @@ static int nand_write(struct mtd_info *mtd, loff_t to,
size_t len,
int ret;
nand_get_device(mtd, FL_WRITING);
+ memset(&ops, 0, sizeof(ops));
ops.len = len;
ops.datbuf = (uint8_t *)buf;
- ops.oobbuf = NULL;
ops.mode = MTD_OPS_PLACE_OOB;
ret = nand_do_write_ops(mtd, to, &ops);
*retlen = ops.retlen;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On Sat, 28 Feb 2015, Jiang Liu wrote: On 2015/2/28 6:24, Rafael J. Wysocki wrote: On Friday, February 27, 2015 03:50:32 PM Thomas Voegtle wrote: Hi, I have the same problem with a Asrock Q1900B-ITX mainboard with a Intel Celeron J1900 onboard. I did a bisect and ended up with: 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit commit 593669c2ac0fe18baee04a3cd5539a148aa48574 Author: Jiang Liu Date: Thu Feb 5 13:44:46 2015 +0800 x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation I can revert this quite big commit on current git head (4f671fe) with no problems and then everything is fine again. Thanks for nailing this one! It really wasn't supposed to make any functional difference, though, so there must be some subtle mistake that escaped everyone in it. I'll have a look at that and hopefully Jiang Liu will be able to help in the meantime too. Hi all, Sorry for slow response, just return from Chinese New Holidays:) Hi Thomas, Could you please help to provide the dmesgs before and after the revert? Attached. Thanks, Thomas[0.00] Linux version 4.0.0-rc1-celeron-00037-gec3360c (thomas@maggie) (gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) ) #218 SMP Sat Feb 28 10:54:22 CET 2015 [0.00] Command line: root=/dev/sda3 console=ttyS0,115200N8 panic=30 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable [0.00] BIOS-e820: [mem 0x0009c800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x200f] reserved [0.00] BIOS-e820: [mem 0x2010-0x79578fff] usable [0.00] BIOS-e820: [mem 0x79579000-0x795a8fff] reserved [0.00] BIOS-e820: [mem 0x795a9000-0x795fcfff] usable [0.00] BIOS-e820: [mem 0x795fd000-0x7970dfff] ACPI NVS [0.00] BIOS-e820: [mem 0x7970e000-0x79a7afff] reserved [0.00] BIOS-e820: [mem 0x79a7b000-0x79a7bfff] usable [0.00] BIOS-e820: [mem 0x79a7c000-0x79abdfff] reserved [0.00] BIOS-e820: [mem 0x79abe000-0x79c2bfff] usable [0.00] BIOS-e820: [mem 0x79c2c000-0x79ff9fff] reserved [0.00] BIOS-e820: [mem 0x79ffa000-0x79ff] usable [0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xffb0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.8 present. [0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Q1900B-ITX, BIOS P1.70 11/04/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-E7FFF write-through [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 07A80 mask FFF80 uncachable [0.00] 2 base 07B00 mask FFF00 uncachable [0.00] 3 base 07C00 mask FFC00 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88096000] 96000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01a0f000, 0x01a0] PGTABLE [0.00] BRK [0x01a1, 0x01a10fff] PGTABLE [0.00] BRK [0x01a11000, 0x01a11fff] PGTABLE [0.00] init_memory_mapping: [mem 0x7920-0x793f] [0.00] [mem 0x7920-0x793f] page 2M [0.00] BRK [0x01a12000, 0x01a12fff] PGTABLE [0.00] init_memory_mapping: [mem 0x6000-0x791f] [0.00] [mem 0x6000-0x791f] page 2M [0.00] init_memory_mapping: [mem 0x4000-0x5fff] [0.00] [mem 0x4000-0x5fff] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x1fff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x1fff] page 2M [0.00] init_memory_mapping: [mem 0x2010
[PATCH 3/7] mtd: tests: fix more potential integer overflows
Caught by Coverity (CID #200625 and others)
Signed-off-by: Brian Norris
Cc: Akinobu Mita
---
drivers/mtd/tests/oobtest.c | 2 +-
drivers/mtd/tests/speedtest.c | 2 +-
drivers/mtd/tests/stresstest.c | 4 ++--
drivers/mtd/tests/subpagetest.c | 4 ++--
drivers/mtd/tests/torturetest.c | 8
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/tests/oobtest.c b/drivers/mtd/tests/oobtest.c
index 5e061186eab1..64390ab88a80 100644
--- a/drivers/mtd/tests/oobtest.c
+++ b/drivers/mtd/tests/oobtest.c
@@ -70,7 +70,7 @@ static int write_eraseblock(int ebnum)
int i;
struct mtd_oob_ops ops;
int err = 0;
- loff_t addr = ebnum * mtd->erasesize;
+ loff_t addr = (loff_t)ebnum * mtd->erasesize;
prandom_bytes_state(&rnd_state, writebuf, use_len_max * pgcnt);
for (i = 0; i < pgcnt; ++i, addr += mtd->writesize) {
diff --git a/drivers/mtd/tests/speedtest.c b/drivers/mtd/tests/speedtest.c
index 5ee9f7021020..a77019cb5510 100644
--- a/drivers/mtd/tests/speedtest.c
+++ b/drivers/mtd/tests/speedtest.c
@@ -185,7 +185,7 @@ static long calc_speed(void)
(finish.tv_usec - start.tv_usec) / 1000;
if (ms == 0)
return 0;
- k = goodebcnt * (mtd->erasesize / 1024) * 1000;
+ k = (uint64_t)goodebcnt * (mtd->erasesize / 1024) * 1000;
do_div(k, ms);
return k;
}
diff --git a/drivers/mtd/tests/stresstest.c b/drivers/mtd/tests/stresstest.c
index c9d42cc2df1b..d90c1c01dac6 100644
--- a/drivers/mtd/tests/stresstest.c
+++ b/drivers/mtd/tests/stresstest.c
@@ -96,7 +96,7 @@ static int do_read(void)
if (offs + len > mtd->erasesize)
len = mtd->erasesize - offs;
}
- addr = eb * mtd->erasesize + offs;
+ addr = (loff_t)eb * mtd->erasesize + offs;
return mtdtest_read(mtd, addr, len, readbuf);
}
@@ -124,7 +124,7 @@ static int do_write(void)
offsets[eb + 1] = 0;
}
}
- addr = eb * mtd->erasesize + offs;
+ addr = (loff_t)eb * mtd->erasesize + offs;
err = mtdtest_write(mtd, addr, len, writebuf);
if (unlikely(err))
return err;
diff --git a/drivers/mtd/tests/subpagetest.c b/drivers/mtd/tests/subpagetest.c
index 7b59ef522d5e..0b835c631f91 100644
--- a/drivers/mtd/tests/subpagetest.c
+++ b/drivers/mtd/tests/subpagetest.c
@@ -95,7 +95,7 @@ static int write_eraseblock2(int ebnum)
loff_t addr = (loff_t)ebnum * mtd->erasesize;
for (k = 1; k < 33; ++k) {
- if (addr + (subpgsize * k) > (ebnum + 1) * mtd->erasesize)
+ if (addr + (subpgsize * k) > (loff_t)(ebnum + 1) *
mtd->erasesize)
break;
prandom_bytes_state(&rnd_state, writebuf, subpgsize * k);
err = mtd_write(mtd, addr, subpgsize * k, &written, writebuf);
@@ -195,7 +195,7 @@ static int verify_eraseblock2(int ebnum)
loff_t addr = (loff_t)ebnum * mtd->erasesize;
for (k = 1; k < 33; ++k) {
- if (addr + (subpgsize * k) > (ebnum + 1) * mtd->erasesize)
+ if (addr + (subpgsize * k) > (loff_t)(ebnum + 1) *
mtd->erasesize)
break;
prandom_bytes_state(&rnd_state, writebuf, subpgsize * k);
clear_data(readbuf, subpgsize * k);
diff --git a/drivers/mtd/tests/torturetest.c b/drivers/mtd/tests/torturetest.c
index b55bc52a1340..5045cf1b3160 100644
--- a/drivers/mtd/tests/torturetest.c
+++ b/drivers/mtd/tests/torturetest.c
@@ -101,11 +101,11 @@ static inline int check_eraseblock(int ebnum, unsigned
char *buf)
{
int err, retries = 0;
size_t read;
- loff_t addr = ebnum * mtd->erasesize;
+ loff_t addr = (loff_t)ebnum * mtd->erasesize;
size_t len = mtd->erasesize;
if (pgcnt) {
- addr = (ebnum + 1) * mtd->erasesize - pgcnt * pgsize;
+ addr = (loff_t)(ebnum + 1) * mtd->erasesize - pgcnt * pgsize;
len = pgcnt * pgsize;
}
@@ -155,11 +155,11 @@ static inline int write_pattern(int ebnum, void *buf)
{
int err;
size_t written;
- loff_t addr = ebnum * mtd->erasesize;
+ loff_t addr = (loff_t)ebnum * mtd->erasesize;
size_t len = mtd->erasesize;
if (pgcnt) {
- addr = (ebnum + 1) * mtd->erasesize - pgcnt * pgsize;
+ addr = (loff_t)(ebnum + 1) * mtd->erasesize - pgcnt * pgsize;
len = pgcnt * pgsize;
}
err = mtd_write(mtd, addr, len, &written, buf);
--
2.1.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 4/7] mtd: nand: fixup bounds checks for nand_{lock,unlock}()
Coverity noticed that these 'ret' assignments weren't being used. Let's use them. Note that nand_lock() and nand_unlock() are still not officially used by any drivers. Coverity CIDs #1227054 and #1227037 Signed-off-by: Brian Norris --- drivers/mtd/nand/nand_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index df7eb4ff07d1..5488a7ad63e7 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -968,7 +968,7 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) __func__, (unsigned long long)ofs, len); if (check_offs_len(mtd, ofs, len)) - ret = -EINVAL; + return -EINVAL; /* Align to last block address if size addresses end of the device */ if (ofs + len == mtd->size) @@ -1031,7 +1031,7 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) __func__, (unsigned long long)ofs, len); if (check_offs_len(mtd, ofs, len)) - ret = -EINVAL; + return -EINVAL; nand_get_device(mtd, FL_LOCKING); -- 2.1.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 1/7] mtd: docg3: drop dead code
If no devices were found, we would already have skipped over this code. Detected by Coverity, CID #744270 Signed-off-by: Brian Norris --- drivers/mtd/devices/docg3.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c index 448ce42f951e..01eddea1f0d9 100644 --- a/drivers/mtd/devices/docg3.c +++ b/drivers/mtd/devices/docg3.c @@ -2079,8 +2079,6 @@ static int __init docg3_probe(struct platform_device *pdev) ret = doc_register_sysfs(pdev, cascade); if (ret) goto err_probe; - if (!found) - goto notfound; platform_set_drvdata(pdev, cascade); doc_dbg_register(cascade->floors[0]->priv); -- 2.1.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] mfd: rk808: disable the under voltage detect
Rk808 has a under voltage detect function, when the voltage of buck is
under 85% the target voltage, the buck output will reset. But if the
power load is too heavy, this function maybe err, when current over
4.2A, although the voltage is normal, but RK808 mistakenly think it is
under 85%, and reset the buck. So let's disable this function.
Signed-off-by: Chris Zhong
---
drivers/mfd/rk808.c | 1 +
include/linux/mfd/rk808.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index bd02150..7cf25c7 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -89,6 +89,7 @@ static const struct rk808_reg_data pre_init_reg[] = {
{ RK808_BOOST_CONFIG_REG, BOOST_ILMIN_MASK, BOOST_ILMIN_100MA },
{ RK808_BUCK1_CONFIG_REG, BUCK1_RATE_MASK, BUCK_ILMIN_200MA },
{ RK808_BUCK2_CONFIG_REG, BUCK2_RATE_MASK, BUCK_ILMIN_200MA },
+ { RK808_DCDC_UV_ACT_REG, BUCK_UV_ACT_MASK, BUCK_UV_ACT_DISABLE},
{ RK808_VB_MON_REG, MASK_ALL, VB_LO_ACT |
VB_LO_SEL_3500MV },
};
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index fb09312..441b6ee 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -156,6 +156,9 @@ enum rk808_reg {
#define BUCK2_RATE_MASK(3 << 3)
#define MASK_ALL 0xff
+#define BUCK_UV_ACT_MASK 0x0f
+#define BUCK_UV_ACT_DISABLE0
+
#define SWITCH2_EN BIT(6)
#define SWITCH1_EN BIT(5)
#define DEV_OFF_RSTBIT(3)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/7] Add VMX module for PPC64
On Fri, Feb 06, 2015 at 02:54:55PM -0200, Leonidas S. Barbosa wrote: > VMX cryptographic acceleration instructions were added to the POWER8 > CPU. These instructions implement portions of AES and GHASH in hardware. > > This patch set adds a new module for PPC64, vmx, that support > cryptographic routines such as AES and GHASH on hardware. In order to > access VMX instructions on Power 8 CPU this module uses scripts > implemented in colaboration with OpenSSL. > > Changelog[v2] > 1. Patch style fixes > 2. Redo unecessary conditions on drivers/crypto/Kconfig > and vmx/Makefile in previous [Patch 7/7] All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: psmouse - when comparing PNP IDs ignore case
Hi,
On 28-02-15 01:18, Dmitry Torokhov wrote:
PNP IDs are supposed to be case-insensitive and so we should compare
them as such.
Signed-off-by: Dmitry Torokhov
Looks good:
Acked-by: Hans de Goede
Regards,
Hans
---
drivers/input/mouse/psmouse-base.c | 39 +++---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index 4ccd01d..a175496 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -463,19 +463,44 @@ static int psmouse_poll(struct psmouse *psmouse)
PSMOUSE_CMD_POLL | (psmouse->pktsize << 8));
}
+static bool psmouse_check_pnp_id(const char *id, const char * const ids[])
+{
+ int i;
+
+ for (i = 0; ids[i]; i++)
+ if (!strcasecmp(id, ids[i]))
+ return true;
+
+ return false;
+}
+
/*
* psmouse_matches_pnp_id - check if psmouse matches one of the passed in ids.
*/
bool psmouse_matches_pnp_id(struct psmouse *psmouse, const char * const ids[])
{
- int i;
-
- if (!strncmp(psmouse->ps2dev.serio->firmware_id, "PNP:", 4))
- for (i = 0; ids[i]; i++)
- if (strstr(psmouse->ps2dev.serio->firmware_id, ids[i]))
- return true;
+ struct serio *serio = psmouse->ps2dev.serio;
+ char *p, *fw_id_copy, *save_ptr;
+ bool found = false;
+
+ if (!strncmp(serio->firmware_id, "PNP:", 4))
+ return false;
+
+ fw_id_copy = kstrndup(&serio->firmware_id[4],
+ sizeof(serio->firmware_id) - 4,
+ GFP_KERNEL);
+ if (!fw_id_copy)
+ return false;
+
+ save_ptr = fw_id_copy;
+ while ((p = strsep(&fw_id_copy, " ")) != NULL) {
+ if (psmouse_check_pnp_id(p, ids))
+ found = true;
+ break;
+ }
- return false;
+ kfree(save_ptr);
+ return found;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] proc: introduce /proc//lbr_stack
On Fri, Feb 27, 2015 at 03:57:02PM -0800, Andi Kleen wrote: > On Fri, Feb 27, 2015 at 11:05:45PM +0100, Peter Zijlstra wrote: > > On Fri, Feb 27, 2015 at 09:54:34AM -0800, Andi Kleen wrote: > > > > > perf record doesn't show where you're currently blocked. > > > > > > > > Of course it does; look at perf inject -s. > > > > > > Trace points don't support the LBR stack. > > > > Yes, indeed. But would it not make much more sense to squirrel the LBR > > state into sched:sched_switch and teach that inject -s thing to dtrt, > > than to make a proc file that's available on all archs but will only > > work on 1-2 x86 uarchs and only if you're also running the right magic > > perf record at the same time? > > Yes. It would be nice to capture the whole PMU state in trace points. > There are use models for this where it can work better than > sampling. > > But that would be a lot bigger project than this simple file, > which is already quite useful with minimal effort. Its also the most horrible hack of an interface ever, so no go. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip 3/7] tracing: allow BPF programs to call ktime_get_ns()
On Fri, Feb 27, 2015 at 04:08:51PM -0800, Alexei Starovoitov wrote:
> bpf_ktime_get_ns() is used by programs to compue time delta between events
> or as a timestamp
>
> Signed-off-by: Alexei Starovoitov
> ---
> include/uapi/linux/bpf.h |1 +
> kernel/trace/bpf_trace.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 4486d36d2e9e..101e509d1001 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -165,6 +165,7 @@ enum bpf_func_id {
> BPF_FUNC_map_update_elem, /* int map_update_elem(&map, &key, &value,
> flags) */
> BPF_FUNC_map_delete_elem, /* int map_delete_elem(&map, &key) */
> BPF_FUNC_probe_read, /* int bpf_probe_read(void *dst, int size,
> void *src) */
> + BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
> __BPF_FUNC_MAX_ID,
> };
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index bcce9b238dad..64b918488607 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -36,6 +36,11 @@ static u64 bpf_probe_read(u64 r1, u64 r2, u64 r3, u64 r4,
> u64 r5)
> return probe_kernel_read(dst, unsafe_ptr, size);
> }
>
> +static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
> + return ktime_get_ns();
> +}
Please use ktime_get_mono_fast_ns() instead. If you ever want to allow
running BPF stuff from general tracepoints and the like you need to
be NMI safe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] UBI: fix out of bounds write
If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Signed-off-by: Brian Norris --- drivers/mtd/ubi/eba.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index da4c79259f67..6442d3fbcb73 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -1418,7 +1418,8 @@ int ubi_eba_init(struct ubi_device *ubi, struct ubi_attach_info *ai) * during re-size. */ ubi_move_aeb_to_list(av, aeb, &ai->erase); - vol->eba_tbl[aeb->lnum] = aeb->pnum; + else + vol->eba_tbl[aeb->lnum] = aeb->pnum; } } -- 2.1.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 0/5] UBI: Coverity-inspired fixes
Except for the last one, these were inspired by Coverity Scan results. These fixes have barely been tested, but they are pretty straightforward logically. As they've been sitting in my dust pile too long, I thought I'd at least get them out there. Brian Norris (5): UBI: account for bitflips in both the VID header and data UBI: fix out of bounds write UBI: initialize LEB number variable UBI: fix check for "too many bytes" UBI: align comment for readability drivers/mtd/ubi/attach.c | 2 +- drivers/mtd/ubi/cdev.c | 2 +- drivers/mtd/ubi/eba.c| 3 ++- drivers/mtd/ubi/ubi.h| 2 +- drivers/mtd/ubi/wl.c | 2 +- 5 files changed, 6 insertions(+), 5 deletions(-) -- 2.1.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 1/5] UBI: account for bitflips in both the VID header and data
We are completely discarding the earlier value of 'bitflips', which
could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the
bitwise OR of header and data 'bitflip' statuses instead.
Coverity CID #1226856
Signed-off-by: Brian Norris
---
drivers/mtd/ubi/attach.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 9d2e16f3150a..b5e154856994 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -410,7 +410,7 @@ int ubi_compare_lebs(struct ubi_device *ubi, const struct
ubi_ainf_peb *aeb,
second_is_newer = !second_is_newer;
} else {
dbg_bld("PEB %d CRC is OK", pnum);
- bitflips = !!err;
+ bitflips |= !!err;
}
mutex_unlock(&ubi->buf_mutex);
--
2.1.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 5/5] UBI: align comment for readability
The kerneldoc for @vid_hdr_aloffset continues onto a second line, but
this is not obvious, because the second line isn't indented, and it
begins with '@'.
Signed-off-by: Brian Norris
---
drivers/mtd/ubi/ubi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index c5be82d9d345..2251a6c4c8fa 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -479,7 +479,7 @@ struct ubi_debug_info {
* @vid_hdr_offset: starting offset of the volume identifier header (might be
* unaligned)
* @vid_hdr_aloffset: starting offset of the VID header aligned to
- * @hdrs_min_io_size
+ *@hdrs_min_io_size
* @vid_hdr_shift: contains @vid_hdr_offset - @vid_hdr_aloffset
* @bad_allowed: whether the MTD device admits of bad physical eraseblocks or
* not
--
2.1.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 4/5] UBI: fix check for "too many bytes"
The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Signed-off-by: Brian Norris --- drivers/mtd/ubi/cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c index d647e504f9b1..7691a2a015cb 100644 --- a/drivers/mtd/ubi/cdev.c +++ b/drivers/mtd/ubi/cdev.c @@ -455,7 +455,7 @@ static long vol_cdev_ioctl(struct file *file, unsigned int cmd, /* Validate the request */ err = -EINVAL; if (req.lnum < 0 || req.lnum >= vol->reserved_pebs || - req.bytes < 0 || req.lnum >= vol->usable_leb_size) + req.bytes < 0 || req.bytes >= vol->usable_leb_size) break; err = get_exclusive(desc); -- 2.1.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 3/5] UBI: initialize LEB number variable
In some of the 'out_not_moved' error paths, lnum may be used
uninitialized. Don't ignore the warning; let's fix it.
This uninitialized variable doesn't have much visible effect in the end,
since we just schedule the PEB for erasure, and its LEB number doesn't
really matter (it just gets printed in debug messages). But let's get it
straight anyway.
Coverity CID #113449
Signed-off-by: Brian Norris
---
drivers/mtd/ubi/wl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 8f7bde6a85d6..0bd92d816391 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1002,7 +1002,7 @@ static int wear_leveling_worker(struct ubi_device *ubi,
struct ubi_work *wrk,
int shutdown)
{
int err, scrubbing = 0, torture = 0, protect = 0, erroneous = 0;
- int vol_id = -1, uninitialized_var(lnum);
+ int vol_id = -1, lnum = -1;
#ifdef CONFIG_MTD_UBI_FASTMAP
int anchor = wrk->anchor;
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: crypto: mxs-dcp - fix type of ret for wait_for_completion_timeout
On Sat, Feb 07, 2015 at 03:09:41AM -0500, Nicholas Mc Guire wrote: > return type of wait_for_completion_timeout is unsigned long not int, this > patch changes the type of ret from int to unsigned long. > > Signed-off-by: Nicholas Mc Guire All four patches applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Generic page fault (Was: libsigsegv ....)
On Sat, 2015-02-28 at 18:14 +1100, Benjamin Herrenschmidt wrote: > On Sat, 2015-02-28 at 18:12 +1100, Benjamin Herrenschmidt wrote: > > > > Let me know what you think of the approach. It's boot tested on x86_64 > > in qemu and > > ... and powerpc64 LE on qemu as well :-) One thing I'd like to do is fold handle_kernel_fault() into handle_bad_area() (and in fact fold do_sigbus as well). Basically have a single handle_bad_fault() that takes sig and si_code as arguments which we call from the generic code for all faults. It will test for kernel vs. user mode and do the right thing (and we could handle the sigbus special case by simply comparing sig to sigbus). The one reason I haven't done it so far is that x86 handle_bad_area() has the is_f00f_bug() call which isn't do for other cases of no_context() and I'm not sure generalizing it is safe for all cases (or maybe I can call it only when sig is SIGSEGV ?) ... I don't actually understand what it does :) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] paride: fix the "verbose" module param
The verbose module parameter can be set to 2 for extremely verbose
messages so the type should be int instead of bool.
Signed-off-by: Dan Carpenter
diff --git a/drivers/block/paride/pg.c b/drivers/block/paride/pg.c
index 2ce3dfd..876d0c3 100644
--- a/drivers/block/paride/pg.c
+++ b/drivers/block/paride/pg.c
@@ -137,7 +137,7 @@
*/
-static bool verbose = 0;
+static int verbose;
static int major = PG_MAJOR;
static char *name = PG_NAME;
static int disable = 0;
@@ -168,7 +168,7 @@ enum {D_PRT, D_PRO, D_UNI, D_MOD, D_SLV, D_DLY};
#include
-module_param(verbose, bool, 0644);
+module_param(verbose, int, 0644);
module_param(major, int, 0);
module_param(name, charp, 0);
module_param_array(drive0, int, NULL, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] net: macb: Add big endian CPU support
Hi David, >> This patch converts all __raw_readl and __raw_writel function calls >> to their corresponding readl_relaxed and writel_relaxed variants. >> >> It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg >> when the CPU is configured in big endian mode. >> >> Signed-off-by: Arun Chandran > > This does not apply cleanly to net-next, please respin. The net-next tree already contains the initial version of this change (commit: a50dad355a5314da64586da36804b86fbebb7c2a). This applies cleanly if you revert that. #~/work/open_source/net-next/net-next$ git log -2 commit 3cbef72505634b346dadb5f4ffd0fdb68c07710c Author: Arun Chandran Date: Wed Feb 18 16:35:44 2015 +0530 net: macb: Add big endian CPU support This patch converts all __raw_readl and __raw_writel function calls to their corresponding readl_relaxed and writel_relaxed variants. It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg when the CPU is configured in big endian mode. Signed-off-by: Arun Chandran commit 693aba8f896f286d9ddd4445ced374d2c96b41a2 Author: Arun Chandran Date: Sat Feb 28 16:03:18 2015 +0530 Revert "net: macb: Add big endian CPU support" This reverts commit a50dad355a5314da64586da36804b86fbebb7c2a. --Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [LKP] [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0()
On Thu, Feb 26, 2015 at 01:16:17PM +0100, Borislav Petkov wrote:
> The proper fix should be to say, don't ioremap setup_data which is
> kernel memory but I'm not sure I have a good idea at the moment how to
> do that *without* ioremapping the thing to inspect it first...
>
> More hmm...
Yeah, too many hmms means this still needed staring at to find out what
exactly the problem is. And the problem is that allocating that struct
setup_data statically in arch/x86/boot/compressed/aslr.c works only by
chance, when the kernel decompressing doesn't overwrite that memory.
One thing that we could do is to stick it right below LOAD_PHYSICAL_ADDR
(16M by default) which is the miminum physical address for the kernel to
be loaded at and kaslr pays attention to.
I.e., this struct setup_data thing lands then here:
[0.00] parse_setup_data: data: 0xe0 (va: ff200fe0) { next:
0x0, type: 0x5, len: 17, data[0]: 0x0 }
which is 16M - 2*sizeof(struct setup_data). Yeah, I left some room
there.
Now, this approach works but I'm not sure whether this is how we want to
be passing setup_data stuff from arch/x86/boot/ to kernel proper so I'd
like to hear some more experienced opinions please...
Thanks!
---
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 7083c16cccba..9f64c64e3ebe 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -14,12 +14,7 @@
static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
-struct kaslr_setup_data {
- __u64 next;
- __u32 type;
- __u32 len;
- __u8 data[1];
-} kaslr_setup_data;
+struct setup_data *ksd;
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER00x40
@@ -302,14 +297,20 @@ static unsigned long find_random_addr(unsigned long
minimum,
return slots_fetch_random();
}
-static void add_kaslr_setup_data(struct boot_params *params, __u8 enabled)
+static void add_kaslr_setup_data(struct boot_params *params,
+u8 *output, __u8 enabled)
{
struct setup_data *data;
- kaslr_setup_data.type = SETUP_KASLR;
- kaslr_setup_data.len = 1;
- kaslr_setup_data.next = 0;
- kaslr_setup_data.data[0] = enabled;
+ /*
+* Stick it right under LOAD_PHYSICAL_ADDR
+*/
+ ksd = (struct setup_data *)(output - 2 * sizeof(struct setup_data));
+
+ ksd->type = SETUP_KASLR;
+ ksd->len = 1;
+ ksd->next = 0;
+ ksd->data[0] = enabled;
data = (struct setup_data *)(unsigned long)params->hdr.setup_data;
@@ -317,10 +318,9 @@ static void add_kaslr_setup_data(struct boot_params
*params, __u8 enabled)
data = (struct setup_data *)(unsigned long)data->next;
if (data)
- data->next = (unsigned long)&kaslr_setup_data;
+ data->next = (unsigned long)ksd;
else
- params->hdr.setup_data = (unsigned long)&kaslr_setup_data;
-
+ params->hdr.setup_data = (unsigned long)ksd;
}
unsigned char *choose_kernel_location(struct boot_params *params,
@@ -335,17 +335,17 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
#ifdef CONFIG_HIBERNATION
if (!cmdline_find_option_bool("kaslr")) {
debug_putstr("KASLR disabled by default...\n");
- add_kaslr_setup_data(params, 0);
+ add_kaslr_setup_data(params, output, 0);
goto out;
}
#else
if (cmdline_find_option_bool("nokaslr")) {
debug_putstr("KASLR disabled by cmdline...\n");
- add_kaslr_setup_data(params, 0);
+ add_kaslr_setup_data(params, output, 0);
goto out;
}
#endif
- add_kaslr_setup_data(params, 1);
+ add_kaslr_setup_data(params, output, 1);
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 98dc9317286e..d3b34df6e539 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -429,7 +429,11 @@ static void __init reserve_initrd(void)
static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
{
- kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
+ struct setup_data *kdata;
+
+ kdata = early_memremap(pa_data, data_len);
+ kaslr_enabled = kdata->data[0];
+ early_iounmap(kdata, data_len);
}
static void __init parse_setup_data(void)
---
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: ALPS - fix memory leak when detection fails
On Saturday 28 February 2015 00:53:57 Dmitry Torokhov wrote:
> This fixes memory leak introduced by commit
> a09221e83e13e09a33109b9b037484eade901cea
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/mouse/alps.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/alps.c
> b/drivers/input/mouse/alps.c index d28726a..1bd15eb 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2605,8 +2605,10 @@ int alps_detect(struct psmouse
> *psmouse, bool set_properties) return -ENOMEM;
>
> error = alps_identify(psmouse, priv);
> - if (error)
> + if (error) {
> + kfree(priv);
> return error;
> + }
>
> if (set_properties) {
> psmouse->vendor = "ALPS";
Acked-by: Pali Rohár
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/2] drivers: cpuidle: minor suspend-to-idle fixes
On Fri, Feb 27, 2015 at 10:11:54PM +, Rafael J. Wysocki wrote:
> On Friday, February 27, 2015 10:00:00 AM Lorenzo Pieralisi wrote:
> > [CC'ed Preeti]
> >
> > On Thu, Feb 26, 2015 at 11:37:54PM +, Rafael J. Wysocki wrote:
> > > Me versions of the two $subject patches follow.
> >
> > Thank you. I am testing them and I have run into the following issue.
> >
> > Starting with:
> >
> > 3810631 ("PM / sleep: Re-implement suspend-to-idle handling")
> >
> > the suspend-to-idle code path in the cpuidle_idle_call() bypasses
> > the CPUIDLE_FLAG_TIMER_STOP code path entirely.
>
> Hmm, this looks like a mistake. Sorry about that.
Thank you for looking into this !
> > Now, on most of
> > the current ARM platforms, the deepest idle state loses the tick device
> > context, therefore this means that going to idle through
> > suspend-to-idle becomes a brute force way of nuking the tick,
> > unless I am missing something here.
> >
> > I am experiencing hangs on resume from suspend-to-idle when the broadcast
> > timer is the broadast-hrtimer (ie there is no HW broadcast timer in the
> > platform) and the deepest idle states lose the tick device context (ie
> > they are CPUIDLE_FLAG_TIMER_STOP), I hope Preeti can help me test this on
> > Power, still chasing the issue.
> >
> > I could not reproduce the issue with a HW broadcast timer device.
> >
> > Platform has deepest idle states that allow CPUs shutdown where the
> > local tick device is gone on entry, I am trying to provide you with a
> > backtrace, I need time to debug.
> >
> > The question I have: is it safe to bypass the CPUIDLE_FLAG_TIMER_STOP
> > and related broadcast mode entry/exit in the suspend-to-idle path ?
> >
> > I do not think it is, but I am asking.
>
> It isn't in general, but it would be OK in the enter_freeze_proper() path
> where the tick is suspended anyway.
Entering state through enter_freeze() (ie adding the function pointer
in the idle states, on platforms where it is appropriate), therefore
freezing the tick solves the issue, so I think we should patch all ARM
drivers that can benefit from this interesting new feature.
> > I can "force" tick freeze by initializing the enter_freeze pointer
> > in the idle states (that's the next thing I will test), but still, for
> > platforms where that's not possible my question above is still valid.
>
> Right.
>
> Does the patch below help (on top of the previous ones)?
I need HW to test, I will do that first thing on Monday, and send
you the appropriate tags. I already put together a similar patch
and tested it yesterday, so I can say already that it solves the
problem, I will test your patch on Monday and get back to you
(patch 1 and 2 in this series already tested on a platform with no
CPUidle driver registered, and they work and fix the NULL drv
dereference issue).
Thank you !
Lorenzo
>
> Rafael
>
>
> ---
> drivers/cpuidle/cpuidle.c | 31 ++-
> kernel/sched/idle.c | 17 ++---
> 2 files changed, 28 insertions(+), 20 deletions(-)
>
> Index: linux-pm/drivers/cpuidle/cpuidle.c
> ===
> --- linux-pm.orig/drivers/cpuidle/cpuidle.c
> +++ linux-pm/drivers/cpuidle/cpuidle.c
> @@ -230,15 +230,36 @@ int cpuidle_select(struct cpuidle_driver
> * @dev: the cpuidle device
> * @index: the index in the idle state table
> *
> - * Returns the index in the idle state, < 0 in case of error.
> - * The error code depends on the backend driver
> + * Returns the index in the idle state, < 0 in case of error. -EBUSY is
> + * returned to indicate that the target state was temporarily unavailable.
> + * The other error codes depend on the backend driver.
> */
> int cpuidle_enter(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> int index)
> {
> - if (cpuidle_state_is_coupled(dev, drv, index))
> - return cpuidle_enter_state_coupled(dev, drv, index);
> - return cpuidle_enter_state(dev, drv, index);
> + unsigned int broadcast;
> + int ret;
> +
> + broadcast = drv->states[index].flags & CPUIDLE_FLAG_TIMER_STOP;
> +
> + /*
> + * Tell the time framework to switch to a broadcast timer
> + * because our local timer will be shutdown. If a local timer
> + * is used from another cpu as a broadcast timer, this call may
> + * fail if it is not available
> + */
> + if (broadcast &&
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
> + return -EBUSY;
> +
> + ret = cpuidle_state_is_coupled(dev, drv, index) ?
> + cpuidle_enter_state_coupled(dev, drv, index) :
> + cpuidle_enter_state(dev, drv, index);
> +
> + if (broadcast)
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +
> + return ret;
> }
>
> /**
> Index: linux-pm/kernel/sched/idle.c
> ===
Re: [PATCH RFC 0/2] add nproc cgroup subsystem
Hello, Aleksa. On Sat, Feb 28, 2015 at 08:26:34PM +1100, Aleksa Sarai wrote: > I just want to quickly echo my support for this statement. Process IDs > aren't limited by kernel memory, they're a hard-set limit. Thus they are Process IDs become a hard global resource because we didn't switch to long during 64bit transition and put an artifical global limit on it, which allows it to affect system-wide operation while its memory consumption is staying within practical range. > a resource like other global resources (open files, etc). Now, while you Unlike open files. > can argue that it is possible to limit the amount of *effective* > processes you can use in a cgroup through kmemcg (by limiting the amount > of memory spent in storing task_struct data) -- that isn't limiting the > usage of the *actual* resource (the fact you're limiting the number of > PIDs is little more than a by-product). No, the problem is not that. The problem is that pid_t is, as a resource, is decoupled from its backing resource - memory - by the extra artificial and difficult-to-overcome limit put on it. You are saying something which is completely different from what Austin was arguing. > Also, If it wasn't an actual resource then why is RLIMIT_NPROC a thing? One strong reason would be because we didn't have a way to account for and limit the fundamental resources. If you can fully contain and control the consumption via rationing the underlying resource, there isn't much point in controlling the upper layer constructs. > To me, that indicates that PID limiting not an esoteric usecase and it > should be possible to use the Linux kernel's home-grown accounting > system to limit the number of PIDs in a cgroup. Otherwise you're stuck Again, I think it's a lot more indicative of the fact that we didn't have any way to control kernel side memory consumption and pids and open files were one of the things which are relatively easy to implement policy-wise. > in a weird world where you *can* limit the number of processes in a > process tree but *not* the number of processes in a cgroup. I'm not sold on the idea of replicating the features of ulimit in cgroups. ulimit is a mixed bag of relatively easily implementable resource limits and their behaviors are a combination of resource limits, per-user usage policies, and per-process behavior safetynets. The only part translatable to cgroups is actual resource related part and even among those we should identify what are actual resources which can't be mapped to consumption of other fundamental resources. > >> In general, I'm pretty strongly against adding controllers for things > >> which aren't fundamental resources in the system. What's next? Open > >> files? Pipe buffer? Number of flocks? Number of session leaders or > >> program groups? > >> > > PID's are a fundamental resource, you run out and it's an only marginally > > better situation than OOM, namely, if you don't already have a shell open > > which has kill builtin (because you can't fork), or have some other reliable > > way to terminate processes without forking, you are stuck either waiting for > > the problem to resolve itself, or have to reset the system. > > I couldn't agree more. PIDs are a fundamental resource because there is > a hard limit on the amount of PIDs you can have in any one system. Once > you've exhausted that limit, there's not much you can do apart from > doing the SYSRQ dance. The reason why this holds is because we can hit the global limit way earlier than a practically sized kmem consumption limits can kick in. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf: fuzzer causes lockup in x86_pmu_event_init()
On Wed, Feb 25, 2015 at 04:16:39PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 23, 2015 at 10:56:10PM -0500, Vince Weaver wrote:
> > On Tue, 17 Feb 2015, Vince Weaver wrote:
> > [884044.228001] RIP: 0010:[] []
> > x86_pmu_event_init+0x138/0x31d
>
> > [884044.228001] Call Trace:
> > [884044.228001] [] perf_try_init_event+0x25/0x47
> > [884044.228001] [] perf_init_event+0x93/0xca
> > [884044.228001] [] perf_event_alloc+0x29b/0x32d
> > [884044.228001] [] SYSC_perf_event_open+0x417/0x89c
> > [884044.228001] [] SyS_perf_event_open+0x9/0xb
>
> That smells like a corrupted sibling_list, I see no other way for that
> loop to not end.
>
> It occurs to me that that list iteration is entirely unserialized, we
> should be holding a ctx lock or mutex, but we do not.
>
> Now IIRC the perf fuzzer is single threaded, so it would not actually
> trigger the most horrible cases here; but this does smell bad.
>
> Does something like the below make sense and/or help? Jolsa?
SNIP
hum, I dont see the locking is a problem.. but looks like once
the sibling becomes singleton event, we dont init its sibling_list
how about patch below.. compile tested ;-)
jirka
---
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3e114019b14a..d91107392ce0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1470,7 +1470,9 @@ static void perf_group_detach(struct perf_event *event)
list_for_each_entry_safe(sibling, tmp, &event->sibling_list,
group_entry) {
if (list)
list_move_tail(&sibling->group_entry, list);
+
sibling->group_leader = sibling;
+ INIT_LIST_HEAD(&sibling->sibling_list);
/* Inherit group flags from the previous leader */
sibling->group_flags = event->group_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/
Re: [tip:perf/core] perf tools: Add feature check for libbabeltrace
On Sat, Feb 28, 2015 at 10:25:03AM +0100, Ingo Molnar wrote:
>
> * tip-bot for Jiri Olsa wrote:
>
> > Commit-ID: 53d0a57343949b2af9b27229db534b98e5a0c4d0
> > Gitweb:
> > http://git.kernel.org/tip/53d0a57343949b2af9b27229db534b98e5a0c4d0
> > Author: Jiri Olsa
> > AuthorDate: Fri, 20 Feb 2015 23:16:58 +0100
> > Committer: Arnaldo Carvalho de Melo
> > CommitDate: Wed, 25 Feb 2015 12:42:24 -0300
> >
> > perf tools: Add feature check for libbabeltrace > >
> > Adding feature check for babeltrace library [1], which will be used for
> > perf data file CTF [2] conversion in following patches.
>
> So this doesn't work on recent Ubuntu systems:
>
> ... libbabeltrace: [ OFF ]
>
> triton:~/tip/tools/perf/config/feature-checks> make
> test-libbabeltrace.bin
> gcc -MD -Wall -Werror -o test-libbabeltrace.bin test-libbabeltrace.c
> # -lbabeltrace provided by
> test-libbabeltrace.c: In function ‘main’:test-libbabeltrace.c:6:2: error:
> implicit declaration of function
> ‘bt_ctf_stream_class_get_packet_context_type’
> [-Werror=implicit-function-declaration]
> bt_ctf_stream_class_get_packet_context_type((void *) 0);
> ^
> cc1: all warnings being treated as errors
> Makefile:140: recipe for target 'test-libbabeltrace.bin' failed
>
> I have all the requirements, libbabeltrace-ctf-dev and
> libbabeltrace-dev installed, yet the writer.h file:
>
> -rw-r--r-- 1 root root 5283 Oct 7 14:44
> /usr/include/babeltrace/ctf-writer/writer.h
>
> does not include a prototype for
> bt_ctf_stream_class_get_packet_context_type().
hum, I have it in stream-class.h and it seems to be there since Jul 29 2014
What is the libbabeltrace package version on Ubuntu?
>
> If Ubuntu's writer.h is too old then either our API use should match
> the ones available:
>
> triton:~/tip/tools/perf/config/feature-checks> grep extern
> /usr/include/babeltrace/ctf-writer/writer.h
> extern "C" {
> extern struct bt_ctf_writer *bt_ctf_writer_create(const char *path);
> extern struct bt_ctf_stream *bt_ctf_writer_create_stream(
> extern int bt_ctf_writer_add_environment_field(struct bt_ctf_writer *writer,
> extern int bt_ctf_writer_add_clock(struct bt_ctf_writer *writer,
> extern char *bt_ctf_writer_get_metadata_string(struct bt_ctf_writer *writer);
> extern void bt_ctf_writer_flush_metadata(struct bt_ctf_writer *writer);
> extern int bt_ctf_writer_set_byte_order(struct bt_ctf_writer *writer,
> extern void bt_ctf_writer_get(struct bt_ctf_writer *writer);
> extern void bt_ctf_writer_put(struct bt_ctf_writer *writer);
>
> or CTF support should be removed from the default set of perf
> features, because right now it blocks the 'all' build speedup.
I'll try to get Ubuntu system and check, but I'd be ok to put
it out of the default set until ditributions catch up..
I'll check next week and send patch or update
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/mm] x86/mm: Unexport set_memory_ro() and set_memory_rw()
On 2/28/2015 2:00 AM, tip-bot for Daniel Borkmann wrote:
Commit-ID: 6bbb614ec478961c7443086bdf7fd6784479c14a
Gitweb: http://git.kernel.org/tip/6bbb614ec478961c7443086bdf7fd6784479c14a
Author: Daniel Borkmann
AuthorDate: Fri, 27 Feb 2015 15:55:40 +0100
Committer: Ingo Molnar
CommitDate: Sat, 28 Feb 2015 10:41:59 +0100
x86/mm: Unexport set_memory_ro() and set_memory_rw()
This effectively unexports set_memory_ro() and set_memory_rw()
functions, and thus reverts:
a03352d2c1dc ("x86: export set_memory_ro and set_memory_rw").
They have been introduced for debugging purposes in e1000e, but
no module user is in mainline kernel (anymore?) and we
explicitly do not want modules to use these functions, as they
i.e. protect eBPF (interpreted & JIT'ed) images from malicious
modifications or bugs.
Outside of eBPF scope, I believe also other set_memory_*()
functions should be unexported on x86 for modules.
Acked-by: Arjan van de Ven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] power: bq27x00_battery: add bq27510 support
Add support for bq27510 to the bq27x00 driver.
Signed-off-by: Alexandre Belloni
---
Changes in v2:
- corrected the bq27x00_battery_read_cyct changes
drivers/power/bq27x00_battery.c | 52 -
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index a78ac201828e..530710ec2bc3 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -24,6 +24,7 @@
* http://focus.ti.com/docs/prod/folders/print/bq27500.html
* http://www.ti.com/product/bq27425-g1
* http://www.ti.com/product/BQ27742-G1
+ * http://www.ti.com/product/BQ27510-G3
*/
#include
@@ -74,6 +75,10 @@
#define BQ27742_POWER_AVG 0x76
+#define BQ27510_REG_SOC0x20
+#define BQ27510_REG_DCAP 0x2E /* Design capacity */
+#define BQ27510_REG_CYCT 0x1E /* Cycle count total */
+
/* bq27425 register addresses are same as bq27x00 addresses minus 4 */
#define BQ27425_REG_OFFSET 0x04
#define BQ27425_REG_SOC0x18 /* Register address plus
offset */
@@ -86,7 +91,7 @@ struct bq27x00_access_methods {
int (*read)(struct bq27x00_device_info *di, u8 reg, bool single);
};
-enum bq27x00_chip { BQ27000, BQ27500, BQ27425, BQ27742};
+enum bq27x00_chip { BQ27000, BQ27500, BQ27425, BQ27742, BQ27510};
struct bq27x00_reg_cache {
int temperature;
@@ -173,6 +178,24 @@ static enum power_supply_property bq27742_battery_props[]
= {
POWER_SUPPLY_PROP_HEALTH,
};
+static enum power_supply_property bq27510_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+ POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+ POWER_SUPPLY_PROP_CYCLE_COUNT,
+ POWER_SUPPLY_PROP_POWER_AVG,
+ POWER_SUPPLY_PROP_HEALTH,
+};
+
static unsigned int poll_interval = 360;
module_param(poll_interval, uint, 0644);
MODULE_PARM_DESC(poll_interval, "battery poll interval in seconds - " \
@@ -197,7 +220,8 @@ static inline int bq27x00_read(struct bq27x00_device_info
*di, u8 reg,
*/
static bool bq27xxx_is_chip_version_higher(struct bq27x00_device_info *di)
{
- if (di->chip == BQ27425 || di->chip == BQ27500 || di->chip == BQ27742)
+ if (di->chip == BQ27425 || di->chip == BQ27500 || di->chip == BQ27742
+ || di->chip == BQ27510)
return true;
return false;
}
@@ -212,6 +236,8 @@ static int bq27x00_battery_read_rsoc(struct
bq27x00_device_info *di)
if (di->chip == BQ27500 || di->chip == BQ27742)
rsoc = bq27x00_read(di, BQ27500_REG_SOC, false);
+ else if (di->chip == BQ27510)
+ rsoc = bq27x00_read(di, BQ27510_REG_SOC, false);
else if (di->chip == BQ27425)
rsoc = bq27x00_read(di, BQ27425_REG_SOC, false);
else
@@ -282,7 +308,9 @@ static int bq27x00_battery_read_ilmd(struct
bq27x00_device_info *di)
{
int ilmd;
- if (bq27xxx_is_chip_version_higher(di))
+ if (di->chip == BQ27510)
+ ilmd = bq27x00_read(di, BQ27510_REG_DCAP, false);
+ else if (bq27xxx_is_chip_version_higher(di))
ilmd = bq27x00_read(di, BQ27500_REG_DCAP, false);
else
ilmd = bq27x00_read(di, BQ27000_REG_ILMD, true);
@@ -350,7 +378,10 @@ static int bq27x00_battery_read_cyct(struct
bq27x00_device_info *di)
{
int cyct;
- cyct = bq27x00_read(di, BQ27x00_REG_CYCT, false);
+ if (di->chip == BQ27510)
+ cyct = bq27x00_read(di, BQ27510_REG_CYCT, false);
+ else
+ cyct = bq27x00_read(di, BQ27x00_REG_CYCT, false);
if (cyct < 0)
dev_err(di->dev, "error reading cycle count total\n");
@@ -421,6 +452,10 @@ static int bq27x00_battery_read_health(struct
bq27x00_device_info *di)
else
tval = POWER_SUPPLY_HEALTH_GOOD;
return tval;
+ } else if (di->chip == BQ27510) {
+ if (tval & BQ27500_FLAG_OTC)
+ return POWER_SUPPLY_HEALTH_OVERHEAT;
+ return POWER_SUPPLY_HEALTH_GOOD;
} else {
if (tval & BQ27000_FLAG_EDV1)
tval = POWER_SUPPLY_HEALTH_DEAD;
@@ -436,6 +471,7 @@ static void bq27x00_update(struct bq27x00_device_info *di)
{
struct bq27x00_reg_cache cache = {0, };
bool is_bq27500 = di->chip == BQ27500;
+ bool is_bq27510 = di->chip == BQ27510;
bool is_bq27425 = di->chip == BQ27425;
bool is_bq27742 = di->chip == BQ27742;
bo
Re: [PATCH] power: bq27x00_battery: add bq27510 support
Hi,
On 25/02/2015 at 23:17:48 +0100, Sebastian Reichel wrote :
> > @@ -350,6 +378,9 @@ static int bq27x00_battery_read_cyct(struct
> > bq27x00_device_info *di)
> > {
> > int cyct;
> >
> > +
>
> spurious newline.
>
> > + if (di->chip == BQ27510)
> > + cyct = bq27x00_read(di, BQ27510_REG_CYCT, false);
> > cyct = bq27x00_read(di, BQ27x00_REG_CYCT, false);
>
> missing else?
>
Indeed, I just sent v2. However, I'm not too happy with all that if/else
layering in this driver. I'll try to rework it so that it scales better.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Attn My Dear
Attn My Dear I have registered your package with BCEAO BANK PLC Republic of Togo this morning and we agreed up that the delivery of your $2.8m in ATM CARD delivery will take place Tomorrow morning call me +234-070-313-564-01 your information is needed Full Name: Home Address occupation: Cell Phone Country: Age: Contact Person Barr Dikko Moore Email:( hon.dikkomo...@gmail.com ) Phone +234-070-313-564-01 Thanks Yours sincerely, Dikko Moore -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm/arm64: KVM: Fix migration race in the arch timer
On Wed, 25 Feb 2015 15:36:21 +
Alex Bennée wrote:
Alex, Christoffer,
> From: Christoffer Dall
>
> When a VCPU is no longer running, we currently check to see if it has
> a timer scheduled in the future, and if it does, we schedule a host
> hrtimer to notify is in case the timer expires while the VCPU is still
> not running. When the hrtimer fires, we mask the guest's timer and
> inject the timer IRQ (still relying on the guest unmasking the time
> when it receives the IRQ).
>
> This is all good and fine, but when migration a VM
> (checkpoint/restore) this introduces a race. It is unlikely, but
> possible, for the following sequence of events to happen:
>
> 1. Userspace stops the VM
> 2. Hrtimer for VCPU is scheduled
> 3. Userspace checkpoints the VGIC state (no pending timer interrupts)
> 4. The hrtimer fires, schedules work in a workqueue
> 5. Workqueue function runs, masks the timer and injects timer
> interrupt 6. Userspace checkpoints the timer state (timer masked)
>
> At restore time, you end up with a masked timer without any timer
> interrupts and your guest halts never receiving timer interrupts.
>
> Fix this by only kicking the VCPU in the workqueue function, and
> sample the expired state of the timer when entering the guest again
> and inject the interrupt and mask the timer only then.
>
> Signed-off-by: Christoffer Dall
> Signed-off-by: Alex Bennée
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8531536..f7fd76e 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -269,7 +269,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>
> int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
> {
> - return 0;
> + return kvm_timer_should_fire(vcpu);
> }
>
> int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> diff --git a/include/kvm/arm_arch_timer.h
> b/include/kvm/arm_arch_timer.h index b3f45a5..98cc9f4 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -72,6 +72,8 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu
> *vcpu); u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
> int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
>
> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
> +
> #else
> static inline int kvm_timer_hyp_init(void)
> {
> @@ -96,6 +98,11 @@ static inline u64 kvm_arm_timer_get_reg(struct
> kvm_vcpu *vcpu, u64 regid) {
> return 0;
> }
> +
> +static inline bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
> +{
> + return false;
> +}
> #endif
>
> #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 6e54f35..98c95f2 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -85,13 +85,22 @@ static irqreturn_t kvm_arch_timer_handler(int
> irq, void *dev_id) return IRQ_HANDLED;
> }
>
> +/*
> + * Work function for handling the backup timer that we schedule when
> a vcpu is
> + * no longer running, but had a timer programmed to fire in the
> future.
> + */
> static void kvm_timer_inject_irq_work(struct work_struct *work)
> {
> struct kvm_vcpu *vcpu;
>
> vcpu = container_of(work, struct kvm_vcpu,
> arch.timer_cpu.expired); vcpu->arch.timer_cpu.armed = false;
> - kvm_timer_inject_irq(vcpu);
> +
> + /*
> + * If the vcpu is blocked we want to wake it up so that it
> will see
> + * the timer has expired when entering the guest.
> + */
> + kvm_vcpu_kick(vcpu);
> }
>
> static enum hrtimer_restart kvm_timer_expire(struct hrtimer *hrt)
> @@ -102,6 +111,21 @@ static enum hrtimer_restart
> kvm_timer_expire(struct hrtimer *hrt) return HRTIMER_NORESTART;
> }
>
> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
> +{
> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> + cycle_t cval, now;
> +
> + if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
> + !(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
> + return false;
> +
> + cval = timer->cntv_cval;
> + now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> +
> + return cval <= now;
> +}
> +
> /**
> * kvm_timer_flush_hwstate - prepare to move the virt timer to the
> cpu
> * @vcpu: The vcpu pointer
> @@ -119,6 +143,13 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu
> *vcpu)
>* populate the CPU timer again.
>*/
> timer_disarm(timer);
> +
> + /*
> + * If the timer expired while we were not scheduled, now is
> the time
> + * to inject it.
> + */
> + if (kvm_timer_should_fire(vcpu))
> + kvm_timer_inject_irq(vcpu);
> }
>
> /**
> @@ -134,16 +165,9 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu
> *vcpu) cycle_t cval, now;
> u64 ns;
>
> - if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
> - !(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
> - return;
> -
> - cval = timer->cntv_cval;
> - now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
> -
>
[PATCH] x86-64: no need to fix up physical addresses if they are correct
If kernel doesn't use kASLR and runned on the same address that was compiled to run, %rbp will be zero and no need to fix physical addresses in the page tables. Signed-off-by: Alexander Kuleshov --- arch/x86/kernel/head_64.S | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 6fd514d9..c0127bc 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -86,6 +86,14 @@ startup_64: jnz bad_address /* +* We have no need to fixup the physical addresses in the page tables +* if there is no difference between the address where kernel compiled +* to run and the actual address where kernel running at. +*/ + cmpq $0x0, %rbp + je 1f + + /* * Fixup the physical addresses in the page table */ addq%rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip) @@ -95,6 +103,7 @@ startup_64: addq%rbp, level2_fixmap_pgt + (506*8)(%rip) +1: /* * Set up the identity mapping for the switchover. These * entries should *NOT* have the global bit set! This also -- 2.3.1.167.g7f4ba4b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] arm/arm64: KVM: Keep elrsr/aisr in sync with software model
On Wed, 25 Feb 2015 15:36:22 +
Alex Bennée wrote:
> From: Christoffer Dall
>
> There is an interesting bug in the vgic code, which manifests itself
> when the KVM run loop has a signal pending or needs a vmid generation
> rollover after having disabled interrupts but before actually
> switching to the guest.
>
> In this case, we flush the vgic as usual, but we sync back the vgic
> state and exit to userspace before entering the guest. The
> consequence is that we will be syncing the list registers back to the
> software model using the GICH_ELRSR and GICH_EISR from the last
> execution of the guest, potentially overwriting a list register
> containing an interrupt.
>
> This showed up during migration testing where we would capture a state
> where the VM has masked the arch timer but there were no interrupts,
> resulting in a hung test.
>
> Cc: Marc Zyngier
> Reported-by: Alex Bennee
> Signed-off-by: Christoffer Dall
> Signed-off-by: Alex Bennée
Looks OK to me.
Acked-by: Marc Zyngier
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 7042251..e2a676e 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -114,6 +114,7 @@ struct vgic_ops {
> void(*sync_lr_elrsr)(struct kvm_vcpu *, int, struct
> vgic_lr); u64 (*get_elrsr)(const struct kvm_vcpu *vcpu);
> u64 (*get_eisr)(const struct kvm_vcpu *vcpu);
> + void(*clear_eisr)(struct kvm_vcpu *vcpu);
> u32 (*get_interrupt_status)(const struct kvm_vcpu
> *vcpu); void (*enable_underflow)(struct kvm_vcpu *vcpu);
> void(*disable_underflow)(struct kvm_vcpu *vcpu);
> diff --git a/virt/kvm/arm/vgic-v2.c b/virt/kvm/arm/vgic-v2.c
> index a0a7b5d..f9b9c7c 100644
> --- a/virt/kvm/arm/vgic-v2.c
> +++ b/virt/kvm/arm/vgic-v2.c
> @@ -72,6 +72,8 @@ static void vgic_v2_sync_lr_elrsr(struct kvm_vcpu
> *vcpu, int lr, {
> if (!(lr_desc.state & LR_STATE_MASK))
> vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr |= (1ULL <<
> lr);
> + else
> + vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr &= ~(1ULL <<
> lr); }
>
> static u64 vgic_v2_get_elrsr(const struct kvm_vcpu *vcpu)
> @@ -84,6 +86,11 @@ static u64 vgic_v2_get_eisr(const struct kvm_vcpu
> *vcpu) return vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr;
> }
>
> +static void vgic_v2_clear_eisr(struct kvm_vcpu *vcpu)
> +{
> + vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr = 0;
> +}
> +
> static u32 vgic_v2_get_interrupt_status(const struct kvm_vcpu *vcpu)
> {
> u32 misr = vcpu->arch.vgic_cpu.vgic_v2.vgic_misr;
> @@ -148,6 +155,7 @@ static const struct vgic_ops vgic_v2_ops = {
> .sync_lr_elrsr = vgic_v2_sync_lr_elrsr,
> .get_elrsr = vgic_v2_get_elrsr,
> .get_eisr = vgic_v2_get_eisr,
> + .clear_eisr = vgic_v2_clear_eisr,
> .get_interrupt_status = vgic_v2_get_interrupt_status,
> .enable_underflow = vgic_v2_enable_underflow,
> .disable_underflow = vgic_v2_disable_underflow,
> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
> index 3a62d8a..dff0602 100644
> --- a/virt/kvm/arm/vgic-v3.c
> +++ b/virt/kvm/arm/vgic-v3.c
> @@ -104,6 +104,8 @@ static void vgic_v3_sync_lr_elrsr(struct kvm_vcpu
> *vcpu, int lr, {
> if (!(lr_desc.state & LR_STATE_MASK))
> vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr |= (1U << lr);
> + else
> + vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr &= ~(1U <<
> lr); }
>
> static u64 vgic_v3_get_elrsr(const struct kvm_vcpu *vcpu)
> @@ -116,6 +118,11 @@ static u64 vgic_v3_get_eisr(const struct
> kvm_vcpu *vcpu) return vcpu->arch.vgic_cpu.vgic_v3.vgic_eisr;
> }
>
> +static void vgic_v3_clear_eisr(struct kvm_vcpu *vcpu)
> +{
> + vcpu->arch.vgic_cpu.vgic_v3.vgic_eisr = 0;
> +}
> +
> static u32 vgic_v3_get_interrupt_status(const struct kvm_vcpu *vcpu)
> {
> u32 misr = vcpu->arch.vgic_cpu.vgic_v3.vgic_misr;
> @@ -192,6 +199,7 @@ static const struct vgic_ops vgic_v3_ops = {
> .sync_lr_elrsr = vgic_v3_sync_lr_elrsr,
> .get_elrsr = vgic_v3_get_elrsr,
> .get_eisr = vgic_v3_get_eisr,
> + .clear_eisr = vgic_v3_clear_eisr,
> .get_interrupt_status = vgic_v3_get_interrupt_status,
> .enable_underflow = vgic_v3_enable_underflow,
> .disable_underflow = vgic_v3_disable_underflow,
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 3b4ded2..3690c1e 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -980,6 +980,11 @@ static inline u64 vgic_get_eisr(struct kvm_vcpu
> *vcpu) return vgic_ops->get_eisr(vcpu);
> }
>
> +static inline void vgic_clear_eisr(struct kvm_vcpu *vcpu)
> +{
> + vgic_ops->clear_eisr(vcpu);
> +}
> +
> static inline u32 vgic_get_interrupt_status(struct kvm_vcpu *vcpu)
> {
> return vgic_ops->get_interrupt_status(vcpu);
> @@ -1019,6 +1024,7 @@ static void vgic_retire_lr(int lr_nr, int irq,
> struct kvm_vcpu *vcpu) vgic
Re: [PATCH] x86-64: no need to fix up physical addresses if they are correct
On Sat, Feb 28, 2015 at 07:34:20PM +0600, Alexander Kuleshov wrote: > If kernel doesn't use kASLR and runned on the same address that was > compiled to run, %rbp will be zero and no need to fix physical addresses > in the page tables. > > Signed-off-by: Alexander Kuleshov > --- > arch/x86/kernel/head_64.S | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > index 6fd514d9..c0127bc 100644 > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -86,6 +86,14 @@ startup_64: > jnz bad_address > > /* > + * We have no need to fixup the physical addresses in the page tables > + * if there is no difference between the address where kernel compiled > + * to run and the actual address where kernel running at. > + */ > + cmpq $0x0, %rbp > + je 1f No thanks - this is saving 4 ADDs which probably execute even in parallel on modern out-of-order x86, for the price of more code in asm which people would have to spend mental energy on in the future without any apparent gain. If you really want to help out with kernel development, I'd suggest you try fixing real bugs. You could read lkml and try to understand and debug the issues people are reporting, get a box and start testing linux-next every day and search the net for kernelnewbies (IRC channel etc) for things to do. Another great exercise is building randconfigs and trying to boot them with kvm and see what splats happen - believe me, lots of them. I sincerely hope that helps. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: change mm_advise_free to clear page dirty
On Fri, Feb 27, 2015 at 10:37:14PM +0900, Minchan Kim wrote:
> On Fri, Feb 27, 2015 at 03:50:29PM +0800, Wang, Yalin wrote:
> > > -Original Message-
> > > From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan Kim
> > > Sent: Friday, February 27, 2015 2:44 PM
> > > To: Wang, Yalin
> > > Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
> > > m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
> > > Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
> > >
> > > On Fri, Feb 27, 2015 at 01:48:48PM +0800, Wang, Yalin wrote:
> > > > > -Original Message-
> > > > > From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan
> > > Kim
> > > > > Sent: Friday, February 27, 2015 1:28 PM
> > > > > To: Wang, Yalin
> > > > > Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
> > > > > m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
> > > > > Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Fri, Feb 27, 2015 at 11:37:18AM +0800, Wang, Yalin wrote:
> > > > > > This patch add ClearPageDirty() to clear AnonPage dirty flag,
> > > > > > the Anonpage mapcount must be 1, so that this page is only used by
> > > > > > the current process, not shared by other process like fork().
> > > > > > if not clear page dirty for this anon page, the page will never be
> > > > > > treated as freeable.
> > > > >
> > > > > In case of anonymous page, it has PG_dirty when VM adds it to
> > > > > swap cache and clear it in clear_page_dirty_for_io. That's why
> > > > > I added ClearPageDirty if we found it in swapcache.
> > > > > What case am I missing? It would be better to understand if you
> > > > > describe specific scenario.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > >
> > > > > > Signed-off-by: Yalin Wang
> > > > > > ---
> > > > > > mm/madvise.c | 15 +--
> > > > > > 1 file changed, 5 insertions(+), 10 deletions(-)
> > > > > >
> > > > > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > > > > index 6d0fcb8..257925a 100644
> > > > > > --- a/mm/madvise.c
> > > > > > +++ b/mm/madvise.c
> > > > > > @@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
> > > > > unsigned long addr,
> > > > > > continue;
> > > > > >
> > > > > > page = vm_normal_page(vma, addr, ptent);
> > > > > > - if (!page)
> > > > > > + if (!page || !PageAnon(page) || !trylock_page(page))
> > > > > > continue;
> > > > > >
> > > > > > if (PageSwapCache(page)) {
> > > > > > - if (!trylock_page(page))
> > > > > > + if (!try_to_free_swap(page))
> > > > > > continue;
> > > > > > -
> > > > > > - if (!try_to_free_swap(page)) {
> > > > > > - unlock_page(page);
> > > > > > - continue;
> > > > > > - }
> > > > > > -
> > > > > > - ClearPageDirty(page);
> > > > > > - unlock_page(page);
> > > > > > }
> > > > > >
> > > > > > + if (page_mapcount(page) == 1)
> > > > > > + ClearPageDirty(page);
> > > > > > + unlock_page(page);
> > > > > > /*
> > > > > > * Some of architecture(ex, PPC) don't update TLB
> > > > > > * with set_pte_at and tlb_remove_tlb_entry so for
> > > > > > --
> > > > Yes, for page which is in SwapCache, it is correct,
> > > > But for anon page which is not in SwapCache, it is always
> > > > PageDirty(), so we should also clear dirty bit to make it freeable,
> > >
> > > No. Every anon page starts from !PageDirty and it has PG_dirty
> > > only when it's addeded into swap cache. If vm_swap_full turns on,
> > > a page in swap cache could have PG_dirty via try_to_free_swap again.
> >
> > mmm..
> > sometimes you can see an anon page PageDirty(), but it is not in swapcache,
> > for example, handle_pte_fault()-->do_swap_page()-->try_to_free_swap(),
> > at this time, the page is deleted from swapcache and is marked PageDirty(),
>
> That's what I missed. It's clear and would be simple patch so
> could you send a patch to fix this issue with detailed description
> like above?
>
> >
> >
> > > So, Do you have concern about swapped-out pages when MADV_FREE is
> > > called? If so, please look at my patch.
> > >
> > > https://lkml.org/lkml/2015/2/25/43
> > >
> > > It will zap the swapped out page. So, this is not a issue any more?
> > >
> > > >
> > > > Another problem is that if an anon page is shared by more than one
> > > process,
> > > > This happened when fork(), the anon page will be copy on write,
> > > > In this case, we should not clear page dirty,
> > > > This is not correct for other process which don't call MADV_FREE
> > > > syscall.
> > >
> > > You mean we shouldn't inherit MADV_FREE attrib
Re: [RFC] mm: change mm_advise_free to clear page dirty
On Sat, Feb 28, 2015 at 10:11:13AM +0800, Wang, Yalin wrote:
> > -Original Message-
> > From: Michal Hocko [mailto:msts...@gmail.com] On Behalf Of Michal Hocko
> > Sent: Saturday, February 28, 2015 5:03 AM
> > To: Wang, Yalin
> > Cc: 'Minchan Kim'; Andrew Morton; linux-kernel@vger.kernel.org; linux-
> > m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
> > Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
> >
> > On Fri 27-02-15 11:37:18, Wang, Yalin wrote:
> > > This patch add ClearPageDirty() to clear AnonPage dirty flag,
> > > the Anonpage mapcount must be 1, so that this page is only used by
> > > the current process, not shared by other process like fork().
> > > if not clear page dirty for this anon page, the page will never be
> > > treated as freeable.
> >
> > Very well spotted! I haven't noticed that during the review.
> >
> > > Signed-off-by: Yalin Wang
> > > ---
> > > mm/madvise.c | 15 +--
> > > 1 file changed, 5 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > index 6d0fcb8..257925a 100644
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
> > unsigned long addr,
> > > continue;
> > >
> > > page = vm_normal_page(vma, addr, ptent);
> > > - if (!page)
> > > + if (!page || !PageAnon(page) || !trylock_page(page))
> > > continue;
> >
> > PageAnon check seems to be redundant because we are not allowing
> > MADV_FREE on any !anon private mappings AFAIR.
> I only see this check:
> /* MADV_FREE works for only anon vma at the moment */
> if (vma->vm_file)
> return -EINVAL;
>
> but for file private map, there are also AnonPage sometimes, do we need change
> to like this:
> if (vma->vm_flags & VM_SHARED)
> return -EINVAL;
I couldn't understand your point. In this stage, we intentionally
disabled madvise_free on file mapped area(AFAIRC, some guys tried
it long time ago but it had many issues so dropped).
So, how can file-private mmaped can reach this code?
Could you elaborate it more about that why we need PageAnon check
in here?
> > >
> > > if (PageSwapCache(page)) {
> > > - if (!trylock_page(page))
> > > + if (!try_to_free_swap(page))
> > > continue;
> >
> > You need to unlock the page here.
> Good spot.
>
> > > -
> > > - if (!try_to_free_swap(page)) {
> > > - unlock_page(page);
> > > - continue;
> > > - }
> > > -
> > > - ClearPageDirty(page);
> > > - unlock_page(page);
> > > }
> > >
> > > + if (page_mapcount(page) == 1)
> > > + ClearPageDirty(page);
> >
> > Please add a comment about why we need to ClearPageDirty even
> > !PageSwapCache. Anon pages are usually not marked dirty AFAIR. The
> > reason seem to be racing try_to_free_swap which sets the page that way
> > (although I do not seem to remember why are we doing that in the first
> > place...)
> >
> Use page_mapcount to judge if a page can be clear dirty flag seems
> Not a very good solution, that is because we don't know how many
> ptes are share this page, I am thinking if there is some good solution
> For shared AnonPage.
>
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] HID: uclogic: actually invert the in-range bit for huion tablets only
On 02/26/2015 08:57 PM, Benjamin Tissoires wrote: This hack is only needed for Huion tablets. It does not seem to have any effect on the other tablets handled by this device right now, but it's better to check for the product id sooner than discovering that we have messed up one tablet later. Signed-off-by: Benjamin Tissoires --- New in v2 drivers/hid/hid-uclogic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c index f44e72b..5f5c16e 100644 --- a/drivers/hid/hid-uclogic.c +++ b/drivers/hid/hid-uclogic.c @@ -930,7 +930,8 @@ static int uclogic_raw_event(struct hid_device *hdev, struct hid_report *report, struct usb_interface *intf = to_usb_interface(hdev->dev.parent); /* If this is a pen input report */ - if (intf->cur_altsetting->desc.bInterfaceNumber == 0 && + if (hdev->product == USB_DEVICE_ID_HUION_TABLET && + intf->cur_altsetting->desc.bInterfaceNumber == 0 && report->type == HID_INPUT_REPORT && report->id == 0x07 && size >= 2) /* Invert the in-range bit */ Right, I completely forgot about this. That's why it's important to put these things out for testing. However, this should be inverted not just for Huion tablets, but rather for all "enabled" tablets. The UC-Logic TWHA60 v3 inverts that bit as well when enabled, IIRC. We can filter enabled tablets by drvdata->rdesc != NULL, or add an explicit flag. Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: bcm-keypad: Add Broadcom keypad controller
On Thu, 2015-02-26 at 08:08 -0800, Scott Branden wrote:
> Add driver for Broadcom's keypad controller.
>
> Broadcom Keypad controller is used to interface a SoC with a matrix-type
> keypad device. The keypad controller supports multiple row and column lines.
> A key can be placed at each intersection of a unique row and a unique column.
> The keypad controller can sense a key-press and key-release and report the
> event using a interrupt to the cpu.
>
> Reviewed-by: Ray Jui
> Signed-off-by: Scott Branden
> ---
> drivers/input/keyboard/Kconfig | 10 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/bcm-keypad.c | 464
>
> 3 files changed, 475 insertions(+)
> create mode 100644 drivers/input/keyboard/bcm-keypad.c
License nit follows.
> diff --git a/drivers/input/keyboard/bcm-keypad.c
> b/drivers/input/keyboard/bcm-keypad.c
> new file mode 100644
> index 000..f229ac0
> --- /dev/null
> +++ b/drivers/input/keyboard/bcm-keypad.c
> @@ -0,0 +1,464 @@
> +/*
> + * Copyright (C) 2014 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
This states that the license is GPL v2 only.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
[...]
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: record task name which froze superblock
On Fri, Feb 20, 2015 at 01:15:22PM +0100, Jan Kara wrote:
> On Fri 20-02-15 14:42:29, Alexey Dobriyan wrote:
> > On Wed, Feb 18, 2015 at 12:13 PM, Jan Kara wrote:
> > >> > > --- a/fs/ioctl.c
> > >> > > +++ b/fs/ioctl.c
> > >> > > @@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd,
> > >> > > struct file *filp,
> > >> > > static int ioctl_fsfreeze(struct file *filp)
> > >> > > {
> > >> > > struct super_block *sb = file_inode(filp)->i_sb;
> > >> > > + int rv;
> > >> > >
> > >> > > if (!capable(CAP_SYS_ADMIN))
> > >> > > return -EPERM;
> > >> > > @@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
> > >> > > return -EOPNOTSUPP;
> > >> > >
> > >> > > /* Freeze */
> > >> > > - if (sb->s_op->freeze_super)
> > >> > > - return sb->s_op->freeze_super(sb);
> > >> > > - return freeze_super(sb);
> > >> > > + if (sb->s_op->freeze_super) {
> > >> > > + rv = sb->s_op->freeze_super(sb);
> > >> > > + if (rv == 0)
> > >> > > + get_task_comm(sb->s_writers.freeze_comm, current);
> > >> > > + } else
> > >> > > + rv = freeze_super(sb);
> > >> > > + return rv;
> > >> > Why don't you just set the name in ioctl_fsfreeze() in both cases?
> > >>
> > >> There are users of freeze_super() in GFS2 unless I'm misreading code.
> > > Yes, there are. The call in fs/gfs2/glops.c is in a call path from
> > > ->freeze_super() handler for GFS2 so that one is handled in
> > > ioctl_fsfreeze() anyway. The call in fs/gfs2/sys.c is a way to freeze
> > > filesystem via sysfs (dunno why GFS2 has to invent its own thing and ioctl
> > > isn't enough). Steven? So having the logic in ioctl_fsfreeze(),
> > > freeze_bdev() and freeze_store() in gfs2 seems to be enough.
> >
> > Jan, my logic is as follows.
> >
> > Recording freezer task name is not filesystem/device specific and
> > thus should be done in generic code. So no changes in GFS2.
> >
> > freeze_super() is generic counterpart to filesystem/device
> > specific ->freeze_super() hook, look how they are paired.
> > It should recore freezer task name, so any future user
> > will not forget to do the same.
> >
> > So it's in ioctl_fsfreeze(), freeze_bdev() and freeze_super().
> Well, but this stores the name in two different levels - once in the top
> level (ioctl_fsfreeze(), freeze_bdev()) and once in a place called from
> there (freeze_super()). That just seems wrong to me. You can just record
> the frozen process in freeze_super() and mandate that if someone manages to
> freeze the fs without calling freeze_super() from his ->freeze_super()
> handler (currently there isn't such filesystem), he is also responsible for
> setting freezer name... Hmm?
Jan I understand you. But I find stranger that GFS will have to record
freezer name.
I'm sending v3, hopefully final.
> > >> > > --- a/include/linux/fs.h
> > >> > > +++ b/include/linux/fs.h
> > >> > > @@ -1221,6 +1221,8 @@ struct sb_writers {
> > >> > > int frozen; /* Is sb frozen? */
> > >> > > wait_queue_head_t wait_unfrozen; /* queue for waiting for
> > >> > > sb to be thawed */
> > >> > > + /* who froze superblock */
> > >> > > + charfreeze_comm[16];
> > >> > Here should be TASK_COMM_LEN, shouldn't it?
> > >>
> > >> It will pull sched.h, dunno if we care about headers anymore.
> > > That's not ideal but IMHO better than having the value hardcoded here.
> > > That is pretty fragile - i.e. think what happens when someone decides to
> > > increase TASK_COMM_LEN...
> >
> > TASK_COMM_LEN is userspace ABI via at least prctl(PR_SET_NAME).
> > I can formally move it to include/uapi/linux/sched.h.
> > This allows to not drag sched.h into fs.h for one tiny define.
> OK, moving the definition would be preferable to me (and IMO also a
> cleanup).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: record task name which froze superblock
Freezing and thawing are separate system calls, task which is supposed
to thaw filesystem/superblock can disappear due to crash or not thaw
due to a bug. At least record task name (we can't take task_struct
reference) to make support engineer's life easier.
Hopefully 16 bytes per superblock isn't much.
TASK_COMM_LEN definition (which is userspace ABI, see prctl(PR_SET_NAME)) is
moved to userspace exported header to not drag sched.h into every fs.h
inclusion.
Signed-off-by: Alexey Dobriyan
---
fs/block_dev.c | 12
fs/ioctl.c | 22 --
fs/super.c |2 ++
include/linux/fs.h |6 ++
include/linux/sched.h |3 ---
include/uapi/linux/sched.h |3 +++
6 files changed, 35 insertions(+), 13 deletions(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -227,9 +227,11 @@ struct super_block *freeze_bdev(struct block_device *bdev)
sb = get_active_super(bdev);
if (!sb)
goto out;
- if (sb->s_op->freeze_super)
+ if (sb->s_op->freeze_super) {
error = sb->s_op->freeze_super(sb);
- else
+ if (error == 0)
+ get_task_comm(sb->s_writers.freeze_comm, current);
+ } else
error = freeze_super(sb);
if (error) {
deactivate_super(sb);
@@ -267,9 +269,11 @@ int thaw_bdev(struct block_device *bdev, struct
super_block *sb)
if (!sb)
goto out;
- if (sb->s_op->thaw_super)
+ if (sb->s_op->thaw_super) {
error = sb->s_op->thaw_super(sb);
- else
+ if (error == 0)
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
+ } else
error = thaw_super(sb);
if (error) {
bdev->bd_fsfreeze_count++;
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file
*filp,
static int ioctl_fsfreeze(struct file *filp)
{
struct super_block *sb = file_inode(filp)->i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
return -EOPNOTSUPP;
/* Freeze */
- if (sb->s_op->freeze_super)
- return sb->s_op->freeze_super(sb);
- return freeze_super(sb);
+ if (sb->s_op->freeze_super) {
+ rv = sb->s_op->freeze_super(sb);
+ if (rv == 0)
+ get_task_comm(sb->s_writers.freeze_comm, current);
+ } else
+ rv = freeze_super(sb);
+ return rv;
}
static int ioctl_fsthaw(struct file *filp)
{
struct super_block *sb = file_inode(filp)->i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
/* Thaw */
- if (sb->s_op->thaw_super)
- return sb->s_op->thaw_super(sb);
- return thaw_super(sb);
+ if (sb->s_op->thaw_super) {
+ rv = sb->s_op->thaw_super(sb);
+ if (rv == 0)
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
+ } else
+ rv = thaw_super(sb);
+ return rv;
}
/*
--- a/fs/super.c
+++ b/fs/super.c
@@ -1351,6 +1351,7 @@ int freeze_super(struct super_block *sb)
* sees write activity when frozen is set to SB_FREEZE_COMPLETE.
*/
sb->s_writers.frozen = SB_FREEZE_COMPLETE;
+ get_task_comm(sb->s_writers.freeze_comm, current);
up_write(&sb->s_umount);
return 0;
}
@@ -1387,6 +1388,7 @@ int thaw_super(struct super_block *sb)
out:
sb->s_writers.frozen = SB_UNFROZEN;
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
smp_wmb();
wake_up(&sb->s_writers.wait_unfrozen);
deactivate_locked_super(sb);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -33,6 +33,7 @@
#include
#include
+#include
struct backing_dev_info;
struct export_operations;
@@ -1217,6 +1218,11 @@ struct sb_writers {
int frozen; /* Is sb frozen? */
wait_queue_head_t wait_unfrozen; /* queue for waiting for
sb to be thawed */
+ /*
+* who froze superblock
+* write-only field for traces in crashdump
+*/
+ charfreeze_comm[TASK_COMM_LEN];
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map lock_map[SB_FREEZE_LEVELS];
#endif
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -303,9 +303,6 @@ extern char ___assert_task_state[1 - 2*!!(
#endif
-/* Task command name length */
-#define TASK_COMM_LEN 16
-
#include
/*
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -49,4 +49,7 @@
*/
#define SCHED_FLAG_RESET_ON_FORK 0x01
+/* Task command name length */
+#define TASK_COMM_LEN 16
[PATCH] Staging: vt6655: fix C99 comments
From: Matteo Semenzato
This patch fixes the following warning:
do not use C99 // comments
Signed-off-by: Matteo Semenzato
---
drivers/staging/vt6655/mac.c | 82 ++--
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index 3653a2b..8048b32 100644
--- a/drivers/staging/vt6655/mac.c
+++ b/drivers/staging/vt6655/mac.c
@@ -141,7 +141,7 @@ bool MACbIsIntDisable(void __iomem *dwIoBase)
*/
void MACvSetShortRetryLimit(void __iomem *dwIoBase, unsigned char byRetryLimit)
{
- // set SRT
+ /* set SRT */
VNSvOutPortB(dwIoBase + MAC_REG_SRT, byRetryLimit);
}
@@ -162,7 +162,7 @@ void MACvSetShortRetryLimit(void __iomem *dwIoBase,
unsigned char byRetryLimit)
*/
void MACvSetLongRetryLimit(void __iomem *dwIoBase, unsigned char byRetryLimit)
{
- // set LRT
+ /* set LRT */
VNSvOutPortB(dwIoBase + MAC_REG_LRT, byRetryLimit);
}
@@ -186,7 +186,7 @@ void MACvSetLoopbackMode(void __iomem *dwIoBase, unsigned
char byLoopbackMode)
ASSERT(byLoopbackMode < 3);
byLoopbackMode <<= 6;
- // set TCR
+ /* set TCR */
VNSvInPortB(dwIoBase + MAC_REG_TEST, &byOrgValue);
byOrgValue = byOrgValue & 0x3F;
byOrgValue = byOrgValue | byLoopbackMode;
@@ -210,13 +210,13 @@ void MACvSaveContext(void __iomem *dwIoBase, unsigned
char *pbyCxtBuf)
{
int ii;
- // read page0 register
+ /* read page0 register */
for (ii = 0; ii < MAC_MAX_CONTEXT_SIZE_PAGE0; ii++)
VNSvInPortB((dwIoBase + ii), (pbyCxtBuf + ii));
MACvSelectPage1(dwIoBase);
- // read page1 register
+ /* read page1 register */
for (ii = 0; ii < MAC_MAX_CONTEXT_SIZE_PAGE1; ii++)
VNSvInPortB((dwIoBase + ii), (pbyCxtBuf +
MAC_MAX_CONTEXT_SIZE_PAGE0 + ii));
@@ -242,27 +242,27 @@ void MACvRestoreContext(void __iomem *dwIoBase, unsigned
char *pbyCxtBuf)
int ii;
MACvSelectPage1(dwIoBase);
- // restore page1
+ /* restore page1 */
for (ii = 0; ii < MAC_MAX_CONTEXT_SIZE_PAGE1; ii++)
VNSvOutPortB((dwIoBase + ii), *(pbyCxtBuf +
MAC_MAX_CONTEXT_SIZE_PAGE0 + ii));
MACvSelectPage0(dwIoBase);
- // restore RCR,TCR,IMR...
+ /* restore RCR,TCR,IMR... */
for (ii = MAC_REG_RCR; ii < MAC_REG_ISR; ii++)
VNSvOutPortB(dwIoBase + ii, *(pbyCxtBuf + ii));
- // restore MAC Config.
+ /* restore MAC Config. */
for (ii = MAC_REG_LRT; ii < MAC_REG_PAGE1SEL; ii++)
VNSvOutPortB(dwIoBase + ii, *(pbyCxtBuf + ii));
VNSvOutPortB(dwIoBase + MAC_REG_CFG, *(pbyCxtBuf + MAC_REG_CFG));
- // restore PS Config.
+ /* restore PS Config. */
for (ii = MAC_REG_PSCFG; ii < MAC_REG_BBREGCTL; ii++)
VNSvOutPortB(dwIoBase + ii, *(pbyCxtBuf + ii));
- // restore CURR_RX_DESC_ADDR, CURR_TX_DESC_ADDR
+ /* restore CURR_RX_DESC_ADDR, CURR_TX_DESC_ADDR */
VNSvOutPortD(dwIoBase + MAC_REG_TXDMAPTR0, *(unsigned long *)(pbyCxtBuf
+ MAC_REG_TXDMAPTR0));
VNSvOutPortD(dwIoBase + MAC_REG_AC0DMAPTR, *(unsigned long *)(pbyCxtBuf
+ MAC_REG_AC0DMAPTR));
VNSvOutPortD(dwIoBase + MAC_REG_BCNDMAPTR, *(unsigned long *)(pbyCxtBuf
+ MAC_REG_BCNDMAPTR));
@@ -290,7 +290,7 @@ bool MACbSoftwareReset(void __iomem *dwIoBase)
unsigned char byData;
unsigned short ww;
- // turn on HOSTCR_SOFTRST, just write 0x01 to reset
+ /* turn on HOSTCR_SOFTRST, just write 0x01 to reset */
VNSvOutPortB(dwIoBase + MAC_REG_HOSTCR, 0x01);
for (ww = 0; ww < W_MAX_TIMEOUT; ww++) {
@@ -321,15 +321,15 @@ bool MACbSafeSoftwareReset(void __iomem *dwIoBase)
unsigned char
abyTmpRegData[MAC_MAX_CONTEXT_SIZE_PAGE0+MAC_MAX_CONTEXT_SIZE_PAGE1];
bool bRetVal;
- // PATCH
- // save some important register's value, then do
- // reset, then restore register's value
-
- // save MAC context
+ /* PATCH
+* save some important register's value, then do
+* reset, then restore register's value
+*/
+ /* save MAC context */
MACvSaveContext(dwIoBase, abyTmpRegData);
- // do reset
+ /* do reset */
bRetVal = MACbSoftwareReset(dwIoBase);
- // restore MAC context, except CR0
+ /* restore MAC context, except CR0 */
MACvRestoreContext(dwIoBase, abyTmpRegData);
return bRetVal;
@@ -354,9 +354,9 @@ bool MACbSafeRxOff(void __iomem *dwIoBase)
unsigned long dwData;
unsigned char byData;
- // turn off wow temp for turn off Rx safely
+ /* turn off wow temp for turn off Rx safely */
- // Clear RX DMA0,1
+ /* Clear RX DMA0,1 */
VNSvOutPortD(dwIoBase + MAC_REG_RXDMACTL0, DMACTL_CLRRUN);
VNSvOutPortD(dwIoBase + MAC_REG_RXDMACTL1, DMACTL_C
[PATCH] Staging: fbtft: fix coding style errors
From: Matteo Semenzato
This patch fixes the following error:
space required after that ';'
Signed-off-by: Matteo Semenzato
---
drivers/staging/fbtft/fbtft_device.c | 68 ++--
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft_device.c
b/drivers/staging/fbtft/fbtft_device.c
index b9f4c30..23d46fe 100644
--- a/drivers/staging/fbtft/fbtft_device.c
+++ b/drivers/staging/fbtft/fbtft_device.c
@@ -61,7 +61,7 @@ MODULE_PARM_DESC(mode, "SPI mode (override device default)");
static char *gpios;
module_param(gpios, charp, 0);
MODULE_PARM_DESC(gpios,
-"List of gpios. Comma separated with the form: reset:23,dc:24 " \
+"List of gpios. Comma separated with the form: reset:23, dc:24 " \
"(when overriding the default, all gpios must be specified)");
static unsigned fps;
@@ -109,7 +109,7 @@ module_param_array(init, int, &init_num, 0);
MODULE_PARM_DESC(init, "Init sequence, used with the custom argument");
static unsigned long debug;
-module_param(debug, ulong , 0);
+module_param(debug, ulong, 0);
MODULE_PARM_DESC(debug,
"level: 0-7 (the remaining 29 bits is for advanced usage)");
@@ -136,43 +136,43 @@ static void adafruit18_green_tab_set_addr_win(struct
fbtft_par *par,
"03 1d 07 06 2E 2C 29 2D 2E 2E 37 3F 00 00 02 10"
static int hy28b_init_sequence[] = {
- -1,0x00e7,0x0010,-1,0x,0x0001,-1,0x0001,0x0100,-1,0x0002,0x0700,
- -1,0x0003,0x1030,-1,0x0004,0x,-1,0x0008,0x0207,-1,0x0009,0x,
- -1,0x000a,0x,-1,0x000c,0x0001,-1,0x000d,0x,-1,0x000f,0x,
- -1,0x0010,0x,-1,0x0011,0x0007,-1,0x0012,0x,-1,0x0013,0x,
- -2,50,-1,0x0010,0x1590,-1,0x0011,0x0227,-2,50,-1,0x0012,0x009c,-2,50,
- -1,0x0013,0x1900,-1,0x0029,0x0023,-1,0x002b,0x000e,-2,50,
- -1,0x0020,0x,-1,0x0021,0x,-2,50,-1,0x0050,0x,
- -1,0x0051,0x00ef,-1,0x0052,0x,-1,0x0053,0x013f,-1,0x0060,0xa700,
- -1,0x0061,0x0001,-1,0x006a,0x,-1,0x0080,0x,-1,0x0081,0x,
- -1,0x0082,0x,-1,0x0083,0x,-1,0x0084,0x,-1,0x0085,0x,
- -1,0x0090,0x0010,-1,0x0092,0x,-1,0x0093,0x0003,-1,0x0095,0x0110,
- -1,0x0097,0x,-1,0x0098,0x,-1,0x0007,0x0133,-1,0x0020,0x,
- -1,0x0021,0x,-2,100,-3 };
+ -1, 0x00e7, 0x0010, -1, 0x, 0x0001, -1, 0x0001, 0x0100, -1, 0x0002,
0x0700,
+ -1, 0x0003, 0x1030, -1, 0x0004, 0x, -1, 0x0008, 0x0207, -1, 0x0009,
0x,
+ -1, 0x000a, 0x, -1, 0x000c, 0x0001, -1, 0x000d, 0x, -1, 0x000f,
0x,
+ -1, 0x0010, 0x, -1, 0x0011, 0x0007, -1, 0x0012, 0x, -1, 0x0013,
0x,
+ -2, 50, -1, 0x0010, 0x1590, -1, 0x0011, 0x0227, -2, 50, -1, 0x0012,
0x009c, -2, 50,
+ -1, 0x0013, 0x1900, -1, 0x0029, 0x0023, -1, 0x002b, 0x000e, -2, 50,
+ -1, 0x0020, 0x, -1, 0x0021, 0x, -2, 50, -1, 0x0050, 0x,
+ -1, 0x0051, 0x00ef, -1, 0x0052, 0x, -1, 0x0053, 0x013f, -1, 0x0060,
0xa700,
+ -1, 0x0061, 0x0001, -1, 0x006a, 0x, -1, 0x0080, 0x, -1, 0x0081,
0x,
+ -1, 0x0082, 0x, -1, 0x0083, 0x, -1, 0x0084, 0x, -1, 0x0085,
0x,
+ -1, 0x0090, 0x0010, -1, 0x0092, 0x, -1, 0x0093, 0x0003, -1, 0x0095,
0x0110,
+ -1, 0x0097, 0x, -1, 0x0098, 0x, -1, 0x0007, 0x0133, -1, 0x0020,
0x,
+ -1, 0x0021, 0x, -2, 100, -3 };
#define HY28B_GAMMA \
"04 1F 4 7 7 0 7 7 6 0\n" \
"0F 00 1 7 4 0 0 0 6 7"
static int pitft_init_sequence[] = {
- -1,0x01,-2,5,-1,0x28,-1,0xEF,0x03,0x80,0x02,-1,0xCF,0x00,0xC1,0x30,
- -1,0xED,0x64,0x03,0x12,0x81,-1,0xE8,0x85,0x00,0x78,
- -1,0xCB,0x39,0x2C,0x00,0x34,0x02,-1,0xF7,0x20,-1,0xEA,0x00,0x00,
- -1,0xC0,0x23,-1,0xC1,0x10,-1,0xC5,0x3e,0x28,-1,0xC7,0x86,-1,0x3A,0x55,
- -1,0xB1,0x00,0x18,-1,0xB6,0x08,0x82,0x27,-1,0xF2,0x00,-1,0x26,0x01,
- -1,0xE0,0x0F,0x31,0x2B,0x0C,0x0E,0x08,0x4E,0xF1,0x37,0x07,0x10,0x03,
- 0x0E,0x09,0x00,-1,0xE1,0x00,0x0E,0x14,0x03,0x11,0x07,0x31,0xC1,0x48,
- 0x08,0x0F,0x0C,0x31,0x36,0x0F,-1,0x11,-2,100,-1,0x29,-2,20,-3 };
+ -1, 0x01, -2, 5, -1, 0x28, -1, 0xEF, 0x03, 0x80, 0x02, -1, 0xCF, 0x00,
0xC1, 0x30,
+ -1, 0xED, 0x64, 0x03, 0x12, 0x81, -1, 0xE8, 0x85, 0x00, 0x78,
+ -1, 0xCB, 0x39, 0x2C, 0x00, 0x34, 0x02, -1, 0xF7, 0x20, -1, 0xEA, 0x00,
0x00,
+ -1, 0xC0, 0x23, -1, 0xC1, 0x10, -1, 0xC5, 0x3e, 0x28, -1, 0xC7, 0x86,
-1, 0x3A, 0x55,
+ -1, 0xB1, 0x00, 0x18, -1, 0xB6, 0x08, 0x82, 0x27, -1, 0xF2, 0x00, -1,
0x26, 0x01,
+ -1, 0xE0, 0x0F, 0x31, 0x2B, 0x0C, 0x0E, 0x08, 0x4E, 0xF1, 0x37, 0x07,
0x10, 0x03,
+ 0x0E, 0x09, 0x00, -1, 0xE1, 0x00, 0x0E, 0x14, 0x03, 0x11, 0x07, 0x31,
0xC1, 0x48,
+ 0x08, 0x0F, 0x0C, 0x31, 0x36, 0x0F, -1, 0x11, -2, 100, -1, 0x29, -2,
20, -3 };
static int waveshare32b_init_sequence[] = {
- -1,0xCB,0x39,0x2C,0x00,0x34,0x02,-1,0xCF,0x00,0xC1,0x30,
- -1,0xE8,0x85,0x00,0x78,-1,0xEA,0x00,0x00,-1,0xED,
[PATCH] Staging: Octeon USB: Fix space prohibited between function name and open parenthesis
This patch fixes the following checkpatch.pl warning in
drivers/staging/octeon-usb/octeon-hcd.c
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Sean Darcy
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index 1daeb31..0408a12 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -412,7 +412,7 @@ struct octeon_hcd {
type c; \
while (1) { \
c.u32 = __cvmx_usb_read_csr32(usb, address);\
- if (c.s.field op (value)) { \
+ if (c.s.field op(value)) { \
result = 0; \
break; \
} else if (cvmx_get_cycle() > done) { \
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
