[no subject]

[Offer]

-- 
Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben
Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der
ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von
2% .reply, wenn nötig.

Good Day, We are a registered private money lender. We give out loans
to firms, Individual who need to update their financial status all
over the world, with Minimal annual Interest Rates of 2%reply if
needed.

[no subject]

[noureddine TAOUAF]

Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 2,800,000.00EUR Ich 
gewann die America Lottery im Wert von $ 758.7 Millionen und ich spende einen 
Teil davon an fnf glckliche Menschen und 
Wohlttigkeits-Huser in Erinnerung an meinen verstorbenen Ehemann, 
der an Krebs gestorben ist. Kontaktieren Sie mich fr weitere Details 
unter: [maviswanczy...@hotmail.com]

[no subject]

[Rev. Luke]

Confidential! Open the attached for details


letter.rtf
Description: RTF file

[no subject]

[Andrew Martinez]

Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

[Andrew Martinez]

Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

[Sherri Gallagher]

Please reply me back
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[Tobin C. Harding]

Subject: [PATCH 0/2] Resolve Co-Developed-by issues

Recently tag Co-Developed-by was added (via a patch to
Documention/process/5.Posting.rst).

see https://lkml.org/lkml/2017/11/16/257

There has already been some discontent expressed over this tag.

A recent patch using the tag generated this response from  akmp (on LKML)

I prefer not to include tags which aren't listed in
Documentation/process/submitting-patches.rst, but I now see that
some bright spark added Co-Developed-by: to
Documentation/process/5.Posting.rst, so the two files are a)
duplicative and b) out of sync

Also, there has been comment over the use of the second capitalized
character 'D'.

This patch set attempts to either resolve this issue or bury it for
good. 

May the bike shedding begin :)

Joe Perches (1):
  checkpatch: add check for tag Co-Developed-by

Tobin C. Harding (1):
  docs: add Co-Developed-by docs

 Documentation/process/submitting-patches.rst |  9 -
 scripts/checkpatch.pl| 58 +---
 2 files changed, 42 insertions(+), 25 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] tracing: Remove redundant subject

[Xiongwei Song]

There are two consecutive 'we' to represent subject, remove one of the two.

Signed-off-by: Xiongwei Song <sxwj...@me.com>
---
 Documentation/trace/events.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 1d486660b40f..813b140cfe2c 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -878,10 +878,10 @@ The following commands are supported:
   Because the default sort key above is 'hitcount', the above shows a
   the list of call_sites by increasing hitcount, so that at the bottom
   we see the functions that made the most kmalloc calls during the
-  run.  If instead we we wanted to see the top kmalloc callers in
-  terms of the number of bytes requested rather than the number of
-  calls, and we wanted the top caller to appear at the top, we can use
-  the 'sort' parameter, along with the 'descending' modifier:
+  run.  If instead we wanted to see the top kmalloc callers in terms
+  of the number of bytes requested rather than the number of calls,
+  and we wanted the top caller to appear at the top, we can use the
+  'sort' parameter, along with the 'descending' modifier:
 
 # echo 'hist:key=call_site.sym:val=bytes_req:sort=bytes_req.descending' > \
/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
-- 
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[Paul R]

I have an import proposal for you..
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[clownscrytoo]

13379.doc
Description: MS-Word document

[no subject]

[1.10.1102011201470.7894]

52503216625202.doc
Description: MS-Word document

[no subject]

[Yury Norov]

Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64

Hi Catalin,
 
Here is a rebase of latest kernel patchset against next-20170602. There's almost
no changes, but there are some conflicts that are not trivial, and I'd like to
refresh the submission therefore.

How are your experiments with testing and benchmarking of ILP32 are going? In
my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
LMBench shows no difference for LP64 and expected performance boost for ILP32
(compared to LP64 results).

Steve Ellcey is handling upstream submission of Glibc patches. The patches are
ready and have been reviewed and reworked per community’s comments. There are
no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
on ILP32 kernel submission.

Catalin, regarding rootfs, is OpenSuSe’s build sufficient for your experiments?
I’ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
them to Debian.

One last thing I wanted to check with you about is ILP32 PCS - does, in your
view, ARM Ltd. needs to publish any additional docs for ABI to become official?

Below is the regular description.

Thanks.
Yury



This series enables aarch64 with ilp32 mode.

As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t is is used by new userspace). Also it
deprecates getrlimit and setrlimit syscalls prior to prlimit64.

This version is based on linux-next from 2017-03-01. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.

Patches 1, 2, 3 and 8 are general, and may be applied separately.

This is the rebase of v7 - still no major changes has been made.

Kernel and GLIBC trees:
https://github.com/norov/linux/tree/ilp32-20170602
https://github.com/norov/glibc/tree/dev9

(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)

Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap:  https://lkml.org/lkml/2016/6/17/990
v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
v7: https://lkml.org/lkml/2017/1/9/213
v7: Resend: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
v7: Resend 2:
- vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
- rebased on next-20170602.

Andrew Pinski (6):
  arm64: rename COMPAT to AARCH32_EL0 in Kconfig
  arm64: ensure the kernel is compiled for LP64
  arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
  arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
  arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
  arm64:ilp32: add ARM64_ILP32 to Kconfig

Philipp Tomsich (1):
  arm64:ilp32: add vdso-ilp32 and use for signal return

Yury Norov (13):
  compat ABI: use non-compat openat and open_by_handle_at variants
  32-bit ABI: introduce ARCH_32BIT_OFF_T config option
  asm-generic: Drop getrlimit and setrlimit syscalls from default list
  arm64: ilp32: add documentation on the ILP32 ABI for ARM64
  thread: move thread bits accessors to separated file
  arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
  arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
  arm64: introduce binfmt_elf32.c
  arm64: ilp32: introduce binfmt_ilp32.c
  arm64: ilp32: share aarch32 syscall handlers
  arm64: signal: share lp64 signal routines to ilp32
  arm64: signal32: move ilp32 and aarch32 common code to separated file
  arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

 Documentation/arm64/ilp32.txt |  45 +++
 arch/Kconfig  |   4 +
 arch/arc/Kconfig  |   1 +
 arch/arc/include/uapi/asm/unistd.h|   1 +
 arch/arm/Kconfig  |   1 +
 arch/arm64/Kconfig|  19 ++-
 arch/arm64/Makefile   |   8 ++
 arch/arm64/include/asm/compat.h   |  19 +--
 arch/arm64/include/asm/elf.h  |  37 ++
 arch/arm64/include/asm/fpsimd.h   |   2 +-
 arch/arm64/include/asm/ftrace.h   |   2 +-
 arch/arm64/include/asm/hwcap.h|   6 +-
 arch/arm64/include/asm/is_compat.h|  90 ++
 arch/arm64/include/asm/memory.h   |   5 +-
 arch/arm64/include/asm/processor.h|  11 +-
 arch/arm64/include/asm/ptrace.h   |   2 +-
 arch/arm64/include/asm/seccomp.h  |   2 +-
 arch/arm64/include/asm/signal32.h |   9 +-
 arch/arm64/include/asm/signal32_common.h  |  27 
 arch/arm64/include/asm/signal_common.h|  33 +
 arch/arm64/include/asm/signal_ilp32.h |  38 ++
 arch

[no subject]

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[David Howells]

Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[Thomas Garnier]

This is PATCH v1 for KASLR memory implementation on x86_64. Minor changes
were done based on RFC v1 comments.

***Background:
The current implementation of KASLR randomizes only the base address of
the kernel and its modules. Research was published showing that static
memory can be overwitten to elevate privileges bypassing KASLR.

In more details:

The physical memory mapping holds most allocations from boot and heap
allocators. Knowning the base address and physical memory size, an
attacker can deduce the PDE virtual address for the vDSO memory page.
This attack was demonstrated at CanSecWest 2016, in the "Getting
Physical Extreme Abuse of Intel Based Paged Systems"
https://goo.gl/ANpWdV (see second part of the presentation). Similar
research was done at Google leading to this patch proposal. Variants
exists to overwrite /proc or /sys objects ACLs leading to elevation of
privileges. These variants were tested against 4.6+.

This set of patches randomizes base address and padding of three
major memory sections (physical memory mapping, vmalloc & vmemmap).
It mitigates exploits relying on predictable kernel addresses. This
feature can be enabled with the CONFIG_RANDOMIZE_MEMORY option.

Padding for the memory hotplug support is managed by
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10
terabytes.

The patches were tested on qemu & physical machines. Xen compatibility was
also verified. Multiple reboots were used to verify entropy for each
memory section.

***Problems that needed solving:
 - The three target memory sections are never at the same place between
   boots.
 - The physical memory mapping can use a virtual address not aligned on
   the PGD page table.
 - Have good entropy early at boot before get_random_bytes is available.
 - Add optional padding for memory hotplug compatibility.

***Parts:
 - The first part prepares for the KASLR memory randomization by
   refactoring entropy functions used by the current implementation and
   support PUD level virtual addresses for physical mapping.
   (Patches 01-02)
 - The second part implements the KASLR memory randomization for all
   sections mentioned.
   (Patch 03)
 - The third part adds support for memory hotplug by adding an option to
   define the padding used between the physical memory mapping section
   and the others.
   (Patch 04)

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html