[PATCH] mg_disk: add CONFIG_PM_SLEEP to suspend/resume functions
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.
drivers/block/mg_disk.c:783:12: warning: 'mg_suspend' defined but not used
[-Wunused-function]
drivers/block/mg_disk.c:807:12: warning: 'mg_resume' defined but not used
[-Wunused-function]
Signed-off-by: Jingoo Han
---
drivers/block/mg_disk.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
index 1788f491..532bb89 100644
--- a/drivers/block/mg_disk.c
+++ b/drivers/block/mg_disk.c
@@ -780,6 +780,7 @@ static const struct block_device_operations mg_disk_ops = {
.getgeo = mg_getgeo
};
+#ifdef CONFIG_PM_SLEEP
static int mg_suspend(struct device *dev)
{
struct mg_drv_data *prv_data = dev->platform_data;
@@ -824,6 +825,7 @@ static int mg_resume(struct device *dev)
return 0;
}
+#endif
static SIMPLE_DEV_PM_OPS(mg_pm, mg_suspend, mg_resume);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC/RFT] regulator: ab8500: Remove is_enabled from struct ab8500_regulator_info
The is_enabled flag looks not necessary at all, it also introduces some issues
because current code updates info->is_enabled flag in error paths of
ab8500_regulator_enable() and ab8500_regulator_disable().
Thus this patch removes is_enabled from struct ab8500_regulator_info.
This patch also removes info->is_enabled checking in
ab8500_regulator_set_mode(),
so it allows setting mode even the regulator is disabled.
Signed-off-by: Axel Lin
---
Hi,
This patch also removes info->is_enabled checking in
ab8500_regulator_set_mode().
I'm not very clear if we should avoid setting mode when the regulator is
disabled.
It looks to me if we don't want to allow setting mode when regulator is
disabled,
this checking should be done in regulator-core.
Seems current code in other regulator drivers does not check if regulator is
enabled or not in set_mode callback implementation.
Axel
drivers/regulator/ab8500.c | 36 ++--
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 12e2740..8a84b6d 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -30,7 +30,6 @@
* @dev: device pointer
* @desc: regulator description
* @regulator_dev: regulator device
- * @is_enabled: status of regulator (on/off)
* @load_lp_uA: maximum load in idle (low power) mode
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
@@ -48,7 +47,6 @@ struct ab8500_regulator_info {
struct device *dev;
struct regulator_desc desc;
struct regulator_dev*regulator;
- bool is_enabled;
int load_lp_uA;
u8 update_bank;
u8 update_reg;
@@ -121,8 +119,6 @@ static int ab8500_regulator_enable(struct regulator_dev
*rdev)
dev_err(rdev_get_dev(rdev),
"couldn't set enable bits for regulator\n");
- info->is_enabled = true;
-
dev_vdbg(rdev_get_dev(rdev),
"%s-enable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n",
info->desc.name, info->update_bank, info->update_reg,
@@ -148,8 +144,6 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
dev_err(rdev_get_dev(rdev),
"couldn't set disable bits for regulator\n");
- info->is_enabled = false;
-
dev_vdbg(rdev_get_dev(rdev),
"%s-disable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n",
info->desc.name, info->update_bank, info->update_reg,
@@ -202,20 +196,15 @@ static int ab8500_regulator_set_mode(struct regulator_dev
*rdev,
return -EINVAL;
}
- if (info->is_enabled) {
- ret = abx500_mask_and_set_register_interruptible(info->dev,
- info->update_bank, info->update_reg,
- info->update_mask, info->update_val);
- if (ret < 0)
- dev_err(rdev_get_dev(rdev),
- "couldn't set regulator mode\n");
-
- dev_vdbg(rdev_get_dev(rdev),
- "%s-set_mode (bank, reg, mask, value): "
- "0x%x, 0x%x, 0x%x, 0x%x\n",
- info->desc.name, info->update_bank, info->update_reg,
- info->update_mask, info->update_val);
- }
+ ret = abx500_mask_and_set_register_interruptible(info->dev,
+ info->update_bank, info->update_reg,
+ info->update_mask, info->update_val);
+ if (ret < 0)
+ dev_err(rdev_get_dev(rdev), "couldn't set regulator mode\n");
+
+ dev_vdbg(rdev_get_dev(rdev), "%s-set_mode (bank, reg, mask, value):
0x%x, 0x%x, 0x%x, 0x%x\n",
+ info->desc.name, info->update_bank, info->update_reg,
+ info->update_mask, info->update_val);
return ret;
}
@@ -265,12 +254,7 @@ static int ab8500_regulator_is_enabled(struct
regulator_dev *rdev)
info->desc.name, info->update_bank, info->update_reg,
info->update_mask, regval);
- if (regval & info->update_mask)
- info->is_enabled = true;
- else
- info->is_enabled = false;
-
- return info->is_enabled;
+ return regval & info->update_mask;
}
static int ab8500_regulator_get_voltage_sel(struct regulator_dev *rdev)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] ASoC: arizona: remove duplicated include from arizona.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- sound/soc/codecs/arizona.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index 26e1579..c979ff2 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Mar 26
Hi all, Please be careful testing this tree due to some unfixed warnings in the block layer ... Changes since 20130325: The vl4-dvb tree gained a build failure for which I disabled a staging driver. The net-next tree gained conflicts against the wireless tree. The wireless-next tree gained conflicts against the wireless tree. The block tree gained a conflict against Linus' tree and a build failure for which I applied a patch. The tty tree lost its build failure. The usb tree gained a conflict against the tty tree. The char-misc tree gained a build failure so I used the version from next-20130325. The akpm tree gained conflicts against the block tree. I applied a patch to partially fix the powerpc allmodconfig build failures. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (53b6809 Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband) Merging fixes/master (f9294e9 powerpc: define the conditions where the ePAPR idle hcall can be supported) Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1) Merging arc-current/for-curr (367f3fc ARC: Fix the typo in event identifier flags used by ptrace) Merging arm-current/fixes (68a154f ARM: 7681/1: hw_breakpoint: use warn_once to avoid spam from reset_ctrl_regs()) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to ESID_BITS*) Merging sparc/master (53b6809 Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband) Merging net/master (a79ca22 ipv6: fix bad free of addrconf_init_net) Merging ipsec/master (85dfb74 af_key: initialize satype in key_notify_policy_flush()) Merging sound-current/for-linus (55a63d4 ALSA: hda - Fix DAC assignment for independent HP) Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing a device) Merging wireless/master (0f49d64 mwifiex: reset skb->data after processing PCIe sleep confirm cmd respose) Merging driver-core.current/driver-core-linus (e5110f4 sysfs: handle failure path correctly for readdir()) Merging tty.current/tty-linus (8b5c913 serial: 8250_pci: Add WCH CH352 quirk to avoid Xscale detection) Merging usb.current/usb-linus (85ecd03 USB: EHCI: fix bug in iTD/siTD DMA pool allocation) Merging staging.current/staging-linus (e4317ce8 staging: comedi: s626: fix continuous acquisition) Merging char-misc.current/char-misc-linus (347e089 VMCI: Fix process-to-process DRGAMs.) Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable and disable paths) Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 entirely) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (246bbed Revert "crypto: caam - add IPsec ESN support") Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (63662139 params
Re: [Suggestion] kernel: 'now' may be used uninitialized in posix_cpu_timer_schedule function
oh, sorry, it seems better to let ARM folks know about it.
;-)
On 2013年03月26日 14:36, Chen Gang wrote:
> Hello Maintainers:
>
> compiling with EXTRA_CFLAGS=-W:
> make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
> make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
> set 'arm-linux-gnu-' for cross chain prefix
> make V=1 EXTRA_CFLAGS=-W ARCH=arm
>
> it will report:
> kernel/posix-cpu-timers.c:1065:19: warning: ‘now’ may be used
> uninitialized in this function [-Wuninitialized]
>
> it seems it is really a bug.
> can any member help to fix it ?
> or provide additional suggestion ?
> (it seems only "unsigned long long now = 0" is not enough).
>
> :-)
>
>
>
> in kernel/posix-cpu-timers.c:
> for variable 'now' is defined without initialization (line 1029)
> it may be used without initialization (line 1066)
>
>
> 1026 void posix_cpu_timer_schedule(struct k_itimer *timer)
> 1027 {
> 1028 struct task_struct *p = timer->it.cpu.task;
> 1029 unsigned long long now;
> 1030
> 1031 if (unlikely(p == NULL))
> 1032 /*
> 1033 * The task was cleaned up already, no future firings.
> 1034 */
> 1035 goto out;
> 1036
> 1037 /*
> 1038 * Fetch the current sample and update the timer's expiry time.
> 1039 */
> 1040 if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
> 1041 cpu_clock_sample(timer->it_clock, p, &now);
> 1042 bump_cpu_timer(timer, now);
> 1043 if (unlikely(p->exit_state)) {
> 1044 clear_dead_task(timer, now);
> 1045 goto out;
> 1046 }
> 1047 read_lock(&tasklist_lock); /* arm_timer needs it. */
> 1048 spin_lock(&p->sighand->siglock);
> 1049 } else {
> 1050 read_lock(&tasklist_lock);
> 1051 if (unlikely(p->sighand == NULL)) {
> 1052 /*
> 1053 * The process has been reaped.
> 1054 * We can't even collect a sample any more.
> 1055 */
> 1056 put_task_struct(p);
> 1057 timer->it.cpu.task = p = NULL;
> 1058 timer->it.cpu.expires = 0;
> 1059 goto out_unlock;
> 1060 } else if (unlikely(p->exit_state) &&
> thread_group_empty(p)) {
> 1061 /*
> 1062 * We've noticed that the thread is dead, but
> 1063 * not yet reaped. Take this opportunity to
> 1064 * drop our task ref.
> 1065 */
> 1066 clear_dead_task(timer, now);
> 1067 goto out_unlock;
> 1068 }
> 1069 spin_lock(&p->sighand->siglock);
> 1070 cpu_timer_sample_group(timer->it_clock, p, &now);
> 1071 bump_cpu_timer(timer, now);
> 1072 /* Leave the tasklist_lock locked for the call below. */
> 1073 }
> 1074
> 1075 /*
> 1076 * Now re-arm for the new expiry time.
> 1077 */
> 1078 BUG_ON(!irqs_disabled());
> 1079 arm_timer(timer);
> 1080 spin_unlock(&p->sighand->siglock);
> 1081
> 1082 out_unlock:
> 1083 read_unlock(&tasklist_lock);
> 1084
> 1085 out:
> 1086 timer->it_overrun_last = timer->it_overrun;
> 1087 timer->it_overrun = -1;
> 1088 ++timer->it_requeue_pending;
> 1089 }
>
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Suggestion] kernel: 'now' may be used uninitialized in posix_cpu_timer_schedule function
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set 'arm-linux-gnu-' for cross chain prefix
make V=1 EXTRA_CFLAGS=-W ARCH=arm
it will report:
kernel/posix-cpu-timers.c:1065:19: warning: ‘now’ may be used uninitialized
in this function [-Wuninitialized]
it seems it is really a bug.
can any member help to fix it ?
or provide additional suggestion ?
(it seems only "unsigned long long now = 0" is not enough).
:-)
in kernel/posix-cpu-timers.c:
for variable 'now' is defined without initialization (line 1029)
it may be used without initialization (line 1066)
1026 void posix_cpu_timer_schedule(struct k_itimer *timer)
1027 {
1028 struct task_struct *p = timer->it.cpu.task;
1029 unsigned long long now;
1030
1031 if (unlikely(p == NULL))
1032 /*
1033 * The task was cleaned up already, no future firings.
1034 */
1035 goto out;
1036
1037 /*
1038 * Fetch the current sample and update the timer's expiry time.
1039 */
1040 if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
1041 cpu_clock_sample(timer->it_clock, p, &now);
1042 bump_cpu_timer(timer, now);
1043 if (unlikely(p->exit_state)) {
1044 clear_dead_task(timer, now);
1045 goto out;
1046 }
1047 read_lock(&tasklist_lock); /* arm_timer needs it. */
1048 spin_lock(&p->sighand->siglock);
1049 } else {
1050 read_lock(&tasklist_lock);
1051 if (unlikely(p->sighand == NULL)) {
1052 /*
1053 * The process has been reaped.
1054 * We can't even collect a sample any more.
1055 */
1056 put_task_struct(p);
1057 timer->it.cpu.task = p = NULL;
1058 timer->it.cpu.expires = 0;
1059 goto out_unlock;
1060 } else if (unlikely(p->exit_state) &&
thread_group_empty(p)) {
1061 /*
1062 * We've noticed that the thread is dead, but
1063 * not yet reaped. Take this opportunity to
1064 * drop our task ref.
1065 */
1066 clear_dead_task(timer, now);
1067 goto out_unlock;
1068 }
1069 spin_lock(&p->sighand->siglock);
1070 cpu_timer_sample_group(timer->it_clock, p, &now);
1071 bump_cpu_timer(timer, now);
1072 /* Leave the tasklist_lock locked for the call below. */
1073 }
1074
1075 /*
1076 * Now re-arm for the new expiry time.
1077 */
1078 BUG_ON(!irqs_disabled());
1079 arm_timer(timer);
1080 spin_unlock(&p->sighand->siglock);
1081
1082 out_unlock:
1083 read_unlock(&tasklist_lock);
1084
1085 out:
1086 timer->it_overrun_last = timer->it_overrun;
1087 timer->it_overrun = -1;
1088 ++timer->it_requeue_pending;
1089 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Submitting fbdev tree patches
On Mon, 2013-03-25 at 05:27 +, Jingoo Han wrote: > On Monday, March 25, 2013 2:11 PM, Tony Prisk wrote: > > > > Is anyone taking patches for fbdev at the moment? > > > > I sent in some patches for 3.9 but didn't hear back - checking the lists > > it doesn't appear Florian has posted much since the end of Oct 2012. > > CC'ed Tomi Valkeinen, Andrew Morton > > > Hi Tony Prisk, > > Tomy Valkeien will take care of fbdev fixes for 3.9. > (http://www.spinics.net/lists/linux-fbdev/msg10243.html) > > How about sending a pull request to Tomy? > > Best regards, > Jingoo Han > > > > > Regards > > Tony Prisk > > These are not fixes but new features/changes for 3.10 - I don't want to create too much work for someone. Any idea when Florian will be back on board? Regards Ton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (block tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
drivers/built-in.o: In function `bio_alloc_pages':
(.opd+0x2364a8): multiple definition of `bio_alloc_pages'
fs/built-in.o:(.opd+0x7188): first defined here
Caused by an interaction between commits a07876064a0b ("block: Add
bio_alloc_pages()") and commit cafe56359144 ("bcache: A block layer
cache") from the block tree.
I have applied the following fix patch (this should have happened in
merge commit 12f45f28441e "Merge branch 'for-3.10/drivers' into
for-next"):
From: Stephen Rothwell
Date: Tue, 26 Mar 2013 17:26:45 +1100
Subject: [PATCH] block: remove the extra copy of bio_alloc_pages
Signed-off-by: Stephen Rothwell
---
drivers/md/bcache/util.c | 18 --
drivers/md/bcache/util.h | 2 --
2 files changed, 20 deletions(-)
diff --git a/drivers/md/bcache/util.c b/drivers/md/bcache/util.c
index dcec2e4..671a55d 100644
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -237,24 +237,6 @@ start: bv->bv_len = min_t(size_t,
PAGE_SIZE - bv->bv_offset,
}
EXPORT_SYMBOL_GPL(bio_map);
-int bio_alloc_pages(struct bio *bio, gfp_t gfp)
-{
- int i;
- struct bio_vec *bv;
-
- bio_for_each_segment(bv, bio, i) {
- bv->bv_page = alloc_page(gfp);
- if (!bv->bv_page) {
- while (bv-- != bio->bi_io_vec + bio->bi_idx)
- __free_page(bv->bv_page);
- return -ENOMEM;
- }
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(bio_alloc_pages);
-
/*
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group (Any
* use permitted, subject to terms of PostgreSQL license; see.)
diff --git a/drivers/md/bcache/util.h b/drivers/md/bcache/util.h
index 56705fd..499d746 100644
--- a/drivers/md/bcache/util.h
+++ b/drivers/md/bcache/util.h
@@ -570,8 +570,6 @@ static inline unsigned fract_exp_two(unsigned x, unsigned
fract_bits)
void bio_map(struct bio *bio, void *base);
-int bio_alloc_pages(struct bio *bio, gfp_t gfp);
-
static inline sector_t bdev_sectors(struct block_device *bdev)
{
return bdev->bd_inode->i_size >> 9;
--
1.8.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpaMCGXPDgf4.pgp
Description: PGP signature
[net-next 3/5] packet: set transport header before doing xmit
Set the transport header for 1) some drivers (e.g ixgbe needs l4 header to do
atr) 2) precise packet length estimation (introduced in 1def9238) needs l4
header to compute header length.
So this patch first tries to get l4 header for packet socket through
skb_flow_dissect(), and pretend no l4 header if skb_flow_dissect() fails.
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
net/packet/af_packet.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index bd0d14c..83fdd0a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -88,6 +88,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_INET
#include
@@ -1412,6 +1413,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct
socket *sock,
__be16 proto = 0;
int err;
int extra_len = 0;
+ struct flow_keys keys;
/*
* Get and verify the address.
@@ -1512,6 +1514,11 @@ retry:
if (unlikely(extra_len == 4))
skb->no_fcs = 1;
+ if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_reset_transport_header(skb);
+
dev_queue_xmit(skb);
rcu_read_unlock();
return len;
@@ -1918,6 +1925,7 @@ static int tpacket_fill_skb(struct packet_sock *po,
struct sk_buff *skb,
struct page *page;
void *data;
int err;
+ struct flow_keys keys;
ph.raw = frame;
@@ -1943,6 +1951,11 @@ static int tpacket_fill_skb(struct packet_sock *po,
struct sk_buff *skb,
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
+ if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_reset_transport_header(skb);
+
if (po->tp_tx_has_off) {
int off_min, off_max, off;
off_min = po->tp_hdrlen - sizeof(struct sockaddr_ll);
@@ -2199,6 +2212,7 @@ static int packet_snd(struct socket *sock,
unsigned short gso_type = 0;
int hlen, tlen;
int extra_len = 0;
+ struct flow_keys keys;
/*
* Get and verify the address.
@@ -2351,6 +2365,13 @@ static int packet_snd(struct socket *sock,
len += vnet_hdr_len;
}
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ skb_set_transport_header(skb, skb_checksum_start_offset(skb));
+ else if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_set_transport_header(skb, reserve);
+
if (unlikely(extra_len == 4))
skb->no_fcs = 1;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[net-next 5/5] net_sched: better precise estimation on packet length for untrusted packets
gso_segs were reset to zero when kernel receive packets from untrusted
source. But we use this zero value to estimate precise packet len which is
wrong. So this patch tries to estimate the correct gso_segs value before using
it in qdisc_pkt_len_init().
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
net/core/dev.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index de930b7..f5ad23b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2588,6 +2588,7 @@ static void qdisc_pkt_len_init(struct sk_buff *skb)
*/
if (shinfo->gso_size) {
unsigned int hdr_len;
+ u16 gso_segs = shinfo->gso_segs;
/* mac layer + network layer */
hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
@@ -2597,7 +2598,12 @@ static void qdisc_pkt_len_init(struct sk_buff *skb)
hdr_len += tcp_hdrlen(skb);
else
hdr_len += sizeof(struct udphdr);
- qdisc_skb_cb(skb)->pkt_len += (shinfo->gso_segs - 1) * hdr_len;
+
+ if (shinfo->gso_type & SKB_GSO_DODGY)
+ gso_segs = DIV_ROUND_UP(skb->len - hdr_len,
+ shinfo->gso_size);
+
+ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;
}
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[net-next 2/5] tuntap: set transport header before passing it to kernel
Currently, for the packets receives from tuntap, before doing header check,
kernel just reset the transport header in netif_receive_skb() which pretends no
l4 header. This is suboptimal for precise packet length estimation (introduced
in 1def9238) which needs correct l4 header for gso packets.
So this patch set the transport header to csum_start for partial checksum
packets, otherwise it first try skb_flow_dissect(), if it fails, just reset the
transport header.
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 95837c1..48cd73a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -70,6 +70,7 @@
#include
#include
+#include
/* Uncomment to enable debugging */
/* #define TUN_DEBUG 1 */
@@ -1049,6 +1050,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
bool zerocopy = false;
int err;
u32 rxhash;
+ struct flow_keys keys;
if (!(tun->flags & TUN_NO_PI)) {
if ((len -= sizeof(pi)) > total_len)
@@ -1203,6 +1205,14 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
}
skb_reset_network_header(skb);
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ skb_set_transport_header(skb, skb_checksum_start_offset(skb));
+ else if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_reset_transport_header(skb);
+
rxhash = skb_get_rxhash(skb);
netif_rx_ni(skb);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[net-next 4/5] netback: set transport header before passing it to kernel
Currently, for the packets receives from netback, before doing header check,
kernel just reset the transport header in netif_receive_skb() which pretends non
l4 header. This is suboptimal for precise packet length estimation (introduced
in 1def9238: net_sched: more precise pkt_len computation) which needs correct l4
header for gso packets.
The patch just reuse the header probed by netback for partial checksum packets
and tries to use skb_flow_dissect() for other cases, if both fail, just pretend
no l4 header.
Cc: Eric Dumazet
Cc: Ian Campbell
Signed-off-by: Jason Wang
---
drivers/net/xen-netback/netback.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index aa28550..fc8faa7 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -39,6 +39,7 @@
#include
#include
+#include
#include
#include
@@ -1184,6 +1185,7 @@ static int checksum_setup(struct xenvif *vif, struct
sk_buff *skb)
if (th >= skb_tail_pointer(skb))
goto out;
+ skb_set_transport_header(skb, 4 * iph->ihl);
skb->csum_start = th - skb->head;
switch (iph->protocol) {
case IPPROTO_TCP:
@@ -1495,6 +1497,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
skb->dev = vif->dev;
skb->protocol = eth_type_trans(skb, skb->dev);
+ skb_reset_network_header(skb);
if (checksum_setup(vif, skb)) {
netdev_dbg(vif->dev,
@@ -1503,6 +1506,15 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
continue;
}
+ if (!skb_transport_header_was_set(skb)) {
+ struct flow_keys keys;
+
+ if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_reset_transport_header(skb);
+ }
+
vif->dev->stats.rx_bytes += skb->len;
vif->dev->stats.rx_packets++;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[net-next 1/5] macvtap: set transport header before passing skb to lower device
Set the transport header for 1) some drivers (e.g ixgbe) needs l4 header 2)
precise packet length estimation (introduced in 1def9238) needs l4 header to
compute header length.
For the packets with partial checksum, the patch just set the transport header
to csum_start. Otherwise tries to use skb_flow_dissect() to get l4 offset, if it
fails, just pretend no l4 header.
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index a449439..acf6450 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/*
* A macvtap queue is the central object of this driver, it connects
@@ -645,6 +646,7 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
int vnet_hdr_len = 0;
int copylen = 0;
bool zerocopy = false;
+ struct flow_keys keys;
if (q->flags & IFF_VNET_HDR) {
vnet_hdr_len = q->vnet_hdr_sz;
@@ -725,6 +727,13 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
goto err_kfree;
}
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ skb_set_transport_header(skb, skb_checksum_start_offset(skb));
+ else if (skb_flow_dissect(skb, &keys))
+ skb_set_transport_header(skb, keys.thoff);
+ else
+ skb_set_transport_header(skb, ETH_HLEN);
+
rcu_read_lock_bh();
vlan = rcu_dereference_bh(q->vlan);
/* copy skb_ubuf_info for callback when skb has no error */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[net-next 0/5] set transport header for untrusted packets
We don't set transport header for untrusted packets in the past, but for the follwoing reasons, we need to do it now. - Better packet length estimation (introduced in 1def9238) needs l4 header for gso packets to compute the header length. - Some driver needs l4 header (e.g. ixgbe needs tcp header to do atr). So this patches tries to set transport header for packets from untrusted source (netback, packet, tuntap, macvtap). Plus a fix for better estimation on packet length for DODGY packet. Tested on tun/macvtap/packet, compile test on netback. Jason Wang (5): macvtap: set transport header before passing skb to lower device tuntap: set transport header before passing it to kernel packet: set transport header before doing xmit netback: set transport header before passing it to kernel net_sched: better precise estimation on packet length for untrusted packets drivers/net/macvtap.c |9 + drivers/net/tun.c | 10 ++ drivers/net/xen-netback/netback.c | 12 net/core/dev.c|8 +++- net/packet/af_packet.c| 21 + 5 files changed, 59 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (v4l-dvb tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c: In function 'solo_enc_default': drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c:1031:7: error: case label does not reduce to an integer constant drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c:1035:7: error: case label does not reduce to an integer constant I am not sure why this has suddenly appeared, but I have disabled the driver for now using this patch: From: Stephen Rothwell Date: Tue, 26 Mar 2013 17:14:47 +1100 Subject: [PATCH] disable solo6x10 driver due to build errors Signed-off-by: Stephen Rothwell --- drivers/staging/media/solo6x10/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig index ec32776..a6a970f 100644 --- a/drivers/staging/media/solo6x10/Kconfig +++ b/drivers/staging/media/solo6x10/Kconfig @@ -1,6 +1,7 @@ config SOLO6X10 tristate "Softlogic 6x10 MPEG codec cards" depends on PCI && VIDEO_DEV && SND && I2C + depends on BROKEN select VIDEOBUF2_DMA_SG select VIDEOBUF2_DMA_CONTIG select SND_PCM -- 1.8.1 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpqaSRrBYMeb.pgp Description: PGP signature
Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy-> members
On 3/25/2013 3:54 PM, Viresh Kumar wrote: > On 25 March 2013 15:11, Sekhar Nori wrote: >> So down in the cpufreq driver probe below, we bail out if freq_table is >> not provided. So all this checking for freq_table in the code you pasted >> above is superfluous. If you can clean that part up and add checking for >> cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to >> test it out ;) > > Attached is the complete patch and following is your fixup for davinci > (just to review): For the attached patch, [nsek...@ti.com: tested on da850 evm] Acked-by: Sekhar Nori Thanks, sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the final tree (akpm and block tree related)
Hi all,
After merging the final tree, today's linux-next build
produced this warning:
fs/bio.c: In function 'submit_bio_wait':
fs/bio.c:786:17: warning: assignment from incompatible pointer type [enabled by
default]
This is due to an interaction between commit 9e882242c ("block: Add
submit_bio_wait(), remove from md") from the block tree and commit
"block: prep work for batch completion" from the akpm tree.
In fact we are getting several more warnings due to that patch in the
akpm tree:
drivers/md/bcache/writeback.c: In function 'write_dirty':
drivers/md/bcache/writeback.c:276:20: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/writeback.c: In function 'read_dirty':
drivers/md/bcache/writeback.c:350:21: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/movinggc.c: In function 'read_moving':
drivers/md/bcache/movinggc.c:160:18: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/request.c: In function 'bch_insert_data_loop':
drivers/md/bcache/request.c:518:16: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/request.c: In function 'do_bio_hook':
drivers/md/bcache/request.c:684:18: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/request.c: In function 'cached_dev_cache_miss':
drivers/md/bcache/request.c:926:19: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/request.c:957:29: warning: assignment from incompatible
pointer type [enabled by default]
drivers/md/bcache/debug.c: In function 'bch_data_verify':
drivers/md/bcache/debug.c:208:19: warning: assignment from incompatible pointer
type [enabled by default]
drivers/md/bcache/super.c: In function 'bch_write_bdev_super':
drivers/md/bcache/super.c:257:17: warning: assignment from incompatible pointer
type [enabled by default]
drivers/md/bcache/super.c: In function 'bcache_write_super':
drivers/md/bcache/super.c:295:18: warning: assignment from incompatible pointer
type [enabled by default]
drivers/md/bcache/super.c: In function 'uuid_io':
drivers/md/bcache/super.c:333:18: warning: assignment from incompatible pointer
type [enabled by default]
drivers/md/bcache/super.c: In function 'prio_io':
drivers/md/bcache/super.c:492:17: warning: assignment from incompatible pointer
type [enabled by default]
There are probably more ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp6iz7JstnUw.pgp
Description: PGP signature
Re: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver
Hi,
On Monday 25 March 2013 03:16 PM, Laxman Dewangan wrote:
On Monday 25 March 2013 03:02 PM, Kishon Vijay Abraham I wrote:
From: Graeme Gregory
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
insertion/removal.
Signed-off-by: Graeme Gregory
Signed-off-by: Moiz Sonasath
Signed-off-by: Ruchika Kharwar
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sebastien Guiriec
---
I think this driver is more over the cable connection like vbus
detetcion or ID pin detection.
Then why not it is implemented based on extcon framework?
extcon framework uses notification mechanism and Felipe dint like using
notification here. right Felipe?
That way, generic usb driver (like tegra_usb driver) will get
notification through extcon.
We need this cable detection through extcon on our tegra solution
through the Palmas.
+#include
+#include
+
+static int palmas_usb_read(struct palmas *palmas, unsigned int reg,
+ unsigned int *dest)
+{
+ unsigned int addr;
+ int slave;
+
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_USB_OTG_BASE);
+ addr = PALMAS_BASE_TO_REG(PALMAS_USB_OTG_BASE, reg);
+
+ return regmap_read(palmas->regmap[slave], addr, dest);
Please use the generic api for palmas_read()/palmas_write(0 as it will
be ease on debugging on register access.
Direct regmap_read() does not help much on this.
Graeme,
Any reason why you dint use palmas_read()/palmas_write here?
Btw palmas_read()/palmas_write() internally uses regmap APIs.
+}
+
+static int palmas_usb_write(struct palmas *palmas, unsigned int reg,
+ unsigned int data)
+{
+ unsigned int addr;
+ int slave;
+
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_USB_OTG_BASE);
+ addr = PALMAS_BASE_TO_REG(PALMAS_USB_OTG_BASE, reg);
+
+ return regmap_write(palmas->regmap[slave], addr, data);
Same as above.
+
+ if (status != OMAP_DWC3_UNKNOWN) {
+ palmas_usb->linkstat = status;
+ palmas_usb->mailboxstat = dwc3_omap_mailbox(status);
Omap specific call, why? This is generic palma driver.
hmm.. I think we should either fall-back to the notification mechanism
or have the client drivers pass function pointer here. Felipe?
+
+ palmas_usb->dev = &pdev->dev;
+
+ palmas_usb->irq1 = regmap_irq_get_virq(palmas->irq_data,
+ PALMAS_ID_OTG_IRQ);
+ palmas_usb->irq2 = regmap_irq_get_virq(palmas->irq_data,
+ PALMAS_ID_IRQ);
+ palmas_usb->irq3 = regmap_irq_get_virq(palmas->irq_data,
+ PALMAS_VBUS_OTG_IRQ);
+ palmas_usb->irq4 = regmap_irq_get_virq(palmas->irq_data,
+ PALMAS_VBUS_IRQ);
Should be come from platform_get_irq() through platform driver.
No. It can be obtained from regmap too.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] sched: move up affinity check to mitigate useless redoing overhead
Currently, LBF_ALL_PINNED is cleared after affinity check is passed.
So, if task migration is skipped by small load value or
small imbalance value in move_tasks(), we don't clear LBF_ALL_PINNED.
At last, we trigger 'redo' in load_balance().
Imbalance value is often so small that any tasks cannot be moved
to other cpus and, of course, this situation may be continued after
we change the target cpu. So this patch move up affinity check code and
clear LBF_ALL_PINNED before evaluating load value in order to
mitigate useless redoing overhead.
In addition, re-order some comments correctly.
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3f8c4f2..d3c6011 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3874,10 +3874,14 @@ int can_migrate_task(struct task_struct *p, struct
lb_env *env)
int tsk_cache_hot = 0;
/*
* We do not migrate tasks that are:
-* 1) running (obviously), or
+* 1) throttled_lb_pair, or
* 2) cannot be migrated to this CPU due to cpus_allowed, or
-* 3) are cache-hot on their current CPU.
+* 3) running (obviously), or
+* 4) are cache-hot on their current CPU.
*/
+ if (throttled_lb_pair(task_group(p), env->src_cpu, env->dst_cpu))
+ return 0;
+
if (!cpumask_test_cpu(env->dst_cpu, tsk_cpus_allowed(p))) {
int new_dst_cpu;
@@ -3948,9 +3952,6 @@ static int move_one_task(struct lb_env *env)
struct task_struct *p, *n;
list_for_each_entry_safe(p, n, &env->src_rq->cfs_tasks, se.group_node) {
- if (throttled_lb_pair(task_group(p), env->src_rq->cpu,
env->dst_cpu))
- continue;
-
if (!can_migrate_task(p, env))
continue;
@@ -4002,7 +4003,7 @@ static int move_tasks(struct lb_env *env)
break;
}
- if (throttled_lb_pair(task_group(p), env->src_cpu,
env->dst_cpu))
+ if (!can_migrate_task(p, env))
goto next;
load = task_h_load(p);
@@ -4013,9 +4014,6 @@ static int move_tasks(struct lb_env *env)
if ((load / 2) > env->imbalance)
goto next;
- if (!can_migrate_task(p, env))
- goto next;
-
move_task(p, env);
pulled++;
env->imbalance -= load;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/6] sched: prevent to re-select dst-cpu in load_balance()
Commit 88b8dac0 makes load_balance() consider other cpus in its group.
But, in that, there is no code for preventing to re-select dst-cpu.
So, same dst-cpu can be selected over and over.
This patch add functionality to load_balance() in order to exclude
cpu which is selected once. We prevent to re-select dst_cpu via
env's cpus, so now, env's cpus is a candidate not only for src_cpus,
but also dst_cpus.
Cc: Srivatsa Vaddagiri
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e3f09f4..6f238d2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3883,7 +3883,7 @@ int can_migrate_task(struct task_struct *p, struct lb_env
*env)
return 0;
if (!cpumask_test_cpu(env->dst_cpu, tsk_cpus_allowed(p))) {
- int new_dst_cpu;
+ int cpu;
schedstat_inc(p, se.statistics.nr_failed_migrations_affine);
@@ -3898,12 +3898,14 @@ int can_migrate_task(struct task_struct *p, struct
lb_env *env)
if (!env->dst_grpmask || (env->flags & LBF_SOME_PINNED))
return 0;
- new_dst_cpu = cpumask_first_and(env->dst_grpmask,
- tsk_cpus_allowed(p));
- if (new_dst_cpu < nr_cpu_ids) {
- env->flags |= LBF_SOME_PINNED;
- env->new_dst_cpu = new_dst_cpu;
- }
+ /* Prevent to re-select dst_cpu via env's cpus */
+ for_each_cpu_and(cpu, env->dst_grpmask, env->cpus)
+ if (cpumask_test_cpu(cpu, tsk_cpus_allowed(p))) {
+ env->flags |= LBF_SOME_PINNED;
+ env->new_dst_cpu = cpu;
+ break;
+ }
+
return 0;
}
@@ -4989,7 +4991,6 @@ static int load_balance(int this_cpu, struct rq *this_rq,
int *balance)
{
int ld_moved, cur_ld_moved, active_balance = 0;
- int lb_iterations, max_lb_iterations;
struct sched_group *group;
struct rq *busiest;
unsigned long flags;
@@ -5009,11 +5010,6 @@ static int load_balance(int this_cpu, struct rq *this_rq,
* other cpus in our group */
if (idle == CPU_NEWLY_IDLE) {
env.dst_grpmask = NULL;
- /* we don't care max_lb_iterations in this case,
-* in following patch, this will be removed */
- max_lb_iterations = 0;
- } else {
- max_lb_iterations = cpumask_weight(env.dst_grpmask);
}
cpumask_copy(cpus, cpu_active_mask);
@@ -5041,7 +5037,6 @@ redo:
schedstat_add(sd, lb_imbalance[idle], env.imbalance);
ld_moved = 0;
- lb_iterations = 1;
if (busiest->nr_running > 1) {
/*
* Attempt to move tasks. If find_busiest_group has found
@@ -5098,14 +5093,17 @@ more_balance:
* moreover subsequent load balance cycles should correct the
* excess load moved.
*/
- if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0 &&
- lb_iterations++ < max_lb_iterations) {
+ if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0) {
env.dst_rq = cpu_rq(env.new_dst_cpu);
env.dst_cpu = env.new_dst_cpu;
env.flags &= ~LBF_SOME_PINNED;
env.loop = 0;
env.loop_break = sched_nr_migrate_break;
+
+ /* Prevent to re-select dst_cpu via env's cpus */
+ cpumask_clear_cpu(env.dst_cpu, env.cpus);
+
/*
* Go back to "more_balance" rather than "redo" since we
* need to continue with same src_cpu.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] sched: rename load_balance_tmpmask to load_balance_mask
This name doesn't represent specific meaning.
So rename it to imply it's purpose.
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f12624..07b4178 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6865,7 +6865,7 @@ struct task_group root_task_group;
LIST_HEAD(task_groups);
#endif
-DECLARE_PER_CPU(cpumask_var_t, load_balance_tmpmask);
+DECLARE_PER_CPU(cpumask_var_t, load_balance_mask);
void __init sched_init(void)
{
@@ -6902,7 +6902,7 @@ void __init sched_init(void)
#endif /* CONFIG_RT_GROUP_SCHED */
#ifdef CONFIG_CPUMASK_OFFSTACK
for_each_possible_cpu(i) {
- per_cpu(load_balance_tmpmask, i) = (void *)ptr;
+ per_cpu(load_balance_mask, i) = (void *)ptr;
ptr += cpumask_size();
}
#endif /* CONFIG_CPUMASK_OFFSTACK */
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d3c6011..e3f09f4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4958,7 +4958,7 @@ static struct rq *find_busiest_queue(struct lb_env *env,
#define MAX_PINNED_INTERVAL512
/* Working cpumask for load_balance and load_balance_newidle. */
-DEFINE_PER_CPU(cpumask_var_t, load_balance_tmpmask);
+DEFINE_PER_CPU(cpumask_var_t, load_balance_mask);
static int need_active_balance(struct lb_env *env)
{
@@ -4993,7 +4993,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
struct sched_group *group;
struct rq *busiest;
unsigned long flags;
- struct cpumask *cpus = __get_cpu_var(load_balance_tmpmask);
+ struct cpumask *cpus = __get_cpu_var(load_balance_mask);
struct lb_env env = {
.sd = sd,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] sched: explicitly cpu_idle_type checking in rebalance_domains()
After commit 88b8dac0, dst-cpu can be changed in load_balance(),
then we can't know cpu_idle_type of dst-cpu when load_balance()
return positive. So, add explicit cpu_idle_type checking.
Cc: Srivatsa Vaddagiri
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f084069..9d693d0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5506,10 +5506,10 @@ static void rebalance_domains(int cpu, enum
cpu_idle_type idle)
if (time_after_eq(jiffies, sd->last_balance + interval)) {
if (load_balance(cpu, rq, sd, idle, &balance)) {
/*
-* We've pulled tasks over so either we're no
-* longer idle.
+* We've pulled tasks over so either we may
+* be no longer idle.
*/
- idle = CPU_NOT_IDLE;
+ idle = idle_cpu(cpu) ? CPU_IDLE : CPU_NOT_IDLE;
}
sd->last_balance = jiffies;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/6] sched: change position of resched_cpu() in load_balance()
cur_ld_moved is reset if env.flags hit LBF_NEED_BREAK.
So, there is possibility that we miss doing resched_cpu().
Correct it as changing position of resched_cpu()
before checking LBF_NEED_BREAK.
Acked-by: Peter Zijlstra
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7a33e59..f084069 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5061,17 +5061,17 @@ more_balance:
double_rq_unlock(env.dst_rq, busiest);
local_irq_restore(flags);
- if (env.flags & LBF_NEED_BREAK) {
- env.flags &= ~LBF_NEED_BREAK;
- goto more_balance;
- }
-
/*
* some other cpu did the load balance for us.
*/
if (cur_ld_moved && env.dst_cpu != smp_processor_id())
resched_cpu(env.dst_cpu);
+ if (env.flags & LBF_NEED_BREAK) {
+ env.flags &= ~LBF_NEED_BREAK;
+ goto more_balance;
+ }
+
/*
* Revisit (affine) tasks on src_cpu that couldn't be moved to
* us and move them to an alternate dst_cpu in our sched_group
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] sched: don't consider other cpus in our group in case of NEWLY_IDLE
Commit 88b8dac0 makes load_balance() consider other cpus in its group,
regardless of idle type. When we do NEWLY_IDLE balancing, we should not
consider it, because a motivation of NEWLY_IDLE balancing is to turn
this cpu to non idle state if needed. This is not the case of other cpus.
So, change code not to consider other cpus for NEWLY_IDLE balancing.
With this patch, assign 'if (pulled_task) this_rq->idle_stamp = 0'
in idle_balance() is corrected, because NEWLY_IDLE balancing doesn't
consider other cpus. Assigning to 'this_rq->idle_stamp' is now valid.
Cc: Srivatsa Vaddagiri
Acked-by: Peter Zijlstra
Signed-off-by: Joonsoo Kim
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9d693d0..3f8c4f2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5007,8 +5007,17 @@ static int load_balance(int this_cpu, struct rq *this_rq,
.cpus = cpus,
};
+ /* For NEWLY_IDLE load_balancing, we don't need to consider
+* other cpus in our group */
+ if (idle == CPU_NEWLY_IDLE) {
+ env.dst_grpmask = NULL;
+ /* we don't care max_lb_iterations in this case,
+* in following patch, this will be removed */
+ max_lb_iterations = 0;
+ } else {
+ max_lb_iterations = cpumask_weight(env.dst_grpmask);
+ }
cpumask_copy(cpus, cpu_active_mask);
- max_lb_iterations = cpumask_weight(env.dst_grpmask);
schedstat_inc(sd, lb_count[idle]);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/6] correct load_balance()
Commit 88b8dac0 makes load_balance() consider other cpus in its group. But, there are some missing parts for this feature to work properly. This patchset correct these things and make load_balance() robust. Others are related to LBF_ALL_PINNED. This is fallback functionality when all tasks can't be moved as cpu affinity. But, currently, if imbalance is not large enough to task's load, we leave LBF_ALL_PINNED flag and 'redo' is triggered. This is not our intention, so correct it. These are based on v3.9-rc4. Changelog v1->v2: Changes from Peter's suggestion [4/6]: don't include a code to evaluate load value in can_migrate_task() [5/6]: rename load_balance_tmpmask to load_balance_mask [6/6]: not use one more cpumasks, use env's cpus for prevent to re-select Joonsoo Kim (6): sched: change position of resched_cpu() in load_balance() sched: explicitly cpu_idle_type checking in rebalance_domains() sched: don't consider other cpus in our group in case of NEWLY_IDLE sched: move up affinity check to mitigate useless redoing overhead sched: rename load_balance_tmpmask to load_balance_mask sched: prevent to re-select dst-cpu in load_balance() kernel/sched/core.c |4 +-- kernel/sched/fair.c | 67 +++ 2 files changed, 38 insertions(+), 33 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf/x86: Ivy Bridge-EP uncore support
From: "Yan, Zheng"
The uncore subsystem in Ivy Bridge-EP is similar to Sandy Bridge-EP.
There are some differences in config register encoding and pci device
IDs. The Ivy Bridge-EP uncore also supports a few new events.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 520 --
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 51 ++-
2 files changed, 543 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 979f81f..54ddede 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -34,9 +34,13 @@ DEFINE_UNCORE_FORMAT_ATTR(occ_sel, occ_sel, "config:14-15");
DEFINE_UNCORE_FORMAT_ATTR(occ_invert, occ_invert, "config:30");
DEFINE_UNCORE_FORMAT_ATTR(occ_edge, occ_edge, "config:14-51");
DEFINE_UNCORE_FORMAT_ATTR(filter_tid, filter_tid, "config1:0-4");
+DEFINE_UNCORE_FORMAT_ATTR(filter_link, filter_link, "config1:5-8");
DEFINE_UNCORE_FORMAT_ATTR(filter_nid, filter_nid, "config1:10-17");
+DEFINE_UNCORE_FORMAT_ATTR(filter_nid2, filter_nid, "config1:32-47");
DEFINE_UNCORE_FORMAT_ATTR(filter_state, filter_state, "config1:18-22");
+DEFINE_UNCORE_FORMAT_ATTR(filter_state2, filter_state, "config1:17-22");
DEFINE_UNCORE_FORMAT_ATTR(filter_opc, filter_opc, "config1:23-31");
+DEFINE_UNCORE_FORMAT_ATTR(filter_opc2, filter_opc, "config1:52-60");
DEFINE_UNCORE_FORMAT_ATTR(filter_band0, filter_band0, "config1:0-7");
DEFINE_UNCORE_FORMAT_ATTR(filter_band1, filter_band1, "config1:8-15");
DEFINE_UNCORE_FORMAT_ATTR(filter_band2, filter_band2, "config1:16-23");
@@ -367,6 +371,7 @@ static struct event_constraint
snbep_uncore_cbox_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x04, 0x3),
UNCORE_EVENT_CONSTRAINT(0x05, 0x3),
UNCORE_EVENT_CONSTRAINT(0x07, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x09, 0x3),
UNCORE_EVENT_CONSTRAINT(0x11, 0x1),
UNCORE_EVENT_CONSTRAINT(0x12, 0x3),
UNCORE_EVENT_CONSTRAINT(0x13, 0x3),
@@ -416,6 +421,14 @@ static struct event_constraint
snbep_uncore_r3qpi_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x24, 0x3),
UNCORE_EVENT_CONSTRAINT(0x25, 0x3),
UNCORE_EVENT_CONSTRAINT(0x26, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x28, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x29, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2a, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2b, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2c, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2d, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2e, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x2f, 0x3),
UNCORE_EVENT_CONSTRAINT(0x30, 0x3),
UNCORE_EVENT_CONSTRAINT(0x31, 0x3),
UNCORE_EVENT_CONSTRAINT(0x32, 0x3),
@@ -423,6 +436,8 @@ static struct event_constraint
snbep_uncore_r3qpi_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x34, 0x3),
UNCORE_EVENT_CONSTRAINT(0x36, 0x3),
UNCORE_EVENT_CONSTRAINT(0x37, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x38, 0x3),
+ UNCORE_EVENT_CONSTRAINT(0x39, 0x3),
EVENT_CONSTRAINT_END
};
@@ -772,55 +787,63 @@ static struct intel_uncore_type snbep_uncore_r3qpi = {
SNBEP_UNCORE_PCI_COMMON_INIT(),
};
+enum {
+ SNBEP_PCI_UNCORE_HA,
+ SNBEP_PCI_UNCORE_IMC,
+ SNBEP_PCI_UNCORE_QPI,
+ SNBEP_PCI_UNCORE_R2PCIE,
+ SNBEP_PCI_UNCORE_R3QPI,
+};
+
static struct intel_uncore_type *snbep_pci_uncores[] = {
- &snbep_uncore_ha,
- &snbep_uncore_imc,
- &snbep_uncore_qpi,
- &snbep_uncore_r2pcie,
- &snbep_uncore_r3qpi,
+ [SNBEP_PCI_UNCORE_HA] = &snbep_uncore_ha,
+ [SNBEP_PCI_UNCORE_IMC] = &snbep_uncore_imc,
+ [SNBEP_PCI_UNCORE_QPI] = &snbep_uncore_qpi,
+ [SNBEP_PCI_UNCORE_R2PCIE] = &snbep_uncore_r2pcie,
+ [SNBEP_PCI_UNCORE_R3QPI]= &snbep_uncore_r3qpi,
NULL,
};
static DEFINE_PCI_DEVICE_TABLE(snbep_uncore_pci_ids) = {
{ /* Home Agent */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_HA),
- .driver_data = (unsigned long)&snbep_uncore_ha,
+ .driver_data = SNBEP_PCI_UNCORE_HA,
},
{ /* MC Channel 0 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC0),
- .driver_data = (unsigned long)&snbep_uncore_imc,
+ .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 1 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC1),
- .driver_data = (unsigned long)&snbep_uncore_imc,
+ .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 2 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC2),
- .driver_data = (unsigned long)&snbep_uncore_imc,
+ .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 3 */
PCI_DEVICE(PCI_VEN
[PATCH 1/2] perf/x86: fix SNB-EP CBO and PCU uncore PMU filter management
From: "Yan, Zheng"
The existing code assumes all Cbox and PCU events are using
filter, but actually the filter is event specific. Furthermore
the filter is sub-divided into multiple fields which are used
by different events.
Signed-off-by: Yan, Zheng
Reported-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 326 +-
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 13 +-
2 files changed, 280 insertions(+), 59 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index b43200d..979f81f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -17,6 +17,9 @@ static struct event_constraint constraint_fixed =
static struct event_constraint constraint_empty =
EVENT_CONSTRAINT(0, 0, 0);
+#define __BITS_VALUE(x, i, n) ((typeof(x))(((x) >> ((i) * (n))) & \
+ ((1ULL << (n)) - 1)))
+
DEFINE_UNCORE_FORMAT_ATTR(event, event, "config:0-7");
DEFINE_UNCORE_FORMAT_ATTR(event_ext, event, "config:0-7,21");
DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
@@ -110,6 +113,21 @@ static void uncore_put_constraint(struct intel_uncore_box
*box, struct perf_even
reg1->alloc = 0;
}
+static u64 uncore_shared_reg_config(struct intel_uncore_box *box, int idx)
+{
+ struct intel_uncore_extra_reg *er;
+ unsigned long flags;
+ u64 config;
+
+ er = &box->shared_regs[idx];
+
+ raw_spin_lock_irqsave(&er->lock, flags);
+ config = er->config;
+ raw_spin_unlock_irqrestore(&er->lock, flags);
+
+ return config;
+}
+
/* Sandy Bridge-EP uncore support */
static struct intel_uncore_type snbep_uncore_cbox;
static struct intel_uncore_type snbep_uncore_pcu;
@@ -205,7 +223,7 @@ static void snbep_uncore_msr_enable_event(struct
intel_uncore_box *box, struct p
struct hw_perf_event_extra *reg1 = &hwc->extra_reg;
if (reg1->idx != EXTRA_REG_NONE)
- wrmsrl(reg1->reg, reg1->config);
+ wrmsrl(reg1->reg, uncore_shared_reg_config(box, 0));
wrmsrl(hwc->config_base, hwc->config | SNBEP_PMON_CTL_EN);
}
@@ -226,29 +244,6 @@ static void snbep_uncore_msr_init_box(struct
intel_uncore_box *box)
wrmsrl(msr, SNBEP_PMON_BOX_CTL_INT);
}
-static int snbep_uncore_hw_config(struct intel_uncore_box *box, struct
perf_event *event)
-{
- struct hw_perf_event *hwc = &event->hw;
- struct hw_perf_event_extra *reg1 = &hwc->extra_reg;
-
- if (box->pmu->type == &snbep_uncore_cbox) {
- reg1->reg = SNBEP_C0_MSR_PMON_BOX_FILTER +
- SNBEP_CBO_MSR_OFFSET * box->pmu->pmu_idx;
- reg1->config = event->attr.config1 &
- SNBEP_CB0_MSR_PMON_BOX_FILTER_MASK;
- } else {
- if (box->pmu->type == &snbep_uncore_pcu) {
- reg1->reg = SNBEP_PCU_MSR_PMON_BOX_FILTER;
- reg1->config = event->attr.config1 &
SNBEP_PCU_MSR_PMON_BOX_FILTER_MASK;
- } else {
- return 0;
- }
- }
- reg1->idx = 0;
-
- return 0;
-}
-
static struct attribute *snbep_uncore_formats_attr[] = {
&format_attr_event.attr,
&format_attr_umask.attr,
@@ -345,16 +340,16 @@ static struct attribute_group
snbep_uncore_qpi_format_group = {
.attrs = snbep_uncore_qpi_formats_attr,
};
+#define SNBEP_UNCORE_MSR_OPS_COMMON_INIT() \
+ .init_box = snbep_uncore_msr_init_box,\
+ .disable_box= snbep_uncore_msr_disable_box, \
+ .enable_box = snbep_uncore_msr_enable_box, \
+ .disable_event = snbep_uncore_msr_disable_event, \
+ .enable_event = snbep_uncore_msr_enable_event,\
+ .read_counter = uncore_msr_read_counter
+
static struct intel_uncore_ops snbep_uncore_msr_ops = {
- .init_box = snbep_uncore_msr_init_box,
- .disable_box= snbep_uncore_msr_disable_box,
- .enable_box = snbep_uncore_msr_enable_box,
- .disable_event = snbep_uncore_msr_disable_event,
- .enable_event = snbep_uncore_msr_enable_event,
- .read_counter = uncore_msr_read_counter,
- .get_constraint = uncore_get_constraint,
- .put_constraint = uncore_put_constraint,
- .hw_config = snbep_uncore_hw_config,
+ SNBEP_UNCORE_MSR_OPS_COMMON_INIT(),
};
static struct intel_uncore_ops snbep_uncore_pci_ops = {
@@ -446,6 +441,145 @@ static struct intel_uncore_type snbep_uncore_ubox = {
.format_group = &snbep_uncore_ubox_format_group,
};
+static struct extra_reg snbep_uncore_cbox_extra_regs[] = {
+ SNBEP_CBO_EVENT_EXTRA_REG(SNBEP_CBO_PMON_CTL_TID_EN,
+ SNBEP_CBO_PMON_CTL_TID_EN, 0x1),
+ SNBEP_CBO_EVENT_EXTRA_REG(0x0334, 0x, 0x4),
+ SNBEP_CBO
linux-next: manual merge of the akpm tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
block/blk-core.c between commit f79ea4161434 ("block: Refactor
blk_update_request()") from the block tree and commit "block, aio: batch
completion for bios/kiocbs" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc block/blk-core.c
index f224d17,186603b..000
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@@ -2280,9 -2251,11 +2281,10 @@@ EXPORT_SYMBOL(blk_fetch_request)
* %false - this request doesn't have any more data
* %true - this request has more data
**/
- bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
+ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes,
+ struct batch_complete *batch)
{
- int total_bytes, bio_nbytes, next_idx = 0;
- struct bio *bio;
+ int total_bytes;
if (!req->bio)
return false;
@@@ -2328,21 -2301,56 +2330,21 @@@
blk_account_io_completion(req, nr_bytes);
- total_bytes = bio_nbytes = 0;
- while ((bio = req->bio) != NULL) {
- int nbytes;
+ total_bytes = 0;
+ while (req->bio) {
+ struct bio *bio = req->bio;
+ unsigned bio_bytes = min(bio->bi_size, nr_bytes);
- if (nr_bytes >= bio->bi_size) {
+ if (bio_bytes == bio->bi_size)
req->bio = bio->bi_next;
- nbytes = bio->bi_size;
- req_bio_endio(req, bio, nbytes, error, batch);
- next_idx = 0;
- bio_nbytes = 0;
- } else {
- int idx = bio->bi_idx + next_idx;
- req_bio_endio(req, bio, bio_bytes, error);
- if (unlikely(idx >= bio->bi_vcnt)) {
- blk_dump_rq_flags(req, "__end_that");
- printk(KERN_ERR "%s: bio idx %d >= vcnt %d\n",
- __func__, idx, bio->bi_vcnt);
- break;
- }
++ req_bio_endio(req, bio, bio_bytes, error, batch);
- nbytes = bio_iovec_idx(bio, idx)->bv_len;
- BIO_BUG_ON(nbytes > bio->bi_size);
+ total_bytes += bio_bytes;
+ nr_bytes -= bio_bytes;
- /*
- * not a complete bvec done
- */
- if (unlikely(nbytes > nr_bytes)) {
- bio_nbytes += nr_bytes;
- total_bytes += nr_bytes;
- break;
- }
-
- /*
- * advance to the next vector
- */
- next_idx++;
- bio_nbytes += nbytes;
- }
-
- total_bytes += nbytes;
- nr_bytes -= nbytes;
-
- bio = req->bio;
- if (bio) {
- /*
- * end more in this run, or just return 'not-done'
- */
- if (unlikely(nr_bytes <= 0))
- break;
- }
+ if (!nr_bytes)
+ break;
}
/*
pgpVwBKddM2Jq.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
drivers/md/raid1.c and drivers/md/raid10.c between commit 9e882242c619
("block: Add submit_bio_wait(), remove from md") from the block tree and
commit "block: prep work for batch completion" from the akpm tree.
I fixed it up (by removing the functions from the files as in the block
tree patch) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxPFEbmoB8Q.pgp
Description: PGP signature
Re: [PATCH 05/10] migrate: add hugepage migration code to migrate_pages()
On Mon, Mar 25, 2013 at 02:04:16PM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:50, Naoya Horiguchi wrote:
> [...]
> > @@ -523,6 +544,11 @@ static inline int check_pmd_range(struct
> > vm_area_struct *vma, pud_t *pud,
> > pmd = pmd_offset(pud, addr);
> > do {
> > next = pmd_addr_end(addr, end);
> > + if (pmd_huge(*pmd) && is_vm_hugetlb_page(vma)) {
> > + check_hugetlb_pmd_range(vma, pmd, nodes,
> > + flags, private);
>
> I am afraid this has the same issue with other huge page sizes I have
> mentioned earlier.
So we need arch-dependent helper functions. I'll try that, but it
might be better to start with enabling only x86_64 if it takes time
to implement this.
> > + continue;
> > + }
> > split_huge_page_pmd(vma, addr, pmd);
> > if (pmd_none_or_trans_huge_or_clear_bad(pmd))
> > continue;
> [...]
> > @@ -1012,14 +1040,8 @@ static int migrate_to_node(struct mm_struct *mm, int
> > source, int dest,
> > check_range(mm, mm->mmap->vm_start, mm->task_size, &nmask,
> > flags | MPOL_MF_DISCONTIG_OK, &pagelist);
> >
> > - if (!list_empty(&pagelist)) {
> > - err = migrate_pages(&pagelist, new_node_page, dest,
> > + return migrate_movable_pages(&pagelist, new_node_page, dest,
> > MIGRATE_SYNC, MR_SYSCALL);
> > - if (err)
> > - putback_lru_pages(&pagelist);
> > - }
> > -
> > - return err;
>
> This is really confusing. Why migrate_pages doesn't do putback cleanup
> on its own but migrate_movable_pages does?
I consider migrate_movable_pages() as a wrapper of migrate_pages(),
not the variant of migrate_pages().
We can find the same pattern in the callers like
if (!list_empty(&pagelist)) {
err = migrate_pages(...);
if (err)
putback_lru_pages(&pagelist);
}
, so it can be simplified by migrate_movable_pages().
Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/blk_types.h between commit a38352e0ac02 ("block: Add an
explicit bio flag for bios that own their bvec") from the block tree and
commit "mm: make snapshotting pages for stable writes a per-bio
operation" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/blk_types.h
index e8de670,22990cf..000
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@@ -116,8 -117,7 +117,8 @@@ struct bio
* Flags starting here get preserved by bio_reset() - this includes
* BIO_POOL_IDX()
*/
- #define BIO_RESET_BITS12
- #define BIO_OWNS_VEC 12 /* bio_free() should free bvec */
+ #define BIO_RESET_BITS13
++#define BIO_OWNS_VEC 13 /* bio_free() should free bvec */
#define bio_flagged(bio, flag)((bio)->bi_flags & (1 << (flag)))
pgpOTgIDvUY5x.pgp
Description: PGP signature
Re: [PATCH] drivers: virtio: Use PTR_RET function
On Tue, 26 Mar 2013 13:57:09 +1030 Rusty Russell wrote: > Alexandru Gheorghiu writes: > > > Used PTR_RET function instead of IS_ERR and PTR_ERR. > > Patch found using coccinelle. > > WTF is PTR_RET? PTR_RET doesn't return anything. Why is it called > that? It doesn't even make sense. > > ZERO_OR_PTR_ERR() maybe. > > But what problem are we solving? Insufficient churn in the tree? Code > being too readable? This isn't some hard-to-get right corner case, or a > missed optimization. > > Andrew, what am I missing here? It seemed like a good idea at the time. Merged it two years ago and have since been keenly awaiting an opportunity to use it. It seems that people _have_ been using it, but mainly netfilter people and we know they're all crazy ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: virtio: Use PTR_RET function
Alexandru Gheorghiu writes: > Used PTR_RET function instead of IS_ERR and PTR_ERR. > Patch found using coccinelle. WTF is PTR_RET? PTR_RET doesn't return anything. Why is it called that? It doesn't even make sense. ZERO_OR_PTR_ERR() maybe. But what problem are we solving? Insufficient churn in the tree? Code being too readable? This isn't some hard-to-get right corner case, or a missed optimization. Andrew, what am I missing here? Grumpy, Rusty. > Signed-off-by: Alexandru Gheorghiu > --- > drivers/virtio/virtio_mmio.c |5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c > index 1ba0d68..d1e664f 100644 > --- a/drivers/virtio/virtio_mmio.c > +++ b/drivers/virtio/virtio_mmio.c > @@ -567,10 +567,7 @@ static int vm_cmdline_set(const char *device, > pdev = platform_device_register_resndata(&vm_cmdline_parent, > "virtio-mmio", vm_cmdline_id++, > resources, ARRAY_SIZE(resources), NULL, 0); > - if (IS_ERR(pdev)) > - return PTR_ERR(pdev); > - > - return 0; > + return PTR_RET(pdev); > } > > static int vm_cmdline_get_device(struct device *dev, void *data) > -- > 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] mfd: max77686: Use NULL instead of 0
'data' is a pointer and hence use NULL instead of 0.
Silences the following warning:
drivers/mfd/max77686.c:49:50: warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
Cc: Jonghwa Lee
---
drivers/mfd/max77686.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 4d73963..1cbb176 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -46,7 +46,7 @@ static struct regmap_config max77686_regmap_config = {
#ifdef CONFIG_OF
static struct of_device_id max77686_pmic_dt_match[] = {
- {.compatible = "maxim,max77686",.data = 0},
+ {.compatible = "maxim,max77686", .data = NULL},
{},
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer
On Thu, 2013-03-21 at 01:41 +, Ben Hutchings wrote:
> On Wed, 2013-03-20 at 21:43 +0100, Sebastian Gottschall (DD-WRT) wrote:
> > Am 20.03.2013 20:02, schrieb Sebastian Gottschall (DD-WRT):
> > > Hello
> > >
> > > The patch for sa_restorer will break mips builds, since sa_restorer
> > > isnt defined as field within the struct, but the MACRO is.
> > > so use the __ARCH_HAS_SA_RESTORER way which is implemented in that way
> > > in linux 3.9 or simply revert the patch
>
> This also appears to break blackfin, ia64, parisc and tile.
>
> I think for earlier 3.x.y series we can use one of the attached
> (untested) patches to define __ARCH_HAS_SA_RESTORER appropriately, and
> then apply the upstream change:
>
> commit 522cff142d7d2f9230839c9e1f21a4d8bcc22a4a
> Author: Andrew Morton
> Date: Wed Mar 13 14:59:34 2013 -0700
>
> kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER
>
> Ben.
The Debian package of 3.2.41, which included these two patches, built on
mips and ia64. (Actually it failed on ia64, but *compilation* was
successful.)
(This does not, of course, prove that I didn't un-fix the information
leak.)
Here is the first patch again (separate versions for 3.8.y and for
earlier series), now with a more accurate subject line. I'm going to
include this in 3.2.42.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
From: Ben Hutchings
Date: Sun, 25 Nov 2012 22:24:19 -0500
Subject: signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer
flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined. Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.
Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.
Signed-off-by: Ben Hutchings
Cc: Al Viro
---
--- a/arch/arm/include/asm/signal.h
+++ b/arch/arm/include/asm/signal.h
@@ -127,6 +127,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/avr32/include/asm/signal.h
+++ b/arch/avr32/include/asm/signal.h
@@ -128,6 +128,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/cris/include/asm/signal.h
+++ b/arch/cris/include/asm/signal.h
@@ -122,6 +122,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/h8300/include/asm/signal.h
+++ b/arch/h8300/include/asm/signal.h
@@ -121,6 +121,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/m32r/include/asm/signal.h
+++ b/arch/m32r/include/asm/signal.h
@@ -123,6 +123,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/m68k/include/asm/signal.h
+++ b/arch/m68k/include/asm/signal.h
@@ -119,6 +119,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/mn10300/include/asm/signal.h
+++ b/arch/mn10300/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/powerpc/include/asm/signal.h
+++ b/arch/powerpc/include/asm/signal.h
@@ -109,6 +109,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/s390/include/asm/signal.h
+++ b/arch/s390/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/sparc/include/asm/signal.h
+++ b/arch/sparc/include/asm/signal.h
@@ -191,6 +191,7 @@ struct __old_sigaction {
unsigned long sa_flags;
void (*sa_restorer)(void); /* not used by Linux/SPARC yet */
};
+#define __ARCH_HAS_SA_RESTORER
typedef struct sigaltstack {
void __user *ss_sp;
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -125,6 +125,8 @@ typedef unsigned long sigset_t;
extern void do_notify_resume(struct pt_regs *, void *, __u32);
# endif /* __KERNEL__ */
+#define __ARCH
Re: [PATCH v2] X.509: Support parse long form of length octets in Authority Key Identifier
Hi experts,
I didn't this patch merged to any git tree or maybe I missed.
Where is the right place for send X.509 patch?
Thanks a lot!
Joey Lee
於 四，2013-03-14 於 15:34 +0800，Lee, Chun-Yi 提到：
> From: Chun-Yi Lee
>
> Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
> Identifier Extension is:
>
>AuthorityKeyIdentifier ::= SEQUENCE {
> keyIdentifier [0] KeyIdentifier OPTIONAL,
> authorityCertIssuer [1] GeneralNamesOPTIONAL,
> authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
>
>KeyIdentifier ::= OCTET STRING
>
> When a certificate also provides
> authorityCertIssuer and authorityCertSerialNumber then the length of
> AuthorityKeyIdentifier SEQUENCE is likely to long form format.
> e.g.
>The example certificate demos/tunala/A-server.pem in openssl source:
>
> X509v3 Authority Key Identifier:
> keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
> DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority
> (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
> serial:00
>
> Current parsing rule of OID_authorityKeyIdentifier only take care the
> short form format, it causes load certificate to modsign_keyring fail:
>
> [ 12.061147] X.509: Extension: 47
> [ 12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
>
> So, this patch add the parsing rule for support long form format against
> Authority Key Identifier.
>
> v2:
> - Removed comma from author's name.
> - Moved 'Short Form length' comment inside the if-body.
> - Changed the type of sub to size_t.
> - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
> - Moved the key_len's value assignment before alter v.
> - Fixed the typo of octets.
> - Add 2 to v before entering the loop for calculate the length.
> - Removed the comment of check vlen.
>
> Cc: Rusty Russell
> Cc: Josh Boyer
> Cc: Randy Dunlap
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Acked-by: David Howells
> Signed-off-by: Chun-Yi Lee
> ---
> crypto/asymmetric_keys/x509_cert_parser.c | 55
> 1 files changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
> b/crypto/asymmetric_keys/x509_cert_parser.c
> index 7fabc4c..59ab6d2 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
> return 0;
> }
>
> +/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0)
> */
> +#define SEQ_TAG_KEYID (ASN1_CONT << 6)
> +
> /*
> * Process certificate extensions that are used to qualify the certificate.
> */
> @@ -407,21 +410,57 @@ int x509_process_extension(void *context, size_t hdrlen,
> }
>
> if (ctx->last_oid == OID_authorityKeyIdentifier) {
> + size_t key_len;
> +
> /* Get hold of the CA key fingerprint */
> if (vlen < 5)
> return -EBADMSG;
> - if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
> - v[1] != vlen - 2 ||
> - v[2] != (ASN1_CONT << 6) ||
> - v[3] != vlen - 4)
> +
> + /* Authority Key Identifier must be a Constructed SEQUENCE */
> + if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
> return -EBADMSG;
> - v += 4;
> - vlen -= 4;
>
> - f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
> + /* Authority Key Identifier is not indefinite length */
> + if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
> + return -EBADMSG;
> +
> + if (vlen < ASN1_INDEFINITE_LENGTH) {
> + /* Short Form length */
> + if (v[1] != vlen - 2 ||
> + v[2] != SEQ_TAG_KEYID ||
> + v[3] != vlen - 4)
> + return -EBADMSG;
> +
> + key_len = v[3];
> + v += 4;
> + } else {
> + /* Long Form length */
> + size_t seq_len = 0;
> + size_t sub = v[1] - ASN1_INDEFINITE_LENGTH;
> +
> + if (sub > 2)
> + return -EBADMSG;
> +
> + /* calculate the length from subsequent octets */
> + v += 2;
> + for (i = 0; i < sub; i++) {
> + seq_len <<= 8;
> + seq_len |= v[i];
> + }
> +
> + if (seq_len != vlen - 2 - sub ||
> + v[sub] != SEQ_TAG_KEYID ||
> + v[sub + 1] > vlen - 4 - sub)
> + return -EBADMSG;
> +
> + key_len = v[sub + 1];
> +
Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list
On Mon, Mar 25 2013, Dave Chinner wrote:
> On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
>> On Mon, Mar 25 2013, Dave Chinner wrote:
>> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> >> Call cond_resched() from shrink_dentry_list() to preserve
>> >> shrink_dcache_parent() interactivity.
>> >>
>> >> void shrink_dcache_parent(struct dentry * parent)
>> >> {
>> >> while ((found = select_parent(parent, &dispose)) != 0)
>> >> shrink_dentry_list(&dispose);
>> >> }
>> >>
>> >> select_parent() populates the dispose list with dentries which
>> >> shrink_dentry_list() then deletes. select_parent() carefully uses
>> >> need_resched() to avoid doing too much work at once. But neither
>> >> shrink_dcache_parent() nor its called functions call cond_resched().
>> >> So once need_resched() is set select_parent() will return single
>> >> dentry dispose list which is then deleted by shrink_dentry_list().
>> >> This is inefficient when there are a lot of dentry to process. This
>> >> can cause softlockup and hurts interactivity on non preemptable
>> >> kernels.
>> >
>> > Hi Greg,
>> >
>> > I can see how this coul dcause problems, but isn't the problem then
>> > that shrink_dcache_parent()/select_parent() itself is mishandling
>> > the need for rescheduling rather than being a problem with
>> > the shrink_dentry_list() implementation? i.e. select_parent() is
>> > aborting batching based on a need for rescheduling, but then not
>> > doing that itself and assuming that someone else will do the
>> > reschedule for it?
>> >
>> > Perhaps this is a better approach:
>> >
>> > - while ((found = select_parent(parent, &dispose)) != 0)
>> > + while ((found = select_parent(parent, &dispose)) != 0) {
>> > shrink_dentry_list(&dispose);
>> > + cond_resched();
>> > + }
>> >
>> > With this, select_parent() stops batching when a resched is needed,
>> > we dispose of the list as a single batch and only then resched if it
>> > was needed before we go and grab the next batch. That should fix the
>> > "small batch" problem without the potential for changing the
>> > shrink_dentry_list() behaviour adversely for other users
>>
>> I considered only modifying shrink_dcache_parent() as you show above.
>> Either approach fixes the problem I've seen. My initial approach adds
>> cond_resched() deeper into shrink_dentry_list() because I thought that
>> there might a secondary benefit: shrink_dentry_list() would be willing
>> to give up the processor when working on a huge number of dentry. This
>> could improve interactivity during shrinker and umount. I don't feel
>> strongly on this and would be willing to test and post the
>> add-cond_resched-to-shrink_dcache_parent approach.
>
> The shrinker has interactivity problems because of the global
> dcache_lru_lock, not because of ithe size of the list passed to
> shrink_dentry_list(). The amount of work that shrink_dentry_list()
> does here is already bound by the shrinker batch size. Hence in the
> absence of the RT folk complaining about significant holdoffs I
> don't think there is an interactivity problem through the shrinker
> path.
No arguments from me.
> As for the unmount path - shrink_dcache_for_umount_subtree() - that
> doesn't use shrink_dentry_list() and so would need it's own internal
> calls to cond_resched(). Perhaps it's shrink_dcache_sb() that you
> are concerned about? Either way, And there are lots more similar
> issues in the unmount path such as evict_inodes(), so unless you are
> going to give every possible path through unmount/remount/bdev
> invalidation the same treatment then changing shrink_dentry_list()
> won't significantly improve the interactivity of the system
> situation in these paths...
Ok. As stated, I wasn't sure if the cond_resched() in
shrink_dentry_list() had any appeal. Apparently it doesn't. I'll drop
this approach in favor of the following:
--->8---
From: Greg Thelen
Date: Sat, 23 Mar 2013 18:25:02 -0700
Subject: [PATCH] vfs: dcache: cond_resched in shrink_dcache_parent
Call cond_resched() in shrink_dcache_parent() to maintain
interactivity.
Before this patch:
void shrink_dcache_parent(struct dentry * parent)
{
while ((found = select_parent(parent, &dispose)) != 0)
shrink_dentry_list(&dispose);
}
select_parent() populates the dispose list with dentries which
shrink_dentry_list() then deletes. select_parent() carefully uses
need_resched() to avoid doing too much work at once. But neither
shrink_dcache_parent() nor its called functions call cond_resched().
So once need_resched() is set select_parent() will return single
dentry dispose list which is then deleted by shrink_dentry_list().
This is inefficient when there are a lot of dentry to process. This
can cause softlockup and hurts interactivity on non preemptable
kernels.
This change adds cond_resched() in shrink_dcache_parent(). The
benefit of this is that need_resched() is quickly cle
Re: [PATCH 03/10] soft-offline: use migrate_pages() instead of migrate_huge_page()
On Mon, Mar 25, 2013 at 01:31:28PM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:48, Naoya Horiguchi wrote:
> > Currently migrate_huge_page() takes a pointer to a hugepage to be
> > migrated as an argument, instead of taking a pointer to the list of
> > hugepages to be migrated. This behavior was introduced in commit
> > 189ebff28 ("hugetlb: simplify migrate_huge_page()"), and was OK
> > because until now hugepage migration is enabled only for soft-offlining
> > which takes only one hugepage in a single call.
> >
> > But the situation will change in the later patches in this series
> > which enable other users of page migration to support hugepage migration.
> > They can kick migration for both of normal pages and hugepages
> > in a single call, so we need to go back to original implementation
> > of using linked lists to collect the hugepages to be migrated.
>
> If the purpose of this patch is to reduce code duplication then you
> should remove migrate_huge_page as it doesn't have any caller anymore.
Yes, that makes sense. I'll do this.
> [...]
> > @@ -1482,12 +1483,20 @@ static int soft_offline_huge_page(struct page
> > *page, int flags)
> > unlock_page(hpage);
> >
> > /* Keep page count to indicate a given hugepage is isolated. */
> > - ret = migrate_huge_page(hpage, new_page, MPOL_MF_MOVE_ALL,
> > - MIGRATE_SYNC);
> > - put_page(hpage);
> > + list_move(&hpage->lru, &pagelist);
> > + ret = migrate_pages(&pagelist, new_page, MPOL_MF_MOVE_ALL,
> > + MIGRATE_SYNC, MR_MEMORY_FAILURE);
> > if (ret) {
> > pr_info("soft offline: %#lx: migration failed %d, type %lx\n",
> > pfn, ret, page->flags);
> > + /*
> > +* We know that soft_offline_huge_page() tries to migrate
> > +* only one hugepage pointed to by hpage, so we need not
> > +* run through the pagelist here.
> > +*/
> > + putback_active_hugepage(hpage);
>
> Maybe I am missing something but why we didn't need to call this before
> when using migrate_huge_page?
migrate_huge_page() does not need list handling before/after the call,
because it's defined to migrate only one hugepage, and it has a page as
an argument, not list_head.
> > + if (ret > 0)
> > + ret = -EIO;
> > } else {
> > set_page_hwpoison_huge_page(hpage);
> > dequeue_hwpoisoned_huge_page(hpage);
> > diff --git v3.9-rc3.orig/mm/migrate.c v3.9-rc3/mm/migrate.c
> > index f69f354..66030b6 100644
> > --- v3.9-rc3.orig/mm/migrate.c
> > +++ v3.9-rc3/mm/migrate.c
> > @@ -981,6 +981,8 @@ static int unmap_and_move_huge_page(new_page_t
> > get_new_page,
> >
> > unlock_page(hpage);
> > out:
> > + if (rc != -EAGAIN)
> > + putback_active_hugepage(hpage);
>
> And why do you put it here? If it is called from migrate_pages then the
> caller already does the clean-up (putback_lru_pages).
What the caller of migrate_pages() cleans up is the (huge)pages which failed
to be migrated. And what the above code cleans up is the source hugepage
after the migration succeeds.
The latter clean-up code originally existed, but removed in 189ebff28
("hugetlb: simplify migrate_huge_page()").
This commit cleans up the code based on that there was only one user
of hugepage migration, but that's not true any more.
So the above hunk is a part of revert of the commit.
But it's not a simple revert, because there's one difference between
now and before 189ebff28 that we link hugepages in-use to hugepage_activelist.
Then we finally come to the above change.
Thanks,
Naoya
> > put_page(new_hpage);
> > if (result) {
> > if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clocksource: Fix build error when !CONFIG_CLKSRC_OF
Fix below build error:
CC drivers/clocksource/exynos_mct.o
drivers/clocksource/exynos_mct.c:557:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '__unused'
drivers/clocksource/exynos_mct.c:558:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '__unused'
make[2]: *** [drivers/clocksource/exynos_mct.o] Error 1
make[1]: *** [drivers/clocksource] Error 2
make: *** [drivers] Error 2
This build error is introduced by commit 4d10f054
"clocksource: make CLOCKSOURCE_OF_DECLARE type safe".
Signed-off-by: Axel Lin
---
include/linux/clocksource.h |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index ac33184..b84a2f3 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -344,11 +344,7 @@ extern void clocksource_of_init(void);
.data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
#else
static inline void clocksource_of_init(void) {}
-#define CLOCKSOURCE_OF_DECLARE(name, compat, fn) \
- static const struct of_device_id __clksrc_of_table_##name \
- __unused __section(__clksrc_of_table) \
-= { .compatible = compat, \
-.data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
+#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)
#endif
#endif /* _LINUX_CLOCKSOURCE_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] migrate: make core migration code aware of hugepage
On Mon, Mar 25, 2013 at 11:57:01AM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:47, Naoya Horiguchi wrote:
...
> > diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> > index 98a478e..a787c44 100644
> > --- v3.9-rc3.orig/mm/hugetlb.c
> > +++ v3.9-rc3/mm/hugetlb.c
> > @@ -48,7 +48,8 @@ static unsigned long __initdata
> > default_hstate_max_huge_pages;
> > static unsigned long __initdata default_hstate_size;
> >
> > /*
> > - * Protects updates to hugepage_freelists, nr_huge_pages, and
> > free_huge_pages
> > + * Protects updates to hugepage_freelists, hugepage_activelist,
> > nr_huge_pages,
> > + * free_huge_pages, and surplus_huge_pages.
> > */
>
> Could you get this out into a separate patch and add lockdep assertions
> to functions which do not lock it directly but they rely on it so that
> the locking is more clear?
> e.g. dequeue_huge_page_node, update_and_free_page, try_to_free_low, ...
OK, I'll try it.
> It would a nice cleanup and a lead for future when somebody tries to
> make the locking a bit saner.
>
...
> > @@ -1056,6 +1064,20 @@ int migrate_pages(struct list_head *from, new_page_t
> > get_new_page,
> > return rc;
> > }
> >
> > +int migrate_movable_pages(struct list_head *from, new_page_t get_new_page,
> > + unsigned long private,
> > + enum migrate_mode mode, int reason)
> > +{
> > + int err = 0;
> > +
> > + if (!list_empty(from)) {
> > + err = migrate_pages(from, get_new_page, private, mode, reason);
> > + if (err)
> > + putback_movable_pages(from);
> > + }
> > + return err;
> > +}
> > +
>
> There doesn't seem to be any caller for this function. Please move it to
> the patch which uses it.
I would do like that if there's only one user of this function, but I thought
that it's better to separate this part as changes of common code
because this function is commonly used by multiple users which are added by
multiple patches later in this series.
I mean doing like
Patch 1: core change
Patch 2: user A (depend on patch 1)
Patch 3: user B (depend on patch 1)
Patch 4: user C (depend on patch 1)
is a bit cleaner and easier in bisecting than doing like
Patch 1: core change + user A
Patch 2: user B (depend on patch 1)
Patch 3: user C (depend on patch 1)
. I'm not sure which is standard or well-accepted way.
Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ia64 idle: delete (*idle)()
From: Len Brown
3e7fc708eb (ia64 idle: delete pm_idle) in 3.9-rc1
didn't finish the job, leaving an un-initialized
reference to (*idle)().
Reported-by: Lars-Peter Clausen
Signed-off-by: Len Brown
---
arch/ia64/kernel/process.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index e34f565..6f7dc8b 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -291,7 +291,6 @@ cpu_idle (void)
}
if (!need_resched()) {
- void (*idle)(void);
#ifdef CONFIG_SMP
min_xtp();
#endif
@@ -299,9 +298,7 @@ cpu_idle (void)
if (mark_idle)
(*mark_idle)(1);
- if (!idle)
- idle = default_idle;
- (*idle)();
+ default_idle();
if (mark_idle)
(*mark_idle)(0);
#ifdef CONFIG_SMP
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] migrate: add migrate_entry_wait_huge()
On Mon, Mar 25, 2013 at 11:13:40AM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:46, Naoya Horiguchi wrote:
> > When we have a page fault for the address which is backed by a hugepage
> > under migration, the kernel can't wait correctly until the migration
> > finishes. This is because pte_offset_map_lock() can't get a correct
> > migration entry for hugepage. This patch adds migration_entry_wait_huge()
> > to separate code path between normal pages and hugepages.
>
> The changelog is missing a description what is the effect of the bug. I
> assume that we end up busy looping on the huge page page fault until
> migration finishes, right?
Right. I'll add it in the description.
> Should this be applied to the stable tree or the current usage of the huge
> page migration (HWPOISON) is not spread enough?
Yes, it's better to also send it to stable.
> I like how you got rid of the duplication but I think this still doesn't
> work for all archs/huge page sizes.
>
> [...]
> > diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> > index 0a0be33..98a478e 100644
> > --- v3.9-rc3.orig/mm/hugetlb.c
> > +++ v3.9-rc3/mm/hugetlb.c
> > @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
> > vm_area_struct *vma,
> > if (ptep) {
> > entry = huge_ptep_get(ptep);
> > if (unlikely(is_hugetlb_entry_migration(entry))) {
> > - migration_entry_wait(mm, (pmd_t *)ptep, address);
> > + migration_entry_wait_huge(mm, (pmd_t *)ptep, address);
>
> e.g. ia64 returns pte_t *
We need arch-independent fix.
> [...]
> > +void migration_entry_wait_huge(struct mm_struct *mm, pmd_t *pmd,
> > + unsigned long address)
> > +{
> > + spinlock_t *ptl = pte_lockptr(mm, pmd);
> > + __migration_entry_wait(mm, (pte_t *)pmd, ptl);
>
> So you are trying to get lockptr from pmd but you have pte in fact. No
> biggy for !USE_SPLIT_PTLOCKS but doesn't work otherwise. So you probably
> need a arch specific huge_pte_lockptr callback for USE_SPLIT_PTLOCKS.
I must fix it, thanks.
And it might be good to generalize the idea of USE_SPLIT_PTLOCKS to pud and pmd.
> Or am I missing something here? All the pte usage in hugetlb is one
> giant mess and I wouldn't be surprised if there were more places
> hardcoded to pmd there.
Yes, that's a big problem on hugetlb and we need many clean-ups.
Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq
On 26 March 2013 07:30, Viresh Kumar wrote: > On 25 March 2013 22:37, David Miller wrote: >> From: Viresh Kumar >> Date: Mon, 25 Mar 2013 22:24:44 +0530 >> >>> This patch moves cpufreq driver of SPARK architecture to drivers/cpufreq. >> >> I don't know what spark is. > > :( > > s/spark/sparc ... > > I will fix patch in V2.. Mistake was done in code too and not only log :) Here is re-spin of this patch (attached too in case you want to test): From: Viresh Kumar Date: Mon, 25 Mar 2013 11:20:23 +0530 Subject: [PATCH] sparc: cpufreq: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq. Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: Viresh Kumar --- arch/sparc/Kconfig | 23 -- arch/sparc/kernel/Makefile | 3 --- drivers/cpufreq/Kconfig| 23 ++ drivers/cpufreq/Makefile | 2 ++ .../cpufreq/sparc-us2e-cpufreq.c | 0 .../cpufreq/sparc-us3-cpufreq.c| 0 6 files changed, 25 insertions(+), 26 deletions(-) rename arch/sparc/kernel/us2e_cpufreq.c => drivers/cpufreq/sparc-us2e-cpufreq.c (100%) rename arch/sparc/kernel/us3_cpufreq.c => drivers/cpufreq/sparc-us3-cpufreq.c (100%) diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 289127d..52e7680 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -260,29 +260,6 @@ config HOTPLUG_CPU if SPARC64 source "drivers/cpufreq/Kconfig" - -config US3_FREQ - tristate "UltraSPARC-III CPU Frequency driver" - depends on CPU_FREQ - select CPU_FREQ_TABLE - help - This adds the CPUFreq driver for UltraSPARC-III processors. - - For details, take a look at . - - If in doubt, say N. - -config US2E_FREQ - tristate "UltraSPARC-IIe CPU Frequency driver" - depends on CPU_FREQ - select CPU_FREQ_TABLE - help - This adds the CPUFreq driver for UltraSPARC-IIe processors. - - For details, take a look at . - - If in doubt, say N. - endif config US3_MC diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile index 6cf591b..5276fd4 100644 --- a/arch/sparc/kernel/Makefile +++ b/arch/sparc/kernel/Makefile @@ -102,9 +102,6 @@ obj-$(CONFIG_PCI_MSI)+= pci_msi.o obj-$(CONFIG_COMPAT) += sys32.o sys_sparc32.o signal32.o -# sparc64 cpufreq -obj-$(CONFIG_US3_FREQ) += us3_cpufreq.o -obj-$(CONFIG_US2E_FREQ) += us2e_cpufreq.o obj-$(CONFIG_US3_MC)+= chmc.o obj-$(CONFIG_KPROBES) += kprobes.o diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 602d5db..a1488f5 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -258,6 +258,29 @@ depends on PPC32 || PPC64 source "drivers/cpufreq/Kconfig.powerpc" endmenu +menu "SPARC CPU frequency scaling drivers" +depends on SPARC64 +config SPARC_US3_CPUFREQ + tristate "UltraSPARC-III CPU Frequency driver" + select CPU_FREQ_TABLE + help + This adds the CPUFreq driver for UltraSPARC-III processors. + + For details, take a look at . + + If in doubt, say N. + +config SPARC_US2E_CPUFREQ + tristate "UltraSPARC-IIe CPU Frequency driver" + select CPU_FREQ_TABLE + help + This adds the CPUFreq driver for UltraSPARC-IIe processors. + + For details, take a look at . + + If in doubt, say N. +endmenu + menu "SH CPU Frequency scaling" depends on SUPERH config SH_CPU_FREQ diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index ab3a054..050bd0c 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -85,4 +85,6 @@ obj-$(CONFIG_ETRAXFS) += cris-etraxfs-cpufreq.o obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o obj-$(CONFIG_SH_CPU_FREQ) += sh-cpufreq.o +obj-$(CONFIG_SPARC_US2E_CPUFREQ) += sparc-us2e-cpufreq.o +obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o obj-$(CONFIG_UNICORE32)+= unicore2-cpufreq.o diff --git a/arch/sparc/kernel/us2e_cpufreq.c b/drivers/cpufreq/sparc-us2e-cpufreq.c similarity index 100% rename from arch/sparc/kernel/us2e_cpufreq.c rename to drivers/cpufreq/sparc-us2e-cpufreq.c diff --git a/arch/sparc/kernel/us3_cpufreq.c b/drivers/cpufreq/sparc-us3-cpufreq.c similarity index 100% rename from arch/sparc/kernel/us3_cpufreq.c rename to drivers/cpufreq/sparc-us3-cpufreq.c 0001-sparc-cpufreq-move-cpufreq-driver-to-drivers-cpufreq.patch Description: Binary data
Re: [PATCH 05/15] KDB: add more exports for supporting KDB modules v2
On 3/25/2013 7:38 PM, Eric W. Biederman wrote:
> Mike Travis writes:
>
>> This patch adds some significant KDB functions to be usable by
>> externally built and loadable KDB modules. All added functions
>> have been marked EXPORT_SYMBOL_GPL as that seems to be the norm.
>> No 'EXPORT_SYMBOL's were changed from previous instances to avoid
>> breaking existing modules.
>
> I don't have any real objections. Although the export of kallsyms
> probably is enough to raise an eyebrow or two.
>
> Are there plans for these external modules to be merged?
>
> In general the policy is to not export things unless there are in tree
> users. Otherwise maitenance can be a challenge if you can't update your
> users when you update their helper functions. Certainly a symbol being
> exported is not a guarantee that the exported function won't be changed.
>
> Eric
I have a few of the older KDB modules converted to be built as
regular external kernel modules but I wasn't certain if they would be
accepted into the base kernel source tree. Both kdbm_dereference.c
and kdbm_debugtypes.c are there which support the following kdb cmds:
"print", "", "Type casting as in lcrash"
"px", "", "Print in hex (type casting) (see 'pxhelp')"
"whatis", or symbol>", "Display the type, or the address for a symbol"
"sizeof", "", "Display the size of a structure, typedef, etc."
"pxhelp", "", "Display help for the px command"
"walk", "", "Walk linked structs (see walkhelp)",
"walkhelp", "", "Display help for the walk command"
These essentially use the kernel symtab to print structure members,
and to walk linked structures from within KDB. That was the primary
motivation for moving the ksymtab stuff to be externally exported.
It currently has a couple of problems but here's an example:
[8]kdb> md8c1 kdb_current_task
0x81c8ed00 88081d714bf0.Kq.
[8]kdb> px *(task_struct *)0x88081d714bf0
struct task_struct {
state = 0x0
stack = 0x88081d71a000
usage = atomic_t {
counter = 0x2
}
flags = 0x10202040
ptrace = 0x0
wake_entry = struct llist_node {
next = (nil)
}
...
(First 'kdb_current_task' should have been taken as the argument to
the px cmd, and second the printout does not stop with 'q' to the
"more>" prompt.) I will sign up to merge these if there is interest?
Thanks,
Mike
>
>> Cc: Tim Bird
>> Cc: Anton Vorontsov
>> Cc: Sasha Levin
>> Cc: Rusty Russell
>> Cc: Greg Kroah-Hartman
>> Cc: Cong Wang
>> Cc: Stephen Boyd
>> Cc: Al Viro
>> Cc: Oleg Nesterov
>> Cc: Eric W. Biederman
>> Cc: Serge Hallyn
>> Reviewed-by: Dimitri Sivanich
>> Signed-off-by: Mike Travis
>> ---
>> v2: change in handling of EXPORT_SYMBOLS.
>> ---
>> kernel/debug/kdb/kdb_io.c |3 +++
>> kernel/debug/kdb/kdb_main.c| 14 ++
>> kernel/debug/kdb/kdb_support.c | 17 +
>> kernel/kallsyms.c |1 +
>> 4 files changed, 35 insertions(+)
>>
>> --- linux.orig/kernel/debug/kdb/kdb_io.c
>> +++ linux/kernel/debug/kdb/kdb_io.c
>> @@ -30,6 +30,7 @@
>> char kdb_prompt_str[CMD_BUFLEN];
>>
>> int kdb_trap_printk;
>> +EXPORT_SYMBOL_GPL(kdb_trap_printk);
>>
>> static int kgdb_transition_check(char *buffer)
>> {
>> @@ -447,6 +448,7 @@ char *kdb_getstr(char *buffer, size_t bu
>> kdb_nextline = 1; /* Prompt and input resets line number */
>> return kdb_read(buffer, bufsize);
>> }
>> +EXPORT_SYMBOL_GPL(kdb_getstr);
>>
>> /*
>> * kdb_input_flush
>> @@ -839,6 +841,7 @@ kdb_print_out:
>> preempt_enable();
>> return retlen;
>> }
>> +EXPORT_SYMBOL_GPL(vkdb_printf);
>>
>> int kdb_printf(const char *fmt, ...)
>> {
>> --- linux.orig/kernel/debug/kdb/kdb_main.c
>> +++ linux/kernel/debug/kdb/kdb_main.c
>> @@ -53,6 +53,7 @@ int kdb_grep_trailing;
>> * Kernel debugger state flags
>> */
>> int kdb_flags;
>> +EXPORT_SYMBOL_GPL(kdb_flags);
>> atomic_t kdb_event;
>>
>> /*
>> @@ -60,12 +61,14 @@ atomic_t kdb_event;
>> * single thread processors through the kernel debugger.
>> */
>> int kdb_initial_cpu = -1; /* cpu number that owns kdb */
>> +EXPORT_SYMBOL_GPL(kdb_initial_cpu);
>> int kdb_nextline = 1;
>> int kdb_state; /* General KDB state */
>>
>> struct task_struct *kdb_current_task;
>> EXPORT_SYMBOL(kdb_current_task);
>> struct pt_regs *kdb_current_regs;
>> +EXPORT_SYMBOL_GPL(kdb_current_regs);
>>
>> const char *kdb_diemsg;
>> static int kdb_go_count;
>> @@ -186,6 +189,7 @@ struct task_struct *kdb_curr_task(int cp
>> #endif
>> return p;
>> }
>> +EXPORT_SYMBOL_GPL(kdb_curr_task);
>>
>> /*
>> * kdbgetenv - This function will return the character string value of
>> @@ -217,6 +221,7 @@ char *kdbgetenv(const char *match
linux-next: build failure after merge of the char-misc tree
Hi all,
After merging the char-misc tree, today's linux-next build
(x86_64_allmodconfig) failed like this:
drivers/input/keyboard/pmic8xxx-keypad.c:24:35: fatal error:
linux/mfd/pm8xxx/gpio.h: No such file or directory
Caused by commit e44b0ceee4cc ("add single-wire serial bus interface
(SSBI) driver") which added the Kconfig symbol MSM_SSBI (later changed to
just SSBI) which did not exist in the tree before. However,
MFD_PM8921_CORE depended on it and that selects MFD_PM8XXX which allows
the above file to build (and fail).
I have used the char-misc tree from next-20130325 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpiUi9N76tH1.pgp
Description: PGP signature
Re: [PATCH] powerpc: remove two lines of dead code
On Mon, Mar 25, 2013 at 11:32:11AM +0100, Paul Bolle wrote:
> Commit c1fb6816fb1b78dd94b673b0fdaa9a7a16e97bd1 ("powerpc: Add
> relocation on exception vector handlers") added two lines of code that
> depend on the macro CONFIG_HVC_SCOM. That macro doesn't exist. Perhaps
> it was intended to use CONFIG_PPC_SCOM here. But since
> "maintence_interrupt" is a typo and there's nothing in arch/powerpc that
> looks like maintenance_interrupt it seems best to just delete these
> lines.
It's cruft from our internal tree that snuck into the patch. I was
meaning to remove it but you beat me to it.
Acked-by: Michael Ellerman
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 v1] the recommended crash memory reservation is too small for x86_64.
On 03/25/2013 07:52 PM, 周洲仪 wrote: > Thanks for reviewing > Is it sounds good to add following line into section "Boot into System > Kernel": > > The memory reserved for crash kernel should be no less than the unpacked > init ram disk size > that loaded with dump-capture kernel plus wired memory used by kernel itself. Sorry, that is just basic knowledge for everyone. > > # > After all, I have been trapped into "hang after capture" problem when > sticking strictly to this document. > Cheers > Zhouyi > >> >> On 03/25/2013 06:56 PM, zhouzho...@gmail.com wrote: >> > From: root >> > >> > >> > On Documentation/kdump/kdump.txt, section Boot into System Kernel: On >> x86 and x86_64, use >> > "crashkernel=64M@16M", but some OSes like ubuntu 12.10 use ram fs larger >> than 64M, so in these cases the >> > memory reserved for crashkernel should be at least 128M. >> >> People use different initramfs generators for different purpose. That means >> the size of initramfs and also its memory consuming can vary very much from >> each other. You just can't list all these generators and their recommended >> reserved memory here. Though I have to say crashkernel=128M is good choice. >> >> I think it would be better to leave this to user or distribution itself to >> determine how much memory should be reserved for crash kernel, then export >> this value to kernel in some ways. >> >> Thanks, >> WANG Chao >> >> > >> > >> > Signed-off-by: Zhouyi Zhou >> > --- >> > Documentation/kdump/kdump.txt |4 +++- >> > 1 file changed, 3 insertions(+), 1 deletion(-) >> > >> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >> > index 13f1aa0..1e850e0 100644 >> > --- a/Documentation/kdump/kdump.txt >> > +++ b/Documentation/kdump/kdump.txt >> > @@ -290,7 +290,9 @@ Boot into System Kernel >> > "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of >> memory >> > starting at physical address 0x0100 (16MB) for the dump-capture >> kernel. >> > >> > - On x86 and x86_64, use "crashkernel=64M@16M". >> > + On x86 and x86_64, use "crashkernel=64M@16M" (some OSes use init ram >> fs larger >> > +than 64M, for example ubuntu-12.10, use crashkernel=128M@16M instead, or >> dump-capture >> > +kernel will out of memory). >> > >> > On ppc64, use "crashkernel=128M@32M". >> > >> > >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the usb tree with the tty tree
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/serial/usb-serial.c between commit 6aad04f21374 ("TTY: add
tty_port_tty_wakeup helper") from the tty tree and commit d12e211d4484
("USB: serial: clean up debug info") from the usb tree.
I fixed it up (I just used the version of usb_serial_port_work() from the
tty tree - see below) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/usb/serial/usb-serial.c
index 2f60474,5eb96df..000
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@@ -542,11 -538,19 +538,11 @@@ static void usb_serial_port_work(struc
{
struct usb_serial_port *port =
container_of(work, struct usb_serial_port, work);
- struct tty_struct *tty;
- tty = tty_port_tty_get(&port->port);
- if (!tty)
- return;
-
- dev_dbg(tty->dev, "%s\n", __func__);
-
- tty_wakeup(tty);
- tty_kref_put(tty);
+ tty_port_tty_wakeup(&port->port);
}
- static void kill_traffic(struct usb_serial_port *port)
+ static void usb_serial_port_poison_urbs(struct usb_serial_port *port)
{
int i;
pgpUCEGNenYTy.pgp
Description: PGP signature
[PATCH] ptp_pch: eliminate a number of sparse warnings
From: Sahara
This fixes a number of sparse warnings like:
warning: incorrect type in argument 2 (different address spaces)
expected void volatile [noderef] *addr
got unsigned int *
warning: Using plain integer as NULL pointer
Additionally this fixes a warning from checkpatch.pl like:
WARNING: sizeof pch_param.station should be sizeof(pch_param.station)
Signed-off-by: Sahara
---
drivers/ptp/ptp_pch.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index 1367655..d1adb19 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -118,7 +118,7 @@ struct pch_ts_regs {
* struct pch_dev - Driver private data
*/
struct pch_dev {
- struct pch_ts_regs *regs;
+ struct pch_ts_regs __iomem *regs;
struct ptp_clock *ptp_clock;
struct ptp_clock_info caps;
int exts0_enabled;
@@ -154,7 +154,7 @@ static inline void pch_eth_enable_set(struct pch_dev *chip)
iowrite32(val, (&chip->regs->ts_sel));
}
-static u64 pch_systime_read(struct pch_ts_regs *regs)
+static u64 pch_systime_read(struct pch_ts_regs __iomem *regs)
{
u64 ns;
u32 lo, hi;
@@ -169,7 +169,7 @@ static u64 pch_systime_read(struct pch_ts_regs *regs)
return ns;
}
-static void pch_systime_write(struct pch_ts_regs *regs, u64 ns)
+static void pch_systime_write(struct pch_ts_regs __iomem *regs, u64 ns)
{
u32 hi, lo;
@@ -315,7 +315,7 @@ int pch_set_station_address(u8 *addr, struct pci_dev *pdev)
struct pch_dev *chip = pci_get_drvdata(pdev);
/* Verify the parameter */
- if ((chip->regs == 0) || addr == (u8 *)NULL) {
+ if ((chip->regs == NULL) || addr == (u8 *)NULL) {
dev_err(&pdev->dev,
"invalid params returning PCH_INVALIDPARAM\n");
return PCH_INVALIDPARAM;
@@ -361,7 +361,7 @@ EXPORT_SYMBOL(pch_set_station_address);
static irqreturn_t isr(int irq, void *priv)
{
struct pch_dev *pch_dev = priv;
- struct pch_ts_regs *regs = pch_dev->regs;
+ struct pch_ts_regs __iomem *regs = pch_dev->regs;
struct ptp_clock_event event;
u32 ack = 0, lo, hi, val;
@@ -415,7 +415,7 @@ static int ptp_pch_adjfreq(struct ptp_clock_info *ptp, s32
ppb)
u32 diff, addend;
int neg_adj = 0;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
- struct pch_ts_regs *regs = pch_dev->regs;
+ struct pch_ts_regs __iomem *regs = pch_dev->regs;
if (ppb < 0) {
neg_adj = 1;
@@ -438,7 +438,7 @@ static int ptp_pch_adjtime(struct ptp_clock_info *ptp, s64
delta)
s64 now;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
- struct pch_ts_regs *regs = pch_dev->regs;
+ struct pch_ts_regs __iomem *regs = pch_dev->regs;
spin_lock_irqsave(&pch_dev->register_lock, flags);
now = pch_systime_read(regs);
@@ -455,7 +455,7 @@ static int ptp_pch_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
u32 remainder;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
- struct pch_ts_regs *regs = pch_dev->regs;
+ struct pch_ts_regs __iomem *regs = pch_dev->regs;
spin_lock_irqsave(&pch_dev->register_lock, flags);
ns = pch_systime_read(regs);
@@ -472,7 +472,7 @@ static int ptp_pch_settime(struct ptp_clock_info *ptp,
u64 ns;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
- struct pch_ts_regs *regs = pch_dev->regs;
+ struct pch_ts_regs __iomem *regs = pch_dev->regs;
ns = ts->tv_sec * 10ULL;
ns += ts->tv_nsec;
@@ -567,9 +567,9 @@ static void pch_remove(struct pci_dev *pdev)
free_irq(pdev->irq, chip);
/* unmap the virtual IO memory space */
- if (chip->regs != 0) {
+ if (chip->regs != NULL) {
iounmap(chip->regs);
- chip->regs = 0;
+ chip->regs = NULL;
}
/* release the reserved IO memory space */
if (chip->mem_base != 0) {
@@ -670,7 +670,7 @@ pch_probe(struct pci_dev *pdev, const struct pci_device_id
*id)
err_req_irq:
ptp_clock_unregister(chip->ptp_clock);
iounmap(chip->regs);
- chip->regs = 0;
+ chip->regs = NULL;
err_ioremap:
release_mem_region(chip->mem_base, chip->mem_size);
@@ -723,7 +723,8 @@ static s32 __init ptp_pch_init(void)
module_init(ptp_pch_init);
module_exit(ptp_pch_exit);
-module_param_string(station, pch_param.station, sizeof pch_param.station,
0444);
+module_param_string(station,
+pch_param.station, sizeof(pch_param.station), 0444);
MODULE_PARM_DESC(station,
"IEEE 1588 station address to use - column separated hex values");
--
1.7.1
--
To unsubscribe from thi
RE: [PATCH 09/16] ia64 idle: delete pm_idle
> > - idle = pm_idle; > > if (!idle) > > Hm, if I'm not mistaken idle will uninitialized at this point, so this > could quite likely lead to a crash. thanks, will fix. -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'
On 2013年03月26日 10:47, Nicolas Pitre wrote: > On Tue, 26 Mar 2013, Chen Gang wrote: > >> a hacker may find something "valuable" with the aid of compiler ;-) >> >> maybe, it is a patch which is too minor to apply. I can understand :-) > > You should send such patches to Jiri Kosina . > ok > > Nicolas > > -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: remove CONFIG_GENERIC_FIND_NEXT_BIT again
> CONFIG_GENERIC_FIND_NEXT_BIT was removed in v3.0, but reappeared in two
> architectures. Remove it again.
>
> Signed-off-by: Paul Bolle
> ---
> 0) Untested.
>
> 1) See commit 63e424c84429903c92a0f1e9654c31ccaf6694d0 ("arch: remove
> CONFIG_GENERIC_FIND_{NEXT_BIT,BIT_LE,LAST_BIT}") for the removal of this
> Kconfig symbol.
>
> 2) Sent as one patch. Feel free to tell me to split it up in two
> patches.
>
> arch/hexagon/Kconfig | 3 ---
> arch/openrisc/Kconfig | 3 ---
> 2 files changed, 6 deletions(-)
>
I'd be fine pulling these into my tree to go with my next batch of
changes, or the OpenRISC folks can if they want. Ack would be nice.
Just in case:
Acked-by: Richard Kuo
Thanks,
Richard Kuo
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'
On Tue, 26 Mar 2013, Chen Gang wrote: > a hacker may find something "valuable" with the aid of compiler ;-) > > maybe, it is a patch which is too minor to apply. I can understand :-) You should send such patches to Jiri Kosina . Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] sched: wake-affine throttle
On 03/25/2013 10:31 PM, Mike Galbraith wrote: [snip] >> >> Do you mean 1ms interval is still too big? and you prefer to have a 0 >> option? > > Not really, I just think a fixed interval may not be good enough without > some idle time consideration. Once a single load gets going less > balancing is more, it's just when load is fluctuating a lot, and mixed > loads where I can imagine troubles. > > Perhaps ramp up to knob interval after an idle period trigger of.. say > migration_cost, or whatever. Something dirt simple that makes it open > the gates when it's most likely to matter. > So a dynamically adjustment, sounds attractively ;-) However, IMHO, I don't think we could be able to figure out when to adjust and how to adjust, actually we even don't have the data to count on, otherwise, there is no necessary to throttle the wake-affine stuff at all... May be do such work in user space will be better? This knob is nothing but compromise, besides, it's a highlight to notify us we still have a feature waiting for improve, if later we have the way to build an accurate wake-affine, remove the knob should be easy. Regards, Michael Wang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/5] PCI/AER: clean all untracked pci_ops_aer when rmmod aer_inject
When we do hot plug for pci devices that were injected aer errors, some newly
created child buses'
pci_ops will be assigned to pci_ops_aer. Aer_inject module will not track these
pci_ops_aer(not
list in pci_bus_ops_list),so we should clean all of these when rmmod aer_inject
module.
Reviewed-by: Huang Ying
Signed-off-by: Yijing Wang
---
drivers/pci/pcie/aer/aer_inject.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pcie/aer/aer_inject.c
b/drivers/pci/pcie/aer/aer_inject.c
index f499f01..4777c44 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -285,6 +285,29 @@ static void pci_bus_ops_init(struct pci_bus_ops *bus_ops,
bus_ops->ops = ops;
}
+static void pci_clean_child_aer_ops(struct pci_bus *bus)
+{
+ struct pci_bus *child;
+
+ list_for_each_entry(child, &bus->children, node) {
+ if (child->ops == &pci_ops_aer)
+ pci_bus_set_ops(child, bus->ops);
+ pci_clean_child_aer_ops(child);
+ }
+}
+
+/* find pci_ops_aer from root bus, and replace it by parent bus's pci_ops.
+ * pci_ops of root bus won't be pci_ops_aer here*/
+static void clean_untracked_pci_ops_aer(void)
+{
+ struct pci_bus_ops *bus_ops;
+
+ list_for_each_entry(bus_ops, &pci_bus_ops_list, list) {
+ if (pci_is_root_bus(bus_ops->bus))
+ pci_clean_child_aer_ops(bus_ops->bus);
+ }
+}
+
static int pci_bus_set_aer_ops(struct pci_bus *bus)
{
struct pci_ops *ops;
@@ -546,6 +569,7 @@ static void __exit aer_inject_exit(void)
list_for_each_entry(bus_ops, &pci_bus_ops_list, list)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
+ clean_untracked_pci_ops_aer();
while ((bus_ops = pci_bus_ops_pop()))
kfree(bus_ops);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/5] PCI/AER: free pci_bus_ops_list and remove pci_bus_ops_pop
Rewrite pci_bus_ops_list release code for simplification, and clean
no used function pci_bus_ops_pop().
Reviewed-by: Huang Ying
Signed-off-by: Yijing Wang
---
drivers/pci/pcie/aer/aer_inject.c | 25 ++---
1 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/pcie/aer/aer_inject.c
b/drivers/pci/pcie/aer/aer_inject.c
index c5372dd..14d2c92 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -143,23 +143,6 @@ static struct pci_ops *__find_pci_bus_ops(struct pci_bus
*bus)
return __find_pci_bus_ops_parent(bus);
}
-static struct pci_bus_ops *pci_bus_ops_pop(void)
-{
- unsigned long flags;
- struct pci_bus_ops *bus_ops = NULL;
-
- spin_lock_irqsave(&inject_lock, flags);
- if (list_empty(&pci_bus_ops_list))
- bus_ops = NULL;
- else {
- struct list_head *lh = pci_bus_ops_list.next;
- list_del(lh);
- bus_ops = list_entry(lh, struct pci_bus_ops, list);
- }
- spin_unlock_irqrestore(&inject_lock, flags);
- return bus_ops;
-}
-
static u32 *find_pci_config_dword(struct aer_error *err, int where,
int *prw1cs)
{
@@ -608,7 +591,7 @@ static void __exit aer_inject_exit(void)
{
struct aer_error *err, *err_next;
unsigned long flags;
- struct pci_bus_ops *bus_ops;
+ struct pci_bus_ops *bus_ops, *tmp_ops;
bus_unregister_notifier(&pci_bus_type, &aerinj_hp_notifier);
misc_deregister(&aer_inject_device);
@@ -617,8 +600,12 @@ static void __exit aer_inject_exit(void)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
clean_untracked_pci_ops_aer();
- while ((bus_ops = pci_bus_ops_pop()))
+
+ /* free pci_bus_ops_list */
+ list_for_each_entry_safe(bus_ops, tmp_ops, &pci_bus_ops_list, list) {
+ list_del(&bus_ops->list);
kfree(bus_ops);
+ }
spin_lock_irqsave(&inject_lock, flags);
list_for_each_entry_safe(err, err_next, &einjected, list) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/5] PCI/AER: use list_for_each_entry to avoid a small race condition window
When we rmmod aer_inject module, there is a small race condition window between
pci_bus_ops_pop()
and pci_bus_set_ops() in aer_inject_exit, eg. pci_read_aer/pci_write_aer was
called between
them. So keep pci_bus_ops_list until pci_bus_set_ops complete, use
list_for_each_entry() instead of
pci_bus_ops_pop to get bus_ops.
Signed-off-by: Yijing Wang
---
drivers/pci/pcie/aer/aer_inject.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/aer/aer_inject.c
b/drivers/pci/pcie/aer/aer_inject.c
index fdab3bb..f499f01 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -543,10 +543,11 @@ static void __exit aer_inject_exit(void)
misc_deregister(&aer_inject_device);
- while ((bus_ops = pci_bus_ops_pop())) {
+ list_for_each_entry(bus_ops, &pci_bus_ops_list, list)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
+
+ while ((bus_ops = pci_bus_ops_pop()))
kfree(bus_ops);
- }
spin_lock_irqsave(&inject_lock, flags);
list_for_each_entry_safe(err, err_next, &einjected, list) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/5] PCI/AER: Fix pci_ops return NULL in pci_read/write_aer
When we injected aer errors to the pcie device by aer_inject module, pci_ops of
the pci
bus the device on will be assigned to pci_ops_aer.So if the target pci device
is a bridge, once we hot-remove and hot-add the bridge, the newly created child
bus's pci_ops
will be assigned to pci_ops_aer too.Now every access to the child bus's device
will cause the
system panic, because it will get a NULL pci_ops in pci_read_aer/pci_write_aer.
Reviewed-by: Huang Ying
Signed-off-by: Yijing Wang
Signed-off-by: Jiang Liu
Reviewed-by: Sven Dietrich
---
drivers/pci/pcie/aer/aer_inject.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pcie/aer/aer_inject.c
b/drivers/pci/pcie/aer/aer_inject.c
index 4e24cb8..fdab3bb 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -109,6 +109,26 @@ static struct aer_error *__find_aer_error_by_dev(struct
pci_dev *dev)
return __find_aer_error((u16)domain, dev->bus->number, dev->devfn);
}
+/* find pci_ops of the nearest parent bus */
+static struct pci_ops *__find_pci_bus_ops_parent(struct pci_bus *bus)
+{
+ struct pci_bus_ops *bus_ops;
+ struct pci_bus *pbus = bus->parent;
+
+ if (!pbus)
+ return NULL;
+
+ while (pbus) {
+ list_for_each_entry(bus_ops, &pci_bus_ops_list, list)
+ if (bus_ops->bus == pbus)
+ return bus_ops->ops;
+
+ pbus = pbus->parent;
+ }
+
+ return NULL;
+}
+
/* inject_lock must be held before calling */
static struct pci_ops *__find_pci_bus_ops(struct pci_bus *bus)
{
@@ -118,7 +138,9 @@ static struct pci_ops *__find_pci_bus_ops(struct pci_bus
*bus)
if (bus_ops->bus == bus)
return bus_ops->ops;
}
- return NULL;
+
+ /* can't find bus_ops, fall back to get bus_ops of parent bus */
+ return __find_pci_bus_ops_parent(bus);
}
static struct pci_bus_ops *pci_bus_ops_pop(void)
@@ -208,6 +230,7 @@ static int pci_read_aer(struct pci_bus *bus, unsigned int
devfn, int where,
}
out:
ops = __find_pci_bus_ops(bus);
+ BUG_ON(!ops);
spin_unlock_irqrestore(&inject_lock, flags);
return ops->read(bus, devfn, where, size, val);
}
@@ -243,6 +266,7 @@ int pci_write_aer(struct pci_bus *bus, unsigned int devfn,
int where, int size,
}
out:
ops = __find_pci_bus_ops(bus);
+ BUG_ON(!ops);
spin_unlock_irqrestore(&inject_lock, flags);
return ops->write(bus, devfn, where, size, val);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/5] PCI/AER: clean pci_bus_ops when related pci bus was removed
When Inject aer errors to the target pci device, a pci_bus_ops will
be allocated for the pci device's pci bus.When the pci bus was removed,
we should also release the pci_bus_ops.
Signed-off-by: Yijing Wang
Reviewed-by: Sven Dietrich
---
drivers/pci/pcie/aer/aer_inject.c | 49 -
1 files changed, 48 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pcie/aer/aer_inject.c
b/drivers/pci/pcie/aer/aer_inject.c
index 4777c44..c5372dd 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -553,9 +553,55 @@ static struct miscdevice aer_inject_device = {
.fops = &aer_inject_fops,
};
+static void aer_clean_pci_bus_ops(struct pci_dev *dev)
+{
+ unsigned long flags;
+ struct pci_bus_ops *bus_ops, *tmp_ops;
+ struct pci_bus *bus;
+ bus = dev->subordinate;
+ if (!bus)
+ return;
+
+ spin_lock_irqsave(&inject_lock, flags);
+ list_for_each_entry_safe(bus_ops, tmp_ops, &pci_bus_ops_list, list)
+ if (bus_ops->bus == bus) {
+ list_del(&bus_ops->list);
+ kfree(bus_ops);
+ break;
+ }
+ spin_unlock_irqrestore(&inject_lock, flags);
+}
+
+static int aer_hp_notify_fn(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ switch (event) {
+ case BUS_NOTIFY_DEL_DEVICE:
+ aer_clean_pci_bus_ops(to_pci_dev(data));
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block aerinj_hp_notifier = {
+ .notifier_call = &aer_hp_notify_fn,
+};
+
static int __init aer_inject_init(void)
{
- return misc_register(&aer_inject_device);
+ int ret;
+ ret = misc_register(&aer_inject_device);
+ if (ret)
+ goto out;
+
+ ret = bus_register_notifier(&pci_bus_type, &aerinj_hp_notifier);
+ if (ret)
+ misc_deregister(&aer_inject_device);
+out:
+ return ret;
}
static void __exit aer_inject_exit(void)
@@ -564,6 +610,7 @@ static void __exit aer_inject_exit(void)
unsigned long flags;
struct pci_bus_ops *bus_ops;
+ bus_unregister_notifier(&pci_bus_type, &aerinj_hp_notifier);
misc_deregister(&aer_inject_device);
list_for_each_entry(bus_ops, &pci_bus_ops_list, list)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/5] Fix aer_inject tool bug
Hi Tony, Can you pick up these bug fix patches into your ras tree? I sent them to PCI subsystem maillist, but Bjorn does not seem very interested in these aer_inject tool bug fix patches. Huang Ying is the author of aer_inject tool. And I had a long discussion with Huang Ying about these patches, and got his reviewed-by. I do not know what people are really interested in these patches, So I try to send them to you. Thank you very much! This series of patch mainly to fix the aer_inject bug described as below: -+-[:40]-+-00.0-[:41]-- | +-01.0-[:42]--+-00.0 Intel Corporation 82576 Gigabit Network Connection | | \-00.1 Intel Corporation 82576 Gigabit Network Connection | +-03.0-[:43]00.0 LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS | +-04.0-[:44]-- | +-05.0-[:45]-- | +-07.0-[:46-49]00.0-[:47-49]--+-02.0-[:48]--+-00.0 Intel Corporation 82576 Gigabit Network Connection | | | \-00.1 Intel Corporation 82576 Gigabit Network Connection | | \-04.0-[:49]--+-00.0 Intel Corporation 82576 Gigabit Network Connection | | \-00.1 Intel Corporation 82576 Gigabit Network Connection my steps: 1)modprobe aer_inject 2)inject aer errors to pcie device :48:00.0 3)modprobe pciehp 4)hot remove Network Card in slot(port :40:07.0) 5)hot add Network Card in slot(port :40:07.0) 6)system panic in step 2) the pci_ops of bus :48 and bus :40 will be assigned to pci_ops_aer in step 5) the pci_ops of the newly created bus :46 will be assigned to pci_ops_aer(inherited by parent pci_ops), but this pci_ops(:46) is not tracked in pci_bus_ops_list in aer_inject module. So every access to pci_config space by pci_ops of :46 will cause system panic, Since pci_ops_aer cannot find its original pci_ops, thus , a NULL pci_ops return; The first patch fix this bug by finding parent pci_ops(tracked in pci_ops_list) instead of returning NULL in step 5); The second patch fix a small race condition window in aer_inject_exit; The Third patch to find and clean all untracked pci_ops_aer in system when aer_inject module exit The rest two patch mainly about to clean bus_ops; Yijing Wang (5): PCI/AER: Fix pci_ops return NULL in pci_read/write_aer PCI/AER: use list_for_each_entry to avoid a small race condition window PCI/AER: clean all untracked pci_ops_aer when rmmod aer_inject PCI/AER: clean pci_bus_ops when related pci bus was removed PCI/AER: free pci_bus_ops_list and remove pci_bus_ops_pop drivers/pci/pcie/aer/aer_inject.c | 123 +++-- 1 files changed, 103 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list
On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
> On Mon, Mar 25 2013, Dave Chinner wrote:
> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
> >> Call cond_resched() from shrink_dentry_list() to preserve
> >> shrink_dcache_parent() interactivity.
> >>
> >> void shrink_dcache_parent(struct dentry * parent)
> >> {
> >>while ((found = select_parent(parent, &dispose)) != 0)
> >>shrink_dentry_list(&dispose);
> >> }
> >>
> >> select_parent() populates the dispose list with dentries which
> >> shrink_dentry_list() then deletes. select_parent() carefully uses
> >> need_resched() to avoid doing too much work at once. But neither
> >> shrink_dcache_parent() nor its called functions call cond_resched().
> >> So once need_resched() is set select_parent() will return single
> >> dentry dispose list which is then deleted by shrink_dentry_list().
> >> This is inefficient when there are a lot of dentry to process. This
> >> can cause softlockup and hurts interactivity on non preemptable
> >> kernels.
> >
> > Hi Greg,
> >
> > I can see how this coul dcause problems, but isn't the problem then
> > that shrink_dcache_parent()/select_parent() itself is mishandling
> > the need for rescheduling rather than being a problem with
> > the shrink_dentry_list() implementation? i.e. select_parent() is
> > aborting batching based on a need for rescheduling, but then not
> > doing that itself and assuming that someone else will do the
> > reschedule for it?
> >
> > Perhaps this is a better approach:
> >
> > - while ((found = select_parent(parent, &dispose)) != 0)
> > + while ((found = select_parent(parent, &dispose)) != 0) {
> > shrink_dentry_list(&dispose);
> > + cond_resched();
> > + }
> >
> > With this, select_parent() stops batching when a resched is needed,
> > we dispose of the list as a single batch and only then resched if it
> > was needed before we go and grab the next batch. That should fix the
> > "small batch" problem without the potential for changing the
> > shrink_dentry_list() behaviour adversely for other users
>
> I considered only modifying shrink_dcache_parent() as you show above.
> Either approach fixes the problem I've seen. My initial approach adds
> cond_resched() deeper into shrink_dentry_list() because I thought that
> there might a secondary benefit: shrink_dentry_list() would be willing
> to give up the processor when working on a huge number of dentry. This
> could improve interactivity during shrinker and umount. I don't feel
> strongly on this and would be willing to test and post the
> add-cond_resched-to-shrink_dcache_parent approach.
The shrinker has interactivity problems because of the global
dcache_lru_lock, not because of ithe size of the list passed to
shrink_dentry_list(). The amount of work that shrink_dentry_list()
does here is already bound by the shrinker batch size. Hence in the
absence of the RT folk complaining about significant holdoffs I
don't think there is an interactivity problem through the shrinker
path.
As for the unmount path - shrink_dcache_for_umount_subtree() - that
doesn't use shrink_dentry_list() and so would need it's own internal
calls to cond_resched(). Perhaps it's shrink_dcache_sb() that you
are concerned about? Either way, And there are lots more similar
issues in the unmount path such as evict_inodes(), so unless you are
going to give every possible path through unmount/remount/bdev
invalidation the same treatment then changing shrink_dentry_list()
won't significantly improve the interactivity of the system
situation in these paths...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/15] KDB: add more exports for supporting KDB modules v2
Mike Travis writes:
> This patch adds some significant KDB functions to be usable by
> externally built and loadable KDB modules. All added functions
> have been marked EXPORT_SYMBOL_GPL as that seems to be the norm.
> No 'EXPORT_SYMBOL's were changed from previous instances to avoid
> breaking existing modules.
I don't have any real objections. Although the export of kallsyms
probably is enough to raise an eyebrow or two.
Are there plans for these external modules to be merged?
In general the policy is to not export things unless there are in tree
users. Otherwise maitenance can be a challenge if you can't update your
users when you update their helper functions. Certainly a symbol being
exported is not a guarantee that the exported function won't be changed.
Eric
> Cc: Tim Bird
> Cc: Anton Vorontsov
> Cc: Sasha Levin
> Cc: Rusty Russell
> Cc: Greg Kroah-Hartman
> Cc: Cong Wang
> Cc: Stephen Boyd
> Cc: Al Viro
> Cc: Oleg Nesterov
> Cc: Eric W. Biederman
> Cc: Serge Hallyn
> Reviewed-by: Dimitri Sivanich
> Signed-off-by: Mike Travis
> ---
> v2: change in handling of EXPORT_SYMBOLS.
> ---
> kernel/debug/kdb/kdb_io.c |3 +++
> kernel/debug/kdb/kdb_main.c| 14 ++
> kernel/debug/kdb/kdb_support.c | 17 +
> kernel/kallsyms.c |1 +
> 4 files changed, 35 insertions(+)
>
> --- linux.orig/kernel/debug/kdb/kdb_io.c
> +++ linux/kernel/debug/kdb/kdb_io.c
> @@ -30,6 +30,7 @@
> char kdb_prompt_str[CMD_BUFLEN];
>
> int kdb_trap_printk;
> +EXPORT_SYMBOL_GPL(kdb_trap_printk);
>
> static int kgdb_transition_check(char *buffer)
> {
> @@ -447,6 +448,7 @@ char *kdb_getstr(char *buffer, size_t bu
> kdb_nextline = 1; /* Prompt and input resets line number */
> return kdb_read(buffer, bufsize);
> }
> +EXPORT_SYMBOL_GPL(kdb_getstr);
>
> /*
> * kdb_input_flush
> @@ -839,6 +841,7 @@ kdb_print_out:
> preempt_enable();
> return retlen;
> }
> +EXPORT_SYMBOL_GPL(vkdb_printf);
>
> int kdb_printf(const char *fmt, ...)
> {
> --- linux.orig/kernel/debug/kdb/kdb_main.c
> +++ linux/kernel/debug/kdb/kdb_main.c
> @@ -53,6 +53,7 @@ int kdb_grep_trailing;
> * Kernel debugger state flags
> */
> int kdb_flags;
> +EXPORT_SYMBOL_GPL(kdb_flags);
> atomic_t kdb_event;
>
> /*
> @@ -60,12 +61,14 @@ atomic_t kdb_event;
> * single thread processors through the kernel debugger.
> */
> int kdb_initial_cpu = -1;/* cpu number that owns kdb */
> +EXPORT_SYMBOL_GPL(kdb_initial_cpu);
> int kdb_nextline = 1;
> int kdb_state; /* General KDB state */
>
> struct task_struct *kdb_current_task;
> EXPORT_SYMBOL(kdb_current_task);
> struct pt_regs *kdb_current_regs;
> +EXPORT_SYMBOL_GPL(kdb_current_regs);
>
> const char *kdb_diemsg;
> static int kdb_go_count;
> @@ -186,6 +189,7 @@ struct task_struct *kdb_curr_task(int cp
> #endif
> return p;
> }
> +EXPORT_SYMBOL_GPL(kdb_curr_task);
>
> /*
> * kdbgetenv - This function will return the character string value of
> @@ -217,6 +221,7 @@ char *kdbgetenv(const char *match)
> }
> return NULL;
> }
> +EXPORT_SYMBOL_GPL(kdbgetenv);
>
> /*
> * kdballocenv - This function is used to allocate bytes for
> @@ -293,6 +298,7 @@ int kdbgetintenv(const char *match, int
> *value = (int) val;
> return diag;
> }
> +EXPORT_SYMBOL_GPL(kdbgetintenv);
>
> /*
> * kdbgetularg - This function will convert a numeric string into an
> @@ -325,6 +331,7 @@ int kdbgetularg(const char *arg, unsigne
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(kdbgetularg);
>
> int kdbgetu64arg(const char *arg, u64 *value)
> {
> @@ -344,6 +351,7 @@ int kdbgetu64arg(const char *arg, u64 *v
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(kdbgetu64arg);
>
> /*
> * kdb_set - This function implements the 'set' command. Alter an
> @@ -425,6 +433,7 @@ int kdb_set(int argc, const char **argv)
>
> return KDB_ENVFULL;
> }
> +EXPORT_SYMBOL_GPL(kdb_set);
>
> static int kdb_check_regs(void)
> {
> @@ -585,6 +594,7 @@ int kdbgetaddrarg(int argc, const char *
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(kdbgetaddrarg);
>
> static void kdb_cmderror(int diag)
> {
> @@ -1049,6 +1059,7 @@ int kdb_parse(const char *cmdstr)
> return 0;
> }
> }
> +EXPORT_SYMBOL_GPL(kdb_parse);
>
>
> static int handle_ctrl_cmd(char *cmd)
> @@ -1109,6 +1120,7 @@ void kdb_set_current_task(struct task_st
> }
> kdb_current_regs = NULL;
> }
> +EXPORT_SYMBOL_GPL(kdb_set_current_task);
>
> /*
> * kdb_local - The main code for kdb. This routine is invoked on a
> @@ -2249,6 +2261,7 @@ void kdb_ps_suppressed(void)
> kdb_printf(" suppressed,\nuse 'ps A' to see all.\n");
> }
> }
> +EXPORT_SYMBOL_GPL(kdb_ps_suppressed);
>
> /*
> * kdb_ps - This function implements the 'ps' command which shows a
> @@ -2281,6 +2294,7 @@ void kdb_ps1(const struct task_struct *p
> }
> }
Re:
-- I am Akilah Saeedi, i have 7.100,000.00 USD for you contact me on my provide email for more details. - Vidarebefordrat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'
On 2013年03月26日 09:48, Greg KH wrote: > On Tue, Mar 26, 2013 at 09:22:57AM +0800, Chen Gang wrote: >> On 2013年03月26日 07:32, Greg KH wrote: >>> On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote: better to let 'inline' in front of 'void' >>> >>> Why? What does this fix? >>> >>> >>> >> >> when I am compiling with "EXTRA_FLAGS=-W", I get a warning: > > That's not anything I really care about, sorry. No one sane builds the > kernel like that :) a hacker may find something "valuable" with the aid of compiler ;-) maybe, it is a patch which is too minor to apply. I can understand :-) thanks. > > greg k-h > > -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REPOST Patch v1 3/3] power: power_supply_core: Add support for supplied_from
Adding support for supplied_from char * array. This is meant to store the
list of suppliers for a given supply, i.e. chargers for a battery. This
list can be populated through devicetree readily as well as passed
directly from the driver.
Signed-off-by: Rhyland Klein
---
v1:
- Changed from RFC v2 -> patch v1
- removed list logic, added logic to first verify all supplies are
present and defer probe until they are.
- after all devices are registered, populate the char ** supplied_from
array which simulates the case of dt not being used.
- added of_node element to struct power_supply
v2 (RFC):
- Simplified and renamed the logic to parse dt for the charger list.
- Tied the dt parsing directly to power_supply_register to make fewer
changes required for converting existing chargers/supplies.
drivers/power/power_supply_core.c | 138 +
include/linux/power_supply.h |3 +
2 files changed, 141 insertions(+)
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index dd675ae..c1c 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -90,6 +90,133 @@ void power_supply_changed(struct power_supply *psy)
}
EXPORT_SYMBOL_GPL(power_supply_changed);
+#ifdef CONFIG_OF
+#include
+
+static int __power_supply_populate_supplied_from(struct device *dev,
+void *data)
+{
+ struct power_supply *psy = (struct power_supply *)data;
+ struct power_supply *epsy = dev_get_drvdata(dev);
+ struct device_node *np;
+ int i = 0;
+
+ do {
+ np = of_parse_phandle(psy->of_node, "power-supplies", i++);
+ if (!np)
+ continue;
+
+ if (np == epsy->of_node) {
+ dev_info(psy->dev, "%s: Found supply : %s\n",
+ psy->name, epsy->name);
+ psy->supplied_from[i-1] = (char *)epsy->name;
+ psy->num_supplies++;
+ break;
+ }
+ } while (np);
+
+ return 0;
+}
+
+int power_supply_populate_supplied_from(struct power_supply *psy)
+{
+ int error;
+
+ error = class_for_each_device(power_supply_class, NULL, psy,
+ __power_supply_populate_supplied_from);
+
+ dev_dbg(psy->dev, "%s %d\n", __func__, error);
+
+ return error;
+}
+
+static int __power_supply_find_supply_from_node(struct device *dev,
+void *data)
+{
+ struct device_node *np = (struct device_node *)data;
+ struct power_supply *epsy = dev_get_drvdata(dev);
+
+ /* return error breaks out of class_for_each_device loop */
+ if (epsy->of_node == np)
+ return -EINVAL;
+
+ return 0;
+}
+
+int power_supply_find_supply_from_node(struct device_node *supply_node)
+{
+ int error;
+ struct device *dev;
+ struct class_dev_iter iter;
+
+ /* Use iterator to see if any other device is registered.
+* This is required since class_for_each_device returns 0
+* if there are no devices registered.
+*/
+ class_dev_iter_init(&iter, power_supply_class, NULL, NULL);
+ dev = class_dev_iter_next(&iter);
+
+ if (!dev)
+ return -EPROBE_DEFER;
+
+ /* we have to treat the return value as inverted, because if
+* we return error on not found, then it won't continue looking.
+* So we trick it by returning error on success to stop looking
+* once the matching device is found.
+*/
+ error = class_for_each_device(power_supply_class, NULL, supply_node,
+ __power_supply_find_supply_from_node);
+
+ return error ? 0 : -EPROBE_DEFER;
+}
+
+int power_supply_check_supplies(struct power_supply *psy)
+{
+ struct device_node *np;
+ int cnt = 0;
+ int ret = 0;
+
+ /* If there is already a list honor it */
+ if (psy->supplied_from && psy->num_supplies > 0)
+ return 0;
+
+ /* No device node found, nothing to do */
+ if (!psy->of_node)
+ return 0;
+
+ do {
+ np = of_parse_phandle(psy->of_node, "power-supplies", cnt++);
+ if (!np)
+ continue;
+
+ ret = power_supply_find_supply_from_node(np);
+ if (ret) {
+ dev_dbg(psy->dev, "Failed to find supply, defer!\n");
+ return -EPROBE_DEFER;
+ }
+ } while (np);
+
+ /* All supplies found, allocate char ** array for filling */
+ psy->supplied_from = devm_kzalloc(psy->dev, sizeof(psy->supplied_from),
+ GFP_KERNEL);
+ if (!psy->supplied_from) {
+ dev_err(psy->dev, "Couldn't allocate memory for supply list\n
[REPOST Patch v1 1/3] power_supply: Define Binding for power-supplies
This property is meant to be used in device nodes which represent
power_supply devices that wish to provide a list of supplies which
provide them power, such as a battery listing its chargers.
Signed-off-by: Rhyland Klein
---
v1:
- changed from RFC v2 -> patch v1
- made poropery plural as it can be a list
- update example with plural & changed once charger address
v2 (RFC):
- changed property to "power-supply" which should be contained in the
battery rather than the charger. Also updated example to match
.../bindings/power_supply/power_supply.txt | 23
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/power_supply.txt
diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt
b/Documentation/devicetree/bindings/power_supply/power_supply.txt
new file mode 100644
index 000..8391bfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
@@ -0,0 +1,23 @@
+Power Supply Core Support
+
+Optional Properties:
+ - power-supplies : This property is added to a supply in order to list the
+ devices which supply it power, referenced by their phandles.
+
+Example:
+
+ usb-charger: power@e {
+ compatible = "some,usb-charger";
+ ...
+ };
+
+ ac-charger: power@c {
+ compatible = "some,ac-charger";
+ ...
+ };
+
+ battery@b {
+ compatible = "some,battery";
+ ...
+ power-supplies = <&usb-charger>, <&ac-charger>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REPOST Patch v1 2/3] power: power_supply: Add core support for supplied_from
This patch adds support for supplies to register a list of char *'s
which represent the list of supplies which supply them. This is the
opposite as the supplied_to list.
This change maintains support for supplied_to until all drivers which
make use of it already are converted.
Signed-off-by: Rhyland Klein
---
v1:
- changed from RFC v2 -> patch v1
- removed list logic and instead added supplied_from char ** array and
num_supplies field
v2 (RFC):
- changed from struct device_node * contained in suppliers to a list
stored in the supplies.
- changed logic for the is_supplied_by check to handle the entire loop
as the array structure is difference between the 2 paths.
drivers/power/power_supply_core.c | 49 +++--
include/linux/power_supply.h |3 +++
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index 5deac43..dd675ae 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -26,17 +26,44 @@ EXPORT_SYMBOL_GPL(power_supply_class);
static struct device_type power_supply_dev_type;
+static int __power_supply_is_supplied_by(struct power_supply *supplier,
+struct power_supply *supply)
+{
+ int i;
+
+ if (!supply->supplied_from && !supplier->supplied_to)
+ return -EINVAL;
+
+ /* Support both supplied_to and supplied_from modes */
+ if (supply->supplied_from) {
+ for (i = 0; i < supply->num_supplies; i++) {
+ if (!supplier->name)
+ continue;
+ if (!strcmp(supplier->name, supply->supplied_from[i]))
+ return 0;
+ }
+ } else {
+ for (i = 0; i < supplier->num_supplicants; i++) {
+ if (!supply->name)
+ continue;
+ if (!strcmp(supplier->supplied_to[i], supply->name))
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
static int __power_supply_changed_work(struct device *dev, void *data)
{
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *pst = dev_get_drvdata(dev);
- int i;
- for (i = 0; i < psy->num_supplicants; i++)
- if (!strcmp(psy->supplied_to[i], pst->name)) {
- if (pst->external_power_changed)
- pst->external_power_changed(pst);
- }
+ if (__power_supply_is_supplied_by(psy, pst)) {
+ if (pst->external_power_changed)
+ pst->external_power_changed(pst);
+ }
+
return 0;
}
@@ -68,17 +95,13 @@ static int __power_supply_am_i_supplied(struct device *dev,
void *data)
union power_supply_propval ret = {0,};
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *epsy = dev_get_drvdata(dev);
- int i;
- for (i = 0; i < epsy->num_supplicants; i++) {
- if (!strcmp(epsy->supplied_to[i], psy->name)) {
- if (epsy->get_property(epsy,
- POWER_SUPPLY_PROP_ONLINE, &ret))
- continue;
+ if (__power_supply_is_supplied_by(epsy, psy))
+ if (!epsy->get_property(epsy, POWER_SUPPLY_PROP_ONLINE, &ret)) {
if (ret.intval)
return ret.intval;
}
- }
+
return 0;
}
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 002a99f..c1cbd5e 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -171,6 +171,9 @@ struct power_supply {
char **supplied_to;
size_t num_supplicants;
+ char **supplied_from;
+ size_t num_supplies;
+
int (*get_property)(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REPOST Patch v1 0/3] Add DT Binding for Power-Supply power-supplies property
This series defines a common way for devicetree initialized power_supplies to define their relationships between chargers and supplicants. This series adds a supplied_from array to complement the supplied_to array and to allow supplies to define the list of supplies which supply them. Then once this property is supported, we can use a new property for devicetree to define the relationships between nodes, and read in this property to generate the supplied_from list. With this logic in place, all drivers need to do to add support for this mechanism, is to store their device tree node in the power_supply struct. They should also handle EPROBE_DEFER properly. Changes since: RFC v2: - Changed to official Patch set rather than RFC - defined supplied_from char ** array rather than complicated struct device_node related array RFC v1: - Inverted the logic so that supplies (batteries) contain a list of the supplies (chargers) which supply them. Rhyland Klein (3): power_supply: Define Binding for power-supplies power: power_supply: Add core support for supplied_from power: power_supply_core: Add support for supplied_from .../bindings/power_supply/power_supply.txt | 23 +++ drivers/power/power_supply_core.c | 187 ++-- include/linux/power_supply.h |6 + 3 files changed, 203 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/power_supply/power_supply.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/25/2013 05:53 PM, John Stultz wrote: > On 03/25/2013 03:36 PM, Arnd Bergmann wrote: >> On Monday 25 March 2013, Rob Herring wrote: >>> I count integrator-cp, realview, versatile and non-DT VExpress that do >>> this (not surprisingly) and 25 platforms or timer implementations plus >>> arm64 that do sched_clock setup in time_init. What's broken by not >>> moving these earlier? >> timekeeping_init() will leave the persistent_clock_exist variable as >> "false", >> which is read in rtc_suspend() and timekeeping_inject_sleeptime(). > > Are you mixing up the persistent_clock and sched_clock here? From a > generic stand-point they have different requirements. Yes. We're talking about sched_clock here. What would be the benefit of having it setup before sched_init vs. later in time_init? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 01/10] clocksource: add generic dummy timer driver
On 03/25/13 11:00, Mark Rutland wrote: > >>> I've spent the last few hours trying to get the dummy_timer driver working >>> on >>> tc2 with the sp804 as the broadcast source (with architected timer support >>> disabled). It turns out that having dummy timer's rating so low means that >>> it >>> won't be selected as the tick device on cpu0 in preference to the sp804, and >>> thus won't push the sp804 out of that spot (allowing it to become the >>> broadcast >>> source). This leads to boot stalling. >> I'm not following here. Why would we want to remove sp804 from the tick >> duty? > To run an SMP system without local timers, we need the sp804 to be the > broadcast timer. Unfortunately the tick device and broadcast timer are > mutually > exclusive positions, so we need to have a dummy timer knock the sp804 out of > tick device duty to enable broadcast. > > When the dummy timer's rating was 400 (against the sp804's 350), this worked. > The sp804 would be registered, and would become cpu0's tick device. Later the > dummy would get registered, knocking the sp804 out (whereupon it would get > cycled back through tick_check_new_device and become the broadcast timer). > > With the dummy timer's rating lower, the sp804 stays as cpu0's tick device, > all > other cpus get dummy timers, but there's no broadcast source, so the system > locks up waiting for secondary cpus. Ok. Thanks for clearing up my confusion. Like you say, increasing the dummy timer rating seems like a hack. But it also sounds like you want to keep the dummy timer driver fully self contained. I'm not opposed to calling dummy_timer_register() at the bottom of tick_init() if we have to, but it sounds like you don't like that. An alternative would be to push the dummy timer logic into the core clockevents layer under the ifdef for arch has broadcast. This is probably the correct approach because most devices don't want to have a dummy timer sitting around unused. I might be able to take a look at this tomorrow. One final question, if you remove all other CPUs besides the CPU that is servicing the sp804 interrupt do we end up in a situation where the sp804 is broadcasting to the dummy tick device? I haven't read through all the code yet for that one. I would think tick_switch_to_oneshot() would complain on your device? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull some powerpc build fixes
The following changes since commit 3912a677f68f6084e0a7b6a1a29310ac1b083713:
Merge tag 'pinctrl-fixes-for-v3.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl (2013-03-24
10:11:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes.git
tags/for-linus
for you to fetch changes up to f9294e989fa6f2990da155242db03cea1550cac8:
powerpc: define the conditions where the ePAPR idle hcall can be supported
(2013-03-26 08:47:27 +1100)
Just a couple of build fixes for powerpc all{mod,yes}config.
Submitted by me since BenH is on vacation.
Chen Gang (1):
powerpc: make additional room in exception vector area
Stuart Yoder (1):
powerpc: define the conditions where the ePAPR idle hcall can be supported
arch/powerpc/kernel/epapr_paravirt.c | 6 ++
arch/powerpc/kernel/exceptions-64s.S | 144 +--
2 files changed, 78 insertions(+), 72 deletions(-)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxnAqBmjUZM.pgp
Description: PGP signature
RE: [PATCH -next v2] mailbox: fix invalid use of sizeof in mailbox_msg_send()
> From: Wei Yongjun
>
> sizeof() when applied to a pointer typed expression gives the size of the
> pointer,
> not that of the pointed data.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/mailbox/mailbox.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index
> 5fea5c2..78e52c0 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -83,7 +83,7 @@ int mailbox_msg_send(struct mailbox *mbox, struct
> mailbox_msg *msg)
>
> mutex_lock(&mq->mlock);
>
> - if (kfifo_avail(&mq->fifo) < (sizeof(msg) + msg->size)) {
> + if (kfifo_avail(&mq->fifo) < (sizeof(*msg) + msg->size)) {
> ret = -ENOMEM;
> goto out;
> }
> @@ -93,8 +93,8 @@ int mailbox_msg_send(struct mailbox *mbox, struct
> mailbox_msg *msg)
> goto out;
> }
>
> - len = kfifo_in(&mq->fifo, (unsigned char *)msg, sizeof(msg));
> - WARN_ON(len != sizeof(msg));
> + len = kfifo_in(&mq->fifo, (unsigned char *)msg, sizeof(*msg));
> + WARN_ON(len != sizeof(*msg));
>
> if (msg->size && msg->pdata) {
> len = kfifo_in(&mq->fifo, (unsigned char *)msg->pdata,
>
Looks good, thanks. I have added this patch to my branch on github.
Regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/md/raid5.c between commit e3620a3ad526 ("MD RAID5: Avoid
accessing gendisk or queue structs when not available") from Linus' tree
and commit 2f6db2a70734 ("raid5: use bio_reset()") from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/md/raid5.c
index 24909eb,7bbd285..000
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@@ -666,16 -665,11 +665,13 @@@ static void ops_run_io(struct stripe_he
bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
bi->bi_io_vec[0].bv_offset = 0;
bi->bi_size = STRIPE_SIZE;
- bi->bi_next = NULL;
if (rrdev)
set_bit(R5_DOUBLE_LOCKED, &sh->dev[i].flags);
- trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
-bi,
disk_devt(conf->mddev->gendisk),
-sh->dev[i].sector);
+
+ if (conf->mddev->gendisk)
+
trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
+bi,
disk_devt(conf->mddev->gendisk),
+sh->dev[i].sector);
generic_make_request(bi);
}
if (rrdev) {
@@@ -700,13 -700,9 +702,10 @@@
rbi->bi_io_vec[0].bv_len = STRIPE_SIZE;
rbi->bi_io_vec[0].bv_offset = 0;
rbi->bi_size = STRIPE_SIZE;
- rbi->bi_next = NULL;
- trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
-rbi,
disk_devt(conf->mddev->gendisk),
-sh->dev[i].sector);
+ if (conf->mddev->gendisk)
+
trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
+rbi,
disk_devt(conf->mddev->gendisk),
+sh->dev[i].sector);
generic_make_request(rbi);
}
if (!rdev && !rrdev) {
pgp3v5ypUH8Mw.pgp
Description: PGP signature
Re: [PATCH 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq
On 25 March 2013 22:37, David Miller wrote: > From: Viresh Kumar > Date: Mon, 25 Mar 2013 22:24:44 +0530 > >> This patch moves cpufreq driver of SPARK architecture to drivers/cpufreq. > > I don't know what spark is. :( s/spark/sparc ... I will fix patch in V2.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [TRIVIAL] Fix typo "CONFIG_CGROUP_CGROUP_MEMCG_SWAP"
On 03/25/2013 05:59:16 PM, Paul Bolle wrote: Signed-off-by: Paul Bolle --- Documentation/cgroups/memory.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Rob Landley Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds
On 03/25/2013 03:55:28 PM, Matt Turner wrote: On Mon, Mar 25, 2013 at 1:06 PM, Michael Cree wrote: > On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote: >> >> On Mon, 25 Mar 2013, Will Deacon wrote: >>> >>> Any news on these? I've included an updated version of the first patch, >>> with >>> the Tested-by-tag and a tweaked commit message below. >> >> >> As a data point, I tried vanilla 3.8.4 on the weekend. With my >> usual config on a UP1500, it will fail at build time with >> relocation errors. If I remove -msmall-data (or replace it with >> ~big~), the machine hangs hard immediatly after aboot telling me >> it's starting it. > > > You probably want the "alpha: Add irongate_io to to PCI bus resources" patch > posted by Matt Turner in the linux-alpha forum. Looks like it has not been > sent to Linus. > > If Matt does not respond in the next day or two I'll collect patches and > send them on to Linus. Yes, please do. I haven't powered on an alpha in a few months. What would it take to add Alpha system support to qemu? (It's got userspace, but not the system management mode instructions, mmu, or a board emulation.) Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'
On Tue, Mar 26, 2013 at 09:22:57AM +0800, Chen Gang wrote: > On 2013年03月26日 07:32, Greg KH wrote: > > On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote: > >> > >> better to let 'inline' in front of 'void' > > > > Why? What does this fix? > > > > > > > > when I am compiling with "EXTRA_FLAGS=-W", I get a warning: That's not anything I really care about, sorry. No one sane builds the kernel like that :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: uio: Fix UIO device registration failure
On Tue, Mar 26, 2013 at 10:31:22AM +0900, Damian Hobson-Garcia wrote: > Until recently uio_get_minor() returned 0 for success and > a negative value on failure. This became non-negative for suceess and > negative for failure. Restore the original return value spec so that we can > successfully initialize UIO devices with a non-zero minor device > number. > > Signed-off-by: Damian Hobson-Garcia > --- > drivers/uio/uio.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Hans, don't you have a bunch of uio patches queued up for me? I've been ignoring them, thinking you are collecting them, is this not true? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: uio: Fix UIO device registration failure
Until recently uio_get_minor() returned 0 for success and
a negative value on failure. This became non-negative for suceess and
negative for failure. Restore the original return value spec so that we can
successfully initialize UIO devices with a non-zero minor device
number.
Signed-off-by: Damian Hobson-Garcia
---
drivers/uio/uio.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c8b9262..b645c47 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -374,6 +374,7 @@ static int uio_get_minor(struct uio_device *idev)
retval = idr_alloc(&uio_idr, idev, 0, UIO_MAX_DEVICES, GFP_KERNEL);
if (retval >= 0) {
idev->minor = retval;
+ retval = 0;
} else if (retval == -ENOSPC) {
dev_err(idev->dev, "too many uio devices\n");
retval = -EINVAL;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'
On 2013年03月26日 07:32, Greg KH wrote: > On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote: >> >> better to let 'inline' in front of 'void' > > Why? What does this fix? > > > when I am compiling with "EXTRA_FLAGS=-W", I get a warning: make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig choose arm-linux-gnu- for cross chain prefix. choose S5pv210 for processor type make V=1 EXTRA_CFLAGS=-W ARCH=arm the warning is: include/linux/platform_data/usb-ohci-s3c2410.h:34:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration] it is only for beautify code, not fix a bug. :-) -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: removes dynamic allocation on stack
On Mon, Mar 25 2013, Philip J. Kelleher wrote: > From: Philip J Kelleher > > This patch removes dynamic allocation on the stack error. > > Signed-off-by: Philip J Kelleher > --- > > > diff -uprN -X linux-block/Documentation/dontdiff > linux-block-vanilla/drivers/block/rsxx/dma.c > linux-block/drivers/block/rsxx/dma.c > --- linux-block-vanilla/drivers/block/rsxx/dma.c 2013-03-25 > 14:44:40.898978713 -0500 > +++ linux-block/drivers/block/rsxx/dma.c 2013-03-25 14:50:48.054969658 > -0500 > @@ -986,7 +986,10 @@ void rsxx_eeh_save_issued_dmas(struct rs > int j; > int cnt; > struct rsxx_dma *dma; > - struct list_head issued_dmas[card->n_targets]; > + struct list_head *issued_dmas; Ahem - thanks, applied :-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the wireless tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/sta_info.c between commit 27a737ff7cb0 ("mac80211: always
synchronize_net() during station removal") from the wireless tree and
commits 3b8d9c290364 ("mac80211: remove underscores from some key
functions") and 6d10e46be5ac ("mac80211: batch key free synchronize_net()")
from the wireless-next tree.
The latter seems to supercede the former, so I just used the latter and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpjxj7m3z9a3.pgp
Description: PGP signature
[PATCH] Fix child thread's introspection of /proc/self/exe
Allow threads other than the main thread to do introspection of files in
proc without relying on read permissions. proc_pid_follow_link() calls
proc_fd_access_allowed() which ultimately calls __ptrace_may_access().
Though this allows additional access to some proc files, we do not
believe that this has any unintended security implications. However it
probably needs to be looked at carefully.
The original problem was a thread of a process whose permissions were
111 couldn't open its own /proc/self/exe This was interfering with a
special purpose debugging tool. A simple reproducer is below.:
#include
#include
#include
#include
#include
#include
#define BUFSIZE 2048
void *thread_main(void *arg){
char *str=(char*)arg;
char buf[BUFSIZE];
ssize_t len=readlink("/proc/self/exe", buf, BUFSIZE);
if(len==-1)
printf("/proc/self/exe in %s: %s\n", str,sys_errlist[errno]);
else
printf("/proc/self/exe in %s: OK\n", str);
return 0;
}
int main(){
pthread_t thread;
int retval=pthread_create( &thread, NULL, thread_main, "thread");
if(retval!=0)
exit(1);
thread_main("main");
pthread_join(thread, NULL);
exit(0);
}
Signed-off-by: Ben Woodard
Signed-off-by: Mark Grondona
---
kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index acbd284..347c4c7 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -234,7 +234,7 @@ static int __ptrace_may_access(struct task_struct
*task, unsigned int mode)
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
- if (task == current)
+ if (same_thread_group(task, current))
return 0;
rcu_read_lock();
tcred = __task_cred(task);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the wireless tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/wireless/core.h between commit f9f475292dbb ("cfg80211: always check
for scan end on P2P device") from the wireless tree and commit
812569699119 ("cfg80211/mac80211: disconnect on suspend") from the
net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Stephen Rothwell
diff --cc net/wireless/core.h
index 5845c2b,d5d06fd..000
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@@ -503,9 -500,9 +500,12 @@@ int cfg80211_validate_beacon_int(struc
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
+void cfg80211_stop_p2p_device(struct cfg80211_registered_device *rdev,
+struct wireless_dev *wdev);
+
+ void cfg80211_leave(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev);
+
#define CFG80211_MAX_NUM_DIFFERENT_CHANNELS 10
#ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS
pgpYevjQdbnBx.pgp
Description: PGP signature
Re: RFC v2: Zynq Clock Controller
On Mon, Mar 25, 2013 at 07:10:35PM +0100, Lars-Peter Clausen wrote:
> On 03/25/2013 06:59 PM, Sören Brinkmann wrote:
> > Hi,
> >
> > On Mon, Mar 25, 2013 at 06:19:11PM +0100, Lars-Peter Clausen wrote:
> >> On 03/25/2013 06:08 PM, Sören Brinkmann wrote:
> >>> Hi Lars,
> >>>
> >>> On Mon, Mar 25, 2013 at 03:46:35PM +0100, Lars-Peter Clausen wrote:
> Hi,
>
> On 03/22/2013 11:41 PM, Sören Brinkmann wrote:
> > Hi Lars,
> >
> > On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote:
> >> On 03/21/2013 12:56 AM, Sören Brinkmann wrote:
> >>> Hi,
> >>>
> >>> I spent some time working on this and incorporating feedback. Here's
> >>> an updated proposal for a clock controller for Zynq:
> >>>
> >>> Required properties:
> >>> - #clock-cells : Must be 1
> >>> - compatible : "xlnx,ps7-clkc" (this may become 'xlnx,zynq-clkc'
> >>> terminology differs a bit between Xilinx internal and mainline)
> >>> - ps-clk-frequency : Frequency of the oscillator providing ps_clk in
> >>> HZ
> >>> (usually 33 MHz oscillators are used for Zynq
> >>> platforms)
> >>> - clock-output-names : List of strings used to name the clock
> >>> outputs. Shall be a list of the outputs given below.
> >>>
> >>> Optional properties:
> >>> - clocks : as described in the clock bindings
> >>> - clock-names : as described in the clock bindings
> >>>
> >>> Clock inputs:
> >>> The following strings are optional parameters to the 'clock-names'
> >>> property in
> >>> order to provide optional (E)MIO clock sources.
> >>> - swdt_ext_clk
> >>> - gem0_emio_clk
> >>> - gem1_emio_clk
> >>> - mio_clk_XX # with XX = 00..53
> >>>
> >>> Example:
> >>> clkc: clkc {
> >>> #clock-cells = <1>;
> >>> compatible = "xlnx,ps7-clkc";
> >>> ps-clk-frequency = <>;
> >>
> >> The input frequency should be a clock as well.
> > Again, monolithic vs split. I don't see a reason not to just internally
> > call clk_register_fixed_rate(). That way its children do not have to
> > cope with a variable name for the xtal.
> > Also, with my proposal 'clocks' and 'clock-names' would be purely
> > optional properties, only required if optional external inputs are
> > present. Having the xtal defined externally would add mandatory entries
> > for
> > those props.
>
>
>
> >
> >>
> >>> clock-output-names = "armpll", "ddrpll", "iopll",
> >>> "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
> >>> "dci", "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1",
> >>> "fclk2", "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1",
> >>> "spi0", "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper",
> >>> "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper",
> >>> "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper",
> >>> "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper", "swdt",
> >>> "dbg_trc", "dbg_apb"; /* long list... explanation below */
> >>> /* optional props */
> >>> clocks = <&clkc 16>, <&clk_foo>;
> >>> clock-names = "gem1_emio_clk", "can_mio_clk_23";
> >>> };
> >>>
> >>> With this revised bindings arbitrary upstream and downstream clock
> >>> providers should be supported and it's also possible to loop back an
> >>> output as input. The downside of supporting this is, that I don't see
> >>> a way around explicitly listing the clock output names in the DT.
> >>> The reason for this is, that a downstream clock provider should use
> >>> of_clk_get_parent_name() to obtain its parent clock name. For a block
> >>> with multiple outputs of_clk_get_parent_name() can return a valid
> >>> clock name only when 'clock-output-names' is present.
> >>> Probably the fclks are the only realistic use case to become parent
> >>> of downstream clock providers, but I could imagine that e.g. a device
> >>> driver like UART wants to use the CCF to model its internal clocks,
> >>> hence it would require its parent clock name. Even though a device
> >>> driver could use clk_get_parent() and __clk_get_name(),
> >>> of_clk_get_parent_name() should probably work as well. I simply have
> >>> a bad feeling about breaking of_clk_get_parent_name() for any clock.
> >>> But after all, I'm open for finding a better solution for this.
> >>>
> >>>
> >>> Similar, inputs for optional clock sources through (E)MIO pins can be
> >>> defined as described in the clock bindings using the 'clocks' and
> >>> 'clock-names' properties, with 'clock-names' being an arbitrary
> >>> subset of the documented names.
Re: [PATCH 3/4] f2fs: remain nat cache entries for further free nid allocation
2013/3/25, Jaegeuk Kim : > In the checkpoint flow, the f2fs investigates the total nat cache entries. > Previously, if an entry has NULL_ADDR, f2fs drops the entry and adds the > obsolete nid to the free nid list. > However, this free nid will be reused sooner, resulting in its nat entry > miss. > In order to avoid this, we don't need to drop the nat cache entry at this > moment. > > Signed-off-by: Jaegeuk Kim Looks good to me. Reviewed-by: Namjae Jeon Thanks~ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the wireless tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/mac80211/sta_info.c between commit 27a737ff7cb0 ("mac80211: always
synchronize_net() during station removal") from the wireless tree and
commit 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when
roaming") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/mac80211/sta_info.c
index 238a0cc,3644ad7..000
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@@ -794,19 -798,14 +799,21 @@@ int __must_check __sta_info_destroy(str
list_del_rcu(&sta->list);
mutex_lock(&local->key_mtx);
- for (i = 0; i < NUM_DEFAULT_KEYS; i++)
+ for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- __ieee80211_key_free(key_mtx_dereference(local, sta->gtk[i]));
+ __ieee80211_key_free(key_mtx_dereference(local, sta->gtk[i]),
+true);
- if (sta->ptk)
+ have_key = true;
+ }
+ if (sta->ptk) {
- __ieee80211_key_free(key_mtx_dereference(local, sta->ptk));
+ __ieee80211_key_free(key_mtx_dereference(local, sta->ptk),
+true);
+ have_key = true;
+ }
mutex_unlock(&local->key_mtx);
+ if (!have_key)
+ synchronize_net();
+
sta->dead = true;
local->num_sta--;
pgpueaDnDE75T.pgp
Description: PGP signature
Re: [PATCH 2/4] f2fs: do not skip writing file meta during fsync
2013/3/25, Jaegeuk Kim : > This patch removes data_version check flow during the fsync call. > The original purpose for the use of data_version was to avoid writng inode > pages redundantly by the fsync calls repeatedly. Hi Jaegeuk. > However, when user can modify file meta and then call fsync, we should not > skip fsync procedure. I have a question. Which case does user can directly modify meta ? Recovery tool ? Thanks. > So, let's remove this condition check and hope that user triggers in right > manner. > > Signed-off-by: Jaegeuk Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list
On Mon, Mar 25 2013, Dave Chinner wrote:
> On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> Call cond_resched() from shrink_dentry_list() to preserve
>> shrink_dcache_parent() interactivity.
>>
>> void shrink_dcache_parent(struct dentry * parent)
>> {
>> while ((found = select_parent(parent, &dispose)) != 0)
>> shrink_dentry_list(&dispose);
>> }
>>
>> select_parent() populates the dispose list with dentries which
>> shrink_dentry_list() then deletes. select_parent() carefully uses
>> need_resched() to avoid doing too much work at once. But neither
>> shrink_dcache_parent() nor its called functions call cond_resched().
>> So once need_resched() is set select_parent() will return single
>> dentry dispose list which is then deleted by shrink_dentry_list().
>> This is inefficient when there are a lot of dentry to process. This
>> can cause softlockup and hurts interactivity on non preemptable
>> kernels.
>
> Hi Greg,
>
> I can see how this coul dcause problems, but isn't the problem then
> that shrink_dcache_parent()/select_parent() itself is mishandling
> the need for rescheduling rather than being a problem with
> the shrink_dentry_list() implementation? i.e. select_parent() is
> aborting batching based on a need for rescheduling, but then not
> doing that itself and assuming that someone else will do the
> reschedule for it?
>
> Perhaps this is a better approach:
>
> - while ((found = select_parent(parent, &dispose)) != 0)
> + while ((found = select_parent(parent, &dispose)) != 0) {
> shrink_dentry_list(&dispose);
> + cond_resched();
> + }
>
> With this, select_parent() stops batching when a resched is needed,
> we dispose of the list as a single batch and only then resched if it
> was needed before we go and grab the next batch. That should fix the
> "small batch" problem without the potential for changing the
> shrink_dentry_list() behaviour adversely for other users
I considered only modifying shrink_dcache_parent() as you show above.
Either approach fixes the problem I've seen. My initial approach adds
cond_resched() deeper into shrink_dentry_list() because I thought that
there might a secondary benefit: shrink_dentry_list() would be willing
to give up the processor when working on a huge number of dentry. This
could improve interactivity during shrinker and umount. I don't feel
strongly on this and would be willing to test and post the
add-cond_resched-to-shrink_dcache_parent approach.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] f2fs: fix the recovery flow to handle errors correctly
2013/3/25, Jaegeuk Kim :
> 2013-03-25 (월), 15:30 +0900, Namjae Jeon:
>> 2013/3/25, Jaegeuk Kim :
>> > We should handle errors during the recovery flow correctly.
>> > For example, if we get -ENOMEM, we should report a mount failure instead
>> > of
>> > conducting the remained mount procedure.
>> >
>> > Signed-off-by: Jaegeuk Kim
>> > ---
>> > fs/f2fs/f2fs.h | 2 +-
>> > fs/f2fs/recovery.c | 46 --
>> > fs/f2fs/super.c| 9 +++--
>> > 3 files changed, 36 insertions(+), 21 deletions(-)
>> >
>> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> > index 5bb87e0..109e12d 100644
>> > --- a/fs/f2fs/f2fs.h
>> > +++ b/fs/f2fs/f2fs.h
>> > @@ -1027,7 +1027,7 @@ void destroy_gc_caches(void);
>> > /*
>> > * recovery.c
>> > */
>> > -void recover_fsync_data(struct f2fs_sb_info *);
>> > +int recover_fsync_data(struct f2fs_sb_info *);
>> > bool space_for_roll_forward(struct f2fs_sb_info *);
>> >
>> > /*
>> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>> > index 2d86eb2..61bdaa7 100644
>> > --- a/fs/f2fs/recovery.c
>> > +++ b/fs/f2fs/recovery.c
>> > @@ -118,10 +118,8 @@ static int find_fsync_dnodes(struct f2fs_sb_info
>> > *sbi,
>> > struct list_head *head)
>> >
>> >lock_page(page);
>> >
>> Hi Jaegeuk.
>> I have a question.
>> > - if (cp_ver != cpver_of_node(page)) {
>> > - err = -EINVAL;
>> > + if (cp_ver != cpver_of_node(page))
>> >goto unlock_out;
>> > - }
>> err = 0 is initialized to zero in the start of function
>> Why have you remove err = -EINVAL; code when mismatching cp_ver ?
>
> This ending condition is used to find the latest node pages that we have
> to recover, not to detect an error to exit the recovery routine.
> For example, the error conditions include -ENOMEM or -EIO, something
> like such the obvious errors.
> Thanks,
Yes, Right. It does make sense.
Thanks for explanation :)
You can add:
Reviewed-by: Namjae Jeon
>
>>
>> Thanks.
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Jaegeuk Kim
> Samsung
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] doc: change example to existing Makefile fragment
On 03/25/2013 05:16:24 AM, Paul Bolle wrote: Signed-off-by: Paul Bolle --- Documentation/kbuild/makefiles.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Acked-by: Rob Landley Please send through the kbuild tree. Rob diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 5198b74..020bb67 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -921,8 +921,9 @@ When kbuild executes, the following steps are followed (roughly): Often, the KBUILD_CFLAGS variable depends on the configuration. Example: - #arch/x86/Makefile - cflags-$(CONFIG_M386) += -march=i386 + #arch/x86/boot/compressed/Makefile + cflags-$(CONFIG_X86_32) := -march=i386 + cflags-$(CONFIG_X86_64) := -mcmodel=small KBUILD_CFLAGS += $(cflags-y) Many arch Makefiles dynamically run the target C compiler to -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: context tracking: add exception support
Hi Russell,
Russell King - ARM Linux writes:
> On Wed, Mar 20, 2013 at 05:01:58PM -0700, Kevin Hilman wrote:
>> Add ARM support for the context tracking subsystem by instrumenting
>> exception entry/exit points.
>>
>> Special thanks to Mats Liljegren for testing, collaboration and adding
>> support for exceptions/faults that were missing in early test versions.
[...]
>> @@ -405,7 +406,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs
>> *regs)
>> unsigned int instr;
>> siginfo_t info;
>> void __user *pc;
>> +enum ctx_state prev_state;
>>
>> +prev_state = exception_enter();
>> pc = (void __user *)instruction_pointer(regs);
>>
>> if (processor_mode(regs) == SVC_MODE) {
>> @@ -433,8 +436,10 @@ asmlinkage void __exception do_undefinstr(struct
>> pt_regs *regs)
>> goto die_sig;
>> }
>>
>> -if (call_undef_hook(regs, instr) == 0)
>> +if (call_undef_hook(regs, instr) == 0) {
>> +exception_exit(prev_state);
>> return;
>> +}
>>
>> die_sig:
>> #ifdef CONFIG_DEBUG_USER
>> @@ -451,12 +456,17 @@ die_sig:
>> info.si_addr = pc;
>>
>> arm_notify_die("Oops - undefined instruction", regs, &info, 0, 6);
>> +exception_exit(prev_state);
>
> So, FP emulation and VFP support happens via a separate path. Does this
> also need to be instrumented?
Looking a little closer at how FP/VFP support are handled along with the
rest of the exceptions, I wondered if it might be simpler to do
something like the patch below. It instruments the assembly directly
using the existing usr_entry macro, and the ret_to_user path.
Doing that would replace instrumenting the various handlers
(do_DataAbort/do_PrefetchAbort), and would handle the FP emulation VFP
support as well.
If this looks OK, I can probably rework the syscall support as well.
This approach covers the slow syscall return path already. Instead of
forcing the slowpath on all syscalls, I would just need to instrument
the syscall entry and fast syscall return.
Kevin
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..050472c 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -396,6 +396,9 @@ ENDPROC(__pabt_svc)
#ifdef CONFIG_IRQSOFF_TRACER
bl trace_hardirqs_off
#endif
+#ifdef CONFIG_CONTEXT_TRACKING
+ bl user_exit
+#endif
.endm
.macro kuser_cmpxchg_check
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3248cde..3bef99b 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -74,6 +74,9 @@ no_work_pending:
#if defined(CONFIG_IRQSOFF_TRACER)
asm_trace_hardirqs_on
#endif
+#if defined(CONFIG_CONTEXT_TRACKING)
+ bl user_enter
+#endif
/* perform architecture specific actions before user return */
arch_ret_to_user r1, lr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 09/12] staging: ti-soc-thermal: fix several kernel-doc warnings and error
On 25-03-2013 14:22, Greg KH wrote: On Tue, Mar 19, 2013 at 10:54:25AM -0400, Eduardo Valentin wrote: This patch updates the documentation to remove all warnings and errors reported by scripts/kernel-doc. Most are missing arguments due to wrong format. Cc: Nishanth Menon Signed-off-by: Eduardo Valentin In the future, don't put empty lines between the Cc: and signed-off-by: lines please, I had to hand-edit all of these to fix that... Ok. Sure.. My bad.. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_EARLY_PRINTK
On 03/22/13 07:07, Thomas Meyer wrote: > Am Samstag, den 16.03.2013, 10:38 -0700 schrieb Randy Dunlap: >> On 03/16/13 08:08, Thomas Meyer wrote: >>> Am Mittwoch, den 13.03.2013, 12:56 -0700 schrieb Randy Dunlap: >>> Yes, >>> >>> so why not do this? As the text to EARLY_PRINTK explains? >> >> Yes, the default should match the help text. >> Acked-by: Randy Dunlap >> >> Please resend your patch with Signed-off-by: line. >> >> Thanks. > > Align EARLY_PRINTK default value with help text value. > > Signed-off-by: Thomas Meyer Acked-by: Randy Dunlap Thanks. tip?? > --- > > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug > index b322f12..852d51c 100644 > --- a/arch/x86/Kconfig.debug > +++ b/arch/x86/Kconfig.debug > @@ -32,7 +32,6 @@ config X86_VERBOSE_BOOTUP > > config EARLY_PRINTK > bool "Early printk" if EXPERT > - default y > ---help--- > Write kernel log output directly into the VGA buffer or to a serial > port. > > > -- -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init/Kconfig: make EXPERT as config instead of menuconfig
On 03/21/13 19:02, zhangwei(Jovi) wrote: > There don't have any EXPERT menu guard, and no config item is > included in EXPERT menu, so change it as a config, not menu. > > This will make user more clear when they use 'make menuconfig' > or 'make nconfig'. > > Signed-off-by: zhangwei(Jovi) > Cc: Randy Dunlap > Cc: Michal Marek Makes sense to me. Acked-by: Randy Dunlap Thanks. > --- > init/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/init/Kconfig b/init/Kconfig > index 5341d72..0495453 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1177,7 +1177,7 @@ config SYSCTL > config ANON_INODES > bool > > -menuconfig EXPERT > +config EXPERT > bool "Configure standard kernel features (expert users)" > # Unhide debug options, to make the on-by-default options visible > select DEBUG_KERNEL > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: Renesas R-Car GPIO driver V3
From: Magnus Damm
This patch is V3 of a GPIO driver for the R-Car series of
SoCs from Renesas. This driver is designed to be reusable
between multiple SoCs that share the same basic building block,
but so far it has only been used on R-Car H1 (r8a7779).
Each driver instance handles 32 GPIOs with individually
maskable IRQs. The driver operates on a single I/O memory
range and the 32 GPIOs are hooked up a single interrupt.
In the case of R-Car H1 either external IRQ pins or GPIOs
with interrupts can be used for on-board interupts. For
external IRQs 4 pins are supported, and in the case of GPIO
there are 202 GPIOS as 202 interrupts hooked up via 6 driver
instances and to the GIC and the Cortex-A9 Quad.
At this point this driver is interfacing as a regular
platform device driver. In the future DT support will be
submitted as an incremental feature patch.
Signed-off-by: Magnus Damm
---
Changes since V2:
- Simple merge of [PATCH 00/03] gpio: Renesas R-Car GPIO driver update
Changes since V1:
- Update based on most suggestions from review by Laurent, thanks!
drivers/gpio/Kconfig|6
drivers/gpio/Makefile |1
drivers/gpio/gpio-rcar.c| 373 +++
include/linux/platform_data/gpio-rcar.h | 25 ++
4 files changed, 405 insertions(+)
--- 0001/drivers/gpio/Kconfig
+++ work/drivers/gpio/Kconfig 2013-03-26 09:15:56.0 +0900
@@ -204,6 +204,12 @@ config GPIO_PXA
help
Say yes here to support the PXA GPIO device
+config GPIO_RCAR
+ tristate "Renesas R-Car GPIO"
+ depends on ARM
+ help
+ Say yes here to support GPIO on Renesas R-Car SoCs.
+
config GPIO_SPEAR_SPICS
bool "ST SPEAr13xx SPI Chip Select as GPIO support"
depends on PLAT_SPEAR
--- 0001/drivers/gpio/Makefile
+++ work/drivers/gpio/Makefile 2013-03-26 09:15:56.0 +0900
@@ -57,6 +57,7 @@ obj-$(CONFIG_GPIO_PL061) += gpio-pl061.o
obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
+obj-$(CONFIG_GPIO_RCAR)+= gpio-rcar.o
obj-$(CONFIG_PLAT_SAMSUNG) += gpio-samsung.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SCH) += gpio-sch.o
--- /dev/null
+++ work/drivers/gpio/gpio-rcar.c 2013-03-26 09:16:09.0 +0900
@@ -0,0 +1,373 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ * Copyright (C) 2013 Magnus Damm
+ *
+ * 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
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_rcar_priv {
+ void __iomem *base;
+ spinlock_t lock;
+ struct gpio_rcar_config config;
+ struct platform_device *pdev;
+ struct gpio_chip gpio_chip;
+ struct irq_chip irq_chip;
+ struct irq_domain *irq_domain;
+};
+
+#define IOINTSEL 0x00
+#define INOUTSEL 0x04
+#define OUTDT 0x08
+#define INDT 0x0c
+#define INTDT 0x10
+#define INTCLR 0x14
+#define INTMSK 0x18
+#define MSKCLR 0x1c
+#define POSNEG 0x20
+#define EDGLEVEL 0x24
+#define FILONOFF 0x28
+
+static inline u32 gpio_rcar_read(struct gpio_rcar_priv *p, int offs)
+{
+ return ioread32(p->base + offs);
+}
+
+static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
+ u32 value)
+{
+ iowrite32(value, p->base + offs);
+}
+
+static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
+int bit, bool value)
+{
+ u32 tmp = gpio_rcar_read(p, offs);
+
+ if (value)
+ tmp |= BIT(bit);
+ else
+ tmp &= ~BIT(bit);
+
+ gpio_rcar_write(p, offs, tmp);
+}
+
+static void gpio_rcar_irq_disable(struct irq_data *d)
+{
+ struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+ gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_irq_enable(struct irq_data *d)
+{
+ struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+ gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
+ unsigned int hwirq,
+ bool active_high_rising_edge,
+ bool level_trigger)
+{
+ unsigned long flags;
+
+ /* follow steps in the GPIO d
Re: [PATCH] seccomp: allow BPF_XOR based ALU instructions.
On Fri, 15 Mar 2013, Nicolas Schichan wrote: > > Signed-off-by: Nicolas Schichan > --- > kernel/seccomp.c |2 ++ > 1 file changed, 2 insertions(+) Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] workqueue: protect wq->nr_drainers and ->flags with wq->mutex
From: Lai Jiangshan
We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.
wq->nr_drainers and ->flags are specific to each workqueue. Protect
->nr_drainers and ->flags with wq->mutex instead of pool_mutex.
tj: Rebased on top of the current dev branch. Updated description.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d448eda..3ac2c4d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -226,7 +226,7 @@ struct wq_device;
* the appropriate worker_pool through its pool_workqueues.
*/
struct workqueue_struct {
- unsigned intflags; /* PL: WQ_* flags */
+ unsigned intflags; /* WQ: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
struct list_headpwqs; /* WR: all pwqs of this wq */
struct list_headlist; /* PL: list of all workqueues */
@@ -242,7 +242,7 @@ struct workqueue_struct {
struct list_headmaydays;/* MD: pwqs requesting rescue */
struct worker *rescuer; /* I: rescue worker */
- int nr_drainers;/* PL: drain in progress */
+ int nr_drainers;/* WQ: drain in progress */
int saved_max_active; /* PW: saved pwq max_active */
#ifdef CONFIG_SYSFS
@@ -2684,10 +2684,10 @@ void drain_workqueue(struct workqueue_struct *wq)
* hotter than drain_workqueue() and already looks at @wq->flags.
* Use __WQ_DRAINING so that queue doesn't have to check nr_drainers.
*/
- mutex_lock(&wq_pool_mutex);
+ mutex_lock(&wq->mutex);
if (!wq->nr_drainers++)
wq->flags |= __WQ_DRAINING;
- mutex_unlock(&wq_pool_mutex);
+ mutex_unlock(&wq->mutex);
reflush:
flush_workqueue(wq);
@@ -2714,10 +2714,10 @@ reflush:
local_irq_enable();
- mutex_lock(&wq_pool_mutex);
+ mutex_lock(&wq->mutex);
if (!--wq->nr_drainers)
wq->flags &= ~__WQ_DRAINING;
- mutex_unlock(&wq_pool_mutex);
+ mutex_unlock(&wq->mutex);
}
EXPORT_SYMBOL_GPL(drain_workqueue);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] workqueue: protect wq->pwqs and iteration with wq->mutex
From: Lai Jiangshan
We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.
init_and_link_pwq() and pwq_unbound_release_workfn() already grab
wq->mutex when adding or removing a pwq from wq->pwqs list. This
patch makes it official that the list is wq->mutex protected for
writes and updates readers accoridingly. Explicit IRQ toggles for
sched-RCU read-locking in flush_workqueue_prep_pwqs() and
drain_workqueues() are removed as the surrounding wq->mutex can
provide sufficient synchronization.
Also, assert_rcu_or_pwq_lock() is renamed to assert_rcu_or_wq_mutex()
and checks for wq->mutex too.
pwq_lock locking and assertion are not removed by this patch and a
couple of for_each_pwq() iterations are still protected by it.
They'll be removed by future patches.
tj: Rebased on top of the current dev branch. Updated description.
Folded in assert_rcu_or_wq_mutex() renaming from a later patch
along with associated comment updates.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 3ac2c4d..9c32fd1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -204,7 +204,7 @@ struct pool_workqueue {
* Release of unbound pwq is punted to system_wq. See put_pwq()
* and pwq_unbound_release_workfn() for details. pool_workqueue
* itself is also sched-RCU protected so that the first pwq can be
-* determined without grabbing pwq_lock.
+* determined without grabbing wq->mutex.
*/
struct work_struct unbound_release_work;
struct rcu_head rcu;
@@ -298,10 +298,11 @@ static void copy_workqueue_attrs(struct workqueue_attrs
*to,
lockdep_is_held(&wq_pool_mutex), \
"sched RCU or wq_pool_mutex should be held")
-#define assert_rcu_or_pwq_lock() \
+#define assert_rcu_or_wq_mutex(wq) \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
+ lockdep_is_held(&wq->mutex) || \
lockdep_is_held(&pwq_lock), \
- "sched RCU or pwq_lock should be held")
+ "sched RCU or wq->mutex should be held")
#ifdef CONFIG_LOCKDEP
#define assert_manager_or_pool_lock(pool) \
@@ -356,7 +357,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
* @pwq: iteration cursor
* @wq: the target workqueue
*
- * This must be called either with pwq_lock held or sched RCU read locked.
+ * This must be called either with wq->mutex held or sched RCU read locked.
* If the pwq needs to be used beyond the locking in effect, the caller is
* responsible for guaranteeing that the pwq stays online.
*
@@ -365,7 +366,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
*/
#define for_each_pwq(pwq, wq) \
list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node) \
- if (({ assert_rcu_or_pwq_lock(); false; })) { } \
+ if (({ assert_rcu_or_wq_mutex(wq); false; })) { } \
else
#ifdef CONFIG_DEBUG_OBJECTS_WORK
@@ -504,13 +505,13 @@ static int worker_pool_assign_id(struct worker_pool *pool)
* first_pwq - return the first pool_workqueue of the specified workqueue
* @wq: the target workqueue
*
- * This must be called either with pwq_lock held or sched RCU read locked.
+ * This must be called either with wq->mutex held or sched RCU read locked.
* If the pwq needs to be used beyond the locking in effect, the caller is
* responsible for guaranteeing that the pwq stays online.
*/
static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
{
- assert_rcu_or_pwq_lock();
+ assert_rcu_or_wq_mutex(wq);
return list_first_or_null_rcu(&wq->pwqs, struct pool_workqueue,
pwqs_node);
}
@@ -2477,12 +2478,10 @@ static bool flush_workqueue_prep_pwqs(struct
workqueue_struct *wq,
atomic_set(&wq->nr_pwqs_to_flush, 1);
}
- local_irq_disable();
-
for_each_pwq(pwq, wq) {
struct worker_pool *pool = pwq->pool;
- spin_lock(&pool->lock);
+ spin_lock_irq(&pool->lock);
if (flush_color >= 0) {
WARN_ON_ONCE(pwq->flush_color != -1);
@@ -2499,11 +2498,9 @@ static bool flush_workqueue_prep_pwqs(struct
workqueue_struct *wq,
pwq->work_color = work_color;
}
- spin_unlock(&pool->lock);
+ spi
[PATCH 6/6] workqueue: remove pwq_lock which is no longer used
From: Lai Jiangshan
To simplify locking, the previous patches expanded wq->mutex to
protect all fields of each workqueue instance including the pwqs list
leaving pwq_lock without any user. Remove the unused pwq_lock.
tj: Rebased on top of the current dev branch. Updated description.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index af6087a..04a8b98 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -125,12 +125,9 @@ enum {
*
* PR: wq_pool_mutex protected for writes. Sched-RCU protected for reads.
*
- * PW: pwq_lock protected.
- *
* WQ: wq->mutex protected.
*
- * WR: wq->mutex and pwq_lock protected for writes. Sched-RCU protected
- * for reads.
+ * WR: wq->mutex protected for writes. Sched-RCU protected for reads.
*
* MD: wq_mayday_lock protected.
*/
@@ -257,7 +254,6 @@ struct workqueue_struct {
static struct kmem_cache *pwq_cache;
static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
-static DEFINE_SPINLOCK(pwq_lock); /* protects pool_workqueues */
static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
static LIST_HEAD(workqueues); /* PL: list of all workqueues */
@@ -300,8 +296,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
#define assert_rcu_or_wq_mutex(wq) \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
- lockdep_is_held(&wq->mutex) || \
- lockdep_is_held(&pwq_lock), \
+ lockdep_is_held(&wq->mutex), \
"sched RCU or wq->mutex should be held")
#ifdef CONFIG_LOCKDEP
@@ -3549,9 +3544,7 @@ static void pwq_unbound_release_workfn(struct work_struct
*work)
* and consistent with the linking path.
*/
mutex_lock(&wq->mutex);
- spin_lock_irq(&pwq_lock);
list_del_rcu(&pwq->pwqs_node);
- spin_unlock_irq(&pwq_lock);
mutex_unlock(&wq->mutex);
put_unbound_pool(pool);
@@ -3635,9 +3628,7 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
pwq_adjust_max_active(pwq);
/* link in @pwq */
- spin_lock_irq(&pwq_lock);
list_add_rcu(&pwq->pwqs_node, &wq->pwqs);
- spin_unlock_irq(&pwq_lock);
mutex_unlock(&wq->mutex);
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
