concerned, these are the only additional
cases to cater for since they cover all characters that have a special
meaning in that context.
Signed-off-by: Siddhesh Poyarekar
Cc: Florian Weimer
---
fs/namespace.c | 5 +
fs/proc_namespace.c | 2 +-
2 files changed, 6 insertions(+), 1 deletio
concerned, these are the only additional
cases to cater for since they cover all characters that have a special
meaning in that context.
Signed-off-by: Siddhesh Poyarekar
Cc: Florian Weimer
---
Changes from v2:
- Check for blank name after the string has been duplicated into
kernelspace.
fs/n
On 12/16/20 10:03 AM, Al Viro wrote:
Once more, with feeling: why bother? What's wrong
with using the damn strndup_user() and then doing
whatever checks you want with the data already
copied, living in normal kernel memory, with all
string functions applicable, etc.?
I was trying to avoid the
concerned, these are the only additional
cases to cater for since they cover all characters that have a special
meaning in that context.
Signed-off-by: Siddhesh Poyarekar
Cc: Florian Weimer
---
Changes from V1:
- Break out a separate routine copy_mount_devname for device name copy.
- Rename copy_mo
On 12/15/20 11:40 AM, Al Viro wrote:
On Tue, Dec 15, 2020 at 09:54:54AM +0530, Siddhesh Poyarekar wrote:
+ get_user(byte, (const char __user *)data);
+
+ return byte ? strndup_user(data, PATH_MAX) : NULL;
}
No. Not to mention anything else, you
* fetch the same data
concerned, these are the only additional
cases to cater for since they cover all characters that have a special
meaning in that context.
Signed-off-by: Siddhesh Poyarekar
Cc: Florian Weimer
---
fs/namespace.c | 8 +++-
fs/proc_namespace.c | 2 +-
2 files changed, 8 insertions(+), 2 deletion
On 08/06/2018 04:01 PM, Mikulas Patocka wrote:
I think there are three possible solutions:
1. provide an alternative memcpy implementation that doesn't do unaligned
accesses and recompile the graphics software with -mstrict-align
Given that there's already a tunable glibc.cpu.cached_memopt for
On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
> + d) CPU Identification :
> +MIDR_EL1 is exposed to help identify the processor. On a
> +heterogeneous system, this could be racy (just like getcpu()). The
> +process could be migrated to another CPU by the time it uses th
On Wednesday 30 November 2016 05:00 PM, Suzuki K Poulose wrote:
>> This doesn't seem to be implemented in this patchset.
>
> This is already available upstream.
Ah OK, I seem to have missed that thread.
Thanks,
Siddhesh
On Tuesday 27 October 2015 11:39 PM, Suzuki K. Poulose wrote:
> I am afraid that would impose a new ABI with complications on how we
> handle information about the CPUs in different states (online, offline,
> etc). I am open to suggestions here.
No I agree it would be non-trivial to maintain this
On Tuesday 13 October 2015 10:52 PM, Suzuki K. Poulose wrote:
> Apart from the selected feature registers, we expose MIDR_EL1 (Main
> ID Register). The user should be aware that, reading MIDR_EL1 can be
> tricky on a heterogeneous system (just like getcpu()). We export the
> value of the current CP
On 14 January 2015 at 19:43, Rasmus Villemoes wrote:
> Just thinking out loud: Could one simply mark a VMA as being used for
> stack during the clone call (is there room in vm_flags, or does
> VM_GROWSDOWN already tell the whole story?), and then write the TID into
> a new field in the VMA - I thi
On 27 June 2013 21:32, Jan Glauber wrote:
> But isn't that confusing to the user? At least it is to me. Imagine someone
> who uses the maps or smaps output to determine the size of code, data and
> stack of a process. Maybe it would be better to not print the stack:tid data
> at all if the kernel
On 26 June 2013 17:13, Jan Glauber wrote:
> Any ideas how that can be fixed? The only solution that comes to my mind
> is to prevent merging vma's that are used for thread stacks. There is already
> a
> flag (MAP_STACK) which is set by the libc for mmap'ing thread stacks but the
> kernel currentl
On 25 October 2012 10:06, Darren Hart wrote:
> Absolutely, that was great. Siddhesh, any objection to this test being
> incorporated into futextest?
>
> http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary
>
I have no objection to the test being incorporated into futextest.
T
> Now there is a different solution to that problem. Do not look at the
> user space value at all and enforce a lookup of possibly available
> pi_state. If pi_state can be found, then the new incoming locker T3
> blocks on that pi_state and legitimately races with T2 to acquire the
> rt_mutex and t
report:
http://sourceware.org/bugzilla/show_bug.cgi?id=14076
Signed-off-by: Siddhesh Poyarekar
---
kernel/futex.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3717e7b..9aa2d5a 100644
--- a/kernel/futex.c
+++ b/kernel
report:
http://sourceware.org/bugzilla/show_bug.cgi?id=14076
Signed-off-by: Siddhesh Poyarekar
---
kernel/futex.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3717e7b..9aa2d5a 100644
--- a/kernel/futex.c
+++ b/kernel
report:
http://sourceware.org/bugzilla/show_bug.cgi?id=14076
Signed-off-by: Siddhesh Poyarekar
---
kernel/futex.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3717e7b..9aa2d5a 100644
--- a/kernel/futex.c
+++ b/kernel
19 matches
Mail list logo
