[git pull] Input updates for 3.16-rc6
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive a few fixups for the input subsystem. Changelog: - Bjorn Helgaas (1): Input: sirfsoc-onkey - fix GPL v2 license string typo Dmitry Torokhov (1): Input: fix defuzzing logic Felipe Balbi (1): Input: ti_am335x_tsc - warn about incorrect spelling Hans de Goede (1): Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) Jiri Kosina (1): Input: i8042 - add Acer Aspire 5710 to nomux blacklist Peter Hutterer (1): Input: document INPUT_PROP_TOPBUTTONPAD Ping Cheng (1): Input: wacom - cleanup multitouch code when touch_max is 2 Tobias Klauser (1): Input: st-keyscan - fix 'defined but not used' compiler warnings Diffstat: Documentation/input/event-codes.txt | 13 + drivers/input/input.c | 6 -- drivers/input/keyboard/st-keyscan.c | 2 ++ drivers/input/misc/sirfsoc-onkey.c| 2 +- drivers/input/mouse/synaptics.c | 5 +++-- drivers/input/serio/i8042-x86ia64io.h | 7 +++ drivers/input/tablet/wacom_wac.c | 28 +++- drivers/input/touchscreen/ti_am335x_tsc.c | 5 - 8 files changed, 41 insertions(+), 27 deletions(-) -- Dmitry signature.asc Description: Digital signature
Re: [PATCH v2 3/4] virtio: rng: delay hwrng_register() till driver is ready
Amit Shah writes: > On (Mon) 21 Jul 2014 [17:15:51], Amit Shah wrote: >> Instead of calling hwrng_register() in the probe routing, call it in the >> scan routine. This ensures that when hwrng_register() is successful, >> and it requests a few random bytes to seed the kernel's pool at init, >> we're ready to service that request. >> >> This will also enable us to remove the workaround added previously to >> check whether probe was completed, and only then ask for data from the >> host. The revert follows in the next commit. >> >> There's a slight behaviour change here on unsuccessful hwrng_register(). >> Previously, when hwrng_unregister() failed, the probe() routine would > > typo: should be hwrng_register(). > > Please fix this up when picking up the patch. Done. All 4 patches applied! Rusty. -- 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 2/2] module: return bool from within_module*()
Petr Mladek writes:
> The within_module*() functions return only true or false. Let's use bool as
> the return type.
>
> Note that it should not change kABI because these are inline functions.
>
> Signed-off-by: Petr Mladek
Thanks, applied both.
Cheers,
Rusty.
> ---
> include/linux/module.h | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 61d8fb2d0873..71f282a4e307 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -396,19 +396,21 @@ bool is_module_address(unsigned long addr);
> bool is_module_percpu_address(unsigned long addr);
> bool is_module_text_address(unsigned long addr);
>
> -static inline int within_module_core(unsigned long addr, const struct module
> *mod)
> +static inline bool within_module_core(unsigned long addr,
> + const struct module *mod)
> {
> return (unsigned long)mod->module_core <= addr &&
> addr < (unsigned long)mod->module_core + mod->core_size;
> }
>
> -static inline int within_module_init(unsigned long addr, const struct module
> *mod)
> +static inline bool within_module_init(unsigned long addr,
> + const struct module *mod)
> {
> return (unsigned long)mod->module_init <= addr &&
> addr < (unsigned long)mod->module_init + mod->init_size;
> }
>
> -static inline int within_module(unsigned long addr, const struct module *mod)
> +static inline bool within_module(unsigned long addr, const struct module
> *mod)
> {
> return within_module_init(addr, mod) || within_module_core(addr, mod);
> }
> --
> 1.8.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] mm, arc: remove obsolete pagefault oom killer comment
On Wednesday 23 July 2014 06:35 AM, David Rientjes wrote:
> Commit 609838cfed97 ("mm: invoke oom-killer from remaining unconverted page
> fault handlers") converted arc to call pagefault_out_of_memory(), so remove
> the comment about future conversion.
>
> Cc: Johannes Weiner
> Signed-off-by: David Rientjes
Thx David,
Applied to ARC for-next.
-Vineet
--
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] m68k: Remove printk statement and add return statement in q40ints.c
On 07/22/2014 09:56 PM, Nick Krause wrote:
On Wed, Jul 23, 2014 at 12:54 AM, Guenter Roeck wrote:
On 07/22/2014 09:08 PM, Nicholas Krause wrote:
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data
*data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
Returning -ENXIO from a function returning an unsigned int isn't really very
helpful,
don't you think ?
With all those FIXMEs, you might want to keep in mind that there is
typically a
good reason for it. If it was as easy as your proposed fix, you can assume
that the FIXME would not have been there in the first place.
Guenter
Sorry Guenter,
That's fine. can I can change the return type of the function or is
that going to break things?
Nick
Please have a look at the context. q40_irq_startup is used to initialize
struct irq_chip.irq_startup, which expects an unsigned int as return value.
To make things more interesting, the caller (function irq_startup) assigns
the result to an int. However, _callers_ of irq_startup either ignore
the return value, or assume that an interrupt is pending if the return
value is not 0.
So all your change accomplishes is to tell the caller that an interrupt
would be pending. Changing the return value to int will only result
in a compile warning but otherwise not change anything.
Unless you put in the effort to really analyze the code, and that applies
to each FIXME you are trying to fix, I would suggest to leave it alone.
Otherwise we just end up worse than before.
Guenter
--
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 v3] gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc
On Wed, Jul 23, 2014 at 12:01 AM, Guenter Roeck wrote: > Both functions were introduced to let gpio drivers request their own > gpio pins. Without exporting the functions, this can however only be > used by gpio drivers built into the kernel. > > Secondary impact is that the functions can not currently be used by > platform initialization code associated with the gpio-pca953x driver. > This code permits auto-export of gpio pins through platform data, but > if this functionality is used, the module can no longer be unloaded due > to the problem solved with the introduction of gpiochip_request_own_desc > and gpiochip_free_own_desc. > > Export both function so they can be used from modules and from > platform initialization code. > > Cc: Mika Westerberg > Signed-off-by: Guenter Roeck Makes sense to have them there. Reviewed-by: Alexandre Courbot -- 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 3/5] gpio: make gpiochip_get_desc() gpiolib-private
On Wed, Jul 23, 2014 at 12:47 PM, Guenter Roeck wrote: > On 07/22/2014 08:10 PM, Alexandre Courbot wrote: >> >> On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: >>> >>> On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. >>> If I implement a gpio chip driver built as module, and I want to use >>> gpiochip_request_own_desc(), how am I supposed to get desc ? >>> >>> I understand that there is still gpio_to_desc(), but I would have thought >>> that >>> desc = gpiochip_get_desc(chip, pin); >>> would be better than >>> desc = gpio_to_desc(chip->base + pin); >>> >>> Not that it makes much of a difference for me, just asking. >> >> >> Actually I was thinking of changing the prototype of >> gpiochip_request_own_desc(), and your comment definitely strenghtens >> that idea. gpiochip functions should not work with descriptors, >> especially since we are going to switch to a multiple-consumer scheme >> where there won't be any canonical descriptor anymore. Thus, how about >> turning gpiochip_request_own_desc() into this: >> >> struct gpio_desc * >> gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char >> *label); >> >> which would basically do both the gpiochip_get_desc() and former >> gpiochip_request_own_desc() in one call. I think it should satisfy >> everybody and removes the need to have gpiochip_get_desc() (a not very >> useful function by itself) exposed out of gpiolib. >> >> I will send a patch taking care of this if you agree that makes sense. >> > > I think you also plan to remove the capability to retrieve the chip > pointer, don't you ? If so, I won't be able to use the function from > the pca953x platform init function, since I won't be able to get the > pointer to the gpio chip. Even if you don't remove gpiod_to_chip(), > things would become a bit messy, since I would first have to convert > a pin to a desc and then to the chip pointer. Anyway, that change > would mean that exporting gpiochip_request_own_desc or its replacement > won't solve one of the problems addressed by my patch anymore, leaving > me more or less in the dark :-(. Here is why this change is taking place: right now you have a clear descriptor/pin mapping, i.e. there is only one descriptor per pin, anytime. For various reasons this is going to change soon, and descriptors will be allocated the provided to GPIO consumers as an abstraction of the pin. Meaning that you cannot really "get the descriptor for that pin" anymore. Since gpiochip_request_own_desc()'s purpose is precisely to request one descriptor for drivers to use, the new prototype makes much more sense IMHO. Another reason to have it work on a gpio_chip is that the gpio_chip pointer is a token to doing certain "priviledged" operations. Like obtaining an arbitrary descriptor. If consumers can get a pointer to the gpio_chip of a descriptor, this means they can basically do anything. Being in the board code, it seems to be that you are in a good position to obtain a pointer to the gpio_chip, and without knowing better I'd say that's what you should try to do. But maybe I would understand your problem better if you could post a small patch of what you want to achieve here. > > I was thinking about implementing a separate platform driver which > would enable me to auto-export (or initialize, if needed) gpio pins > from arbitrary gpio drivers to user space. I could make this work > with both devicetree data and platform data. Sure, that driver > would not have a chance to get accepted upstream, since it would use > devicetree data to, in a sense, configure the system, but on the > upside it would be independent of gpio API changes, and it would > work for _all_ gpio chips, not just for the ones with gpio driver > support. Unfortunately this approach doesn't really work either, > since exported pin names need to be configured with the chip driver, > and can not be selected afterwards when a pin is actually exported. > > On the other side, would you agree to adding something like > gpiod_export_name(), which would export a gpio pin with given name, > not using the default or chip->names ? That might help solving > at least some of my problems, and I would no longer depend on > gpiochip_request_own_desc or any of the related functions. Isn't that what gpiod_export_link() does? > > For reference, I currently need the ability to auto-export > gpio pins to user space for pca953x, ich, and for various > to-be-published gpio drivers used by my employer. Under which criteria are the GPIOs auto-exported? Can't you have the board code simply request all the GPIOs as a regular consumer and export them to user-space? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org
Re: [PATCH] ACPI/NVS: Not save NVS region for new machines to accelerate S3
On 2014年07月23日 07:40, Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 01:55:22 PM Lan Tianyu wrote:
>> NVS region is saved and restored unconditionally for machines without
>> nvs_nosave quirk during S3. Tested some new machines and the operation
>> is not necessary. Saving NVS region also affects S2RAM speed. The time of
>> NVS saving and restoring depends on the size of NVS region and it consumes
>> 7~10ms normally.
>>
>> This patch is to make machines produced from 2012 to now not saving NVS
>> region
>> to accelerate S3.
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> drivers/acpi/sleep.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index b3e3cc7..896d8be 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -322,7 +322,12 @@ static struct dmi_system_id acpisleep_dmi_table[]
>> __initdata = {
>>
>> static void acpi_sleep_dmi_check(void)
>> {
>> +int year;
>> +
>> dmi_check_system(acpisleep_dmi_table);
>> +
>> +if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && year >= 2012)
>> +acpi_nvs_nosave_s3();
>
> I'd prefer the ordering here to be different so that individual quirks
> could be used to change the date-based wholesale behavior.
Ok. I will update soon.
>
>> }
>>
>> /**
>>
>
--
Best regards
Tianyu Lan
--
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 00/14] arm64: eBPF JIT compiler
On Mon, Jul 21, 2014 at 8:49 AM, Alexei Starovoitov wrote: > On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote: [...] >>> This series applies against net-next and is tested working >>> with lib/test_bpf on ARMv8 Foundation Model. >> >> Looks like it works on my Juno board too, so: >> >> Acked-by: Will Deacon >> >> for the series. Thanks Will! I've added your acked-by to the entire series, also tweaked 14/14's commit log to indicate that it's been tested on Juno as well. >> >> It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which >> also means the dependency on -next isn't an issue). Perhaps you could repost >> around -rc3? > > Thanks for testing! Nice to see it working on real hw. > I'm not sure why you're proposing a 4+ week delay. The patches > will rot instead of getting used and tested. Imo it makes sense to > get them into net-next now for 3.17. > JIT is disabled by sysctl by default anyway. Hmm... if net-next is still open, and David is willing to pull in this series, I share Alexei's opinion -- don't see why a delay is necessary. David, any chance of pulling this series into net-next for 3.17? BTW, I also tried merging 'git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core' with this series. The example merge is available at 'https://github.com/zlim/linux.git arm64/bpf-merge'. The merge conflict resolution is really trivial: 8< diff --cc arch/arm64/Kconfig index 7534a80a,ce6e733..c165c91 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@@ -32,8 -33,8 +34,9 @@@ config ARM6 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK - select HAVE_C_RECORDMCOUNT + select HAVE_BPF_JIT + select HAVE_C_RECORDMCOUNT + select HAVE_CC_STACKPROTECTOR select HAVE_DEBUG_BUGVERBOSE select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_API_DEBUG >8 Anyway, here's an updated branch (with Will's acks, commit log tweak noting Will's testing on real hardware, rebase on net-next). I can repost entire patch series if needed. The following changes since commit 52c4f0ec662bbf02f1b0bcb311a48af2c8e5ee89: drivers: net: cpsw: add support to dump ALE table via ethtool register dump (2014-07-22 19:58:25 -0700) are available in the git repository at: https://github.com/zlim/linux.git arm64/bpf for you to fetch changes up to 533f668ff3e8d69f22c6e5432e0eb1005f2e8970: arm64: eBPF JIT compiler (2014-07-22 21:52:09 -0700) -- 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] ASoC: sirf-usp: Fixed a bug for playback and capture work at the same time
1. The startup function invoked when the playback and capture.
If start playback when capturing, the registers are re-initinitialised.
That cause the playback fail. So move the startup code into runtime resume.
2. Modified: If non RUNTIME_PM support, the probe need enable clock and
initinitialise registers.
3. Refine code.
Signed-off-by: Rongjun Ying
---
sound/soc/sirf/sirf-usp.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/soc/sirf/sirf-usp.c b/sound/soc/sirf/sirf-usp.c
index 9693bc2..3a73037 100644
--- a/sound/soc/sirf/sirf-usp.c
+++ b/sound/soc/sirf/sirf-usp.c
@@ -103,11 +103,8 @@ static int sirf_usp_pcm_set_dai_fmt(struct snd_soc_dai
*dai,
return 0;
}
-static int sirf_usp_i2s_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
+static void sirf_usp_i2s_init(struct sirf_usp *usp)
{
- struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
-
/* Configure RISC mode */
regmap_update_bits(usp->regmap, USP_RISC_DSP_MODE,
USP_RISC_DSP_SEL, ~USP_RISC_DSP_SEL);
@@ -119,19 +116,16 @@ static int sirf_usp_i2s_startup(struct snd_pcm_substream
*substream,
regmap_write(usp->regmap, USP_TX_DMA_IO_LEN, 0);
regmap_write(usp->regmap, USP_RX_DMA_IO_LEN, 0);
- regmap_write(usp->regmap, USP_RX_FRAME_CTRL, USP_SINGLE_SYNC_MODE);
-
- regmap_write(usp->regmap, USP_TX_FRAME_CTRL, USP_TXC_SLAVE_CLK_SAMPLE);
-
/* Configure Mode2 register */
regmap_write(usp->regmap, USP_MODE2, (1 << USP_RXD_DELAY_LEN_OFFSET) |
- (0 << USP_TXD_DELAY_LEN_OFFSET));
+ (0 << USP_TXD_DELAY_LEN_OFFSET) |
+ USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE);
/* Configure Mode1 register */
regmap_write(usp->regmap, USP_MODE1,
USP_SYNC_MODE | USP_EN | USP_TXD_ACT_EDGE_FALLING |
USP_RFS_ACT_LEVEL_LOGIC1 | USP_TFS_ACT_LEVEL_LOGIC1 |
- USP_TX_UFLOW_REPEAT_ZERO);
+ USP_TX_UFLOW_REPEAT_ZERO | USP_CLOCK_MODE_SLAVE);
/* Configure RX DMA IO Control register */
regmap_write(usp->regmap, USP_RX_DMA_IO_CTRL, 0);
@@ -155,8 +149,6 @@ static int sirf_usp_i2s_startup(struct snd_pcm_substream
*substream,
/* Congiure TX FIFO Level Check register */
regmap_write(usp->regmap, USP_TX_FIFO_LEVEL_CHK,
TX_FIFO_SC(0x1B) | TX_FIFO_LC(0x0E) | TX_FIFO_HC(0x04));
-
- return 0;
}
static int sirf_usp_pcm_hw_params(struct snd_pcm_substream *substream,
@@ -204,23 +196,19 @@ static int sirf_usp_pcm_hw_params(struct
snd_pcm_substream *substream,
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
regmap_update_bits(usp->regmap, USP_TX_FRAME_CTRL,
USP_TXC_DATA_LEN_MASK | USP_TXC_FRAME_LEN_MASK
- | USP_TXC_SHIFTER_LEN_MASK,
+ | USP_TXC_SHIFTER_LEN_MASK | USP_TXC_SLAVE_CLK_SAMPLE,
((data_len - 1) << USP_TXC_DATA_LEN_OFFSET)
| ((frame_len - 1) << USP_TXC_FRAME_LEN_OFFSET)
- | ((shifter_len - 1) << USP_TXC_SHIFTER_LEN_OFFSET));
+ | ((shifter_len - 1) << USP_TXC_SHIFTER_LEN_OFFSET)
+ | USP_TXC_SLAVE_CLK_SAMPLE);
else
regmap_update_bits(usp->regmap, USP_RX_FRAME_CTRL,
USP_RXC_DATA_LEN_MASK | USP_RXC_FRAME_LEN_MASK
- | USP_RXC_SHIFTER_LEN_MASK,
+ | USP_RXC_SHIFTER_LEN_MASK | USP_SINGLE_SYNC_MODE,
((data_len - 1) << USP_RXC_DATA_LEN_OFFSET)
| ((frame_len - 1) << USP_RXC_FRAME_LEN_OFFSET)
- | ((shifter_len - 1) << USP_RXC_SHIFTER_LEN_OFFSET));
-
- regmap_update_bits(usp->regmap, USP_MODE1,
- USP_CLOCK_MODE_SLAVE, USP_CLOCK_MODE_SLAVE);
- regmap_update_bits(usp->regmap, USP_MODE2,
- USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE,
- USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE);
+ | ((shifter_len - 1) << USP_RXC_SHIFTER_LEN_OFFSET)
+ | USP_SINGLE_SYNC_MODE);
return 0;
}
@@ -253,7 +241,6 @@ static int sirf_usp_pcm_trigger(struct snd_pcm_substream
*substream, int cmd,
}
static const struct snd_soc_dai_ops sirf_usp_pcm_dai_ops = {
- .startup = sirf_usp_i2s_startup,
.trigger = sirf_usp_pcm_trigger,
.set_fmt = sirf_usp_pcm_set_dai_fmt,
.hw_params = sirf_usp_pcm_hw_params,
@@ -282,7 +269,6 @@ static struct snd_soc_dai_driver sirf_usp_pcm_dai = {
.ops = _usp_pcm_dai_ops,
};
-#ifdef CONFIG_PM
static int sirf_usp_pcm_runtime_suspend(struct device *dev)
{
struct sirf_usp *usp = dev_get_drvdata(dev);
@@ -293,9 +279,15 @@ static int sirf_usp_pcm_runtime_suspend(struct
[PATCH 00/16] rcu: Some minor fixes and cleanups
Hi Paul, This is a series of minor fixes and cleanup patches which I found while studying the code. All my previous pending (but not rejected ;) patches are superseded by this series, expect the rcutorture snprintf changes. I am still waiting for you to decide on that one :) These changes have been tested by the kvm rcutorture test setup. Some tests give me stall warnings, but otherwise have SUCCESS messages in the logs. But those are occuring even without these changes with the tip paul/rcu/dev. May be it is because I am running them for a duration of 4 minutes each only? -- Pranith. Pranith Kumar (16): rcu: Use rcu_num_nodes instead of NUM_RCU_NODES rcu: Check return value for cpumask allocation rcu: Fix comment for gp_state field values rcu: Remove redundant check for an online CPU rcu: Add noreturn attribute to boost kthread rcu: Clear gp_flags only when actually starting new gp rcu: Save and restore irq flags in rcu_gp_cleanup() rcu: Clean up rcu_spawn_one_boost_kthread() rcu: Remove redundant check for online cpu rcu: Check for RCU_FLAG_GP_INIT bit in gp_flags for spurious wakeup rcu: Check for spurious wakeup using return value rcu: Rename rcu_spawn_gp_kthread() to rcu_spawn_kthreads() rcu: Spawn nocb kthreads from rcu_prepare_kthreads() rcu: Remove redundant checks for rcu_scheduler_fully_active rcu: Check for a nocb cpu before trying to spawn nocb threads rcu: kvm.sh: Fix error when you pass --cpus argument kernel/rcu/tree.c | 42 ++- kernel/rcu/tree.h | 4 +-- kernel/rcu/tree_plugin.h | 40 + tools/testing/selftests/rcutorture/bin/kvm.sh | 4 +-- 4 files changed, 47 insertions(+), 43 deletions(-) -- 2.0.0.rc2 -- 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 01/16] rcu: Use rcu_num_nodes instead of NUM_RCU_NODES
NUM_RCU_NODES is set at build time and is usually a huge number. We calculate
the actual number of rcu nodes necessary at boot time based on nr_cpu_ids in
rcu_init_geometry() and store it in rcu_num_nodes. We should use this variable
instead of NUM_RCU_NODES.
This commit changes all such NUM_RCU_NODES uses to rcu_num_nodes.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index c31eb28..f07b643 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -885,7 +885,7 @@ void synchronize_rcu_expedited(void)
/* Snapshot current state of ->blkd_tasks lists. */
rcu_for_each_leaf_node(rsp, rnp)
sync_rcu_preempt_exp_init(rsp, rnp);
- if (NUM_RCU_NODES > 1)
+ if (rcu_num_nodes > 1)
sync_rcu_preempt_exp_init(rsp, rcu_get_root(rsp));
put_online_cpus();
@@ -1475,7 +1475,7 @@ static void __init rcu_spawn_boost_kthreads(void)
BUG_ON(smpboot_register_percpu_thread(_cpu_thread_spec));
rnp = rcu_get_root(rcu_state_p);
(void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
- if (NUM_RCU_NODES > 1) {
+ if (rcu_num_nodes > 1) {
rcu_for_each_leaf_node(rcu_state_p, rnp)
(void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
--
2.0.0.rc2
--
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 04/16] rcu: Remove redundant check for an online CPU
rcu_prcess_callbacks() is the softirq handler for RCU which is raised from
invoke_rcu_core() which is called from __call_rcu_core().
Each of these three functions checks if the cpu is online. We can remove the
redundant ones. This commit removes one of these redundant check.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 72e0b1f..044946e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2563,8 +2563,6 @@ static void rcu_process_callbacks(struct softirq_action
*unused)
{
struct rcu_state *rsp;
- if (cpu_is_offline(smp_processor_id()))
- return;
trace_rcu_utilization(TPS("Start RCU core"));
for_each_rcu_flavor(rsp)
__rcu_process_callbacks(rsp);
--
2.0.0.rc2
--
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 02/16] rcu: Check return value for cpumask allocation
This commit add a check for return value of zalloc_cpumask_var() used while
allocating cpumask for rcu_nocb_mask.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index f07b643..bac9797 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -88,7 +88,10 @@ static void __init rcu_bootup_announce_oddness(void)
#ifdef CONFIG_RCU_NOCB_CPU
#ifndef CONFIG_RCU_NOCB_CPU_NONE
if (!have_rcu_nocb_mask) {
- zalloc_cpumask_var(_nocb_mask, GFP_KERNEL);
+ if (!zalloc_cpumask_var(_nocb_mask, GFP_KERNEL)) {
+ pr_info("rcu_nocb_mask allocation failed\n");
+ return;
+ }
have_rcu_nocb_mask = true;
}
#ifdef CONFIG_RCU_NOCB_CPU_ZERO
--
2.0.0.rc2
--
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 03/16] rcu: Fix comment for gp_state field values
The comment in the code states that the values are for gp_flags field, when the
values are actually for gp_state field. This commit fixes the inconsistency.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index f703ea8..9643f10 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -498,7 +498,7 @@ struct rcu_state {
#define RCU_GP_FLAG_INIT 0x1 /* Need grace-period initialization. */
#define RCU_GP_FLAG_FQS 0x2 /* Need grace-period quiescent-state forcing. */
-/* Values for rcu_state structure's gp_flags field. */
+/* Values for rcu_state structure's gp_state field. */
#define RCU_GP_WAIT_INIT 0 /* Initial state. */
#define RCU_GP_WAIT_GPS 1 /* Wait for grace-period start. */
#define RCU_GP_WAIT_FQS 2 /* Wait for force-quiescent-state time. */
--
2.0.0.rc2
--
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 05/16] rcu: Add noreturn attribute to boost kthread
rcu_boost_kthread() runs in an infinite loop and does not return. This commit
adds the __noreturn attribute to the function.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index bac9797..dd53247 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1222,7 +1222,7 @@ static int rcu_boost(struct rcu_node *rnp)
* Priority-boosting kthread. One per leaf rcu_node and one for the
* root rcu_node.
*/
-static int rcu_boost_kthread(void *arg)
+static __noreturn int rcu_boost_kthread(void *arg)
{
struct rcu_node *rnp = (struct rcu_node *)arg;
int spincnt = 0;
@@ -1250,7 +1250,6 @@ static int rcu_boost_kthread(void *arg)
}
/* NOTREACHED */
trace_rcu_utilization(TPS("End boost kthread@notreached"));
- return 0;
}
/*
--
2.0.0.rc2
--
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 06/16] rcu: Clear gp_flags only when actually starting new gp
We are clearing the gp_flags before we check if a grace period is in progress.
If a grace period is in progress, we return after incorrectly clearing the
gp_flags. The code comments say that this is highly unlikely, but just to be
safe this commit moves the clearing of gp_flags to after the check for grace
period in progress.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 044946e..b14cecd 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1605,7 +1605,6 @@ static int rcu_gp_init(struct rcu_state *rsp)
raw_spin_unlock_irq(>lock);
return 0;
}
- ACCESS_ONCE(rsp->gp_flags) = 0; /* Clear all flags: New grace period. */
if (WARN_ON_ONCE(rcu_gp_in_progress(rsp))) {
/*
@@ -1616,6 +1615,8 @@ static int rcu_gp_init(struct rcu_state *rsp)
return 0;
}
+ ACCESS_ONCE(rsp->gp_flags) = 0; /* Clear all flags: New grace period. */
+
/* Advance to a new grace period and initialize state. */
record_gp_stall_check_time(rsp);
/* Record GP times before starting GP, hence smp_store_release(). */
--
2.0.0.rc2
--
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 09/16] rcu: Remove redundant check for online cpu
There are two checks for an online CPU if two if() conditions. This commit
simplies this by replacing it with only one check for the online CPU.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 5dcbf36..8d598a2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2602,15 +2602,18 @@ static void __call_rcu_core(struct rcu_state *rsp,
struct rcu_data *rdp,
{
bool needwake;
+ if (!cpu_online(smp_processor_id()))
+ return;
+
/*
* If called from an extended quiescent state, invoke the RCU
* core in order to force a re-evaluation of RCU's idleness.
*/
- if (!rcu_is_watching() && cpu_online(smp_processor_id()))
+ if (!rcu_is_watching())
invoke_rcu_core();
- /* If interrupts were disabled or CPU offline, don't invoke RCU core. */
- if (irqs_disabled_flags(flags) || cpu_is_offline(smp_processor_id()))
+ /* If interrupts were disabled, don't invoke RCU core. */
+ if (irqs_disabled_flags(flags))
return;
/*
--
2.0.0.rc2
--
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 11/16] rcu: Check for spurious wakeup using return value
When the gp_kthread wakes up from the wait event, it returns 0 if the wake up is
due to the condition having been met. This commit checks this return value
for a spurious wake up before calling rcu_gp_init().
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f8847d9..3b20ad2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1790,11 +1790,11 @@ static int __noreturn rcu_gp_kthread(void *arg)
ACCESS_ONCE(rsp->gpnum),
TPS("reqwait"));
rsp->gp_state = RCU_GP_WAIT_GPS;
- wait_event_interruptible(rsp->gp_wq,
+ ret = wait_event_interruptible(rsp->gp_wq,
ACCESS_ONCE(rsp->gp_flags) &
RCU_GP_FLAG_INIT);
/* Locking provides needed memory barrier. */
- if (rcu_gp_init(rsp))
+ if (!ret && rcu_gp_init(rsp))
break;
cond_resched();
flush_signals(current);
--
2.0.0.rc2
--
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 07/16] rcu: Save and restore irq flags in rcu_gp_cleanup()
We use raw_spin_lock_irqsave/restore() family of functions throughout the code
but for two locations. This commit replaces raw_spin_lock_irq()/unlock_irq()
with irqsave/restore() in one such location. This is not strictly necessary,
so I did not change the other location. I will update the other location if
this is accepted :)
This commit changes raw_spin_lock_irq()/unlock_irq() to
lock_irqsave()/restore().
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b14cecd..5dcbf36 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1706,13 +1706,13 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
*/
static void rcu_gp_cleanup(struct rcu_state *rsp)
{
- unsigned long gp_duration;
+ unsigned long gp_duration, flags;
bool needgp = false;
int nocb = 0;
struct rcu_data *rdp;
struct rcu_node *rnp = rcu_get_root(rsp);
- raw_spin_lock_irq(>lock);
+ raw_spin_lock_irqsave(>lock, flags);
smp_mb__after_unlock_lock();
gp_duration = jiffies - rsp->gp_start;
if (gp_duration > rsp->gp_max)
@@ -1726,7 +1726,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
* safe for us to drop the lock in order to mark the grace
* period as completed in all of the rcu_node structures.
*/
- raw_spin_unlock_irq(>lock);
+ raw_spin_unlock_irqrestore(>lock, flags);
/*
* Propagate new ->completed value to rcu_node structures so
@@ -1738,7 +1738,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
* grace period is recorded in any of the rcu_node structures.
*/
rcu_for_each_node_breadth_first(rsp, rnp) {
- raw_spin_lock_irq(>lock);
+ raw_spin_lock_irqsave(>lock, flags);
smp_mb__after_unlock_lock();
ACCESS_ONCE(rnp->completed) = rsp->gpnum;
rdp = this_cpu_ptr(rsp->rda);
@@ -1746,11 +1746,11 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
needgp = __note_gp_changes(rsp, rnp, rdp) || needgp;
/* smp_mb() provided by prior unlock-lock pair. */
nocb += rcu_future_gp_cleanup(rsp, rnp);
- raw_spin_unlock_irq(>lock);
+ raw_spin_unlock_irqrestore(>lock, flags);
cond_resched();
}
rnp = rcu_get_root(rsp);
- raw_spin_lock_irq(>lock);
+ raw_spin_lock_irqsave(>lock, flags);
smp_mb__after_unlock_lock(); /* Order GP before ->completed update. */
rcu_nocb_gp_set(rnp, nocb);
@@ -1767,7 +1767,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
ACCESS_ONCE(rsp->gpnum),
TPS("newreq"));
}
- raw_spin_unlock_irq(>lock);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
/*
--
2.0.0.rc2
--
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 12/16] rcu: Rename rcu_spawn_gp_kthread() to rcu_spawn_kthreads()
We are currently spawning all the threads from this functions. This commit
renames the function so that it reflects the current scenario better.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3b20ad2..afd54e2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3501,9 +3501,10 @@ static int rcu_pm_notify(struct notifier_block *self,
}
/*
- * Spawn the kthreads that handle each RCU flavor's grace periods.
+ * Spawn the kthreads that handle each RCU flavor's grace periods
+ * and the no-cb and boost kthreads.
*/
-static int __init rcu_spawn_gp_kthread(void)
+static int __init rcu_spawn_kthreads(void)
{
unsigned long flags;
struct rcu_node *rnp;
@@ -3523,7 +3524,7 @@ static int __init rcu_spawn_gp_kthread(void)
rcu_spawn_boost_kthreads();
return 0;
}
-early_initcall(rcu_spawn_gp_kthread);
+early_initcall(rcu_spawn_kthreads);
/*
* This function is invoked towards the end of the scheduler's initialization
--
2.0.0.rc2
--
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 16/16] rcu: kvm.sh: Fix error when you pass --cpus argument
When you pass --cpus argument to kvm.sh, it errors out as it assumes you have
all the requires CPUs to run a batch. This commit fixes this along with a minor
comment fix.
Signed-off-by: Pranith Kumar
---
tools/testing/selftests/rcutorture/bin/kvm.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
b/tools/testing/selftests/rcutorture/bin/kvm.sh
index 36534f9..1128d85 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -214,7 +214,7 @@ END {
batch = 0;
nc = -1;
- # Each pass through the following loop creates on test batch
+ # Each pass through the following loop creates one test batch
# that can be executed concurrently given ncpus. Note that a
# given test that requires more than the available CPUs will run in
# their own batch. Such tests just have to make do with what
@@ -228,7 +228,7 @@ END {
for (i = 0; i < njobs; i++) {
if (done[i])
continue; # Already part of a batch.
- if (nc >= cpus[i] || nc == ncpus) {
+ if (nc >= cpus[i]) {
# This test fits into the current batch.
done[i] = batch;
--
2.0.0.rc2
--
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 08/16] rcu: Clean up rcu_spawn_one_boost_kthread()
Even though we pass on the return value of kthread_create, we do not
use it anywhere. This commit uses kthread_run() and adds BUG_ON() when we create
the kthread and changes the return type of this function to void.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.h| 2 +-
kernel/rcu/tree_plugin.h | 15 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 9643f10..fc21899 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -569,7 +569,7 @@ static void invoke_rcu_callbacks_kthread(void);
static bool rcu_is_callbacks_kthread(void);
#ifdef CONFIG_RCU_BOOST
static void rcu_preempt_do_callbacks(void);
-static int rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
+static void rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
struct rcu_node *rnp);
#endif /* #ifdef CONFIG_RCU_BOOST */
static void __init rcu_spawn_boost_kthreads(void);
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index dd53247..4d42791 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1330,7 +1330,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node
*rnp)
* already exist. We only create this kthread for preemptible RCU.
* Returns zero if all is well, a negated errno otherwise.
*/
-static int rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
+static void rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
struct rcu_node *rnp)
{
int rnp_index = rnp - >node[0];
@@ -1347,18 +1347,15 @@ static int rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
rsp->boost = 1;
if (rnp->boost_kthread_task != NULL)
return 0;
- t = kthread_create(rcu_boost_kthread, (void *)rnp,
+ t = kthread_run(rcu_boost_kthread, (void *)rnp,
"rcub/%d", rnp_index);
- if (IS_ERR(t))
- return PTR_ERR(t);
+ BUG_ON(IS_ERR(t));
raw_spin_lock_irqsave(>lock, flags);
smp_mb__after_unlock_lock();
rnp->boost_kthread_task = t;
raw_spin_unlock_irqrestore(>lock, flags);
sp.sched_priority = RCU_BOOST_PRIO;
sched_setscheduler_nocheck(t, SCHED_FIFO, );
- wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
- return 0;
}
static void rcu_kthread_do_work(void)
@@ -1476,10 +1473,10 @@ static void __init rcu_spawn_boost_kthreads(void)
per_cpu(rcu_cpu_has_work, cpu) = 0;
BUG_ON(smpboot_register_percpu_thread(_cpu_thread_spec));
rnp = rcu_get_root(rcu_state_p);
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
if (rcu_num_nodes > 1) {
rcu_for_each_leaf_node(rcu_state_p, rnp)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
}
@@ -1490,7 +1487,7 @@ static void rcu_prepare_kthreads(int cpu)
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
if (rcu_scheduler_fully_active)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
#else /* #ifdef CONFIG_RCU_BOOST */
--
2.0.0.rc2
--
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 14/16] rcu: Remove redundant checks for rcu_scheduler_fully_active
rcu_scheduler_fully_active is set to true early in the boot process.
The check for this flag is only needed in rcu_prepare_kthreads() as this
function is called before the above flag is set. All other checks are redundant.
Hence this commit removes those redundant checks.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 9a50e1d..541c776 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1341,7 +1341,7 @@ static void rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
if (_preempt_state != rsp)
return 0;
- if (!rcu_scheduler_fully_active || rnp->qsmaskinit == 0)
+ if (rnp->qsmaskinit == 0)
return 0;
rsp->boost = 1;
@@ -1486,9 +1486,10 @@ static void rcu_prepare_kthreads(int cpu)
struct rcu_node *rnp = rdp->mynode;
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
- if (rcu_scheduler_fully_active)
- rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ if (!rcu_scheduler_fully_active)
+ return;
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
rcu_spawn_all_nocb_kthreads(cpu);
}
@@ -2508,9 +2509,8 @@ static void rcu_spawn_all_nocb_kthreads(int cpu)
{
struct rcu_state *rsp;
- if (rcu_scheduler_fully_active)
- for_each_rcu_flavor(rsp)
- rcu_spawn_one_nocb_kthread(rsp, cpu);
+ for_each_rcu_flavor(rsp)
+ rcu_spawn_one_nocb_kthread(rsp, cpu);
}
/*
--
2.0.0.rc2
--
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 13/16] rcu: Spawn nocb kthreads from rcu_prepare_kthreads()
rcu_prepare_kthreads() is called when a CPU hotplug event happens. We can also spawn the nocb kthreads from this function. This is preparation for the next patch which remove the redundant check for rcu_scheduler_fully_active. This commit moves the spawning of nocb kthreads to rcu_prepare_kthreads(). Signed-off-by: Pranith Kumar --- kernel/rcu/tree.c| 1 - kernel/rcu/tree_plugin.h | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index afd54e2..4dc449c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3453,7 +3453,6 @@ static int rcu_cpu_notify(struct notifier_block *self, case CPU_UP_PREPARE_FROZEN: rcu_prepare_cpu(cpu); rcu_prepare_kthreads(cpu); - rcu_spawn_all_nocb_kthreads(cpu); break; case CPU_ONLINE: case CPU_DOWN_FAILED: diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 4d42791..9a50e1d 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1488,6 +1488,8 @@ static void rcu_prepare_kthreads(int cpu) /* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */ if (rcu_scheduler_fully_active) rcu_spawn_one_boost_kthread(rcu_state_p, rnp); + + rcu_spawn_all_nocb_kthreads(cpu); } #else /* #ifdef CONFIG_RCU_BOOST */ -- 2.0.0.rc2 -- 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 15/16] rcu: Check for a nocb cpu before trying to spawn nocb threads
This commit tries to spawn nocb kthreads only when the CPU is marked as a nocb cpu. This is a minor optimization. Signed-off-by: Pranith Kumar --- kernel/rcu/tree_plugin.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 541c776..8abff0a 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1490,7 +1490,8 @@ static void rcu_prepare_kthreads(int cpu) return; rcu_spawn_one_boost_kthread(rcu_state_p, rnp); - rcu_spawn_all_nocb_kthreads(cpu); + if (rcu_is_nocb_cpu(cpu)) + rcu_spawn_all_nocb_kthreads(cpu); } #else /* #ifdef CONFIG_RCU_BOOST */ -- 2.0.0.rc2 -- 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 10/16] rcu: Check for RCU_FLAG_GP_INIT bit in gp_flags for spurious wakeup
rcu_gp_init() is called once the gp_kthread wakes up on the condition that
the init bit is set in the gp_flags. For a spurious wakeup we need to check that
it is actually set. This commit ensures that the RCU_GP_FLAG_INIT bit is set in
gp_flags.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 8d598a2..f8847d9 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1600,7 +1600,7 @@ static int rcu_gp_init(struct rcu_state *rsp)
rcu_bind_gp_kthread();
raw_spin_lock_irq(>lock);
smp_mb__after_unlock_lock();
- if (!ACCESS_ONCE(rsp->gp_flags)) {
+ if (!(ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_INIT)) {
/* Spurious wakeup, tell caller to go back to sleep. */
raw_spin_unlock_irq(>lock);
return 0;
--
2.0.0.rc2
--
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: linux-next: manual merge of the drm-intel tree with the drm tree
On Wed, Jul 23, 2014 at 5:06 AM, Stephen Rothwell wrote: > P.S. Daniel, that drm-intel tree commit has no Signed-off-by from its > author ... Oops, fixed. Thanks for pointing this out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] m68k: Remove printk statement and add return statement in q40ints.c
On Wed, Jul 23, 2014 at 12:54 AM, Guenter Roeck wrote:
> On 07/22/2014 09:08 PM, Nicholas Krause wrote:
>>
>> This removes the printk statement for irqs not defined by the hardware in
>> function q40_irq_startup and instead returns -ENXIO as stated by the fix
>> me message.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> arch/m68k/q40/q40ints.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
>> index 513f9bb..86f05c0 100644
>> --- a/arch/m68k/q40/q40ints.c
>> +++ b/arch/m68k/q40/q40ints.c
>> @@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data
>> *data)
>> switch (irq) {
>> case 1: case 2: case 8: case 9:
>> case 11: case 12: case 13:
>> - printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
>> irq);
>> - /* FIXME return -ENXIO; */
>> + return -ENXIO;
>
>
> Returning -ENXIO from a function returning an unsigned int isn't really very
> helpful,
> don't you think ?
>
> With all those FIXMEs, you might want to keep in mind that there is
> typically a
> good reason for it. If it was as easy as your proposed fix, you can assume
> that the FIXME would not have been there in the first place.
>
> Guenter
>
Sorry Guenter,
That's fine. can I can change the return type of the function or is
that going to break things?
Nick
--
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 0/5] futex: introduce an optimistic spinning futex
On Mon, 2014-07-21 at 09:42 -0700, Andi Kleen wrote: > FWIW the main problem is currently that switch-through-idle is so > slow. I think improving that would give a boost to far more > situations. Two high frequency idle enter/exit suckage spots: 1) nohz (tick) - it's expensive to start/stop tick on every micro-idle, throttle it or something. 2) ondemand governor - tweak silly default settings to reflect the reality that we routinely schedule communicating threads cross core. (3. seek/destroy fastpath cycles, damn things multiply over time) -Mike -- 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: RE: [PATCH] lib : lz4 using put_unaligned_le16 instead of put_unaligned
> If your patch is applied, the data which is compressed > by your big-endian system won't be decompressed in other little-endian system. I can't understand this. Please, could you explain this more ? My patch just replaces put_unaligned with put_unaligned_le16. and this just write compression data in little endian byte-order regardless of machine byte-order, like ext file system. So, i guess there is no problem what you pointed Thanks.
Re: [PATCH] m68k: Remove printk statement and add return statement in q40ints.c
On 07/22/2014 09:08 PM, Nicholas Krause wrote:
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
Returning -ENXIO from a function returning an unsigned int isn't really very
helpful,
don't you think ?
With all those FIXMEs, you might want to keep in mind that there is typically a
good reason for it. If it was as easy as your proposed fix, you can assume
that the FIXME would not have been there in the first place.
Guenter
--
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 powerpc.git merge branch
Hi Linus ! Here is a handful of powerpc fixes for 3.16. They are all pretty simple and self contained and should still make this release. Cheers, Ben. The following changes since commit f56029410a13cae3652d1f34788045c40a13ffc7: powerpc/perf: Never program book3s PMCs with values >= 0x8000 (2014-07-11 13:50:47 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 6f5405bc2ee0102bb3856e2cdea64ff415db2e0c: powerpc: use _GLOBAL_TOC for memmove (2014-07-22 15:56:04 +1000) Aneesh Kumar K.V (1): powerpc: subpage_protect: Increase the array size to take care of 64TB Joel Stanley (1): powerpc: Disable doorbells on Power8 DD1.x Li Zhong (1): powerpc: use _GLOBAL_TOC for memmove Paul Mackerras (1): powerpc: Fix bugs in emulate_step() Tyrel Datwyler (1): powerpc/pseries: dynamically added OF nodes need to call of_node_init arch/powerpc/include/asm/cputable.h | 1 + arch/powerpc/include/asm/mmu-hash64.h | 3 ++- arch/powerpc/kernel/cputable.c| 20 arch/powerpc/lib/mem_64.S | 2 +- arch/powerpc/lib/sstep.c | 10 +- arch/powerpc/platforms/pseries/dlpar.c| 1 + arch/powerpc/platforms/pseries/reconfig.c | 1 + 7 files changed, 31 insertions(+), 7 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/
Work Ideas
I am working for some work in the kernel. I am new to the kernel but I am read Robert Love's book and another book on device drivers, so my theory is good is prettygood other then not being up to date on the newest features in the latest kernels. If anyone wants to give me something to do I don't mind what type of work . The one problem is I don'thave a budget for test hardware, so if hardware testing is needed someone else will need to test for me on the hardware that testing is needed . I am not asking for pay just to help you guys out more as some of my fix mes let's say wasted previous time. Cheers Nick :) -- 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 v2 14/16] cpufreq: Add cpufreq driver for Tegra124
On 21 July 2014 21:09, Tuomas Tynkkynen wrote:
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 7364a53..df3c73e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -244,6 +244,7 @@ config ARM_SPEAR_CPUFREQ
> config ARM_TEGRA_CPUFREQ
> bool "TEGRA CPUFreq support"
> depends on ARCH_TEGRA
> + depends on GENERIC_CPUFREQ_CPU0
Wouldn't this also disturb the existing cpufreq driver for earlier
tegra platforms? i.e. we don't need cpufreq-cpu0 for them
atleast as of now.
> default y
> help
> This adds the CPUFreq driver support for TEGRA SOCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index db6d9a2..3437d24 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
> obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra-cpufreq.o
> +obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra124-cpufreq.o
Maybe, you can update the same line if you want.
> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
>
>
> ##
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> b/drivers/cpufreq/tegra124-cpufreq.c
> +static struct cpufreq_frequency_table *freq_table;
> +
> +static struct device *cpu_dev;
> +static struct clk *cpu_clk;
> +static struct clk *pllp_clk;
> +static struct clk *pllx_clk;
> +static struct clk *dfll_clk;
The routines in this file are going to be called just once at boot, right?
In that case we are actually wasting some memory by creating globals.
Probably just move all these in a struct and allocate it at runtime.
> +static int tegra124_cpu_switch_to_dfll(void)
> +{
> + struct clk *original_cpu_clk_parent;
> + unsigned long rate;
> + struct dev_pm_opp *opp;
> + int ret;
> +
> + rate = clk_get_rate(cpu_clk);
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, );
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> +
> + ret = clk_set_rate(dfll_clk, rate);
> + if (ret)
> + return ret;
> +
> + original_cpu_clk_parent = clk_get_parent(cpu_clk);
> + clk_set_parent(cpu_clk, pllp_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(dfll_clk);
> + if (ret)
> + goto out_switch_to_original_parent;
> +
> + clk_set_parent(cpu_clk, dfll_clk);
> +
> + return 0;
> +
> +out_switch_to_original_parent:
> + clk_set_parent(cpu_clk, original_cpu_clk_parent);
> +
> + return ret;
> +}
> +
> +static struct platform_device_info cpufreq_cpu0_devinfo = {
> + .name = "cpufreq-cpu0",
> +};
> +
> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev)
> + return -ENODEV;
> +
Shouldn't we do a of_node_get() here?
> + cpu_clk = of_clk_get_by_name(cpu_dev->of_node, "cpu_g");
> + if (IS_ERR(cpu_clk))
> + return PTR_ERR(cpu_clk);
> +
> + dfll_clk = of_clk_get_by_name(cpu_dev->of_node, "dfll");
> + if (IS_ERR(dfll_clk)) {
> + ret = PTR_ERR(dfll_clk);
> + goto out_put_cpu_clk;
> + }
> +
> + pllx_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_x");
> + if (IS_ERR(pllx_clk)) {
> + ret = PTR_ERR(pllx_clk);
> + goto out_put_dfll_clk;
> + }
> +
> + pllp_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_p");
> + if (IS_ERR(pllp_clk)) {
> + ret = PTR_ERR(pllp_clk);
> + goto out_put_pllx_clk;
> + }
> +
> + ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
> + if (ret)
> + goto out_put_pllp_clk;
Why do you need this? cpufreq-cpu0 also does it and this freq_table is
just not getting used at all then.
> +
> + ret = tegra124_cpu_switch_to_dfll();
> + if (ret)
> + goto out_free_table;
> +
> + platform_device_register_full(_cpu0_devinfo);
> +
> + return 0;
> +
> +out_free_table:
> + dev_pm_opp_free_cpufreq_table(cpu_dev, _table);
> +out_put_pllp_clk:
> + clk_put(pllp_clk);
> +out_put_pllx_clk:
> + clk_put(pllx_clk);
> +out_put_dfll_clk:
> + clk_put(dfll_clk);
> +out_put_cpu_clk:
> + clk_put(cpu_clk);
> +
> + return ret;
> +}
> +
> +static struct platform_driver tegra124_cpufreq_platdrv = {
> + .driver = {
> + .name = "cpufreq-tegra124",
> + .owner = THIS_MODULE,
> + },
> + .probe = tegra124_cpufreq_probe,
> +};
> +
> +static const struct of_device_id soc_of_matches[] = {
> + {
smp-cmp.c: CDFIXMES
Are the lines with CDFIXME still needed? If not please tell me as I will send in a patch removing these two from this file in order to help you guys out :). Cheers Nick -- 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] checkpatch: Fix false positives for --strict "space after cast" test
commit 89da401f6cff ("checkpatch: improve "no space after cast" test")
in -next improved the cast test for non pointer types, but also
introduced false positives for some types of static inlines.
Add a test for an open brace to the exclusions to avoid these
false positives.
Reported-by: Hartley Sweeten
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dc72a9b..7dcfc75 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2418,7 +2418,7 @@ sub process {
}
}
- if ($line =~ /^\+.*\(\s*$Type\s*\)[
\t]+(?!$Assignment|$Arithmetic)/) {
+ if ($line =~ /^\+.*\(\s*$Type\s*\)[
\t]+(?!$Assignment|$Arithmetic|{)/) {
if (CHK("SPACING",
"No space is necessary after a cast\n" .
$herecurr) &&
$fix) {
--
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] microblaze: Add comment for defines
This adds a comment for and removes a fix me by labeling these
defines as memory cache definitions.
Signed-off-by: Nicholas Krause
---
arch/microblaze/include/asm/pvr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/include/asm/pvr.h
b/arch/microblaze/include/asm/pvr.h
index 4bbdb4c..441f3a0 100644
--- a/arch/microblaze/include/asm/pvr.h
+++ b/arch/microblaze/include/asm/pvr.h
@@ -186,7 +186,7 @@ struct pvr_s {
#define PVR_DCACHE_USE_FSL(_pvr) (_pvr.pvr[5] & PVR5_DCACHE_USE_FSL_MASK)
#define PVR_DCACHE_ALLOW_WR(_pvr) \
(_pvr.pvr[5] & PVR5_DCACHE_ALLOW_WR_MASK)
-/* FIXME two shifts on one line needs any comment */
+/* memory caches */
#define PVR_DCACHE_LINE_LEN(_pvr) \
(1 << ((_pvr.pvr[5] & PVR5_DCACHE_LINE_LEN_MASK) >> 21))
#define PVR_DCACHE_BYTE_SIZE(_pvr) \
--
1.9.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/
Re: Random panic in load_balance() with 3.16-rc
On Tue, Jul 22, 2014 at 8:53 PM, Michel Dänzer wrote: > > Just happened again with the same change on top of 3.16-rc6. The (maybe) related bugzilla entry is just odd. Bruno Wolff reports that the BUG_ON() in his added patch triggers: + cpumask_clear(sched_group_cpus(sg)); + sg->sgc->capacity = 0; + BUG_ON(!cpumask_empty(sched_group_cpus(sg))); where it *just* did a cpumask_clear(), and now the BUG_ON() triggers that it's no longer empty? That would imply an allocation error, but all the sched groups seem to be properly allocated with the proper addition of cpumask_size(). And his config file even has NR_CPUS being 32, so it should be a single word of bitmap, which triggers all the simple code. Completely insane, in other words. Linus -- 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 v3 0/4] dra7: Add PCIe support
Hello Bjorn, > -Original Message- > From: Bjorn Helgaas [mailto:bhelg...@google.com] > Sent: Wednesday, July 23, 2014 3:03 AM > To: Kishon Vijay Abraham I > Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux- > p...@vger.kernel.org; jg1@samsung.com; Mohit KUMAR DCG; linux- > ker...@vger.kernel.org; grant.lik...@linaro.org > Subject: Re: [PATCH v3 0/4] dra7: Add PCIe support > > On Thu, Jul 17, 2014 at 02:30:39PM +0530, Kishon Vijay Abraham I wrote: > > Changes from v2: > > * Added myself as MAINTAINER of pcie dra7xx driver [...] > > I applied these to pci/host-designware for v3.17. This will not be in my > first > pull request because I'm going on vacation and won't have time to get > everything through -next and tagged. But I'm planning a second pull request > that will include this. > > Mohit, I applied your ack of "use untranslated address" from the v1 posting > (your mail of Jul 09) to the corresponding patch here, since Kishon didn't > carry it forward. Let me know if that's not OK. - yes, OK with me. Thanks Mohit > > I also squashed the last two patches into one so the DT binding > documentation goes along with the dra7xx driver addition. > > Bjorn -- 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 4/4] aio: use iovec array rather than the single one
Hi Jeff,
On 07/22/2014 11:20 PM, Jeff Moyer wrote:
> Gu Zheng writes:
>
>> use an iovec array rather than the single one, so that we can avoid
>> to alloc more iovecs buffer in small(< 8) PREADV/PWRITEV cases.
>
> I did some basic functional testing of this change and the change in
> patch 1/4. That testing included using aio-stress to drive queue depths
> of 7, 8 and 9, and verify that it didn't fall over. I also ran xfstests
> './check -g aio', and libaio's 'make partcheck'.
>
> The change looks good to me, and passed testing, so:
>
> Reviewed-by: Jeff Moyer
Thanks for your review and test.
>
> However, I still would like some comment on the reasoning behind it, and
> whether there is some measurable performance advantage for some
> workload. Additionally, it would be nice if that comment made its way
> into the commit message.
I'll add more useful info, and send it out later.
Thanks,
Gu
>
> Cheers,
> Jeff
>
>>
>> Signed-off-by: Gu Zheng
>> ---
>> fs/aio.c | 10 +-
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 0cd0479..ef21efe 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -1260,12 +1260,12 @@ static ssize_t aio_setup_vectored_rw(struct kiocb
>> *kiocb,
>> if (compat)
>> ret = compat_rw_copy_check_uvector(rw,
>> (struct compat_iovec __user *)buf,
>> -*nr_segs, 1, *iovec, iovec);
>> +*nr_segs, UIO_FASTIOV, *iovec, iovec);
>> else
>> #endif
>> ret = rw_copy_check_uvector(rw,
>> (struct iovec __user *)buf,
>> -*nr_segs, 1, *iovec, iovec);
>> +*nr_segs, UIO_FASTIOV, *iovec, iovec);
>> if (ret < 0)
>> return ret;
>>
>> @@ -1302,7 +1302,7 @@ static ssize_t aio_run_iocb(struct kiocb *req,
>> unsigned opcode,
>> fmode_t mode;
>> aio_rw_op *rw_op;
>> rw_iter_op *iter_op;
>> -struct iovec inline_vec, *iovec = _vec;
>> +struct iovec inline_vecs[UIO_FASTIOV], *iovec = inline_vecs;
>> struct iov_iter iter;
>>
>> switch (opcode) {
>> @@ -1337,7 +1337,7 @@ rw_common:
>> if (!ret)
>> ret = rw_verify_area(rw, file, >ki_pos,
>> req->ki_nbytes);
>> if (ret < 0) {
>> -if (iovec != _vec)
>> +if (iovec != inline_vecs)
>> kfree(iovec);
>> return ret;
>> }
>> @@ -1384,7 +1384,7 @@ rw_common:
>> return -EINVAL;
>> }
>>
>> -if (iovec != _vec)
>> +if (iovec != inline_vecs)
>> kfree(iovec);
>>
>> if (ret != -EIOCBQUEUED) {
> .
>
--
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 3/4] aio: fix some comments
On 07/22/2014 10:12 PM, Benjamin LaHaise wrote: > On Tue, Jul 22, 2014 at 10:40:03AM +0800, Gu Zheng wrote: >> Signed-off-by: Gu Zheng > > Again, you're missing a commit message here. Please resubmit with a commit > message. Got it, I'll resend it later. Thanks, Gu > > -ben > >> --- >> fs/aio.c |7 +++ >> 1 files changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/fs/aio.c b/fs/aio.c >> index 1dc6158..0cd0479 100644 >> --- a/fs/aio.c >> +++ b/fs/aio.c >> @@ -1037,7 +1037,7 @@ void aio_complete(struct kiocb *iocb, long res, long >> res2) >> } >> EXPORT_SYMBOL(aio_complete); >> >> -/* aio_read_events >> +/* aio_read_events_ring >> * Pull an event off of the ioctx's event ring. Returns the number of >> * events fetched >> */ >> @@ -1289,9 +1289,8 @@ static ssize_t aio_setup_single_vector(struct kiocb >> *kiocb, >> } >> >> /* >> - * aio_setup_iocb: >> - * Performs the initial checks and aio retry method >> - * setup for the kiocb at the time of io submission. >> + * aio_run_iocb: >> + * Performs the initial checks and io submission. >> */ >> static ssize_t aio_run_iocb(struct kiocb *req, unsigned opcode, >> char __user *buf, bool compat) >> -- >> 1.7.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/
[PATCH] m68k: Remove printk statement and add return statement in q40ints.c
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
}
return 0;
}
--
1.9.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/
Re: [PATCH 0/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth, On Tuesday 22 July 2014 10:15 PM, Nishanth Menon wrote: > On 07/16/2014 03:36 AM, Lokesh Vutla wrote: >> This series add seperate ocp interface lists that are specific to dra74x >> and dra72x, and moving USB OTG SS4 to dra74x only since its not present >> in dra72x. Without this USB OTG SS4 hwmod gives an abort on dra72x. >> >> Adding support for soc_is_dra74x() and soc_is_dra72x() in order to >> differentiate >> between dra74x and dra72x and pass the respective ocp interface lists. >> >> Verified on dra74x evm and dra72x evm using 3.16-rc5 based mainline kernel. >> >> Before: >> dra74x : http://paste.ubuntu.com/7802364/ >> dra72x : http://paste.ubuntu.com/7802334/ (Kernel panic) >> >> After- >> dra74x : http://paste.ubuntu.com/7802340/ >> dra72x : http://paste.ubuntu.com/7802338/ (booted) >> >> Rajendra Nayak (2): >> ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() >> varients >> ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists >> >> arch/arm/mach-omap2/omap_hwmod.c |3 +++ >> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 -- >> arch/arm/mach-omap2/soc.h |7 +++ >> 3 files changed, 30 insertions(+), 2 deletions(-) >> > Tested-by: Nishanth Menon Thanks.. > > BUT, I suggest a follow up series to do exactly the same (moving stuff > that are not common from dra7.dtsi to dra72x.dtsi and 74x.dtsi) as > well to ensure that dts indicates exactly the same information (only > the applicable IPs are present in dts). The separation of dra72x.dtsi and dra74x.dtsi is already happened and the patch is already present in mainline[1]. Looks like usb_otg_ss4 is still present in dra7.dtsi, but this should go into dra74x.dtsi. I ll take it up. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=38b248db60e32734417534b57f9ab687c445113a Thanks and regards, Lokesh > -- 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 2/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth,
On Tuesday 22 July 2014 10:20 PM, Nishanth Menon wrote:
> On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
>> From: Rajendra Nayak
>>
>> To deal with IPs which are specific to dra74x and dra72x, maintain seperate
>> ocp interface lists, while keeping the common list for all common IPs.
>>
>> Move USB OTG SS4 to dra74x only list since its unavailable in
>> dra72x and is giving an abort during boot. The dra72x only list
>> is empty for now and a placeholder for future hwmod additions which
>> are specific to dra72x.
>>
>> Fixes: d904b38 ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
>
> please use a format as following:
> Fixes: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
>
>> Reported-by: Keerthy
>> Signed-off-by: Rajendra Nayak
>> Signed-off-by: Lokesh Vutla
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c |3 +++
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 --
>> 2 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 6c074f3..14f8370 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -3345,6 +3345,9 @@ int __init omap_hwmod_register_links(struct
>> omap_hwmod_ocp_if **ois)
>> if (!ois)
>> return 0;
>>
>> +if (ois[0] == NULL) /*empty list*/
> /* Empty list */ ?
>> +return 0;
>> +
>
> This change looks like a different patch?
Since we are introducing empty lists in this patch, I guess
this can go in the same patch.
>
>> if (!linkspace) {
>> if (_alloc_linkspace(ois)) {
>> pr_err("omap_hwmod: could not allocate link space\n");
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 284324f..c95033c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -35,6 +35,7 @@
>> #include "i2c.h"
>> #include "mmc.h"
>> #include "wd_timer.h"
>> +#include "soc.h"
>>
>> /* Base offset for all DRA7XX interrupts external to MPUSS */
>> #define DRA7XX_IRQ_GIC_START32
>> @@ -2705,7 +2706,6 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> _l4_per3__usb_otg_ss1,
>> _l4_per3__usb_otg_ss2,
>> _l4_per3__usb_otg_ss3,
>> -_l4_per3__usb_otg_ss4,
>> _l3_main_1__vcp1,
>> _l4_per2__vcp1,
>> _l3_main_1__vcp2,
>> @@ -2714,8 +2714,26 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> NULL,
>> };
>>
>> +static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
>> +_l4_per3__usb_otg_ss4,
>> +NULL,
>> +};
>> +
>> +static struct omap_hwmod_ocp_if *dra72x_hwmod_ocp_ifs[] __initdata = {
>> +NULL,
>> +};
>> +
>> int __init dra7xx_hwmod_init(void)
>> {
>> +int ret;
>> +
>> omap_hwmod_init();
>> -return omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
>> +ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
> if (ret)
> goto out;
>> +
>> +if (!ret && soc_is_dra74x())
> no need of !ret
>> +return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
>> +else if (!ret && soc_is_dra72x())
> no need of else and !ret
>> +return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
>> +
>
> out:
Ok. Will do this and repost.
Thanks and regards,
Lokesh
>> +return ret;
>> }
>>
>
>
--
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 v3 6/7] ACPI: Add support to force header inclusion rules for .
Hi Lv, On 2014-7-16 16:58, Lv Zheng wrote: > As there is only CONFIG_ACPI=n processing in the , it is not > safe to include directly for source out of Linux ACPI > subsystems. > > This patch adds error messaging to warn developers of such wrong > inclusions. Thanks for doing this, it makes life much easier for people who want to use ACPI but not so familiar with ACPI. Best Regards Hanjun -- 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: Random panic in load_balance() with 3.16-rc
On 22.07.2014 15:13, Michel Dänzer wrote: > On 18.07.2014 18:29, Michel Dänzer wrote: >> On 17.07.2014 16:58, Peter Zijlstra wrote: >>> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote: I've been running into the panic captured in the attached picture (hope it's legible) randomly while running 3.16-rc4 and -rc5. I haven't noticed any pattern as to when it happens; at least once it happened while the box was basically sitting idle. dmesg, .config and /proc/cpuinfo attached as well; let me know if you need anything else. >>> >>> Does lkml.kernel.org/r/20140716145546.ga6...@wolff.to cure things? >> >> Yes, adding back >> >>cpumask_clear(sched_group_cpus(sg)); >> >> seems to do the trick, thanks. > > I'm afraid it happened again with 3.16-rc5 plus the above change. It > seemed to last longer than before, but maybe that was just luck. > > Going to try 3.16-rc6 now. Just happened again with the same change on top of 3.16-rc6. Are there any other potential fixes yet? I hope this problem is on the radar as a showstopper for 3.16. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer signature.asc Description: OpenPGP digital signature
[PATCH net-next v3 0/2] cleanup for Realtek 8139CP
From: Varka Bhadram changes since v2: - making version info print once. changes sice v1: - remove unused varible warning Varka Bhadram (2): ethernet: realtek: use module_pci_driver ethernet: realtek: use pci_device_id drivers/net/ethernet/realtek/8139cp.c | 36 + 1 file changed, 9 insertions(+), 27 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/
Re: [f2fs-dev] f2fs: Possible use-after-free when umount filesystem
Hi, On 07/23/2014 10:12 AM, Chao Yu wrote: > Hi Andrey Gu, > >> -Original Message- >> From: Andrey Tsyvarev [mailto:tsyva...@ispras.ru] >> Sent: Tuesday, July 22, 2014 6:04 PM >> To: Gu Zheng >> Cc: Jaegeuk Kim; linux-kernel; Alexey Khoroshilov; >> linux-f2fs-de...@lists.sourceforge.net >> Subject: Re: [f2fs-dev] f2fs: Possible use-after-free when umount filesystem >> >> Hi Gu, >> Investigation shows, that f2fs_evict_inode, when called for 'meta_inode', uses >> invalidate_mapping_pages() for 'node_inode'. But 'node_inode' is deleted before 'meta_inode' in f2fs_put_super via iput(). It seems that in common usage scenario this use-after-free is benign, because 'node_inode' >> remains partially valid data even after kmem_cache_free(). But things may change if, while 'meta_inode' is evicted in one f2fs filesystem, another (mounted) >> f2fs filesystem requests inode from cache, and formely 'node_inode' of the first filesystem is returned. >>> The analysis seems reasonable. Have you tried to swap the reclaim order of >>> node_inde >>> and meta_inode? >>> >>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c >>> index 870fe19..e114418 100644 >>> --- a/fs/f2fs/super.c >>> +++ b/fs/f2fs/super.c >>> @@ -430,8 +430,8 @@ static void f2fs_put_super(struct super_block *sb) >>> if (sbi->s_dirty && get_pages(sbi, F2FS_DIRTY_NODES)) >>> write_checkpoint(sbi, true); >>> >>> - iput(sbi->node_inode); >>> iput(sbi->meta_inode); >>> + iput(sbi->node_inode); >>> >>> /* destroy f2fs internal modules */ >>> destroy_node_manager(sbi); >>> >>> Thanks, >>> Gu >> >> With reclaim order of node_inode and meta_inode swapped, use-after-free >> error disappears. >> >> But shouldn't initialization order of these inodes be swapped too? >> As meta_inode uses node_inode, it seems logical that it should be >> initialized after it. The initialization order dose not affect anything, so swapping the order dose not make more sense here. > > IMO, it's not easy to exchange order of initialization between meta_inode and > node_inode, because we should use meta_inode in get_valid_checkpoint for valid > cp first for usual verification, then init node_inode. Yeah, but I think just moving node_inode's initialization to the front of meta_inode dose not break anything. > > As I checked, nids for both meta_inode and node_inode are reservation, so > it's not > necessary for us to invalidate pages which will never alloced. > > How about skipping it as following? It seems the right way to fix this issue. To Andrey: Could you please try this one? Thanks, Gu > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > index 2cf6962..cafba3c 100644 > --- a/fs/f2fs/inode.c > +++ b/fs/f2fs/inode.c > @@ -273,7 +273,7 @@ void f2fs_evict_inode(struct inode *inode) > > if (inode->i_ino == F2FS_NODE_INO(sbi) || > inode->i_ino == F2FS_META_INO(sbi)) > - goto no_delete; > + goto out_clear; > > f2fs_bug_on(get_dirty_dents(inode)); > remove_dirty_dir_inode(inode); > @@ -295,6 +295,7 @@ void f2fs_evict_inode(struct inode *inode) > > sb_end_intwrite(inode->i_sb); > no_delete: > - clear_inode(inode); > invalidate_mapping_pages(NODE_MAPPING(sbi), inode->i_ino, inode->i_ino); > +out_clear: > + clear_inode(inode); > } > >> >> -- >> Best regards, >> >> Andrey Tsyvarev >> Linux Verification Center, ISPRAS >> web:http://linuxtesting.org >> >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> ___ >> Linux-f2fs-devel mailing list >> linux-f2fs-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > -- 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 net-next v3 1/2] ethernet: realtek: use module_pci_driver
From: Varka Bhadram
This patch converts to use the macro module_pci_driver, which makes
the code smaller and simpler.
Previously in this driver we are having driver version info will be
printed log buffer based on whether the driver selected as module
or statically into image itself. By using the module_pci_driver that
part of the code removed. For the first time of the device init,
we are making the version info to be printed once.
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/realtek/8139cp.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index 2bc728e..be101ca 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1887,11 +1887,7 @@ static int cp_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
resource_size_t pciaddr;
unsigned int addr_len, i, pci_using_dac;
-#ifndef MODULE
- static int version_printed;
- if (version_printed++ == 0)
- pr_info("%s", version);
-#endif
+ pr_info_once("%s", version);
if (pdev->vendor == PCI_VENDOR_ID_REALTEK &&
pdev->device == PCI_DEVICE_ID_REALTEK_8139 && pdev->revision <
0x20) {
@@ -2121,18 +2117,4 @@ static struct pci_driver cp_driver = {
#endif
};
-static int __init cp_init (void)
-{
-#ifdef MODULE
- pr_info("%s", version);
-#endif
- return pci_register_driver(_driver);
-}
-
-static void __exit cp_exit (void)
-{
- pci_unregister_driver (_driver);
-}
-
-module_init(cp_init);
-module_exit(cp_exit);
+module_pci_driver(cp_driver);
--
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 net-next v3 2/2] ethernet: realtek: use pci_device_id
From: Varka Bhadram
This patch use the struct pci_device_id instead of using macro
DEFINE_PCI_DEVICE_TABLE which is deprecated and should not be used.
And also moves these ids after probe and remove functionalities.
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/realtek/8139cp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index be101ca..75b1693 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -382,13 +382,6 @@ static int cp_get_eeprom(struct net_device *dev,
static int cp_set_eeprom(struct net_device *dev,
struct ethtool_eeprom *eeprom, u8 *data);
-static DEFINE_PCI_DEVICE_TABLE(cp_pci_tbl) = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139), },
- { PCI_DEVICE(PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322), },
- { },
-};
-MODULE_DEVICE_TABLE(pci, cp_pci_tbl);
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -2106,6 +2099,13 @@ static int cp_resume (struct pci_dev *pdev)
}
#endif /* CONFIG_PM */
+static const struct pci_device_id cp_pci_tbl[] = {
+{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139), },
+{ PCI_DEVICE(PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322), },
+{ },
+};
+MODULE_DEVICE_TABLE(pci, cp_pci_tbl);
+
static struct pci_driver cp_driver = {
.name = DRV_NAME,
.id_table = cp_pci_tbl,
--
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: [RFC Patch V1 21/30] mm, irqchip: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Jason, Thanks for your review. According to review comments, we need to rework the patch set in another direction and will give up this patch. Regards! Gerry On 2014/7/18 20:40, Jason Cooper wrote: > On Fri, Jul 11, 2014 at 03:37:38PM +0800, Jiang Liu wrote: >> When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id() >> may return a node without memory, and later cause system failure/panic >> when calling kmalloc_node() and friends with returned node id. >> So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with >> memory for the/current cpu. >> >> If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id() >> is the same as cpu_to_node()/numa_node_id(). >> >> Signed-off-by: Jiang Liu >> --- >> drivers/irqchip/irq-clps711x.c |2 +- >> drivers/irqchip/irq-gic.c |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) > > Do you have anything depending on this? Can apply it to irqchip? If > you need to keep it with other changes, > > Acked-by: Jason Cooper > > But please do let me know if I can take it. > > thx, > > Jason. > -- 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 3/5] gpio: make gpiochip_get_desc() gpiolib-private
On 07/22/2014 08:10 PM, Alexandre Courbot wrote: On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. If I implement a gpio chip driver built as module, and I want to use gpiochip_request_own_desc(), how am I supposed to get desc ? I understand that there is still gpio_to_desc(), but I would have thought that desc = gpiochip_get_desc(chip, pin); would be better than desc = gpio_to_desc(chip->base + pin); Not that it makes much of a difference for me, just asking. Actually I was thinking of changing the prototype of gpiochip_request_own_desc(), and your comment definitely strenghtens that idea. gpiochip functions should not work with descriptors, especially since we are going to switch to a multiple-consumer scheme where there won't be any canonical descriptor anymore. Thus, how about turning gpiochip_request_own_desc() into this: struct gpio_desc * gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label); which would basically do both the gpiochip_get_desc() and former gpiochip_request_own_desc() in one call. I think it should satisfy everybody and removes the need to have gpiochip_get_desc() (a not very useful function by itself) exposed out of gpiolib. I will send a patch taking care of this if you agree that makes sense. I think you also plan to remove the capability to retrieve the chip pointer, don't you ? If so, I won't be able to use the function from the pca953x platform init function, since I won't be able to get the pointer to the gpio chip. Even if you don't remove gpiod_to_chip(), things would become a bit messy, since I would first have to convert a pin to a desc and then to the chip pointer. Anyway, that change would mean that exporting gpiochip_request_own_desc or its replacement won't solve one of the problems addressed by my patch anymore, leaving me more or less in the dark :-(. I was thinking about implementing a separate platform driver which would enable me to auto-export (or initialize, if needed) gpio pins from arbitrary gpio drivers to user space. I could make this work with both devicetree data and platform data. Sure, that driver would not have a chance to get accepted upstream, since it would use devicetree data to, in a sense, configure the system, but on the upside it would be independent of gpio API changes, and it would work for _all_ gpio chips, not just for the ones with gpio driver support. Unfortunately this approach doesn't really work either, since exported pin names need to be configured with the chip driver, and can not be selected afterwards when a pin is actually exported. On the other side, would you agree to adding something like gpiod_export_name(), which would export a gpio pin with given name, not using the default or chip->names ? That might help solving at least some of my problems, and I would no longer depend on gpiochip_request_own_desc or any of the related functions. For reference, I currently need the ability to auto-export gpio pins to user space for pca953x, ich, and for various to-be-published gpio drivers used by my employer. Thanks, Guenter -- 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] usb-core: Remove Fix mes in file hcd.c
On Tue, Jul 22, 2014 at 8:44 PM, Sasha Levin wrote: > On 07/18/2014 10:52 PM, Nick Krause wrote: >> On Fri, Jul 18, 2014 at 10:45 PM, Nick Krause wrote: >>> Sorry didn't run spell check. I will resend this patch with the >>> correct information >>> as needed. Thanks for the advice, Sasha. >>> >>> Cheers Nick >>> >>> On Fri, Jul 18, 2014 at 10:36 PM, Sasha Levin wrote: On 07/18/2014 01:34 PM, Nicholas Krause wrote: > I am removing two fix mes in this file as after dicussing then it seems > there is no reason to check against Null for usb_device as it can never > be NULL and this is check is therefore not needed. > > Signed-off-by: Nicholas Krause Please explain exactly why it's not needed, why it can never be NULL, and what prevents it from being NULL. "after dicussing" (do you run spellcheck on your mails?) won't mean anything to someone looking at this commit in a year. Your commit message also mentions usb_device which has nothing to do with your patch. Thanks, Sasha >> >> Sasha , >> Greg seems to have signed it off. >> Cheers Nick > > Greg? > > Even if the patch is correct (and I'm not saying it is) the commit message is > way off. > > > Thanks, > Sasha Sasha, The patch is in the kernel now. I am not going through the trouble of removing it, if you want to fix the commit message go on ahead. Nick -- 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 v4] x86,cpu-hotplug: assign same CPU number to readded CPU
llc_shared_map is not cleared even if CPU is offline or hot removed.
So when hot-plugging CPU and assigning new CPU number to hot-added CPU,
the mask has wrong value. The mask is used by CSF schduler to create
sched_domain. So it breaks CFS scheduler.
Here is a example on my system.
My system has 4 sockets and each socket has 15 cores and HT is enabled.
In this case, each core of sockes is numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119
Then llc_shared_mask of CPU#30 has 0x3fff8001fffc000.
It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.
When hot-removing socket#2 and #3, each core of sockets is numbered
as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains
having 0x3fff8001fffc000.
After that, when hot-adding socket#2 and #3, each core of sockets is
numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119
Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffc000.
It means that last level cache of Socket#2 is shared with CPU#30-59
and 90-104. So the mask has wrong value.
At first, I cleared hot-removed CPU number's bit from llc_shared_map
when hot removing CPU. But Borislav suggested that the problem will
disappear if readded CPU is assigned same CPU number. And llc_shared_map
must not be changed.
So the patch assigns same CPU number to readded CPU by linking CPU
number to APIC ID. And by the patch, the problem disappers.
Signed-off-by: Yasuaki Ishimatsu
Suggested-by: Borislav Petkov
Reviewed-by: Toshi Kani
---
v2: change cpuid to cpunum
v3: fix Borislav's email address of Suggested-by
fix typo (ACPI ID to APIC ID)
v4: change cpu_used_xxx to cpu_number_xxx
---
arch/x86/kernel/apic/apic.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ad28db7..5cecc3b 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -220,6 +220,23 @@ static void apic_pm_activate(void);
static unsigned long apic_phys;
/*
+ * Bind APIC ID to Logical CPU number
+ * Logical CPU number to APIC ID does not change by this array
+ * even if CPU is hotplugged. So don't clear the array even if
+ * CPU is hot-removed
+ */
+static int apicid_to_cpunum[MAX_LOCAL_APIC] = {
+ [0 ... MAX_LOCAL_APIC-1] = -1,
+};
+
+/*
+ * Represent Logical CPU number bound to APIC ID
+ * Don't clear a bit even if CPU is hot-removed
+ */
+static DECLARE_BITMAP(cpu_number_bits, CONFIG_NR_CPUS);
+static struct cpumask *const cpu_number_mask = to_cpumask(cpu_number_bits);
+
+/*
* Get the LAPIC version
*/
static inline int lapic_get_version(void)
@@ -2122,6 +2139,17 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
+static int get_cpunum(int apicid)
+{
+ int cpu;
+
+ cpu = apicid_to_cpunum[apicid];
+ if (cpu < 0)
+ cpu = cpumask_next_zero(-1, cpu_number_mask);
+
+ return cpu;
+}
+
int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
@@ -2199,7 +2227,9 @@ int generic_processor_info(int apicid, int version)
*/
cpu = 0;
} else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+ cpu = get_cpunum(apicid);
+
+ apicid_to_cpunum[apicid] = cpu;
/*
* Validate version
@@ -2228,6 +2258,7 @@ int generic_processor_info(int apicid, int version)
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
apic->x86_32_early_logical_apicid(cpu);
#endif
+ cpumask_set_cpu(cpu, cpu_number_mask);
set_cpu_possible(cpu, true);
set_cpu_present(cpu, true);
--
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 V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Nishanth and Alexander, Thanks for review, will update the comments in next version. Regards! Gerry On 2014/7/22 5:09, Nishanth Aravamudan wrote: > On 21.07.2014 [12:53:33 -0700], Alexander Duyck wrote: >> I do agree the description should probably be changed. There shouldn't be >> any panics involved, only a performance impact as it will be reallocating >> always if it is on a node with no memory. > > Yep, thanks for the review. > >> My intention on this was to make certain that the memory used is from the >> closest node possible. As such I believe this change likely honours that. > > Absolutely, just wanted to make it explicit that it's not a functional > fix, just a performance fix (presuming this shows up at all on systems > that have memoryless NUMA nodes). > > I'd suggest an update to the comments, as well. > > Thanks, > Nish > -- 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] kernel: printk: fix bool assignements
Fix coccinelle warnings.
Signed-off-by: Neil Zhang
---
kernel/printk/printk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 13e839d..89894e5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -881,7 +881,7 @@ static bool __read_mostly ignore_loglevel;
static int __init ignore_loglevel_setup(char *str)
{
- ignore_loglevel = 1;
+ ignore_loglevel = true;
pr_info("debug: ignoring loglevel setting.\n");
return 0;
@@ -948,7 +948,7 @@ static inline void boot_delay_msec(int level)
#endif
#if defined(CONFIG_PRINTK_TIME)
-static bool printk_time = 1;
+static bool printk_time = true;
#else
static bool printk_time;
#endif
@@ -1959,12 +1959,12 @@ int update_console_cmdline(char *name, int idx, char
*name_new, int idx_new, cha
return -1;
}
-bool console_suspend_enabled = 1;
+bool console_suspend_enabled = true;
EXPORT_SYMBOL(console_suspend_enabled);
static int __init console_suspend_disable(char *str)
{
- console_suspend_enabled = 0;
+ console_suspend_enabled = false;
return 1;
}
__setup("no_console_suspend", console_suspend_disable);
--
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: [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Michal, Thanks for your comments! As discussed, we will rework the patch set in another direction to hide memoryless node from normal slab users. Regards! Gerry On 2014/7/18 15:36, Michal Hocko wrote: > On Fri 11-07-14 15:37:26, Jiang Liu wrote: >> When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id() >> may return a node without memory, and later cause system failure/panic >> when calling kmalloc_node() and friends with returned node id. >> So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with >> memory for the/current cpu. >> >> If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id() >> is the same as cpu_to_node()/numa_node_id(). > > The change makes difference only for really tiny memcgs. If we really > have all pages on unevictable list or anon with no swap allowed and that > is the reason why no node is set in scan_nodes mask then reclaiming > memoryless node or any arbitrary close one doesn't make any difference. > The current memcg might not have any memory on that node at all. > > So the change doesn't make any practical difference and the changelog is > misleading. > >> Signed-off-by: Jiang Liu >> --- >> mm/memcontrol.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index a2c7bcb0e6eb..d6c4b7255ca9 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1933,7 +1933,7 @@ int mem_cgroup_select_victim_node(struct mem_cgroup >> *memcg) >> * we use curret node. >> */ >> if (unlikely(node == MAX_NUMNODES)) >> -node = numa_node_id(); >> +node = numa_mem_id(); >> >> memcg->last_scanned_node = node; >> return node; >> -- >> 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/
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit b19729617929 ("drm/i915:
fix psr match conditions screw ups") from the drm tree and commit
24acaf94ed4a ("drm/i915: Fix up PSR frontbuffer tracking") from the
drm-intel tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_dp.c
index eda73ea3002f,9274ddfd78c7..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1801,20 -1762,17 +1796,18 @@@ static bool intel_edp_psr_match_conditi
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_crtc *crtc = dig_port->base.base.crtc;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
- struct drm_i915_gem_object *obj;
- struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
- dev_priv->psr.source_ok = false;
+ lockdep_assert_held(_priv->psr.lock);
+ lockdep_assert_held(>struct_mutex);
+ WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
++ crtc = dig_port->base.base.crtc;
+ WARN_ON(!drm_modeset_is_locked(>mutex));
- if (!HAS_PSR(dev)) {
- DRM_DEBUG_KMS("PSR not supported on this platform\n");
- return false;
- }
+ dev_priv->psr.source_ok = false;
- if (IS_HASWELL(dev) && (intel_encoder->type != INTEL_OUTPUT_EDP ||
- dig_port->port != PORT_A)) {
+ if (IS_HASWELL(dev) && dig_port->port != PORT_A) {
DRM_DEBUG_KMS("HSW ties PSR to DDI A (eDP)\n");
return false;
}
@@@ -1847,11 -1786,6 +1821,7 @@@
if (IS_BROADWELL(dev))
goto out;
- if (I915_READ(SPRCTL(intel_crtc->pipe)) & SPRITE_ENABLE) {
- DRM_DEBUG_KMS("PSR condition failed: Sprite is Enabled\n");
- return false;
- }
-
++ intel_crtc = to_intel_crtc(crtc);
if (I915_READ(HSW_STEREO_3D_CTL(intel_crtc->config.cpu_transcoder)) &
S3D_ENABLE) {
DRM_DEBUG_KMS("PSR condition failed: Stereo 3D is Enabled\n");
@@@ -3712,10 -3620,7 +3753,8 @@@ intel_dp_detect(struct drm_connector *c
enum drm_connector_status status;
enum intel_display_power_domain power_domain;
struct edid *edid = NULL;
+ bool ret;
- intel_runtime_pm_get(dev_priv);
-
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
signature.asc
Description: PGP signature
Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Tejun and Christoph, Thanks for your suggestions and discussion. Tejun really gives a good point to hide memoryless node interface from normal slab users. I will rework the patch set to go that direction. Regards! Gerry On 2014/7/12 3:11, Christoph Lameter wrote: > On Fri, 11 Jul 2014, Tejun Heo wrote: > >> On Fri, Jul 11, 2014 at 12:29:30PM -0500, Christoph Lameter wrote: >>> GFP_THISNODE is mostly used by allocators that need memory from specific >>> nodes. The use of numa_mem_id() there is useful because one will not >>> get any memory at all when attempting to allocate from a memoryless >>> node using GFP_THISNODE. >> >> As long as it's in allocator proper, it doesn't matter all that much >> but the changes are clearly not contained, are they? > > Well there is a proliferation of memory allocators recently. NUMA is often > a second thought in those. > -- 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: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params
On 2014/7/22 10:04, Alasdair G Kergon wrote: On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote: Unanswered. Let's ask the same question in a different way: A quick search for 'vold' returns: https://android.googlesource.com/platform/system/vold/ and the code there requests a fixed 64K allocation to hold the names of active volumes. So unlike libdevmapper-based applications where a smaller allocation is used at first and only extended if needed, Android just assumes that 64KB is enough for everyone. So is your claim that: 1. This 64KB allocation for the brief duration of the ioctl to store the names of active device-mapper volumes leads to memory problems? [Mustn't the system *already* be in a bad state if this pushes it over the limit?] It's a good question. 1) Usually, Android mobile runs for a long time. It's very command that users don't turn off the phones for months. Users might start lots of applications. memory is used up in the end. Kernel might recollect memory over and over again. 2) We never blames this Out of memory issue fully to DM. 3) We want to improve the OOM issue. and 2. The systems on which this memory shortage occurs have so many volumes (with long names?) that a smaller allocation would not suffice? 64K is small, comparing with 2GB, even 4GB total memory. However, this 64K by kmalloc has a strict criteria. It might be continuous physical memory and align with 64K. If memory is used up, freed memory is very fragmented. Such 64K criteria is a hard request. Usually, driver can allocate such memory at booting initialization. After that, it should allocate many sparse pages instead of continuous memory. Here 64K allocation is after booting. Thanks for the kind comments. Yanmin -- 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 3/5] gpio: make gpiochip_get_desc() gpiolib-private
On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: > On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: >> As GPIO descriptors are not going to remain unique anymore, having this >> function public is not safe. Restrain its use to gpiolib since we have >> no user outside of it. >> > If I implement a gpio chip driver built as module, and I want to use > gpiochip_request_own_desc(), how am I supposed to get desc ? > > I understand that there is still gpio_to_desc(), but I would have thought > that > desc = gpiochip_get_desc(chip, pin); > would be better than > desc = gpio_to_desc(chip->base + pin); > > Not that it makes much of a difference for me, just asking. Actually I was thinking of changing the prototype of gpiochip_request_own_desc(), and your comment definitely strenghtens that idea. gpiochip functions should not work with descriptors, especially since we are going to switch to a multiple-consumer scheme where there won't be any canonical descriptor anymore. Thus, how about turning gpiochip_request_own_desc() into this: struct gpio_desc * gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label); which would basically do both the gpiochip_get_desc() and former gpiochip_request_own_desc() in one call. I think it should satisfy everybody and removes the need to have gpiochip_get_desc() (a not very useful function by itself) exposed out of gpiolib. I will send a patch taking care of this if you agree that makes sense. -- 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: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params
On 2014/7/22 9:23, Alasdair G Kergon wrote: On 2014/7/9 6:39, Mikulas Patocka wrote: Which ioctl with more than 16kB arguments do you use? Unanswered. Let's ask the same question in a different way: Please supply the output of these three commands on the real-world system on which you believe that that particular allocation is causing you a problem: dmsetup info -c dmsetup table dmsetup status Android doesn't include the command. We compiled lvm2-2_02_107.tar.gz and copy dmsetup to the board. But command reports No devices. # /data/bin/dmsetup info No devices found # cat /proc/devices Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 4 ttyMFD 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 21 sg 29 fb 81 video4linux 89 i2c 108 ppp 116 alsa 128 ptm 136 pts 153 spi 166 ttyACM 180 usb 188 ttyUSB 189 usb_device 202 cpu/msr 203 cpu/cpuid 226 drm 241 mdm_ctrl 242 sep54 243 roccat 244 hidraw 245 ttyGS 246 usbmon 247 ttyPTI 248 gsmtty 249 bsg 250 iio 251 ptp 252 pps 253 media 254 rtc Block devices: 1 ramdisk 259 blkext 7 loop 8 sd 9 md 11 sr 65 sd 66 sd 67 sd 68 sd 69 sd 70 sd 71 sd 128 sd 129 sd 130 sd 131 sd 132 sd 133 sd 134 sd 135 sd 179 mmc 253 device-mapper 254 mdp -- 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 drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit d05410f9a450
("drm/i915: split conversion function out into separate function") from
the drm tree and commit 6b09e72050b4 ("drm/i915: Power gating display
wells during i915_pm_suspend") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
P.S. Daniel, that drm-intel tree commit has no Signed-off-by from its
author ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index a5af732b87b8,1389d8a30f0a..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4314,27 -4300,6 +4314,23 @@@ static void i9xx_pfit_enable(struct int
I915_WRITE(BCLRPAT(crtc->pipe), 0);
}
+static enum intel_display_power_domain port_to_power_domain(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return POWER_DOMAIN_PORT_DDI_A_4_LANES;
+ case PORT_B:
+ return POWER_DOMAIN_PORT_DDI_B_4_LANES;
+ case PORT_C:
+ return POWER_DOMAIN_PORT_DDI_C_4_LANES;
+ case PORT_D:
+ return POWER_DOMAIN_PORT_DDI_D_4_LANES;
+ default:
+ WARN_ON_ONCE(1);
+ return POWER_DOMAIN_PORT_OTHER;
+ }
+}
+
- #define for_each_power_domain(domain, mask) \
- for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
- if ((1 << (domain)) & (mask))
-
enum intel_display_power_domain
intel_display_port_power_domain(struct intel_encoder *intel_encoder)
{
signature.asc
Description: PGP signature
[RESEND RFC PATCH v1 0/70] Gloabl CPU Hot-plug flag _FROZEN Clean up
Back to long time ago (about 1.5 years), Thomas began the work for CPU hot-plug, one first thing is CPU hotplug flag cleanup. Paul hoped all the _FROZEN variants of the notifier actions can be removed at that time. Now here it is. Patch 1 ~ 69: remove all kinds of XXX_FROZEN usages Patch 70: remove XXX_FROZEN from the kernel thoroughly Not sure if removing XXX_FROZEN flags thoroughly is overkilled. Fix me if I'm wrong. P.S. My last post is banned because of the capital Triple-X in subject :-( Chen, Gong (69): ia64, err_inject: _FROZEN Cleanup ia64, mca: _FROZEN Cleanup ia64, palinfo: _FROZEN Cleanup ia64, salinfo: _FROZEN Cleanup ia64, topology: _FROZEN Cleanup x86, intel_cacheinfo: _FROZEN Cleanup x86, mce, therm_throt: _FROZEN Cleanup x86, mce_amd: _FROZEN Cleanup x86, kvm: _FROZEN Cleanup x86, vsyscall_64: _FROZEN Cleanup x86, pci, amd_bus: _FROZEN Cleanup x86, x2apic_cluster: _FROZEN Cleanup x86, microcode, core: _FROZEN Cleanup x86, kernel, cpuid: _FROZEN Cleanup x86, kernel, msr: _FROZEN Cleanup arm, vfp, vfpmodule: _FROZEN Cleanup arm, kvm: _FROZEN Cleanup powerpc, sysfs: _FROZEN Cleanup powerpc, mm, numa: _FROZEN Cleanup powerpc, powermac, smp: _FROZEN Cleanup powerpc, mmu_context_nohash: _FROZEN Cleanup mips, loongson, smp: _FROZEN Cleanup s390, perf_cpum_sf: _FROZEN Cleanup sparc, sysfs: _FROZEN Cleanup rcu, tree: _FROZEN Cleanup kernel, padata: _FROZEN Cleanup kernel, profile: _FROZEN Cleanup kernel, sched, core: _FROZEN Cleanup kernel, hrtimer: _FROZEN Cleanup kernel, relay: _FROZEN Cleanup kernel, smp: _FROZEN Cleanup kernel, timer: _FROZEN Cleanup kernel, softirq: _FROZEN Cleanup mm, slab: _FROZEN Cleanup mm, vmscan: _FROZEN Cleanup mm, vmstat: _FROZEN Cleanup mm, memcontrol: _FROZEN Cleanup mm, page_alloc: _FROZEN Cleanup mm, slub: _FROZEN Cleanup fs, buffer: _FROZEN Cleanup xfs, xfs_mount: _FROZEN Cleanup net, iucv: _FROZEN Cleanup net, core, flow: _FROZEN Cleanup net, core, dev: _FROZEN Cleanup block, blk-mq: _FROZEN Cleanup block, blk-iopoll: _FROZEN Cleanup block, blk-softirq: _FROZEN Cleanup driver, base, topology: _FROZEN Cleanup clocksource, metag_generic: _FROZEN Cleanup powercap, intel_rapl: _FROZEN Cleanup cpuidle, cpuidle-powernv: _FROZEN Cleanup cpuidle, cpuidle-pseries: _FROZEN Cleanup cpufreq, acpi-cpufreq: _FROZEN Cleanup irqchip, irq-armada-370-xp: _FROZEN Cleanup irqchip, irq-gic: _FROZEN Cleanup scsi, bnx2fc, bnx2fc_fcoe: _FROZEN Cleanup scsi, bnx2i, bnx2i_init: _FROZEN Cleanup scsi, fcoe: _FROZEN Cleanup scsi, virtio_scsi: _FROZEN Cleanup md, raid5: _FROZEN Cleanup virt, kvm, arm, arch_timer: _FROZEN Cleanup virt, kvm, arm, vgic: _FROZEN Cleanup trace, ring_buffer: _FROZEN Cleanup oprofile, timer_int: _FROZEN Cleanup lib, cpu-notifier-error-inject: _FROZEN Cleanup lib, percpu_counter: _FROZEN Cleanup lib, radix-tree: _FROZEN Cleanup staging, lustre, linux-cpu: _FROZEN Cleanup cpu: Eliminate _FROZEN flags thoroughly Thomas Gleixner (1): cpu: Restructure FROZEN state handling arch/arm/kvm/arm.c | 3 +- arch/arm/vfp/vfpmodule.c | 6 +- arch/ia64/kernel/err_inject.c | 4 +- arch/ia64/kernel/mca.c | 3 +- arch/ia64/kernel/palinfo.c | 4 +- arch/ia64/kernel/salinfo.c | 4 +- arch/ia64/kernel/topology.c| 4 +- arch/mips/loongson/loongson-3/smp.c| 5 +- arch/powerpc/kernel/sysfs.c| 4 +- arch/powerpc/mm/mmu_context_nohash.c | 5 +- arch/powerpc/mm/numa.c | 5 +- arch/powerpc/platforms/powermac/smp.c | 11 ++-- arch/s390/kernel/perf_cpum_sf.c| 1 - arch/sparc/kernel/sysfs.c | 4 +- arch/x86/kernel/apic/x2apic_cluster.c | 11 +++- arch/x86/kernel/cpu/intel_cacheinfo.c | 4 +- arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 +- arch/x86/kernel/cpu/mcheck/therm_throt.c | 5 +- arch/x86/kernel/cpu/microcode/core.c | 8 +-- arch/x86/kernel/cpuid.c| 6 +- arch/x86/kernel/kvm.c | 9 +-- arch/x86/kernel/msr.c | 6 +- arch/x86/kernel/vsyscall_64.c | 2 +- arch/x86/pci/amd_bus.c | 3 +- block/blk-iopoll.c | 2 +- block/blk-mq.c
WARNING: at kernel/cpuset.c:1139
commit 734d45130cb ("cpuset: update cs->effective_{cpus, mems} when
config changes") introduce the below warning in my server.
[ 35.652137] [ cut here ]
[ 35.652141] WARNING: at kernel/cpuset.c:1139
[ 35.652142] Modules linked in: ebtable_nat xt_CHECKSUM bridge stp llc
be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio
libcxgbi ib_iser iptable_mangle nf_conntrack_ipv4 rdma_cm nf_defrag_ipv4
xt_conntrack iw_cm nf_conntrack ib_cm ib_sa ib_mad ebtable_filter
ib_core ebtables ip6_tables ib_addr iscsi_tcp libiscsi_tcp libiscsi
scsi_transport_iscsi e1000e ses ptp enclosure pps_core be2net shpchp
vhost_net tun macvtap macvlan vhost kvm binfmt_misc uinput lpfc
scsi_transport_fc ipr
[ 35.652185] CPU: 36 PID: 1363 Comm: libvirtd Not tainted
3.16.0-rc5-next-20140721+ #93
[ 35.652187] task: c003b3443a00 ti: c003bb008000 task.ti:
c003bb008000
[ 35.652189] NIP: c015ff38 LR: c015ff2c CTR:
[ 35.652190] REGS: c003bb00b850 TRAP: 0700 Not tainted
(3.16.0-rc5-next-20140721+)
[ 35.652191] MSR: 90029032 CR:
24004824 XER:
[ 35.652196] CFAR: c045f6cc SOFTE: 1
GPR00: c015ff04 c003bb00bad0 c145acf8 0001
GPR04: c003b3dae5d0 0100
GPR08: c003b3dae548 0004 0004
GPR12: 0001 cfeea200 008066727bd8 008066727a30
GPR16: 0080667dfa08 008066727a68 0080667279f8 0080667279d0
GPR20: c166acf8 c003b3dae530 c1311990 c003b3dae5d0
GPR24: c003b3dae530 c003b3dadc00 c003b3dae400 0001
GPR28: c1311968 c003b1873100 c003b3dae400
[ 35.652219] NIP [c015ff38] .cpuset_write_resmask+0x438/0x8c0
[ 35.652221] LR [c015ff2c] .cpuset_write_resmask+0x42c/0x8c0
[ 35.65] Call Trace:
[ 35.652224] [c003bb00bad0] [c015ff04]
.cpuset_write_resmask+0x404/0x8c0 (unreliable)
[ 35.652227] [c003bb00bba0] [c0156f08]
.cgroup_file_write+0x78/0x190
[ 35.652230] [c003bb00bc50] [c030c490]
.kernfs_fop_write+0x150/0x1e0
[ 35.652233] [c003bb00bcf0] [c026b6d0] .vfs_write+0xe0/0x270
[ 35.652235] [c003bb00bd90] [c026be24] .SyS_write+0x64/0x110
[ 35.652238] [c003bb00be30] [c000a158] syscall_exit+0x0/0x98
[ 35.652239] Instruction dump:
[ 35.652240] e93a 39549528 e9290118 7fa95000 419e0024 7ea3ab78
7ee4bb78 38a00100
[ 35.652243] 482ff719 6000 2fa3 419e0008 <0fe0> 7f43d378
4bfffa71 813a006c
[ 35.652247] ---[ end trace f91b0c3aadfe71a6 ]---
Thanks,
Mike
--
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/
[RFC PATCH v1 02/70] ia64, err_inject: _FROZEN Cleanup
Remove XXX_FROZEN state from ia64/err_inject.
Signed-off-by: Chen, Gong
---
arch/ia64/kernel/err_inject.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/ia64/kernel/err_inject.c b/arch/ia64/kernel/err_inject.c
index 0c161ed..a8b70d4 100644
--- a/arch/ia64/kernel/err_inject.c
+++ b/arch/ia64/kernel/err_inject.c
@@ -242,13 +242,11 @@ static int err_inject_cpu_callback(struct notifier_block
*nfb,
struct device *sys_dev;
sys_dev = get_cpu_device(cpu);
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
err_inject_add_dev(sys_dev);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
err_inject_remove_dev(sys_dev);
break;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 10/70] x86, kvm: _FROZEN Cleanup
Remove XXX_FROZEN state from kvm.
Signed-off-by: Chen, Gong
---
arch/x86/kernel/kvm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 3dd8e2c..22d472b 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -442,19 +442,20 @@ static int kvm_cpu_notify(struct notifier_block *self,
unsigned long action,
void *hcpu)
{
int cpu = (unsigned long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_DOWN_FAILED:
- case CPU_ONLINE_FROZEN:
smp_call_function_single(cpu, kvm_guest_cpu_online, NULL, 0);
break;
case CPU_DOWN_PREPARE:
- case CPU_DOWN_PREPARE_FROZEN:
smp_call_function_single(cpu, kvm_guest_cpu_offline, NULL, 1);
break;
default:
break;
}
+
+ if (action == CPU_DOWN_FAILED)
+ smp_call_function_single(cpu, kvm_guest_cpu_online, NULL, 0);
+
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 08/70] x86, mce, therm_throt: _FROZEN Cleanup
Remove XXX_FROZEN state from mce/therm_throt.
Signed-off-by: Chen, Gong
---
arch/x86/kernel/cpu/mcheck/therm_throt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c
b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 36a1bb6..dd13686 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -283,16 +283,13 @@ thermal_throttle_cpu_callback(struct notifier_block *nfb,
dev = get_cpu_device(cpu);
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
err = thermal_throttle_add_dev(dev, cpu);
WARN_ON(err);
break;
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
thermal_throttle_remove_dev(dev);
break;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 17/70] arm, vfp, vfpmodule: _FROZEN Cleanup
Remove XXX_FROZEN state from arm/vfp/vfpmodule.
Signed-off-by: Chen, Gong
---
arch/arm/vfp/vfpmodule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2f37e1d..a1a6154 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -642,9 +642,11 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
static int vfp_hotplug(struct notifier_block *b, unsigned long action,
void *hcpu)
{
- if (action == CPU_DYING || action == CPU_DYING_FROZEN)
+ action &= ~CPU_TASKS_FROZEN;
+
+ if (action == CPU_DYING)
vfp_current_hw_state[(long)hcpu] = NULL;
- else if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
+ else if (action == CPU_STARTING)
vfp_enable(NULL);
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 19/70] powerpc, sysfs: _FROZEN Cleanup
Remove XXX_FROZEN state from powerpc/sysfs.
Signed-off-by: Chen, Gong
---
arch/powerpc/kernel/sysfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 67fd2fd..8a3739c 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -852,14 +852,12 @@ static int sysfs_cpu_notify(struct notifier_block *self,
{
unsigned int cpu = (unsigned int)(long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
register_cpu_online(cpu);
break;
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
unregister_cpu_online(cpu);
break;
#endif
--
2.0.0.rc2
--
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/
[RFC PATCH v1 20/70] powerpc, mm, numa: _FROZEN Cleanup
Remove XXX_FROZEN state from powerpc/mm/numa.
Signed-off-by: Chen, Gong
---
arch/powerpc/mm/numa.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 3b181b2..080ef52 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -598,18 +598,15 @@ static int cpu_numa_callback(struct notifier_block *nfb,
unsigned long action,
unsigned long lcpu = (unsigned long)hcpu;
int ret = NOTIFY_DONE, nid;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
nid = numa_setup_cpu(lcpu);
verify_cpu_node_mapping((int)lcpu, nid);
ret = NOTIFY_OK;
break;
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
unmap_cpu_from_node(lcpu);
break;
ret = NOTIFY_OK;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 14/70] x86, microcode, core: _FROZEN Cleanup
Remove XXX_FROZEN state from x86/microcode/core.
Signed-off-by: Chen, Gong
---
arch/x86/kernel/cpu/microcode/core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index dd9d619..27e47be 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -499,6 +499,10 @@ mc_cpu_callback(struct notifier_block *nb, unsigned long
action, void *hcpu)
pr_debug("CPU%d removed\n", cpu);
break;
+ case CPU_UP_CANCELED:
+ /* The CPU refused to come up during a system resume */
+ if (action & CPU_TASKS_FROZEN)
+ microcode_fini_cpu(cpu);
/*
* case CPU_DEAD:
*
@@ -509,10 +513,6 @@ mc_cpu_callback(struct notifier_block *nb, unsigned long
action, void *hcpu)
*/
}
- /* The CPU refused to come up during a system resume */
- if (action == CPU_UP_CANCELED_FROZEN)
- microcode_fini_cpu(cpu);
-
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 21/70] powerpc, powermac, smp: _FROZEN Cleanup
Remove XXX_FROZEN state from powermac/smp.
Signed-off-by: Chen, Gong
---
arch/powerpc/platforms/powermac/smp.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/smp.c
b/arch/powerpc/platforms/powermac/smp.c
index 5cbd4d6..980605f 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -861,9 +861,8 @@ static int smp_core99_cpu_notify(struct notifier_block
*self,
{
int rc;
- switch(action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
/* Open i2c bus if it was used for tb sync */
if (pmac_tb_clock_chip_host) {
rc = pmac_i2c_open(pmac_tb_clock_chip_host, 1);
@@ -875,9 +874,11 @@ static int smp_core99_cpu_notify(struct notifier_block
*self,
break;
case CPU_ONLINE:
case CPU_UP_CANCELED:
- /* Close i2c bus if it was used for tb sync */
- if (pmac_tb_clock_chip_host)
- pmac_i2c_close(pmac_tb_clock_chip_host);
+ if (!(action & CPU_TASKS_FROZEN)) {
+ /* Close i2c bus if it was used for tb sync */
+ if (pmac_tb_clock_chip_host)
+ pmac_i2c_close(pmac_tb_clock_chip_host);
+ }
break;
default:
break;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 29/70] kernel, sched, core: _FROZEN Cleanup
Remove XXX_FROZEN state from sched/core.
Signed-off-by: Chen, Gong
---
kernel/sched/core.c | 55 -
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bc1638b..f0aff5f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -459,13 +459,10 @@ hotplug_hrtick(struct notifier_block *nfb, unsigned long
action, void *hcpu)
{
int cpu = (int)(long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
case CPU_DOWN_PREPARE:
- case CPU_DOWN_PREPARE_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
hrtick_clear(cpu_rq(cpu));
return NOTIFY_OK;
}
@@ -6742,30 +6739,28 @@ static int num_cpus_frozen; /* used to mark
begin/end of suspend/resume */
static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action,
void *hcpu)
{
- switch (action) {
- case CPU_ONLINE_FROZEN:
- case CPU_DOWN_FAILED_FROZEN:
-
- /*
-* num_cpus_frozen tracks how many CPUs are involved in suspend
-* resume sequence. As long as this is not the last online
-* operation in the resume sequence, just build a single sched
-* domain, ignoring cpusets.
-*/
- num_cpus_frozen--;
- if (likely(num_cpus_frozen)) {
- partition_sched_domains(1, NULL, NULL);
- break;
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
+ if (action & CPU_TASKS_FROZEN) {
+ /*
+* num_cpus_frozen tracks how many CPUs are involved
+* in suspend resume sequence. As long as this is not
+* the last online operation in the resume sequence,
+* just build a single sched domain, ignoring cpusets.
+*/
+ num_cpus_frozen--;
+ if (likely(num_cpus_frozen)) {
+ partition_sched_domains(1, NULL, NULL);
+ break;
+ }
}
/*
-* This is the last CPU online operation. So fall through and
-* restore the original sched domains by considering the
-* cpuset configurations.
+* This is the last CPU online operation. So restore the
+* original sched domains by considering the cpuset
+* configurations.
*/
-
- case CPU_ONLINE:
- case CPU_DOWN_FAILED:
cpuset_update_active_cpus(true);
break;
default:
@@ -6777,13 +6772,13 @@ static int cpuset_cpu_active(struct notifier_block
*nfb, unsigned long action,
static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long
action,
void *hcpu)
{
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_DOWN_PREPARE:
- cpuset_update_active_cpus(false);
- break;
- case CPU_DOWN_PREPARE_FROZEN:
- num_cpus_frozen++;
- partition_sched_domains(1, NULL, NULL);
+ if (action & CPU_TASKS_FROZEN) {
+ num_cpus_frozen++;
+ partition_sched_domains(1, NULL, NULL);
+ } else
+ cpuset_update_active_cpus(false);
break;
default:
return NOTIFY_DONE;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 28/70] kernel, profile: _FROZEN Cleanup
Remove XXX_FROZEN state from kernel/profile.
Signed-off-by: Chen, Gong
---
kernel/profile.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/profile.c b/kernel/profile.c
index 54bf5ba..22bca4b 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -333,9 +333,8 @@ static int profile_cpu_callback(struct notifier_block *info,
int node, cpu = (unsigned long)__cpu;
struct page *page;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
node = cpu_to_mem(cpu);
per_cpu(cpu_profile_flip, cpu) = 0;
if (!per_cpu(cpu_profile_hits, cpu)[1]) {
@@ -361,14 +360,11 @@ out_free:
__free_page(page);
return notifier_from_errno(-ENOMEM);
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
if (prof_cpu_mask != NULL)
cpumask_set_cpu(cpu, prof_cpu_mask);
break;
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
if (prof_cpu_mask != NULL)
cpumask_clear_cpu(cpu, prof_cpu_mask);
if (per_cpu(cpu_profile_hits, cpu)[0]) {
--
2.0.0.rc2
--
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/
[RFC PATCH v1 30/70] kernel, hrtimer: _FROZEN Cleanup
Remove XXX_FROZEN state from kernel/hrtimer.
Signed-off-by: Chen, Gong
---
kernel/hrtimer.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 3ab2899..a37958e 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1756,27 +1756,19 @@ static int hrtimer_cpu_notify(struct notifier_block
*self,
{
int scpu = (long)hcpu;
- switch (action) {
-
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
init_hrtimers_cpu(scpu);
break;
-
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DYING:
- case CPU_DYING_FROZEN:
clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, );
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
- {
clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, );
migrate_hrtimers(scpu);
break;
- }
#endif
-
default:
break;
}
--
2.0.0.rc2
--
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 v7 03/10] x86, mpx: add macro cpu_has_mpx
On 2014-07-23, Hansen, Dave wrote:
> On 07/20/2014 10:38 PM, Qiaowei Ren wrote:
>> +#ifdef CONFIG_X86_INTEL_MPX
>> +#define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX) #else #define
>> +cpu_has_mpx 0 #endif /* CONFIG_X86_INTEL_MPX */
>
> Is this enough checking? Looking at the extension reference, it says:
>
>> 9.3.3 Enabling of Intel MPX States An OS can enable Intel MPX states to
>> support software operation using bounds registers with the following
>> steps: * Verify the processor supports XSAVE/XRSTOR/XSETBV/XGETBV
>> instructions and XCR0 by checking CPUID.1.ECX.XSAVE[bit 26]=1.
>
> That, I assume the xsave code is already doing.
>
>> * Verify the processor supports both Intel MPX states by checking
> CPUID.(EAX=0x0D, ECX=0):EAX[4:3] is 11b.
>
> I see these bits _attempting_ to get set in pcntxt_mask via XCNTXT_MASK.
> But, I don't see us ever actually checking that they _do_ get set.
> For instance, we do this for:
>
>> if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
>> pr_err("FP/SSE not shown under xsave features
> 0x%llx\n",
>>pcntxt_mask);
>> BUG();
>> }
The checking about MPX feature should be as follow:
if (pcntxt_mask & XSTATE_EAGER) {
if (eagerfpu == DISABLE) {
pr_err("eagerfpu not present, disabling some xstate
features: 0x%llx\n",
pcntxt_mask & XSTATE_EAGER);
pcntxt_mask &= ~XSTATE_EAGER;
} else {
eagerfpu = ENABLE;
}
}
This patch was merged into kernel the ending of last year
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e7d820a5e549b3eb6c3f9467507566565646a669
)
Thanks,
Qiaowei
--
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/
[RFC PATCH v1 38/70] mm, memcontrol: _FROZEN Cleanup
Remove XXX_FROZEN state from mm/memcontrol. Signed-off-by: Chen, Gong --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index a2c7bcb..871667d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2540,7 +2540,7 @@ static int memcg_cpu_hotplug_callback(struct notifier_block *nb, if (action == CPU_ONLINE) return NOTIFY_OK; - if (action != CPU_DEAD && action != CPU_DEAD_FROZEN) + if ((action & ~CPU_TASKS_FROZEN) != CPU_DEAD) return NOTIFY_OK; for_each_mem_cgroup(iter) -- 2.0.0.rc2 -- 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/
[RFC PATCH v1 35/70] mm, slab: _FROZEN Cleanup
Remove XXX_FROZEN state from mm/slab.
Signed-off-by: Chen, Gong
---
mm/slab.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 3070b92..5490528 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1325,20 +1325,17 @@ static int cpuup_callback(struct notifier_block *nfb,
long cpu = (long)hcpu;
int err = 0;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
mutex_lock(_mutex);
err = cpuup_prepare(cpu);
mutex_unlock(_mutex);
break;
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
start_cpu_timer(cpu);
break;
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DOWN_PREPARE:
- case CPU_DOWN_PREPARE_FROZEN:
/*
* Shutdown cache reaper. Note that the slab_mutex is
* held so that if cache_reap() is invoked it cannot do
@@ -1350,11 +1347,9 @@ static int cpuup_callback(struct notifier_block *nfb,
per_cpu(slab_reap_work, cpu).work.func = NULL;
break;
case CPU_DOWN_FAILED:
- case CPU_DOWN_FAILED_FROZEN:
start_cpu_timer(cpu);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
/*
* Even if all the cpus of a node are down, we don't free the
* kmem_cache_node of any cache. This to avoid a race between
@@ -1366,7 +1361,6 @@ static int cpuup_callback(struct notifier_block *nfb,
/* fall through */
#endif
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
mutex_lock(_mutex);
cpuup_canceled(cpu);
mutex_unlock(_mutex);
--
2.0.0.rc2
--
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/
[RFC PATCH v1 41/70] fs, buffer: _FROZEN Cleanup
Remove XXX_FROZEN state from fs/buffer.
Signed-off-by: Chen, Gong
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index eba6e4f..47960b7 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3373,7 +3373,7 @@ static void buffer_exit_cpu(int cpu)
static int buffer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
- if (action == CPU_DEAD || action == CPU_DEAD_FROZEN)
+ if ((action & ~CPU_TASKS_FROZEN) == CPU_DEAD)
buffer_exit_cpu((unsigned long)hcpu);
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 52/70] cpuidle, cpuidle-powernv: _FROZEN Cleanup
Remove XXX_FROZEN state from cpuidle/cpuidle-powernv.
Signed-off-by: Chen, Gong
---
drivers/cpuidle/cpuidle-powernv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 74f5788..78575a8 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -107,16 +107,14 @@ static int powernv_cpuidle_add_cpu_notifier(struct
notifier_block *n,
per_cpu(cpuidle_devices, hotcpu);
if (dev && cpuidle_get_driver()) {
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
--
2.0.0.rc2
--
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/
[RFC PATCH v1 50/70] clocksource, metag_generic: _FROZEN Cleanup
Remove XXX_FROZEN state from clocksource/metag_generic.
Signed-off-by: Chen, Gong
---
drivers/clocksource/metag_generic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clocksource/metag_generic.c
b/drivers/clocksource/metag_generic.c
index 9e4db41..eefa164 100644
--- a/drivers/clocksource/metag_generic.c
+++ b/drivers/clocksource/metag_generic.c
@@ -159,9 +159,8 @@ static int arch_timer_cpu_notify(struct notifier_block
*self,
{
int cpu = (long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
- case CPU_STARTING_FROZEN:
arch_timer_setup(cpu);
break;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 56/70] irqchip, irq-gic: _FROZEN Cleanup
Remove XXX_FROZEN state from irqchip/irq-gic.
Signed-off-by: Chen, Gong
---
drivers/irqchip/irq-gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 7c131cf..a8df097 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -877,7 +877,7 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
static int gic_secondary_init(struct notifier_block *nfb, unsigned long action,
void *hcpu)
{
- if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
+ if ((action & ~CPU_TASKS_FROZEN) == CPU_STARTING)
gic_cpu_init(_data[0]);
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 58/70] scsi, bnx2i, bnx2i_init: _FROZEN Cleanup
Remove XXX_FROZEN state from scsi/bnx2i_init.
Signed-off-by: Chen, Gong
---
drivers/scsi/bnx2i/bnx2i_init.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 80c03b4..bd71179 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -476,15 +476,13 @@ static int bnx2i_cpu_callback(struct notifier_block *nfb,
{
unsigned cpu = (unsigned long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
printk(KERN_INFO "bnx2i: CPU %x online: Create Rx thread\n",
cpu);
bnx2i_percpu_thread_create(cpu);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
printk(KERN_INFO "CPU %x offline: Remove Rx thread\n", cpu);
bnx2i_percpu_thread_destroy(cpu);
break;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 57/70] scsi, bnx2fc, bnx2fc_fcoe: _FROZEN Cleanup
Remove XXX_FROZEN state from scsi/bnx2fc_fcoe.
Signed-off-by: Chen, Gong
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 785d0d7..c56281d 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -2507,14 +2507,12 @@ static int bnx2fc_cpu_callback(struct notifier_block
*nfb,
{
unsigned cpu = (unsigned long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
printk(PFX "CPU %x online: Create Rx thread\n", cpu);
bnx2fc_percpu_thread_create(cpu);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
printk(PFX "CPU %x offline: Remove Rx thread\n", cpu);
bnx2fc_percpu_thread_destroy(cpu);
break;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 61/70] md, raid5: _FROZEN Cleanup
Remove XXX_FROZEN state from md/raid5.
Signed-off-by: Chen, Gong
---
drivers/md/raid5.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 6234b2e..3d76235 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5665,9 +5665,8 @@ static int raid456_cpu_notify(struct notifier_block *nfb,
unsigned long action,
long cpu = (long)hcpu;
struct raid5_percpu *percpu = per_cpu_ptr(conf->percpu, cpu);
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
if (alloc_scratch_buffer(conf, percpu)) {
pr_err("%s: failed memory allocation for cpu%ld\n",
__func__, cpu);
@@ -5675,7 +5674,6 @@ static int raid456_cpu_notify(struct notifier_block *nfb,
unsigned long action,
}
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
free_scratch_buffer(conf, per_cpu_ptr(conf->percpu, cpu));
break;
default:
--
2.0.0.rc2
--
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/
[RFC PATCH v1 65/70] oprofile, timer_int: _FROZEN Cleanup
Remove XXX_FROZEN state from oprofile/timer_int.
Signed-off-by: Chen, Gong
---
drivers/oprofile/timer_int.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/oprofile/timer_int.c b/drivers/oprofile/timer_int.c
index 61be1d9..ab5a0a9 100644
--- a/drivers/oprofile/timer_int.c
+++ b/drivers/oprofile/timer_int.c
@@ -79,14 +79,12 @@ static int oprofile_cpu_notify(struct notifier_block *self,
{
long cpu = (long) hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
smp_call_function_single(cpu, __oprofile_hrtimer_start,
NULL, 1);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
__oprofile_hrtimer_stop(cpu);
break;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 63/70] virt, kvm, arm, vgic: _FROZEN Cleanup
Remove XXX_FROZEN state from kvm/arm/vgic.
Signed-off-by: Chen, Gong
---
virt/kvm/arm/vgic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 56ff9be..f93b8c5 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1452,13 +1452,11 @@ static void vgic_init_maintenance_interrupt(void *info)
static int vgic_cpu_notify(struct notifier_block *self,
unsigned long action, void *cpu)
{
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
- case CPU_STARTING_FROZEN:
vgic_init_maintenance_interrupt(NULL);
break;
case CPU_DYING:
- case CPU_DYING_FROZEN:
disable_percpu_irq(vgic_maint_irq);
break;
}
--
2.0.0.rc2
--
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/
[RFC PATCH v1 64/70] trace, ring_buffer: _FROZEN Cleanup
Remove XXX_FROZEN state from trace/ring_buffer.
Signed-off-by: Chen, Gong
---
kernel/trace/ring_buffer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index ff70271..1cd5793 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4607,9 +4607,8 @@ static int rb_cpu_notify(struct notifier_block *self,
int cpu_i, nr_pages_same;
unsigned int nr_pages;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
if (cpumask_test_cpu(cpu, buffer->cpumask))
return NOTIFY_OK;
@@ -4639,7 +4638,6 @@ static int rb_cpu_notify(struct notifier_block *self,
cpumask_set_cpu(cpu, buffer->cpumask);
break;
case CPU_DOWN_PREPARE:
- case CPU_DOWN_PREPARE_FROZEN:
/*
* Do nothing.
* If we were to free the buffer, then the user would
--
2.0.0.rc2
--
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/
[RFC PATCH v1 66/70] lib, cpu-notifier-error-inject: _FROZEN Cleanup
Remove XXX_FROZEN state from lib/cpu-notifier-error-inject.
Signed-off-by: Chen, Gong
---
lib/cpu-notifier-error-inject.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/cpu-notifier-error-inject.c b/lib/cpu-notifier-error-inject.c
index 707ca24..78c28db 100644
--- a/lib/cpu-notifier-error-inject.c
+++ b/lib/cpu-notifier-error-inject.c
@@ -10,10 +10,10 @@ MODULE_PARM_DESC(priority, "specify cpu notifier priority");
static struct notifier_err_inject cpu_notifier_err_inject = {
.actions = {
- { NOTIFIER_ERR_INJECT_ACTION(CPU_UP_PREPARE) },
- { NOTIFIER_ERR_INJECT_ACTION(CPU_UP_PREPARE_FROZEN) },
- { NOTIFIER_ERR_INJECT_ACTION(CPU_DOWN_PREPARE) },
- { NOTIFIER_ERR_INJECT_ACTION(CPU_DOWN_PREPARE_FROZEN) },
+ {NOTIFIER_ERR_INJECT_ACTION(CPU_UP_PREPARE)},
+ {NOTIFIER_ERR_INJECT_ACTION(CPU_UP_PREPARE|CPU_TASKS_FROZEN)},
+ {NOTIFIER_ERR_INJECT_ACTION(CPU_DOWN_PREPARE)},
+ {NOTIFIER_ERR_INJECT_ACTION(CPU_DOWN_PREPARE|CPU_TASKS_FROZEN)},
{}
}
};
--
2.0.0.rc2
--
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/
[RFC PATCH v1 67/70] lib, percpu_counter: _FROZEN Cleanup
Remove XXX_FROZEN state from lib/percpu_counter. Signed-off-by: Chen, Gong --- lib/percpu_counter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c index 7dd33577..9a833ea 100644 --- a/lib/percpu_counter.c +++ b/lib/percpu_counter.c @@ -169,7 +169,7 @@ static int percpu_counter_hotcpu_callback(struct notifier_block *nb, struct percpu_counter *fbc; compute_batch_value(); - if (action != CPU_DEAD && action != CPU_DEAD_FROZEN) + if ((action & ~CPU_TASKS_FROZEN) != CPU_DEAD) return NOTIFY_OK; cpu = (unsigned long)hcpu; -- 2.0.0.rc2 -- 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/
[RFC PATCH v1 68/70] lib, radix-tree: _FROZEN Cleanup
Remove XXX_FROZEN state from lib/radix-tree.
Signed-off-by: Chen, Gong
---
lib/radix-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 3291a8e..5f7231c 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -1465,7 +1465,7 @@ static int radix_tree_callback(struct notifier_block *nfb,
struct radix_tree_preload *rtp;
/* Free per-cpu pool of perloaded nodes */
- if (action == CPU_DEAD || action == CPU_DEAD_FROZEN) {
+ if ((action & ~CPU_TASKS_FROZEN) == CPU_DEAD) {
rtp = _cpu(radix_tree_preloads, cpu);
while (rtp->nr) {
kmem_cache_free(radix_tree_node_cachep,
--
2.0.0.rc2
--
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/
[RFC PATCH v1 70/70] cpu: Eliminate _FROZEN flags thoroughly
By now all usages of XXX_FROZEN have been removed. It can
be deleted safely.
Signed-off-by: Chen, Gong
---
include/linux/cpu.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 95978ad..9de61cc 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -97,15 +97,6 @@ enum {
*/
#define CPU_TASKS_FROZEN 0x0010
-#define CPU_ONLINE_FROZEN (CPU_ONLINE | CPU_TASKS_FROZEN)
-#define CPU_UP_PREPARE_FROZEN (CPU_UP_PREPARE | CPU_TASKS_FROZEN)
-#define CPU_UP_CANCELED_FROZEN (CPU_UP_CANCELED | CPU_TASKS_FROZEN)
-#define CPU_DOWN_PREPARE_FROZEN(CPU_DOWN_PREPARE | CPU_TASKS_FROZEN)
-#define CPU_DOWN_FAILED_FROZEN (CPU_DOWN_FAILED | CPU_TASKS_FROZEN)
-#define CPU_DEAD_FROZEN(CPU_DEAD | CPU_TASKS_FROZEN)
-#define CPU_DYING_FROZEN (CPU_DYING | CPU_TASKS_FROZEN)
-#define CPU_STARTING_FROZEN(CPU_STARTING | CPU_TASKS_FROZEN)
-
#ifdef CONFIG_SMP
/* Need to know about CPUs going up/down? */
--
2.0.0.rc2
--
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/
[RFC PATCH v1 69/70] staging, lustre, linux-cpu: _FROZEN Cleanup
Remove XXX_FROZEN state from lustre/linux-cpu.
Signed-off-by: Chen, Gong
---
drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
index fc21210..0e061ca 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
@@ -954,16 +954,14 @@ cfs_cpu_notify(struct notifier_block *self, unsigned long
action, void *hcpu)
unsigned int cpu = (unsigned long)hcpu;
bool warn;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
spin_lock(_data.cpt_lock);
cpt_data.cpt_version++;
spin_unlock(_data.cpt_lock);
default:
- if (action != CPU_DEAD && action != CPU_DEAD_FROZEN) {
+ if ((action & ~CPU_TASKS_FROZEN) != CPU_DEAD) {
CDEBUG(D_INFO, "CPU changed [cpu %u action %lx]\n",
cpu, action);
break;
--
2.0.0.rc2
--
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 drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_gem_render_state.c between commit
88b982873567 ("drm/i915: fix freeze with blank screen booting highmem")
from the drm-intel-fixes tree and commit 1ce826d436f3 ("drm/i915:
Simplify processing of the golden render context state") from the drm
tree.
I fixed it up (the latter appears to supercede the former, so I used
that) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[RFC PATCH v1 60/70] scsi, virtio_scsi: _FROZEN Cleanup
Remove XXX_FROZEN state from scsi/virtio_scsi.
Signed-off-by: Chen, Gong
---
drivers/scsi/virtio_scsi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 308256b..22f4a6e5 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -782,11 +782,9 @@ static int virtscsi_cpu_callback(struct notifier_block
*nfb,
unsigned long action, void *hcpu)
{
struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
- switch(action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
__virtscsi_set_affinity(vscsi, true);
break;
default:
--
2.0.0.rc2
--
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/
[RFC PATCH v1 53/70] cpuidle, cpuidle-pseries: _FROZEN Cleanup
Remove XXX_FROZEN state from cpuidle/cpuidle-pseries.
Signed-off-by: Chen, Gong
---
drivers/cpuidle/cpuidle-pseries.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-pseries.c
b/drivers/cpuidle/cpuidle-pseries.c
index 6f7b019..11902eb 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -176,16 +176,14 @@ static int pseries_cpuidle_add_cpu_notifier(struct
notifier_block *n,
per_cpu(cpuidle_devices, hotcpu);
if (dev && cpuidle_get_driver()) {
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
--
2.0.0.rc2
--
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/
[RFC PATCH v1 59/70] scsi, fcoe: _FROZEN Cleanup
Remove XXX_FROZEN state from scsi/fcoe.
Signed-off-by: Chen, Gong
---
drivers/scsi/fcoe/fcoe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 00ee0ed..f1d3f6a 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1376,14 +1376,12 @@ static int fcoe_cpu_callback(struct notifier_block *nfb,
{
unsigned cpu = (unsigned long)hcpu;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
FCOE_DBG("CPU %x online: Create Rx thread\n", cpu);
fcoe_percpu_thread_create(cpu);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
FCOE_DBG("CPU %x offline: Remove Rx thread\n", cpu);
fcoe_percpu_thread_destroy(cpu);
break;
--
2.0.0.rc2
--
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/
[RFC PATCH v1 55/70] irqchip, irq-armada-370-xp: _FROZEN Cleanup
Remove XXX_FROZEN state from irqchip/irq-armada-370-xp.
Signed-off-by: Chen, Gong
---
drivers/irqchip/irq-armada-370-xp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 574aba0..1c46257 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -357,7 +357,7 @@ static void armada_xp_mpic_smp_cpu_init(void)
static int armada_xp_mpic_secondary_init(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
- if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
+ if ((action & ~CPU_TASKS_FROZEN) == CPU_STARTING)
armada_xp_mpic_smp_cpu_init();
return NOTIFY_OK;
}
--
2.0.0.rc2
--
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/
