> On 1 Mar 2018, at 11.22, Matias Bjørling wrote:
>
> On 02/28/2018 04:49 PM, Javier González wrote:
>> Currently, the device geometry is stored redundantly in the nvm_id and
>> nvm_geo structures at a device level. Moreover, when instantiating
>> targets on a specific number of LUNs, these struc
When opening a device with write access, ubiblock_open returns an error
code. Currently, this error code is -EPERM, but this is not the right
value.
The open function for other block devices returns -EROFS when opening
read-only devices with FMODE_WRITE set. When used with dm-verity, the
verityset
> On 1 Mar 2018, at 11.33, Matias Bjørling wrote:
>
> On 02/28/2018 04:49 PM, Javier González wrote:
>> Assign missing mccap value on 2.0 path
>> Signed-off-by: Javier González
>> ---
>> drivers/nvme/host/lightnvm.c | 4 +++-
>> include/linux/lightnvm.h | 8 +---
>> 2 files changed, 8 i
Am Freitag, 2. März 2018, 12:16:18 CET schrieb Romain Izard:
> When opening a device with write access, ubiblock_open returns an error
> code. Currently, this error code is -EPERM, but this is not the right
> value.
>
> The open function for other block devices returns -EROFS when opening
> read-o
On Fri, 2018-03-02 at 10:16 +0800, Ming Lei wrote:
> On Thu, Mar 01, 2018 at 04:19:34PM -0500, Laurence Oberman wrote:
> > On Thu, 2018-03-01 at 14:01 -0500, Laurence Oberman wrote:
> > > On Thu, 2018-03-01 at 16:18 +, Don Brace wrote:
> > > > > -Original Message-
> > > > > From: Ming L
Hi Tang Junhui---
On 03/01/2018 09:45 PM, tang.jun...@zte.com.cn wrote:
> From: Tang Junhui
>
> Hello, Mike
>
> This patch looks good, but has some conflicts with this patch:
> bcache: fix for data collapse after re-attaching an attached device
> https://git.kernel.org/pub/scm/linux/kernel/git/
On 03/02/2018 06:55 AM, Michael Lyle wrote:
> Hi Tang Junhui---
>
> On 03/01/2018 09:45 PM, tang.jun...@zte.com.cn wrote:
>> From: Tang Junhui
>>
>> Hello, Mike
>>
>> This patch looks good, but has some conflicts with this patch:
>> bcache: fix for data collapse after re-attaching an attached dev
> -Original Message-
> From: Laurence Oberman [mailto:lober...@redhat.com]
> Sent: Friday, March 02, 2018 8:09 AM
> To: Ming Lei
> Cc: Don Brace ; Jens Axboe ;
> linux-block@vger.kernel.org; Christoph Hellwig ; Mike
> Snitzer ; linux-s...@vger.kernel.org; Hannes Reinecke
> ; Arun Easi ; Om
This patchet applies on top of Matias' for-17/core, with the following
patches applied:
lightnvm: pblk: refactor init/exit sequences (V2)
nvme: implement log page low/high offset and dwords (V2)
# Changes since V4
- Remove init/exit sequences as it has been sent separately
-Rebase on top of la
Complete the generic geometry structure with the maxoc and maxocpu
felds, present in the 2.0 spec. Also, expose them through sysfs.
Signed-off-by: Javier González
---
drivers/nvme/host/lightnvm.c | 17 +
include/linux/lightnvm.h | 2 ++
2 files changed, 19 insertions(+)
dif
In preparation of pblk supporting 2.0, implement the get log report
chunk in pblk. Also, define the chunk states as given in the 2.0 spec.
Signed-off-by: Javier González
---
drivers/lightnvm/pblk-core.c | 138 +++
drivers/lightnvm/pblk-init.c | 222 +++
Implement 2.0 support in pblk. This includes the address formatting and
mapping paths, as well as the sysfs entries for them.
Signed-off-by: Javier González
---
drivers/lightnvm/pblk-init.c | 56 ++--
drivers/lightnvm/pblk-sysfs.c | 46 +++---
drivers/lightnvm/pblk.h | 196 +
In preparation for 2.0 support in pblk, rename variables referring to
the address format to addrf and reserve ppaf for the 1.2 path.
Signed-off-by: Javier González
---
drivers/lightnvm/pblk-init.c | 8
drivers/lightnvm/pblk-sysfs.c | 4 ++--
drivers/lightnvm/pblk.h | 16 +++
Add support for 2.0 address format. Also, align address bits for 1.2 and
2.0 to be able to operate on channel and luns without requiring a format
conversion. Use a generic address format for this purpose.
Also, convert the generic operations to the generic format in pblk.
Signed-off-by: Javier Go
Normalize nomenclature for naming channels, luns, chunks, planes and
sectors as well as derivations in order to improve readability.
Signed-off-by: Javier González
---
drivers/lightnvm/core.c | 89 +--
drivers/lightnvm/pblk-core.c | 4 +-
drivers/l
The 2.0 spec provides a report chunk log page that can be retrieved
using the stangard nvme get log page. This replaces the dedicated
get/put bad block table in 1.2.
This patch implements the helper functions to allow targets retrieve the
chunk metadata using get log page. It makes nvme_get_log_ex
At this point, only 1.2 spec is supported, thus check for it. Also,
since device-side L2P is only supported in the 1.2 spec, make sure to
only check its value under 1.2.
Signed-off-by: Javier González
---
drivers/lightnvm/pblk-init.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(
On address conversions, use the generic device, instead of the target
device. This allows to use conversions outside of the target's realm.
Signed-off-by: Javier González
---
drivers/lightnvm/core.c | 4 ++--
include/linux/lightnvm.h | 8
2 files changed, 6 insertions(+), 6 deletions(-
Currently, the device geometry is stored redundantly in the nvm_id and
nvm_geo structures at a device level. Moreover, when instantiating
targets on a specific number of LUNs, these structures are replicated
and manually modified to fit the instance channel and LUN partitioning.
Instead, create a
Create a shorten version to use in the generic geometry.
Signed-off-by: Javier González
---
drivers/nvme/host/lightnvm.c | 6 ++
include/linux/lightnvm.h | 8
2 files changed, 14 insertions(+)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index de4105
Separate the version between major and minor on the generic geometry and
represent it through sysfs in the 2.0 path. The 1.2 path only shows the
major version to preserve the existing user space interface.
Signed-off-by: Javier González
---
drivers/lightnvm/core.c | 4 ++--
drivers/nvme/ho
With gcc 4.9.0:
block/blk-core.c: In function 'blk_pm_allow_request':
block/blk-core.c:2653:2: warning: enumeration value 'RPM_ACTIVE' not
handled in switch [-Wswitch]
switch (rq->q->rpm_status) {
^
Convert the return statement below the switch() block into a default
case to
On Thu, Mar 01, 2018 at 11:53:16PM +, Stephen Bates wrote:
> > There's a meaningful difference between writing to an NVMe CMB vs PMR
>
> When the PMR spec becomes public we can discuss how best to integrate it into
> the P2P framework (if at all) ;-).
http://nvmexpress.org/wp-content/upload
it://git.kernel.dk/linux-block.git tags/for-linus-20180302
Baegjae Sung (1):
nvme-multipath: fix sysfs dangerously created links
Christoph Hellwig (3):
nvme-fabrics: don't check for non-NULL module in nvmf_register_transport
nvme-rdma: use blk_rq_payload_bytes instead of blk_rq
On Thu, Mar 01, 2018 at 11:57:43PM +, Stephen Bates wrote:
> > We don't want to lump these all together without knowing which region
> > you're allocating from, right?
>
> In all seriousness I do agree with you on these Keith in the long
> term. We would consider adding property flags for th
On Fri, 2018-03-02 at 09:34 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote:
> > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt
> > wrote:
> > >
> > > Could be that x86 has the smarts to do the right thing, still trying to
> > > untangle the
On 01.03.2018 23:20, Andreas Dilger wrote:
>
> On Mar 1, 2018, at 9:04 AM, Theodore Ts'o wrote:
>> This doesn't seem to make sense; the PC is where we are currently
>> executing, and LR is the "Link Register" where the flow of control
>> will be returning after the current function returns, right
On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi wrote:
>
> FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.
No.
Or rather, that's simply just another (small) part of it all - and an
architected and documented one at that.
Like the page table caching entries, the memory type r
On 02/03/18 09:18 AM, Jason Gunthorpe wrote:
This allocator is already seems not useful for the P2P target memory
on a Mellanox NIC due to the way it has a special allocation flow
(windowing) and special usage requirements..
Nor can it be usefull for the doorbell memory in the NIC.
No one s
On Fri, Mar 2, 2018 at 8:57 AM, Linus Torvalds
wrote:
>
> Like the page table caching entries, the memory type range registers
> are really just "secondary information". They don't actually select
> between PCIe and RAM, they just affect the behavior on top of that.
Side note: historically the tw
On Fri, 2018-03-02 at 08:57 -0800, Linus Torvalds wrote:
> On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi wrote:
> >
> > FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.
>
> No.
>
> Or rather, that's simply just another (small) part of it all - and an
> architected and docum
>http://nvmexpress.org/wp-content/uploads/NVM-Express-1.3-Ratified-TPs.zip
@Keith - my apologies.
@Christoph - thanks for the link
So my understanding of when the technical content surrounding new NVMe
Technical Proposals (TPs) was wrong. I though the TP content could only be
discussed onc
> It seems people miss-understand HMM :(
Hi Jerome
Your unhappy face emoticon made me sad so I went off to (re)read up on HMM.
Along the way I came up with a couple of things.
While hmm.txt is really nice to read it makes no mention of DEVICE_PRIVATE and
DEVICE_PUBLIC. It also gives no indica
On Fri, 2018-03-02 at 10:25 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote:
> >
> > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote:
> > > We use only 52 in practice but yes.
> > >
> > > > That's 64PB. If you use need
> > > > a sparse vmemmap
On Fri, 2018-03-02 at 15:03 +, Don Brace wrote:
> > -Original Message-
> > From: Laurence Oberman [mailto:lober...@redhat.com]
> > Sent: Friday, March 02, 2018 8:09 AM
> > To: Ming Lei
> > Cc: Don Brace ; Jens Axboe > k>;
> > linux-block@vger.kernel.org; Christoph Hellwig ;
> > Mike
>
On Fri, Mar 02, 2018 at 09:38:43PM +, Stephen Bates wrote:
> > It seems people miss-understand HMM :(
>
> Hi Jerome
>
> Your unhappy face emoticon made me sad so I went off to (re)read up
> on HMM. Along the way I came up with a couple of things.
>
> While hmm.txt is really nice to read it
On 02/03/18 02:44 PM, Benjamin Herrenschmidt wrote:
Allright, so, I think I have a plan to fix this, but it will take a
little bit of time.
Basically the idea is to have firmware pass to Linux a region that's
known to not have anything in it that it can use for the vmalloc space
rather than ha
Looks good,
Reviewed-by: Christoph Hellwig
Although I think this should say 'fixes kernel-doc warnings' instead
of supressing them, as the old comments use invalid syntax.
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Feb 06, 2018 at 08:17:39PM +0800, Ming Lei wrote:
> No functional change, just prepare for converting to 2-stage
> irq vector spread.
>
> Cc: Thomas Gleixner
> Cc: Christoph Hellwig
> Signed-off-by: Ming Lei
> ---
> kernel/irq/affinity.c | 99
> +---
Looks fine,
Reviewed-by: Christoph Hellwig
Looks fine,
Reviewed-by: Christoph Hellwig
Bart,
s/manipulaton/manipulation/ in Subject. Otherwise OK.
> Move the definition of queue_flag_clear_unlocked() up and move the
> definition of queue_in_flight() down such that all queue flag
> manipulation function definitions become contiguous.
Reviewed-by: Martin K. Petersen
--
Martin K.
Bart,
> Except for changing the atomic queue flag manipulations that are
> protected by the queue lock into non-atomic manipulations, this
> patch does not change any functionality.
Looks fine.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Introduce functions that modify the queue flags and that protect
> these modifications with the request queue lock. Except for moving
> one wake_up_all() call from inside to outside a critical section,
> this patch does not change any functionality.
Looks OK.
Reviewed-by: Martin K. Pete
Bart,
> Use the blk_queue_flag_*() functions instead of open-coding these.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Since the queue flags may be changed concurrently from multiple
> contexts after a queue becomes visible in sysfs, make these changes
> safe by protecting these with the queue lock.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Use the blk_queue_flag_{set,clear}() functions instead of open-coding
> these.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Use blk_queue_flag_set() instead of open-coding this function.
Acked-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> This patch has been generated as follows:
>
> for verb in set_unlocked clear_unlocked set clear; do
> replace-in-files queue_flag_${verb} blk_queue_flag_${verb%_unlocked} \
> $(git grep -lw queue_flag_${verb} drivers block/bsg*)
> done
>
> Except for protecting all queue flag change
Bart,
> Use blk_queue_flag_set() instead of open-coding this function.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Since it is not safe to use queue_flag_(set|clear)_unlocked() without
> holding the queue lock after the sysfs entries for a queue have been
> created, complain if this happens.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> This patch helps to avoid that new code gets introduced in block drivers
> that manipulates queue flags without holding the queue lock when that
> lock should be held.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
On ARM64, the default page size has been 64K on some distributions, and
we should allow ARM64 people to play null_blk.
This patch fixes the issue by extend page bitmap size for supporting
other non-4KB PAGE_SIZE.
Reported-by: Yi Zhang
Signed-off-by: Ming Lei
---
drivers/block/null_blk.c | 46 +
54 matches
Mail list logo
