On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
> 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
On Thu, 17 Jan 2019 23:13:28 +1100
Michael Ellerman wrote:
> On machines with 1TB segments and a 32-entry SLB it's quite hard to
> cause sufficient SLB pressure to trigger bugs caused due to badly
> timed SLB faults.
>
> We have seen this in the past and a few years ago added the
>
On 1/18/19 12:14 PM, Arnd Bergmann wrote:
On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote:
On 1/18/19 11:18 AM, Arnd Bergmann wrote:
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns
On 1/18/19 11:18 AM, Arnd Bergmann wrote:
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns about the contents. The first
version did not see a lot of replies, which could mean that
either
On Fri, Jan 18, 2019 at 11:28:24PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
>
> > On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote:
> >> The recent rewrite of the SLB code into C included the assumption that
> >> all CPUs we run on have at least 32 SLB entries.
On Fri, Dec 21, 2018 at 8:43 AM Madalin Bucur wrote:
>
> By clearing all interrupt sources, not only those that
> already occurred, the existing code may acknowledge by
> mistake interrupts that occurred after the code checks
> for them.
>
> Signed-off-by: Madalin Bucur
> Signed-off-by: Roy
On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote:
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote:
> I think we have two issues if we reuse those numbers for new syscalls.
> First, I'd really like to see new syscalls be numbered consistently
> everywhere, or at least on all x86 variants, and we can't on x32
> because they mean something
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
>
> On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > - Once we get to 512, we clash with the x32 numbers (unless
> > > we remove x32 support first), and probably have to
On Fri, Jan 18, 2019 at 01:16:24PM +, Viorel Suman wrote:
> > > 1. Moved "dais" node from machine driver DTS node to device driver
> > > DTS node
> > > as suggested by Rob.
> > That was not what I suggested. You still have a virtual node which
> > looks to me to be unnecessary.
>
> To me
On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > - Once we get to 512, we clash with the x32 numbers (unless
> > we remove x32 support first), and probably have to skip
> > a few more. I also considered using the 512..547 space
On Fri, Jan 18, 2019 at 6:20 PM Gabriel Paubert wrote:
>
> On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
> > 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
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This
The pull request you sent on Fri, 18 Jan 2019 23:45:09 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.0-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c5b709804ed7d36c45b5efa170d9e3ea8c29b865
Thank you!
--
Hi Mike,
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only
Hi Mike,
On Wed, Jan 16, 2019 at 03:44:12PM +0200, Mike Rapoport wrote:
> The last parameter of memblock_alloc_from() is the lower limit for the
> memory allocation. When it is 0, the call is equivalent to
> memblock_alloc().
>
> Signed-off-by: Mike Rapoport
Acked-by: Paul Burton # MIPS part
On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote:
>
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64.
However, for consistency it seems better to have the 32-bit
From: Deepa Dinamani
struct timex is not y2038 safe.
Switch all the syscall apis to use y2038 safe __kernel_timex.
Note that sys_adjtimex() does not have a y2038 safe solution. C libraries
can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).
Signed-off-by: Deepa Dinamani
sparc64 is the only architecture on Linux that has a 'timeval'
definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes
problems for sparc32 compat mode when we convert it to use the
new __kernel_timex type that has the same layout as all other
64-bit architectures.
To avoid adding
This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.
This gets us to the point of being able to safely use a C library
that
A lot of system calls that pass a time_t somewhere have an implementation
using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
been reworked so that this implementation can now be used on 32-bit
architectures as well.
The missing step is to redefine them using the regular
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
abd use the _time32 system calls from the former compat layer instead
of the system calls that take __kernel_timespec and similar arguments.
The temporary redirects for __kernel_timespec, __kernel_itimerspec
and
x32 has always followed the time64 calling conventions of these
syscalls, which required a special hack in compat_get_timespec
aka get_old_timespec32 to continue working.
Since we now have the time64 syscalls, use those explicitly.
Signed-off-by: Arnd Bergmann
---
From: Deepa Dinamani
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.
Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there
A small typo has crept into the y2038 conversion of the timer_settime
system call. So far this was completely harmless, but once we start
using the new version, this has to be fixed.
Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec")
Signed-off-by: Arnd Bergmann
---
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns about the contents. The first
version did not see a lot of replies, which could mean that
either everyone is happy with it, or that it was
We now use 64-bit time_t on all architectures, so the __kernel_timex,
__kernel_timeval and __kernel_timespec redirects can be removed
after having served their purpose.
This makes it all much less confusing, as the __kernel_* types
now always refer to the same layout based on 64-bit time_t across
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
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,
We want to reuse the compat_timex handling on 32-bit architectures the
same way we are using the compat handling for timespec when moving to
64-bit time_t.
Move all definitions related to compat_timex out of the compat code
into the normal timekeeping code, along with a rename to old_timex32,
From: Deepa Dinamani
struct timex uses struct timeval internally.
struct timeval is not y2038 safe.
Introduce a new UAPI type struct __kernel_timex
that is y2038 safe.
struct __kernel_timex uses a timeval type that is
similar to struct __kernel_timespec which preserves the
same structure size
These are all for ignoring the lack of obsolete system calls,
which have been marked the same way in scripts/checksyscall.sh,
so these can be removed.
Signed-off-by: Arnd Bergmann
---
arch/mips/include/asm/unistd.h | 16
arch/parisc/include/asm/unistd.h | 3 ---
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
Alpha has traditionally followed the OSF1 calling conventions
here, with its getxpid, getxuid, getxgid system calls returning
two different values in separate registers.
Following what glibc has done here, we can define getpid,
getuid and getgid to be aliases for getxpid, getxuid and getxgid
As Joseph Myers points out, alpha has never had a standard statfs64
interface and instead returns only 32-bit numbers here.
While there is an old osf_statfs64 system call that returns additional
data, this has some other quirks and does not get used in glibc.
I considered making the stat64
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
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
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
---
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
__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
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 the system call on arm64
systems in compat mode, and also reduces the
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 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 +
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
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
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
Hello Christoph,
I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your
Git powerpc-dma.6-debug today.
Unfortunately I don't see any error messages (kernel ring buffer) and I
don't have a RS232 serial null modem cable to get them.
Cheers,
Christian
On Thu, Jan 17, 2019 at 09:49:05AM -0200, Breno Leitao wrote:
hi Sasha,
On 1/16/19 11:35 AM, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: e1c3743e1a20 powerpc/tm: Set MSR[TS] just prior to recheckpoint.
Commit 8ce5f8415753 ("of: Remove struct device_node.type pointer")
removed struct device_node.type pointer, but the conversion to use
of_node_is_type() accessor was missed in chrp_init_IRQ().
Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
Reported-by: kbuild test robot
Cc:
Hi Rob, Nicolin, All,
On Jo, 2019-01-17 at 10:18 -0600, Rob Herring wrote:
> On Thu, Jan 17, 2019 at 12:46:25PM +, Viorel Suman wrote:
> >
> > The patchset adds NXP Audio Mixer (AUDMIX) device and machine
> > drivers and related DT bindings documentation.
> >
> > Changes since V2:
> > 1.
On Fri, Jan 18, 2019 at 01:46:46PM +0100, Christian Zigotzky wrote:
> Sorry, it's not possible to patch
> '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it
> manually but without any success.
Weird:
hch@carbon:~/work/linux$ git checkout
Sorry, it's not possible to patch
'257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried
it manually but without any success.
-- Christian
On 18 January 2019 at 1:18PM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
git clone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Linus,
Please pull some more powerpc fixes for 5.0:
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the git repository at:
Segher Boessenkool writes:
> On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote:
>> The recent rewrite of the SLB code into C included the assumption that
>> all CPUs we run on have at least 32 SLB entries. This is currently
>> true but a bit fragile as the SLB size is actually
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>
>
> I get the following error message with your patch:
Hmm. Did I attached the wrong patch?
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 257002094bc5935dd63207a380d9698ab81f0775
I get the following error message with your patch:
patching file a/kernel/dma/direct.c
Hunk #1 FAILED at 118.
Hunk #2 FAILED at 139.
2 out of 2 hunks FAILED -- saving
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h
vb2_dc_get_userptr pokes into arm direct mapping details to get the
resemblance of a dma address for a a physical address that does is
not backed by a page struct. Not only is this not portable to other
architectures with dma direct mapping offsets, but also not to uses
of IOMMUs of any kind.
Hi all,
this series fixes a rather gross layering violation in videobuf2, which
pokes into arm DMA mapping internals to get a DMA address for memory that
does not have a page structure, and to do so fixes up the dma_map_resource
implementation to not provide a somewhat dangerous default and
Instead provide a proper implementation in the direct mapping code, and
also wire it up for arm and powerpc, leaving an error return for all the
IOMMU or virtual mapping instances for which we'd have to wire up an
actual implementation
Signed-off-by: Christoph Hellwig
---
On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
> For which commit?
On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
one you identified as breaking the detection of the SATA disks.
For which commit?
-- Christian
On 18 January 2019 at 09:35AM, Christoph Hellwig wrote:
Hi Christian,
can you check if the debug printks in this patch trigger?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++
Hi Hans,
On Fri, Jan 18, 2019 at 11:08 AM Hans Verkuil wrote:
> This patch is still in my patchwork todo list, and I wonder who will pick
> this up,
> especially the change to arch/powerpc/include/asm/io.h.
I think the powerpc tree makes most sense.
> Wouldn't it be easier to just fix this in
Hi Geert,
This patch is still in my patchwork todo list, and I wonder who will pick this
up,
especially the change to arch/powerpc/include/asm/io.h.
Wouldn't it be easier to just fix this in fsl-viu.c only by doing this:
#ifndef CONFIG_PPC
#ifndef out_be32
#define out_be32(v, a)
On Fri, Jan 18, 2019 at 1:53 AM Tobias Ulmer wrote:
>
> On Fri, Jan 18, 2019 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2019-01-17 at 10:42 +0100, Tobias Ulmer wrote:
> > > On Wed, Jan 16, 2019 at 12:15:14PM +1100, Benjamin Herrenschmidt wrote:
> > > > On Tue, 2019-01-15 at
On Thu, Jan 17, 2019 at 9:40 PM Sabyasachi Gupta
wrote:
>
> Remove linux/printk.h which is included more than once.
>
> Signed-off-by: Sabyasachi Gupta
Acked-by: Souptick Joarder
> ---
> arch/powerpc/platforms/powernv/opal.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
On Fri, Jan 18, 2019 at 01:22:41PM +1100, Paul Mackerras wrote:
> On Tue, Jan 15, 2019 at 11:49:45PM +0100, Tobias Ulmer wrote:
> > Hi,
> >
> > both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Interesting, I just built v4.20 with g5_defconfig for my quad and it
> booted
Hi Christoph,
On 2019-01-17 18:21, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
>> On 2019-01-11 19:17, Christoph Hellwig wrote:
>>> vb2_dc_get_userptr pokes into arm direct mapping details to get the
>>> resemblance of a dma address for a a
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant
On Wed, Jan 16, 2019 at 03:44:21PM +0200, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/arc/kernel/unwind.c | 3 +--
>
Hi Christian,
can you check if the debug printks in this patch trigger?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device
> Yeah I noticed this just yesterday.
Just FYI this has been accepted as regression in gcc, and fixed is
provided for GCC 9.0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
73 matches
Mail list logo
