* [U-Boot] [PATCH v5 05/11] arm, davinci: add support for new spl framework
From: Tom Rini @ 2011-10-31 22:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAF1CA7.5010403@freescale.com>
On Mon, Oct 31, 2011 at 3:09 PM, Scott Wood <scottwood@freescale.com> wrote:
> On 10/30/2011 11:53 PM, Heiko Schocher wrote:
>> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl_nand.c b/arch/arm/cpu/arm926ejs/davinci/spl_nand.c
>> new file mode 100644
>> index 0000000..efc0521
>> --- /dev/null
>> +++ b/arch/arm/cpu/arm926ejs/davinci/spl_nand.c
>> @@ -0,0 +1,57 @@
>> +/*
>> + * Copyright (C) 2011
>> + * Heiko Schocher, DENX Software Engineering, hs at denx.de.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +
>> +#include <common.h>
>> +#include <nand.h>
>> +#include <asm/io.h>
>
> Does this file use anything from asm/io.h?
>
>> +/*
>> + * The main entry for NAND booting. It's necessary that SDRAM is already
>> + * configured and available since this code loads the main U-Boot image
>> + * from NAND into SDRAM and starts it from there.
>> + */
>> +void nand_boot(void)
>> +{
>> + ? ? int ret;
>> + ? ? __attribute__((noreturn)) void (*uboot)(void);
>> +
>> + ? ? /*
>> + ? ? ?* Load U-Boot image from NAND into RAM
>> + ? ? ?*/
>> + ? ? ret = ?nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
>> + ? ? ? ? ? ? ? ? ? ? CONFIG_SYS_NAND_U_BOOT_SIZE,
>> + ? ? ? ? ? ? (void *)CONFIG_SYS_NAND_U_BOOT_DST);
>> +
>> +#ifdef CONFIG_NAND_ENV_DST
>> + ? ? ret = ?nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
>> + ? ? ? ? ? ? (void *)CONFIG_NAND_ENV_DST);
>> +
>> +#ifdef CONFIG_ENV_OFFSET_REDUND
>> + ? ? ret = ?nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, CONFIG_ENV_SIZE,
>> + ? ? ? ? ? ? (void *)CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE);
>> +#endif
>> +#endif
>> +
>> + ? ? /*
>> + ? ? ?* Jump to U-Boot image
>> + ? ? ?*/
>> + ? ? uboot = (void *)CONFIG_SYS_NAND_U_BOOT_START;
>> + ? ? (*uboot)();
>> +}
>
> This is common to most NAND SPLs. ?It would be nice to stick this in a
> common place (at least the loading part, maybe not the jump). ?Not
> nand_spl_simple.c, as it's utility is not limited to the simple driver.
> ?Maybe drivers/mtd/nand/nand_spl_load.c?
Indeed, the difference right here between davinci and omap*(/am335x)
is parsing u-boot.img for the size or just using a hard-coded size
variable.
--
Tom
^ permalink raw reply
* [PATCH UPDATED 14/17] freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE
From: Tejun Heo @ 2011-10-31 22:34 UTC (permalink / raw)
To: rjw, paul, linux-kernel, linux-pm; +Cc: arnd, oleg, matthltc
In-Reply-To: <1320087928-32307-15-git-send-email-tj@kernel.org>
Using TIF_FREEZE for freezing worked when there was only single
freezing condition (the PM one); however, now there is also the
cgroup_freezer and single bit flag is getting clumsy.
thaw_processes() is already testing whether cgroup freezing in in
effect to avoid thawing tasks which were frozen by both PM and cgroup
freezers.
This is racy (nothing prevents race against cgroup freezing) and
fragile. A much simpler way is to test actual freeze conditions from
freezing() - ie. directly test whether PM or cgroup freezing is in
effect.
This patch adds variables to indicate whether and what type of
freezing conditions are in effect and reimplements freezing() such
that it directly tests whether any of the two freezing conditions is
active and the task should freeze. On fast path, freezing() is still
very cheap - it only tests system_freezing_cnt.
This makes the clumsy dancing aroung TIF_FREEZE unnecessary and
freeze/thaw operations more usual - updating state variables for the
new state and nudging target tasks so that they notice the new state
and comply. As long as the nudging happens after state update, it's
race-free.
* This allows use of freezing() in freeze_task(). Replace the open
coded tests with freezing().
* p != current test is added to warning printing conditions in
try_to_freeze_tasks() failure path. This is necessary as freezing()
is now true for the task which initiated freezing too.
-v2: Oleg pointed out that re-freezing FROZEN cgroup could increment
system_freezing_cnt. Fixed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Paul Menage <paul@paulmenage.org> (for the cgroup portions)
---
Later fix patched merged. Please read reply to the head message for
details. Thanks.
include/linux/freezer.h | 33 +++++++++----------------
kernel/cgroup_freezer.c | 10 +++++++-
kernel/fork.c | 1 -
kernel/freezer.c | 62 ++++++++++++++++++++++++++++++----------------
kernel/power/process.c | 15 ++++++++---
5 files changed, 72 insertions(+), 49 deletions(-)
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index 243ec0b..6152e46 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -5,8 +5,13 @@
#include <linux/sched.h>
#include <linux/wait.h>
+#include <linux/atomic.h>
#ifdef CONFIG_FREEZER
+extern atomic_t system_freezing_cnt; /* nr of freezing conds in effect */
+extern bool pm_freezing; /* PM freezing in effect */
+extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
+
/*
* Check if a process has been frozen
*/
@@ -15,28 +20,16 @@ static inline int frozen(struct task_struct *p)
return p->flags & PF_FROZEN;
}
-/*
- * Check if there is a request to freeze a process
- */
-static inline int freezing(struct task_struct *p)
-{
- return test_tsk_thread_flag(p, TIF_FREEZE);
-}
+extern bool freezing_slow_path(struct task_struct *p);
/*
- * Request that a process be frozen
- */
-static inline void set_freeze_flag(struct task_struct *p)
-{
- set_tsk_thread_flag(p, TIF_FREEZE);
-}
-
-/*
- * Sometimes we may need to cancel the previous 'freeze' request
+ * Check if there is a request to freeze a process
*/
-static inline void clear_freeze_flag(struct task_struct *p)
+static inline bool freezing(struct task_struct *p)
{
- clear_tsk_thread_flag(p, TIF_FREEZE);
+ if (likely(!atomic_read(&system_freezing_cnt)))
+ return false;
+ return freezing_slow_path(p);
}
static inline bool should_send_signal(struct task_struct *p)
@@ -179,9 +172,7 @@ static inline void set_freezable_with_signal(void)
})
#else /* !CONFIG_FREEZER */
static inline int frozen(struct task_struct *p) { return 0; }
-static inline int freezing(struct task_struct *p) { return 0; }
-static inline void set_freeze_flag(struct task_struct *p) {}
-static inline void clear_freeze_flag(struct task_struct *p) {}
+static inline bool freezing(struct task_struct *p) { return false; }
static inline bool __refrigerator(bool check_kthr_stop) { return false; }
static inline int freeze_processes(void) { return -ENOSYS; }
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index c72ec7e..5f45423 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -145,7 +145,11 @@ static struct cgroup_subsys_state *freezer_create(struct cgroup_subsys *ss,
static void freezer_destroy(struct cgroup_subsys *ss,
struct cgroup *cgroup)
{
- kfree(cgroup_freezer(cgroup));
+ struct freezer *freezer = cgroup_freezer(cgroup);
+
+ if (freezer->state != CGROUP_THAWED)
+ atomic_dec(&system_freezing_cnt);
+ kfree(freezer);
}
/*
@@ -307,10 +311,14 @@ static int freezer_change_state(struct cgroup *cgroup,
switch (goal_state) {
case CGROUP_THAWED:
+ if (freezer->state != CGROUP_THAWED)
+ atomic_dec(&system_freezing_cnt);
freezer->state = CGROUP_THAWED;
unfreeze_cgroup(cgroup, freezer);
break;
case CGROUP_FROZEN:
+ if (freezer->state == CGROUP_THAWED)
+ atomic_inc(&system_freezing_cnt);
freezer->state = CGROUP_FREEZING;
retval = try_to_freeze_cgroup(cgroup, freezer);
break;
diff --git a/kernel/fork.c b/kernel/fork.c
index 8e6b6f4..fa7beb3 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1000,7 +1000,6 @@ static void copy_flags(unsigned long clone_flags, struct task_struct *p)
new_flags |= PF_FORKNOEXEC;
new_flags |= PF_STARTING;
p->flags = new_flags;
- clear_freeze_flag(p);
}
SYSCALL_DEFINE1(set_tid_address, int __user *, tidptr)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 7a9f706..a797f41 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -11,9 +11,41 @@
#include <linux/freezer.h>
#include <linux/kthread.h>
+/* total number of freezing conditions in effect */
+atomic_t system_freezing_cnt = ATOMIC_INIT(0);
+EXPORT_SYMBOL(system_freezing_cnt);
+
+/* indicate whether PM freezing is in effect, protected by pm_mutex */
+bool pm_freezing;
+bool pm_nosig_freezing;
+
/* protects freezing and frozen transitions */
static DEFINE_SPINLOCK(freezer_lock);
+/**
+ * freezing_slow_path - slow path for testing whether a task needs to be frozen
+ * @p: task to be tested
+ *
+ * This function is called by freezing() if system_freezing_cnt isn't zero
+ * and tests whether @p needs to enter and stay in frozen state. Can be
+ * called under any context. The freezers are responsible for ensuring the
+ * target tasks see the updated state.
+ */
+bool freezing_slow_path(struct task_struct *p)
+{
+ if (p->flags & PF_NOFREEZE)
+ return false;
+
+ if (pm_nosig_freezing || cgroup_freezing(p))
+ return true;
+
+ if (pm_freezing && !(p->flags & PF_FREEZER_NOSIG))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(freezing_slow_path);
+
/* Refrigerator is place where frozen processes are stored :-). */
bool __refrigerator(bool check_kthr_stop)
{
@@ -23,17 +55,11 @@ bool __refrigerator(bool check_kthr_stop)
long save;
/*
- * Enter FROZEN. If NOFREEZE, schedule immediate thawing by
- * clearing freezing.
+ * No point in checking freezing() again - the caller already did.
+ * Proceed to enter FROZEN.
*/
spin_lock_irq(&freezer_lock);
repeat:
- if (!freezing(current)) {
- spin_unlock_irq(&freezer_lock);
- return was_frozen;
- }
- if (current->flags & PF_NOFREEZE)
- clear_freeze_flag(current);
current->flags |= PF_FROZEN;
spin_unlock_irq(&freezer_lock);
@@ -99,18 +125,12 @@ static void fake_signal_wake_up(struct task_struct *p)
bool freeze_task(struct task_struct *p, bool sig_only)
{
unsigned long flags;
- bool ret = false;
spin_lock_irqsave(&freezer_lock, flags);
-
- if ((p->flags & PF_NOFREEZE) ||
- (sig_only && !should_send_signal(p)))
- goto out_unlock;
-
- if (frozen(p))
- goto out_unlock;
-
- set_freeze_flag(p);
+ if (!freezing(p) || frozen(p)) {
+ spin_unlock_irqrestore(&freezer_lock, flags);
+ return false;
+ }
if (should_send_signal(p)) {
fake_signal_wake_up(p);
@@ -123,10 +143,9 @@ bool freeze_task(struct task_struct *p, bool sig_only)
} else {
wake_up_state(p, TASK_INTERRUPTIBLE);
}
- ret = true;
-out_unlock:
+
spin_unlock_irqrestore(&freezer_lock, flags);
- return ret;
+ return true;
}
void __thaw_task(struct task_struct *p)
@@ -143,7 +162,6 @@ void __thaw_task(struct task_struct *p)
* avoid leaving dangling TIF_SIGPENDING behind.
*/
spin_lock_irqsave(&freezer_lock, flags);
- clear_freeze_flag(p);
if (frozen(p)) {
wake_up_process(p);
} else {
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 54ba145..eed8995 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -101,7 +101,7 @@ static int try_to_freeze_tasks(bool sig_only)
read_lock(&tasklist_lock);
do_each_thread(g, p) {
if (!wakeup && !freezer_should_skip(p) &&
- freezing(p) && !frozen(p))
+ p != current && freezing(p) && !frozen(p))
sched_show_task(p);
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
@@ -120,7 +120,11 @@ int freeze_processes(void)
{
int error;
+ if (!pm_freezing)
+ atomic_inc(&system_freezing_cnt);
+
printk("Freezing user space processes ... ");
+ pm_freezing = true;
error = try_to_freeze_tasks(true);
if (!error) {
printk("done.");
@@ -142,6 +146,7 @@ int freeze_kernel_threads(void)
int error;
printk("Freezing remaining freezable tasks ... ");
+ pm_nosig_freezing = true;
error = try_to_freeze_tasks(false);
if (!error)
printk("done.");
@@ -158,6 +163,11 @@ void thaw_processes(void)
{
struct task_struct *g, *p;
+ if (pm_freezing)
+ atomic_dec(&system_freezing_cnt);
+ pm_freezing = false;
+ pm_nosig_freezing = false;
+
oom_killer_enable();
printk("Restarting tasks ... ");
@@ -166,9 +176,6 @@ void thaw_processes(void)
read_lock(&tasklist_lock);
do_each_thread(g, p) {
- if (cgroup_freezing(p))
- continue;
-
__thaw_task(p);
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
--
1.7.3.1
^ permalink raw reply related
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Claudio Moretti @ 2011-10-31 22:34 UTC (permalink / raw)
To: Jonas Meurer; +Cc: dm-crypt
In-Reply-To: <4EAF1E95.1070203@freesources.org>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
>
> While I agree with you, that cryptsetup already does a lot to prevent
> data (i.e. header) loss, I don't see a reason why (optional) header
> backup at some random place on the device would be such a big security
> problem.
>
Because it would significantly decrease the efficiency of cryptsetup
anti-forensic features, if i'm not wrong..
Meaning that if the header is stored somewhere in the disk, that place
should be traceable: if it is random, there has to be some known place
where its location is stored; if the location information is not stored,
but one has to analyze the entire disk to find it, analyzing the disk would
expose the header; this applies also to the "fixed header location"
hypothesis.
That's what I think I have understood from previous (similar and related)
discussions with Arno; please, correct me if I'm mistaken.
Regards,
Claudio
[-- Attachment #2: Type: text/html, Size: 1075 bytes --]
^ permalink raw reply
* problem clearing bit-rates with 'iw'
From: Ben Greear @ 2011-10-31 22:34 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
According to the help, it seems I should be able to pass no rates and
have it clear the mask. But, it seems that is not actually working:
[root@lec2010-ath9k-1 lanforge]# ./local/sbin/iw dev sta4 set bitrates legacy-2.4
command failed: Invalid argument (-22)
[root@lec2010-ath9k-1 lanforge]# ./local/sbin/iw dev sta4 set bitrates legacy-2.4 ""
Usage: ./local/sbin/iw [options] dev <devname> set bitrates [legacy-<2.4|5> <legacy rate in Mbps>*]
Sets up the specified rate masks.
Not passing any arguments would clear the existing mask (if any).
Options:
--debug enable netlink debugging
[root@lec2010-ath9k-1 lanforge]# ./local/sbin/iw dev sta4 set bitrates
command failed: Invalid argument (-22)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <4EAF1FF6.3000500@zytor.com>
On Mon, Oct 31, 2011 at 3:23 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> I use enigmail which is a Thunderbird plugin; it works quite well, but,
> well, it requires Thunderbird. I think many GUI MUAs have similar
> plugins, but text MTAs might be worse, I don't know.
I have never met a GUI MUA I like before google webmail. And the
advantage of google webmail isn't so much the GUI MUA, as the fact
that it doesn't suck like IMAP, and does the automatic folders and
good handling of archives right.
The reason I switched away from pine was that pine is fine (apart from
the archival thing) if you have all your mail local. But "local mail"
is painful when traveling, or when trying to interact with mail using
a mobile phone etc.
And IMAP mail in turn is totally useless both when traveling *and*
when at home.
So no, thunderbird isn't an option. A command line interface that just
verifies the gpg signature is what I'd like to see.
Linus
^ permalink raw reply
* [PATCH 18/17] freezer: restructure __refrigerator()
From: Tejun Heo @ 2011-10-31 22:34 UTC (permalink / raw)
To: rjw, paul, linux-kernel, linux-pm; +Cc: arnd, oleg, matthltc
In-Reply-To: <1320087928-32307-1-git-send-email-tj@kernel.org>
If another freeze happens before all tasks leave FROZEN state after
being thawed, the freezer can see the existing FROZEN and consider the
tasks to be frozen but they can clear FROZEN without checking the new
freezing().
Oleg suggested restructuring __refrigerator() such that there's single
condition check section inside freezer_lock and sigpending is cleared
afterwards, which fixes the problem and simplifies the code.
Restructure accordingly.
-v2: Frozen loop exited without releasing freezer_lock. Fixed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
---
kernel/freezer.c | 32 +++++++++++---------------------
1 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index a95250c..10f9840 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -52,39 +52,29 @@ bool __refrigerator(bool check_kthr_stop)
/* Hmm, should we be allowed to suspend when there are realtime
processes around? */
bool was_frozen = false;
- long save;
+ long save = current->state;
- /*
- * No point in checking freezing() again - the caller already did.
- * Proceed to enter FROZEN.
- */
- spin_lock_irq(&freezer_lock);
-repeat:
- current->flags |= PF_FROZEN;
- spin_unlock_irq(&freezer_lock);
-
- save = current->state;
pr_debug("%s entered refrigerator\n", current->comm);
- spin_lock_irq(¤t->sighand->siglock);
- recalc_sigpending(); /* We sent fake signal, clean it up */
- spin_unlock_irq(¤t->sighand->siglock);
-
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
+
+ spin_lock_irq(&freezer_lock);
+ current->flags |= PF_FROZEN;
if (!freezing(current) ||
(check_kthr_stop && kthread_should_stop()))
+ current->flags &= ~PF_FROZEN;
+ spin_unlock_irq(&freezer_lock);
+
+ if (!(current->flags & PF_FROZEN))
break;
was_frozen = true;
schedule();
}
- /* leave FROZEN */
- spin_lock_irq(&freezer_lock);
- if (freezing(current))
- goto repeat;
- current->flags &= ~PF_FROZEN;
- spin_unlock_irq(&freezer_lock);
+ spin_lock_irq(¤t->sighand->siglock);
+ recalc_sigpending(); /* We sent fake signal, clean it up */
+ spin_unlock_irq(¤t->sighand->siglock);
pr_debug("%s left refrigerator\n", current->comm);
--
1.7.3.1
^ permalink raw reply related
* [PATCH 19/17] freezer: use lock_task_sighand() in fake_signal_wake_up()
From: Tejun Heo @ 2011-10-31 22:35 UTC (permalink / raw)
To: rjw, paul, linux-kernel, linux-pm; +Cc: arnd, oleg, matthltc
In-Reply-To: <1320087928-32307-1-git-send-email-tj@kernel.org>
cgroup_freezer calls freeze_task() without holding tasklist_lock and,
if the task is exiting, its ->sighand may be gone by the time
fake_signal_wake_up() is called. Use lock_task_sighand() instead of
accessing ->sighand directly.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Paul Menage <paul@paulmenage.org>
---
kernel/freezer.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 10f9840..a9c18c7 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -93,9 +93,10 @@ static void fake_signal_wake_up(struct task_struct *p)
{
unsigned long flags;
- spin_lock_irqsave(&p->sighand->siglock, flags);
- signal_wake_up(p, 1);
- spin_unlock_irqrestore(&p->sighand->siglock, flags);
+ if (lock_task_sighand(p, &flags)) {
+ signal_wake_up(p, 1);
+ unlock_task_sighand(p, &flags);
+ }
}
/**
--
1.7.3.1
^ permalink raw reply related
* [PATCH UPDATED 20/17] freezer: remove unused @sig_only from freeze_task()
From: Tejun Heo @ 2011-10-31 22:35 UTC (permalink / raw)
To: rjw, paul, linux-kernel, linux-pm; +Cc: arnd, oleg, matthltc
In-Reply-To: <1320087928-32307-1-git-send-email-tj@kernel.org>
After "freezer: make freezing() test freeze conditions in effect
instead of TIF_FREEZE", freezing() returns authoritative answer on
whether the current task should freeze or not and freeze_task()
doesn't need or use @sig_only. Remove it.
While at it, rewrite function comment for freeze_task() and rename
@sig_only to @user_only in try_to_freeze_tasks().
This patch doesn't cause any functional change.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
---
include/linux/freezer.h | 2 +-
kernel/cgroup_freezer.c | 4 ++--
kernel/freezer.c | 21 +++++++++------------
kernel/power/process.c | 8 ++++----
4 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index ac0513e..4b3dc4c 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -48,7 +48,7 @@ static inline bool try_to_freeze(void)
return __refrigerator(false);
}
-extern bool freeze_task(struct task_struct *p, bool sig_only);
+extern bool freeze_task(struct task_struct *p);
extern bool __set_freezable(bool with_signal);
#ifdef CONFIG_CGROUP_FREEZER
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 5f45423..d161958 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -206,7 +206,7 @@ static void freezer_fork(struct cgroup_subsys *ss, struct task_struct *task)
/* Locking avoids race with FREEZING -> THAWED transitions. */
if (freezer->state == CGROUP_FREEZING)
- freeze_task(task, true);
+ freeze_task(task);
spin_unlock_irq(&freezer->lock);
}
@@ -274,7 +274,7 @@ static int try_to_freeze_cgroup(struct cgroup *cgroup, struct freezer *freezer)
cgroup_iter_start(cgroup, &it);
while ((task = cgroup_iter_next(cgroup, &it))) {
- if (!freeze_task(task, true))
+ if (!freeze_task(task))
continue;
if (frozen(task))
continue;
diff --git a/kernel/freezer.c b/kernel/freezer.c
index a9c18c7..0845321 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -100,20 +100,17 @@ static void fake_signal_wake_up(struct task_struct *p)
}
/**
- * freeze_task - send a freeze request to given task
- * @p: task to send the request to
- * @sig_only: if set, the request will only be sent if the task has the
- * PF_FREEZER_NOSIG flag unset
- * Return value: 'false', if @sig_only is set and the task has
- * PF_FREEZER_NOSIG set or the task is frozen, 'true', otherwise
+ * freeze_task - send a freeze request to given task
+ * @p: task to send the request to
*
- * The freeze request is sent by setting the tasks's TIF_FREEZE flag and
- * either sending a fake signal to it or waking it up, depending on whether
- * or not it has PF_FREEZER_NOSIG set. If @sig_only is set and the task
- * has PF_FREEZER_NOSIG set (ie. it is a typical kernel thread), its
- * TIF_FREEZE flag will not be set.
+ * If @p is freezing, the freeze request is sent by setting %TIF_FREEZE
+ * flag and either sending a fake signal to it or waking it up, depending
+ * on whether it has %PF_FREEZER_NOSIG set.
+ *
+ * RETURNS:
+ * %false, if @p is not freezing or already frozen; %true, otherwise
*/
-bool freeze_task(struct task_struct *p, bool sig_only)
+bool freeze_task(struct task_struct *p)
{
unsigned long flags;
diff --git a/kernel/power/process.c b/kernel/power/process.c
index eed8995..8bddc48 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -22,7 +22,7 @@
*/
#define TIMEOUT (20 * HZ)
-static int try_to_freeze_tasks(bool sig_only)
+static int try_to_freeze_tasks(bool user_only)
{
struct task_struct *g, *p;
unsigned long end_time;
@@ -37,14 +37,14 @@ static int try_to_freeze_tasks(bool sig_only)
end_time = jiffies + TIMEOUT;
- if (!sig_only)
+ if (!user_only)
freeze_workqueues_begin();
while (true) {
todo = 0;
read_lock(&tasklist_lock);
do_each_thread(g, p) {
- if (p == current || !freeze_task(p, sig_only))
+ if (p == current || !freeze_task(p))
continue;
/*
@@ -65,7 +65,7 @@ static int try_to_freeze_tasks(bool sig_only)
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
- if (!sig_only) {
+ if (!user_only) {
wq_busy = freeze_workqueues_busy();
todo += wq_busy;
}
--
1.7.3.1
^ permalink raw reply related
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 22:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3zVxHyixC670Nfrh=r0dXgju=5goz-rLb7WncNTdXjOw@mail.gmail.com>
On Monday 31 October 2011 17:49:58 Simon Glass wrote:
> On Mon, Oct 31, 2011 at 2:15 PM, Tabi Timur-B04825 wrote:
> > On Sun, Oct 30, 2011 at 7:54 PM, Mike Frysinger wrote:
> >> -static void print_num(const char *, ulong);
> >> +__maybe_unused
> >> +static void print_num(const char *name, ulong value)
> >> +{
> >> + printf("%-12s= 0x%08lX\n", name, value);
> >> +}
> >
> > Will the linker remove the functions from the binary if they are unusued?
>
> If built with -ffunction-sections and --gc-sections,, then the linker
> can do this sort of thing. Otherwise it can't, but the compiler can. I
> just tested Mike's code on my ARM compiler to make sure and it happily
> removed print_eth() when it was not used.
i don't think you need function-sections to make this happen. since it is
marked "static", gcc should do DCE on it. the __maybe_unused markings is just
to kill off any warnings about the func not being used (which might occur in
the #ifdef jungle below). that attribute does not tell gcc to retain the
function even if it isn't referenced in this file (as far as gcc can tell).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/233f254c/attachment.pgp
^ permalink raw reply
* Re: Keyboard and mouse issues on MacBook Air (4,2)
From: Nico Schottelius @ 2011-10-31 22:37 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Nico Schottelius, LKML
In-Reply-To: <alpine.LNX.2.00.1110281745290.3541@pobox.suse.cz>
Jiri Kosina [Fri, Oct 28, 2011 at 05:46:29PM +0200]:
> On Sat, 22 Oct 2011, Nico Schottelius wrote:
>
> > The missing bit to correct my previous patch: To which device IDs do the
> > devices named above match to? I.e. is USB_DEVICE_ID_APPLE_WELLSPRING6_*
> > the MacBook Air 4,2?
>
> You need to check the USB IDs (lsusb will tell you) to see which quirk /
> translation table is getting used.
Alright, will prepare a better patch the next weeks (currently no access
to a 4,2 air). So far I've found three different keyboard layouts on the
Air:
2,1 has all keys from F1-F12 mapped, same as 4,2
3,1 has the quirk with missing F5 mapping
I've the usb ids for 2,1 and 4,2 right now and will try to get it
from 3,1 as well.
If anyone with a MacBook Air 3,2 or 4,1 (or any other version not listed
above) is reading this, can you send me an email with the output of
lsusb (or the system profiler from macosx) and which multimedia keys are
mapped to which F1-F12 keys?
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 22:37 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Pekka Enberg, Cyclonus J, Sasha Levin, Christoph Hellwig,
David Rientjes, Linus Torvalds, linux-mm, LKML, Andrew Morton,
Konrad Wilk, Jeremy Fitzhardinge, Seth Jennings, ngupta,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet
In-Reply-To: <60592afd-97aa-4eaf-b86b-f6695d31c7f1@default>
On Mon, Oct 31, 2011 at 01:58:39PM -0700, Dan Magenheimer wrote:
> Hmmm... not sure I understand this one. It IS copy-based
> so is not zerocopy; the page of data is actually moving out
copy-based is my main problem, being synchronous is no big deal I
agree.
I mean, I don't see why you have to make one copy before you start
compressing and then you write to disk the output of the compression
algorithm. To me it looks like this API forces on zcache one more copy
than necessary.
I can't see why this copy is necessary and why zcache isn't working on
"struct page" on core kernel structures instead of moving the memory
off to a memory object invisible to the core VM.
> TRUE. Tell me again why a vmexit/vmenter per 4K page is
> "impossible"? Again you are assuming (1) the CPU had some
It's sure not impossible, it's just impossible we want it as it'd be
too slow.
> real work to do instead and (2) that vmexit/vmenter is horribly
Sure the CPU has another 1000 VM to schedule. This is like saying
virtio-blk isn't needed on desktop virt becauase the desktop isn't
doing much I/O. Absurd argument, there are another 1000 desktops doing
I/O at the same time of course.
> slow. Even if vmexit/vmenter is thousands of cycles, it is still
> orders of magnitude faster than a disk access. And vmexit/vmenter
I fully agree tmem is faster for Xen than no tmem. That's not the
point, we don't need such an articulate hack hiding pages from the
guest OS in order to share pagecache, our hypervisor is just a bit
more powerful and has a function called file_read_actor that does what
your tmem copy does...
> is about the same order of magnitude as page copy, and much
> faster than compression/decompression, both of which still
> result in a nice win.
Saying it's a small overhead, is not like saying it is _needed_. Why
not add a udelay(1) in it too? Sure it won't be noticeable.
> You are also assuming that frontswap puts/gets are highly
> frequent. By definition they are not, because they are
> replacing single-page disk reads/writes due to swapping.
They'll be as frequent as the highmem bounce buffers...
> That said, the API/ABI is very extensible, so if it were
> proven that batching was sufficiently valuable, it could
> be added later... but I don't see it as a showstopper.
> Really do you?
That's fine with me... but like ->writepages it'll take ages for the
fs to switch from writepage to writepages. Considering this is a new
API I don't think it's unreasonable to ask at least it to handle
immediately zerocopy behavior. So showing the userland mapping to the
tmem layer so it can avoid the copy and read from the userland
address. Xen will badly choke if ever tries to do that, but zcache
should be ok with that.
Now there may be algorithms where the page must be stable, but others
will be perfectly fine even if the page is changing under the
compression, and in that case the page won't be discarded and it'll be
marked dirty again. So even if a wrong data goes on disk, we'll
rewrite later. I see no reason why there has always to be a copy
before starting any compression/encryption as long as the algorithm
will not crash its input data isn't changing under it.
The ideal API would be to send down page pointers (and handling
compound pages too), not to copy. Maybe with a flag where you can also
specify offsets so you can send down partial pages too down to a byte
granularity. The "copy input data before anything else can happen"
looks flawed to me. It is not flawed for Xen because Xen has no
knowledge of the guest "struct page" but her I'm talking about the
not-virt usages.
> So, please, all the other parts necessary for tmem are
> already in-tree, why all the resistance about frontswap?
Well my comments are generic not specific to frontswap.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 22:37 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Pekka Enberg, Cyclonus J, Sasha Levin, Christoph Hellwig,
David Rientjes, Linus Torvalds, linux-mm, LKML, Andrew Morton,
Konrad Wilk, Jeremy Fitzhardinge, Seth Jennings, ngupta,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet
In-Reply-To: <60592afd-97aa-4eaf-b86b-f6695d31c7f1@default>
On Mon, Oct 31, 2011 at 01:58:39PM -0700, Dan Magenheimer wrote:
> Hmmm... not sure I understand this one. It IS copy-based
> so is not zerocopy; the page of data is actually moving out
copy-based is my main problem, being synchronous is no big deal I
agree.
I mean, I don't see why you have to make one copy before you start
compressing and then you write to disk the output of the compression
algorithm. To me it looks like this API forces on zcache one more copy
than necessary.
I can't see why this copy is necessary and why zcache isn't working on
"struct page" on core kernel structures instead of moving the memory
off to a memory object invisible to the core VM.
> TRUE. Tell me again why a vmexit/vmenter per 4K page is
> "impossible"? Again you are assuming (1) the CPU had some
It's sure not impossible, it's just impossible we want it as it'd be
too slow.
> real work to do instead and (2) that vmexit/vmenter is horribly
Sure the CPU has another 1000 VM to schedule. This is like saying
virtio-blk isn't needed on desktop virt becauase the desktop isn't
doing much I/O. Absurd argument, there are another 1000 desktops doing
I/O at the same time of course.
> slow. Even if vmexit/vmenter is thousands of cycles, it is still
> orders of magnitude faster than a disk access. And vmexit/vmenter
I fully agree tmem is faster for Xen than no tmem. That's not the
point, we don't need such an articulate hack hiding pages from the
guest OS in order to share pagecache, our hypervisor is just a bit
more powerful and has a function called file_read_actor that does what
your tmem copy does...
> is about the same order of magnitude as page copy, and much
> faster than compression/decompression, both of which still
> result in a nice win.
Saying it's a small overhead, is not like saying it is _needed_. Why
not add a udelay(1) in it too? Sure it won't be noticeable.
> You are also assuming that frontswap puts/gets are highly
> frequent. By definition they are not, because they are
> replacing single-page disk reads/writes due to swapping.
They'll be as frequent as the highmem bounce buffers...
> That said, the API/ABI is very extensible, so if it were
> proven that batching was sufficiently valuable, it could
> be added later... but I don't see it as a showstopper.
> Really do you?
That's fine with me... but like ->writepages it'll take ages for the
fs to switch from writepage to writepages. Considering this is a new
API I don't think it's unreasonable to ask at least it to handle
immediately zerocopy behavior. So showing the userland mapping to the
tmem layer so it can avoid the copy and read from the userland
address. Xen will badly choke if ever tries to do that, but zcache
should be ok with that.
Now there may be algorithms where the page must be stable, but others
will be perfectly fine even if the page is changing under the
compression, and in that case the page won't be discarded and it'll be
marked dirty again. So even if a wrong data goes on disk, we'll
rewrite later. I see no reason why there has always to be a copy
before starting any compression/encryption as long as the algorithm
will not crash its input data isn't changing under it.
The ideal API would be to send down page pointers (and handling
compound pages too), not to copy. Maybe with a flag where you can also
specify offsets so you can send down partial pages too down to a byte
granularity. The "copy input data before anything else can happen"
looks flawed to me. It is not flawed for Xen because Xen has no
knowledge of the guest "struct page" but her I'm talking about the
not-virt usages.
> So, please, all the other parts necessary for tmem are
> already in-tree, why all the resistance about frontswap?
Well my comments are generic not specific to frontswap.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2245.90308@zytor.com>
On Mon, Oct 31, 2011 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Didn't realize that... I guess I'm too used to named remotes.
>
> If so, just using a tag should be fine, no?
Yes, that's what I think. But the argument for using a separate
namespace is that
(a) you never get confused
(b) it would make it easier to make the 1:1 relationship between
branch names and these "pull request signature tags" without limiting
the naming of *normal* tags in any way
(c) they do have separate lifetimes from "real" tags.
But seriously, I don't care about the *implementation* all that much.
If people want to use the crazy git "notes" capability, you can do
that too, although quite frankly, I don't see the point. What actually
matters is that "git push" and "git pull" would JustWork(tm), and
check the signature if one exists, without having to cut-and-paste
data that simply shouldn't be visible to the user.
I abhor the interface Ingo suggested, for example. Why would we have
stupid command line options that we should cut-and-paste? Automation
is for computers, not for people.
Linus
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Frans Meulenbroeks @ 2011-10-31 22:33 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <j8n6fh$dvf$1@dough.gmane.org>
2011/10/31 Koen Kooi <koen@dominion.thruhere.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Op 31-10-11 22:18, Philip Balister schreef:
> > On 10/31/2011 01:48 PM, Koen Kooi wrote:
> >> Op 31-10-11 17:24, Paul Menzel schreef:
> >>> Am Montag, den 31.10.2011, 11:50 +0100 schrieb Koen Kooi:
> >>>> Op 29-10-11 14:33, Paul Menzel schreef:
> >>>>> Dear Martin, dear Denis,
> >>>>>
> >>>>>
> >>>>> Am Samstag, den 29.10.2011, 12:29 +0200 schrieb Martin Jansa:
> >>>>>> From: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> >>>>>>
> >>>>>> Added LIC_FILES_CHKSUM, and fixed LICENSE
> >>>>>>
> >>>>>> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> >>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>>>>
> >>>>> NACK.
> >>>>>
> >>>>> please add the version you import and the commit ID you import
> >>>>> from. This is all written in the guide lines [1]!
> >>>>
> >>>> And as I've said before, meta-oe is not oe-dev, so you can't use
> >>>> take the old 'rules' and apply them to meta-oe 1:1!
> >>
> >>> The guide lines I referred to [1] have been written for OE-core. ;-)
> >>
> >> Yes, and oe-core still isn't meta-oe
> >
> > Why would we need different guidelines?
>
> Different goals I guess. And I don't trust a ruleset that's in a wiki, too
> much room for people coming in and messing it up.
>
> As far as I recall the idea was that meta oe should follow the same
guidelines as oe core.
When was this changed?
Who decided this?
And if there need to be different guidelines, I feel it is useful to
document them somewhere (and probably also why it deviates from oe-core).
Anyway, I think I start to understand why so few people are willing to
contribute to meta-oe.
Have fun! Frans.
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Jonas Meurer @ 2011-10-31 22:40 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <CAP8O3oNnSWO2q5-97XkcpxE-FK7nyyTF1YSSWCf+F+crpr2pEw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 31.10.2011 01:30, schrieb Aleksander Swirski:
> I'm pretty sure this warning is only displayed when someone decides
> to create new crypto on some partition or fill encrypted device
> with random data in the next step after setting the password. but
> just setting the password on an existing device makes data unusable
> without warning. when the partitioning is finished there is a list
> of partitions that will be wiped out, and also, during my
> installation crypto-deviced and /home inside LVM was not listed
> there, but already lost few clicks earlier.
I'm not sure what you mean by 'setting the password on an existing
device'. Last time I checked, the Debian Installer didn't support to
unlock and integrate existing encrypted partitions. You needed to do
this manually on the console. Thus, there was no way to set the
password for an existing device.
I'm pretty sure that you did what you called to 'create new crypto on
some partition'.
Nevertheless, in case that no warning was displayed to you, this
clearly should be considered as a bug.
> i understand that it wasn't taken into consideration that someone
> can attach existing encrypted device, but only that a new one will
> be created. this is inconsistent with how it goes with unencrypted
> partitions, where you can reattach them without formatting and keep
> your data. so i guess with encrypted partition this should also
> work that way. or maybe i miss the point? i will try to make the
> whole scenario clear, and then send my proposition, to
> debian-boot@lists.debian.org <mailto:debian-boot@lists.debian.org>
Yes, support for using existing encrypted devices is not added to the
installer yet. At least, there's a bugreport[1] with a patch. This
might be a useful starting point in case you want to work on adding
this feature.
Greetings,
jonas
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451535
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOryP1AAoJEFJi5/9JEEn+s8kP/2A/ws7Dbo/rUZPY/WmFR/tx
a73AmY/AWf65ouQV89d2+cwF0587UUOFKEOm/6ZOQG8NS5Jwep/co35lSk2s7alZ
uT71R2UELFs8gkDswyBLuzq3UplISiBCZJWWJtRp/5ElYGhQ1B0ylGv3MVcfOxCh
843fmzYNr6YgJFfL960uWoRRNjGQ6C7+a/hbjkJ/ANDnv5/+cSASbSk9cjdPwJh8
sKFzTOy874sUs9rFTQlCSW7sdaNlG9WnTcIrrLJi5MRqsDA48cNbtvpexUzZOw4P
OAeIlPfMliqBlGgs6df5ChFzd3ho+gKl3drowypHa7NMXKuA0AKoRhAEMA93b1LM
ZIWQLn76aOo8+3VxBGzLZ4jr5fXI4/7ikSGPheElOdidFSq3ZHJVVo6Qzvkyn5L+
XwNf/bB9VIo5XnE88TulDPsCyAOn4wNQIGkikt6LmAvXDAA8OuRUSYKxRAxfFZHm
Qw8MTt5EnJO6rox6LcfuM52H5mFbpZsQONhTVqs6lCjj3aSuaS2UKD7u+3vnuH1L
mGnOVLIQP8o65bjE8/twNelSJRCbIdjltxvs3X60WbknfdMaj97jASBf7bolVCCk
rIYw9W644aAihCBz5B/8svjXGN3FuQdvuedrmCUkcFdmPacNDDzcKvDmF063JvdD
P+r8MM78XAqOjpROebnR
=tlhe
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCHSET UPDATED pm] freezer: fix various bugs and simplify implementation, take#2
From: Tejun Heo @ 2011-10-31 22:40 UTC (permalink / raw)
To: rjw, paul, linux-kernel, linux-pm; +Cc: arnd, oleg, matthltc
In-Reply-To: <1320087928-32307-1-git-send-email-tj@kernel.org>
Hello,
On Mon, Oct 31, 2011 at 12:05:11PM -0700, Tejun Heo wrote:
> 0001-freezer-fix-current-state-restoration-race-in-refrig.patch
> 0002-freezer-don-t-unnecessarily-set-PF_NOFREEZE-explicit.patch
> 0003-freezer-unexport-refrigerator-and-update-try_to_free.patch
> 0004-freezer-implement-and-use-kthread_freezable_should_s.patch
> 0005-freezer-rename-thaw_process-to-__thaw_task-and-simpl.patch
> 0006-freezer-remove-racy-clear_freeze_flag-and-set-PF_NOF.patch
> 0007-freezer-don-t-distinguish-nosig-tasks-on-thaw.patch
> 0008-freezer-use-dedicated-lock-instead-of-task_lock-memo.patch
> 0009-freezer-make-freezing-indicate-freeze-condition-in-e.patch
> 0010-freezer-test-freezable-conditions-while-holding-free.patch
> 0011-freezer-kill-PF_FREEZING.patch
> 0012-freezer-clean-up-freeze_processes-failure-path.patch
> 0013-cgroup_freezer-prepare-for-removal-of-TIF_FREEZE.patch
> 0014-freezer-make-freezing-test-freeze-conditions-in-effe.patch
> 0015-freezer-remove-now-unused-TIF_FREEZE.patch
> 0016-freezer-remove-should_send_signal-and-update-frozen.patch
> 0017-freezer-fix-set_freezable-_with_signal-race.patch
I completely forgot about the second patchset[1] fixing problems of
the first one. The first two are folded into respective patches in
the series (0013 and 0014 updated). The following three patches have
been appended to the series.
0018-freezer-restructure-__refrigerator.patch
0019-freezer-use-lock_task_sighand-in-fake_signal_wake_up.patch
0020-freezer-remove-unused-sig_only-from-freeze_task.patch
There still are three more patches which got lost. I'll repost them
later.
The git branch has been updated to reflect the changes.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git pm-freezer
The new HEAD is efb69700c8 "freezer: remove unused @sig_only from
freeze_task()".
Thanks.
--
tejun
[1] http://thread.gmane.org/gmane.linux.kernel/1187553
^ permalink raw reply
* Re: [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
From: Ben Hutchings @ 2011-10-31 22:41 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Weiping Pan, netdev, andy, linux-kernel
In-Reply-To: <16441.1320096188@death>
On Mon, 2011-10-31 at 14:23 -0700, Jay Vosburgh wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
> >On Mon, 2011-10-31 at 13:32 -0700, Jay Vosburgh wrote:
> >[...]
> >> This particular case arises only during enslavement. The call
> >> to bond_update_speed_duplex call has failed, but the device is marked by
> >> bonding to be up. Bonding complains that the device isn't down, but it
> >> cannot get speed and duplex, and therefore is assuming them to be
> >> 100/Full.
> >>
> >> The catch is that this happens only for the ARP monitor, because
> >> it initially presumes a slave to be up regardless of actual carrier
> >> state (for historical reasons related to very old 10 or 10/100 drivers,
> >> prior to the introduction of netif_carrier_*).
> >
> >Right, I gathered that. Is there any reason to use the ARP monitor when
> >all slaves support link state notification? Maybe the bonding
> >documentation should recommend miimon in section 7, not just in section
> >2.
>
> The ARP monitor can validate that traffic actually flows from
> the slave to some destination in the switch domain (and back), so, for
> example, it's useful in cases that multiple switch hops exist between
> the host and the local router. A link failure in the middle of the path
> won't affect carrier on the local device, but still may cause a
> communications break.
Then the ARP monitor should gracefully handle the case where a new slave
has link down, as proposed.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] Ext4: Don't normalize an falloc request if it can fit in 1 extent.
From: Ted Ts'o @ 2011-10-31 22:42 UTC (permalink / raw)
To: Greg Harm; +Cc: Andreas Dilger, linux-ext4
In-Reply-To: <1319824917-28345-1-git-send-email-gharm@google.com>
On Fri, Oct 28, 2011 at 11:01:57AM -0700, Greg Harm wrote:
> If an fallocate request fits in EXT_UNINIT_MAX_LEN, then set the
> EXT4_GET_BLOCKS_NO_NORMALIZE flag. For larger fallocate requests,
> let mballoc.c normalize the request.
> This fixes a problem where large requests were being split
> into non-contiguous extents due to haldar@google.com's
> "ext4: do not normalize block requests from fallocate."
>
> Testing: Checked that 8.x MB falloc'ed files are still laid down
> next to each other (contiguously).
> Checked that the maximum size extent (127.9MB) is allocated as 1
> extent.
> Checked that a 1GB file is somewhat contiguous (often 5-6
> non-contiguous extents now).
> Checked that a 120MB file can still be falloc'ed even if there are no
> single extents large enough to hold it.
>
> Signed-off-by: Greg Harm <gharm@google.com>
Thanks, I had to tweak the patch slightly to make it apply given the
current ext4 tree.
- Ted
commit 5f11e7c457769808bafe5048a98c5cfd624e85f3
Author: Greg Harm <gharm@google.com>
Date: Mon Oct 31 18:41:47 2011 -0400
ext4: Don't normalize an falloc request if it can fit in 1 extent.
If an fallocate request fits in EXT_UNINIT_MAX_LEN, then set the
EXT4_GET_BLOCKS_NO_NORMALIZE flag. For larger fallocate requests,
let mballoc.c normalize the request.
This fixes a problem where large requests were being split into
non-contiguous extents due to commit 556b27abf73: ext4: do not
normalize block requests from fallocate.
Testing:
*) Checked that 8.x MB falloc'ed files are still laid down next to
each other (contiguously).
*) Checked that the maximum size extent (127.9MB) is allocated as 1
extent.
*) Checked that a 1GB file is somewhat contiguous (often 5-6
non-contiguous extents now).
*) Checked that a 120MB file can still be falloc'ed even if there are
no single extents large enough to hold it.
Signed-off-by: Greg Harm <gharm@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index e585caa..9dfdf8f 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4336,10 +4336,16 @@ long ext4_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
trace_ext4_fallocate_exit(inode, offset, max_blocks, ret);
return ret;
}
- flags = EXT4_GET_BLOCKS_CREATE_UNINIT_EXT |
- EXT4_GET_BLOCKS_NO_NORMALIZE;
+ flags = EXT4_GET_BLOCKS_CREATE_UNINIT_EXT;
if (mode & FALLOC_FL_KEEP_SIZE)
flags |= EXT4_GET_BLOCKS_KEEP_SIZE;
+ /*
+ * Don't normalize the request if it can fit in one extent so
+ * that it doesn't get unnecessarily split into multiple
+ * extents.
+ */
+ if (len <= EXT_UNINIT_MAX_LEN << blkbits)
+ flags |= EXT4_GET_BLOCKS_NO_NORMALIZE;
retry:
while (ret >= 0 && ret < max_blocks) {
map.m_lblk = map.m_lblk + ret;
^ permalink raw reply related
* [PATCH] svn: Quote repository root in regex match
From: Ted Percival @ 2011-10-31 22:37 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Ted Percival
Fixes a problem matching repository URLs, especially those with a '+' in
the URL, such as svn+ssh:// URLs. Parts of the URL were interpreted as
special characters by the regex matching.
Signed-off-by: Ted Percival <ted.percival@quest.com>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 351e743..4e95450 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -629,7 +629,7 @@ sub populate_merge_info {
fatal "merge commit $d has ancestor $parent, but that change "
."does not have git-svn metadata!";
}
- unless ($branchurl =~ /^$rooturl(.*)/) {
+ unless ($branchurl =~ /^\Q$rooturl\E(.*)/) {
fatal "commit $parent git-svn metadata changed mid-run!";
}
my $branchpath = $1;
@@ -791,7 +791,7 @@ sub cmd_dcommit {
."has uuid $uuid!";
}
- unless ($branchurl =~ /^$rooturl(.*)/) {
+ unless ($branchurl =~ /^\Q$rooturl\E(.*)/) {
# This branch is very strange indeed.
fatal "merge parent $parent for $d is on branch "
."$branchurl, which is not under the "
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 00/17] drop unused Kconfig symbols
From: Michal Marek @ 2011-10-31 22:42 UTC (permalink / raw)
To: Paul Bolle; +Cc: linux-kernel
In-Reply-To: <1319456255.2409.30.camel@x61.thuisdomein>
On Mon, Oct 24, 2011 at 01:37:35PM +0200, Paul Bolle wrote:
> 0) This is what's left of the Kconfig patches that I send (to
> maintainers and lkml) ten days ago.
>
> 1) I've dropped five patches that were taken by the maintainers
> (blackfin, unicore32, tomoyo, m68k, and staging). cris got a NAK (for an
> invalid reason, but I guess I'll just try again after the v3.2 merge
> window closes).
>
> 2) I've added all the tags the rest of these patches collected.
>
> 3) No further tests were done since I first send these (not that the
> tests done then were very thorough).
>
> 4) I'll send these patches only to you and the people that added a tag.
> Please tell me if you'd like me to also cc lkml and the maintainers. I
> assumed cc'ing those addresses would not be helpful in this stage.
>
> Paul Bolle (17):
> alpha: drop unused Kconfig symbol
> sparc: drop unused Kconfig symbol
> um: drop unused Kconfig symbol
> sh: drop unused Kconfig symbol
> score: drop unused Kconfig symbols
> m32r: drop unused Kconfig symbol
> samples: drop unused Kconfig symbol
> arm: at91: drop unused Kconfig symbol
> (arm: drop unused Kconfig symbol -- skipped)
> openrisc: drop unused Kconfig symbols
> mips: drop unused Kconfig symbols
> powerpc: 40x: drop unused Kconfig symbol
> powerpc: drop unused Kconfig symbols
> x86: drop unused Kconfig symbol
> stmmac: drop unused Kconfig symbol
> pci: drop unused Kconfig symbol
> scsi: drop unused Kconfig symbol
Applied except for the one arm commit.
Michal
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Nicolas Pitre @ 2011-10-31 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029135653.GA25057@mudshark.cambridge.arm.com>
On Sat, 29 Oct 2011, Will Deacon wrote:
> I'll give this a go for v2, thanks. Once this is sorted out I'll do a second
> pass to clean up the reboot modes since I've already got some patches for
> that.
OK great. Please ask Russell to merge your series whenever you're ready
after 3.2-rc1 and I'll rebase my arch_idle series on top of that.
Nicolas
^ permalink raw reply
* Re: how to run ceph on top of other local file system
From: Tommi Virtanen @ 2011-10-31 22:43 UTC (permalink / raw)
To: sheng qiu; +Cc: Sage Weil, ceph-devel
In-Reply-To: <CAB7xdikDt4e7AjRQOKow+p2P4tD9M8yinrgnMxVGFrhu_NsYSg@mail.gmail.com>
On Mon, Oct 31, 2011 at 15:27, sheng qiu <herbert1984106@gmail.com> wrote:
> Thanks a lot for your help.
> i am trying to read the codes of ceph and get a deep understand of how
> it works with its components. but i find it very hard to get into it,
> can you give me some hint on how to read the codes efficiently?
I'm afraid it comes down to reading, trying, failing, re-reading, and
repeating that a lot.
I wrote a "big picture" overview of the architecture of Ceph (while
still trying to keep it very very short) over here:
http://ceph.newdream.net/docs/latest/architecture/
For me personally, knowledge of other network/distributed filesystems,
including things like HDFS, was pretty helpful in getting a grasp of
what's where. I still don't know much of the details of the messaging
etc, but I think one can get a good overview understanding of Ceph's
internals in a few weeks.
I'm personally putting my time into making Ceph conceptually simpler,
not toward trying to explain the complexities. Hopefully that'll be
more useful, in the long run.
^ permalink raw reply
* RE: [PATCH] flexcan: Fix CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK
From: Reuben Dowle @ 2011-10-31 22:43 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, linux-can
In-Reply-To: <4EAF21A6.702@pengutronix.de>
Currently the flexcan driver uses hardware local echo. This blindly
echoes all transmitted frames to all receiving sockets, regardless what
CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
This patch now submits transmitted frames to be echoed in the transmit
complete interrupt, preserving the reference to the sending socket.
This allows the can protocol to correctly handle the local echo.
Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
---
drivers/net/can/flexcan.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index e023379..542ada8 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -302,7 +302,7 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
- kfree_skb(skb);
+ can_put_echo_skb(skb, dev, 0);
/* tx_packets is incremented in flexcan_irq */
stats->tx_bytes += cf->can_dlc;
@@ -612,6 +612,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
/* tx_bytes is incremented in flexcan_start_xmit */
stats->tx_packets++;
flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
+ can_get_echo_skb(dev, 0);
netif_wake_queue(dev);
}
@@ -670,6 +671,8 @@ static int flexcan_chip_start(struct net_device *dev)
int err;
u32 reg_mcr, reg_ctrl;
+ can_free_echo_skb(dev, 0);
+
/* enable module */
flexcan_chip_enable(priv);
@@ -697,12 +700,13 @@ static int flexcan_chip_start(struct net_device *dev)
* only supervisor access
* enable warning int
* choose format C
+ * disable local echo
*
*/
reg_mcr = flexcan_read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_FEN | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_SUPV | FLEXCAN_MCR_WRN_EN |
- FLEXCAN_MCR_IDAM_C;
+ FLEXCAN_MCR_IDAM_C | FLEXCAN_MCR_SRX_DIS;
dev_dbg(dev->dev.parent, "%s: writing mcr=0x%08x", __func__, reg_mcr);
flexcan_write(reg_mcr, ®s->mcr);
@@ -970,7 +974,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
goto failed_map;
}
- dev = alloc_candev(sizeof(struct flexcan_priv), 0);
+ dev = alloc_candev(sizeof(struct flexcan_priv), 1);
if (!dev) {
err = -ENOMEM;
goto failed_alloc;
@@ -978,7 +982,14 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
dev->netdev_ops = &flexcan_netdev_ops;
dev->irq = irq;
- dev->flags |= IFF_ECHO; /* we support local echo in hardware */
+
+ /* Driver supports local echo.
+ * We support local echo in hardware, however this is not used because
+ * hardware local echo loses the sending socket reference
+ * (thus CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK socket options
+ * would not work)
+ */
+ dev->flags |= IFF_ECHO;
priv = netdev_priv(dev);
priv->can.clock.freq = clock_freq;
---
> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: Tuesday, November 01, 2011 11:31 AM
> To: Reuben Dowle
> Cc: netdev@vger.kernel.org; linux-can@vger.kernel.org
> Subject: Re: [PATCH] flexcan: Fix CAN_RAW_RECV_OWN_MSGS and
> CAN_RAW_LOOPBACK
>
> On 10/31/2011 11:18 PM, Reuben Dowle wrote:
> > Currently the flexcan driver uses hardware local echo. This blindly
> echos all transmitted frames to all receiving sockets, regardless what
> CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
> >
> > This patch now submits transmitted frames to be echoed in the
> transmit complete interrupt, preserving the reference to the sending
> socket. This allows the can protocol to correctly handle the local
> echo.
> >
> > Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
>
> Patch looks quite good. Can you please wrap the description to about 72
> chars?
^ permalink raw reply
* RE: [PATCH] flexcan: Fix CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK
From: Reuben Dowle @ 2011-10-31 22:43 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, linux-can
In-Reply-To: <4EAF21A6.702@pengutronix.de>
Currently the flexcan driver uses hardware local echo. This blindly
echoes all transmitted frames to all receiving sockets, regardless what
CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
This patch now submits transmitted frames to be echoed in the transmit
complete interrupt, preserving the reference to the sending socket.
This allows the can protocol to correctly handle the local echo.
Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
---
drivers/net/can/flexcan.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index e023379..542ada8 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -302,7 +302,7 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
- kfree_skb(skb);
+ can_put_echo_skb(skb, dev, 0);
/* tx_packets is incremented in flexcan_irq */
stats->tx_bytes += cf->can_dlc;
@@ -612,6 +612,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
/* tx_bytes is incremented in flexcan_start_xmit */
stats->tx_packets++;
flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
+ can_get_echo_skb(dev, 0);
netif_wake_queue(dev);
}
@@ -670,6 +671,8 @@ static int flexcan_chip_start(struct net_device *dev)
int err;
u32 reg_mcr, reg_ctrl;
+ can_free_echo_skb(dev, 0);
+
/* enable module */
flexcan_chip_enable(priv);
@@ -697,12 +700,13 @@ static int flexcan_chip_start(struct net_device *dev)
* only supervisor access
* enable warning int
* choose format C
+ * disable local echo
*
*/
reg_mcr = flexcan_read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_FEN | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_SUPV | FLEXCAN_MCR_WRN_EN |
- FLEXCAN_MCR_IDAM_C;
+ FLEXCAN_MCR_IDAM_C | FLEXCAN_MCR_SRX_DIS;
dev_dbg(dev->dev.parent, "%s: writing mcr=0x%08x", __func__, reg_mcr);
flexcan_write(reg_mcr, ®s->mcr);
@@ -970,7 +974,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
goto failed_map;
}
- dev = alloc_candev(sizeof(struct flexcan_priv), 0);
+ dev = alloc_candev(sizeof(struct flexcan_priv), 1);
if (!dev) {
err = -ENOMEM;
goto failed_alloc;
@@ -978,7 +982,14 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
dev->netdev_ops = &flexcan_netdev_ops;
dev->irq = irq;
- dev->flags |= IFF_ECHO; /* we support local echo in hardware */
+
+ /* Driver supports local echo.
+ * We support local echo in hardware, however this is not used because
+ * hardware local echo loses the sending socket reference
+ * (thus CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK socket options
+ * would not work)
+ */
+ dev->flags |= IFF_ECHO;
priv = netdev_priv(dev);
priv->can.clock.freq = clock_freq;
---
> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: Tuesday, November 01, 2011 11:31 AM
> To: Reuben Dowle
> Cc: netdev@vger.kernel.org; linux-can@vger.kernel.org
> Subject: Re: [PATCH] flexcan: Fix CAN_RAW_RECV_OWN_MSGS and
> CAN_RAW_LOOPBACK
>
> On 10/31/2011 11:18 PM, Reuben Dowle wrote:
> > Currently the flexcan driver uses hardware local echo. This blindly
> echos all transmitted frames to all receiving sockets, regardless what
> CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
> >
> > This patch now submits transmitted frames to be echoed in the
> transmit complete interrupt, preserving the reference to the sending
> socket. This allows the can protocol to correctly handle the local
> echo.
> >
> > Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
>
> Patch looks quite good. Can you please wrap the description to about 72
> chars?
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2245.90308@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>
>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>> - which is how things happen as a result of a pull request - you won't
>> get tags at all - you have to ask for them by name or use "--tags" to
>> get them all.
>>
>
> Didn't realize that... I guess I'm too used to named remotes.
>
> If so, just using a tag should be fine, no?
So nobody is worried about this (quoting from my earlier message)?
On the other hand, the consumers of "Linus kernel" may want to say that
they trust your tree and your tags because they can verify them with your
GPG signature, but also they can independently verify the lieutenants'
trees you pulled from are genuine.
A signed emphemeral tag is usable as means to verify authenticity in a
hop-by-hop fashion, but that does not leave a permanent trail that can be
used for auditing.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.