On Fri Jan 24, 2025 at 3:00 PM EET, Nikolai Kondrashov wrote:
> On 1/24/25 2:16 PM, Jarkko Sakkinen wrote:
> > On Fri Jan 24, 2025 at 10:12 AM EET, Laurent Pinchart wrote:
> >> Gitlab as an open-source software project (the community edition) is one
> >> thing, but can
On Fri Jan 24, 2025 at 2:58 PM EET, Nikolai Kondrashov wrote:
> Hi Jarkko,
>
> On 1/23/25 11:30 PM, Jarkko Sakkinen wrote:
> > On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
> >> We are working towards creating a generic, upstream GitLab-CI pipeline
> >&g
On Fri Jan 24, 2025 at 10:12 AM EET, Laurent Pinchart wrote:
> Gitlab as an open-source software project (the community edition) is one
> thing, but can we please avoid advertising specific proprietary services
> in the kernel documentation ?
I don't think we should have any of this in the mainlin
On Thu Jan 23, 2025 at 11:30 PM EET, Jarkko Sakkinen wrote:
> On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
> > We are working towards creating a generic, upstream GitLab-CI pipeline
> > (kci-gitlab) that will replace DRM-CI [1]. The proposed GitLab-CI pipeline
> &g
On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
> We are working towards creating a generic, upstream GitLab-CI pipeline
> (kci-gitlab) that will replace DRM-CI [1]. The proposed GitLab-CI pipeline
> is designed with a distributed infrastructure model, making it possible
> to run on any gi
On Thu Feb 29, 2024 at 12:55 AM EET, Helen Koike wrote:
> Dear Kernel Community,
>
> This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining
> a
> basic test pipeline triggered by code pushes to a GitLab-CI instance. This
> initial version includes static checks (checkpatch a
On Wed Jan 24, 2024 at 7:22 PM EET, Mark Brown wrote:
> On Wed, Jan 24, 2024 at 09:13:49AM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
>
> > > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > > didn't appear in a p
.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include "tpm.h"
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c
> b/drivers/char/tpm/tpm_tis_spi_main.c
> index 1f5207974a17..c6101914629d 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -28,7 +28,7 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
>
> diff --git a/drivers/char/tpm/tpm_tis_synquacer.c
> b/drivers/char/tpm/tpm_tis_synquacer.c
> index 49278746b0e2..7f9b4bfceb6e 100644
> --- a/drivers/char/tpm/tpm_tis_synquacer.c
> +++ b/drivers/char/tpm/tpm_tis_synquacer.c
> @@ -9,7 +9,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include "tpm.h"
> #include "tpm_tis_core.h"
> --
> 2.40.1
drivers/char/tpm/**
Acked-by: Jarkko Sakkinen
BR, Jarkko
pages + i);
> break;
> default:
> ret = -EINVAL;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d255964ec331..7f31e0a4adb5 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2474,7 +2474,7 @@ static inline int check_user_page_hwpoison(unsigned
> long addr)
> {
> int rc, flags = FOLL_HWPOISON | FOLL_WRITE;
>
> - rc = get_user_pages(addr, 1, flags, NULL, NULL);
> + rc = get_user_pages(addr, 1, flags, NULL);
> return rc == -EHWPOISON;
> }
>
> --
> 2.40.0
Acked-by: Jarkko Sakkinen
BR, Jarkko
On Mon, Mar 07, 2022 at 10:11:19PM +, David Laight wrote:
> From: Christoph Hellwig
> > Sent: 07 March 2022 15:57
> >
> > On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > > So what would you suggest to sort out the issue? I'm happy to go
On Mon, Mar 07, 2022 at 07:56:53AM -0800, Christoph Hellwig wrote:
> On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > So what would you suggest to sort out the issue? I'm happy to go with
> > ioctl if nothing else is acceptable.
>
> PLenty of dri
On Mon, Mar 07, 2022 at 03:33:52PM +0100, David Hildenbrand wrote:
> On 07.03.22 15:22, Jarkko Sakkinen wrote:
> > On Mon, Mar 07, 2022 at 11:12:44AM +0100, David Hildenbrand wrote:
> >> On 06.03.22 06:32, Jarkko Sakkinen wrote:
> >>> For device memory (aka VM_IO
On Mon, Mar 07, 2022 at 07:29:22AM -0800, Dave Hansen wrote:
> On 3/7/22 03:27, Jarkko Sakkinen wrote:
> > But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets
> > filtered out and never reach that function.
> >
> > I don't know unorthodox that
On Mon, Mar 07, 2022 at 02:37:48PM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 03:41:54PM -0800, Dave Hansen wrote:
> > In short: page faults stink. The core kernel has lots of ways of
> > avoiding page faults like madvise(MADV_WILLNEED) or mmap(MAP_POPULATE).
> > But, those only work
On Mon, Mar 07, 2022 at 11:12:44AM +0100, David Hildenbrand wrote:
> On 06.03.22 06:32, Jarkko Sakkinen wrote:
> > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow
> > to use that for initializing the device memory by providing a new callback
> > f_op
On Sun, Mar 06, 2022 at 11:48:26PM -0800, Christoph Hellwig wrote:
> On Sun, Mar 06, 2022 at 11:33:02AM +, Matthew Wilcox wrote:
> > On Sun, Mar 06, 2022 at 07:32:04AM +0200, Jarkko Sakkinen wrote:
> > > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing.
On Mon, Mar 07, 2022 at 03:16:57PM +0200, Jarkko Sakkinen wrote:
> On Sun, Mar 06, 2022 at 10:43:31PM +, Matthew Wilcox wrote:
> > On Sun, Mar 06, 2022 at 07:02:57PM +0200, Jarkko Sakkinen wrote:
> > > So can I conclude from this that in general having populate availabl
On Sun, Mar 06, 2022 at 10:43:31PM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 07:02:57PM +0200, Jarkko Sakkinen wrote:
> > So can I conclude from this that in general having populate available for
> > device memory is something horrid, or just the implementation path?
&
On Sun, Mar 06, 2022 at 03:24:56PM -0800, Andrew Morton wrote:
> On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote:
>
> > Sometimes you might want to use MAP_POPULATE to ask a device driver to
> > initialize the device memory in some specific manner. SGX driver can use
&
On Sun, Mar 06, 2022 at 03:41:54PM -0800, Dave Hansen wrote:
> On 3/6/22 15:24, Andrew Morton wrote:
> > On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen
> > wrote:
> >
> >> Sometimes you might want to use MAP_POPULATE to ask a device driver to
> >&g
ops->mmap() and make
it conditionally called inside call_mmap(). Update call sites
accodingly.
Signed-off-by: Jarkko Sakkinen
---
arch/mips/kernel/vdso.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
fs/coda/file.c | 2 +-
fs/ove
On Sun, Mar 06, 2022 at 07:03:00PM +0200, Jarkko Sakkinen wrote:
> On Sun, Mar 06, 2022 at 11:01:36AM +0100, Greg Kroah-Hartman wrote:
> > On Sun, Mar 06, 2022 at 07:32:05AM +0200, Jarkko Sakkinen wrote:
> > > Sometimes you might want to use MAP_POPULATE to ask a device driver t
On Sun, Mar 06, 2022 at 11:01:36AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 06, 2022 at 07:32:05AM +0200, Jarkko Sakkinen wrote:
> > Sometimes you might want to use MAP_POPULATE to ask a device driver to
> > initialize the device memory in some specific manner. SGX driver can
On Sun, Mar 06, 2022 at 08:30:14AM +, David Laight wrote:
> From: Jarkko Sakkinen
> > Sent: 06 March 2022 05:32
> >
> > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow
> > to use that for initializing the device memory by providing a new c
enclave with
mmap() by populating pages with EAUG. Use f_ops->populate() callback to
achieve this behaviour.
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/driver.c | 129 +++
1 file changed, 129 insertions(+)
diff --git a/arch/x86/kernel/cpu/sgx/driver.
Move sgx_encl_page_alloc() to encl.c and export it so that it can be
used in the implementation for MAP_POPULATE, which requires to allocate
new enclave pages.
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/encl.c | 38 +
arch/x86/kernel/cpu/sgx
ops->mmap() and make
it conditionally called inside call_mmap(). Update call sites
accodingly.
---
Signed-off-by: Jarkko Sakkinen
v3:
- if (!ret && do_populate && file->f_op->populate)
+ if (!ret && do_populate && file->f_op->populate &a
ess elegant and requires
two syscalls (mmap + ioctl) per memory range, instead of just one
(mmap).
Jarkko Sakkinen (3):
mm: Add f_ops->populate()
x86/sgx: Export sgx_encl_page_alloc()
x86/sgx: Implement EAUG population with MAP_POPULATE
arch/mips/kernel/vdso.c| 2 +-
ar
On Sun, Mar 06, 2022 at 04:19:26AM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 06:11:21AM +0200, Jarkko Sakkinen wrote:
> > On Sun, Mar 06, 2022 at 03:52:12AM +, Matthew Wilcox wrote:
> > > On Sun, Mar 06, 2022 at 05:21:11AM +0200, Jarkko Sakkinen wrote:
> >
On Sun, Mar 06, 2022 at 03:52:12AM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 05:21:11AM +0200, Jarkko Sakkinen wrote:
> > On Sun, Mar 06, 2022 at 02:57:55AM +, Matthew Wilcox wrote:
> > > On Sun, Mar 06, 2022 at 04:15:33AM +0200, Jarkko Sakkinen wrote:
> >
ops->mmap() and make
it conditionally called inside call_mmap(). Update call sites
accodingly.
Signed-off-by: Jarkko Sakkinen
---
v2:
- if (!ret && do_populate)
+ if (!ret && do_populate && file->f_op->populate)
(reported by Jan Harkes)
---
arch/mips/k
On Sun, Mar 06, 2022 at 02:57:55AM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 04:15:33AM +0200, Jarkko Sakkinen wrote:
> > Sometimes you might want to use MAP_POPULATE to ask a device driver to
> > initialize the device memory in some specific manner. SGX driver can
ops->mmap() and make
it conditionally called inside call_mmap(). Update call sites
accodingly.
Signed-off-by: Jarkko Sakkinen
---
arch/mips/kernel/vdso.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
fs/coda/file.c | 2 +-
fs/ove
On Mon, Dec 07, 2020 at 11:58:44AM -0800, James Bottomley wrote:
> On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > > and that function is leaking
On Mon, Dec 07, 2020 at 03:28:03PM -0400, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > Just as a side note. I was looking at tpm_tis_probe_irq_single() and
> > that function is leaking the interrupt request if any of the checks
> > afterwards fails,
On Sun, Dec 06, 2020 at 10:33:09PM +0100, Thomas Gleixner wrote:
> On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote:
> > On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> >> Now that kstat_irqs is exported, get rid of count_interrupts in
> >> i915_pmu.c
> >
> > May I ask why this has been
by: kernel test robot
I'm not sure if this makes much sense.
> Cc: Thomas Gleixner
> Cc: Jarkko Sakkinen
> Cc: Jason Gunthorpe
> Cc: Peter Huewe
> Cc: James Bottomley
> Cc: Matthew Garrett
> Cc: Hans de Goede
> Signed-off-by: Jerry Snitselaar
/Jarkko
___
On Tue, Jul 07, 2020 at 11:04:12AM -0700, Randy Dunlap wrote:
> Drop the doubled word "in".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: James Bottomley
> Cc: Jarkko Sakkinen
> Cc: Mimi Zohar
> Cc: linux-
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote:
> On 10/23/19 4:56 AM, Jarkko Sakkinen wrote:
> > On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> > > Replace all occurrences of prefered with preferred to make future
> > > checkpatch.pl
On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> Replace all occurrences of prefered with preferred to make future
> checkpatch.pl's happy. A few places the incorrect spelling is
> matched with the correct spelling to preserve existing user space API.
>
> Signed-off-by: Mark Salyzy
;> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> > >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > >>> wrote:
> > >>>>
> > >>>> In order to comply with the CoC, replace with a hug.
> > >>
> &
On Fri, Nov 30, 2018 at 02:40:19PM -0800, Jarkko Sakkinen wrote:
> Got you... Well I now read the 2nd amendment now through, and yeah, kind
> of way I work/function anyway.
Ugh, looked up the word from dictionary for something that makes
additions to some guidelines because did not kn
On Fri, Nov 30, 2018 at 02:30:45PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> [...]
> > > Have you read Documentation/process/code-of-conduct-
> > >
On Fri, Nov 30, 2018 at 02:26:05PM -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> > On Fri, 30 Nov 2018 14:12:19 -0800
> > Jarkko Sakkinen wrote:
> >
> > > As a maintainer myself (and based on somewhat distu
On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen wrote:
>
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobo
On Fri, Nov 30, 2018 at 01:57:49PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > No because use of what some people consider to be bad language
> > >
On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> From: Jarkko Sakkinen
> Date: Fri, 30 Nov 2018 13:44:05 -0800
>
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> >> No because use of what some people consider to be bad language isn&#x
On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> No because use of what some people consider to be bad language isn't
> necessarily abusive, offensive or degrading. Our most heavily censored
> medium is TV and "fuck" is now considered acceptable in certain
> contexts on most chan
On Fri, Nov 30, 2018 at 12:35:07PM -0800, David Miller wrote:
> From: Jens Axboe
> Date: Fri, 30 Nov 2018 13:12:26 -0700
>
> > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> >> On Fri, 30 Nov 2018, Kees Cook wrote:
> >>
> >>> On Fri, Nov 30,
On Fri, Nov 30, 2018 at 08:42:23PM +, Chris Mason wrote:
> I think the bar for changing the documentation/comments should be
> improvement in the clarity or approachability of whatever is being
> changed.
>
> This patch set is kind of like Linus sitting at kernel summit with a
> sign that s
On Fri, Nov 30, 2018 at 09:31:13PM +0100, Matthias Brugger wrote:
> Like John I don't think that the word "fuck" is something we have to ban from
> the source code, but I don't care too much. Anyway, please don't change it to
> something like heck as it might be difficult for non-english speaker to
On Fri, Nov 30, 2018 at 09:09:48PM +0100, John Paul Adrian Glaubitz wrote:
> Or just leave it as is because we're all grown up and don't freak out
> when a piece of text contains the word "fuck".
>
> I still don't understand why people think that the word "fuck" is what
> would keep certain groups
On Fri, Nov 30, 2018 at 06:13:50PM -0200, Diego Viola wrote:
> On Fri, Nov 30, 2018 at 5:30 PM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > drivers/gpu/drm/
On Fri, Nov 30, 2018 at 11:40:17AM -0800, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug
On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
> > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > wrote:
> > >
> > > In order to comply with the CoC, replace with a hug.
>
> I
In order to comply with the CoC, replace with a hug.
Jarkko Sakkinen (15):
MIPS: replace with a hug
Documentation: replace with a hug
drm/nouveau: replace with a hug
m68k: replace with a hug
parisc: replace with a hug
cpufreq: replace with a hug
In order to comply with the CoC, replace with a hug.
Signed-off-by: Jarkko Sakkinen
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c| 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
le of times and verified that
access_ok() is only removed when the buffer is allocated with
compat_alloc_user_space(). My deepest apologies for this kind of
sloppiness!
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_ioc32.c
On 07/02/2015 11:10 AM, Jani Nikula wrote:
> On Wed, 01 Jul 2015, Jarkko Sakkinen
> wrote:
>> The compat ioctl handler ends up calling access_ok() twice: first
>> indirectly inside compat_alloc_user_space() and then after returning
>> from that function. This patch f
On 07/02/2015 10:32 AM, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 12:24:37PM +0300, Jarkko Sakkinen wrote:
>> The compat ioctl handler ends up calling access_ok() twice: first
>> indirectly inside compat_alloc_user_space() and then after returning
>> from that funct
The compat ioctl handler ends up calling access_ok() twice: first
indirectly inside compat_alloc_user_space() and then after returning
from that function. This patch fixes issue.
Signed-off-by: Jarkko Sakkinen
---
drivers/gpu/drm/drm_ioc32.c | 55 +
1
61 matches
Mail list logo
