[PATCH 1/4] random/trace: remove unused trace_random_read()

Since commit 30c08efec888 ('random: make /dev/random be almost like /dev/urandom'), trace_random_read() is unused. Cc: Andy Lutomirski Cc: Theodore Ts'o Signed-off-by: Yann Droneaud --- include/trace/events/random.h | 25 - 1 file changed, 25 deletions(-) diff --git

[PATCH 3/4] random/trace: remove unused trace_extract_entropy_user()

Since commit 90ea1c6436d2 ('random: remove the blocking pool') trace_extract_entropy_user() is unused. As the result, trace_extract_entropy() is the only trace function needed, thus there's no need for a separate event class / event. Cc: Andy Lutomirski Cc: Theodore Ts'o Signed-off-by: Yann

[PATCH 0/4] random/trace: remove unused function

Hi, After simplifications brought recently to random [1], some trace functions are no more needed. This patchset removes them. [1] https://lore.kernel.org/linux-api/cover.1577088521.git.l...@kernel.org/ Yann Droneaud (4): random/trace: remove unused trace_random_read() random/trace: remove

[PATCH 4/4] random/trace: remove unused trace_xfer_secondary_pool()

Since commit 84df7cdfbb21 ('random: delete code to pull data into pools'), trace_xfer_secondary_pool() is unused. Cc: Andy Lutomirski Cc: Theodore Ts'o Signed-off-by: Yann Droneaud --- include/trace/events/random.h | 29 - 1 file changed, 29 deletions(-) diff

[PATCH 2/4] random/trace: remove unused trace_push_to_pool()

Since commit 90ea1c6436d2 ('random: remove the blocking pool') trace_push_to_pool() is unused. Cc: Andy Lutomirski Cc: Theodore Ts'o Signed-off-by: Yann Droneaud --- include/trace/events/random.h | 22 -- 1 file changed, 22 deletions(-) diff --git a/include/trace/events

Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms

dard, is supposed to return the length of the formatted string, regarless of the size of the destination buffer. So encouraging developper to write something like code below because snprintf() in kernel behave in a non-standard way, will likely create some issues in the near future. for(;...;) offset += snprintf(buf + offset, size - offset, "..", ); (Reminder: the code below is not safe and shouldn't be used) Regards. -- Yann Droneaud OPTEYA

[PATCH 3/3] binfmt/elf: randomize padding between ELF interp info

variables, if someone want to scare userspace). [1] https://www.openwall.com/lists/kernel-hardening/2019/03/29/3 Link: https://lore.kernel.org/lkml/cover.1560423331.git.ydrone...@opteya.com Cc: Elena Reshetova Signed-off-by: Yann Droneaud --- fs/binfmt_elf.c | 30 ++ 1 fi

[PATCH 2/3] binfmt/elf: align AT_RANDOM array

://sourceware.org/ml/libc-alpha/2008-10/msg00013.html [1] https://lore.kernel.org/lkml/20081003001616.gn10...@outflux.net/ Link: https://lore.kernel.org/lkml/cover.1560423331.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud --- fs/binfmt_elf.c | 16 1 file changed, 8 insertions

[PATCH 1/3] binfmt/elf: use functions for stack manipulation

stack pointer on 16 bytes boundary. The macro is replaced by elf_stack_add_items() followed by elf_stack_align(). Link: https://lore.kernel.org/lkml/cover.1560423331.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud --- fs/binfmt_elf.c | 68 - 1

[PATCH 0/3] ELF interpretor info: align and add random padding

security as I'm not aware of any attack that can be prevented with this mechanism in place. Regards. Yann Droneaud (3): binfmt/elf: use functions for stack manipulation binfmt/elf: align AT_RANDOM array binfmt/elf: randomize padding between ELF interp info fs/binfmt_elf.c | 110

[PATCH 4/3] binfmt/elf: don't expose prandom_u32() state

at a time. Instead this patch makes use of get_random_u64() to seed once a local PRNG. The local PRNG can be used safely to produces the random offsets, exposing its internal state won't harm. Link: https://lore.kernel.org/lkml/cover.1560423331.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud

Re: [PATCH v1 1/2] fork: add clone3

Hi, Le samedi 01 juin 2019 à 00:08 +0200, Christian Brauner a écrit : > On Wed, May 29, 2019 at 05:42:14PM +0200, Yann Droneaud wrote: > > Le mercredi 29 mai 2019 à 17:22 +0200, Christian Brauner a écrit : > > > This adds the clone3 system call. > > > > > >

Re: [RFCv2 6/6] mm: extend process_madvise syscall to support vector arrary

of each operation */ > + const struct iovec __user *results; > + /* input address ranges */ > + const struct iovec __user *ranges; Using pointer type in uAPI structure require a 'compat' version of the syscall need to be provided. If using iovec too. > +}; > + > #en

Re: [PATCH v1 1/2] fork: add clone3

args->stack_size = args.stack_size; > + kargs->tls = args.tls; > + > + return 0; > +} > + > +SYSCALL_DEFINE2(clone3, struct clone_args __user *, uargs, size_t, size) > +{ > + int err; > + > + struct kernel_clone_args kargs; > + > + err = copy_clone_args_from_user(, uargs, size); > + if (err) > + return err; > + > + return _do_fork(); > } > #endif > Regards. -- Yann Droneaud OPTEYA

Re: [PATCH v2 0/5] pid: add pidfd_open()

it would punch a hole in chroot() ... (but in 2019, nobody should rely on it for security purpose). Regards. -- Yann Droneaud OPTEYA

Re: [PATCH 2/4] pid: add pidfd_open()

FD_TO_PIDFD) > + return -EINVAL; > + > + if (pid != -1) > + return -EINVAL; > + > + if (pidfd >= 0) > I think it can be stricter with: if (pidfd != -1) (and match the check done for flag == 0). Regards. -- Yann Droneaud OPTEYA

Re: [PATCH 05/11] UAPI: coda: Don't use internal kernel structs in UAPI

Hi, Le jeudi 06 septembre 2018 à 08:13 +0100, David Howells a écrit : > Yann Droneaud wrote: > > > This structure should not have been exposed to userspace in the > > first > > place: it's unusable by userspace as it is. It was incorrect to > > have it > >

Re: [PATCH 05/11] UAPI: coda: Don't use internal kernel structs in UAPI

Hi, Le jeudi 06 septembre 2018 à 08:13 +0100, David Howells a écrit : > Yann Droneaud wrote: > > > This structure should not have been exposed to userspace in the > > first > > place: it's unusable by userspace as it is. It was incorrect to > > have it > >

Re: [RFC] UAPI: Check headers by compiling all together as C++

Le mercredi 05 septembre 2018 à 19:33 +0200, Yann Droneaud a écrit : > Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit : > > On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote: > > > > > > Here's a set of patches that inserts a step into the

Re: [RFC] UAPI: Check headers by compiling all together as C++

Le mercredi 05 septembre 2018 à 19:33 +0200, Yann Droneaud a écrit : > Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit : > > On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote: > > > > > > Here's a set of patches that inserts a step into the

Re: [PATCH 05/11] UAPI: coda: Don't use internal kernel structs in UAPI

. So the structure can be moved back to . > #define CODA_REQ_ASYNC 0x1 > All CODA_REQ_* defines internals to kernel side and not exchanged with userspace. Please move them back to Regards. -- Yann Droneaud OPTEYA

Re: [PATCH 05/11] UAPI: coda: Don't use internal kernel structs in UAPI

. So the structure can be moved back to . > #define CODA_REQ_ASYNC 0x1 > All CODA_REQ_* defines internals to kernel side and not exchanged with userspace. Please move them back to Regards. -- Yann Droneaud OPTEYA

Re: [RFC] UAPI: Check headers by compiling all together as C++

they do the C namespace trick > themselves when they do the import? That must be how they are doing it > today, right? > They can't. Adding extern "C" { } doesn't magically make "class" a non keyword. Even if it was the case, writing C++ code using whatever->

Re: [RFC] UAPI: Check headers by compiling all together as C++

they do the C namespace trick > themselves when they do the import? That must be how they are doing it > today, right? > They can't. Adding extern "C" { } doesn't magically make "class" a non keyword. Even if it was the case, writing C++ code using whatever->

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

27e1ea4cd1a3e7;hb=23158b08a0908f381459f273a984c6fd3283 63cb#l142 And there's also AT_ANYNET and AT_ANYNODE from ddp (aka. AppleTalk) http://man7.org/linux/man-pages/man7/ddp.7.html Regards. -- Yann Droneaud OPTEYA

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

27e1ea4cd1a3e7;hb=23158b08a0908f381459f273a984c6fd3283 63cb#l142 And there's also AT_ANYNET and AT_ANYNODE from ddp (aka. AppleTalk) http://man7.org/linux/man-pages/man7/ddp.7.html Regards. -- Yann Droneaud OPTEYA

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

yte to set to 0 in each canary ? Regards. -- Yann Droneaud OPTEYA

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

yte to set to 0 in each canary ? Regards. -- Yann Droneaud OPTEYA

Re: [kernel-hardening] [PATCH v2] time: Remove CONFIG_TIMER_STATS

Hi, Don't forget to send to linux-...@vger.kernel.org Le mercredi 08 février 2017 à 11:26 -0800, Kees Cook a écrit : > Currently CONFIG_TIMER_STATS exposes process information across > namespaces: > > kernel/time/timer_list.c print_timer(): > > SEQ_printf(m, ", %s/%d", tmp,

Re: [kernel-hardening] [PATCH v2] time: Remove CONFIG_TIMER_STATS

Hi, Don't forget to send to linux-...@vger.kernel.org Le mercredi 08 février 2017 à 11:26 -0800, Kees Cook a écrit : > Currently CONFIG_TIMER_STATS exposes process information across > namespaces: > > kernel/time/timer_list.c print_timer(): > > SEQ_printf(m, ", %s/%d", tmp,

Re: IB/core: Fine-tuning for ib_is_udata_cleared()

o free; > I find that the two update steps should work in principle, > shouldn't they? > It would be better to squash them here. Regards. --  Yann Droneaud OPTEYA

Re: IB/core: Fine-tuning for ib_is_udata_cleared()

o free; > I find that the two update steps should work in principle, > shouldn't they? > It would be better to squash them here. Regards. --  Yann Droneaud OPTEYA

Re: [PATCH v3 1/7] random: Simplify API for random address requests

) % range << PAGE_SHIFT); > +} > + >  /* Interface for in-kernel drivers of true hardware RNGs. >   * Those devices may produce endless random bits and will be > throttled >   * when our pool is full. >  Regards. --  Yann Droneaud OPTEYA

Re: [PATCH v3 1/7] random: Simplify API for random address requests

) % range << PAGE_SHIFT); > +} > + >  /* Interface for in-kernel drivers of true hardware RNGs. >   * Those devices may produce endless random bits and will be > throttled >   * when our pool is full. >  Regards. --  Yann Droneaud OPTEYA

Re: [PATCH 1/7] random: Simplify API for random address requests

x/random.h > @@ -35,6 +35,7 @@ extern const struct file_operations random_fops, > urandom_fops; >  unsigned int get_random_int(void); >  unsigned long get_random_long(void); >  unsigned long randomize_range(unsigned long start, unsigned long end, > unsigned long len); > +unsigned long randomize_addr(unsigned long start, unsigned long range); >   >  u32 prandom_u32(void); >  void prandom_bytes(void *buf, size_t nbytes); Regards. -- Yann Droneaud OPTEYA

Re: [PATCH 1/7] random: Simplify API for random address requests

,7 @@ extern const struct file_operations random_fops, > urandom_fops; >  unsigned int get_random_int(void); >  unsigned long get_random_long(void); >  unsigned long randomize_range(unsigned long start, unsigned long end, > unsigned long len); > +unsigned long randomize_addr(unsigned long start, unsigned long range); >   >  u32 prandom_u32(void); >  void prandom_bytes(void *buf, size_t nbytes); Regards. -- Yann Droneaud OPTEYA

Re: [kernel-hardening] [RFC patch 1/6] random: Simplify API for random address requests

Hi, Le mardi 26 juillet 2016 à 03:01 +, Jason Cooper a écrit : > To date, all callers of randomize_range() have set the length to 0, > and check for a zero return value.  For the current callers, the only > way to get zero returned is if end <= start.  Since they are all > adding a constant

Re: [kernel-hardening] [RFC patch 1/6] random: Simplify API for random address requests

Hi, Le mardi 26 juillet 2016 à 03:01 +, Jason Cooper a écrit : > To date, all callers of randomize_range() have set the length to 0, > and check for a zero return value.  For the current callers, the only > way to get zero returned is if end <= start.  Since they are all > adding a constant

Re: [PATCH v2 1/3] coccinelle: also catch kzfree() issues

Hi, Le mardi 21 juin 2016 à 11:43 +0200, Michal Marek a écrit : > Dne 20.6.2016 v 22:21 Julia Lawall napsal(a): > > On Mon, 20 Jun 2016, Michal Marek wrote: > > On 2016-05-23 17:18, Julia Lawall wrote: > > > > On Mon, 23 May 2016, Yann Droneaud wrote: > > > &g

Re: [PATCH v2 1/3] coccinelle: also catch kzfree() issues

Hi, Le mardi 21 juin 2016 à 11:43 +0200, Michal Marek a écrit : > Dne 20.6.2016 v 22:21 Julia Lawall napsal(a): > > On Mon, 20 Jun 2016, Michal Marek wrote: > > On 2016-05-23 17:18, Julia Lawall wrote: > > > > On Mon, 23 May 2016, Yann Droneaud wrote: > > > &g

[PATCH v2 3/3] coccinelle: catch krealloc() on devm_*() allocated memory

, krealloc() must not be used on a pointer returned by devm_*() functions. Cc: Tejun Heo <t...@kernel.org> Cc: Pekka Enberg <penb...@cs.helsinki.fi> Acked-by: Julia Lawall <julia.law...@lip6.fr> Signed-off-by: Yann Droneaud <ydrone...@opteya.com> --- scripts/coccinelle/free/dev

[PATCH v2 2/3] coccinelle: recognize more devm_* memory allocation functions

vas.pandruv...@linux.intel.com> Cc: Eli Billauer <eli.billa...@gmail.com> Cc: Himangi Saraogi <himangi...@gmail.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Wolfram Sang <w.s...@pengutronix.de> Cc: Daniel Thompson <daniel.thomp...@linaro.org> Acked-by: J

[PATCH v2 3/3] coccinelle: catch krealloc() on devm_*() allocated memory

, krealloc() must not be used on a pointer returned by devm_*() functions. Cc: Tejun Heo Cc: Pekka Enberg Acked-by: Julia Lawall Signed-off-by: Yann Droneaud --- scripts/coccinelle/free/devm_free.cocci | 4 1 file changed, 4 insertions(+) diff --git a/scripts/coccinelle/free/devm_free.cocci

[PATCH v2 2/3] coccinelle: recognize more devm_* memory allocation functions

c: Wolfram Sang Cc: Daniel Thompson Acked-by: Julia Lawall Signed-off-by: Yann Droneaud --- scripts/coccinelle/free/devm_free.cocci | 20 1 file changed, 20 insertions(+) diff --git a/scripts/coccinelle/free/devm_free.cocci b/scripts/coccinelle/free/devm_free.cocci ind

[PATCH v2 0/3] coccinelle: catchup on memory allocation functions

...@opteya.com [2] http://lkml.kernel.org/r/cover.1455638829.git.ydrone...@opteya.com Regards. Yann Droneaud (3): coccinelle: also catch kzfree() issues coccinelle: recognize more devm_* memory allocation functions coccinelle: catch krealloc() on devm_*() allocated memory scripts/coccinelle/free

[PATCH v2 0/3] coccinelle: catchup on memory allocation functions

...@opteya.com [2] http://lkml.kernel.org/r/cover.1455638829.git.ydrone...@opteya.com Regards. Yann Droneaud (3): coccinelle: also catch kzfree() issues coccinelle: recognize more devm_* memory allocation functions coccinelle: catch krealloc() on devm_*() allocated memory scripts/coccinelle/free

[PATCH v2 1/3] coccinelle: also catch kzfree() issues

ed-off-by: Yann Droneaud <ydrone...@opteya.com> --- scripts/coccinelle/free/devm_free.cocci | 2 ++ scripts/coccinelle/free/ifnullfree.cocci | 4 +++- scripts/coccinelle/free/kfree.cocci | 18 +++--- scripts/coccinelle/free/kfreeaddr.cocci | 6 +- 4 files changed, 25 inse

[PATCH v2 1/3] coccinelle: also catch kzfree() issues

Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), kfree() is no more the only function to be considered: kzfree() should be recognized too. In particular, kzfree() must not be called on memory allocated through devm_*() functions. Cc: Johannes Weiner Signed-off-by: Yann Droneaud

Re: [PATCHv1 1/3] coccinelle: also catch kzfree() issues

Le lundi 22 février 2016 à 09:20 -0500, Julia Lawall a écrit : > On Mon, 22 Feb 2016, Yann Droneaud wrote: > > > Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), > > kfree() is no more the only function to be considered. > > > > In particular, kzfree(

Re: [PATCHv1 1/3] coccinelle: also catch kzfree() issues

Le lundi 22 février 2016 à 09:20 -0500, Julia Lawall a écrit : > On Mon, 22 Feb 2016, Yann Droneaud wrote: > > > Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), > > kfree() is no more the only function to be considered. > > > > In particular, kzfree(

[PATCHv1 1/3] coccinelle: also catch kzfree() issues

Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), kfree() is no more the only function to be considered. In particular, kzfree() must not be called on memory allocated through devm_*() functions. Cc: Johannes Weiner <han...@cmpxchg.org> Signed-off-by: Yann Droneaud <ydrone...@o

[PATCHv1 1/3] coccinelle: also catch kzfree() issues

Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), kfree() is no more the only function to be considered. In particular, kzfree() must not be called on memory allocated through devm_*() functions. Cc: Johannes Weiner Signed-off-by: Yann Droneaud --- Hi Julia, As you suggested, I've use

[PATCH 1/3] coccinelle: also catch kzfree() issues

Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), kfree() is no more the only function to be considered. Cc: Johannes Weiner <han...@cmpxchg.org> Signed-off-by: Yann Droneaud <ydrone...@opteya.com> --- scripts/coccinelle/free/devm_free.cocci | 2 ++ scripts/coccinelle/free

[PATCH 3/3] coccinelle: catch krealloc() on devm_*() allocated memory

, krealloc() must not be used on a pointer returned by devm_*() functions. Cc: Tejun Heo <t...@kernel.org> Cc: Pekka Enberg <penb...@cs.helsinki.fi> Signed-off-by: Yann Droneaud <ydrone...@opteya.com> --- scripts/coccinelle/free/devm_free.cocci | 4 1 file changed, 4 inserti

[PATCH 1/3] coccinelle: also catch kzfree() issues

Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'), kfree() is no more the only function to be considered. Cc: Johannes Weiner Signed-off-by: Yann Droneaud --- scripts/coccinelle/free/devm_free.cocci | 2 ++ scripts/coccinelle/free/kfree.cocci | 3 +++ scripts/coccinelle/free

[PATCH 3/3] coccinelle: catch krealloc() on devm_*() allocated memory

, krealloc() must not be used on a pointer returned by devm_*() functions. Cc: Tejun Heo Cc: Pekka Enberg Signed-off-by: Yann Droneaud --- scripts/coccinelle/free/devm_free.cocci | 4 1 file changed, 4 insertions(+) diff --git a/scripts/coccinelle/free/devm_free.cocci b/scripts/coccinelle

[PATCH 0/3] coccinelle: catchup on memory allocation functions

() - free_pages() - free_page() I've ran coccicheck on drivers/staging and found no new issue, which is great, but that questions those patches' usefulness, YMMV. Regards. Yann Droneaud (3): coccinelle: also catch kzfree() issues coccinelle: recognize more devm_* memory allocation functions

[PATCH 2/3] coccinelle: recognize more devm_* memory allocation functions

vas.pandruv...@linux.intel.com> Cc: Eli Billauer <eli.billa...@gmail.com> Cc: Himangi Saraogi <himangi...@gmail.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Wolfram Sang <w.s...@pengutronix.de> Cc: Daniel Thompson <daniel.thomp...@linaro.org> Signed-off-b

[PATCH 0/3] coccinelle: catchup on memory allocation functions

() - free_pages() - free_page() I've ran coccicheck on drivers/staging and found no new issue, which is great, but that questions those patches' usefulness, YMMV. Regards. Yann Droneaud (3): coccinelle: also catch kzfree() issues coccinelle: recognize more devm_* memory allocation functions

[PATCH 2/3] coccinelle: recognize more devm_* memory allocation functions

c: Wolfram Sang Cc: Daniel Thompson Signed-off-by: Yann Droneaud --- scripts/coccinelle/free/devm_free.cocci | 20 1 file changed, 20 insertions(+) diff --git a/scripts/coccinelle/free/devm_free.cocci b/scripts/coccinelle/free/devm_free.cocci index 83c03adec1c5..3794

Re: [PATCH] IB/core: avoid 32-bit warning

to cast inside INIT_UDATA() and not have callers > worry about it? It's ... complicated. See INIT_UDATA_BUF_OR_NULL(). Awayway, I have patch to do the opposite, eg. explicitly cast u64 value to (void __user *)(unsigned long) in the caller function instead, as it allows some safer / new oper

Re: [PATCH] IB/core: avoid 32-bit warning

Arnd Bergmann > Fixes: 565197dd8fb1 ("IB/core: Extend ib_uverbs_create_cq") > Reviewed-by: Yann Droneaud > diff --git a/drivers/infiniband/core/uverbs_cmd.c > b/drivers/infiniband/core/uverbs_cmd.c > index be4cb9f04be3..88b3b78340f2 100644 > --- a/drivers/infiniban

Re: [PATCH] IB/core: avoid 32-bit warning

; Would it make sense to cast inside INIT_UDATA() and not have callers > worry about it? It's ... complicated. See INIT_UDATA_BUF_OR_NULL(). Awayway, I have patch to do the opposite, eg. explicitly cast u64 value to (void __user *)(unsigned long) in the caller function instead, as it all

Re: [PATCH] IB/core: avoid 32-bit warning

rnd Bergmann <a...@arndb.de> > Fixes: 565197dd8fb1 ("IB/core: Extend ib_uverbs_create_cq") > Reviewed-by: Yann Droneaud <ydrone...@opteya.com> > diff --git a/drivers/infiniband/core/uverbs_cmd.c > b/drivers/infiniband/core/uverbs_cmd.c > index be4cb9f04be3.

Re: [PATCH v2 3/3] falloc: expose ioctl numbers into uapi

ved area */ > +}; > + > +#define FS_IOC_RESVSP_IOW('X', 40, struct > space_resv) > +#define FS_IOC_RESVSP64 _IOW('X', 42, struct > space_resv) > + > #endif /* _UAPI_FALLOC_H_ */ Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send

Re: [PATCH v2 3/3] falloc: expose ioctl numbers into uapi

pad[4]; /* reserved area */ > +}; > + > +#define FS_IOC_RESVSP_IOW('X', 40, struct > space_resv) > +#define FS_IOC_RESVSP64 _IOW('X', 42, struct > space_resv) > + > #endif /* _UAPI_FALLOC_H_ */ Regards. -- Yann Droneaud OPTEYA -- T

Re: [PATCH] timerfd: expose uapi header

ones. We want > + * to re-use O_* flags that couldn't possibly have a meaning > + * from eventfd, in order to leave a free define-space for > + * shared O_* flags. > + */ > +#define TFD_TIMER_ABSTIME (1 << 0) > +#define TFD_TIMER_CANCEL_ON_SET (1 << 1) >

Re: [PATCH] timerfd: expose uapi header

when defining > + * new flags, since they might collide with O_* ones. We want > + * to re-use O_* flags that couldn't possibly have a meaning > + * from eventfd, in order to leave a free define-space for > + * shared O_* flags. > + */ > +#define TFD_TIMER_ABSTIME (1 << 0) > +#def

Re: [PATCH v2 2/2] perf tools: report PERF_FLAG_FD_CLOEXEC probing error once

Le vendredi 02 octobre 2015 à 15:20 +0200, Jiri Olsa a écrit : > On Thu, Oct 01, 2015 at 05:16:26PM +0200, Yann Droneaud wrote: > > In case of failure, unrelated to PERF_FLAG_FD_CLOEXEC, > > perf_flag_probe() reports the error twice. For example: > > > > $

Re: [PATCH v2 2/2] perf tools: report PERF_FLAG_FD_CLOEXEC probing error once

Le vendredi 02 octobre 2015 à 15:20 +0200, Jiri Olsa a écrit : > On Thu, Oct 01, 2015 at 05:16:26PM +0200, Yann Droneaud wrote: > > In case of failure, unrelated to PERF_FLAG_FD_CLOEXEC, > > perf_flag_probe() reports the error twice. For example: > > > > $

Re: [PATCH v2 1/2] perf tools: shortcut PERF_FLAG_FD_CLOEXEC probing in case of EBUSY error

Hi, Le jeudi 01 octobre 2015 à 22:52 +0200, Jiri Olsa a écrit : > On Thu, Oct 01, 2015 at 05:16:25PM +0200, Yann Droneaud wrote: > > This patch is a simplification of the logic introduced as part of > > commit 63914aca8f7e ('perf tools: Show better error message in case >

Re: [PATCH] uapi: remove i2o header in uapi

i2c.h -header-y += i2o-dev.h header-y += i8k.h header-y += icmp.h header-y += icmpv6.h Note, you may also use git format-patch -D to reduce the size of your patch. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu

[PATCH v2 1/2] perf tools: shortcut PERF_FLAG_FD_CLOEXEC probing in case of EBUSY error

Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: William Cohen Link: http://lkml.kernel.org/r/cover.1443708092.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud --- tools/perf/util/cloexec.c | 8

[PATCH v2 2/2] perf tools: report PERF_FLAG_FD_CLOEXEC probing error once

Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: William Cohen Link: http://lkml.kernel.org/r/cover.1443708092.git.ydrone...@opteya.com Reported-by: Jiri Olsa Signed-off-by: Yann Droneaud --- tools/perf/util/cloexec.c | 25 + 1 file

[PATCH v2 0/2] perf tool: improve error handling in perf_flag_probe()

kernel.org/r/1406908014-8312-1-git-send-email-jo...@kernel.org [2] http://lkml.kernel.org/r/cover.1425901229.git.ydrone...@opteya.com [3] http://lkml.kernel.org/r/cover.1410595700.git.ydrone...@opteya.com [4] http://lkml.kernel.org/r/20140920121438.gb15...@krava.brq.redhat.com Yann Droneaud (2):

[PATCH v2 0/2] perf tool: improve error handling in perf_flag_probe()

kernel.org/r/1406908014-8312-1-git-send-email-jo...@kernel.org [2] http://lkml.kernel.org/r/cover.1425901229.git.ydrone...@opteya.com [3] http://lkml.kernel.org/r/cover.1410595700.git.ydrone...@opteya.com [4] http://lkml.kernel.org/r/20140920121438.gb15...@krava.brq.redhat.com Yann Droneaud (2):

[PATCH v2 1/2] perf tools: shortcut PERF_FLAG_FD_CLOEXEC probing in case of EBUSY error

; Cc: Stephane Eranian <eran...@google.com> Cc: William Cohen <wco...@redhat.com> Link: http://lkml.kernel.org/r/cover.1443708092.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud <ydrone...@opteya.com> --- tools/perf/util/cloexec.c | 8 ++-- 1 file changed, 6 insertions(

[PATCH v2 2/2] perf tools: report PERF_FLAG_FD_CLOEXEC probing error once

Cc: William Cohen <wco...@redhat.com> Link: http://lkml.kernel.org/r/cover.1443708092.git.ydrone...@opteya.com Reported-by: Jiri Olsa <jo...@kernel.org> Signed-off-by: Yann Droneaud <ydrone...@opteya.com> --- tools/perf/util/cloexec.c | 25 + 1 file change

Re: [PATCH] uapi: remove i2o header in uapi

perv.h header-y += hysdn_if.h header-y += i2c-dev.h header-y += i2c.h -header-y += i2o-dev.h header-y += i8k.h header-y += icmp.h header-y += icmpv6.h Note, you may also use git format-patch -D to reduce the size of your patch. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from thi

Re: [PATCH v2 1/2] perf tools: shortcut PERF_FLAG_FD_CLOEXEC probing in case of EBUSY error

Hi, Le jeudi 01 octobre 2015 à 22:52 +0200, Jiri Olsa a écrit : > On Thu, Oct 01, 2015 at 05:16:25PM +0200, Yann Droneaud wrote: > > This patch is a simplification of the logic introduced as part of > > commit 63914aca8f7e ('perf tools: Show better error message in case >

[-stable] perf/x86: Fix copy_from_user_nmi() return if range is not ok

Hi, I believe commit ebf2d2689de551d90965090bb991fc640a0c0d41 ("perf/x86: Fix copy_from_user_nmi() return if range is not ok") should be applied to stable kernels starting from v3.13.y up to v4.1.y. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line &q

[-stable] perf/x86: Fix copy_from_user_nmi() return if range is not ok

Hi, I believe commit ebf2d2689de551d90965090bb991fc640a0c0d41 ("perf/x86: Fix copy_from_user_nmi() return if range is not ok") should be applied to stable kernels starting from v3.13.y up to v4.1.y. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line &q

[tip:perf/urgent] perf/x86: Fix copy_from_user_nmi() return if range is not ok

Commit-ID: ebf2d2689de551d90965090bb991fc640a0c0d41 Gitweb: http://git.kernel.org/tip/ebf2d2689de551d90965090bb991fc640a0c0d41 Author: Yann Droneaud AuthorDate: Mon, 22 Jun 2015 21:38:43 +0200 Committer: Ingo Molnar CommitDate: Mon, 6 Jul 2015 14:09:27 +0200 perf/x86: Fix

[tip:perf/urgent] perf/x86: Fix copy_from_user_nmi() return if range is not ok

Commit-ID: ebf2d2689de551d90965090bb991fc640a0c0d41 Gitweb: http://git.kernel.org/tip/ebf2d2689de551d90965090bb991fc640a0c0d41 Author: Yann Droneaud ydrone...@opteya.com AuthorDate: Mon, 22 Jun 2015 21:38:43 +0200 Committer: Ingo Molnar mi...@kernel.org CommitDate: Mon, 6 Jul 2015 14:09

[PATCH] x86: fix copy_from_user_nmi() return if range is not ok

copied, eg. 0, instead of the remaining bytes. As all users of copy_from_user_nmi() were modified as part of commit 0a196848ca36, the function should be fixed to return the total number of bytes if range is not correct. Signed-off-by: Yann Droneaud --- arch/x86/lib/usercopy.c | 2 +- 1 file

[PATCH] x86: fix copy_from_user_nmi() return if range is not ok

. 0, instead of the remaining bytes. As all users of copy_from_user_nmi() were modified as part of commit 0a196848ca36, the function should be fixed to return the total number of bytes if range is not correct. Signed-off-by: Yann Droneaud ydrone...@opteya.com --- arch/x86/lib/usercopy.c | 2 +- 1

[PATCH v1 1/3] fs: use seq_open_private() for proc_mounts

m Signed-off-by: Yann Droneaud --- fs/mount.h | 3 --- fs/namespace.c | 6 +++--- fs/proc_namespace.c | 34 -- 3 files changed, 19 insertions(+), 24 deletions(-) diff --git a/fs/mount.h b/fs/mount.h index b5b8082bfa42..14db05d424f7 100644 --- a/fs/moun

[PATCH v1 3/3] fs: documents seq_open()'s usage of file->private_data

seq_open() store its struct seq_file in file->private_data, thus, it must not be modified by user of seq_file. Link: http://lkml.kernel.org/r/cover.1433193673.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud --- fs/seq_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a

[PATCH v1 2/3] fs: allocate structure unconditionally in seq_open()

n(). Link: http://lkml.kernel.org/r/cover.1433193673.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud --- fs/seq_file.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/seq_file.c b/fs/seq_file.c index c14f6a43beb5..a909f12dad4d 100644 --- a/fs/seq_file.c +++

[PATCH v1 0/3] No more seq_file pre-allocation

pen(). Changes from v0 [0]: - convert kmalloc() + memset() to kzalloc() - revised a bit commit messages [0] [PATCH 0/3] seq_file allocation in seq_open() http://lkml.kernel.org/r/cover.1430777196.git.ydrone...@opteya.com http://lkml.kernel.org/g/cover.1430777196.git.ydrone...@opteya.com Yann Droneaud

[PATCH v1 0/3] No more seq_file pre-allocation

(). Changes from v0 [0]: - convert kmalloc() + memset() to kzalloc() - revised a bit commit messages [0] [PATCH 0/3] seq_file allocation in seq_open() http://lkml.kernel.org/r/cover.1430777196.git.ydrone...@opteya.com http://lkml.kernel.org/g/cover.1430777196.git.ydrone...@opteya.com Yann Droneaud (3

[PATCH v1 2/3] fs: allocate structure unconditionally in seq_open()

(). Link: http://lkml.kernel.org/r/cover.1433193673.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud ydrone...@opteya.com --- fs/seq_file.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/seq_file.c b/fs/seq_file.c index c14f6a43beb5..a909f12dad4d 100644

[PATCH v1 3/3] fs: documents seq_open()'s usage of file-private_data

seq_open() store its struct seq_file in file-private_data, thus, it must not be modified by user of seq_file. Link: http://lkml.kernel.org/r/cover.1433193673.git.ydrone...@opteya.com Signed-off-by: Yann Droneaud ydrone...@opteya.com --- fs/seq_file.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH v1 1/3] fs: use seq_open_private() for proc_mounts

Signed-off-by: Yann Droneaud ydrone...@opteya.com --- fs/mount.h | 3 --- fs/namespace.c | 6 +++--- fs/proc_namespace.c | 34 -- 3 files changed, 19 insertions(+), 24 deletions(-) diff --git a/fs/mount.h b/fs/mount.h index b5b8082bfa42

Re: Device Tree Blob (DTB) licence

Hi, [removing Cc: licens...@fsf.org] Le vendredi 22 mai 2015 à 12:05 +0200, Yann Droneaud a écrit : > Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : > > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud > > > > wrote: > > > > > > I believe

Re: Device Tree Blob (DTB) licence

Hi, Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud > wrote: > > > > I believe Device Tree Blob (.dtb file) built from kernel's Device > > Tree > > Sources (.dts, which #include .dtsi, which #include

Re: Device Tree Blob (DTB) licence

Hi, Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud ydrone...@opteya.com wrote: I believe Device Tree Blob (.dtb file) built from kernel's Device Tree Sources (.dts, which #include .dtsi, which #include .h) using Device

Re: Device Tree Blob (DTB) licence

Hi, [removing Cc: licens...@fsf.org] Le vendredi 22 mai 2015 à 12:05 +0200, Yann Droneaud a écrit : Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud ydrone...@opteya.com wrote: I believe Device Tree Blob (.dtb file) built

Device Tree Blob (DTB) licence

(any combination of X11, MIT, BSD, GPLv2). Regards. -- Yann Droneaud OPTEYA -- 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 re

Device Tree Blob (DTB) licence

(any combination of X11, MIT, BSD, GPLv2). Regards. -- Yann Droneaud OPTEYA -- 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

  1   2   3   4   5   >