r then the supported phys addr width.
[1] Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A
Signed-off-by: Frantisek Hrbata
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 13 +
2 files changed, 17 insertions(+)
diff --git a/arch/x86/in
On Tue, Apr 02, 2013 at 11:48:34AM -0700, H. Peter Anvin wrote:
> On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
> >
> > diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> > index d8e8eef..39607c6 100644
> > --- a/arch/x86/include/asm/io.h
> >
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
> On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
> >
> > Hi, this is exactly what the patch is doing imho. Note that the
> > valid_phys_addr_range(), which is using the high_memory, is the same as the
> >
On Mon, Aug 26, 2013 at 02:56:04PM +0200, Peter Oberparleiter wrote:
> On 24.08.2013 21:12, Frantisek Hrbata wrote:
> > On Fri, Aug 23, 2013 at 05:15:19PM +0200, Peter Oberparleiter wrote:
> >> Also it is my understanding that there are some distribution-specific
> >>
On Mon, Aug 26, 2013 at 04:14:07PM +0200, Peter Oberparleiter wrote:
> On 24.08.2013 21:44, Frantisek Hrbata wrote:
> > On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
> >> On 23.08.2013 17:15, Peter Oberparleiter wrote:
> >>> On 23.08.2013
On Mon, Aug 26, 2013 at 02:45:10PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 23:00, Frantisek Hrbata wrote:
> > On Fri, Aug 23, 2013 at 05:12:19PM +0200, Peter Oberparleiter wrote:
> >> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> >>> The gcov in-memory
On Wed, Aug 28, 2013 at 03:46:05PM +0200, Peter Oberparleiter wrote:
> On 27.08.2013 15:34, Frantisek Hrbata wrote:
> > On Mon, Aug 26, 2013 at 04:14:07PM +0200, Peter Oberparleiter wrote:
> >> On 24.08.2013 21:44, Frantisek Hrbata wrote:
> >>> On Fri, Aug 23, 2
000400776>] 0x400775
Oct 2 11:24:02 amd-pence-01 kernel: RSP <7fff2d34da10>
Oct 2 11:24:02 amd-pence-01 kernel: ---[ end trace 8a123cd70049eebc ]---
-8<--
Please note the PTE value 8008000a0225.
Signed-off-by: F
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> > +
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory);
> > +}
> > +
&g
On Wed, Oct 02, 2013 at 11:36:09AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
> > On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> >> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> >>> +
> >>> +
On Wed, Sep 18, 2013 at 02:31:27PM -0700, Andrew Morton wrote:
> On Wed, 18 Sep 2013 14:27:05 -0700 Joe Perches wrote:
>
> > On Wed, 2013-09-18 at 14:22 -0700, Andrew Morton wrote:
> > > On Wed, 4 Sep 2013 16:42:54 +0200 Frantisek Hrbata
> > > wrote:
> > &
On Thu, Sep 19, 2013 at 11:04:16AM +0200, Peter Oberparleiter wrote:
> On 04.09.2013 16:42, Frantisek Hrbata wrote:
> > The gcov in-memory format changed in gcc 4.7. The biggest change, which
> > requires this special implementation, is that gcov_info no longer contains
> >
: Frantisek Hrbata
---
Documentation/gcov.txt | 4
kernel/gcov/Kconfig| 30 ++
kernel/gcov/Makefile | 32 +++-
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
index e7ca647
fn_info in gcov_info
- use vmalloc for counter values in gcov_info_dup
- use iter buffer for gcda
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 562 ++
2 files changed, 568 insertions(+)
create m
ray, but not both at the same time
Signed-off-by: Frantisek Hrbata
---
include/asm-generic/vmlinux.lds.h | 1 +
kernel/module.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 69732d2..c55d8d9 100
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115 ++
kernel/gcov/gcov.h
provided by Peter Oberparleiter. Detailed
description in patches.
Frantisek Hrbata (4):
gcov: move gcov structs definitions to a gcc version specific file
gcov: add support for gcc 4.7 gcov format
gcov: compile specific gcov implementation based on gcc version
kernel: add support for
On Fri, Sep 06, 2013 at 11:43:08AM +0930, Rusty Russell wrote:
> Frantisek Hrbata writes:
> > This adds the .init_array section as yet another section with constructors.
> > This
> > is needed because gcc could add __gcov_init calls to .init_array or .ctors
> > sectio
On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> Kyle McMartin writes:
> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> >> > > v2: - reuse mod->ctors for .init_array section for modules, because
> >> > > gcc uses
On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
> Frantisek Hrbata writes:
> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> >> Kyle McMartin writes:
> >> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> >
account that
even the core gcov structures, like gcov_info, could change. One part that could
be problematic is the addition of the .init_array section for constructors.
Tested with lcov and seems to be working fine, giving similar results as for the
older format.
Frantisek Hrbata (4):
gcov: move
code and to
introduce simple helpers for accessing data inside gcov_info.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 26 ++--
kernel/gcov/fs.c | 27 ++--
kernel/gcov/gcc_3_4.c | 115 ++
kernel/gcov/gcov.h
. Now each
gcov_fn_info contans it's counters, which makes things a little bit easier.
This is heavily based on the previous gcc_3_4.c implementation.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov/base.c| 6 +
kernel/gcov/gcc_4_7.c | 612 +++
Compile the correct gcov implementation file for a specific gcc version. In
the future, if another file is added, the conditions will need to be somehow
adjusted to if-elif-else case, but at this point the simple cc-ifversion should
be enough.
Signed-off-by: Frantisek Hrbata
---
kernel/gcov
This adds the .init_array section as yet another section with constructors. This
is needed because gcc is adding __gcov_init calls to .init_array.
Signed-off-by: Frantisek Hrbata
---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/module.h| 2 ++
kernel/module.c
On Fri, Aug 23, 2013 at 05:08:07PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > This is an attempt to bring support for modified gcov format in gcc 4.7 to
> > the kernel. It tries to leverage the existing layout/abstraction, which was
> >
On Fri, Aug 23, 2013 at 05:09:58PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > Since also the gcov structures(gcov_info, gcov_fn_info, gcov_ctr_info) can
> > change between gcc releases, as shown in gcc 4.7, they cannot be defined in
&
On Fri, Aug 23, 2013 at 05:13:31PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > This adds the .init_array section as yet another section with constructors.
> > This
> > is needed because gcc is adding __gcov_init calls to .init_array.
&
On Fri, Aug 23, 2013 at 05:12:19PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > The gcov in-memory format changed in gcc 4.7. The biggest change, which
> > requires this special implementation, is that gcov_info no longer contains
> >
On Fri, Aug 23, 2013 at 05:15:19PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > Compile the correct gcov implementation file for a specific gcc version. In
> > the future, if another file is added, the conditions will need to be somehow
>
On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 17:15, Peter Oberparleiter wrote:
> > On 23.08.2013 10:39, Frantisek Hrbata wrote:
> >> Compile the correct gcov implementation file for a specific gcc version. In
> >> the future, if
same check is already done in ioremap. This patch just uses the same approach
and adds the same check to mmap_mem. I would like to ask what do you think about
the fix and if it looks ok to you.
Many thanks
--
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
usb/xhci, so I for sure could
overlooked something. That's also a reason I'm not sending a patch, because
I'm not sure if simple virt_dev != NULL in xhci_free_dev is enough/correct to
fix this.
Thank you
--
Frantisek Hrbata
--
To unsubscribe from this list: send the line &qu
On Thu, May 09, 2013 at 03:15:59PM -0700, Sarah Sharp wrote:
> On Tue, May 07, 2013 at 04:03:33PM +0200, Frantisek Hrbata wrote:
> > Hi,
>
> Hi Frantisek,
>
> > there is a NULL pointer dereference in xhci_free_dev if
> > xhci_alloc_dev timeouts while waiting for a
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
> On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
> >
> > Hi, this is exactly what the patch is doing imho. Note that the
> > valid_phys_addr_range(), which is using the high_memory, is the same as the
> >
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
> Hi Peter,
> On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
> >When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
> >X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bit
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
> On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
> >On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
> >>Hi Peter,
> >>On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
> >>>When
is is IMHO the only valid reason to use high_memory check in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked s
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
quot;cannot close");
return 0;
}
-8<--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c|
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
On Mon, Sep 29, 2014 at 10:15:28PM +0200, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Frantisek Hrbata wrote:
> > V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
>
> AFAICT, Dave also asked you to change size_t count into something more
> intuitive, i.e
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
y.
This is IMHO the only valid reason to use high_memory check in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
("cannot close");
return 0;
}
-8<------
V3: use len_bytes instead of count, thanks to Dave Hansen and Thomas Gleixner
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek H
On Tue, Sep 30, 2014 at 07:27:51AM -0700, Dave Hansen wrote:
> On 09/30/2014 05:41 AM, Frantisek Hrbata wrote:
> > Does it make sense to replace "count" with "size" so it's consistent with
> > the
> > rest or do you prefer "nr_bytes" or as
On Fri, Aug 15, 2014 at 11:10:25AM -0700, Dave Hansen wrote:
> On 08/15/2014 04:44 AM, Frantisek Hrbata wrote:
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory);
> > +}
> > +
> > +int va
There is no need to block read/write access to /dev/mem for phys. addr. above
high_memory for non-system RAM. The only limitation should be
boot_cpu_data.x86_phys_bits(max phys. addr. size).
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1
safely for
kernel mapped memory and it will also allow read/write to access non-system RAM
above high_memory once the high_memory check is removed from
valid_phys_addr_range.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/ioremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
allowing read/write to access non-system RAM above high_memory. So far this was
possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (2):
x86: add high_memory check to (xlate|unxlate)_dev_mem_ptr
x86: remove high_memory check from valid_phys_addr_ra
call(SYS_mmap2, NULL, ps, PROT_READ, MAP_SHARED, fd,
OFFSET);
if (map == MAP_FAILED)
die("cannot mmap");
c = map[0];
if (munmap(map, ps) == -1)
die("cannot munmap");
if (close(fd) == -1)
die
re with a hope it will get more attention or at least
to start the discussion how/if this should be fixed.
The patch is the same except I added a check for phys addr overflow before
calling phys_addr_valid. Maybe this check should be in do_mmap_pgoff.
Many thanks
Frantisek Hrbata (1):
x86: add ph
On Thu, Aug 14, 2014 at 09:36:03AM -0700, Dave Hansen wrote:
> Thanks for dredging this back up!
>
> On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory
On Thu, Aug 14, 2014 at 10:20:53AM -0700, H. Peter Anvin wrote:
> On 08/14/2014 09:36 AM, Dave Hansen wrote:
> > Thanks for dredging this back up!
> >
> > On 08/14/2014 07:18 AM, Frantisek Hrbata wrote:
> >> +int valid_phys_addr_range(phys_addr_t addr, size_t coun
self-nack
As pointed by Dave Hansen, the check is just wrong. I will post V2.
Many thanks Dave!
--
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
thing kept from historic
reasons. I'm just curious and I of course may be missing something.
Many thanks
Frantisek Hrbata (2):
x86: add arch_pfn_possible helper
x86: add phys addr validity check for /dev/mem mmap
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c| 12 +
Add helper to check maximum possible pfn on x86. Also make the current
phys_addr_valid helper using it internally.
Signed-off-by: Frantisek Hrbata
---
arch/x86/mm/physaddr.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/physaddr.h b/arch/x86/mm
quot;cannot close");
return 0;
}
-8<--
V2: fix pfn check in valid_mmap_phys_addr_range, thanks to Dave Hansen
Signed-off-by: Frantisek Hrbata
---
arch/x86/include/asm/io.h | 4
arch/x86/mm/mmap.c|
61 matches
Mail list logo
