Hi,
Le mardi 14 octobre 2014 à 12:57 +1100, Michael Ellerman a écrit :
> On Mon, 2014-10-13 at 21:30 +0200, Yann Droneaud wrote:
> > This patch replaces calls to get_unused_fd() with equivalent call to
> > get_unused_fd_flags(0) to preserve current behavor for existing code.
> &
Hi,
Le mercredi 01 octobre 2014 à 15:36 -0700, Andrew Morton a écrit :
> On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud wrote:
>
> > According to commit 80af258867648 ('fanotify: groups can specify
> > their f_flags for new fd'), file descriptors create
|FAN_FD_CLOEXEC,
O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
Signed-off-by: Yann Droneaud
---
Hi Andrew,
While I believe fanotify_init() must enable close-on-exec
when requested by userspace to prevent unwelcomed security
issue, I understand your concerns regarding the possible
Hi,
Le jeudi 02 octobre 2014 à 10:13 +0100, Pádraig Brady a écrit :
> On 10/02/2014 08:52 AM, Yann Droneaud wrote:
> > In order to not potentially break applications which were
> > requesting O_CLOEXEC on event file descriptors but which
> > actually need it to be not ef
Cc: Richard Guy Briggs
Cc: Eric Paris
Cc: Al Viro
Cc: Andrew Morton
Cc: sta...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Reviewed-by: Jan Kara
Reviewed by: Heinrich Schuchardt
Tested-by: Heinrich Schuchardt
Signed-off-by: Yann Droneaud
---
Hi Andrew,
> Fair enough, it sounds like
/2014/kernel-recipes/lightning-talk-kernel-userspace-ABI/
[2] https://gitorious.org/opteya/talk-kernel-userspace-abi
[3] http://kernel.recipes/
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
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: Yan
ail-ydrone...@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/cocci
, 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
er
Cc: Himangi Saraogi
Cc: Geert Uytterhoeven
Cc: 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.co
pages()
- 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 alloc
er
Cc: Himangi Saraogi
Cc: Geert Uytterhoeven
Cc: 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/f
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/cocci
, 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
Cc: Anton Blanchard
Cc: Benjamin Herrenschmidt
Fixes: 1d18c47c735e ('arm64: MMU fault handling and page table management')
Signed-off-by: Yann Droneaud
---
arch/arm64/mm/mmap.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/mm/mmap.c b/a
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 #inc
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
ts the use of file->private_data
to hold pointer to struct seq_file.
Yann Droneaud (3):
fs: use seq_open_private() for proc_mounts
fs: allocate structure unconditionally in seq_open()
fs: documents seq_open()'s usage of file->private_data
fs/mount.h | 3 ---
fs/namespac
seq_open() stores 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.1430777196.git.ydrone...@opteya.com
Signed-off-by: Yann Droneaud
---
fs/seq_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a
q_open().
Link: http://lkml.kernel.org/r/cover.1430777196.git.ydrone...@opteya.com
Signed-off-by: Yann Droneaud
---
fs/seq_file.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 555f82155be8..cb9c3dbd1a1e 100644
--- a/fs/seq_file.
ed to use seq_release_private(),
in order to release the private structure allocated by
seq_open_private().
Then, ->private is used directly instead of proc_mounts()
macro to access to the proc_mounts structure.
Link: http://lkml.kernel.org/r/cover.1430777196.git.ydrone...@opteya.com
Signed-
, dual licensed
(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.ht
Most headers for InfiniBand/RDMA are located under
include/rdma/ and include/uapi/rdma.
Signed-off-by: Yann Droneaud
---
Hi,
While checking if Doug Ledford was added as maintainer for IB subsystem
(and git tree updated), I've found the headers in rdma/ were not identified
as being part
error.
Cc: Adrian Hunter
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.1425901229.git.ydrone...@opteya.com
Signed-off-by: Yann Droneaud
---
tool
g/r/1406908014-8312-1-git-send-email-jo...@kernel.org
[2] http://lkml.kernel.org/r/cover.1410595700.git.ydrone...@opteya.com
[3] http://lkml.kernel.org/r/20140920121438.gb15...@krava.brq.redhat.com
Yann Droneaud (2):
perf tools: shortcut PERF_FLAG_FD_CLOEXEC probing in case of EBUSY
Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: William Cohen
Link: http://lkml.kernel.org/r/cover.1425901229.git.ydrone...@opteya.com
Reported-by: Jiri Olsa
Signed-off-by: Yann Droneaud
---
tools/perf/util/cloexec.c | 25 +
1
om happening?
> If not, should I post a patch that fixes it to LKML? Or is it
> considered too "theoretical" and cannot happen in practice?
>
I haven't looked at your explanations, you should have come with a
reproductible test case to demonstrate the issue (involving sl
n.
>
> Sorry for sending this at the very end of the release cycle, but we
> didn't realize the scope of the required fix until just now.
>
I hope this could go in v3.19 as, at this stage, we don't want to expose
any bits of this ABI in a released kernel.
Regards.
--
Ya
he compiler.
In the end, people not sane enough can do not so useful
thing such as 'make W=123e'.
Signed-off-by: Yann Droneaud
---
Makefile | 1 +
scripts/Makefile.extrawarn | 4
2 files changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index 6b69223a5
x % 32));
> >
> > - if (srq->idx_bit_fields[i] & mask)
> > - srq->idx_bit_fields[i] &= ~mask;
> > - else
> > - srq->idx_bit_fields[i] |= mask;
> > + srq->idx_bit_fields[i] ^= mask;
> > }
> >
>
ude/linux/dmar.h
Simplify include/linux/dmar.h a bit based on the fact that
both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP select CONFIG_DMAR_TABLE.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send t
if
>
> while (1) {
> /* check cloexec flag */
I've reviewed the use of __GLIBC_PREREQ(2, 6), but not whether using cpu
= 0 is OK if sched_getcpu() is not available.
Reviewed-by: Yann Droneaud
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this
hink it would punch a hole in chroot() ... (but in 2019, nobody
should rely on it for security purpose).
Regards.
--
Yann Droneaud
OPTEYA
standard, 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
can't 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
d from userspace.
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
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
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
>
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, timer->star
) % 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
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
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 particula
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 Dro
lting 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 ---
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
t 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 ++
.org/
[3] https://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 change
kargs->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(&kargs, uargs, size);
> + if (err)
> + return err;
> +
> + return _do_fork(&kargs);
> }
> #endif
>
Regards.
--
Yann Droneaud
OPTEYA
esult 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.
> +};
&
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.
> > >
> > >
to set to 0 in each
canary ?
Regards.
--
Yann Droneaud
OPTEYA
goto 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
Commit-ID: a21b0b354d4ac39be691f51c53562e2c24443d9e
Gitweb: http://git.kernel.org/tip/a21b0b354d4ac39be691f51c53562e2c24443d9e
Author: Yann Droneaud
AuthorDate: Sun, 5 Jan 2014 21:36:33 +0100
Committer: Ingo Molnar
CommitDate: Sun, 12 Jan 2014 10:16:59 +0100
perf: Introduce a flag to
Commit-ID: 26f7f9877234e6b9ed87eff4ca450631bafe0182
Gitweb: http://git.kernel.org/tip/26f7f9877234e6b9ed87eff4ca450631bafe0182
Author: Yann Droneaud
AuthorDate: Sat, 11 Jan 2014 18:48:15 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 13 Jan 2014 17:20:05 -0300
perf tools
Commit-ID: 57480d2cd93579d665e57e144e1e63f7f02ef058
Gitweb: http://git.kernel.org/tip/57480d2cd93579d665e57e144e1e63f7f02ef058
Author: Yann Droneaud
AuthorDate: Mon, 30 Jun 2014 22:28:47 +0200
Committer: Jiri Olsa
CommitDate: Fri, 18 Jul 2014 09:09:34 +0200
perf tools: Enable close-on
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
201 - 256 of 256 matches
Mail list logo
