On Thu, Jan 10, 2019 at 05:24:27PM +0100, Arnd Bergmann wrote:
> A couple of architectures including arm64 already implement the
> kexec_file_load system call, on many others we have assigned a system
> call number for it, but not implemented it yet.
>
> Adding the number in arch/arm/ lets us use
On Thu, Jan 10, 2019 at 05:24:26PM +0100, Arnd Bergmann wrote:
> The migrate_pages system call has an assigned number on all architectures
> except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
> Fix warning: #warning syscall migrate_pages not implemented"), it was
> intentionally
While reading through the sysvipc implementation, I noticed that the n32
semctl/shmctl/msgctl system calls behave differently based on whether
o32 support is enabled or not: Without o32, the IPC_64 flag passed by
user space is rejected but calls without that flag get IPC_64 behavior.
As far as I
__kernel_timespec and timespec are currently the same type, but once
they are different, the type cast has to be changed here.
Signed-off-by: Arnd Bergmann
---
arch/sparc/kernel/sys_sparc_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
For shmat, alpha uses the osf_shmat name, we can do
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl
b/arch/ia64/kernel/syscalls/syscall.tbl
Most architectures have assigned numbers for both seccomp and
perf_event_open, even when they do not implement either.
ia64 is an exception here, so for consistency lets add numbers for both
of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
the system calls just return
The migrate_pages system call has an assigned number on all architectures
except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
Fix warning: #warning syscall migrate_pages not implemented"), it was
intentionally left out based on the observation that there are no 32-bit
ARM NUMA
The io_pgetevents system call was added in linux-4.18 but has
no entry for alpha:
warning: #warning syscall io_pgetevents not implemented [-Wcpp]
Assign a the next system call number here.
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
Most architectures have assigned a numbers for the seccomp syscall
even when they do not implement it.
m68k is an exception here, so for consistency lets add the number.
Unless CONFIG_SECCOMP is implemented, the system call just
returns -ENOSYS.
Signed-off-by: Arnd Bergmann
---
Most architectures define system call numbers for the rseq and pkey system
calls, even when they don't support the features, and perhaps never will.
Only a few architectures are missing these, so just define them anyway
for consistency. If we decide to add them later to one of these, the
system
The system call tables have diverged a bit over the years, and a number
of the recent additions never made it into all architectures, for one
reason or another.
This is an attempt to clean it up as far as we can without breaking
compatibility, doing a number of steps:
- Add system calls that
The behavior of these system calls is slightly different between
architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
symbol. Most architectures that implement the split IPC syscalls don't set
that symbol and only get the modern version, but alpha, arm, microblaze,
mips-n32,
The IPC system call handling is highly inconsistent across architectures,
some use sys_ipc, some use separate calls, and some use both. We also
have some architectures that require passing IPC_64 in the flags, and
others that set it implicitly.
For the additon of a y2083 safe semtimedop() system
statx is available on almost all other architectures but
got missed on sh, so add it now.
Signed-off-by: Arnd Bergmann
---
arch/sh/kernel/syscalls/syscall.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/kernel/syscalls/syscall.tbl
b/arch/sh/kernel/syscalls/syscall.tbl
index
When I merged this patch, the file was accidentally left intact
instead of being removed, which means any changes to syscall.tbl
have no effect.
Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
Signed-off-by: Arnd Bergmann
---
arch/sh/include/uapi/asm/unistd_32.h
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
The __IGNORE_* lines are now all obsolete and can be
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
For PowerPC PMUs that do not support context exclusion let's
advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
perf will prevent us from handling events where any exclusion flags
are set. Let's also remove the now unnecessary check for exclusion
flags.
Signed-off-by: Andrew
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
Update design.txt to reflect the presence of the exclude_host
and exclude_guest perf flags.
Signed-off-by: Andrew Murray
---
tools/perf/design.txt | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/design.txt b/tools/perf/design.txt
index a28dca2..0453ba2 100644
---
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
PMU drivers that support at
Add a function that tests if any of the perf event exclusion flags
are set on a given event.
Signed-off-by: Andrew Murray
---
include/linux/perf_event.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d5c551..54a78d2
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags. This approach is error prone and
often
As the Alpha PMU doesn't support context exclusion let's advertise
the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
The ARM PMU driver can be used to represent a variety of ARM based
PMUs. Some of these PMUs do not provide support for context
exclusion, where this is the case we advertise the
PERF_PMU_CAP_NO_EXCLUDE capability to ensure that perf prevents us
from handling events where any exclusion flags are
For x86 PMUs that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
Now that perf_flags is not used we remove it.
Signed-off-by: Andrew Murray
---
include/uapi/linux/perf_event.h | 2 --
tools/include/uapi/linux/perf_event.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags.
However this approach requires that each time a
Peter Zijlstra writes:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any exclusion flags are set.
On Mon, Jan 07, 2019 at 04:27:30PM +, Andrew Murray wrote:
> The Cavium ThunderX2 UNCORE PMU driver doesn't support any event
> filtering. Let's advertise the PERF_PMU_CAP_NO_EXCLUDE capability to
> simplify the code.
>
> Signed-off-by: Andrew Murray
> ---
> drivers/perf/thunderx2_pmu.c |
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
From: Deepa Dinamani
Date: Mon, 7 Jan 2019 19:26:49 -0800
> The series introduces new socket timestamps that are
> y2038 safe.
Great discussion, but this is definitely net-next material and the net-next
tree is not open at this time.
On Tue, Jan 8, 2019 at 12:10 PM Arnd Bergmann wrote:
>
> This is a cleanup to prepare for the addition of 64-bit time_t
> in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
> unnecessarily complex and error-prone, moving it all into the
> main setsockopt()/getsockopt() implementation
On Tue, Jan 8, 2019 at 12:04 PM Arnd Bergmann wrote:
>
> On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani wrote:
> >
> > SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> > as the time format. struct timeval is not y2038 safe.
> > The subsequent patches in the series add support for
This is a cleanup to prepare for the addition of 64-bit time_t
in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
unnecessarily complex and error-prone, moving it all into the
main setsockopt()/getsockopt() implementation requires half
as much code and is easier to extend.
32-bit user
On Tue, Jan 8, 2019 at 6:24 AM Deepa Dinamani wrote:
>
> SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> as the time format. struct timeval is not y2038 safe.
> The subsequent patches in the series add support for new socket
> timeout options with _NEW suffix that are y2038 safe.
On Tue, Jan 08, 2019 at 11:36:33AM -0500, Boris Ostrovsky wrote:
> On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> > On the various exclude options; they are as follows (IIUC):
> >
> > - exclude_guest: we're a HV/host-kernel and we don't want the counter
> >to run when we run a
On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any
On Tue, Jan 08, 2019 at 01:13:57PM +, Andrew Murray wrote:
> On Tue, Jan 08, 2019 at 02:10:31PM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
> >
> > > Yes I found lots of examples like this across the tree whilst doing this
> > > work.
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of
On Tue, Jan 8, 2019 at 8:37 AM Willem de Bruijn
wrote:
>
> On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
> >
> > The series introduces new socket timestamps that are
> > y2038 safe.
> >
> > The time data types used for the existing socket timestamp
> > options: SO_TIMESTAMP,
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
> for all architectures.
>
> Signed-off-by: Deepa Dinamani
> Cc: ch...@zankel.net
> Cc: fenghua...@intel.com
> Cc:
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> The series introduces new socket timestamps that are
> y2038 safe.
>
> The time data types used for the existing socket timestamp
> options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING
> are not y2038 safe. The series introduces
On Tue, Jan 08, 2019 at 02:10:31PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
>
> > Yes I found lots of examples like this across the tree whilst doing this
> > work. However I decided to initially start with simply removing duplicated
> > code
On Tue, Jan 08, 2019 at 11:48:41AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
> > For drivers that do not support context exclusion let's advertise the
> > PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
> > prevent us from handling
On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote:
> Yes I found lots of examples like this across the tree whilst doing this
> work. However I decided to initially start with simply removing duplicated
> code as a result of adding this flag and attempting to preserve existing
>
On Tue, Jan 08, 2019 at 11:49:40AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:28PM +, Andrew Murray wrote:
>
> This patch has the exact same subject as the previous one.. that seems
> sub-optimal.
Ah yes, I'll update that in subsquent revisions. (The reason for two patches
On Tue, Jan 08, 2019 at 11:28:02AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:22PM +, Andrew Murray wrote:
> > @@ -393,9 +386,8 @@ __hw_perf_event_init(struct perf_event *event)
> > /*
> > * Check whether we need to exclude the counter from certain modes.
> > */
On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
> For drivers that do not support context exclusion let's advertise the
> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
> prevent us from handling events where any exclusion flags are set.
> Let's also remove the now
On Mon, Jan 07, 2019 at 04:27:28PM +, Andrew Murray wrote:
This patch has the exact same subject as the previous one.. that seems
sub-optimal.
On Mon, Jan 07, 2019 at 04:27:22PM +, Andrew Murray wrote:
> @@ -393,9 +386,8 @@ __hw_perf_event_init(struct perf_event *event)
> /*
>* Check whether we need to exclude the counter from certain modes.
>*/
> + if (armpmu->set_event_filter &&
> +
SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
as the time format. struct timeval is not y2038 safe.
The subsequent patches in the series add support for new socket
timeout options with _NEW suffix that are y2038 safe.
Rename the existing options with _OLD suffix forms so that the
Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
for all architectures.
Signed-off-by: Deepa Dinamani
Cc: ch...@zankel.net
Cc: fenghua...@intel.com
Cc: r...@twiddle.net
Cc: t...@linutronix.de
Cc: ubr...@linux.ibm.com
Cc:
SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING options, the
way they are currently defined, are not y2038 safe.
Subsequent patches in the series add new y2038 safe versions
of these options which provide 64 bit timestamps on all
architectures uniformly.
Hence, rename existing options with OLD
Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
socket timestamp options.
These are the y2038 safe versions of the SO_TIMESTAMP_OLD
and SO_TIMESTAMPNS_OLD for all architectures.
Note that the format of scm_timestamping.ts[0] is not changed
in this patch.
Signed-off-by: Deepa Dinamani
The series introduces new socket timestamps that are
y2038 safe.
The time data types used for the existing socket timestamp
options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING
are not y2038 safe. The series introduces SO_TIMESTAMP_NEW,
SO_TIMESTAMPNS_NEW and SO_TIMESTAMPING_NEW to replace
On Mon, Jan 07, 2019 at 11:02:36AM -0800, Paul E. McKenney wrote:
> On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > > > On Mon, Jan
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > > > On 2019/1/3
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
The Cavium ThunderX2 UNCORE PMU driver doesn't support any event
filtering. Let's advertise the PERF_PMU_CAP_NO_EXCLUDE capability to
simplify the code.
Signed-off-by: Andrew Murray
---
drivers/perf/thunderx2_pmu.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
The ARM PMU driver can be used to represent a variety of ARM based
PMUs. Some of these PMUs do not provide support for context
exclusion, where this is the case we advertise the
PERF_PMU_CAP_NO_EXCLUDE capability to ensure that perf prevents us
from handling events where any exclusion flags are
For x86 PMUs that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
For PowerPC PMUs that do not support context exclusion let's
advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
perf will prevent us from handling events where any exclusion flags
are set. Let's also remove the now unnecessary check for exclusion
flags.
Signed-off-by: Andrew
Now that perf_flags is not used we remove it.
Signed-off-by: Andrew Murray
---
include/uapi/linux/perf_event.h | 2 --
tools/include/uapi/linux/perf_event.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
Add a function that tests if any of the perf event exclusion flags
are set on a given event.
Signed-off-by: Andrew Murray
---
include/linux/perf_event.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d5c551..54a78d2
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags. This approach is error prone and
often
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags.
However this approach requires that each time a
Update design.txt to reflect the presence of the exclude_host
and exclude_guest perf flags.
Signed-off-by: Andrew Murray
---
tools/perf/design.txt | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/design.txt b/tools/perf/design.txt
index a28dca2..0453ba2 100644
---
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > How about naming the thing: dependent_ptr() ? That is without any (r)mb
> > implications at all. The address dependency is strictly weaker than an
> > rmb in
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
syscall_get_* functions are required to be implemented on all
architectures in order to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request.
This adds remaining 4 syscall_get_* functions as documented
in asm-generic/syscall.h: syscall_get_nr, syscall_get_arguments,
On Wed, Jan 02, 2019 at 01:00:24PM -0800, Matthew Wilcox wrote:
> On Wed, Jan 02, 2019 at 03:57:58PM -0500, Michael S. Tsirkin wrote:
> > @@ -875,6 +893,8 @@ to the CPU containing it. See the section on
> > "Multicopy atomicity"
> > for more information.
> >
> >
> > +
> > +
> > In summary:
On Wed, Jan 02, 2019 at 03:57:58PM -0500, Michael S. Tsirkin wrote:
> @@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy
> atomicity"
> for more information.
>
>
> +
> +
> In summary:
>
>(*) Control dependencies can order prior loads against later stores.
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for this.
However, if the first access was a read and the second used an address
depending on the first one we would have a data dependency and no
barrier would
The pull request you sent on Sun, 30 Dec 2018 17:25:19 -0500:
> https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f12e840c819bab42621685558a01d3f46ab9a226
Thank you!
--
Deet-doot-dot, I am a
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This bug caused overwriting of ps,pc,gp registers instead
of fixing intended r16,r17,r18 (see `struct pt_regs`).
More details:
Initially Dmitry noticed a kernel bug as a failure
on strace
Hi Linus,
Please pull a few small changes for alpha as well as the new system call table
generation support from Firoz Khan.
Thanks,
Matt
The following changes since commit 9097a058d49e049925d8da72db07fffcee24efa0:
Merge branch 'i2c/for-current' of
Hi Matt,
On Fri, 21 Dec 2018 11:46:59 -0500 Matt Turner wrote:
>
> Probably so. This is just a super part-time thing for me, so I've
> never figured out what I needed to do to be included in linux-next.
The requirements are:
"You will need to ensure that the patches/commits in your tree/series
Btw, can you try wit the very latests dma-mapping-for-next tree
which has a new fix from Thierry Reding that might be related.
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote:
> On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> > Hi Christoph,
> >
> > I test kernel from your 'dma-alloc-always-zero' branch, and as
> > I can see we have DMA peripherals (like USB) broken.
>
> I would be really
Hi Christoph,
I test kernel from your 'dma-alloc-always-zero' branch, and as
I can see we have DMA peripherals (like USB) broken.
There are the errors example I got during USB initializing:
-->8
usb 1-1: device descriptor read/64, error
On Wed, Dec 19, 2018 at 4:59 PM Matt Turner wrote:
> On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan wrote:
> > On Tue, 13 Nov 2018 at 15:02, Firoz Khan wrote:
> >
> > Could someone review this patch series and queue it for 4.21
> > through alpha tree would be great.
>
> Thank you! I'll take a
FYI, I've picked this up for dma-mapping for-next now.
On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan wrote:
>
> Hi Folks,
>
> On Tue, 13 Nov 2018 at 15:02, Firoz Khan wrote:
> >
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> >
On Tue, Dec 18, 2018 at 8:33 AM Arnd Bergmann wrote:
>
> On Sat, Dec 15, 2018 at 7:52 PM Willem de Bruijn
> wrote:
> >
> > > 3 reasons for not doing this:
> > >
> > > 1. We do not want to break userspace. If we move this to
> > > linux/socket.h all the userspace programs now have to include
> >
On Tue, Dec 18, 2018 at 8:16 AM Arnd Bergmann wrote:
>
> On Wed, Dec 12, 2018 at 4:25 PM Willem de Bruijn
> wrote:
> > On Tue, Dec 11, 2018 at 3:30 PM Deepa Dinamani
> > wrote:
>
> > > @@ -851,39 +890,7 @@ int sock_setsockopt(struct socket *sock, int level,
> > > int optname,
> > >
On Sat, Dec 15, 2018 at 7:52 PM Willem de Bruijn
wrote:
>
> > 3 reasons for not doing this:
> >
> > 1. We do not want to break userspace. If we move this to
> > linux/socket.h all the userspace programs now have to include
> > linux/socket.h or get this definition through a new libc.
> > 2. All
On Wed, Dec 12, 2018 at 4:25 PM Willem de Bruijn
wrote:
> On Tue, Dec 11, 2018 at 3:30 PM Deepa Dinamani wrote:
> > @@ -851,39 +890,7 @@ int sock_setsockopt(struct socket *sock, int level,
> > int optname,
> > break;
> >
> > case SO_TIMESTAMPING_OLD:
> > -
At present there are multiple places where invalid node number is encoded
as -1. Even though implicitly understood it is always better to have macros
in there. Replace these open encodings for an invalid node number with the
global macro NUMA_NO_NODE. This helps remove NUMA related assumptions
From: Stephen Rothwell
This replaces all open encodings in tools with NUMA_NO_NODE.
Also linux/numa.h is now needed for the perf build.
Signed-off-by: Anshuman Khandual
Signed-off-by: Stephen Rothwell
---
tools/include/linux/numa.h | 16
tools/perf/bench/numa.c| 6
Changes in V3:
- Dropped all references to NUMA_NO_NODE as per Lubomir Rinetl
- Split the patch into two creating a new one specifically for tools
- Folded Stephen's linux-next build fix into the second patch
Changes in V2: (https://patchwork.kernel.org/patch/10698089/)
- Added inclusion of
> > Also for the other comment. The reason the conditionals were not
> > consistent is because they were not consistent to begin with.
>
> The only difference I see is an inversion of the test. Nesting order
> is the same:
>
> int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
>
> 3 reasons for not doing this:
>
> 1. We do not want to break userspace. If we move this to
> linux/socket.h all the userspace programs now have to include
> linux/socket.h or get this definition through a new libc.
> 2. All the socket options are together in the file asm/socket.h. It
> doesn't
On Sat, Dec 15, 2018 at 7:12 AM Willem de Bruijn
wrote:
>
> On Fri, Dec 14, 2018 at 8:07 PM Deepa Dinamani wrote:
> >
> > > > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > > > b/arch/alpha/include/uapi/asm/socket.h
> > > > index 00e45c80e574..352e3dc0b3d9 100644
> > > > ---
On Fri, Dec 14, 2018 at 8:07 PM Deepa Dinamani wrote:
>
> > > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > > b/arch/alpha/include/uapi/asm/socket.h
> > > index 00e45c80e574..352e3dc0b3d9 100644
> > > --- a/arch/alpha/include/uapi/asm/socket.h
> > > +++
1101 - 1200 of 2609 matches
Mail list logo
