Hello.
I found that
$ cat /proc/slab_allocators
causes an oops.
-- dmesg start --
[ 22.719620] BUG: unable to handle kernel paging request at 8800389b7ff8
[ 22.719742] IP: [] handle_slab+0x8d/0x1a0
[ 22.719742] PGD 2d64067 PUD 2d65067 PMD 3fc20067 PTE 8000389b706
Fleming, Matt wrote:
> On 7 April 2014 21:42, Andi Kleen wrote:
> >
> > This sounds like the UEFI boot corrupts some memory?
>
> Hmpf, yeah. I'll take a look in the morning.
>
> Thomas, you mention you're running in a 32-bit vm earlier in this
> thread. Any chance you're using ovmf because that
Thomas B臘hler wrote:
> >> For convenience, here is a copy-and-paste of the full text:
> >
> > I did some experiments know and I can't find any 32bit modules
> > that do not load with 32bit MODVERSIONS on or off with
> > a current tree.
> >
> > Do you have a specific config?
> > Specific compile
Struan Bartlett wrote:
> Adds tty driver to netconsole module. When module is loaded,
> creates /dev/netcon0 device and enables support for console=netcon0
> kernel cmdline option, causing /dev/console output to be sent to
> /dev/netcon0. This allows startup/shutdown script output from
> headless p
Thomas Gleixner wrote:
> But then systemd/udev mutters:
>
>"You migh be able to work around the timeout with udev rules and
> OPTIONS+="event_timeout=120", but that code was maybe never used
> or tested, so it might not work correctly." [1]
>
> AFAICT from the ubuntu bug system [2] no
Oleg Nesterov wrote:
> On 03/22, Tetsuo Handa wrote:
> >
> > Oleg Nesterov wrote:
> > > Tetsuo, what do you think?
> >
> > I don't like blocking SIGKILL while doing operations that depend on memory
> > allocation by other processes. If the OOM k
ommit 786235ee sounds like a kernel API breakage.
--
>From 731f1f6dec7efaa132f751c432079b9b1fdb78d2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 22 Mar 2014 15:16:50 +0900
Subject: [PATCH] kthread: Handle SIGKILL gracefully in kthread_create().
Commit 786235ee "kth
Oleg Nesterov wrote:
> > > If we need the urgent hack to fix the regression, then I suggest to change
> > > scsi_host_alloc() temporary until mptsas (or whatever) is fixed.
> >
> > Device initialization taking longer than 30 seconds is possible and is not a
> > hang up. It is systemd which needs to
Oleg Nesterov wrote:
> If we need the urgent hack to fix the regression, then I suggest to change
> scsi_host_alloc() temporary until mptsas (or whatever) is fixed.
Device initialization taking longer than 30 seconds is possible and is not a
hang up. It is systemd which needs to be fixed.
> --- x
Andrew Morton wrote:
> What process is running here? Presumably modprobe.
Yes. It is a worker systemd-udevd process who is acting like modprobe .
> A possible explanation is that modprobe has genuinely received a
> SIGKILL. Can you identify anything in this setup which might send a
> SIGKILL to
Oleg Nesterov wrote:
> > @@ -292,6 +292,17 @@ struct task_struct *kthread_create_on_node(int
> > (*threadfn)(void *data),
> > * new kernel thread.
> > */
> > if (unlikely(wait_for_completion_killable(&done))) {
> > + int i = 0;
> > +
> > + /*
> > +* I
ccfaab53 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 16 Mar 2014 22:44:23 +0900
Subject: [PATCH] kthread: Do not leave kthread_create() immediately upon
SIGKILL.
Commit 786235ee "kthread: make kthread_create() killable" changed to
leave kthread_create() as soon as receiving
Joseph Salisbury wrote:
> A kernel bug report was opened against Ubuntu[0]. We performed a kernel
> bisect, and found that reverting the following commit resolved this bug:
I added a comment to that bug report.
This commit by chance revealed incorrect error handling of mptsas_probe() or
mptscsih
using do_get_task_comm() proposed in this thread.
--
>From 1fe3dcd8792bc1296e337daba661200a8feaf706 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 11 Mar 2014 21:09:48 +0900
Subject: [PATCH] LSM: Pass comm name via get_task_comm()
When we pass task->comm to audit_log_untrustedstring
audit_log_task() and you prefer locked version, please pick up below patch
via your git tree.
If you are unsure or prefer lockless version, I'll make a lockless version
using do_get_task_comm() proposed in this thread.
--
>From 88c3ff13efa10df6f4d4d0f2c243124ce6a3eaeb Mon Sep 17
Richard Guy Briggs wrote:
> > > > Likewise, audit_log_untrustedstring(ab, current->comm) is racy.
> > > > If task->comm was "Hello Linux" until audit_string_contains_control()
> > > > in
> > > > audit_log_n_untrustedstring() returns false, and becomes "Penguin"
> > > > before
> > > > memc
gt; sprintf(buf, "%s", task->comm);
> >
> > .
>
> How about you do what you're supposed to do when you want a reliable
> ->comm and use get_task_comm()?
>
I always want a reliable ->comm . But get_task_comm() is not for calling from
vsnprintf
Thank you for reviewing, Paul.
Paul E. McKenney wrote:
> > +/**
> > + * set_task_comm - Change task_struct->comm with tracer and perf hooks
> > called.
> > + *
> > + * @tsk: Pointer to "struct task_struct".
> > + * @buf: New comm name.
> > + *
> > + * Returns nothing.
> > + */
> > +void set_task_
Lai Jiangshan wrote:
> CC scheduler people.
>
> I can't figure out what we get with this patch.
>
OK. Welcome to this thread. I'll explain you what is going on.
Current problem:
printk("%s\n", task->comm) is racy because "%s" format specifier assumes that
the corresponding argument does not
Joe Perches wrote:
> Convert printks to pr_
> Add pr_fmt to prefix output with "tomoyo: "
> Coalesce formats.
>
> Signed-off-by: Joe Perches
Acked-by: Tetsuo Handa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Tetsuo Handa wrote:
> This is a draft patch which changes task_struct->comm to use RCU.
Changes from previous draft version:
Changed "struct rcu_comm" to use copy-on-write approach. Those multi-thread
or multi-process applications which do not change comm name will consume
Johannes Weiner wrote:
> Thanks for the report. There is already a fix for this in -mm:
> http://marc.info/?l=linux-mm-commits&m=139180637114625&w=2
>
> It was merged on the 7th, so it should show up in -next... any day
> now?
That patch solved this bproblem but breaks build instead.
ERROR: \
Hello.
I got a lockdep warning shown below, and the bad commit seems to be de055616
\"mm: keep page cache radix tree nodes in check\" as of next-20140212
on linux-next.git.
Regards.
=
[ INFO: possible irq lock inversion dependency detected
Hello.
Tetsuo Handa wrote:
> I think there is some point in applying the preparatory patches (commcpy() and
> %pT patches) now, for they fix time-to-call-strlen()-to-time-to-call-memcpy()
> problem by making sure that the comm string passed to strlen() etc. is also
> passed to memc
Thomas B臘hler wrote:
> This looks exactly like the problem experienced by Tetsuo Handa in [1].
> However, for me, his solution, i.e. setting
> CONFIG_PHYSICAL_ALIGN=0x100
> instead of
> CONFIG_PHYSICAL_ALIGN=0x10
> doesn't help and the symptoms stay the same
ll overwrite this
change in order to avoid re-calculation of pathnames.
LSM users, please review your relevant part in the following changes.
>From 15850773c7b6336f1d884c2daa314f4c408d355e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 18
James, would you pick up this patch?
Tetsuo Handa wrote:
> James, please apply.
>
> Kevin, does "cause OOM" mean something like the OOM killer or kmalloc()
> failure
> is triggerred by frequent prctl() requests by userspace applications?
> If yes, we should backpo
Rusty, would you pick up this patch?
This message was added in 3.13-rc1. Thus, should be fixed in 3.13.
Tetsuo Handa wrote:
> From cc90e27d5cda227e7a0cbeb5de3cc1cbb1595dfa Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 23 Dec 2013 15:52:42 +0900
> Subject: [PATCH]
Miklos Szeredi wrote:
> +
> + if (flags)
> + return -EOPNOTSUPP;
> +
If (at least for now) only ext4 interprets renameat2() flags,
I think adding a new member to "struct inode_operations" and
check it like
if (!old_dir->i_op->swapname)
return -EOPNOTSUPP;
John Johansen wrote:
> On 01/14/2014 05:03 AM, Tetsuo Handa wrote:
> > Miklos Szeredi wrote:
> >> On Mon, Jan 13, 2014 at 11:03 PM, Tetsuo Handa
> >> wrote:
> >>> Miklos Szeredi wrote:
> >>>> Cross rename (A, B) is equivalent to plain rena
Miklos Szeredi wrote:
> On Mon, Jan 13, 2014 at 11:03 PM, Tetsuo Handa
> wrote:
> > Miklos Szeredi wrote:
> >> Cross rename (A, B) is equivalent to plain rename(A, B) + plain rename
> >> (B, A) done as a single atomic operation. If security module allows
> >
Miklos Szeredi wrote:
> Cross rename (A, B) is equivalent to plain rename(A, B) + plain rename
> (B, A) done as a single atomic operation. If security module allows
> both then cross rename is allowed. If at least one is denied then the
> cross rename is denied.
Yes, the functionality itself is
Miklos Szeredi wrote:
> Please consider for -next (3.14).
Excuse me, but did you explain to CONFIG_SECURITY_PATH=y users?
I don't see changes in TOMOYO and AppArmor directories.
TOMOYO might want to use new keyword like "file swapname"
rather than using "file rename" for cross rename operation.
--
Geert Uytterhoeven wrote:
> On Sat, Jan 11, 2014 at 12:59 AM, Andrew Morton
> wrote:
> >> +char *comm_name(char *buf, char *end, struct task_struct *tsk,
> >> + struct printf_spec spec, const char *fmt)
> >> +{
> >> + char name[TASK_COMM_LEN];
> >> +
> >> + /* Caller can pass N
Andrew Morton wrote:
> In the absence of step 3, steps 1 and 2 are rather pointless churn.
>
> So I think it would be better to merge (into mainline) steps 1 and 3
> first and at the same time. Then start thinking about step 2.
Unfortunately we can't.
Step 2 depends on step 1 for avoiding compil
Joe Perches wrote:
> On Sat, 2014-01-11 at 10:59 +0900, Tetsuo Handa wrote:
> > I just added noinline_for_stack as with other functions does.
> > But indeed, stack used by name[] is only 16 bytes but stack used by function
> > arguments are larger than 16 bytes. We should remo
Andrew Morton wrote:
> > This patch introduces %pT format specifier for printing task_struct->comm.
> > Currently %pT does not provide consistency. I'm planning to change to use
> > RCU
> > in the future. By using RCU, the comm name read from task_struct->comm will
> > be
> > guaranteed to be con
Joe Perches wrote:
> On Sat, 2014-01-11 at 10:28 +0900, Tetsuo Handa wrote:
> > Step 1: (targeted to 3.14-rc1)
> > Add "%pT" format specifier and commcpy() wrapper function.
> >
> > Step 2: (started after step 1 is reflected to other git trees)
>
Andrew Morton wrote:
> On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa
> wrote:
>
> > This patch introduces %pT format specifier for printing task_struct->comm.
> > Currently %pT does not provide consistency. I'm planning to change to use
> > RCU
> > i
Tetsuo Handa wrote:
> Pavel Machek wrote:
> > > + * Please use this wrapper function which will be updated in the future
> > > to read
> > > + * @tsk->comm in a consistent way.
> > > + */
> > > +static inline int commcmp(con
>From 8c8032d179af2aa3841c37d72c18002cd0ba7448 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 9 Jan 2014 21:57:53 +0900
Subject: [PATCH] init: Fix possible format string bug.
Use constant format string in case message changes.
Signed-off-by: Tetsuo Handa
---
init/initramfs.c |
t;From 0d1f03d59a477459f3d3c190593d9e78f5d67de8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 9 Jan 2014 21:32:22 +0900
Subject: [PATCH] lib/vsprintf: add %pT format specifier
Since task_struct->comm can be modified by other threads while the current
thread is reading it, it is recommended to use get_
Pavel Machek wrote:
> > > > I'm not nacking this, just stating my view.
> > >
> > > And I believe Andrew clearly stated his view, on the very topic you
> > > asked him on.
> >
> > I believe Andrew's view:
> >
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 1
Joe Perches wrote:
> On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > Is this really necessary?
> > No problem. %pT[012] are simply optimization (reducing number of function
> > arguments for saving text size) and therefore I can d
Joe Perches wrote:
> On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> > > Since my purpose is to make reading of task_struct->comm consistent,
> > > %pT-like
> > > extension is what I want for centralizing pointer dereferences.
> >
> > If we h
Pavel Machek wrote:
> > + * Please use this wrapper function which will be updated in the future to
> > read
> > + * @tsk->comm in a consistent way.
> > + */
> > +static inline int commcmp(const struct task_struct *tsk, const char *comm)
> > +{
> > + return strcmp(tsk->comm, comm);
> > +}
>
> I
Tetsuo Handa wrote:
> Since my purpose is to make reading of task_struct->comm consistent, %pT-like
> extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch, I'd like to propose a counterpart
patch for users reading/copying tas
Chris Wilson wrote:
> > Then, this file->pid in &dev->filelist keeps at least one reference.
> > OK. Updated patch follows.
>
> Looks good to me, and the comment is great.
> -Chris
Please pick up this patch via your git tree.
Also, please change from "" to whatever you like. For example,
dump_ho
I found an unapplied patch from https://lkml.org/lkml/2013/9/19/17 .
--
>From 38f01b48ae371058845274f4d7def4d81dbac4ea Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 4 Jan 2014 16:26:00 +0900
Subject: [PATCH] slub: Fix possible format string bug.
The "name" is
I'm planning to convert task_struct->comm to use RCU so that they always get
consistent result. Inconsistent result (e.g. trailing '\0' byte is emitted when
printing string argument) is caused by breaking a rule that the string argument
must not change during the function when it is passed as "cons
Chris Wilson wrote:
> On Tue, Dec 24, 2013 at 08:50:23PM +0900, Tetsuo Handa wrote:
> > >From 482be6384379072eb4c0d45d0ab8a25df4f59ed7 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Tue, 24 Dec 2013 18:04:14 +0900
> > Subject: [PATCH] drm/i915: Fix r
> > the
> > target task's comm name.
> >
> > Signed-off-by: Tetsuo Handa
> > ---
>
> Well this is not entirely true... for 99.9% of calls to this function we
> do have the rcu read lock held (when called from the seq file code). So
> the only i
Joe Perches wrote:
> On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > > > previous choice (i.e. reserve '\x7F' to '\xFF')
27;s better.
>
> Is there a particularly utility/reason to use 0xff
> vs ascii SUB/PU1/PU2?
>
Nothing. Is 0x1A preferable to 0xFF?
--
>From ebace41254ea02250c01c56a9e3ee08a34957830 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 1 Jan 2014 18:15:34 +0900
Subject: [PA
Joe Perches wrote:
> > Please describe your format and rules (e.g. what byte starts a built-in
> > token;
> > what bytes are used for representing variable name, what separates flags,
> > field
> > width and precision options from variable name if these options are
> > specified,
> > what byte t
Joe Perches wrote:
> I get:
>
> $ grep-2.5.4 -rP --include=*.[ch] -oh \
>
> "\b(?:printk|[a-z_]+_(?:printk|emerg|alert|crit|err|warn|notice|info|debug|dbg))[^;]*\bcurrent->[\w_]+"
> * | \
> grep -P -oh "\bcurrent->[\w_]+"| sort | uniq -c | sort -rn
> 380 current->pid
> 267 current->c
Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > >
> > > > > > #define PRINTK_PID "\002"
&
Joe Perches wrote:
> On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> >
> > > > > #define PRINTK_PID "\002"
> > > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
>
> > > > >
> > > > > printk(PRINTK_TASK_ID ": ha
Andrew Morton wrote:
> which is painful, so we also provide the new vsprintf token as a
> convenience:
>
> pr_warn("%|: hair on fire\n");
>
> but I don't know what we can use in place of %|.
We are using %pEXTENSION where EXTENSION is [A-Za-z0-9]* because compiler does
not need to understa
Hello.
Chris Wilson wrote:
> > Since get_pid_task() grabs a reference on the task_struct, we have to drop
> > the
> > refcount after reading that task\'s comm name. Also, directly reading like
> > get_pid_task()->comm can trigger an oops when get_pid_task() returned NULL.
>
> The second issue is
>From 545dae06c6690a0c937e082ed984f828a2ea7aa2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Dec 2013 18:16:17 +0900
Subject: [PATCH] lib/vsprintf: add %pT[C012] format specifier
Since task_struct->comm can be modified by other threads while the current
thread is reading it,
>From efee681e4ca6152d9549a50e93ca932b00f03014 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 24 Dec 2013 18:04:43 +0900
Subject: [PATCH] GFS2: Fix unsafe dereference in dump_holder()
Since we are not in RCU nor tasklist_lock held, we need to grab a reference on
the returned task_str
>From 482be6384379072eb4c0d45d0ab8a25df4f59ed7 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 24 Dec 2013 18:04:14 +0900
Subject: [PATCH] drm/i915: Fix refcount leak and possible NULL pointer
dereference.
Since get_pid_task() grabs a reference on the task_struct, we have to drop
>From cc90e27d5cda227e7a0cbeb5de3cc1cbb1595dfa Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 23 Dec 2013 15:52:42 +0900
Subject: [PATCH] module: Add missing newline in printk call.
Add missing \n and also follow commit bddb12b3 "kernel/module.c: use pr_foo()".
Signed-o
Mimi Zohar wrote:
> @@ -132,24 +133,22 @@ static inline int integrity_digsig_verify(const
> unsigned int id,
> return -EOPNOTSUPP;
> }
>
> +static int integrity_init_keyring(const unsigned int id)
Please add inline keyword, or compiler makes noisy warning.
> +{
> + return 0;
> +}
>
Jim Lieb wrote:
> On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> > Jim Lieb wrote:
> > > Subsequent uses look like:
> > > use_creds(cached fd);
> > >
> > > followed by
> > >
> > > open/creat/mknod/write
> >
Jim Lieb wrote:
> Subsequent uses look like:
>
> use_creds(cached fd);
> followed by
> open/creat/mknod/write
> followed by
> use_creds(-1);
Are you aware that calling commit_creds() is prohibitted between
override_creds() and revert_creds() ?
If the caller does some operation
UTEXES=y.
Fix it by explicitly passing a bool which tells whether p != NULL
or not.
[ PeterZ: This is a sad patch, but provided it actually generates
similar code I suppose its the best we can do bar whole
sale deprecating gcc-3. ]
Signed-off-by: Tetsuo Handa
Acked-by: Pete
>From bbba584a502b9417af06e4a55401c013a7e90eb1 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 30 Oct 2013 16:12:58 +0900
Subject: [PATCH linux-next-20131029] IB/ipath: Fix random stack overflow.
Commit 18fec3c6 "IB/ipath: Convert ipath_user_sdma_pin_pages() to use
get_user_pa
Tetsuo Handa wrote:
> I would send another one which uses only security_file_alloc/free .
I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and
waiting for your response. How long are we expected to remain vulnerable due to
lack of multiple concurrent LSM s
t; from
the sender side. Be sure to update the iptables rules as needed. ;-)
Source code: (Total 409 lines)
-- udplogger.c start --
/*
* Simple UDP logger - A utility for receiving output from netconsole.
*
*Written by Tetsuo Handa
*/
#include
#include
#include
#include
Commit-ID: b0267507dfd0187fb7840a0ec461a510a7f041c5
Gitweb: http://git.kernel.org/tip/b0267507dfd0187fb7840a0ec461a510a7f041c5
Author: Tetsuo Handa
AuthorDate: Thu, 17 Oct 2013 19:45:29 +0900
Committer: Ingo Molnar
CommitDate: Fri, 18 Oct 2013 21:58:54 +0200
mutex: Avoid gcc version
Peter Zijlstra wrote:
> On Thu, Oct 17, 2013 at 12:54:21PM +0200, Maarten Lankhorst wrote:
> > op 17-10-13 12:52, Peter Zijlstra schreef:
> > > On Thu, Oct 17, 2013 at 07:45:29PM +0900, Tetsuo Handa wrote:
> > >> Commit 040a0a37 "mutex: Add suppo
her p != NULL or not.
Signed-off-by: Tetsuo Handa
---
kernel/mutex.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 6d647ae..d24105b 100644
--- a/kernel/mutex.c
+++ b/kernel/mute
Kees Cook wrote:
> So I sent this LSM as one I\'d been waiting
> for stacking on. Essentially, I\'m breaking the catch-22 by sending
> this. I\'d like it to get into the tree so we don\'t have a catch-22
> about stacking any more. :)
I\'m also trying to break the catch-22 by sending KPortReserve.
Kees Cook wrote:
> Any update on this? It'd be nice to have it in linux-next.
What was the conclusion at LSS about multiple concurrent LSM support?
If we agreed to merge multiple concurrent LSM support, there will be nothing to
prevent this module from merging.
--
To unsubscribe from this list: se
-3.
Tetsuo Handa wrote:
> Can the patch below go to 3.12-rcX (and the patch above to 3.11-stable which
> does the same thing)?
>
> Regards.
> --
> >From a1b01c858143c2c2c92b17e7df096042bfe0df6b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 24 Sep
I tried to inspect "struct user_struct"->files , but it seems to me that
the value is always 0... This field is not used?
--
>From e6f9007c5785d5c9817b8fb798542c44d1eefcc5 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 14 Oct 2013 00:19:19 +0900
Subject: [PATC
Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
3.4-stable doesn't need this patch because commit 264b83c07a84
("usermodehelper: check subprocess_info->path != NULL") already fixed it.
--
To unsubscribe from this list: send the line "unsubscr
Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
3.10-stable doesn't need this patch because commit 264b83c07a84
("usermodehelper: check subprocess_info->path != NULL") already fixed it.
--
To unsubscribe from this list: send the line "unsubs
Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
3.0-stable doesn't need this patch because commit 264b83c07a84
("usermodehelper: check subprocess_info->path != NULL") already fixed it.
--
To unsubscribe from this list: send the line "unsubscr
Kees Cook wrote:
> +static int modpin_load_module(struct file *file)
> +{
> + struct dentry *module_root;
> +
> + if (!file) {
> + if (!modpin_enforced) {
> + report_load_module(NULL, "old-api-pinning-ignored");
> + return 0;
> + }
> +
> +
Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 08:56:53PM +0900, Tetsuo Handa wrote:
> > From: Tetsuo Handa
> > Date: Mon, 9 Sep 2013 20:48:13 +0900
> > Subject: [PATCH] mutex: Avoid gcc version dependent __builtin_constant_p()
> > usage.
> >
> > Commit
e+0x55/0x70
[ 601.025088] [] work_notifysig+0x24/0x29
[ 601.026304] [] ? __do_page_fault+0x500/0x500
-- dmesg end --
Below is the patch to fix this problem.
>From 052fedc920b735354b618e23c0b74c7b88ecd3c6 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
David Rientjes wrote:
> On Sat, 28 Sep 2013, Tetsuo Handa wrote:
>
> > Some of enterprise users might prefer "kernel panic followed by kdump and
> > automatic reboot" to "a system is not responding for unpredictable period",
> > for
> > the
.
>From 02b28fd709971f71e5de9a5b595ff4fd059028b3 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 19 Sep 2013 17:23:17 +0900
Subject: [PATCH] seq_file: Introduce seq_setwidth() and seq_pad()
There are several users who want to know bytes written by s
David Rientjes wrote:
> There may not be any eligible processes left and then the machine panics.
Some of enterprise users might prefer "kernel panic followed by kdump and
automatic reboot" to "a system is not responding for unpredictable period", for
the panic helps getting information for anal
ill such users.
kthread_create() is one of such users and this patch fixes the problem for
kthreadd by making kthread_create() killable.
Signed-off-by: Tetsuo Handa
Cc: Oleg Nesterov
Acked-by: David Rientjes
Signed-off-by: Andrew Morton
--
To unsubscribe from this list: send the line
>From 0fe0c9d09b45cce0f00457755861204d51d7c2c9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Sep 2013 00:00:27 +0900
Subject: [PATCH] kthread: make kthread_create() killable
Any users of wait_for_completion() might be chosen by the OOM killer while
waiting for completion() call by
at the user put a bare "|" into
> /proc/sys/kernel/core_pattern. Is ENOENT ("No such file or directory")
> the most appropriate error code here? I think EINVAL ("Invalid
> argument")?
>
I'm fine with EINVAL. Updated patch follows.
--
>F
Hello, Maarten.
Is this patch already queued for 3.12-rcX ?
I expect this patch be committed before sending a patch for 3.11-stable.
Regards.
--
>From a1b01c858143c2c2c92b17e7df096042bfe0df6b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 24 Sep 2013 23:44:17 +0900
Subj
Andrew, would you pick up this patch?
Regards.
--
>From d6ff218545060c5f8b75b15d5b34bffcf625508f Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 16 Sep 2013 02:19:10 +0900
Subject: [PATCH] kmod: Check for NULL at call_usermodehelper_exec().
If /proc/sys/kernel/core_patt
Kees Cook wrote:
> >> - seq_printf(seq, "%*s\n", 127 - len, "");
> >> + seq_pad(seq, '\n');
> >
> > Hmm, seq_pad is unintuitive. I would say it pads the string by '\n'. Of
> > course it does not, but...
>
> I don't think this is a very serious problem. Curre
that this patch is merged, would you confirm that I didn't break
your code with below patch?
Regards.
>From f8b60ebe3971901b93dedb8eee0f85b60d0fdc5f Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 20 Sep 2013 12:01:07 +0900
Subject: [PATCH] Re
on. This patch helps users to simplify
length calculation for alignment. I think this approach is better if adding
a size_t to the seq_file is acceptable.
So, the patch follows.
--------
>From 02b28fd709971f71e5de9a5b595ff4fd059028b3 Mon Sep 17 00:00:00
If the code to test is built into vmlinux, we could use run-time checking like
--
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1601,6 +1601,11 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
if (WARN_ON_ONCE((int) size < 0))
return 0;
+
Kees Cook wrote:
> > -- output start --
> > const : literal
> > not const : const char *
> > not const : const char []
> > const : const char * const
>
> What version of gcc did you use? I don't get the last as const, for
> some reason. And as Dan mentions, shouldn't const char[] b
Kees Cook wrote:
> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now,
> > int __sprintf(int safe, char *buf, const char *fmt, ...)
> > {
> >
Kees Cook wrote:
> On Mon, Sep 16, 2013 at 1:09 AM, Geert Uytterhoeven
> wrote:
> > On Mon, Sep 16, 2013 at 9:43 AM, Kees Cook wrote:
> >> All users of %n are calculating padding size when using seq_file, so
> >> instead use the new last_len member for discovering the length of the
> >> written s
Kees Cook wrote:
> - seq_printf(m, "%s%d%n", con->name, con->index, &len);
> - len = 21 - len;
> + len = m->count;
> + seq_printf(m, "%s%d", con->name, con->index);
> + len = 21 - (m->count - len);
Why not to create a new function which returns bytes written?
The new function d
1801 - 1900 of 2177 matches
Mail list logo
