site6 | 25 Jul 22:39 2016
Picon

Effective way to help you develop global market

您好

让你一天联系100个客户变为一天联系上万个高质量目标潜在客户。
订单不断!!避开B2B的价格战,展会的成本高。
让对你们产品感兴趣的上游客户主动来找你。


想了解更多主动式外贸开发客户,请加 QQ------> 3246075707 
直接验证客户信息 是否真实、有效

也可加微信号:sunsesoftsam

----------------------------------------------
您是选择主动出击,从源头开发优质客户,还是苦苦等待客户来联系你呢 
如有不需要此信息,请回复“不需要”,我们将会将您的邮箱进行屏蔽,不再给您发信的。


祝:生意兴隆!
Jessica Yu | 25 Jul 11:25 2016
Picon

[PATCH v2 0/1] Add ro_after_init support for modules

Hi,

This patch adds ro_after_init support for modules by adding an additional
page-aligned section in the module layout. This new ro_after_init section
sits between rodata and writable data.

So, the new module layout looks like:
   [text] [rodata] [ro_after_init] [writable data]

RO after init data remains RW during init and RO protection is enabled
separately after module init runs.

Did some light testing with lkdtm compiled as a module, verified that
ro_after_init data is writable during init, and that it oopsed after attempted
writes after init. Also tested livepatch (which uses module_{enable,disable}_ro
for its own purposes) to make sure nothing broke. More testing is appreciated :-)

Some remarks on the implementation:
 * A new SHF_RO_AFTER_INIT flag is introduced in elf.h to make
   identification of .data..ro_after_init sections and the work of
   layout_sections() easier. Its chosen value is within the SHF_MASKOS
   range.
 * If a module doesn't have a ro_after_init section, then
   core_layout.ro_after_init_size just takes the value of
   core_layout.ro_size, and frob_ro_after_init() should do nothing.

Based on linux-next.

v1 here:
http://lkml.kernel.org/g/1465863198-15947-1-git-send-email-jeyu-H+wXaHxf7aLQT0dZR+AlfA <at> public.gmane.org
(Continue reading)

Mathieu Desnoyers | 24 Jul 05:09 2016
Gravatar

Re: [RFC PATCH v7 7/7] Restartable sequences: self-tests

----- On Jul 23, 2016, at 5:26 PM, Dave Watson davejwatson@... wrote:

> Hi Mathieu,

> > Implements two basic tests of RSEQ functionality, and one more
> > exhaustive parameterizable test.

> Thanks for beefing up the tests. I ran this set through our jemalloc
> tests using rseq, and everything looks good so far.

> +static inline __attribute__((always_inline))
> +bool rseq_finish(struct rseq_lock *rlock,
> + intptr_t *p, intptr_t to_write,
> + struct rseq_state start_value)
> +{
> + RSEQ_INJECT_C(9)
> +
> + if (unlikely(start_value.lock_state != RSEQ_LOCK_STATE_RESTART)) {
> + if (start_value.lock_state == RSEQ_LOCK_STATE_LOCK)
> + rseq_fallback_wait(rlock);
> + return false;
> + }
> +
> +#ifdef __x86_64__
> + /*
> + * The __rseq_table section can be used by debuggers to better
> + * handle single-stepping through the restartable critical
> + * sections.
> + */
> + __asm__ __volatile__ goto (
(Continue reading)

Mathieu Desnoyers | 21 Jul 23:14 2016
Gravatar

[RFC PATCH v7 0/7] Restartable sequences system call

Hi,

This is mostly a re-write of Paul Turner and Andrew Hunter's restartable
critical sections (percpu atomics), which brings the following main
benefits over Paul Turner's prior version (v2):

- The ABI is now architecture-agnostic, and it requires fewer
  instruction on the user-space fast path,
- Ported to ARM 32, in addition to cover x86 32/64. Adding support
  for new architectures is now trivial,
- Progress is ensured by a fall-back to locking (purely userspace)
  when single-stepped by a debugger.

This is v7, as it derives from my prior getcpu cache and thread local
ABI patchsets. You will find benchmark results in the changelog of
patch 1/7.

Feedback is welcome!

Thanks,

Mathieu

Mathieu Desnoyers (7):
  Restartable sequences system call
  tracing: instrument restartable sequences
  Restartable sequences: ARM 32 architecture support
  Restartable sequences: wire up ARM 32 system call
  Restartable sequences: x86 32/64 architecture support
  Restartable sequences: wire up x86 32/64 system call
(Continue reading)

Andrey Vagin | 20 Jul 22:42 2016

[PATCH 0/3 v3] fs: allow to use dirfd as root for openat and other *at syscalls

The problem is that a pathname can contain absolute symlinks and now
they are resolved relative to the current root.

It may be a problem if you want to open a file in another namespace.
For example, you open /proc/PID/root for a process from the target
namespace and then you use openat() to open a file from this namespace.

If a path to the file contains an absolute symlink, you will open a file
from the current namespace, because a symlink will be resolved relative
to the current root.

A proposed solution adds a new flag which means that dirfd should be
set as a root for a current system call (openat(), statat(), etc).

Here are examples how we can open a file in a contex of another process.

How we can do this without these changes:

	old_root = open("/", O_PATH);
	old_cwd = open(".", O_PATH);
	chroot("/proc/PID/root");

	fd = open(pathname, O_RDONLY);

	fchdir(old_root); /* emulate fchroot() */
	chroot(".");
	fchdir(old_cwd);

	close(old_cwd);
	close(old_root);
(Continue reading)

Andrey Vagin | 14 Jul 20:20 2016

[PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

Each namespace has an owning user namespace and now there is not way
to discover these relationships.

Pid and user namepaces are hierarchical. There is no way to discover
parent-child relationships too.

Why we may want to know relationships between namespaces?

One use would be visualization, in order to understand the running system.
Another would be to answer the question: what capability does process X have to
perform operations on a resource governed by namespace Y?

One more use-case (which usually called abnormal) is checkpoint/restart.
In CRIU we age going to dump and restore nested namespaces.

There [1] was a discussion about which interface to choose to determing
relationships between namespaces.

Eric suggested to add two ioctl-s [2]:
> Grumble, Grumble.  I think this may actually a case for creating ioctls
> for these two cases.  Now that random nsfs file descriptors are bind
> mountable the original reason for using proc files is not as pressing.
>
> One ioctl for the user namespace that owns a file descriptor.
> One ioctl for the parent namespace of a namespace file descriptor.

Here is an implementaions of these ioctl-s.

[1] https://lkml.org/lkml/2016/7/6/158
[2] https://lkml.org/lkml/2016/7/9/101
(Continue reading)

Darrick J. Wong | 14 Jul 20:11 2016
Picon

[PATCH] ioctl_ficlonerange.2: mention a subtlety with length == 0

I forgot to document that passing length == 0 to clonerange actually
makes it clone all the way to EOF, so do that now.

Signed-off-by: Darrick J. Wong <darrick.wong@...>
---
 man2/ioctl_ficlonerange.2 |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/man2/ioctl_ficlonerange.2 b/man2/ioctl_ficlonerange.2
index d1da3e6..c4715d0 100644
--- a/man2/ioctl_ficlonerange.2
+++ b/man2/ioctl_ficlonerange.2
 <at>  <at>  -59,6 +59,9  <at>  <at>  into the file
 at offset
 .IR dest_offset ",
 provided that both are files.
+If
+.IR src_length
+is zero, the ioctl reflinks to the end of the source file.
 This information is conveyed in a structure of
 the following form:
 .in +4n
omc3 | 27 Jun 02:17 2016
Picon

Re:Help you develop global target market to win customers! !

Give yourself a chance to Take the initiative develop global customers
Contact QQ: 3246075707

请加+QQ 3246075707 联系 在线演示主动开发全球客户,欢迎验证是否真实有效
也可加微信号:sunsesoftsam

您是主动开发国外当地的目标客户还是继续等客户自己上门了解呢
Michael Kerrisk (man-pages | 25 Jun 09:30 2016
Picon
Gravatar

Review of ptrace Yama ptrace_scope description

Hi Kees,

So, last year, I added some documentation to ptrace(2) to describe
the Yama ptrace_scope file. I don't think I asked you for review
at the time, but in the light of other changes to the ptrace(2)
page, it occurred to me that it might be a good idea to ask you
to check the text below to see if anything is missing or could be
improved. Might you have a moment for that?

    /proc/sys/kernel/yama/ptrace_scope
        On systems with the Yama Linux Security Module (LSM)  installed
        (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
        the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
        Linux  3.4)  can  be  used  to  restrict the ability to trace a
        process with ptrace(2) (and thus also the ability to use  tools
        such  as  strace(1) and gdb(1)).  The goal of such restrictions
        is to prevent attack escalation whereby a  compromised  process
        can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
        agent or an SSH session) owned by the user  in  order  to  gain
        additional credentials and thus expand the scope of the attack.

        More precisely, the Yama LSM limits two types of operations:

        *  Any   operation   that   performs   a   ptrace  access  mode
           PTRACE_MODE_ATTACH     check—for      example,      ptrace()
           PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
           cussion above.)

        *  ptrace() PTRACE_TRACEME.

(Continue reading)

Michael Kerrisk (man-pages | 21 Jun 11:41 2016
Picon
Gravatar

Documenting ptrace access mode checking

Hi Jann, Stephen, et al.

Jann, since you recently committed a patch in this area, and Stephen,
since you committed 006ebb40d3d much further back in time, I wonder if
you might help me by reviewing the text below that I propose to add to
the ptrace(2) man page, in order to document "ptrace access mode 
checking" that is performed in various parts of the kernel-user-space
interface. Of course, I welcome input from anyone else as well.

Here's the new ptrace(2) text. Any comments, technical or terminological
fixes, other improvements, etc. are welcome.

[[
   Ptrace access mode checking
       Various parts of the kernel-user-space API (not just  ptrace(2)
       operations), require so-called "ptrace access mode permissions"
       which are gated  by  Linux  Security  Modules  (LSMs)  such  as
       SELinux,  Yama,  Smack,  or  the  default  LSM.  Prior to Linux
       2.6.27, all such checks were of a  single  type.   Since  Linux
       2.6.27, two access mode levels are distinguished:

       PTRACE_MODE_READ
              For  "read" operations or other operations that are less
              dangerous, such as: get_robust_list(2); kcmp(2); reading
              /proc/[pid]/auxv,         /proc/[pid]/environ,        or
              /proc/[pid]/stat; or readlink(2) of  a  /proc/[pid]/ns/*
              file.

       PTRACE_MODE_ATTACH
              For  "write"  operations,  or  other operations that are
(Continue reading)

Darrick J. Wong | 17 Jun 03:17 2016
Picon

[PATCH v9 0/3] fallocate for block devices

Hi,

This is a redesign of the patch series that fixes various interface
problems with the existing "zero out this part of a block device"
code.  BLKZEROOUT2 is gone.

The first patch is still a fix to the existing BLKZEROOUT ioctl to
invalidate the page cache if the zeroing command to the underlying
device succeeds.  Without this patch we still have the pagecache
coherence bug that's been in the kernel forever.

The second patch changes the internal block device functions to reject
attempts to discard or zeroout that are not aligned to the logical
block size.  Previously, we only checked that the start/len parameters
were 512-byte aligned, which caused kernel BUG_ONs for unaligned IOs
to 4k-LBA devices.

The third patch creates an fallocate handler for block devices, wires
up the FALLOC_FL_PUNCH_HOLE flag to zeroing-discard, and connects
FALLOC_FL_ZERO_RANGE to write-same so that we can have a consistent
fallocate interface between files and block devices.  It also allows
the combination of PUNCH_HOLE and NO_HIDE_STALE to invoke non-zeroing
discard.

Test cases for the new block device fallocate are now in xfstests as
generic/349-351.

Comments and questions are, as always, welcome.  Patches are against
4.7-rc3.

(Continue reading)


Gmane