All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
	ceph-devel@vger.kernel.org, drbd-dev@lists.linbit.com,
	devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org,
	linux-nilfs@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	linux-cachefs@redhat.com, intel-wired-lan@lists.osuosl.org,
	xen- devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	Fenghua Yu <fenghua.yu@intel.com>,
	ecryptfs@vger.kernel.org, linux-um@lists.infradead.org,
	intel-gfx@lists.freedesktop.org, linux-erofs@lists.ozlabs.org,
	reiserfs-devel@vger.kernel.org, linux-block@vger.kernel.org,
	linux-bcache@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	io-uring@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
	ceph-devel@vger.kernel.org, drbd-dev@lists.linbit.com,
	devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org,
	linux-nilfs@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	linux-cachefs@redhat.com, intel-wired-lan@lists.osuosl.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	Fenghua Yu <fenghua.yu@intel.com>,
	ecryptfs@vger.kernel.org, linux-um@lists.infradead.org,
	intel-gfx@lists.freedesktop.org, linux-erofs@lists.ozlabs.org,
	reiserfs-devel@vger.kernel.org, linux-block@vger.kernel.org,
	linux-bcache@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	io-uring@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 16:19:46 +0000	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ira Weiny <ira.weiny@intel.com>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mmc@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, linux-kselftest@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
	linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, x86@kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-afs@lists.infradead.org, cluster-devel@redhat.com,
	Ingo Molnar <mingo@redhat.com>,
	intel-wired-lan@lists.osuosl.org, kexec@lists.infradead.org,
	xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org,
	bpf@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
	linux-um@lists.infradead.org, reiserfs-devel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	ceph-devel@vger.kernel.org, io-uring@vger.kernel.org,
	linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 09:19:46 -0700	[thread overview]
Message-ID: <20201012161946.GA858@sol.localdomain> (raw)
In-Reply-To: <20201012065635.GB2046448@iweiny-DESK2.sc.intel.com>

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric



  reply	other threads:[~2020-10-12 16:19 UTC|newest]

Thread overview: 1245+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 19:49 [PATCH RFC PKS/PMEM 00/58] PMEM: Introduce stray write protection for PMEM ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 01/58] x86/pks: Add a global pkrs option ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 02/58] x86/pks/test: Add testing for global option ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 03/58] memremap: Add zone device access protection ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 04/58] kmap: Add stray access protection for device pages ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 06/58] kmap: Introduce k[un]map_thread debugging ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 07/58] drivers/drbd: Utilize new kmap_thread() ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 08/58] drivers/firmware_loader: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 09/58] drivers/gpu: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 22:03   ` Daniel Vetter
2020-10-09 22:03     ` [Cluster-devel] " Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` [Intel-wired-lan] " Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` [Intel-gfx] " Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` [f2fs-dev] " Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
2020-10-09 22:03     ` Daniel Vetter
     [not found]     ` <20201009220349.GQ438822-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01     ` Ira Weiny
2020-10-10 23:01       ` [Cluster-devel] " Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` [Intel-wired-lan] " Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` [Intel-gfx] " Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` [f2fs-dev] " Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01       ` Ira Weiny
2020-10-10 23:01     ` Ira Weiny
2020-10-10 23:01     ` Ira Weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 10/58] drivers/rdma: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 11/58] drivers/net: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 12/58] fs/afs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 13/58] fs/btrfs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 14/58] fs/cifs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 15/58] fs/ecryptfs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 16/58] fs/gfs2: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 17/58] fs/nilfs2: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 18/58] fs/hfs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 19/58] fs/hfsplus: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 20/58] fs/jffs2: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 21/58] fs/nfs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 22/58] fs/f2fs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 21:34   ` Eric Biggers
2020-10-09 21:34     ` [Cluster-devel] " Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` [Intel-wired-lan] " Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` [Intel-gfx] " Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` [f2fs-dev] " Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-09 21:34     ` Eric Biggers
2020-10-10  0:39     ` Matthew Wilcox
2020-10-10  0:39       ` [Cluster-devel] " Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` [Intel-wired-lan] " Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` [Intel-gfx] " Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` [f2fs-dev] " Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  0:39       ` Matthew Wilcox
2020-10-10  1:30       ` Eric Biggers
2020-10-10  1:30         ` [Cluster-devel] " Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` [Intel-wired-lan] " Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` [Intel-gfx] " Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` [f2fs-dev] " Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-10  1:30         ` Eric Biggers
2020-10-12  6:56         ` Ira Weiny
2020-10-12  6:56           ` [Cluster-devel] " Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` [Intel-wired-lan] " Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` [Intel-gfx] " Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` [f2fs-dev] " Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12  6:56           ` Ira Weiny
2020-10-12 16:19           ` Eric Biggers [this message]
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` [Intel-wired-lan] " Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` [Intel-gfx] " Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` [f2fs-dev] " Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-12 16:19             ` Eric Biggers
2020-10-10  2:43     ` James Bottomley
2020-10-10  2:43       ` [Cluster-devel] " James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` [Intel-wired-lan] " James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` [Intel-gfx] " James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` [f2fs-dev] " James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-10  2:43       ` James Bottomley
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 23/58] fs/fuse: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: " ira.weiny
2020-10-09 19:49   ` [Cluster-devel] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [Intel-gfx] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` [f2fs-dev] " ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:49   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 25/58] fs/reiserfs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 26/58] fs/zonefs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-12  2:30   ` Damien Le Moal
2020-10-12  2:30     ` [Cluster-devel] " Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` [Intel-wired-lan] " Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` [Intel-gfx] " Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` [f2fs-dev] " Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-12  2:30     ` Damien Le Moal
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 27/58] fs/ubifs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 28/58] fs/cachefiles: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 29/58] fs/ntfs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 30/58] fs/romfs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 31/58] fs/vboxsf: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 32/58] fs/hostfs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 33/58] fs/cramfs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 34/58] fs/erofs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 35/58] fs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 36/58] fs/ext2: Use ext2_put_page ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 37/58] fs/ext2: Utilize new kmap_thread() ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 38/58] fs/isofs: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 39/58] fs/jffs2: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 40/58] net: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 41/58] drivers/target: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 42/58] drivers/scsi: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 43/58] drivers/mmc: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 44/58] drivers/xen: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 45/58] drivers/firmware: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 46/58] drives/staging: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 47/58] drivers/mtd: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 48/58] drivers/md: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-10  2:20   ` Coly Li
2020-10-10  2:20     ` [Cluster-devel] " Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` [Intel-wired-lan] " Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` [Intel-gfx] " Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` [f2fs-dev] " Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-10  2:20     ` Coly Li
2020-10-12  5:28     ` Ira Weiny
2020-10-12  5:28       ` [Cluster-devel] " Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` [Intel-wired-lan] " Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` [Intel-gfx] " Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` [f2fs-dev] " Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  5:28       ` Ira Weiny
2020-10-12  7:40       ` Coly Li
2020-10-12  7:40         ` [Cluster-devel] " Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` [Intel-wired-lan] " Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` [Intel-gfx] " Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` [f2fs-dev] " Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-12  7:40         ` Coly Li
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 49/58] drivers/misc: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 50/58] drivers/android: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 51/58] kernel: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-10  3:43   ` Eric W. Biederman
2020-10-10  3:43     ` [Cluster-devel] " Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` [Intel-wired-lan] " Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` [Intel-gfx] " Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` [f2fs-dev] " Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-10  3:43     ` Eric W. Biederman
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 52/58] mm: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 53/58] lib: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 54/58] powerpc: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 55/58] samples: " ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 56/58] dax: Stray access protection for dax_direct_access() ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 57/58] nvdimm/pmem: Stray access protection for pmem->virt_addr ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-10  2:53   ` John Hubbard
2020-10-10  2:53     ` [Cluster-devel] " John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` [Intel-wired-lan] " John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` [Intel-gfx] " John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` [f2fs-dev] " John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-10  2:53     ` John Hubbard
2020-10-12  5:52     ` Ira Weiny
2020-10-12  5:52       ` [Cluster-devel] " Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` [Intel-wired-lan] " Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` [Intel-gfx] " Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` [f2fs-dev] " Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-12  5:52       ` Ira Weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 58/58] [dax|pmem]: Enable stray access protection ira.weiny
2020-10-09 19:50   ` [Cluster-devel] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [Intel-gfx] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` [f2fs-dev] " ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 19:50   ` ira.weiny
2020-10-09 22:51 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for PMEM: Introduce stray write protection for PMEM Patchwork
2020-10-10 11:36 ` [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread() Bernard Metzler
2020-10-10 11:36   ` [Cluster-devel] " Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` [Intel-wired-lan] " Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` [Intel-gfx] " Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` [f2fs-dev] " Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-10 11:36   ` Bernard Metzler
2020-10-12  4:47   ` Ira Weiny
2020-10-12  4:47     ` [Cluster-devel] " Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` [Intel-wired-lan] " Ira Weiny
2020-10-12  4:47     ` [Intel-gfx] " Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` [f2fs-dev] " Ira Weiny
2020-10-12  4:47     ` Ira Weiny
2020-10-12  4:47     ` Ira Weiny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201012161946.GA858@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bp@alien8.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=cluster-devel@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=drbd-dev@lists.linbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=ira.weiny@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=samba-technical@lists.samba.org \
    --cc=target-devel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.