On Thu, Sep 03, 2015 at 12:36:08PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 03, 2015 at 07:16:19PM +0000, Richard Yao wrote:
> > On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> > > On Thu, Sep 03, 2015 at 06:22:25PM +, Richard Yao wrote:
> > &g
On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone
> > runs
> > `mount -t ext3 /dev/$DEVICE $MNT`?
> >
> &g
On Thu, Sep 03, 2015 at 01:36:45PM -0500, Eric Sandeen wrote:
> On 9/3/15 1:22 PM, Richard Yao wrote:
> > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone
> > runs
> > `mount -t ext3 /dev/$DEVICE $MNT`?
> >
> > This should fail with the
What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
`mount -t ext3 /dev/$DEVICE $MNT`?
This should fail with the ext3 driver, but it looks like it will work fine with
CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
not built with CONFIG_E
I seem to have botched the reply headers, so I am resending this. I use mutt
fairly infrequently, but I am making an effort to use it more it more.
On Tue, Sep 01, 2015 at 02:21:43PM +0100, Ben Hutchings wrote:
> On Tue, 2015-09-01 at 01:24 +0000, Richard Yao wrote:
> > On Mon, 2015-08
On Mon, 2015-08-17 09:56:55 -0700, Ben Hutchings wrote:
> On Mon, 2015-08-17 at 17:11 +0200, Michal Hocko wrote:
> > On Mon 17-08-15 16:56:32, Ben Hutchings wrote:
> > > On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> > > > On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > > > > Proprieta
On 20 July 2015 at 19:52, Richard Yao wrote:
>
> From: Richard Yao
>
> I noticed that genksyms will segfault when it sees duplicate function
> pointer type declaration when I placed the same function pointer
> definition in two separate headers in a local branch as an intermedi
From: Richard Yao
I noticed that genksyms will segfault when it sees duplicate function
pointer type declaration when I placed the same function pointer
definition in two separate headers in a local branch as an intermediate
step of some refactoring. This can be reproduced by piping the
, dash and
zsh. Other shells were not tested.
Signed-off-by: Richard Yao
Reviewed-by: Emilio López
---
tools/perf/config/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 094ddae..70426d6 100644
--- a/tools/p
10093
Now all I need to do is take time during my weekend to figure out how to
do it. My apologies for the noise.
On 05/18/2015 02:07 PM, Richard Yao wrote:
> Is there anyway to do direct mapped cache on Intel hardware?
>
> Direct mapped cache should allow me to implement software ECC
Is there anyway to do direct mapped cache on Intel hardware?
Direct mapped cache should allow me to implement software ECC via the
low memory / high memory split. It would be slow, but I would prefer to
have a slow laptop than one that is vulnerable to bit flips.
If direct mapped cache is possibl
On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
> On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
>> Assuming that this dance succeeds, the FUSE process could then make a
>> readonly file in itself, open it read only, unlink it, put the data into
>> the f
be able to perform multicast and zero copy using memfd. Is
there something that I have missed that make this not the case?
Yours truly,
Richard Yao
signature.asc
Description: OpenPGP digital signature
On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
>>>> They regard a userland compatibility shim in the systemd repostory to
>>>> provide
>>>> backward compatibility for applications. Unfor
On 11/29/2014 12:59 PM, Greg Kroah-Hartman wrote:
> On Sat, Nov 29, 2014 at 06:34:16AM +0000, Richard Yao wrote:
>> I had the opportunity at LinuxCon Europe to chat with Greg and some other
>> kdbus
>> developers. A few things stood out from our conversation that I thought I
On 12/01/2014 09:23 AM, One Thousand Gnomes wrote:
>> told quite plainly that such distributions are not worth consideration. If
>> kdbus
>> is merged despite concerns about security and backward compatibility, could
>> we
>> at least have the shim moved to libc netural place, like Linus' tree?
>
I had the opportunity at LinuxCon Europe to chat with Greg and some other kdbus
developers. A few things stood out from our conversation that I thought I would
bring to the list for discussion.
The first is that I asked them why we need to add yet another IPC mechanism (and
quite possibly another
major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.
Signed-off-by: Richard Yao
---
fs/namespace.c | 20
fs/pnode.h | 17 +
2 files changed, 25
a bug that has annoyed both myself and others for some time
now. I am presently super busy preparing for next week's Open ZFS developer
summit, but I would love to see this patch merged. I will make time to respond
to any emails regarding it.
Yours truly,
Richard Yao
Richard Yao (1):
major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.
Signed-off-by: Richard Yao
---
fs/namespace.c | 20
fs/pnode.h | 17 +
2 files changed, 25
sk if including him as ACKed by was okay. I have CCed
Mateusz, Ted, Mauro, the usual people from get_maintainers.pl and other
interested parties.
Yours truly,
Richard Yao
Richard Yao (1):
vfs: Respect MS_RDONLY at bind mount creation
fs/namespace.c | 20
fs/pnode.h
tly.
Richard Yao (1):
vfs: Respect MS_RDONLY at bind mount creation
fs/namespace.c | 20
fs/pnode.h | 17 +
2 files changed, 25 insertions(+), 12 deletions(-)
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.
Signed-off-by: Richard Yao
---
fs/namespace.c | 20
fs/pnode.h | 17 +
2 files changed, 25
This revision introduces CL_MAKE_RDONLY to propagate the request to make things
readonly all the way to clone_mnt() as suggested by Mateusz Guzik.
Richard Yao (1):
vfs: Respect MS_RDONLY at bind mount creation
fs/namespace.c | 15 +++
fs/pnode.h | 17 +
2 files
major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.
Signed-off-by: Richard Yao
---
fs/namespace.c | 15 +++
fs/pnode.h | 17 +
2 files changed, 20 insertions
On 08/01/2014 03:20 PM, Mateusz Guzik wrote:
> On Fri, Aug 01, 2014 at 02:12:24PM -0400, Richard Yao wrote:
>> `mount -o bind,ro ...` suffers from a silent failure where the readonly
>> flag is ignored. The bind mount will be created rw whenever the target
>> is rw. Users typi
, so I am sending it again with some minor corrections. I
had considered splitting the mnt_make_readonly() loop into its own helper
function for readability, but that turned out to make the code less readable.
Richard Yao (1):
vfs: Respect MS_RDONLY at bind mount creation
fs/namespace.c | 13
major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.
Signed-off-by: Richard Yao
---
fs/namespace.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs
soft
deadlock.
Signed-off-by: Richard Yao
---
mm/vmscan.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 3f56c8d..c07c635 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1083,13 +1083,16 @@ static unsigned long shrink_page_list(struct
I do not have a way of tracing it. I meant to reply when I did, but that has
not changed. That being said, I like this patch.
On May 29, 2014, at 2:22 AM, Joonsoo Kim wrote:
> Richard Yao reported a month ago that his system have a trouble
> with vmap_area_lock contention during perfo
Commit-ID: 61d4290cc1f10588147b76b385875f06827d47ff
Gitweb: http://git.kernel.org/tip/61d4290cc1f10588147b76b385875f06827d47ff
Author: Richard Yao
AuthorDate: Sat, 26 Apr 2014 13:17:55 -0400
Committer: Jiri Olsa
CommitDate: Wed, 30 Apr 2014 16:49:29 +0200
perf machine: Search for
On Apr 27, 2014, at 4:08 PM, Linus Torvalds
wrote:
> On Sun, Apr 27, 2014 at 5:08 AM, Ingo Molnar wrote:
>>
>> So it's useful information for hairy bugs and it would be sad to
>> remove them.
>
> I tend to agree. I've often found the left-overs to be good clues
> about what just got called. A
:
>
> * Richard Yao wrote:
>
>> Stack traces are generated by scanning the stack and interpeting
>> anything that looks like it could be a pointer to something. We do
>> not need to do this when we have frame pointers, but we do it
>> anyway, with the distinctio
: Richard Yao
---
arch/x86/kernel/dumpstack.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index d9c12d3..94ffe06 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -162,7 +162,11 @@ static void
,
Richard Yao
On 04/15/2014 07:56 AM, Jiri Olsa wrote:
> On Tue, Apr 15, 2014 at 02:44:52PM +0900, Namhyung Kim wrote:
>> Hi Richard,
>>
>> On Thu, 10 Apr 2014 12:52:59 -0400, Richard Yao wrote:
>>> Modules installed outside of the kernel's build system should go into
ts that I
had been doing meant that perf was also traversing the build and source
symlinks in %s/lib/modules/%s. That is undesireable, so we explicitly
exclude them from traversal with a minor tweak to the traversal routine.
Signed-off-by: Richard Yao
---
tools/perf/util/machine.c | 16 +++
On 04/10/2014 12:51 PM, Andi Kleen wrote:
> Richard Yao writes:
>
>> Performance analysis of software compilation by Gentoo portage on an
>> Intel E5-2620 with 64GB of RAM revealed that a sizeable amount of time,
>> anywhere from 5% to 15%, was spent in get_vmalloc_inf
ules/%s". This
way open source modules that are out-of-tree have no incentive to start
populating a directory reserved for in-kernle modules and I can stop hex
editing my system's perf binary when profiling OSS out-of-tree modules.
Signed-off-by: Richard Yao
---
tools/perf/util/machine.c |
spent
spinning is clear.
Signed-off-by: Richard Yao
---
lib/Kconfig.debug | 11 +++
mm/vmalloc.c | 32
2 files changed, 43 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index dd7f885..a3e6967 100644
--- a/lib/Kconfig.debug
+++
regression the problem David S. Miller found when CONFIG_NET_9P_VIRTIO=m was
set and should resolve all criticism.
Richard Yao (1):
9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
net/9p/trans_virtio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--
1.8.3.2
--
To
much longer. Also, special thanks to Linus
Torvalds for his insightful explanation of why this should use
is_vmalloc_addr() instead of is_vmalloc_or_module_addr():
https://lkml.org/lkml/2014/2/8/272
Signed-off-by: Richard Yao
---
net/9p/trans_virtio.c | 5 -
1 file changed, 4 insertions(+), 1
On Feb 8, 2014, at 5:24 PM, Linus Torvalds
wrote:
> On Sat, Feb 8, 2014 at 12:44 PM, Richard Yao wrote:
>>
>> However, is_vmalloc_addr() only applies to the vmalloc region. While all
>> architectures load kernel modules into virtual memory (to my knowledge),
>> som
On 02/08/2014 03:06 PM, Linus Torvalds wrote:
> On Sat, Feb 8, 2014 at 11:58 AM, Richard Yao wrote:
>>
>> My apologies for that. Here is the backtrace:
>>
>> [] p9_virtio_zc_request+0x45e/0x510
>> [] p9_client_zc_rpc.constprop.16+0xfd/0x4f0
>> [] p9_clien
On 02/08/2014 02:45 PM, Linus Torvalds wrote:
> On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao wrote:
> And what's the backtrace that gets mentioned - but not quoted - for
> the horrible 9p crap? So that we can see who the guilty party is that
> thinks that it's somehow ok to
his pull request to you for approval.
Richard Yao (2):
mm/vmalloc: export is_vmalloc_or_module_addr
9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
mm/vmalloc.c | 1 +
net/9p/trans_virtio.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
--
1.8.3.2
--
ZFS file-based vdevs on virtfs to be used without killing QEMU.
Also, special thanks to both Avi Kivity and Alexander Graf for their
interpretation of QEMU backtraces. Without their guidence, tracking down
this bug would have taken much longer.
Signed-off-by: Richard Yao
Acked-by: Alexander Graf
breaks with that patch applied and
CONFIG_NET_9P_VIRTIO=m. With this export in place, all is well.
Signed-off-by: Richard Yao
---
mm/vmalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0fdf968..8a2e54f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -218,6
his pull request to you for approval.
Richard Yao (2):
mm/vmalloc: export is_vmalloc_or_module_addr
9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
mm/vmalloc.c | 1 +
net/9p/trans_virtio.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
--
1.8.3.2
--
On Jan 30, 2014, at 7:44 PM, David Miller wrote:
> From: David Miller
> Date: Thu, 30 Jan 2014 16:29:26 -0800 (PST)
>
>> From: Richard Yao
>> Date: Thu, 30 Jan 2014 13:02:48 -0500
>>
>>> The 9p-virtio transport does zero copy on things larger than 1024 byt
->readv, ->writev and ->sendfile have been removed while ->show_fdinfo
has been added. The documentation should reflect this.
Signed-off-by: Richard Yao
---
Documentation/filesystems/vfs.txt | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/D
ZFS file-based vdevs on virtfs to be used without killing QEMU.
Also, special thanks to both Avi Kivity and Alexander Graf for their
interpretation of QEMU backtraces. Without their guidence, tracking down
this bug would have taken much longer.
Signed-off-by: Richard Yao
Acked-by: Alexander Graf
by this
issue because it was not sent to the correct people sooner.
Richard Yao (1):
9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
net/9p/trans_virtio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--
1.8.3.2
--
To unsubscribe from this list: send the line
On 12/31/2013 02:41 PM, Dominique Martinet wrote:
> Hi,
Thanks for the fast reply.
> Richard Yao wrote on Tue, Dec 31, 2013 :
>> #!/bin/bash
>> cat <<-EOF
>> EOF
>>
>> Running this causes bash to fork via clone(), set fd=0 to point to an
>> e
I have a small shell script:
#!/bin/bash
cat <<-EOF
EOF
Running this causes bash to fork via clone(), set fd=0 to point to an
empty file in /tmp, unlink it and then execve cat. Specifically,
something like this;
[pid 3699] open("/tmp/sh-thd-1388524249",
O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) =
ZFSOnLinux does memory allocations using a wrapper that invokes
dump_stack() whenever GFP_KERNEL is used in a performance-critical path
(e.g. one that affects swap).
Unfortunately, dump_stack() seems to always produce nonsensical
backtraces. Here is an example that a Debian user sent me yesterday:
Why are the LZ4 symbols being GPL-exported when the LZ4 code is
BSD-licensed and no substantial changes appear to have been made when it
was merged?
Also, why is the module license GPL when the code itself is clearly
under a BSD license?
signature.asc
Description: OpenPGP digital signature
On 06/16/2013 03:00 AM, Jeff Liu wrote:
> On 06/16/2013 08:46 AM, Richard Yao wrote:
>
>> On 06/15/2013 01:09 AM, Jeff Liu wrote:
>>> [Add ocfs2-devel to CC-list]
>>>
>>> Hello Richard,
>>>
>>> Thanks for your patch.
>>>
>>
On 06/15/2013 01:09 AM, Jeff Liu wrote:
> [Add ocfs2-devel to CC-list]
>
> Hello Richard,
>
> Thanks for your patch.
>
> On 06/15/2013 03:23 AM, Richard Yao wrote:
>
>> There are multiple issues with the custom llseek implemented in ocfs2 for
>> implement
On 06/15/2013 02:22 AM, shencanquan wrote:
> Hello, Richard and Jeff,
>we found that llseek has another bug when in SEEK_END. it should be
> add the inode lock and unlock.
>this bug can be reproduce the following scenario:
>on one nodeA, open the file and then write some data to file a
that issue. However, the ocfs2 code was not fortunate enough
to have had this corrected at that time.
Signed-off-by: Richard Yao
---
fs/btrfs/file.c | 49 -
1 file changed, 20 insertions(+), 29 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.
addressed #3 in btrfs. The only lingering issue was that
the offset > inode->i_sb->s_maxbytes check became dead code. The ocfs2
code was not fortunate enough to have had a similar correction until
now.
Signed-off-by: Richard Yao
---
fs/ocfs2/file.c | 65 ++
alues when in reality such functions should only
care about SEEK_HOLE/SEEK_DATA. Any other cases should be passsed to
generic_file_llseek().
Richard Yao (2):
ocfs2: Fix llseek() semantics and do some cleanup
btrfs: Cleanup llseek()
fs/btrfs/file.c | 49 ++-
On 06/08/2013 02:11 AM, Sergei Trofimovich wrote:
> On Fri, 07 Jun 2013 23:47:33 -0400
> Richard Yao wrote:
>
>> When you use dm-crypt, block IO requests to a dm-* device will invoke
>> dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
>>
When you use dm-crypt, block IO requests to a dm-* device will invoke
dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
which will immediately queue it to the device.
If a few dozen IOs are queued in rapid succ
On 12/01/2012 01:30 PM, Roger Heflin wrote:
> On Sat, Dec 1, 2012 at 6:04 AM, Richard Yao wrote:
>> Standard Microsystems Corp. 8-in-1 Card
>> Reader
>
> Does that card reader support SDHC cards?The older readers don't
> support >2GB (ie sdhc)
> cards, a
I have the following SD Card Reader:
http://support.dell.com/support/edocs/monitors/2405fpw/en/about.htm#Card
Reader Specificatoins
It is identified as the following in lsusb:
Bus 002 Device 007: ID 0424:223a Standard Microsystems Corp. 8-in-1 Card
Reader
I have a LG microSD Card adapter that c
66 matches
Mail list logo
