Le 13/12/2019 à 22:34, Rob Herring a écrit :
On Thu, Nov 28, 2019 at 12:16:35PM +, Christophe Leroy wrote:
Since commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO
descriptors"), the prefered way to define chipselect GPIOs is using
'cs-gpios' property instead of the legacy 'gpios'
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via unpin_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
On Wed, 11 Dec 2019 09:38:39 -0600, Thomas Falcon wrote:
> This conditional is missing a bang, with the intent
> being to break when the retry count reaches zero.
>
> Fixes: 476d96ca9c ("ibmvnic: Bound waits for device queries")
> Suggested-by: Juliet Kim
> Signed-off-by: Thomas Falcon
Ah
On Fri, Dec 13, 2019 at 1:33 PM Arnd Bergmann wrote:
>
> A few hundred randconfig (x86, arm32 and arm64) builds later I
> still only found one other instance:
Just send me the pull request to READ_ONCE() and WRITE_ONCE() be
arithmetic types, and your two trivial fixes, and let's get this over
On 13/12/19 2:16 am, Daniel Axtens wrote:
> powerpc has a variable number of PTRS_PER_*, set at runtime based
> on the MMU that the kernel is booted under.
>
> This means the PTRS_PER_* are no longer constants, and therefore
> breaks the build.
>
> Define default MAX_PTRS_PER_*s in the same
On Thu, Nov 28, 2019 at 12:16:35PM +, Christophe Leroy wrote:
> Since commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO
> descriptors"), the prefered way to define chipselect GPIOs is using
> 'cs-gpios' property instead of the legacy 'gpios' property.
This will break using a new dtb on a
On Fri, Dec 13, 2019 at 2:17 PM Arnd Bergmann wrote:
>
> On Thu, Dec 12, 2019 at 9:50 PM Linus Torvalds
> wrote:
> I'll have my randconfig builder look for instances, so far I found one,
> see below. My feeling is that it would be better to enforce at least
> the size being a 1/2/4/8, to avoid
On Fri, 2019-12-13 at 03:50:35 UTC, Michael Ellerman wrote:
> From: Srikar Dronamraju
>
> With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on
> pre-empted vCPUs"), the scheduler avoids preempted vCPUs to schedule
> tasks on wakeup. This leads to wrong choice of CPU, which in-turn
>
On Mon, 2019-06-24 at 14:41:48 UTC, Frederic Barrat wrote:
> If an ocxl device is unbound through sysfs at the same time its AFU is
> being opened by a user process, the open code may dereference freed
> stuctures, which can lead to kernel oops messages. You'd have to hit a
> tiny time window, but
Segher Boessenkool writes:
> Hi!
>
> On Fri, Dec 13, 2019 at 11:07:55PM +1100, Michael Ellerman wrote:
>> I tried this:
>>
>> > @@ -295,6 +296,23 @@ void __write_once_size(volatile void *p, void *res,
>> > int size)
>> > */
>> > #define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
>> >
>> >
On Fri, Dec 13, 2019 at 07:45:36PM +1100, Alexey Kardashevskiy wrote:
> By default a pseries guest supports a H_PUT_TCE hypercall which maps
> a single IOMMU page in a DMA window. Additionally the hypervisor may
> support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once;
> this is
Hi Christophe,
On 12/13/19 5:47 AM, Christophe Leroy wrote:
> Le 13/12/2019 à 01:05, Dmitry Safonov a écrit :
[..]
>
> powerpc patchwork didn't get the full series, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=148198
Yes, I was under impression that architecture
On Thu, 2019-12-12 at 11:53 +1100, Michael Ellerman wrote:
> Thadeu Lima de Souza Cascardo writes:
[...]
> > This is a patch on binutils carried by Fedora:
> >
> > https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
> >
> > " b8265c Have readelf display extra
Add support of KASAN_VMALLOC on PPC32.
To allow this, the early shadow covering the VMALLOC space
need to be removed once high_memory var is set and before
freeing memblock.
And the VMALLOC area need to be aligned such that boundaries
are covered by a full shadow page.
Signed-off-by: Christophe
On Fri, Dec 13, 2019 at 01:56:18PM +0100, Peter Zijlstra wrote:
>
> Excellent! I had to change it to something like:
>
> #define unqual_typeof(x)typeof(({_Atomic typeof(x) ___x __maybe_unused;
> ___x; }))
>
> but that does indeed work!
>
> Now I suppose we should wrap that in a symbol
Hi!
On Fri, Dec 13, 2019 at 11:07:55PM +1100, Michael Ellerman wrote:
> I tried this:
>
> > @@ -295,6 +296,23 @@ void __write_once_size(volatile void *p, void *res,
> > int size)
> > */
> > #define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
> >
> > +#else /* GCC_VERSION < 40800 */
> > +
> >
Hi Christophe,
- We run a lot of code at boot in real mode. This includes stuff like
printk(), so it's not feasible to just disable instrumentation
around it.
>>>
>>> Have you definitely given up the idea of doing a standard implementation
>>> of KASAN like other 64
On Thu, Dec 12, 2019 at 9:50 PM Linus Torvalds
wrote:
> On Thu, Dec 12, 2019 at 11:34 AM Will Deacon wrote:
> > The root of my concern in all of this, and what started me looking at it in
> > the first place, is the interaction with 'typeof()'. Inheriting 'volatile'
> > for a pointer means that
On Fri, Dec 13, 2019 at 11:47:06AM +0100, Luc Van Oostenryck wrote:
> On Thu, Dec 12, 2019 at 09:53:38PM +0100, Peter Zijlstra wrote:
> > Now, looking at the current GCC source:
> >
> >
> > https://github.com/gcc-mirror/gcc/blob/97d7270f894395e513667a031a0c309d1819d05e/gcc/c/c-parser.c#L3707
>
Le 12/12/2019 à 16:16, Daniel Axtens a écrit :
KASAN support on Book3S is a bit tricky to get right:
- It would be good to support inline instrumentation so as to be able to
catch stack issues that cannot be caught with outline mode.
- Inline instrumentation requires a fixed offset.
Peter Zijlstra writes:
> On Thu, Dec 12, 2019 at 10:07:56AM +, Will Deacon wrote:
>
>> > So your proposed change _should_ be fine. Will, I'm assuming you never
>> > saw this on your ARGH64 builds when you did this code ?
>>
>> I did see it, but (a) looking at the code out-of-line makes it
Le 10/12/2019 à 06:10, Daniel Axtens a écrit :
Christophe Leroy writes:
Le 07/08/2019 à 01:38, Daniel Axtens a écrit :
KASAN support on powerpc64 is interesting:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run
On Thu, Dec 12, 2019 at 09:53:38PM +0100, Peter Zijlstra wrote:
> Now, looking at the current GCC source:
>
>
> https://github.com/gcc-mirror/gcc/blob/97d7270f894395e513667a031a0c309d1819d05e/gcc/c/c-parser.c#L3707
>
> it seems that __typeof__() is supposed to strip all qualifiers from
>
Alexey Kardashevskiy writes:
> From: Ram Pai
>
> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> secure guests")
> disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
> path for secure VMs, helped enable dma_direct path. This enabled
>
Alexey Kardashevskiy writes:
> H_PUT_TCE_INDIRECT uses a 4K page with TCEs to allow handling up to 512
> TCEs per hypercall. While it is a decent optimization, we rather share
> less of secure VM memory so let's avoid sharing.
>
> This only allows H_PUT_TCE_INDIRECT for normal (not secure) VMs.
Fedora binutils has been patched to show "other info" for a symbol at the
end of the line. This was done in order to support unmaintained scripts
that would break with the extra info. [1]
[1]
https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
This in turn has
Srikar Dronamraju writes:
> * Michael Ellerman [2019-12-13 14:50:35]:
>
>> Waiman Long suggested using static_keys.
>>
>> Fixes: 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted
>> vCPUs")
>> Cc: sta...@vger.kernel.org # v4.18+
>> Reported-by: Parth Shah
>> Reported-by: Ihor
This enables IOMMU for SVM. Instead of sharing
a H_PUT_TCE_INDIRECT page, this uses H_PUT_TCE for mapping
and H_STUFF_TCE for clearing TCEs which should bring
acceptable performance at the boot time; otherwise things
work with the same speed anyway.
Please comment. Thanks.
Alexey Kardashevskiy
H_PUT_TCE_INDIRECT uses a 4K page with TCEs to allow handling up to 512
TCEs per hypercall. While it is a decent optimization, we rather share
less of secure VM memory so let's avoid sharing.
This only allows H_PUT_TCE_INDIRECT for normal (not secure) VMs.
This keeps using H_STUFF_TCE as it does
By default a pseries guest supports a H_PUT_TCE hypercall which maps
a single IOMMU page in a DMA window. Additionally the hypervisor may
support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once;
this is advertised via the device tree /rtas/ibm,hypertas-functions
property which
From: Ram Pai
Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
secure guests")
disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
path for secure VMs, helped enable dma_direct path. This enabled
support for bounce-buffering through
31 matches
Mail list logo
