On 03/19/2015 10:59 PM, Dan Williams wrote:
>
> At least for block-i/o it seems the only place we really need struct
> page infrastructure is for kmap(). Given we already need a kmap_pfn()
> solution for option 2 a "dynamic allocation" stop along that
> development path may just naturally fall o
On 03/20/2015 11:08 PM, Rik van Riel wrote:
> On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
<>
>> There's a lot of code out there that relies on struct page being PAGE_SIZE
>> bytes. I'm cool with replacing 'struct page' with 'struct superpage'
>> [1] in the biovec and auditing all of the code whi
On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
<>
>
> In addition to the options there's also a time line. At least for the
> short term where we want to get something going 1a seems like the
> absolutely be option. It works perfectly fine for the lots of small
> capacity dram-like nvdimms, an
On 03/20/2015 10:31 PM, Matthew Wilcox wrote:
<>
>
> There's a lot of code out there that relies on struct page being PAGE_SIZE
> bytes.
Not so much really. Not at the lower end of the stack. You can actually feed
a
vp = kmalloc(64K);
bv_page = virt_to_page(vp)
bv_len =
On 03/20/2015 06:21 PM, Rik van Riel wrote:
> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>
>> 1. Construct struct pages for persistent memory
>> 1a. Permanently
>> 1b. While the pages are under I/O
>
> Michael Tsirkin and I have been doing some thinking about what
> it would take to allocate s
On 03/20/2015 05:56 PM, Rik van Riel wrote:
> On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
>> On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
>
>>>> I'm not the one afraid of hard work, if it was for a good cause, but for
>>>> what?
>>>> reall
On 03/19/2015 09:59 PM, Andrew Morton wrote:
> On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh wrote:
>
>> On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
>> <>
>>>
>>> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
&
ly agree with this patch. (So many of them, bread crumbs of copy/paste
for you ;0)
Reviewed-by: Boaz Harrosh
> fs/affs/affs.h | 2 +-
> fs/befs/befs.h | 2 +-
> fs/coda/coda_linux.h| 2 +-
> fs/hfs/hfs_fs.h | 2 +-
> fs/hfsplus/hfsplu
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
<>
>
> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
> want to be able to do any kind of I/O directly to persistent memory,
> and I think we do, we need to do one of:
>
> 1. Construct struct pages for persistent memory
> 1
On 03/18/2015 07:43 PM, Ross Zwisler wrote:
> On Thu, 2015-03-05 at 13:55 +0200, Boaz Harrosh wrote:
>> From: Ross Zwisler
>>
>> PMEM is a new driver That supports any physical contiguous iomem range
>> as a single block device. The driver has support for as many as nee
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
> On Wed, Mar 18, 2015 at 12:47:21PM +0200, Boaz Harrosh wrote:
>> God! Look at this endless list of files and it is only the very beginning.
>> It does not even work and touches only 10% of what will need to be touched
>> for t
On 03/16/2015 10:25 PM, Dan Williams wrote:
> This is in support of enabling block device drivers to perform DMA
> to/from persistent memory which may not have a backing struct page
> entry.
>
> Signed-off-by: Dan Williams
> ---
> arch/Kconfig |3 +++
> include/as
/prd
>
> Cc: linux-nvd...@lists.01.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: ax...@kernel.dk
> Cc: h...@infradead.org
> Cc: r...@redhat.com
>
> Boaz Harrosh (1):
> pmem: Let each device manage private memory region
>
Not signed-off-by me.
> Ross Zwisler (5)
On 03/16/2015 11:13 PM, Ross Zwisler wrote:
> From: Boaz Harrosh
>
> This patch removes any global memory information. And lets
> each pmem-device manage it's own memory region.
>
> pmem_alloc() Now receives phys_addr and disk_size and will
> map that region, also pmem
On 03/16/2015 10:25 PM, Dan Williams wrote:
> Avoid the impending disaster of requiring struct page coverage for what
> is expected to be ever increasing capacities of persistent memory.
If you are saying "disaster", than we need to believe you. Or is there
a scientific proof for this.
Actually
On 03/12/2015 12:42 AM, Ross Zwisler wrote:
<>
>
> Anyway, I thought your response to the original bug report against PMEM was
> that you were alright with this one line change since it didn't hurt anything,
> and perhaps it helped someone. Do you have the same stance for BRD,
No what I did in
ith no source code - is the first I have
heard of this.
> Instead we should have brd explicitly tell the block layer that it can
> handle data segments of at most PAGE_SIZE.
>
> Signed-off-by: Ross Zwisler
> Reported-by: Hugh Daschbach
> Cc: Roger C. Pao (Enmotus)
&g
On 03/11/2015 03:39 PM, Sasha Levin wrote:
> On 03/11/2015 08:40 AM, Steven Rostedt wrote:
>> On Wed, 11 Mar 2015 08:34:46 -0400
>> Sasha Levin wrote:
>>
Fair enough. We knew there are existing kmemcheck users, but KASan should
be
superior both in performance and the scope of bugs
On 03/10/2015 07:11 AM, joeyli wrote:
<>
>
> Per my understand...
>
> With EFI Boot Stub, there have setup_e820() codes in
> arch/x86/boot/compressed/eboot.c
> that used to transfer EFI memmap to e820 entries. Currently doesn't have any
> EFI_MEMORY_TYPE reflects to NvDIMM that will map to e820_
On 03/09/2015 05:17 PM, Dan Williams wrote:
> On Mon, Mar 9, 2015 at 11:14 AM, Andy Lutomirski wrote:
>> On Mon, Mar 9, 2015 at 7:44 AM, Dan Williams
>> wrote:
>>> On Mon, Mar 9, 2015 at 7:19 AM, Boaz Harrosh wrote:
>>>> On 03/05/2015 10:56 PM, Dan Wil
On 03/06/2015 08:37 PM, Ross Zwisler wrote:
<>
>> I maintain these patches on latest Kernels here:
>> git://git.open-osd.org/pmem.git branch pmem
>>
>> Thanks for reviewing
>> Boaz
>
> Hey Boaz,
>
> Regarding the PMEM series, my group has been working on an updated
> version of this driver f
On 03/06/2015 01:03 AM, Andy Lutomirski wrote:
<>
>
> I think it would be nice to have control over the caching mode.
> Depending on the application, WT or UC could make more sense.
>
Patches are welcome. say
map=sss@aaa:WT,sss@aaa:CA, ...
But for us, with direct_access(), all benchmark
On 03/06/2015 01:09 AM, Andy Lutomirski wrote:
<>
>
> I will be shocked if a standard of this form ever appears. Modern
> systems *don't have e820*. The BIOSes that are using this type 12
> hack are awful throwbacks.
So far the systems we have, with DDR4 NvDIMM(s) (Actual chips arriving soon)
s
On 03/05/2015 10:56 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:24 AM, Boaz Harrosh wrote:
>>
<>
>> Now the ACPI comity, as far as I know, did not yet define a
>> standard type for NvDIMM. Also, as far as I know any NvDIMM
>> standard will only be de
On 03/05/2015 10:41 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:20 AM, Boaz Harrosh wrote:
>>
>> There is something not very nice (Gentlemen nice) In current
>> e820.c code.
>>
>> At Multiple places for example @memblock_x86_fill() it will
>> add the
with hacked up pmem that will ignore
the return code from request_mem_region_exclusive. So here it is
official
Signed-off-by: Boaz Harrosh
---
drivers/block/Kconfig | 12
drivers/block/pmem.c | 9 ++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers
ill
never be released to the Kernel's page-allocators. (page_freeze)
Signed-off-by: Boaz Harrosh
---
drivers/block/Kconfig | 13 +
drivers/block/pmem.c | 20
2 files changed, 33 insertions(+)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index
QUASHME2]
We need to calculate the nid for every section, it is
possible that the same contiguous range will span two
numa-nodes.
Signed-off-by: Boaz Harrosh
Signed-off-by: Yigal Korman
Signed-off-by: Boaz Harrosh
---
include/linux/memory_hotplug.h
section of pages
allocated but without any zone associated. This is because belonging
to a zone will give the memory to the page allocators, but
persistent_memory belongs to a block device, and is not available for
regular volatile usage.
Signed-off-by: Yigal Korman
Signed-off-by: Boaz Harrosh
From: Ross Zwisler
Also fixed a top the initial version
[boaz]
SQUASHME pmem: Micro optimization the hotpath 002
Signed-off-by: Ross Zwisler
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/block/pmem.c b
From: Ross Zwisler
Based on commit a72132c31d58 ("brd: add support for rw_page()")
Signed-off-by: Ross Zwisler
---
drivers/block/pmem.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index bba53af..750ffdf 100644
--- a/drivers/block
(blkext) now.
If anyone knows of what would work differently after this
patch please do tell.
But it looks like the calls to register_blkdev is just dead
code for us right now
Thanks
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/
x27;t clobber the map module param
SQUASHME: pmem: Few changes to Initial version of pmem
SQUASHME: Changes to copyright text (trivial)
TODO: Add Documentation/blockdev/pmem.txt
Need-signed-by: Ross Zwisler
Signed-off-by: Boaz Harrosh
---
MAINTAINERS| 7 ++
drivers/block/Kconfig
There are already NvDIMMs and other Persistent-memory devices in the market, and
lots more of them will be coming in near future.
Current stack is coming along very nice, and filesystems support for leveraging
this
technologies has been submitted to Linus in the DAX series by Matthew Wilcox.
Th
quot;What if ACPI assigns type-12 for something else in future"
[And I say: Then just don't. Please?]
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c2f2da2..4
Anvin"
CC: x...@kernel.org
CC: Dan Williams
CC: Andrew Morton
CC: Bjorn Helgaas
CC: Vivek Goyal
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 3 +++
include/linux/ioport.h | 1 +
kernel/resource.c | 11 ++-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --
ds of thousands sold world wide)
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Dan Williams
CC: Matthew Wilcox
CC: Christoph Hellwig
CC: Andy Lutomirski
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 31 +--
Hi
[v5]
* [PATCH 2/3] Added the add_taint(TAINT_FIRMWARE_WORKAROUND,...)
and changed the printed message as requested
* Use IORESOURCE_MEM_WARN bit from the mem specific bit range
(not 64bit only anymore, only works with memory resources)
* Fix user visible typo reserved-unkown => reserved-un
On 03/04/2015 04:20 PM, Daniel Wagner wrote:
> On 03/03/2015 01:55 AM, Jeff Layton wrote:
>> On Mon, 2 Mar 2015 15:25:12 +0100
>> Daniel Wagner wrote:
>>
<>
> I have fixed that stuff and now I am testing it. Though it seems
> that there is a memory leak which can be triggered with
>
> whi
On 02/25/2015 12:22 PM, Ingo Molnar wrote:
>
> * Boaz Harrosh wrote:
>
>> List of patches:
>> [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY
>> The main fix
>>
>> [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit)
>>
On 02/24/2015 07:04 PM, Dan Williams wrote:
> On Tue, Feb 24, 2015 at 7:00 AM, Boaz Harrosh wrote:
>>
>> Resource providers set this flag if they want
>> that request_region will print a warning in dmesg
>> if this particular memory resource is locked by a driver.
>&
ot;
CC: x...@kernel.org
CC: Dan Williams
CC: Andrew Morton
CC: Bjorn Helgaas
CC: Vivek Goyal
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 3 +++
include/linux/ioport.h | 1 +
kernel/resource.c | 9 -
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/
On 02/24/2015 11:07 AM, Ingo Molnar wrote:
>
> * Boaz Harrosh wrote:
>
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -1075,8 +1075,13 @@ struct resource * __request_region(struct resource
>> *parent,
>> break;
On 02/24/2015 11:06 AM, Ingo Molnar wrote:
>
> * Boaz Harrosh wrote:
>
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -255,6 +256,5 @@ static inline bool resource_overlaps(struct resource
>> *r1, struct resource *r2)
>>
On 02/24/2015 10:34 AM, Ingo Molnar wrote:
>
> * Boaz Harrosh wrote:
>
>> On 02/24/2015 06:22 AM, Dan Williams wrote:
>> <>
>>>> By Popular demand An Extra WARNING message is printed if
>>>> an "UNKNOWN" is found. It will look lik
On 02/24/2015 10:39 AM, Boaz Harrosh wrote:
>
> Resource providers set this flag if they want
> that request_region_XXX will print a warning in dmesg
> if this particular resource is locked by a driver.
>
> Thous acting as a Protocol Police about experimental
> devices that
.c that
wants to WARN about UNKNOWN memory types.
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 3 +++
include/linux/ioport.h | 2 +-
kernel/resource.c | 7 ++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
On 02/24/2015 06:22 AM, Dan Williams wrote:
<>
>> By Popular demand An Extra WARNING message is printed if
>> an "UNKNOWN" is found. It will look like this:
>> e820: WARNING [mem 0x1-0x1] is unknown type 12
>
> I don't think we need to warn that an unknown range was published, ju
On 02/23/2015 05:49 PM, Andy Lutomirski wrote:
> On Mon, Feb 23, 2015 at 4:48 AM, Boaz Harrosh wrote:
>>
>> There are multiple vendors of DDR3 NvDIMMs out in the market today.
>> At various stages of development/production. It is estimated that
>> there are already
On 02/23/2015 05:46 PM, Andy Lutomirski wrote:
> On Mon, Feb 23, 2015 at 4:43 AM, Boaz Harrosh wrote:
>>
>> Resource providers set this flag if they want
>> that request_region_XXX will print a warning in dmesg
>> if this particular resource is locked by a driver.
>&
unknown-xxx"
I hope this patch is not accepted and that the simple patch
that just names above as "unknown-12" is. KISS right?
Signed-off-by: Boaz Harrosh
---
arch/x86/include/uapi/asm/e820.h | 1 -
arch/x86/kernel/e820.c | 29 -
2 file
In this patch I name type-12 "unknown-12". This is because of
ACPI politics that refuse to reserve type-12 as DDR3-NvDIMM
and members keep saying:
"What if ACPI assigns type-12 for something else in future"
[And I say: Then just don't. Please?]
Signed-off-by: Bo
r
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Dan Williams
CC: Andrew Morton
CC: Bjorn Helgaas
CC: Vivek Goyal
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 3 +++
include/linux/ioport.h | 23 +++
kernel/resource.c | 7 ++
Estimated 100ds of thousands sold world wide)
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Dan Williams
CC: Matthew Wilcox
CC: Christoph Hellwig
CC: Andy Lutomirski
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 31
Hi
[v2]
* Added warning at bring up about unknown type
* Added an extra patch to warn-print in request_resource
* changed name from NvDIMM-12 => unknown-12
I wish we would reconsider this. So we need to suffer until some unknown
future when ACPI decides to reuse type-12. When this happens we c
On 02/22/2015 07:05 PM, Boaz Harrosh wrote:
> On 02/22/2015 06:27 PM, Christoph Hellwig wrote:
<>
>> I won't be back to my nvdimm enabled hardware until after LSF/MM,
>> so any work from me in this area will have to wait a bit.
>>
<>
BTW: I have an out
On 02/22/2015 06:27 PM, Christoph Hellwig wrote:
> On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote:
>> I do not see why you need the nvdimm_type= kernel option at all.
>>
>> I have here a script that auto detects any NvDIMM. It works with all
>> the chips
On 02/21/2015 01:52 PM, Nicolas Iooss wrote:
<>
>
> I'm basically developing a project where I created an out-of-tree module
> which uses mmap() as a kind of communication channel between a kernel
> module and a userspace program (in short, a ring buffer). The virtual
> file which is used for mma
On 02/19/2015 12:31 PM, Ingo Molnar wrote:
<>
>> I will submit a new version of my patch-1 with the
>> pr_warn.
>>
>> Or did you already apply my patch-1 and you want one on
>> top? What is the URL of your tree please?
>
> New patch please, and please also Cc: everyone who
> expressed interest
On 02/19/2015 12:01 PM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig
>> wrote:
>>> On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote:
In fact it was originally "type-6" until ACPI 5
claimed that number for official u
On 02/18/2015 09:35 PM, Dan Williams wrote:
> On Wed, Feb 18, 2015 at 11:27 AM, Ingo Molnar wrote:
>>
<>
>>>
>>> No, it seems the safe thing to do is prevent the
>>> kernel from accessing any memory that it does not know
>>> the side-effects of accessing.
>>
<>
The Kernel does
On 02/19/2015 02:47 AM, Christoph Hellwig wrote:
> On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote:
>> In fact it was originally "type-6" until ACPI 5 claimed that number
>> for official use, so these platforms, with early proof-of-concept
>> nvdimm support, have already gone through o
On 02/17/2015 10:52 PM, Ross Zwisler wrote:
> On Mon, 2015-02-16 at 13:24 +0200, Boaz Harrosh wrote:
>> With old Kernels there was a bug in x86 where any unknown
>> memory chip type would come up BUSY when calling
>> request_mem_region_exclusive().
>>
>> So for
On 02/17/2015 12:03 AM, Matthew Wilcox wrote:
> On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
>> In any way this is a problem for the new type-12 NvDIMM memory chips that
>> are circulating around. (It is estimated that there are already 100ds of
>> thousands N
with hacked up pmem that will ignore
the return code from request_mem_region_exclusive. So here it is
official
Signed-off-by: Boaz Harrosh
---
drivers/block/Kconfig | 12
drivers/block/pmem.c | 11 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers
ere any reason why I should not submit the final
version as "NvDIMM" from the get go. Then if the ACPI defines
another new type-Y Memory we can name both types "NvDIMM", No?
Please comment
Signed-off-by: Boaz Harrosh
---
arch/x86/include/uapi/asm/e820.h | 2 +-
arch/x86/ke
t;UNKNOWN" type is the not Standard type-12
DDR3-NvDIMM which is used by multiple vendors for a while
now. (Estimated 100ds of thousands sold world wide)
A later patch adds type-12 to the list of "KNOWN", types.
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 20 ++
Hi
There is a deficiency in current e820.c handling where unknown new memory-chip
types come up as a BUSY resource when some other driver (like pmem) tries to
call request_mem_region_exclusive() on that resource. Even though, actually
there is nothing using it.
>From inspecting the code and the hi
On 01/22/2015 02:39 PM, Boaz Harrosh wrote:
> From: Boaz Harrosh
>
> As Christoph put it:
> Can we just get rid of the warnings? It's fairly annoying as devices
> without partitions are perfectly fine and very useful.
>
> Me too I see this message every VM boot fo
From: Boaz Harrosh
As Christoph put it:
Can we just get rid of the warnings? It's fairly annoying as devices
without partitions are perfectly fine and very useful.
Me too I see this message every VM boot for ages on all my
devices. Would love to just remove it. For me a partition-tab
On 01/18/2015 05:32 PM, Boaz Harrosh wrote:
> From: Boaz Harrosh
>
> As Christoph put it best:
> Can we just get rid of the warnings? It's fairly annoying as devices
> without partitions are perfectly fine and very useful.
>
> Me too I see this message every
From: Boaz Harrosh
As Christoph put it best:
Can we just get rid of the warnings? It's fairly annoying as devices
without partitions are perfectly fine and very useful.
Me too I see this message every VM boot for ages on all my
devices. Would love to just remove it. For me a part
On 01/17/2015 12:49 AM, Jens Axboe wrote:
> On 01/16/2015 03:32 PM, Tony Luck wrote:
>> On Wed, Jan 7, 2015 at 8:07 AM, Boaz Harrosh wrote:
>>> From: Boaz Harrosh
>>>
>>> This patch fixes up brd's partitions scheme, now enjoying all worlds.
>>
On 01/08/2015 10:56 PM, Jens Axboe wrote:
> On 01/07/2015 09:02 AM, Boaz Harrosh wrote:
>> Jens Hi
>>
>> Currently brd has multiple bugs when trying to use partitions. After this
>> set all known problems are solved. Please see individual patch for
>> descripti
From: Boaz Harrosh
Because of the direct_access() API which returns a PFN. partitions
better start on 4K boundary, else offset ZERO of a partition will
not be aligned and blk_direct_access() will fail the call.
By setting blk_queue_physical_block_size(PAGE_SIZE) we can communicate
this to fdisk
From: Boaz Harrosh
This patch fixes up brd's partitions scheme, now enjoying all worlds.
The MAIN fix here is that currently, if one fdisks some partitions,
a BAD bug will make all partitions point to the same start-end sector
ie: 0 - brd_size And an mkfs of any partition would tras
, checking the length requested
is positive, checking for the sector being page-aligned, and checking
the length of the request does not pass the end of the partition.
Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Boaz Harrosh
---
Documentation/filesystems/xi
From: Matthew Wilcox
The 'pfn' returned by axonram was completely bogus, and has been since
2008.
Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Mathieu Desnoyers
Cc: sta...@vger.kernel.org
---
arch/powerpc/sysdev/axonram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Jens Hi
Currently brd has multiple bugs when trying to use partitions. After this
set all known problems are solved. Please see individual patch for description
of the problem.
(Another merge window, another patchset send. I wish you would tell me to
just *uck-off, instead of this silence. What i
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict
> in .gitignore between commit dfe0487249e5 (".gitignore: Add Kdevelop4
> project files") from the kbuild tree and commit 75185f57f110 ("staging:
> unisys: fix CamelCase macro names in controlframework.h") from the
> stagin
On 11/25/2014 10:22 PM, Michal Marek wrote:
> On Tue, Nov 25, 2014 at 06:42:54PM +0200, Boaz Harrosh wrote:
>> From: Boaz Harrosh
>>
>> I'm not sure what is the costume with such IDE project files.
>> Most might be dot-files. It is kind of annoying for the Kdevelop
From: Boaz Harrosh
I'm not sure what is the costume with such IDE project files.
Most might be dot-files. It is kind of annoying for the Kdevelop4 user.
So please consider adding *.kdev4 files to be ignored?
Signed-off-by: Boaz Harrosh
---
.gitignore | 1 +
1 file changed, 1 inse
On 11/20/2014 03:11 PM, Tejun Heo wrote:
> Hello, Boaz.
>
<>
> W/ preloading, one way to do it is,
>
> if (preload())
> handle -ENOMEM;
> lock;
> error = insert();
> if (error)
> handle error which can't be -ENOMEM;
> unlock;
> prelo
On 11/20/2014 01:50 PM, Tejun Heo wrote:
> Hello, Boaz.
>
> On Thu, Nov 20, 2014 at 12:42:53PM +0200, Boaz Harrosh wrote:
>> if I understand correctly the motivation here is that the allocation
>> of the internal element is done GFP_KERNEL at this call
>>
>> Then
On 11/14/2014 12:11 AM, Tejun Heo wrote:
> inode->i_devices is a list_head used to link device inodes to the
> corresponding block_device or cdev. This patch makes block_device and
> cdev usfe ptrset to keep track of the inodes instead of linking
> inode->i_devices allowing removal of the field an
On 11/14/2014 12:11 AM, Tejun Heo wrote:
<>
> @@ -426,7 +427,7 @@ struct block_device {
> struct inode * bd_inode; /* will die */
> struct super_block *bd_super;
> struct mutexbd_mutex; /* open/close mutex */
> - struct list_headbd_
On 11/18/2014 11:10 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Tue, 18 Nov 2014 10:05:19 +0100
>
> The ore_put_io_state() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using
On 11/13/2014 11:22 PM, Pieter Smith wrote:
> Compile out splice support from exofs when the splice-family of syscalls is
> not
> supported by the system (i.e. CONFIG_SYSCALL_SPLICE is undefined).
>
> Signed-off-by: Pieter Smith
ACK-by: Boaz Harrosh
Or do you need that I pus
On 11/10/2014 11:58 AM, Karel Zak wrote:
> On Sun, Nov 09, 2014 at 06:57:27PM +0200, Boaz Harrosh wrote:
>> with a small 4M disk
>
> This is the problem, for small disks (<= 4MiB) we don't use 1MiB
> grain because it does not make sense. For so small devices t
On 11/06/2014 07:25 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh writes:
>
> Boaz,
>
> Boaz> Note that blk_queue_physical_block_size() also trashes io_min, but
> Boaz> we can leave this one to be 512. io_min as opposed to
> B
On 11/07/2014 11:23 AM, Karel Zak wrote:
> On Wed, Nov 05, 2014 at 04:10:50PM +0200, Boaz Harrosh wrote:
>> From: Boaz Harrosh
>>
>> Now when fdisk is run on brd it will ask some cryptic
>> questions about CHS. This is because the getgeo block operation
>> is n
On 11/05/2014 05:14 PM, Boaz Harrosh wrote:
> From: Boaz Harrosh
>
Sorry
[V4]
Also fix the cryptic comment at the source code.
I have pushed new trees to the public tree as well
Thanks
Boaz
<>
> +static int brd_getgeo(struct block_device *bd, struct hd_geometry *geo)
>
From: Boaz Harrosh
Now when fdisk is run on brd it will ask some cryptic
questions about CHS. This is because the getgeo block operation
is not implemented.
With the usual emulated values of 64, 32, X and the default
size of 4M device, fdisk will offer 34 as possible first-sector,
And after the
On 11/05/2014 04:20 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh writes:
>
> Hey Boaz,
>
> Boaz> Note that blk_queue_physical_block_size() also trashes io_min, but
> Boaz> we can leave this one to be 512. io_min as opposed to
From: Boaz Harrosh
Now when fdisk is run on brd it will ask some cryptic
questions about CHS. This is because the getgeo block operation
is not implemented.
With the usual emulated values of 64, 32, X and the default
size of 4M device, fdisk will offer 34 as possible first-sector,
And after the
From: Boaz Harrosh
Because of the direct_access() API which returns a PFN. partitions
better start on 4K boundary, else offset ZERO of a partition will
not be aligned and blk_direct_access() will fail the call.
By setting blk_queue_physical_block_size(PAGE_SIZE) we can communicate
this to fdisk
From: Boaz Harrosh
This patch fixes up brd's partitions scheme, now enjoying all worlds.
The MAIN fix here is that currently, if one fdisks some partitions,
a BAD bug will make all partitions point to the same start-end sector
ie: 0 - brd_size And an mkfs of any partition would tras
, checking the length requested
is positive, checking for the sector being page-aligned, and checking
the length of the request does not pass the end of the partition.
Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Boaz Harrosh
---
Documentation/filesystems/xi
From: Matthew Wilcox
The 'pfn' returned by axonram was completely bogus, and has been since
2008.
Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Mathieu Desnoyers
Cc: sta...@vger.kernel.org
---
arch/powerpc/sysdev/axonram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Jens Hi
Currently brd has multiple bugs when trying to use partitions. After this
set all known problems are solved. Please see individual patch for description
of the problem.
[v3]
Same exact code but some commit messages changed to try and explain better
what was fixed and why. (Rebased on 3.18
201 - 300 of 573 matches
Mail list logo
