On Wed, Nov 13, 2019 at 02:45:15PM +, Robin Murphy wrote:
> In all honesty, this seems silly. If we can set a per-device flag to say
> "oh, bypass these ops and use some other ops instead", then we can just as
> easily simply give the device the appropriate ops in the first place.
> Because,
On Wed, Nov 13, 2019 at 05:13:39PM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a
On 11/14/19 12:50 PM, Oliver O'Halloran wrote:
On Thu, Nov 14, 2019 at 6:19 PM Madhavan Srinivasan
wrote:
When a root user or a user with CAP_SYS_ADMIN
privilege use trace_imc performance monitoring
unit events, to monitor application or KVM threads,
may result in a checkstop (System crash).
On Thu, Nov 14, 2019 at 6:19 PM Madhavan Srinivasan
wrote:
>
> When a root user or a user with CAP_SYS_ADMIN
> privilege use trace_imc performance monitoring
> unit events, to monitor application or KVM threads,
> may result in a checkstop (System crash). Reason
> being frequent switch of the "tra
When a root user or a user with CAP_SYS_ADMIN
privilege use trace_imc performance monitoring
unit events, to monitor application or KVM threads,
may result in a checkstop (System crash). Reason
being frequent switch of the "trace/accumulation"
mode of In-Memory Collection hardware.
This patch disab
On Thu, Nov 14, 2019 at 04:08:25PM +1100, Paul Mackerras wrote:
> On Wed, Nov 13, 2019 at 01:50:42PM -0800, Ram Pai wrote:
> > On Thu, Nov 14, 2019 at 08:18:24AM +1100, Paul Mackerras wrote:
> > > On Tue, Nov 12, 2019 at 10:32:33PM -0800, Ram Pai wrote:
> > > > On Wed, Nov 13, 2019 at 11:14:27AM +1
On 11/13/19 3:22 PM, John Hubbard wrote:
> On 11/13/19 2:43 AM, Jan Kara wrote:
> ...
>> How does FOLL_PIN result in grabbing (at least normal, for now) page
>> reference?
>> I didn't find that anywhere in this patch but it is a prerequisite to
>> converting any user to pin_user_pages() interface,
On Tue, Nov 12, 2019 at 05:59:41PM +1100, Andrew Donnellan wrote:
> From: Nicholas Piggin
>
> Commit ff45000fcb56b5b0f1a14a865d3541746d838a0a upstream.
>
> The boot wrapper performs its own relocations and does not require
> PT_INTERP segment. However currently we don't tell the linker that.
>
On Tue, Nov 12, 2019 at 07:52:24PM +1100, Andrew Donnellan wrote:
> Dear stable team
>
> Please backport the following patches.
>
> Commits:
>
> - 164af597ce945751e2dcd53d0a86e84203a6d117
> ("powerpc/Makefile: Use cflags-y/aflags-y for setting endian options")
>
> - 4dc831aa88132f835cefe876aa
On 2019/11/13 17:23, Michael Ellerman wrote:
It needs to use PTRRELOC() for the kernstart_virt_addr accesses.
I've made that change and squashed it into the series. I've pushed that
as a branch to here:
https://github.com/linuxppc/linux/commits/topic/kaslr-book3e32
That boots for me on q
On Thu, Nov 14, 2019 at 03:49:45PM +1100, Aleksa Sarai wrote:
> On 2019-11-13, Al Viro wrote:
> > On Tue, Nov 05, 2019 at 08:05:47PM +1100, Aleksa Sarai wrote:
> >
> > > @@ -862,6 +870,8 @@ static int nd_jump_root(struct nameidata *nd)
> > > void nd_jump_link(struct path *path)
> > > {
> > >
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> - /*
> -* Determine if we need Soft-UART mode
> -*/
> if (of_find_property(np, "soft-uart", NULL)) {
> dev_dbg(&ofdev->dev, "using Soft-UART mode\n");
> soft_uart = 1;
> +
On 11/12/19 1:14 AM, Rasmus Villemoes wrote:
but that's because readl and writel by definition work on little-endian
registers. I.e., on a BE platform, the readl and writel implementation
must themselves contain a swab, so the above would end up doing two
swabs on a BE platform.
Do you know whe
On Wed, Nov 13, 2019 at 01:50:42PM -0800, Ram Pai wrote:
> On Thu, Nov 14, 2019 at 08:18:24AM +1100, Paul Mackerras wrote:
> > On Tue, Nov 12, 2019 at 10:32:33PM -0800, Ram Pai wrote:
> > > On Wed, Nov 13, 2019 at 11:14:27AM +1100, Paul Mackerras wrote:
> > > > On Tue, Nov 12, 2019 at 06:45:55AM -0
On Wed, Nov 13, 2019 at 08:59:08PM +0530, Bharata B Rao wrote:
> On Tue, Nov 12, 2019 at 04:34:34PM +1100, Paul Mackerras wrote:
> > On Mon, Nov 04, 2019 at 09:47:58AM +0530, Bharata B Rao wrote:
> > [snip]
> > > @@ -5442,6 +5471,64 @@ static int kvmhv_store_to_eaddr(struct kvm_vcpu
> > > *vcpu, u
On 2019-11-13, Aleksa Sarai wrote:
> On 2019-11-13, Al Viro wrote:
> > Minor nit here - I'd split "move the conditional call of set_root()
> > into nd_jump_root()" into a separate patch before that one. Makes
> > for fewer distractions in this one. I'd probably fold "and be
> > ready for errors
On 2019-11-13, Al Viro wrote:
> On Tue, Nov 05, 2019 at 08:05:47PM +1100, Aleksa Sarai wrote:
>
> > @@ -862,6 +870,8 @@ static int nd_jump_root(struct nameidata *nd)
> > void nd_jump_link(struct path *path)
> > {
> > struct nameidata *nd = current->nameidata;
> > +
> > + nd->last_magiclin
On 11/13/19 11:09 AM, Ira Weiny wrote:
...
diff --git a/mm/gup.c b/mm/gup.c
index 82e7e4ce5027..90f5f95ee7ac 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1756,11 +1756,11 @@ long get_user_pages(unsigned long start, unsigned long
nr_pages,
struct vm_area_struct **vmas)
{
/*
On 11/13/19 2:43 AM, Jan Kara wrote:
...
How does FOLL_PIN result in grabbing (at least normal, for now) page reference?
I didn't find that anywhere in this patch but it is a prerequisite to
converting any user to pin_user_pages() interface, right?
ohhh, I messed up on this intermediate patch:
On 11/13/19 3:15 AM, Jan Kara wrote:
On Tue 12-11-19 20:26:49, John Hubbard wrote:
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and won
On Wed, Nov 13, 2019 at 02:00:06PM -0800, Dan Williams wrote:
> On Wed, Nov 13, 2019 at 11:23 AM Dan Williams
> wrote:
> >
> > On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
> > >
> > > An upcoming patch changes and complicates the refcounting and
> > > especially the "put page" aspects of
On 11/13/19 2:55 PM, Dan Williams wrote:
On Wed, Nov 13, 2019 at 2:49 PM John Hubbard wrote:
On 11/13/19 2:00 PM, Dan Williams wrote:
...
Ugh, when did all this HMM specific manipulation sneak into the
generic ZONE_DEVICE path? It used to be gated by pgmap type with its
own put_zone_device_pr
On Wed, Nov 13, 2019 at 2:49 PM John Hubbard wrote:
>
> On 11/13/19 2:00 PM, Dan Williams wrote:
> ...
> >> Ugh, when did all this HMM specific manipulation sneak into the
> >> generic ZONE_DEVICE path? It used to be gated by pgmap type with its
> >> own put_zone_device_private_page(). For example
On 11/13/19 2:00 PM, Dan Williams wrote:
...
Ugh, when did all this HMM specific manipulation sneak into the
generic ZONE_DEVICE path? It used to be gated by pgmap type with its
own put_zone_device_private_page(). For example it's certainly
unnecessary and might be broken (would need to check) to
On Friday, November 8, 2019 10:12:11 PM CET Arnd Bergmann wrote:
> All of the remaining syscalls that pass a timeval (gettimeofday, utime,
> futimesat) can trivially be changed to pass a __kernel_old_timeval
> instead, which has a compatible layout, but avoids ambiguity with
> the timeval type in u
Hi all,
After merging the powerpc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
security/integrity/platform_certs/load_uefi.c:17:19: warning:
'efi_cert_sha256_guid' defined but not used [-Wunused-variable]
17 | static efi_guid_t efi_cert_sha256_guid __initdata =
On Wed, Nov 13, 2019 at 11:23 AM Dan Williams wrote:
>
> On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
> >
> > An upcoming patch changes and complicates the refcounting and
> > especially the "put page" aspects of it. In order to keep
> > everything clean, refactor the devmap page release r
On Fri, 8 Nov 2019, Arnd Bergmann wrote:
> The gettimeofday() function in vdso uses the traditional 'timeval'
> structure layout, which will be incompatible with future versions of
> glibc on 32-bit architectures that use a 64-bit time_t.
>
> This interface is problematic for y2038, when time_t o
On Thu, Nov 14, 2019 at 08:18:24AM +1100, Paul Mackerras wrote:
> On Tue, Nov 12, 2019 at 10:32:33PM -0800, Ram Pai wrote:
> > On Wed, Nov 13, 2019 at 11:14:27AM +1100, Paul Mackerras wrote:
> > > On Tue, Nov 12, 2019 at 06:45:55AM -0800, Ram Pai wrote:
> > > > On Tue, Nov 12, 2019 at 10:32:04PM +1
On Fri, Nov 8, 2019 at 10:04 PM Arnd Bergmann wrote:
>
> This is a series of cleanups for the y2038 work, mostly intended
> for namespace cleaning: the kernel defines the traditional
> time_t, timeval and timespec types that often lead to y2038-unsafe
> code. Even though the unsafe usage is mostly
On Mon, Nov 11, 2019 at 05:18:23PM +0800, Shengjiu Wang wrote:
> There are two asrc module in imx8qm, each module has different
> clock configuration, and the DMA type is EDMA.
>
> So in this patch, we define the new clocks, refine the clock map,
> and include struct fsl_asrc_soc_data for differen
On 2019-11-13 8:41 pm, Florian Fainelli wrote:
On 11/13/19 12:34 PM, Robin Murphy wrote:
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mappin
On Tue, Nov 12, 2019 at 10:32:33PM -0800, Ram Pai wrote:
> On Wed, Nov 13, 2019 at 11:14:27AM +1100, Paul Mackerras wrote:
> > On Tue, Nov 12, 2019 at 06:45:55AM -0800, Ram Pai wrote:
> > > On Tue, Nov 12, 2019 at 10:32:04PM +1100, Paul Mackerras wrote:
> > > > On Mon, Nov 11, 2019 at 11:52:15PM -0
On 11/13/19 12:34 PM, Robin Murphy wrote:
> On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
>> Using a mask to represent bus DMA constraints has a set of limitations.
>> The biggest one being it can only hold a power of two (minus one). The
>> DMA mapping code is already aware of this and trea
Nothing but pedantic spelling and grammar nits of the commit log follow.
-Tyrel
On 11/13/19 1:40 AM, Oliver O'Halloran wrote:
> On PowerNV the PCIe topology is (currently) managed the powernv platform
s/the powernv/by the powernv
> code in cooperation with firmware. The PCIe-native service driv
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is alre
On 11/13/19 3:43 AM, Daniel Vetter wrote:
...
Can't we call this unpin_user_page then, for some symmetry? Or is that
even more churn?
Looking from afar the naming here seems really confusing.
That look from afar is valuable, because I'm too close to the problem to see
how the naming looks. :)
On 11/13/19 10:59 AM, Ira Weiny wrote:
On Tue, Nov 12, 2019 at 08:26:56PM -0800, John Hubbard wrote:
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented
On 11/13/19 11:17 AM, Ira Weiny wrote:
...
@@ -348,33 +347,13 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
flags |= FOLL_WRITE;
down_read(&mm->mmap_sem);
- if (mm == current->mm) {
- ret = get_user_pages(vaddr, 1, flags | FOLL_
Hi Sergey,
On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those f
On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek wrote:
> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.
I'm in favor of this patchset too. If there's other areas that need to
adjust the curre
On Wed, 6 Nov 2019 23:25:13 +
Russell King - ARM Linux admin wrote:
> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it
On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
Unfortunately that is the case. As my tests will fail if a backtrace i
On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky wrote:
> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> printk_emergency_enter(log_level);
> __show_stack(task, sp);
> printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - -
On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky wrote:
> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.
> >
>
On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
>
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_
On Wed, Nov 13, 2019 at 09:02:02AM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 12, 2019 at 08:26:55PM -0800, John Hubbard wrote:
> > As it says in the updated comment in gup.c: current FOLL_LONGTERM
> > behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> > FS DAX check requirement
On Tue, Nov 12, 2019 at 08:26:51PM -0800, John Hubbard wrote:
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is
On Tue, Nov 12, 2019 at 08:27:10PM -0800, John Hubbard wrote:
> Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
> have been converted to pin_longterm_pages(), lock it down:
>
> 1) Add an assertion to get_user_pages(), preventing callers from
>passing FOLL_LONGTERM (in additi
On Tue, Nov 12, 2019 at 08:27:08PM -0800, John Hubbard wrote:
> Up until now, gup_benchmark supported testing of the
> following kernel functions:
>
> * get_user_pages(): via the '-U' command line option
> * get_user_pages_longterm(): via the '-L' command line option
> * get_user_pages_fast(): as
On Tue, Nov 12, 2019 at 08:27:09PM -0800, John Hubbard wrote:
> It's good to have basic unit test coverage of the new FOLL_PIN
> behavior. Fortunately, the gup_benchmark unit test is extremely
> fast (a few milliseconds), so adding it the the run_vmtests suite
> is going to cause no noticeable chan
On Tue, Nov 12, 2019 at 08:27:07PM -0800, John Hubbard wrote:
> Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
> instead of a hard-coded "1" value.
>
> Also, clean up the filtering of gup flags a little, by just doing
> it once before issuing any of the get_user_pages*() calls. This
>
On Tue, Nov 12, 2019 at 08:26:56PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() varia
On Tue, Nov 12, 2019 at 08:26:55PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_r
On Wed, Nov 13, 2019 at 2:43 AM Jan Kara wrote:
>
> On Tue 12-11-19 20:26:56, John Hubbard wrote:
> > Introduce pin_user_pages*() variations of get_user_pages*() calls,
> > and also pin_longterm_pages*() variations.
> >
> > These variants all set FOLL_PIN, which is also introduced, and
> > thoroug
On Tue, Nov 12, 2019 at 08:26:50PM -0800, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Simple enough...
Reviewed-by: Ira Weiny
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set.
> > See
> > + * get_user_pages_fast() for documentation on the function arguments,
> > because
> > + * the arguments here a
On 13/11/2019 17:46, Greg Kurz wrote:
> We need to check the host page size is big enough to accomodate the
> EQ. Let's do this before taking a reference on the EQ page to avoid
> a potential leak if the check fails.
>
> Cc: sta...@vger.kernel.org # v5.2
> Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV
We need to check the host page size is big enough to accomodate the
EQ. Let's do this before taking a reference on the EQ page to avoid
a potential leak if the check fails.
Cc: sta...@vger.kernel.org # v5.2
Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ
configuration")
S
The EQ page is allocated by the guest and then passed to the hypervisor
with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page
before handing it over to the HW. This reference is dropped either when
the guest issues the H_INT_RESET hcall or when the KVM device is released.
But, the
Signed-off-by: Michal Suchanek
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eb19fad370d7..2e6c187bc98c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12772,6 +12772,8 @@ F: arch/*/kernel/*/perf_event*.c
F: arch/*/kernel/*/*/perf_e
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
Wi
Many of the performance moniroting unit (PMU) SPRs are
exposed in the sysfs. "perf" API is the primary interface to program
PMU and collect counter data in the system. So expose these
PMU SPRs in the absence of CONFIG_PERF_EVENTS.
Patch adds a new CONFIG option 'CONFIG_PMU_SYSFS'. The new config
o
On Tue, Nov 12, 2019 at 04:34:34PM +1100, Paul Mackerras wrote:
> On Mon, Nov 04, 2019 at 09:47:58AM +0530, Bharata B Rao wrote:
> [snip]
> > @@ -5442,6 +5471,64 @@ static int kvmhv_store_to_eaddr(struct kvm_vcpu
> > *vcpu, ulong *eaddr, void *ptr,
> > return rc;
> > }
> >
> > +/*
> > + *
On 13/11/2019 1:37 pm, Christoph Hellwig wrote:
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve p
On Wed, Nov 13, 2019 at 08:40:35PM +1100, Oliver O'Halloran wrote:
> On PowerNV the PCIe topology is (currently) managed the powernv platform
> code in cooperation with firmware. The PCIe-native service drivers bypass
> both and this can cause problems.
>
> Historically this hasn't been a big deal
Use the DMA API bypass mechanism for direct window mappings. This uses
common code and speed up the direct mapping case by avoiding indirect
calls just when not using dma ops at all. It also fixes a problem where
the sync_* methods were using the bypass check for DMA allocations, but
those are pa
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Signed-off-by: Christoph Hellwig
---
include/linux/device.h | 4 +
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve performance. The powerpc
code already has a simila
On Tue, Nov 12, 2019 at 08:26:55PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_r
On Wed, Nov 13, 2019 at 11:12:10AM +0100, Jan Kara wrote:
> On Wed 13-11-19 01:02:02, John Hubbard wrote:
> > On 11/13/19 12:22 AM, Daniel Vetter wrote:
> > ...
> > > > > Why are we doing this? I think things got confused here someplace, as
> > > >
> > > >
> > > > Because:
> > > >
> > > > a) The
On Tue 12-11-19 20:26:49, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle diffe
David Hildenbrand writes:
> On 12.11.19 11:46, Michael Ellerman wrote:
>> David Hildenbrand writes:
>>> On 31.10.19 15:29, David Hildenbrand wrote:
We can now get rid of the cmm_lock and completely rely on the balloon
compaction internals, which now also manage the page list and the loc
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/p
Interesting. Give me some time to come up with a real fix, as drivers
really should not mess with GFP flags for these allocations, and even
if they did swiotlb is supposed to take care of any resulting problems.
https://bugzilla.kernel.org/show_bug.cgi?id=205201
--- Comment #14 from Christian Zigotzky (chzigot...@xenosoft.de) ---
Created attachment 285889
--> https://bugzilla.kernel.org/attachment.cgi?id=285889&action=edit
Patch for renaming the GFP_DMA32 to GFP_DMA
Hi All,
The issue with the BT878 TV
On Tue 12-11-19 20:26:48, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Cc: Kiri
On Tue 12-11-19 20:26:50, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Looks good. You can add:
Reviewed-by: Jan Kara
On Tue 12-11-19 20:26:51, John Hubbard wrote:
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_managed(
On Tue 12-11-19 20:26:56, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() variants also set FOL
On Wed, 2019-11-13 at 08:35 +0100, Christoph Hellwig wrote:
> Hi all,
>
> there is no good reason to have different version of dma_capable.
> This series removes the arch overrides and also adds a few cleanups
> in the same area.
Reviewed-by: Nicolas Saenz Julienne
for the whole series,
Thanks!
Hello Christoph,
I have found the issue. :-)
GFP_DMA32 was renamed to GFP_DMA in the PowerPC updates 4.21-1 in
December last year.
Some PCI devices still use GFP_DMA32 (grep -r GFP_DMA32 *). I renamed
GFP_DMA32 to GFP_DMA in the file
"drivers/media/v4l2-core/videobuf-dma-sg.c". After compil
On Wed 13-11-19 01:02:02, John Hubbard wrote:
> On 11/13/19 12:22 AM, Daniel Vetter wrote:
> ...
> > > > Why are we doing this? I think things got confused here someplace, as
> > >
> > >
> > > Because:
> > >
> > > a) These need put_page() calls, and
> > >
> > > b) there is no put_pages() call,
On Wed, Nov 13, 2019 at 9:41 AM Michal Suchánek wrote:
>
> On Wed, Nov 13, 2019 at 01:02:34PM +1000, Nicholas Piggin wrote:
> > >
> > > @@ -277,7 +276,7 @@ static void do_signal(struct task_struct *tsk)
> > >
> > > rseq_signal_deliver(&ksig, tsk->thread.regs);
> > >
> > > - if (is32) {
> >
On older distributions like Sles12SP5 gcc does not recognize
-no-pie option making the powerpc selftests build to fail
Fixes the following:
gcc: error: unrecognized command line option ‘-no-pie’
Signed-off-by: Harish
---
tools/testing/selftests/powerpc/pmu/ebb/Makefile | 7 ++-
1 file chang
On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functi
On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log le
On PowerNV the PCIe topology is (currently) managed the powernv platform
code in cooperation with firmware. The PCIe-native service drivers bypass
both and this can cause problems.
Historically this hasn't been a big deal since the only port service
driver that saw much use was the AER driver. The
Scott Wood writes:
> This contains KASLR support for book3e 32-bit.
>
> The following changes since commit 612ee81b9461475b5a5612c2e8d71559dd3c7920:
>
> powerpc/papr_scm: Fix an off-by-one check in papr_scm_meta_{get, set}
> (2019-10-10 20:15:53 +1100)
>
> are available in the Git repository at
On 11/13/19 12:22 AM, Daniel Vetter wrote:
...
Why are we doing this? I think things got confused here someplace, as
Because:
a) These need put_page() calls, and
b) there is no put_pages() call, but there is a release_pages() call that
is, arguably, what put_pages() would be.
the comment
On Wed, Nov 13, 2019 at 01:02:34PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on November 13, 2019 2:52 am:
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
>
> For the most part these seem okay to
On Tue, Nov 12, 2019 at 10:10 PM John Hubbard wrote:
>
> On 11/12/19 12:38 PM, Jason Gunthorpe wrote:
> > On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote:
> >> Hi,
> >>
> >> The cover letter is long, so the more important stuff is first:
> >>
> >> * Jason, if you or someone could look
92 matches
Mail list logo
