Miklos Szeredi writes:
> On Mon, Nov 26, 2012 at 3:29 AM, Ian Kent wrote:
>>> > > MS_UNBINDABLE says: skip this mount when copying a mount tree, such
>>> > > as when the mount namespace is cloned.
>>> > >
>>> > > If you set MS_UNBINDABLE on autofs mounts then they will simply not
>>> > > appear
Zhang Yanfei writes:
> This patch adds an atomic notifier list named crash_notifier_list.
> Currently, when loading kvm-intel module, a notifier will be registered
> in the list to enable vmcss loaded on all cpus to be VMCLEAR'd if
> needed.
crash_notifier_list ick gag please no. Effectively th
Gleb Natapov writes:
> On Mon, Nov 26, 2012 at 09:08:54AM -0600, Eric W. Biederman wrote:
>> Zhang Yanfei writes:
>>
>> > This patch adds an atomic notifier list named crash_notifier_list.
>> > Currently, when loading kvm-intel module, a notifier will be regi
Gleb Natapov writes:
> On Mon, Nov 26, 2012 at 11:43:10AM -0600, Eric W. Biederman wrote:
>> Gleb Natapov writes:
>>
>> > On Mon, Nov 26, 2012 at 09:08:54AM -0600, Eric W. Biederman wrote:
>> >> Zhang Yanfei writes:
>> >>
>&
Stephen Rothwell writes:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in kernel/fork.c
> between commit b2e0d98705e6 ("userns: Implement unshare of the user
> namespace") from the userns tree and commit ("fork: unshare: remove dead
> cod") from the akpm tree.
>
> I f
Zhang Yanfei writes:
> So in summary,
>
> 1. a specific callback function instead of a notifier?
Yes.
> 2. Instead of calling vmclear_local_loaded_vmcss, the vmclear operation
>will just call the vmclear on every vmcss loaded on the cpu?
>
>like below:
>
>static void crash_vmclear_l
Petr Tesarik writes:
> To allow filtering of huge pages, makedumpfile must be able to identify
> them in the dump. This can be done by checking for the appropriate
> page flag, so communicate its value to makedumpfile through the VMCOREINFO
> interface.
I don't have any siginificant problems wi
Adding Serge as he is the sometimes capabilities maintainer to this
discussion.
Casey Schaufler writes:
> On 3/18/2013 11:30 AM, Vivek Goyal wrote:
>> On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote:
>>> On 3/18/2013 10:05 AM, Vivek Goyal wrote:
On Fri, Mar 15, 2013 at 02:1
HATAYAMA Daisuke writes:
> Due to mmap() requirement, we need to copy pages not starting or
> ending with page-size aligned address in 2nd kernel and to map them to
> user-space.
>
> For example, see the map below:
>
> -0001 : reserved
> 0001-0009f800 : System RAM
> 00
HATAYAMA Daisuke writes:
> To satisfy mmap()'s page-size boundary requirement, allocate per-cpu
> crash_notes objects on page-size boundary.
>
> /proc/vmcore on the 2nd kernel checks if each note objects is
> allocated on page-size boundary. If there's some object not satisfying
> the page-size b
HATAYAMA Daisuke writes:
> To satisfy mmap()'s page-size boundary requirement, specify aligned
> attribute to vmcoreinfo_note objects to allocate it on page-size
> boundary.
Again I am not seeing the point.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
HATAYAMA Daisuke writes:
> Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD type
> note in order to make the buffer satisfy mmap()'s page-size boundary
> requirement. This patch makes finishing reading each buffer if the
> note type now being read is NT_VMCORE_PAD type.
Ick. Ev
Andrew Morton writes:
> On Sat, 16 Mar 2013 13:02:29 +0900 HATAYAMA Daisuke
> wrote:
>
>> If there's some vmcore object that doesn't satisfy page-size boundary
>> requirement, remap_pfn_range() fails to remap it to user-space.
>>
>> Objects that posisbly don't satisfy the requirement are ELF n
HATAYAMA Daisuke writes:
> Currently, the code assumes that position of program header table is
> next to ELF header. But future change can break the assumption on
> kexec-tools and the 1st kernel. To avoid worst case, reference e_phoff
> member explicitly to get position of program header table
HATAYAMA Daisuke writes:
> Current code assumes all PT_NOTE headers are placed at the beginning
> of program header table and they are consequtive. But the assumption
> could be broken by future changes on either kexec-tools or the 1st
> kernel. This patch removes the assumption and rearranges pr
HATAYAMA Daisuke writes:
> To satisfy mmap() page-size boundary requirement, round up buffer size
> of ELF headers by PAGE_SIZE. The resulting value becomes offset of ELF
> note segments and it's assigned in unique PT_NOTE program header
> entry.
Ok. That is just silly. You can use a single buf
HATAYAMA Daisuke writes:
> To satisfy mmap()'s page-size boundary requirement, allocate per-cpu
> crash_notes objects on page-size boundary.
>
> /proc/vmcore on the 2nd kernel checks if each note objects is
> allocated on page-size boundary. If there's some object not satisfying
> the page-size b
HATAYAMA Daisuke writes:
> To satisfy mmap()'s page-size boundary requirement, specify aligned
> attribute to vmcoreinfo_note objects to allocate it on page-size
> boundary.
Those requirements don't exist. Making this patch wasteful and wrong.
Eric
> Signed-off-by: HATAYAMA Daisuke
> ---
>
>
HATAYAMA Daisuke writes:
> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
> note type to make them satisfy mmap()'s page-size boundary
> requirement.
The requirement does not exist. Making this change wasteful wrong, and
potentially a ABI change between the first and second
HATAYAMA Daisuke writes:
> Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD type
> note in order to make the buffer satisfy mmap()'s page-size boundary
> requirement. This patch makes finishing reading each buffer if the
> note type now being read is NT_VMCORE_PAD type.
There is
HATAYAMA Daisuke writes:
> If there's some vmcore object that doesn't satisfy page-size boundary
> requirement, remap_pfn_range() fails to remap it to user-space.
>
> Objects that posisbly don't satisfy the requirement are ELF note
> segments only. The memory chunks corresponding to PT_LOAD entri
HATAYAMA Daisuke writes:
> Currently, read to /proc/vmcore is done by read_oldmem() that uses
> ioremap/iounmap per a single page. For example, if memory is 1GB,
> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
> times. This causes big performance degradation.
>
> In particular, the
Vivek Goyal writes:
> Are you saying that some parts of the vmcore file will support mmap() and
> others will not. If yes, how would a user know which parts of file are
> mappable and which are not.
I think I answered this in another email in my review but I will
reanswer here.
There is absolut
Serge Hallyn writes:
> Hi,
>
> Benoit was kind enough to follow up on some scalability issues with
> larger (but not huge imo) numbers of containers. Running a script
> to simply time the creation of veth pairs on a rather large (iiuc)
> machine, he got the following numbers (time is for creatio
Benoit Lourdelet writes:
> Hello,
>
> The measurement has been done with kernel 3.8.2.
>
> Linux ieng-serv06 3.7.9 #3 SMP Wed Feb 27 02:38:58 PST 2013 x86_64 x86_64
> x86_64 GNU/Linux
Two different kernel versions?
> What information would you like to see on the kernel ?
The question is where
Vivek Goyal writes:
> On Tue, Mar 19, 2013 at 03:12:10PM -0700, Eric W. Biederman wrote:
>> HATAYAMA Daisuke writes:
>>
>> > To satisfy mmap()'s page-size boundary requirement, allocate per-cpu
>> > crash_notes objects on page-size boundary.
>> >
Vivek Goyal writes:
> On Tue, Mar 19, 2013 at 03:38:45PM -0700, Eric W. Biederman wrote:
>> HATAYAMA Daisuke writes:
>>
>> > If there's some vmcore object that doesn't satisfy page-size boundary
>> > requirement, remap_pfn_range() fails to rem
HATAYAMA Daisuke writes:
> From: "Eric W. Biederman"
> Subject: Re: [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark
> indicating the end of ELF note buffer
> Date: Tue, 19 Mar 2013 14:11:51 -0700
>
>> HATAYAMA Daisuke writes:
>>
>>> Moder
HATAYAMA Daisuke writes:
> From: "Eric W. Biederman"
> Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
> page-size boundary requirement
> Date: Wed, 20 Mar 2013 13:55:55 -0700
>
>> Vivek Goyal writes:
>>
>>&g
HATAYAMA Daisuke writes:
> From: "Eric W. Biederman"
> Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to
> get position of program header table
> Date: Tue, 19 Mar 2013 14:44:16 -0700
>
>> HATAYAMA Daisuke writes:
>>
>>>
HATAYAMA Daisuke writes:
> From: Andrew Morton
> Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
> Date: Tue, 19 Mar 2013 12:30:05 -0700
>
>> On Sat, 16 Mar 2013 13:00:47 +0900 HATAYAMA Daisuke
>> wrote:
>>
>>> Currently, read to /proc/vmcore is done by read_oldmem
HATAYAMA Daisuke writes:
>
> Do you mean for each range represented by each PT_LOAD entry, say:
>
> [p_paddr, p_paddr + p_memsz]
>
> extend it as:
>
> [rounddown(p_paddr, PAGE_SIZE), roundup(p_paddr + p_memsz, PAGE_SIZE)].
>
> not only objects in vmcore_list, but also updating p_paddr and p_me
HATAYAMA Daisuke writes:
> From: "Eric W. Biederman"
> Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
> page-size boundary requirement
> Date: Wed, 20 Mar 2013 23:29:05 -0700
>
>> HATAYAMA Daisuke writes:
>>>
>&
HATAYAMA Daisuke writes:
> The breakage was caused by the introduction of new NT_VMCORE_PAD to
> "VMCOREINFO" name, except for which it worked fine. But it will be
> dropped in the next version. It'll be no problem for some time.
>
> The breakage was caused by makedumpfile itself due to the bug t
HATAYAMA Daisuke writes:
> OK, rigorously, suceess or faliure of the requested free pages
> allocation depends on actual memory layout at the 2nd kernel boot. To
> increase the possibility of allocating memory, we have no method but
> reserve more memory for the 2nd kernel now.
Good enough. If
Tejun Heo writes:
> Hello,
So my first response after looking at the ipc patch is ick.
Why the deep percpu magic?
Why don't associate idr_preload with an idr structure.
When reading code with idr_preload I get this deep down creepy feeling.
What is this magic that is going on?
Can't we just p
Tejun Heo writes:
> Hey, Eric.
>
> On Sun, Feb 3, 2013 at 5:41 AM, Eric W. Biederman
> wrote:
>> Why the deep percpu magic?
>
> Eh? What's magical about it? You preload percpu buffer if you're
> gonna be allocating an id from context which doesn't a
Sedat Dilek writes:
> On Thu, Feb 7, 2013 at 11:20 AM, Sedat Dilek wrote:
>> On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek wrote:
>>> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell
>>> wrote:
Hi all,
Changes since 20130206:
Removed tree: kvmtool (still present via th
Andrew Morton writes:
> On Sun, 03 Feb 2013 21:13:36 +0800
> Zhang Yanfei wrote:
>
>> From: Zhang Yanfei
>>
>> In function read_vmcore, two if tests are duplicate. Change the position
>> of them could reduce the duplication. This change does not affect
>> the behaviour of the function.
> Whil
me code with is forgetting to
>> > reenable interrupts on a rarely-tested error path, and that ENOMEM is
>> > tickling the bug.
>>
>> Right, agreed. As I said, I think that is mostly a secondary issue.
>> Hopefully it will be easy to fix once we figure out why
> > reenable interrupts on a rarely-tested error path, and that ENOMEM is
>> > > tickling the bug.
>> >
>> > Right, agreed. As I said, I think that is mostly a secondary issue.
>> > Hopefully it will be easy to fix once we figure out why we're g
Josh Boyer writes:
> < Two emails fly past each other in the night >
Yep.
>> My best guess in some dark corner of mock has untested code to unshare a
>> pid namespace, and that corner started doing something now that
>> unsharing of the pid namespace actually works.
>>
>> If mock has called un
Josh Boyer writes:
>> So it looks mock is taking a buggy untested code path and things are not
>> working as it expected.
>
> Quite possibly, yes. I instrumented the kernel a bit and it is indeed
> failing in the alloc_pid call.
>
> Clark, thoughts here?
I will just add the solution is probably
Clark Williams writes:
> The more I look at that the more I think I should nuke CLONE_NEWPID in
> mock. It came in with a commit that added NEWIPC, which I think is valid
> for mock managing a chroot, but we're not looking to do full-up
> containers at this point and it looks like containers is t
Andrew Morton writes:
> On Fri, 08 Feb 2013 12:13:09 -0800
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>> If mock has called unshare(CLONE_NEWPID). And then forked a process and
>> that process exited, and then forked anothe process that second and all
>> subs
Mitsuhiro Tanino writes:
> Re: [Patch 0/2] Exclude hwpoison page from vmcore dump
> (2012/11/01 19:40), Eric W. Biederman wrote:
>> Mitsuhiro Tanino writes:
>> I agree. If we are performing filtering filtering out of poisoned pages
>> seems very reasonable. So
efs_off_t is always a u64.
Nacked-by: "Eric W. Biederman"
> smatch analysis:
>
> fs/befs/linuxvfs.c:851 befs_fill_super() warn: impossible
> condition '(befs_sb->num_blocks > ~(0)) => (0-u64max > u64max)'
>
> Cc: Al Viro
> Cc: Andrew Morton
>
Sven Joachim writes:
> On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:
>
>> 3.8-stable review patch. If anyone has any objections, please let me know.
>
> I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
> 3.9-rc5: "udevd[56]: sender uid=65534, message ignored". Rever
t needs both a new version from me and a review
>>> by someone) here:
>>>
>>> http://www.spinics.net/lists/netdev/msg229948.html
>>
>> Hmm... this is not a stable candidate, IMHO.
>
> Agreed.
>
>>
>> This has to be fixed (if n
Eric Dumazet writes:
> On Wed, 2013-04-03 at 17:05 -0700, Eric W. Biederman wrote:
>> Sven Joachim writes:
>>
>> > On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:
>> >
>> >> 3.8-stable review patch. If anyone has any objections, please let
Eric Dumazet writes:
> On Wed, 2013-04-03 at 17:19 -0700, Eric Dumazet wrote:
>
>> Well, yes, this commit fixes a real bug : We were coalescing two
>> messages into a single one, even if the senders were different.
>
> By the way, the 'LSB' test program can be found here :
>
> https://lsbbugs.lin
sockets that wish to send credentails
to other sockets.
In practice this break some versions of udev because they receive a
message and the sending uid is bogus so they drop the message.
Cc: sta...@vger.kernel.org
Reported-by: Sven Joachim
Signed-off-by: "Eric W. Biederman"
---
Karel Srot
Reported-by: Ding Tianhong
Signed-off-by: "Eric W. Biederman"
---
net/unix/af_unix.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f153a8d..2db702d 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix
Andy Lutomirski writes:
> On Wed, Apr 3, 2013 at 5:47 PM, Eric W. Biederman
> wrote:
>>
>> No. The patch is still bogus.
>>
>> If the problem is that we are not coallescing messages in stream_recvmsg
>> we need a different fix.
>>
>> Pro
e the cost of cache line misses
justifies retaining code for a future potential application.
Signed-off-by: "Eric W. Biederman"
---
Included in this patchset because there are trivial dependencies,
and since we are sort of arguing about this anyway. This definitely is
not for stable
dingtianhong writes:
> On 2013/4/4 10:13, Eric W. Biederman wrote:
>>
>> This reverts commit 14134f6584212d585b310ce95428014b653dfaf6.
>>
>> The problem that the above patch was meant to address is that af_unix
>> messages are not being coallesced b
dingtianhong writes:
> On 2013/4/4 10:14, Eric W. Biederman wrote:
>>
>> It was reported that the following LSB test case failed
>> https://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we
>> were not coallescing unix stream messages when the applica
Zhang Yanfei writes:
> hole_end has been checked to make sure it is <= crash_res.end in the
> while condition check, so the if condition check is duplicate.
That test is definitely a duplicate.
Reviewed-by: "Eric W. Biederman"
> Signed-off-by: Zhang Yanfei
> ---
I will look at this patch in a bit. I already have a similar patch
in my queue, although I don't know if I have pushed that out yet.
Andrew Morton writes:
> btw, what the heck is up with CONFIG_UIDGID_CONVERTED? That thing
> prevents userns from being compiled in an allmodconfig build, which
For anyone who cares about resource control setting up the memory
control group in combination with user namespaces is strongly
recommended.
User namespaces are a particular problem when it comes to resource
control. Not all of the resources you can create with a user namespace
currently have or
+-
kernel/user_namespace.c | 62 +++--
mm/shmem.c|2 +
8 files changed, 92 insertions(+), 22 deletions(-)
Eric W. Biederman (6):
userns: Avoid recursion in put_user_ns
userns: Allow any uid or gid mappings
ested user namespaces after this change my test program runs to
completion and causes no harm.
Pointed-out-by: Vasily Kulikov
Signed-off-by: "Eric W. Biederman"
---
include/linux/user_namespace.h | 10 +-
kernel/user.c |4 +---
kernel/user_names
complained. So use a simple check to ensure that ranges
in the mapping extents don't overlap.
Signed-off-by: "Eric W. Biederman"
---
kernel/user_namespace.c | 45 +++--
1 files changed, 39 insertions(+), 6 deletions(-)
diff
In the help text describing user namespaces recommend use of memory
control groups. In many cases memory control groups are the only
mechanism there is to limit how much memory a user who can create
user namespaces can use.
Signed-off-by: "Eric W. Biederman"
---
Documentation/
namespace will
not allow the options of an existing mount of devpts to be modified.
- Create /dev/pts/ptmx as the root user in the user namespace that
mounts devpts so that it's permissions to be changed.
Signed-off-by: "Eric W. Biederman"
---
fs/devpts/inode.c | 18
root using ramfs to exhaust memory
the memory control group can be deployed.
Signed-off-by: "Eric W. Biederman"
---
fs/ramfs/inode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index eab8c09..c24f1e1 100644
--- a/fs/ram
control group successfully limits how much memory tmpfs can
consume on any system that cares about a user namespace root using
tmpfs to exhaust memory the memory control group can be deployed.
Signed-off-by: "Eric W. Biederman"
---
mm/shmem.c |2 ++
1 files changed, 2 insertions(+), 0
Aristeu Rozanski writes:
> On Thu, Jan 24, 2013 at 04:46:12PM -0800, Andrew Morton wrote:
>> eek, a macro! Macros are always bad.
>>
>> This one is bad because
>>
>> a) it's a macro
>>
>> b) it evaluates its args multiple times and hence will cause nasty
>>bugs if called with expressions-
"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>>
>> There is no backing store to ramfs and file creation
>> rules are the same as for any other filesystem so
>> it is semantically safe to allow unprivileged users
>> t
"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>>
>> In the help text describing user namespaces recommend use of memory
>> control groups. In many cases memory control groups are the only
>> mechanism there is to limit
Gao feng writes:
> This patch allow the unprivileged user to mount mqueuefs in
> user ns.
>
> If two userns share the same ipcns,the files in mqueue fs
> should be seen in both these two userns.
>
> If the userns has its own ipcns,it has its own mqueue fs too.
> ipcns has already done this job we
Gao feng writes:
> On 2013/01/28 11:43, Eric W. Biederman wrote:
>> Gao feng writes:
>>
>>> This patch allow the unprivileged user to mount mqueuefs in
>>> user ns.
>>>
>>> If two userns share the same ipcns,the files in mqueue fs
>>
Lord Glauber Costa of Sealand writes:
> On 01/26/2013 06:22 AM, Eric W. Biederman wrote:
>>
>> In the help text describing user namespaces recommend use of memory
>> control groups. In many cases memory control groups are the only
>> mechanism there is to limit how
Lord Glauber Costa of Sealand writes:
> I just saw in a later patch of yours that your concern here seems not
> limited to backed ram by tmpfs, but with things like the internal
> structures for userns , to avoid patterns in the form: 'for (;;)
> unshare(...)'
>
> Humm, it does seem sensible. The
Lord Glauber Costa of Sealand writes:
> On 01/28/2013 12:14 PM, Eric W. Biederman wrote:
>> Lord Glauber Costa of Sealand writes:
>>
>>> I just saw in a later patch of yours that your concern here seems not
>>> limited to backed ram by tmpfs, but with things
Vasily Kulikov writes:
> Acked-by: Vasily Kulikov
>
> The second bug I've noted in the same email (OOM) looks like should be
> "fixed" by using memcg to limit kernel memory. So, I'm fine with this
> side of user_ns :)
Good. That is what it looked like from here.
You pointed out one or two ot
Lord Glauber Costa of Sealand writes:
>> For two pieces of software that were designed to complement each other
>> I find it a bit surprising how many people (including myself) need the
>> connection made that memory control groups and user namespaces should go
>> together.
>
> Well, I've manifes
Vivek Goyal writes:
> On Tue, Feb 26, 2013 at 10:30:45AM -0500, Vivek Goyal wrote:
>> On Tue, Feb 26, 2013 at 04:57:47AM +, Matthew Garrett wrote:
>>
>> [..]
>> > > - encourage things like per-host random keys - with the stupid UEFI
>> > > checks disabled entirely if required. They are almo
Serge Hallyn writes:
> Quoting Raphael S.Carvalho (raphael.sc...@gmail.com):
>> It seems GCC generates a better code in that way, so I changed that
>> statement.
>> Btw, they have the same semantic, so I'm sending this patch due to
>> performance issues.
>>
>> Signed-off-by: Raphael S.Carvalho
"Michael Kerrisk (man-pages)" writes:
> Eric et al,
>
> Eventually, there will be more namespace man pages, but let us start
> now with one for PID namespaces. The attached page aims to provide a
> fairly complete overview of PID namespaces.
>
> Eric, various pieces of the page are shifted out of
new->user_ns
is NULL (as is every other field in new except session_keyring at that
point).
It looks like it is safe to sleep in key_change_session_keyring so why
we just don't use prepare_creds there like everywhere else is beyond
me.
The intent is clearly to copy all of the fields from
Sasha Levin writes:
> On 02/17/2013 07:17 PM, ebied...@xmission.com wrote:
>> The bad pointer value is 0xfff0. Hmm.
>>
>> If you have the failure location correct it looks like a corrupted hash
>> entry was found while following the hash chain.
>>
>> It looks like the memory has be
Li Fei writes:
> There is well known issue that freezing will fail in case that fuse
> daemon is frozen firstly with some requests not handled, as the fuse
> usage task is waiting for the response from fuse daemon and can't be
> frozen. To solve the issue as above, make fuse daemon frozen after
>
Alan Stern writes:
> On Wed, 20 Feb 2013, Eric W. Biederman wrote:
>
>> Why can't the fuse filesystem freeze when there are requests pending?
>
> It _can_ freeze (that is, the fuse daemon can). The problem is that
> tasks _using_ the fuse filsystem can't if the
"Raphael S.Carvalho" writes:
> Just sending this patch in order to simplify the code.
> However, I'm not sure if the code was written in that way due to
> specific reasons.
That doesn't look any simpler to me, and I expect you have now biased
the branch in the wrong direction.
The CLONE_THREAD
Alan Stern writes:
> On Wed, 20 Feb 2013, Eric W. Biederman wrote:
>
>> >> Why can't the fuse filesystem freeze when there are requests pending?
>> >
>> > It _can_ freeze (that is, the fuse daemon can). The problem is that
>> > tasks _usi
allmodconfig but it looks like the xfs changes need
another couple of days before it they are ready.
Eric W. Biederman (91):
userns: Avoid recursion in put_user_ns
userns: Allow any uid or gid mappings that don't overlap.
userns: Recommend use of memory control groups.
u
> members which point to uninitialized memory.
Agreed.
I don't think that failure path has ever actually been exercised.
The code is wrong, and it is worth fixing.
Andrew I do you think you could queue this up? I don't have a handy tree.
Reviewed-by: "Eric W. Biederman"
Jingbai Ma writes:
> On 03/11/2013 05:42 PM, Eric W. Biederman wrote:
>> The kernel is known bad. What is bad is unclear.
>> Executing any extra code is a bad idea.
>>
>> The history here is that before kexec-on-panic there were lots of dump
>> routines that
you are working with the community instead of trying asking the rest of
us to support something you won't share.
Nacked-by: "Eric W. Biederman"
> --- linux.orig/kernel/signal.c
> +++ linux/kernel/signal.c
> @@ -1419,7 +1419,7 @@ out_unlock:
> rcu_read_unlock()
"Michael Kerrisk (man-pages)" writes:
> Eric et al.,
>
> [CCing Li because of reboot(2) changes]
>
> I have (I think) addressed all previous comments in the current draft
> of the pid_namespaces(7) page. This is a final sanity check before I
> call this page complete (modulo any future kernel cha
Mike Travis writes:
> Let me see if I can understand the concept better. By denying
> an external hardware vendor the use of KDB to support a significant
> piece of proprietary hardware on Linux, I furthering the interests
> of Linux and the community how?
By ignoring interests of someone who d
Larry Baker writes:
> Greg,
>
> Will there also be a 2.6-stable patch (Eric's first submission)? My CentOS
> 6.3
> systems still use 2.6 kernels.
Larry what is in CentOS is for the CentOS maintainers to determine.
Last I checked they followed RHEL and RHEL seems to have so little
interest in d
Joonsoo Kim writes:
> From: Joonsoo Kim
>
> Although our intention is to unexport internal structure entirely,
> but there is one exception for kexec. kexec dumps address of vmlist
> and makedumpfile uses this information.
>
> We are about to remove vmlist, then another way to retrieve informati
e these trivial fixes.
Eric W. Biederman (2):
fs: Limit sys_mount to only request filesystem modules. (Part 3)
fs: Readd the fs module aliases.
fs/cifs/cifsfs.c |1 +
fs/ext4/super.c |2 ++
fs/freevxfs/vxfs_super.c |1 +
fs/hostfs/hostfs_kern.c |1 +
Kees Cook writes:
> Hi,
>
> It seem like we should block (at least) this combination. On 3.9, this
> exploit works once uidmapping is added.
>
> http://www.openwall.com/lists/oss-security/2013/03/13/10
Yes. That is a bad combination. It let's chroot confuse privileged
processes.
Now to figure
Sedat Dilek writes:
> On Wed, Mar 13, 2013 at 7:37 PM, Felix Fietkau wrote:
>> On 2013-03-13 7:12 PM, Robin Holt wrote:
>>> On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi wrote:
> On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dile
Larry Baker writes:
> I gather then that the long term kernels shown at https://www.kernel.org/
> might eventually get updated if Willy Tarreau and Paul Gortmaker subscribe to
> the sta...@vger.kernel.org list and decide to apply Eric's patches to the
> mainline stable 2.6 kernels. Otherwise
Andy Lutomirski writes:
> On 03/13/2013 11:35 AM, Eric W. Biederman wrote:
>> Kees Cook writes:
>>
>>> Hi,
>>>
>>> It seem like we should block (at least) this combination. On 3.9, this
>>> exploit works once uidmapping is added.
>>>
-by: Eric W. Biederman
---
fs/ext3/super.c |2 +-
fs/ext4/super.c |2 +-
fs/gfs2/quota.c | 52 +--
fs/ocfs2/file.c |6 +-
fs/ocfs2/quota_global.c | 43 +++-
fs/ocfs2/quota_local.c | 15 +++--
fs/quota/dquot.c
1 - 100 of 5726 matches
Mail list logo
