Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 05:33:56 Anton Vorontsov wrote: > On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote: > > > On 09/12/2012 03:57 AM, Alexandre Courbot wrote: > > > > > New revision of the power sequences, taking as usual the feedback that > > > was > > > kindly provided about the last version. > > > > > > I think now is a good time to discuss integrating this and to start > > > looking for a maintainer who would be willing to merge this into > > > his/her tree (I am especially thinking about the power framework > > > maintainers, since this is where the code is right now. > > > > > > The other alternative is for you to maintain this going forward; I > > believe that would be as simple as: > > > > * Create a patch to add yourself to MAINTAINERS for the > > drivers/power/power_seq/ directory. > > > > * Get a kernel.org account, push this patch to a branch there, and add > > the branch into linux-next. > > > > * Send a pull request to Linus at the appropriate time. > > > > * Ongoing: Accept any patches, perform any maintenance required, etc. > > > > Does anyone see any issue with Alexandre doing this? Nobody else has > > volunteered yet:-) > > > Yup, looks like the best way. I am fine this way too - it will just take some time for me to get ready as I will need to get my GPG key signed by some kernel developers first (that's what I forgot to do during the last LinuxCon!). I know a few here so it should not be too hard to get them drunk and sign my key, but I don't expect to be ready for the 3.7 merge window. Would anybody be concerned by this delay? By the meantime I can also make a branch available somewhere. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: > New revision of the power sequences, taking as usual the feedback that was > kindly provided about the last version. > > I think now is a good time to discuss integrating this and to start looking > for > a maintainer who would be willing to merge this into his/her tree (I am > especially thinking about the power framework maintainers, since this is where > the code is right now. The second patch in this series enables the > pwm_backlight > driver to be used with the device tree, without relying on board-dependent > callbacks to support complex power sequences. We also plan to use power > sequences in other Tegra drivers, and other people have expressed interest in > this work during earlier reviews. See for instance > > https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018532.html > > and > > https://lkml.org/lkml/2012/9/6/270 > > There is probably some more details to fix and improve, but the current shape > should be enough to know if we want this and where - therefore any sign from > a maintainer would be greatly appreciated! I want to reiterate my opinion that I think power sequences in DT data is the wrong way to go. Powering sequences are device specific issues and should be handled in the device driver. But I also think that power sequences inside the drivers would probably be useful. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 1/4] Runtime Interpreted Power Sequences
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: > Some device drivers (panel backlights especially) need to follow precise > sequences for powering on and off, involving gpios, regulators, PWMs > with a precise powering order and delays to respect between each steps. > These sequences are board-specific, and do not belong to a particular > driver - therefore they have been performed by board-specific hook > functions to far. The sequences are not board-specific, they are device (backlight, etc.) specific. The sequences have been handled in board-specific hook functions so far because there hasn't been proper drivers for the devices. If I were to take the same panel (and backlight) you have and install it on my board, I would need the same power sequence. Tomi signature.asc Description: This is a digitally signed message part
Re: Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in fix_read_error function
On Thu, 13 Sep 2012 10:28:32 +0800 hank wrote:
> On 09/04/2012 11:07 AM, hank wrote:
>
> > From 0ba5879082544dc3aa13807087563b1258124b1e Mon Sep 17 00:00:00 2001
> > From: hank
> > Date: Tue, 4 Sep 2012 10:23:45 +0800
> > Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in
> > fix_read_error function
> >
> > in fix_read_error function, the conf->mirrors[read_disk].rdev may
> > become NULL, as in this function, rdev->nr_pending may be zero, anyone
> > can delete it. So should check if it is NULL before use.
> >
> > Signed-off-by: hank
> > ---
> > drivers/md/raid1.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> > index 611b5f7..fd8de28 100644
> > --- a/drivers/md/raid1.c
> > +++ b/drivers/md/raid1.c
> > @@ -2005,7 +2005,7 @@ static void fix_read_error(struct r1conf *conf, int
> > read_disk,
> > if (!success) {
> > /* Cannot read from anywhere - mark it bad */
> > struct md_rdev *rdev = conf->mirrors[read_disk].rdev;
> > - if (!rdev_set_badblocks(rdev, sect, s, 0))
> > + if (!rdev || !rdev_set_badblocks(rdev, sect, s, 0))
> > md_error(mddev, rdev);
> > break;
> > }
>
>
>
> Anyone can review this patch? I think it is a bug and should be fixed.
I agree there is a bug there but I don't think this is the right fix.
If rdev could be NULL there, then it could also be NULL in
md_error(mddev, conf->mirrors[r1_bio->read_disk].rdev);
in handle_read_error().
I think we should just hold on to the reference to the rdev until we are
done with it, like the follow.
Would you agree?
Thanks,
NeilBrown
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 611b5f7..eb1f8a3 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -333,9 +333,10 @@ static void raid1_end_read_request(struct bio *bio, int
error)
spin_unlock_irqrestore(>device_lock, flags);
}
- if (uptodate)
+ if (uptodate) {
raid_end_bio_io(r1_bio);
- else {
+ rdev_dec_pending(conf->mirrors[mirror].rdev, conf->mddev);
+ } else {
/*
* oops, read error:
*/
@@ -349,9 +350,8 @@ static void raid1_end_read_request(struct bio *bio, int
error)
(unsigned long long)r1_bio->sector);
set_bit(R1BIO_ReadError, _bio->state);
reschedule_retry(r1_bio);
+ /* don't drop the reference on read_disk yet */
}
-
- rdev_dec_pending(conf->mirrors[mirror].rdev, conf->mddev);
}
static void close_write(struct r1bio *r1_bio)
@@ -2220,6 +2220,7 @@ static void handle_read_error(struct r1conf *conf, struct
r1bio *r1_bio)
unfreeze_array(conf);
} else
md_error(mddev, conf->mirrors[r1_bio->read_disk].rdev);
+ rdev_dec_pending(conf->mirrors[r1_bio->read_disk].rdev, conf->mddev);
bio = r1_bio->bios[r1_bio->read_disk];
bdevname(bio->bi_bdev, b);
signature.asc
Description: PGP signature
Re: [PATCH] Fix queueing work if !bdi_cap_writeback_dirty()
Fengguang Wu writes: >> If used custom bdi with BDI_CAP_NO_WRITEBACK, wait_for_completion() >> (e.g. sync_inodes_sb()) will be blocked forever. > > The sync(2) block cannot be fixed by this patch? This patch fixes block problem too. >> I tested by custom bdi with BDI_CAP_NO_WRITEBACK - sync(2) blocked >> forever by this reason. > > What's your test script? How do you create/use that custom bdi? Ah, I wrote my kernel module to test. I guess there is no users in current kernel for now, because it doesn't work. Thanks. -- OGAWA Hirofumi -- 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] arm: tegra: fixing compilation error
As usb_phy.h got moved from mach to include/linux/usb and renamed as tegra_usb_phy.h, correcting it in the include path. Signed-off-by: Venu Byravarasu --- arch/arm/mach-tegra/board-dt-tegra20.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c b/arch/arm/mach-tegra/board-dt-tegra20.c index adc6b98..3308a65 100644 --- a/arch/arm/mach-tegra/board-dt-tegra20.c +++ b/arch/arm/mach-tegra/board-dt-tegra20.c @@ -41,7 +41,7 @@ #include #include -#include +#include #include "board.h" #include "clock.h" -- 1.7.1.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: linux-next: Tree for Sept 12 (kernel-panic after pressing any key at X login)
On Thu, Sep 13, 2012 at 5:18 AM, Sedat Dilek wrote: > On Wed, Sep 12, 2012 at 10:46 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 201209011: >> >> The pci tree lost its build failure. >> >> The mfd tree gained a conflict against Linus' tree. >> >> The omap_dss2 tree lost its conflict. >> >> The trivial tree gained a conflict against the mfd tree. >> >> The kvm tree gained a conflict against Linus' tree. >> >> The workqueues tree gained a conflict against the omap_dss2 tree. >> >> The usb tree gained conflicts against the usb.current tree. >> >> The staging tree gained a conflict against the thermal tree and a build >> failure for which I applied a merge fix patch. >> >> The tegra tree gained conflicts against the usb and arm-perf trees. >> >> >> > > Hi, > > this weeks linux-next seems to bring new and new issues, yay :-)! > > I have taken a photo, but can't say what can have caused. > The issue is reproducible... > Immediately, after pressing any key (when X-display-manager (lightdm) > and X-greeter are up) my machine panics and is no more usable (cold > rough brutal killer restart). > Note: Using upstart or systemd does not matter. > > Any pointer to an area where to dig into or any feedback in general is > welcome! > > Kind Regards, > - Sedat - [ CC Dmitry Torokhov (linux-input maintainer) plus linux-input ML ] By looking at my screenshot, someone could imagine that there is a problem coming from the input GIT branch(es) merges: input_to_handler() input_pass_values() input_handle_event() input_event() Unfortunately, with those 3 revert-patches I see the same kernel-panic. Dimitry, any idea what can cause this kernel-panic? - Sedat - 0001-Revert-Input-evdev-Add-the-events-callback.patch Description: Binary data 0002-Revert-Input-Send-events-one-packet-at-a-time.patch Description: Binary data 0003-Revert-Input-Move-autorepeat-to-the-event-passing-ph.patch Description: Binary data
Re: [PATCH 02/25] MPILIB: Provide count_leading/trailing_zeros() based on arch functions
On Mon, 10 Sep 2012, Kasatkin, Dmitry wrote: > > Signed-off-by: David Howells > > Cc: David S. Miller > > Cc: Dmitry Kasatkin > > Cc: Arnd Bergmann > > Hi James, > > Can you please apply this? Could you send me this and any other outstanding changes as patches against my -next branch, tested and signed-off ? Or, perhaps Mimi could do that as maintainer of the integrity subsystem. - James -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/20] Input: Make sure we follow all EV_KEY events
On Sat, Sep 01, 2012 at 09:46:58PM +0200, Henrik Rydberg wrote:
> For some EV_KEY types, sending a larger-than-one value causes the
> input state to oscillate. This patch makes sure this cannot happen,
> clearing up the autorepeat bypass logic in the process.
>
> Signed-off-by: Henrik Rydberg
Acked-by: Dmitry Torokhov
> ---
> drivers/input/input.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 8ebf116..4d64500 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -239,24 +239,30 @@ static void input_handle_event(struct input_dev *dev,
> break;
>
> case EV_KEY:
> - if (is_event_supported(code, dev->keybit, KEY_MAX) &&
> - !!test_bit(code, dev->key) != value) {
> + if (is_event_supported(code, dev->keybit, KEY_MAX)) {
> +
> + /* auto-repeat bypasses state updates */
> + if (value == 2) {
> + disposition = INPUT_PASS_TO_HANDLERS;
> + break;
> + }
> +
> + if (!!test_bit(code, dev->key) != !!value) {
>
> - if (value != 2) {
> __change_bit(code, dev->key);
> + disposition = INPUT_PASS_TO_HANDLERS;
> +
> if (value)
> input_start_autorepeat(dev, code);
> else
> input_stop_autorepeat(dev);
> }
> -
> - disposition = INPUT_PASS_TO_HANDLERS;
> }
> break;
>
> case EV_SW:
> if (is_event_supported(code, dev->swbit, SW_MAX) &&
> - !!test_bit(code, dev->sw) != value) {
> + !!test_bit(code, dev->sw) != !!value) {
>
> __change_bit(code, dev->sw);
> disposition = INPUT_PASS_TO_HANDLERS;
> @@ -283,7 +289,7 @@ static void input_handle_event(struct input_dev *dev,
>
> case EV_LED:
> if (is_event_supported(code, dev->ledbit, LED_MAX) &&
> - !!test_bit(code, dev->led) != value) {
> + !!test_bit(code, dev->led) != !!value) {
>
> __change_bit(code, dev->led);
> disposition = INPUT_PASS_TO_ALL;
> --
> 1.7.12
>
--
Dmitry
--
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 patches] libata new PCI IDs
Please pull 7b4f6ecacb14f384adc1a5a67ad95eb082c02bd1 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
Alan Cox (2):
ahci: Add alternate identifier for the 88SE9172
ahci: Add identifiers for ASM106x devices
Ben Hutchings (1):
ahci: Add JMicron 362 device IDs
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 50d5dea..7862d17 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -268,6 +268,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci_ign_iferr },
+ /* JMicron 362B and 362C have an AHCI function with IDE class code */
+ { PCI_VDEVICE(JMICRON, 0x2362), board_ahci_ign_iferr },
+ { PCI_VDEVICE(JMICRON, 0x236f), board_ahci_ign_iferr },
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
@@ -393,6 +396,8 @@ static const struct pci_device_id ahci_pci_tbl[] = {
.driver_data = board_ahci_yes_fbs }, /* 88se9125 */
{ PCI_DEVICE(0x1b4b, 0x917a),
.driver_data = board_ahci_yes_fbs }, /* 88se9172 */
+ { PCI_DEVICE(0x1b4b, 0x9192),
+ .driver_data = board_ahci_yes_fbs }, /* 88se9172 on
some Gigabyte */
{ PCI_DEVICE(0x1b4b, 0x91a3),
.driver_data = board_ahci_yes_fbs },
@@ -400,7 +405,10 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci }, /* PDC42819 */
/* Asmedia */
- { PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci }, /* ASM1061 */
+ { PCI_VDEVICE(ASMEDIA, 0x0601), board_ahci }, /* ASM1060 */
+ { PCI_VDEVICE(ASMEDIA, 0x0602), board_ahci }, /* ASM1060 */
+ { PCI_VDEVICE(ASMEDIA, 0x0611), board_ahci }, /* ASM1061 */
+ { PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci }, /* ASM1062 */
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
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 02/20] Input: Improve the events-per-packet estimate
On Sat, Sep 01, 2012 at 09:46:57PM +0200, Henrik Rydberg wrote:
> The events-per-packet estimate has so far been used by MT devices
> only. This patch adjusts the packet buffer size to also accomodate the
> KEY and MSC events. Keyboards normally send one or two keys at a
> time. MT devices normally send a number of button keys along with the
> MT information. The buffer size chosen here covers those cases, and
> matches the default buffer size in evdev. Since the input estimate is
> now preferred, remove the special input-mt estimate.
>
> Reviewed-by: Ping Cheng
> Signed-off-by: Henrik Rydberg
Makes sense.
Acked-by: Dmitry Torokhov
> ---
> drivers/input/input-mt.c | 1 -
> drivers/input/input.c| 10 +++---
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
> index c6df704..58bde77 100644
> --- a/drivers/input/input-mt.c
> +++ b/drivers/input/input-mt.c
> @@ -42,7 +42,6 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int
> num_slots)
> mt->num_slots = num_slots;
> input_set_abs_params(dev, ABS_MT_SLOT, 0, num_slots - 1, 0, 0);
> input_set_abs_params(dev, ABS_MT_TRACKING_ID, 0, TRKID_MAX, 0, 0);
> - input_set_events_per_packet(dev, 6 * num_slots);
>
> /* Mark slots as 'unused' */
> for (i = 0; i < num_slots; i++)
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 6e90705..8ebf116 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1777,6 +1777,9 @@ static unsigned int
> input_estimate_events_per_packet(struct input_dev *dev)
> if (test_bit(i, dev->relbit))
> events++;
>
> + /* Make room for KEY and MSC events */
> + events += 7;
> +
> return events;
> }
>
> @@ -1815,6 +1818,7 @@ int input_register_device(struct input_dev *dev)
> {
> static atomic_t input_no = ATOMIC_INIT(0);
> struct input_handler *handler;
> + unsigned int packet_size;
> const char *path;
> int error;
>
> @@ -1827,9 +1831,9 @@ int input_register_device(struct input_dev *dev)
> /* Make sure that bitmasks not mentioned in dev->evbit are clean. */
> input_cleanse_bitmasks(dev);
>
> - if (!dev->hint_events_per_packet)
> - dev->hint_events_per_packet =
> - input_estimate_events_per_packet(dev);
> + packet_size = input_estimate_events_per_packet(dev);
> + if (dev->hint_events_per_packet < packet_size)
> + dev->hint_events_per_packet = packet_size;
>
> /*
>* If delay and period are pre-set by the driver, then autorepeating
> --
> 1.7.12
>
--
Dmitry
--
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 01/20] Input: Break out MT data
On Sat, Sep 01, 2012 at 09:46:56PM +0200, Henrik Rydberg wrote:
> Move all MT-related things to a separate place. This saves some
> bytes for non-mt input devices, and prepares for new MT features.
>
> Signed-off-by: Henrik Rydberg
...
> @@ -1287,10 +1284,8 @@ struct input_dev {
>
> int rep[REP_CNT];
>
> - struct input_mt_slot *mt;
> - int mtsize;
> + struct input_mt *mt;
> int slot;
> - int trkid;
>
> struct input_absinfo *absinfo;
Shouldn't 'slot' go into struct input_mt as well?
Thanks.
--
Dmitry
--
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 v9 05/13] ARM: SoC: convert Exynos4 to SoC descriptor
On 9/12/12, Arnd Bergmann wrote:
> From: Marc Zyngier
>
> Convert Exynos4 to use the SoC descriptor to provide its SMP
> and CPU hotplug operations.
>
> Cc: Kukjin Kim
> Tested-by: Kyungmin Park
Acked-by: Kyungmin Park
> Signed-off-by: Marc Zyngier
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-exynos/common.h |5 +
> arch/arm/mach-exynos/hotplug.c | 18 +++---
> arch/arm/mach-exynos/mach-armlex4210.c |1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c |1 +
> arch/arm/mach-exynos/mach-nuri.c |1 +
> arch/arm/mach-exynos/mach-origen.c |1 +
> arch/arm/mach-exynos/mach-smdk4x12.c |2 ++
> arch/arm/mach-exynos/mach-smdkv310.c |2 ++
> arch/arm/mach-exynos/mach-universal_c210.c |1 +
> arch/arm/mach-exynos/platsmp.c | 20
> 10 files changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index aed2eeb..dac146d 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -14,6 +14,7 @@
>
> extern struct sys_timer exynos4_timer;
>
> +struct map_desc;
> void exynos_init_io(struct map_desc *mach_desc, int size);
> void exynos4_init_irq(void);
> void exynos5_init_irq(void);
> @@ -59,4 +60,8 @@ void exynos4212_register_clocks(void);
> #define exynos4212_register_clocks()
> #endif
>
> +extern struct smp_operations exynos_smp_ops;
> +
> +extern void exynos_cpu_die(unsigned int cpu);
> +
> #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
> diff --git a/arch/arm/mach-exynos/hotplug.c
> b/arch/arm/mach-exynos/hotplug.c
> index 9c17a0a..d0a5a70 100644
> --- a/arch/arm/mach-exynos/hotplug.c
> +++ b/arch/arm/mach-exynos/hotplug.c
> @@ -21,6 +21,8 @@
>
> #include
>
> +#include "common.h"
> +
> extern volatile int pen_release;
>
> static inline void cpu_enter_lowpower(void)
> @@ -95,17 +97,12 @@ static inline void platform_do_lowpower(unsigned int
> cpu, int *spurious)
> }
> }
>
> -int platform_cpu_kill(unsigned int cpu)
> -{
> - return 1;
> -}
> -
> /*
> * platform-specific code to shutdown a CPU
> *
> * Called with IRQs disabled
> */
> -void platform_cpu_die(unsigned int cpu)
> +void __cpuinit exynos_cpu_die(unsigned int cpu)
> {
> int spurious = 0;
>
> @@ -124,12 +121,3 @@ void platform_cpu_die(unsigned int cpu)
> if (spurious)
> pr_warn("CPU%u: %u spurious wakeup calls\n", cpu, spurious);
> }
> -
> -int platform_cpu_disable(unsigned int cpu)
> -{
> - /*
> - * we don't allow CPU 0 to be shutdown (it is still too special
> - * e.g. clock tick interrupts)
> - */
> - return cpu == 0 ? -EPERM : 0;
> -}
> diff --git a/arch/arm/mach-exynos/mach-armlex4210.c
> b/arch/arm/mach-exynos/mach-armlex4210.c
> index 5a3daa0..3f37a5e 100644
> --- a/arch/arm/mach-exynos/mach-armlex4210.c
> +++ b/arch/arm/mach-exynos/mach-armlex4210.c
> @@ -199,6 +199,7 @@ static void __init armlex4210_machine_init(void)
> MACHINE_START(ARMLEX4210, "ARMLEX4210")
> /* Maintainer: Alim Akhtar */
> .atag_offset= 0x100,
> + .smp= smp_ops(exynos_smp_ops),
> .init_irq = exynos4_init_irq,
> .map_io = armlex4210_map_io,
> .handle_irq = gic_handle_irq,
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index ef770bc..8833060 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -79,6 +79,7 @@ static char const *exynos5250_dt_compat[] __initdata = {
> DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
> /* Maintainer: Kukjin Kim */
> .init_irq = exynos5_init_irq,
> + .smp= smp_ops(exynos_smp_ops),
> .map_io = exynos5250_dt_map_io,
> .handle_irq = gic_handle_irq,
> .init_machine = exynos5250_dt_machine_init,
> diff --git a/arch/arm/mach-exynos/mach-nuri.c
> b/arch/arm/mach-exynos/mach-nuri.c
> index ea785fc..ffaa355 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -1383,6 +1383,7 @@ static void __init nuri_machine_init(void)
> MACHINE_START(NURI, "NURI")
> /* Maintainer: Kyungmin Park */
> .atag_offset= 0x100,
> + .smp= smp_ops(exynos_smp_ops),
> .init_irq = exynos4_init_irq,
> .map_io = nuri_map_io,
> .handle_irq = gic_handle_irq,
> diff --git a/arch/arm/mach-exynos/mach-origen.c
> b/arch/arm/mach-exynos/mach-origen.c
> index 4e574c2..abd0e60 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -806,6 +806,7 @@ static void __init origen_machine_init(void)
> MACHINE_START(ORIGEN, "ORIGEN")
> /* Maintainer: JeongHyeon Kim */
> .atag_offset= 0x100,
> + .smp= smp_ops(exynos_smp_ops),
> .init_irq
Re: [PATCH v4 00/21] OMAP UART Patches
On Wed, Sep 12, 2012 at 08:25:30PM +, Paul Walmsley wrote: > Hi > > On Wed, 12 Sep 2012, Felipe Balbi wrote: > > > On Tue, Sep 11, 2012 at 10:02:48PM +, Paul Walmsley wrote: > > > > > The bad news is that N800 no longer boots -- or the UART dies during > > > serial init: > > > > > > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt > > > > > > The problem doesn't seem to affect the 2430SDP. > > > > > > Could you put together a patch to fix N800? > > > > I'll see what I can do. BTW, is that log with DEBUG_LL enabled ? > > Yes. Here's the .config that was used on N800: > > http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/build/n800_b_testconfig/Kconfig Thanks :-) -- balbi signature.asc Description: Digital signature
Re: [GIT] Digital signature library bugfix
On Thu, 13 Sep 2012, Linus Torvalds wrote: > On Wed, Sep 12, 2012 at 6:22 PM, Kasatkin, Dmitry > wrote: > > > > But I will re-send updated patch in a moment. > > Ok, I took that updated patch instead of the pull request, since I > liked that much more, and hadn't actually pushed out the pull yet. Thanks. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/3] KVM: perf: kvm events analysis tool
static const char * const kvm_usage[] = {
-"perf kvm [] {top|record|report|diff|buildid-list}",
+"perf kvm [] {top|record|report|diff|buildid-list|stat}",
NULL
};
The usage for the report/record sub commands of stat is never shown. e.g.,
$ perf kvm stat
--> shows help for perf-stat
$ perf kvm
--> shows the above and perf-kvm's usage
[I deleted this thread, so having to reply to one of my responses.
hopefully noone is unduly harmed by this.]
I've been using this command a bit lately -- especially on nested
virtualization -- and I think the syntax is quirky - meaning wrong. In
my case I always follow up a record with a report and end up using a
shell script wrapper that combines the 2 and running it repeatedly. e.g.,
$PERF kvm stat record -o $FILE -p $pid -- sleep $time
[ $? -eq 0 ] && $PERF --no-pager kvm -i $FILE stat report
As my daughter likes to say - awkward.
That suggests what is really needed is a 'live' mode - a continual
updating of the output like perf top, not a record and analyze later
mode. Which does come back to why I responded to this email -- the
syntax is klunky and awkward.
So, I spent a fair amount of time today implementing a live mode. And
after a lot of swearing at the tracepoint processing code I finally have
it working. And the format extends easily (meaning < day and the next
step) to a perf-based kvm_stat replacement. Example syntax is:
perf kvm stat [-p |-a|...]
which defaults to an update delay of 1 second, and vmexit analysis.
The guts of the processing logic come from the existing kvm-events code.
The changes focus on combining the record and report paths into one. The
display needs some help (Arnaldo?), but it seems to work well.
I'd like to get opinions on what next? IMO, the record/report path
should not get a foot hold from a backward compatibility perspective and
having to maintain those options. I am willing to take the existing
patches into git to maintain authorship and from there apply patches to
make the live mode work - which includes a bit of refactoring of perf
code (like the stats changes).
Before I march down this path, any objections, opinions, etc?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Input: joydev - fix axes values sent in initial js_event
On Wed, Sep 05, 2012 at 10:09:57PM +0200, Vojtěch Boček wrote: > Hi, > > 2012/9/5 Dmitry Torokhov > > So what guarantees that joystick events will arrive in time, before > > joydev_generate_startup_event() is called? It looks like your solution > > is racy... > > > > I wonder if we should not generate the startup event until we have seen > > at least one EV_SYN, i.e. entire device state has been transmitted to > > us. > > I just tried to delay read() until first EV_SYN arrives as you suggested, > but that was not the problem, at least not the main one. First joystick > input events arrives immediately after it is plugged in and driver is loaded, > but when that happens, joydev may not be (and most likely is not) > opened yet, which means the events will never reach joydev because of > "if (!handle->open)" check in input_pass_event. > > I wonder how to handle this. Is "if(!handle->open)" valid check? I think so, > my guess is that joydev is the only handler with internal buffer, and it > is useless to update that buffer when the device is not opened. > I think reloading abs values on joydev open should be okay. > > I suppose that if we reload abs values on joydev open, waiting for first > sync is not needed, yes? > > So the patch could look like this: This makes sense. Just to confirm - have you tried the patch and verified it works for you? Thanks. -- Dmitry -- 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: host: tegra: code clean up
On 09/12/2012 09:42 PM, Venu Byravarasu wrote: > Stephen Warren wrote at Wednesday, September 12, 2012 11:41 PM: >> On 09/12/2012 01:02 AM, Venu Byravarasu wrote: >>> As part of code clean up, used devm counterparts for the APIs >>> possible. >> >> Almost all of this patch has already been applied as: > > Agree. > Currently Balbi's tree has bit old ehci-tegra.c. Quite possibly. That would happen if patches to ehci-tegra.c were checked into other branches, which have not yet been merged to Linus's tree, and hence have not made it into the baseline for Felipe's tree. This is especially likely as ehci-tegra.c isn't something that Felipe's xceiv branch would usually take patches for IIRC. > Because of this the patches prepared with linux-next need to be rebased onto > this tree and prepare a new patch. > My main intention behind pushing this patch was to get all changes of > ehci-tegra.c from linux-next into balbi's code base so that I can push the > same patch against either balbi's tree or linux-next. That's not the way the Linux branching model works. The primary way for Felipe's branch to pick up changes from another branch is for the other branch to be merged by Linus, and then Felipe to either merge Linus's branch into his, or start a new branch based on a more recent tag from Linus's tree. If you send patches to Felipe that duplicate work that's already happened in another branch, you'll most likely end up causing merge conflicts when Felipe's branch is merged with the other branch containing the same work in linux-next, Greg's USB tree, and Linus's tree. Of course, you might get lucky and avoid conflicts if the patches are identical, but duplicate patches are still not a good idea. It's best if you send patches that apply and operate correctly on one particular branch, e.g. just Felipe's or some other USB (sub-)maintainer's branch. If your patches actually rely on changes from multiple different branches, then that is problematic. The simplest answer is to simply wait for the (end of the) next kernel merge window when everything has been merged together, and then start sending patches based on the merged result. In some cases, branches can be merged together other than by Linus, although you do have to be quite careful to avoid pain when doing this. It's best to plan out what patches you'll send, where you expect they will be applied, and point out any such dependencies to the maintainers ahead of time. Developing all your big patches first and then sending them, rather than developing them piecemeal, may help you plan this out better, at least at first. -- 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] input: gpio_keys_polled: fix dt pdata->nbuttons
On Wed, Sep 12, 2012 at 06:27:23PM -0300, Alexandre Pereira da Silva wrote: > pdata->nbuttons should be updated by the dt code. > > Signed-off-by: Alexandre Pereira da Silva Applied, thank you Alexandre. > --- > drivers/input/keyboard/gpio_keys_polled.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/input/keyboard/gpio_keys_polled.c > b/drivers/input/keyboard/gpio_keys_polled.c > index 7908952..f2142de 100644 > --- a/drivers/input/keyboard/gpio_keys_polled.c > +++ b/drivers/input/keyboard/gpio_keys_polled.c > @@ -129,6 +129,7 @@ gpio_keys_polled_get_devtree_pdata(struct device *dev) > } > > pdata->buttons = (struct gpio_keys_button *)(pdata + 1); > + pdata->nbuttons = nbuttons; > > pdata->rep = !!of_get_property(node, "autorepeat", NULL); > of_property_read_u32(node, "poll-interval", >poll_interval); > -- > 1.7.10 > -- Dmitry -- 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/3] perf: require exclude_guest to use PEBS - kernel side enforcement
Em Wed, Sep 12, 2012 at 10:33:36PM -0600, David Ahern escreveu: > On 9/12/12 8:38 PM, Namhyung Kim wrote: > >I see a whitespace problem here. :) > > grr an extra freaking tab. As people say down here, it happens, even in the best families... :-P - Arnaldo $ shutdown now tho -- 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] ARM: fix bad applied patch for arch/arm/Kconfig of stable 3.0.y tree.
ARM_ERRATA_764369 and PL310_ERRATA_769419 do not appear in config menu in stable 3.0.y tree. This is because backported patch for arm/arm/Kconfig applied wrong place. This patch solves it. Signed-off-by: Tetsuyuki Kobayashi --- Hello, Greg This is patch for stable 3.0.y tree. 3.2.y, 3.4.y and 3.5.y do not have this problem. Only 3.0.y. arch/arm/Kconfig | 52 ++-- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7692bca..85368ed 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1234,6 +1234,32 @@ config ARM_ERRATA_754327 This workaround defines cpu_relax() as smp_mb(), preventing correctly written polling loops from denying visibility of updates to memory. +config ARM_ERRATA_764369 + bool "ARM errata: Data cache line maintenance operation by MVA may not succeed" + depends on CPU_V7 && SMP + help + This option enables the workaround for erratum 764369 + affecting Cortex-A9 MPCore with two or more processors (all + current revisions). Under certain timing circumstances, a data + cache line maintenance operation by MVA targeting an Inner + Shareable memory region may fail to proceed up to either the + Point of Coherency or to the Point of Unification of the + system. This workaround adds a DSB instruction before the + relevant cache maintenance functions and sets a specific bit + in the diagnostic control register of the SCU. + +config PL310_ERRATA_769419 + bool "PL310 errata: no automatic Store Buffer drain" + depends on CACHE_L2X0 + help + On revisions of the PL310 prior to r3p2, the Store Buffer does + not automatically drain. This can cause normal, non-cacheable + writes to be retained when the memory system is idle, leading + to suboptimal I/O performance for drivers using coherent DMA. + This option adds a write barrier to the cpu_idle loop so that, + on systems with an outer cache, the store buffer is drained + explicitly. + endmenu source "arch/arm/common/Kconfig" @@ -1298,32 +1324,6 @@ source "drivers/pci/Kconfig" source "drivers/pcmcia/Kconfig" -config ARM_ERRATA_764369 - bool "ARM errata: Data cache line maintenance operation by MVA may not succeed" - depends on CPU_V7 && SMP - help - This option enables the workaround for erratum 764369 - affecting Cortex-A9 MPCore with two or more processors (all - current revisions). Under certain timing circumstances, a data - cache line maintenance operation by MVA targeting an Inner - Shareable memory region may fail to proceed up to either the - Point of Coherency or to the Point of Unification of the - system. This workaround adds a DSB instruction before the - relevant cache maintenance functions and sets a specific bit - in the diagnostic control register of the SCU. - -config PL310_ERRATA_769419 - bool "PL310 errata: no automatic Store Buffer drain" - depends on CACHE_L2X0 - help - On revisions of the PL310 prior to r3p2, the Store Buffer does - not automatically drain. This can cause normal, non-cacheable - writes to be retained when the memory system is idle, leading - to suboptimal I/O performance for drivers using coherent DMA. - This option adds a write barrier to the cpu_idle loop so that, - on systems with an outer cache, the store buffer is drained - explicitly. - endmenu menu "Kernel Features" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: phy: re-organize tegra phy driver
On 09/12/2012 09:49 PM, Venu Byravarasu wrote: > Stephen Warren wrote at Thursday, September 13, 2012 12:06 AM: >> On 09/12/2012 04:58 AM, Venu Byravarasu wrote: >>> Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc. >>> In order to support USB phy drivers on these SOCs, existing >>> phy driver is split into SOC agnostic common USB phy driver and >>> tegra2 specific USB phy driver. >>> This will facilitate easy addition & deletion of phy drivers for >>> Tegra SOCs. >> >> For capitalization/related reasons, I would re-write the commit >> description as: >> >> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc. >> In order to support USB PHY drivers on these SoCs, existing > > Will change tegra2 to Tegra20 and similar for Tegra30 & NVIDIA. > However as phy is not an acronym, should we still have it in Caps? I'd certainly expect to see PHY in all-caps, yes. As entirely arbitrary justification, see the precedent at: https://en.wikipedia.org/wiki/PHY_(chip) Sorry for bike-shedding, but I'm picky about that kind of thing, at least sometimes. -- 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: phy: re-organize tegra phy driver
On 09/12/2012 10:16 PM, Venu Byravarasu wrote:
> Forgot to address some of the comments made by stephen, in my previous update.
> Hence addressing them now.
> Thanks a lot Stephen, for detailed review.
OK, so since this patch is basically just splitting the file into
multiple parts, you can ignore most of my review comments for this patch
and consider them as input for things in future cleanup patches.
One comment below:
> Stephen Warren wrote at Thursday, September 13, 2012 12:06 AM:
>> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
...
>>> +static int tegra2_usb_phy_open(struct tegra_usb_phy *phy)
>>> +{
>>> + struct tegra_ulpi_config *ulpi_config;
>>> + int err;
>>> +
>>> + if (phy_is_ulpi(phy)) {
>>
>> Similarly, this seems like it'd be better as two separate functions,
>> since there's already an op defined for open.
>
> tegra2_usb_phy_open is called via open of ops only.
> Plz let me know if you still have any concern here.
What I meant was the body of this function is:
tegra2_usb_phy_open:
if (ulpi)
do a bunch of ULPI stuff
else
do a bunch of UTMI stuff
It's seems it'd be simpler to split this into two functions:
tegra2_usb_ulpi_phy_open:
do a bunch of ULPI stuff
tegra2_usb_utmi_phy_open:
do a bunch of UTMI stuff
... and have the code that initializes the ops assign the appropriate
one of those two functions into the open op, just like it does for
all/most other ops.
Still, this may come under the same argument as above; fuel for future
cleanup since the existing code already works this way?
--
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 v5 2/2] OMAP:IOMMU:flush L1 and L2 caches
Hi Russell,
On Wed, Sep 12, 2012 at 10:11 PM, Russell King - ARM Linux
wrote:
> On Wed, Sep 12, 2012 at 08:49:16PM +0530, Gupta, Ramesh wrote:
>> Thanks to the RMK's suggestions.
>
> I should've made clear the distinction between _range and _area.
> A _range function takes start and end. An _area function takes a start
> and size. So...
>
>> -static void flush_iopgd_range(u32 *first, u32 *last)
>> +static void flush_iopgd_range(u32 *first, size_t size)
>
> This should change to flush_iopgd_area().
Looks like I missed this, I will fix and send the updated patch.
>
>> {
>> - /* FIXME: L2 cache should be taken care of if it exists */
>> - do {
>> - asm("mcrp15, 0, %0, c7, c10, 1 @ flush_pgd"
>> - : : "r" (first));
>> - first += L1_CACHE_BYTES / sizeof(*first);
>> - } while (first <= last);
>> + phys_addr_t phys = virt_to_phys(first);
>> +
>> + iommu_flush_area(first, size);
>> + outer_flush_range(phys, phys + size);
>> }
>>
>> -static void flush_iopte_range(u32 *first, u32 *last)
>> +static void flush_iopte_range(u32 *first, size_t size)
>> +
>
> flush_iopte_area(). (And there shouldn't be a blank line between this
> and the open curley.)
I will fix it.
> Otherwise, looks fine.
thank you.
Best regards
Ramesh Gupta G
--
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/3] perf: require exclude_guest to use PEBS - kernel side enforcement
On 9/12/12 8:38 PM, Namhyung Kim wrote:
Hi David,
On Wed, 12 Sep 2012 09:16:29 -0600, David Ahern wrote:
From: Peter Zijlstra
Per Peter:
"Intel PEBS in VT-x context uses the DS address as a guest linear address,
even though its programmed by the host as a host linear address. This
either results in guest memory corruption and or the hardware faulting and
'crashing' the virtual machine. Therefore we have to disable PEBS on VT-x
enter and re-enable on VT-x exit, enforcing a strict exclude_guest.
This patch enforces exclude_guest kernel side.
[snip]
@@ -380,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip) {
int precise = 0;
+ if (!event->attr.exclude_guest)
+ return -EOPNOTSUPP;
I see a whitespace problem here. :)
grr an extra freaking tab.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] sound/soc/soc-core.c: Remove useless kfree
On Wed, Sep 12, 2012 at 05:06:46PM +0200, Peter Senna Tschudin wrote: > From: Peter Senna Tschudin > > Remove useless kfree() and clean up code related to the removal. > > The semantic patch that finds this problem is as follows: > (http://coccinelle.lip6.fr/) Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add missing perf_hpp__init for pipe-mode
Oops, please do s/record/report/ on the subject line, sorry! ;-) Also I don't see the issue on the other users of the setup_browser() - i.e. perf annotate and perf top - since they call it unconditionally. Thanks, Namhyung -- 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] perf record: Add missing perf_hpp__init for pipe-mode
From: Namhyung Kim
The perf_hpp__init() function was only called from setup_browser() so
that the pipe-mode missed the initialization thus didn't respond to
related options. Fix it.
Reported-by: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 97b2e6300f4c..279155a47d1c 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -689,8 +689,10 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
if (strcmp(report.input_name, "-") != 0)
setup_browser(true);
- else
+ else {
use_browser = 0;
+ perf_hpp__init(false, false);
+ }
/*
* Only in the newt browser we are doing integrated annotation,
--
1.7.11.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 2/2] [trivial] Documentation: broken URL in libata
On 02/13/2012 12:22 PM, Randy Dunlap wrote: On 02/13/2012 01:09 AM, Michael Opdenacker wrote: Fix broken link to license text: http://www.opensource.org/licenses/osl-1.1.txt The text for version 1.1 of the Open Sofware license doesn't seem to be available anywhere on http://www.opensource.org/ any more. Replace it with a snapshot from the Internet Wayback Machine. That's one option. Too bad opensource.org doesn't provide archives. OSL v1.1 is also available here: http://fedoraproject.org/wiki/Licensing:OSL1.1 and here: http://www.samurajdata.se/opensource/mirror/licenses/osl.php Jeff, I don't suppose there is any chance of changing this file's license? (since the Debian people found it to be a problem .. long ago) Yeah, that's fine... -- 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: phy: re-organize tegra phy driver
Forgot to address some of the comments made by stephen, in my previous update.
Hence addressing them now.
Thanks a lot Stephen, for detailed review.
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Thursday, September 13, 2012 12:06 AM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-te...@vger.kernel.org
> Subject: Re: [PATCH] USB: phy: re-organize tegra phy driver
>
> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> > Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> > In order to support USB phy drivers on these SOCs, existing
> > phy driver is split into SOC agnostic common USB phy driver and
> > tegra2 specific USB phy driver.
> > This will facilitate easy addition & deletion of phy drivers for
> > Tegra SOCs.
>
> For capitalization/related reasons, I would re-write the commit
> description as:
>
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
> PHY driver is split into SoC agnostic common USB PHY driver and
> Tegra20-specific USB phy driver. This will facilitate easy addition
> and deletion of phy drivers for Tegra SoCs.
>
> ... and s/tegra/Tegra/ in the patch subject.
>
> Tested-by: Stephen Warren
>
> (On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
> breakout board)
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>
> > @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > }
> > }
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type",
> "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
>
> Do we not support device mode yet? There's a dr_mode property in the DT
> that's supposed to indicate host/device/otg.
>
Device & otg support will be added soon.
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
>
> > +#include
>
> Please remove that #include statement; the heaer is not needed, and will
> be deleted in the kernel 3.7 merge window.
Sure, will remove it.
>
> > +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> > +{
> > + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> > + if (IS_ERR(phy->pad_clk)) {
> > + pr_err("%s: can't get utmip pad clock\n", __func__);
> > + return PTR_ERR(phy->pad_clk);
> > + }
> > +
> > + if (phy->instance == 0) {
> > + phy->pad_regs = phy->regs;
> > + } else {
>
> Can we use something other than phy->instance here? I see lots of usage
> of this field, but we should really be deleting the following code from
> ehci-tegra.c, rather the propagating the use of that field.
I too feel the same way.
Planning to address it in next patches.
>
> /* This is pretty ugly and needs to be fixed when we do only
> * device-tree probing. Old code relies on the platform_device
> * numbering that we lack for device-tree-instantiated devices.
> */
> if (instance < 0) {
> switch (res->start) {
> case TEGRA_USB_BASE:
> instance = 0;
> break;
> case TEGRA_USB2_BASE:
> instance = 1;
> break;
> case TEGRA_USB3_BASE:
> instance = 2;
> break;
> default:
> err = -ENODEV;
> dev_err(>dev, "unknown usb instance\n");
> goto fail_io;
> }
> }
>
> Still, I suppose the cleanup not to use the instance value could be a
> later patch as long as you're aware of the issue and planning to solve it.
Yes, planning to address it in next patches.
>
> > + phy->pad_regs = ioremap(TEGRA_USB_BASE,
> TEGRA_USB_SIZE);
>
> Hmmm. Why do we need to remap the registers again? Didn't the EHCI
> controller already map them? I'm a little confused what in HW causes the
> need for this whole if statement.
>
In order to have very minimal changes in the patch, I did not clean this up.
This was taken from old code, which is yet to be cleaned up.
This patch just moves tegra2 specific code from single phy driver to
tegra2_usb_phy.c
Will address all clean up stuff in next patches.
> > + if (!phy->pad_regs) {
> > + pr_err("%s: can't remap usb registers\n", __func__);
> > + clk_put(phy->pad_clk);
> > + return -ENOMEM;
> > +
[RFC] sched: nohz_idle_balance
On tickless system, one CPU runs load balance for all idle CPUs. The cpu_load of this CPU is updated before starting the load balance of each other idle CPUs. We should instead update the cpu_load of the balance_cpu. Signed-off-by: Vincent Guittot --- kernel/sched/fair.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 1ca4fe4..9ae3a5b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum cpu_idle_type idle) if (need_resched()) break; - raw_spin_lock_irq(_rq->lock); - update_rq_clock(this_rq); - update_idle_cpu_load(this_rq); - raw_spin_unlock_irq(_rq->lock); + rq = cpu_rq(balance_cpu); + + raw_spin_lock_irq(>lock); + update_rq_clock(rq); + update_idle_cpu_load(rq); + raw_spin_unlock_irq(>lock); rebalance_domains(balance_cpu, CPU_IDLE); - rq = cpu_rq(balance_cpu); if (time_after(this_rq->next_balance, rq->next_balance)) this_rq->next_balance = rq->next_balance; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] leds-lp5523: Fix riskiness of the page fault
On Wed, Sep 12, 2012 at 8:16 PM, Kim, Milo wrote:
> The last attribute should be terminated as NULL because any member of
> attribute structure is accessed while adding the sysfs file.
> If not, invalid address may cause the page fault problem.
>
Thanks, applied
-Bryan
> Signed-off-by: Milo(Woogyom) Kim
> ---
> drivers/leds/leds-lp5523.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index 5ebdc92..97994ff 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -759,6 +759,7 @@ static struct attribute *lp5523_attributes[] = {
> _attr_engine2_leds.attr,
> _attr_engine3_load.attr,
> _attr_engine3_leds.attr,
> + NULL,
> };
>
> static const struct attribute_group lp5523_group = {
> --
> 1.7.9.5
>
>
> Best Regards,
> Milo
>
>
--
Bryan Wu
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] leds-lp5523: turn off the LED engines on unloading the driver
On Wed, Sep 12, 2012 at 8:16 PM, Kim, Milo wrote:
> The LP5523 has 3 engines which are used for running LED patterns.
> These engines should be off while unloading the driver.
> Obviously, LP5523 platform data are used for releasing the resource
> such like enable()/release_resource(), but these are not mandatory.
> Therefore this patch is required without the platform data dependency.
>
Thanks, merged into my for-next branch
-Bryan
> Signed-off-by: Milo(Woogyom) Kim
> ---
> drivers/leds/leds-lp5523.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index 3d60428..5ebdc92 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -997,6 +997,9 @@ static int lp5523_remove(struct i2c_client *client)
> struct lp5523_chip *chip = i2c_get_clientdata(client);
> int i;
>
> + /* Disable engine mode */
> + lp5523_write(client, LP5523_REG_OP_MODE, LP5523_CMD_DISABLED);
> +
> lp5523_unregister_sysfs(client);
>
> for (i = 0; i < chip->num_leds; i++) {
> --
> 1.7.9.5
>
>
> Best Regards,
> Milo
>
--
Bryan Wu
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: phy: re-organize tegra phy driver
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Thursday, September 13, 2012 12:06 AM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-te...@vger.kernel.org
> Subject: Re: [PATCH] USB: phy: re-organize tegra phy driver
>
> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> > Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> > In order to support USB phy drivers on these SOCs, existing
> > phy driver is split into SOC agnostic common USB phy driver and
> > tegra2 specific USB phy driver.
> > This will facilitate easy addition & deletion of phy drivers for
> > Tegra SOCs.
>
> For capitalization/related reasons, I would re-write the commit
> description as:
>
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
Will change tegra2 to Tegra20 and similar for Tegra30 & NVIDIA.
However as phy is not an acronym, should we still have it in Caps?
> PHY driver is split into SoC agnostic common USB PHY driver and
> Tegra20-specific USB phy driver. This will facilitate easy addition
> and deletion of phy drivers for Tegra SoCs.
>
> ... and s/tegra/Tegra/ in the patch subject.
>
> Tested-by: Stephen Warren
>
> (On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
> breakout board)
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>
> > @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > }
> > }
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type",
> "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
>
> Do we not support device mode yet? There's a dr_mode property in the DT
> that's supposed to indicate host/device/otg.
>
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
>
> > +#include
>
> Please remove that #include statement; the heaer is not needed, and will
> be deleted in the kernel 3.7 merge window.
>
> > +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> > +{
> > + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> > + if (IS_ERR(phy->pad_clk)) {
> > + pr_err("%s: can't get utmip pad clock\n", __func__);
> > + return PTR_ERR(phy->pad_clk);
> > + }
> > +
> > + if (phy->instance == 0) {
> > + phy->pad_regs = phy->regs;
> > + } else {
>
> Can we use something other than phy->instance here? I see lots of usage
> of this field, but we should really be deleting the following code from
> ehci-tegra.c, rather the propagating the use of that field.
>
> /* This is pretty ugly and needs to be fixed when we do only
> * device-tree probing. Old code relies on the platform_device
> * numbering that we lack for device-tree-instantiated devices.
> */
> if (instance < 0) {
> switch (res->start) {
> case TEGRA_USB_BASE:
> instance = 0;
> break;
> case TEGRA_USB2_BASE:
> instance = 1;
> break;
> case TEGRA_USB3_BASE:
> instance = 2;
> break;
> default:
> err = -ENODEV;
> dev_err(>dev, "unknown usb instance\n");
> goto fail_io;
> }
> }
>
> Still, I suppose the cleanup not to use the instance value could be a
> later patch as long as you're aware of the issue and planning to solve it.
>
> > + phy->pad_regs = ioremap(TEGRA_USB_BASE,
> TEGRA_USB_SIZE);
>
> Hmmm. Why do we need to remap the registers again? Didn't the EHCI
> controller already map them? I'm a little confused what in HW causes the
> need for this whole if statement.
>
> > + if (!phy->pad_regs) {
> > + pr_err("%s: can't remap usb registers\n", __func__);
> > + clk_put(phy->pad_clk);
> > + return -ENOMEM;
> > + }
> > + }
>
> > +static void tegra2_utmi_phy_clk_disable(struct tegra_usb_phy *phy)
> > +{
> > + unsigned long val;
> > + void __iomem *base = phy->regs;
> > +
> > + if (phy->instance == 0) {
>
> Hmmm. There sure are a lot of places where the code is conditional based
> on instance. This seems to be crying out to be split into more ops
> functions that get set up once at probe() time and then just used.
>
> > +static int tegra2_utmi_phy_power_off(struct
RE: [PATCH] usb: host: tegra: code clean up
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, September 12, 2012 11:41 PM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: host: tegra: code clean up
>
> On 09/12/2012 01:02 AM, Venu Byravarasu wrote:
> > As part of code clean up, used devm counterparts for the APIs
> > possible.
>
> Almost all of this patch has already been applied as:
Agree.
Currently Balbi's tree has bit old ehci-tegra.c.
Because of this the patches prepared with linux-next need to be rebased onto
this tree and prepare a new patch.
My main intention behind pushing this patch was to get all changes of
ehci-tegra.c from linux-next into balbi's code base so that I can push the same
patch against either balbi's tree or linux-next.
> bc2ff98 drivers/usb/host/ehci-tegra.c: use devm_ functions
>
> (btw, that patch has a much better patch subject than this one)
>
> The only additions in your patch are shown below, and those changes
> should indeed be a separate patch.
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> > index 6223d17..dba9f07 100644
> > --- a/drivers/usb/host/ehci-tegra.c
> > +++ b/drivers/usb/host/ehci-tegra.c
> > @@ -701,7 +701,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > break;
> > default:
> > err = -ENODEV;
> > - dev_err(>dev, "unknown usb instance\n");
> > + dev_err(>dev, "unknown usb inst:%d\n",
> > instance);
> > goto fail_io;
> > }
> > }
> > @@ -744,7 +744,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> >
> > err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> > if (err) {
> > - dev_err(>dev, "Failed to add USB HCD\n");
> > + dev_err(>dev, "usb_add_hcd failed with err 0x%x\n",
> > err);
> > goto fail;
> > }
> >
> > @@ -753,7 +753,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> >
> > /* Don't skip the pm_runtime_forbid call if wakeup isn't working */
> > /* if (!pdata->power_down_on_bus_suspend) */
> > - pm_runtime_forbid(>dev);
> > + pm_runtime_forbid(>dev);
> > pm_runtime_enable(>dev);
> > pm_runtime_put_sync(>dev);
> > return err;
>
> I'm not sure that last change is worth making; hopefully, you'll fix the
> bug the causes the "if" to be commented out, and we can re-enabled it
> again. Removing the indent makes it much less obvious which lines of
> code the "if" was intended to cover.
--
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] block: Document lack of ordering of submit_bio/generic_make_request
From: Joseph Glanville
It is worth noting here that the block layer makes no attempt
to preserve the order of requests and that upper layers like
journaling filesystems that require such ordering need to do so
explicity.
Signed-off-by: Joseph Glanville
---
block/blk-core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..14b8be6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1749,6 +1749,11 @@ end_io:
* bio happens to be merged with someone else, and may resubmit the bio to
* a lower device by calling into generic_make_request recursively, which
* means the bio should NOT be touched after the call to ->make_request_fn.
+ *
+ * Ordering is not guaranteed, callers of generic_make_request()
+ * that require ordering should ensure dependencies are first drained
+ * before submission of dependent bios.
+ *
*/
void generic_make_request(struct bio *bio)
{
@@ -1808,6 +1813,7 @@ EXPORT_SYMBOL(generic_make_request);
* submit_bio() is very similar in purpose to generic_make_request(), and
* uses that function to do most of the work. Both are fairly rough
* interfaces; @bio must be presetup and ready for I/O.
+ * Note: submit_bio() doesn't ensure ordering, see generic_make_request()
*
*/
void submit_bio(int rw, struct bio *bio)
--
1.7.12
--
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: [REVIEW][PATCH 12/15] userns: Convert drm to use kuid and kgid and struct pid where appropriate
On Thu, Sep 13, 2012 at 12:14 PM, Eric W. Biederman wrote: > Dave Airlie writes: > >>> Blink Blink this had not been converted to use struct pid ages ago? >>> >>> - On drm open capture the openers kuid and struct pid. >>> - On drm close release the kuid and struct pid >>> - When reporting the uid and pid convert the kuid and struct pid >>> into values in the appropriate namespace. >>> >> >> Hi Eric, >> >> I'm fine with this seems okay, do you want me to merge it via >> drm-next? > > My plan is to merge it via my user namespace tree. And since you have > responed positively I will add your acked-by. There are some nice > synergies when I get all of the changes in one tree. > > If for some reason you want to carry this in your drm tree we can work > something out. > > In this case I expect the change isn't big enough to worry about. No all fine by me, for formality sake: Acked-by: Dave Airlie -- 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 5/5] device and dynamic_debug: Use dev_vprintk_emit and dev_printk_emit
Convert direct calls of vprintk_emit and printk_emit to the
dev_ equivalents.
Make create_syslog_header static.
Signed-off-by: Joe Perches
Acked-by: David S. Miller
Tested-by: Jim Cromie
Acked-by: Jason Baron
---
drivers/base/core.c| 14 +-
include/linux/device.h |2 --
lib/dynamic_debug.c| 31 +++
net/core/dev.c | 16 ++--
4 files changed, 22 insertions(+), 41 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index ffccb64..65f82e3 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1861,7 +1861,8 @@ void device_shutdown(void)
*/
#ifdef CONFIG_PRINTK
-int create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
+static int
+create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
{
const char *subsys;
size_t pos = 0;
@@ -1939,17 +1940,12 @@ EXPORT_SYMBOL(dev_printk_emit);
static int __dev_printk(const char *level, const struct device *dev,
struct va_format *vaf)
{
- char hdr[128];
- size_t hdrlen;
-
if (!dev)
return printk("%s(NULL device *): %pV", level, vaf);
- hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
-
- return printk_emit(0, level[1] - '0', hdrlen ? hdr : NULL, hdrlen,
- "%s %s: %pV",
- dev_driver_string(dev), dev_name(dev), vaf);
+ return dev_printk_emit(level[1] - '0', dev,
+ "%s %s: %pV",
+ dev_driver_string(dev), dev_name(dev), vaf);
}
int dev_printk(const char *level, const struct device *dev,
diff --git a/include/linux/device.h b/include/linux/device.h
index 0063d01..2da4589 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -891,8 +891,6 @@ extern const char *dev_driver_string(const struct device
*dev);
#ifdef CONFIG_PRINTK
-extern int create_syslog_header(const struct device *dev,
- char *hdr, size_t hdrlen);
extern int dev_vprintk_emit(int level, const struct device *dev,
const char *fmt, va_list args);
extern __printf(3, 4)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 6b3ebab..e7f7d99 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -591,15 +591,11 @@ int __dynamic_dev_dbg(struct _ddebug *descriptor,
res = printk(KERN_DEBUG "(NULL device *): %pV", );
} else {
char buf[PREFIX_SIZE];
- char dict[128];
- size_t dictlen;
- dictlen = create_syslog_header(dev, dict, sizeof(dict));
-
- res = printk_emit(0, 7, dictlen ? dict : NULL, dictlen,
- "%s%s %s: %pV",
- dynamic_emit_prefix(descriptor, buf),
- dev_driver_string(dev), dev_name(dev), );
+ res = dev_printk_emit(7, dev, "%s%s %s: %pV",
+ dynamic_emit_prefix(descriptor, buf),
+ dev_driver_string(dev), dev_name(dev),
+ );
}
va_end(args);
@@ -627,18 +623,13 @@ int __dynamic_netdev_dbg(struct _ddebug *descriptor,
if (dev && dev->dev.parent) {
char buf[PREFIX_SIZE];
- char dict[128];
- size_t dictlen;
-
- dictlen = create_syslog_header(dev->dev.parent,
- dict, sizeof(dict));
-
- res = printk_emit(0, 7, dictlen ? dict : NULL, dictlen,
- "%s%s %s %s: %pV",
- dynamic_emit_prefix(descriptor, buf),
- dev_driver_string(dev->dev.parent),
- dev_name(dev->dev.parent),
- netdev_name(dev), );
+
+ res = dev_printk_emit(7, dev->dev.parent,
+ "%s%s %s %s: %pV",
+ dynamic_emit_prefix(descriptor, buf),
+ dev_driver_string(dev->dev.parent),
+ dev_name(dev->dev.parent),
+ netdev_name(dev), );
} else if (dev) {
res = printk(KERN_DEBUG "%s: %pV", netdev_name(dev), );
} else {
diff --git a/net/core/dev.c b/net/core/dev.c
index 1ec186a..8ad42fd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6428,16 +6428,12 @@ static int __netdev_printk(const char *level, const
struct net_device *dev,
int r;
if (dev && dev->dev.parent) {
- char dict[128];
- size_t dictlen = create_syslog_header(dev->dev.parent,
- dict, sizeof(dict));
-
- r = printk_emit(0,
[PATCH 4/5] dev: Add dev_vprintk_emit and dev_printk_emit
Add utility functions to consolidate the use of
create_syslog_header and vprintk_emit.
This allows conversion of logging functions that
call create_syslog_header and then call vprintk_emit
or printk_emit to the dev_ equivalents.
Signed-off-by: Joe Perches
Acked-by: David S. Miller
Tested-by: Jim Cromie
Acked-by: Jason Baron
---
drivers/base/core.c| 27 +++
include/linux/device.h | 11 +++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index d46b635..ffccb64 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1909,6 +1909,33 @@ int create_syslog_header(const struct device *dev, char
*hdr, size_t hdrlen)
}
EXPORT_SYMBOL(create_syslog_header);
+int dev_vprintk_emit(int level, const struct device *dev,
+const char *fmt, va_list args)
+{
+ char hdr[128];
+ size_t hdrlen;
+
+ hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
+
+ return vprintk_emit(0, level, hdrlen ? hdr : NULL, hdrlen, fmt, args);
+}
+EXPORT_SYMBOL(dev_vprintk_emit);
+
+int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...)
+{
+ va_list args;
+ int r;
+
+ va_start(args, fmt);
+
+ r = dev_vprintk_emit(level, dev, fmt, args);
+
+ va_end(args);
+
+ return r;
+}
+EXPORT_SYMBOL(dev_printk_emit);
+
static int __dev_printk(const char *level, const struct device *dev,
struct va_format *vaf)
{
diff --git a/include/linux/device.h b/include/linux/device.h
index 4800d73..0063d01 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -893,6 +893,10 @@ extern const char *dev_driver_string(const struct device
*dev);
extern int create_syslog_header(const struct device *dev,
char *hdr, size_t hdrlen);
+extern int dev_vprintk_emit(int level, const struct device *dev,
+ const char *fmt, va_list args);
+extern __printf(3, 4)
+int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...);
extern __printf(3, 4)
int dev_printk(const char *level, const struct device *dev,
@@ -914,6 +918,13 @@ int _dev_info(const struct device *dev, const char *fmt,
...);
#else
+static int dev_vprintk_emit(int level, const struct device *dev,
+ const char *fmt, va_list args)
+{ return 0; }
+static inline __printf(3, 4)
+int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...)
+{ return 0; }
+
static inline int __dev_printk(const char *level, const struct device *dev,
struct va_format *vaf)
{ return 0; }
--
1.7.8.111.gad25c.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] netdev_printk/netif_printk: Remove a superfluous logging colon
netdev_printk originally called dev_printk with %pV. This style emitted the complete dev_printk header with a colon followed by the netdev_name prefix followed by a colon. Now that netdev_printk does not call dev_printk, the extra colon is superfluous. Remove it. Example: old: sky2 :02:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both new: sky2 :02:00.0 eth0: Link is up at 100 Mbps, full duplex, flow control both Signed-off-by: Joe Perches Acked-by: David S. Miller Tested-by: Jim Cromie Acked-by: Jason Baron --- lib/dynamic_debug.c |2 +- net/core/dev.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 2a29f4e..6b3ebab 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -634,7 +634,7 @@ int __dynamic_netdev_dbg(struct _ddebug *descriptor, dict, sizeof(dict)); res = printk_emit(0, 7, dictlen ? dict : NULL, dictlen, - "%s%s %s: %s: %pV", + "%s%s %s %s: %pV", dynamic_emit_prefix(descriptor, buf), dev_driver_string(dev->dev.parent), dev_name(dev->dev.parent), diff --git a/net/core/dev.c b/net/core/dev.c index a588145..1ec186a 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6434,7 +6434,7 @@ static int __netdev_printk(const char *level, const struct net_device *dev, r = printk_emit(0, level[1] - '0', dictlen ? dict : NULL, dictlen, - "%s %s: %s: %pV", + "%s %s %s: %pV", dev_driver_string(dev->dev.parent), dev_name(dev->dev.parent), netdev_name(dev), vaf); -- 1.7.8.111.gad25c.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] netdev_printk/dynamic_netdev_dbg: Directly call printk_emit
A lot of stack is used in recursive printks with %pV.
Using multiple levels of %pV (a logging function with %pV
that calls another logging function with %pV) can consume
more stack than necessary.
Avoid excessive stack use by not calling dev_printk from
netdev_printk and dynamic_netdev_dbg. Duplicate the logic
and form of dev_printk instead.
Make __netdev_printk static.
Remove EXPORT_SYMBOL(__netdev_printk)
Whitespace and brace style neatening.
Signed-off-by: Joe Perches
Acked-by: David S. Miller
Tested-by: Jim Cromie
Acked-by: Jason Baron
---
include/linux/netdevice.h |3 ---
lib/dynamic_debug.c | 26 +++---
net/core/dev.c| 24 +---
3 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 59dc05f3..5f49cc0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2720,9 +2720,6 @@ static inline const char *netdev_name(const struct
net_device *dev)
return dev->name;
}
-extern int __netdev_printk(const char *level, const struct net_device *dev,
- struct va_format *vaf);
-
extern __printf(3, 4)
int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...);
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 29ff2e4..2a29f4e 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -611,20 +611,40 @@ EXPORT_SYMBOL(__dynamic_dev_dbg);
#ifdef CONFIG_NET
int __dynamic_netdev_dbg(struct _ddebug *descriptor,
- const struct net_device *dev, const char *fmt, ...)
+const struct net_device *dev, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
int res;
- char buf[PREFIX_SIZE];
BUG_ON(!descriptor);
BUG_ON(!fmt);
va_start(args, fmt);
+
vaf.fmt = fmt;
vaf.va =
- res = __netdev_printk(dynamic_emit_prefix(descriptor, buf), dev, );
+
+ if (dev && dev->dev.parent) {
+ char buf[PREFIX_SIZE];
+ char dict[128];
+ size_t dictlen;
+
+ dictlen = create_syslog_header(dev->dev.parent,
+ dict, sizeof(dict));
+
+ res = printk_emit(0, 7, dictlen ? dict : NULL, dictlen,
+ "%s%s %s: %s: %pV",
+ dynamic_emit_prefix(descriptor, buf),
+ dev_driver_string(dev->dev.parent),
+ dev_name(dev->dev.parent),
+ netdev_name(dev), );
+ } else if (dev) {
+ res = printk(KERN_DEBUG "%s: %pV", netdev_name(dev), );
+ } else {
+ res = printk(KERN_DEBUG "(NULL net_device): %pV", );
+ }
+
va_end(args);
return res;
diff --git a/net/core/dev.c b/net/core/dev.c
index 8398836..a588145 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6422,22 +6422,30 @@ const char *netdev_drivername(const struct net_device
*dev)
return empty;
}
-int __netdev_printk(const char *level, const struct net_device *dev,
+static int __netdev_printk(const char *level, const struct net_device *dev,
struct va_format *vaf)
{
int r;
- if (dev && dev->dev.parent)
- r = dev_printk(level, dev->dev.parent, "%s: %pV",
- netdev_name(dev), vaf);
- else if (dev)
+ if (dev && dev->dev.parent) {
+ char dict[128];
+ size_t dictlen = create_syslog_header(dev->dev.parent,
+ dict, sizeof(dict));
+
+ r = printk_emit(0, level[1] - '0',
+ dictlen ? dict : NULL, dictlen,
+ "%s %s: %s: %pV",
+ dev_driver_string(dev->dev.parent),
+ dev_name(dev->dev.parent),
+ netdev_name(dev), vaf);
+ } else if (dev) {
r = printk("%s%s: %pV", level, netdev_name(dev), vaf);
- else
+ } else {
r = printk("%s(NULL net_device): %pV", level, vaf);
+ }
return r;
}
-EXPORT_SYMBOL(__netdev_printk);
int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
@@ -6452,6 +6460,7 @@ int netdev_printk(const char *level, const struct
net_device *dev,
vaf.va =
r = __netdev_printk(level, dev, );
+
va_end(args);
return r;
@@ -6471,6 +6480,7 @@ int func(const struct net_device *dev, const char *fmt,
...) \
vaf.va = \
\
r = __netdev_printk(level, dev, ); \
+
[PATCH] fs: Preserve error code in get_empty_filp()
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
- not enough memory for file structures
- operation is not allowed
- user is over its limit
Currently the function returns NULL in all cases and we loose the exact
reason of the error. All callers of get_empty_filp() assume that the function
can fail with ENFILE only.
Return error through pointer. Change all callers to preserve this error code.
Signed-off-by: Anatol Pomozov
Reviewed-by: "Theodore Ts'o"
---
arch/ia64/kernel/perfmon.c | 4 ++--
fs/anon_inodes.c | 5 +++--
fs/file_table.c| 22 ++
fs/hugetlbfs/inode.c | 5 +++--
fs/namei.c | 4 ++--
fs/open.c | 5 ++---
fs/pipe.c | 9 ++---
ipc/shm.c | 4 +++-
mm/shmem.c | 5 +++--
net/socket.c | 4 ++--
10 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 3fa4bc5..da2dcce 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2221,9 +2221,9 @@ pfm_alloc_file(pfm_context_t *ctx)
d_add(path.dentry, inode);
file = alloc_file(, FMODE_READ, _file_ops);
- if (!file) {
+ if (IS_ERR(file)) {
path_put();
- return ERR_PTR(-ENFILE);
+ return file;
}
file->f_flags = O_RDONLY;
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 28d39fb..73536e3 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -160,10 +160,11 @@ struct file *anon_inode_getfile(const char *name,
d_instantiate(path.dentry, anon_inode_inode);
- error = -ENFILE;
file = alloc_file(, OPEN_FMODE(flags), fops);
- if (!file)
+ if (IS_ERR(file)) {
+ error = PTR_ERR(file);
goto err_dput;
+ }
file->f_mapping = anon_inode_inode->i_mapping;
file->f_pos = 0;
diff --git a/fs/file_table.c b/fs/file_table.c
index 701985e..3b3f4d7 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -94,8 +94,8 @@ int proc_nr_files(ctl_table *table, int write,
#endif
/* Find an unused file structure and return a pointer to it.
- * Returns NULL, if there are no more free file structures or
- * we run out of memory.
+ * Returns an error pointer if some error happend e.g. we over file
+ * structures limit, run out of memory or operation is not permitted.
*
* Be very careful using this. You are responsible for
* getting write access to any mount that you might assign
@@ -108,6 +108,7 @@ struct file *get_empty_filp(void)
const struct cred *cred = current_cred();
static long old_max;
struct file * f;
+ int error;
/*
* Privileged users can go above max_files
@@ -117,17 +118,22 @@ struct file *get_empty_filp(void)
* percpu_counters are inaccurate. Do an expensive check before
* we go and fail.
*/
- if (percpu_counter_sum_positive(_files) >=
files_stat.max_files)
+ if (percpu_counter_sum_positive(_files) >=
files_stat.max_files) {
+ error = -ENFILE;
goto over;
+ }
}
f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
- if (f == NULL)
+ if (f == NULL) {
+ error = -ENOMEM;
goto fail;
+ }
percpu_counter_inc(_files);
f->f_cred = get_cred(cred);
- if (security_file_alloc(f))
+ error = security_file_alloc(f);
+ if (error)
goto fail_sec;
INIT_LIST_HEAD(>f_u.fu_list);
@@ -149,7 +155,7 @@ over:
fail_sec:
file_free(f);
fail:
- return NULL;
+ return ERR_PTR(error);
}
/**
@@ -173,8 +179,8 @@ struct file *alloc_file(struct path *path, fmode_t mode,
struct file *file;
file = get_empty_filp();
- if (!file)
- return NULL;
+ if (IS_ERR(file))
+ return file;
file->f_path = *path;
file->f_mapping = path->dentry->d_inode->i_mapping;
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8349a89..5ec849b 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -984,11 +984,12 @@ struct file *hugetlb_file_setup(const char *name,
unsigned long addr,
inode->i_size = size;
clear_nlink(inode);
- error = -ENFILE;
file = alloc_file(, FMODE_WRITE | FMODE_READ,
_file_operations);
- if (!file)
+ if (IS_ERR(file)) {
+ error = PTR_ERR(file);
goto out_dentry; /* inode is already attached */
+ }
return file;
diff --git a/fs/namei.c b/fs/namei.c
index dd1ed1b..0160da0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2885,8 +2885,8 @@ static struct file *path_openat(int dfd, const char
[PATCH 1/5] dev_dbg/dynamic_debug: Update to use printk_emit, optimize stack
commit c4e00daaa9
("driver-core: extend dev_printk() to pass structured data")
changed __dev_printk and broke dynamic-debug's ability to control the
dynamic prefix of dev_dbg(dev,..).
commit af7f2158fd
("drivers-core: make structured logging play nice with dynamic-debug")
made a minimal correction.
The current dynamic debug code uses up to 3 recursion levels via %pV.
This can consume quite a bit of stack. Directly call printk_emit to
reduce the recursion depth.
These changes include:
dev_dbg:
o Create and use function create_syslog_header to format the syslog
header for printk_emit uses.
o Call create_syslog_header and neaten __dev_printk
o Make __dev_printk static not global
o Remove include header declaration of __dev_printk
o Remove now unused EXPORT_SYMBOL() of __dev_printk
o Whitespace neatening
dynamic_dev_dbg:
o Remove KERN_DEBUG from dynamic_emit_prefix
o Call create_syslog_header and printk_emit
o Whitespace neatening
Signed-off-by: Joe Perches
Acked-by: David S. Miller
Tested-by: Jim Cromie
Acked-by: Jason Baron
---
drivers/base/core.c| 64 +--
include/linux/device.h |8 +++---
lib/dynamic_debug.c| 39 +---
3 files changed, 67 insertions(+), 44 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5e6e00b..d46b635 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1861,26 +1861,19 @@ void device_shutdown(void)
*/
#ifdef CONFIG_PRINTK
-int __dev_printk(const char *level, const struct device *dev,
-struct va_format *vaf)
+int create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
{
- char dict[128];
- const char *level_extra = "";
- size_t dictlen = 0;
const char *subsys;
-
- if (!dev)
- return printk("%s(NULL device *): %pV", level, vaf);
+ size_t pos = 0;
if (dev->class)
subsys = dev->class->name;
else if (dev->bus)
subsys = dev->bus->name;
else
- goto skip;
+ return 0;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "SUBSYSTEM=%s", subsys);
+ pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys);
/*
* Add device identifier DEVICE=:
@@ -1896,32 +1889,41 @@ int __dev_printk(const char *level, const struct device
*dev,
c = 'b';
else
c = 'c';
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=%c%u:%u",
- c, MAJOR(dev->devt), MINOR(dev->devt));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=%c%u:%u",
+ c, MAJOR(dev->devt), MINOR(dev->devt));
} else if (strcmp(subsys, "net") == 0) {
struct net_device *net = to_net_dev(dev);
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=n%u", net->ifindex);
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=n%u", net->ifindex);
} else {
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=+%s:%s", subsys, dev_name(dev));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=+%s:%s", subsys, dev_name(dev));
}
-skip:
- if (level[2])
- level_extra = [2]; /* skip past KERN_SOH "L" */
- return printk_emit(0, level[1] - '0',
- dictlen ? dict : NULL, dictlen,
- "%s %s: %s%pV",
- dev_driver_string(dev), dev_name(dev),
- level_extra, vaf);
+ return pos;
+}
+EXPORT_SYMBOL(create_syslog_header);
+
+static int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+{
+ char hdr[128];
+ size_t hdrlen;
+
+ if (!dev)
+ return printk("%s(NULL device *): %pV", level, vaf);
+
+ hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
+
+ return printk_emit(0, level[1] - '0', hdrlen ? hdr : NULL, hdrlen,
+ "%s %s: %pV",
+ dev_driver_string(dev), dev_name(dev), vaf);
}
-EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
@@ -1936,6 +1938,7 @@ int dev_printk(const char *level, const struct device
*dev,
vaf.va =
r = __dev_printk(level, dev, );
+
va_end(args);
Re: linux-next: Tree for Sept 11 (drm related: boot problems on amd64)
On Wed, Sep 12, 2012 at 9:52 PM, Bjorn Helgaas wrote:
> On Tue, Sep 11, 2012 at 4:04 PM, Sedat Dilek wrote:
>> On Tue, Sep 11, 2012 at 8:29 PM, Sedat Dilek wrote:
>>> On Tue, Sep 11, 2012 at 8:12 PM, Sedat Dilek wrote:
>>>> On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> Changes since 201209010:
>>>>>
>>>>> New tree: ixp4xx
>>>>>
>>>>> The pci tree gained a build failure so I used the version from
>>>>> next-20120910.
>>>>>
>>>>> The regulator tree lost its build failure.
>>>>>
>>>>> The staging tree lost its build failure.
>>>>>
>>>>> The akpm tree lost a few patches that turned up elsewhere.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> today's and yesterday's Linux-Next is broken for me again.
>>>> I tried with systemd and upstart on Ubuntu/precise, with nomodeset and
>>>> rescue boot-option.
>>>>
>>>> With rescue boot-option I see this in my logs (Intel sandy-bridge
>>>> ultrabook here):
>>>>
>>>> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
>>>> *ERROR* Cannot initialize the agpgart module.
>>>> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
>>>>
>>>> I have not checked any MLs... coming from hospital right now.
>>>>
>>>
>>> More ERRORs:
>>>
>>> # grep -A1 "ERROR" /var/log/kern.log
>>> Sep 10 17:51:29 fambox kernel: [ 10.205818]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 10 17:51:29 fambox kernel: [ 10.206055] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 10 15:53:00 fambox kernel: [ 10.500387]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 10 15:53:00 fambox kernel: [ 10.500602] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 20:41:01 fambox kernel: [9.636010]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 20:41:01 fambox kernel: [9.636202] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 18:42:18 fambox kernel: [ 10.132229]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 18:42:18 fambox kernel: [ 10.132433] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 18:43:36 fambox kernel: [9.654972] [drm:drm_pci_agp_init]
>>> *ERROR* Cannot initialize the agpgart module.
>>> Sep 11 18:43:36 fambox kernel: [9.654980] DRM: Fill_in_dev failed.
>>> --
>>> Sep 11 19:52:10 fambox kernel: [9.545562]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 19:52:10 fambox kernel: [9.545798] i915: probe of
>>> :00:02.0 failed with error -5
>>> --
>>> Sep 11 20:04:09 fambox kernel: [9.798233]
>>> [drm:i915_get_bridge_dev] *ERROR* bridge device not found
>>> Sep 11 20:04:09 fambox kernel: [9.798557] i915: probe of
>>> :00:02.0 failed with error -5
>>>
>>
>> [ CC Bjorn (pci maintainer) ]
>>
>> I pulled in pci.git#next up to commit
>> 9c2178e6ba49fe48c468edc08ad94b53e1b1 ("Merge branch
>> 'pci/gavin-window-alignment' into next") on top of next-20120911.
>> This lets my machine boot, but freezes somewhere else.
>
> We had a PCI bug in an earlier version of this patch:
> http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=b9443f401bb20ae6414e3e68bca0413bad28b689
> that caused lspci to fail.
>
I retested with next-20120912 and my machine boots, so no more
drm-related errors causing boot-failures.
> I suspect this also caused the issue you saw. We've since fixed it,
> but let me know if you see a PCI-related issue again.
>
Immediately after pressing any single key at X-login (Ubuntu/precise
IIRC uses lightdm + unity-greeter), my machine produces a
kernel-panic.
I have taken a photo and will send a separate email on this.
Can't say ATM what is the root-cause for it.
But that is what I have seen after my merging of the "clean"
pci.git/next into yesterday's "nine-eleven" release.
Further questions (not issue related):
While doing a simple grepping for new "pcie-cap" patterns (a list at
[1]) came with commit 8c0d3a02c1309eb6112d2e7c8172e8ceb26ecfca ("PCI:
Add accessors for PCI Express Capability") on drivers/gpu/
directory...more simplifications possible (I had only a quick view)?
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=8c0d3a02c1309eb6112d2e7c8172e8ceb26ecfca#patch2
> 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 0/5] dev_ and dynamic_debug cleanups
On Wed, Sep 12, 2012 at 10:39:48PM -0400, Jason Baron wrote: > On Wed, Sep 12, 2012 at 06:13:30PM -0700, Joe Perches wrote: > > On Thu, 2012-09-06 at 13:53 -0400, Jason Baron wrote: > > > On Thu, Sep 06, 2012 at 09:13:59AM -0700, Greg Kroah-Hartman wrote: > > > > Jason, any ACK on these, or any of the other random dynamic debug > > > > patches floating around? What am I supposed to be applying here? > > [] > > > I just posted some follow up comments to Joe, so let's see where that > > > discussion goes. > > > > Jason, I think you need to ack these original 5 patches. > > > > Hi, > > Yes, they are certainly an improvement. Please add to the series: > > Acked-by: Jason Baron Um, can someone please resend these with the ack so I can pick them up? They are long gone from my mboxes... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Various things Linux doesn't have/doesn't need
On Thu, Sep 13, 2012 at 10:30:06AM +1000, Cruz Julian Bishop wrote: > Do you guys get paid (or are part of a bet) when you make > suggestions like these, or do you just do it for, as a friend > tells me, "shits and giggles"? I'm going to guess that people have been leaving their systems unattended without a screen saver, and someone is trying to make them look like total whackos by posting a these e-mails from their unlocked/unattended accounts. :-) - Ted -- 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: [tip:perf/core] perf hists: Introduce perf_hpp for hist period printing
Hi Arnaldo and Robert, On Wed, 12 Sep 2012 15:48:15 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 12, 2012 at 07:26:41PM +0200, Robert Richter escreveu: >> On 09.09.12 01:54:39, tip-bot for Namhyung Kim wrote: >> >> # perf record -e cycles -aq sleep 1 ; perf report -n --sort comm,dso | sed >> '/%/q;d' ; \ >>perf record -e cycles -aq sleep 1 | perf report -n --sort comm,dso | sed >> '/%/q;d' >> 99.86%11804 swapper [kernel.kallsyms] >> 91.57% swapper [kernel.kallsyms] >>^^ >>number of samples missing >> >> Moving and changing the code at the same time make the patch >> unreviewable. So no clue that's the problem here. > > Yeah, that was unfortunate (movind and changing), we need to try hard > not to do that... Okay, will be careful next time. > > Anyway, Namhyung, can you take a look at this? Sure, I'll take a look. Thanks, Namhyung -- 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/3] perf: require exclude_guest to use PEBS - kernel side enforcement
Hi David,
On Wed, 12 Sep 2012 09:16:29 -0600, David Ahern wrote:
> From: Peter Zijlstra
>
> Per Peter:
> "Intel PEBS in VT-x context uses the DS address as a guest linear address,
> even though its programmed by the host as a host linear address. This
> either results in guest memory corruption and or the hardware faulting and
> 'crashing' the virtual machine. Therefore we have to disable PEBS on VT-x
> enter and re-enable on VT-x exit, enforcing a strict exclude_guest.
>
> This patch enforces exclude_guest kernel side.
>
[snip]
> @@ -380,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
> if (event->attr.precise_ip) {
> int precise = 0;
>
> + if (!event->attr.exclude_guest)
> + return -EOPNOTSUPP;
I see a whitespace problem here. :)
Thanks,
Namhyung
> +
> /* Support for constant skid */
> if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
> precise++;
--
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/5] dev_ and dynamic_debug cleanups
On Wed, Sep 12, 2012 at 06:13:30PM -0700, Joe Perches wrote: > On Thu, 2012-09-06 at 13:53 -0400, Jason Baron wrote: > > On Thu, Sep 06, 2012 at 09:13:59AM -0700, Greg Kroah-Hartman wrote: > > > Jason, any ACK on these, or any of the other random dynamic debug > > > patches floating around? What am I supposed to be applying here? > [] > > I just posted some follow up comments to Joe, so let's see where that > > discussion goes. > > Jason, I think you need to ack these original 5 patches. > Hi, Yes, they are certainly an improvement. Please add to the series: Acked-by: Jason Baron Thanks! -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: [ 042/108] NFS: Alias the nfs module to nfs4
On Wed, Sep 12, 2012 at 9:24 PM, Myklebust, Trond wrote: > On Wed, 2012-09-12 at 21:08 -0400, Josh Boyer wrote: >> On Wed, Sep 12, 2012 at 7:28 PM, Greg Kroah-Hartman >> wrote: >> > From: Greg KH >> > >> > 3.5-stable review patch. If anyone has any objections, please let me know. >> > >> > -- >> > >> > commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream. >> > >> > This allows distros to remove the line from their modprobe >> > configuration. >> > >> > Signed-off-by: Bryan Schumaker >> > Signed-off-by: Trond Myklebust >> > [bwh: Backported to 3.2: adjust context] >> > Signed-off-by: Ben Hutchings >> > Signed-off-by: Greg Kroah-Hartman >> >> Could someone elaborate why this is acceptable now, while it wasn't >> during the timeframe I sent an identical patch months ago? >> >> http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/02064.html >> >> We had some trouble in Fedora 17 because of this and would up with >> patches to nfs-utils because the modalias was NAKed. If we're bringing >> it into stable (and upstream) at this point, it would be good to know >> what changed so I can go and undo what we did because I was told no. >> >> Please don't get me wrong, I'm all for simplicity. I'm just perhaps >> so simple that the brief changelog confuses me because it doesn't >> actually describe why the original solution wasn't followed up on. > > Linux-3.6 converts NFSv2/v3/v4 into modules, and so modprobe.conf > entries of the form > > alias nfs4 nfs > > will now fail to ensure that 'mount -t nfs4 ...' works. In order to Ah, ok. That makes sense. > facilitate the task for the distros when dealing with kernels >= 3.5.x, > we've added the automatic module alias so that they can remove the > hard-coded aliases in modprobe.conf while remaining backward-compatible. This is queued for 3.5.x, 3.4.x, 3.2.x, and 3.0.x. That's probably OK, but it's a slightly broader scope that what you mentioned above. At any rate, I'm glad to see this go in. It will make things easier going forward. Thanks for the reply. josh -- 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 06/25] docs: Xen ARM DT bindings
On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
>> On Tue, 28 Aug 2012, Rob Herring wrote:
>>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
>>> While it is a PPC doc, we should reuse or extend what makes sense.
>>>
>>> See section 7.5:
>>>
>>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
>>
>> Thanks for the link, I wasn't aware of ePAPR.
>>
>> The hypervisor node defined by ePAPR is not very different from what I
>> am proposing. Should I try to be compatible with the hypervisor
>> specification above (as in compatible = "epapr,hypervisor-1.1")?
>> Or should I just use it as a reference for my own specification?
>>
>> Personally I would rather avoid full compatibility with ePAPR.
>
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
>
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).
compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.
Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.
We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.
> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.
It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.
> - guest-id
> we usually make a point in trying not to tell the guest its own domid
> because if the VM gets migrated to a different host it acquires a new
> domid, therefore it should not rely on it.
>
> - guest-name
> we could pass the guest name here, but I don't see how it could be
> of any use.
>
I have no issue with these being optional.
>
> On the other hand, thinking more about what Xen needs in the device
> tree, I think we could improve the current spec by clarifying the
> meaning of the memory region and interrupt properties we currently
> require. I thought about moving them to two separate children node with
> an explicit name:
>
> ---
>
> * Xen hypervisor device tree bindings
>
I really think we need to define ARM hypervisor device tree bindings
first, then Xen specific bindings as an addition to that. I worry that
the KVM folks aren't paying attention and then want something different
later on.
> Xen ARM virtual platforms shall have the following properties and
> children nodes:
>
> - compatible property:
> compatible = "xen,xen", "xen,xen-";
"xen,xen" should be last as it is less specific.
> where is the version of the Xen ABI of the platform.
>
> - grant_table child with the following properties:
> - name:
> name = "grant_table";
What's a grant table?
> - reg: specifies the base physical address and size of a region in
> memory where the grant table should be mapped to, using an
> HYPERVISOR_memory_op hypercall.
>
> - events child with the following properties:
> - name:
> name = "events";
> - interrupts: the interrupt used by Xen to inject event notifications.
Why a child node? Just an interrupts property alone should be fine. If
you have cases with different number of interrupts, the compatible
property can distinguish that.
Rob
>
>
> Example:
> hypervisor {
> compatible = "xen,xen", "xen,xen-4.2";
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <3>;
> ranges = <0xb000 0xb000 0x2>;
>
> grant_table {
> name = "grant_table";
> reg = <0xb000 0x2>;
> };
>
> events {
> name = "events";
> interrupts = <1 15 0xf08>;
> };
> };
>
--
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: Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in fix_read_error function
On 09/04/2012 11:07 AM, hank wrote:
> From 0ba5879082544dc3aa13807087563b1258124b1e Mon Sep 17 00:00:00 2001
> From: hank
> Date: Tue, 4 Sep 2012 10:23:45 +0800
> Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in
> fix_read_error function
>
> in fix_read_error function, the conf->mirrors[read_disk].rdev may
> become NULL, as in this function, rdev->nr_pending may be zero, anyone
> can delete it. So should check if it is NULL before use.
>
> Signed-off-by: hank
> ---
> drivers/md/raid1.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 611b5f7..fd8de28 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -2005,7 +2005,7 @@ static void fix_read_error(struct r1conf *conf, int
> read_disk,
> if (!success) {
> /* Cannot read from anywhere - mark it bad */
> struct md_rdev *rdev = conf->mirrors[read_disk].rdev;
> - if (!rdev_set_badblocks(rdev, sect, s, 0))
> + if (!rdev || !rdev_set_badblocks(rdev, sect, s, 0))
> md_error(mddev, rdev);
> break;
> }
Anyone can review this patch? I think it is a bug and should be fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: suspend: use flush range instead of flush all
2012/9/12 Russell King - ARM Linux :
> On Wed, Sep 12, 2012 at 02:40:45PM +0530, Shilimkar, Santosh wrote:
>> On Wed, Sep 12, 2012 at 2:24 PM, Russell King - ARM Linux
>> wrote:
>> > On Wed, Sep 12, 2012 at 01:13:33PM +0530, Shilimkar, Santosh wrote:
>> >> On Wed, Sep 12, 2012 at 12:48 PM, wzch wrote:
>> >> > void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
>> >> > {
>> >> > + u32 *ptr_orig = ptr;
>> >> > *save_ptr = virt_to_phys(ptr);
>> >> >
>> >> > /* This must correspond to the LDM in cpu_resume() assembly */
>> >> > @@ -26,7 +27,8 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp,
>> >> > u32 *save_ptr)
>> >> >
>> >> > cpu_do_suspend(ptr);
>> >> >
>> >> > - flush_cache_all();
>> >> Lorenzo's patch was limiting above flush to local cache (LOUs) instead
>> >> of dropping it completely.
>> >
>> > Err, that is wrong. Normally, when CPUs go into suspend, the L1 cache is
>> > lost entirely. This is the only flush which many CPUs see of the L1
>> > cache.
>> >
>> > So removing this flush _will_ break suspend to RAM on existing CPUs.
>>
>> As mentioned, keeping that flush till inner shareability domain(L1) should be
>> enough. In fact if that part gets pushed down to the finisher() which any
>> way needs to take care of the cache maintenance, we can get rid of
>> completely.
>
> It is difficult to call the cache maintenance functions from assembly.
> Why not have the generic code do the inner shareability flush, and then
> leave the responsibility for any further cache maintenance caused by the
> actions of the finisher to the finisher to deal with - as it is now.
>
> That way we end up with more generic code, and don't go back to the
> rediculous situation where we had everyone implementing this crap in
> their own broken way time and time again in their platform code.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Russell/All,
I have several questions:
1. Even we call flush_calche_all in __cpu_suspend_save, since later we
will outer_clean_range which may cause cache operations so we still
need to flush again in finisher, right?
2. Not every platform the L1 will be lost, we have the option to keep
L1 retentive, right? Just consider single core CA9. So we may not need
to flush all every time.
3. Why it's difficult to call cache maintenance in assembly? Moreover,
not every finisher is assembly, right?
--
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] memory-hotplug: don't replace lowmem pages with highmem
On Wed, 12 Sep 2012, Minchan Kim wrote: > [1] reporeted that lowmem pages could be replaced by > highmem pages during migration of CMA and fixed. > > Quote from [1]'s description > " > The filesystem layer expects pages in the block device's mapping to not > be in highmem (the mapping's gfp mask is set in bdget()), but CMA can > currently replace lowmem pages with highmem pages, leading to crashes in > filesystem code such as the one below: > > Unable to handle kernel NULL pointer dereference at virtual address > 0400 > pgd = c0c98000 > [0400] *pgd=00c91831, *pte=, *ppte= > Internal error: Oops: 817 [#1] PREEMPT SMP ARM > CPU: 0Not tainted (3.5.0-rc5+ #80) > PC is at __memzero+0x24/0x80 > ... > Process fsstress (pid: 323, stack limit = 0xc0cbc2f0) > Backtrace: > [] (ext4_getblk+0x0/0x180) from [] > (ext4_bread+0x1c/0x98) > [] (ext4_bread+0x0/0x98) from [] > (ext4_mkdir+0x160/0x3bc) >r4:c15337f0 > [] (ext4_mkdir+0x0/0x3bc) from [] > (vfs_mkdir+0x8c/0x98) > [] (vfs_mkdir+0x0/0x98) from [] > (sys_mkdirat+0x74/0xac) >r6: r5:c152eb40 r4:01ff r3:c14b43f0 > [] (sys_mkdirat+0x0/0xac) from [] > (sys_mkdir+0x20/0x24) >r6:beccdcf0 r5:00074000 r4:beccdbbc > [] (sys_mkdir+0x0/0x24) from [] > (ret_fast_syscall+0x0/0x30) > " > > Memory-hotplug has same problem with CMA so [1]'s fix could be applied > with memory-hotplug, too. > > Fix it by reusing. > > [1] 6a6dccba2, mm: cma: don't replace lowmem pages with highmem > > Cc: Kamezawa Hiroyuki > Cc: Yasuaki Ishimatsu > Cc: Michal Nazarewicz > Cc: Marek Szyprowski > Cc: Wen Congyang > Signed-off-by: Minchan Kim Acked-by: David Rientjes -- 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: [REVIEW][PATCH 12/15] userns: Convert drm to use kuid and kgid and struct pid where appropriate
Dave Airlie writes: >> Blink Blink this had not been converted to use struct pid ages ago? >> >> - On drm open capture the openers kuid and struct pid. >> - On drm close release the kuid and struct pid >> - When reporting the uid and pid convert the kuid and struct pid >> into values in the appropriate namespace. >> > > Hi Eric, > > I'm fine with this seems okay, do you want me to merge it via > drm-next? My plan is to merge it via my user namespace tree. And since you have responed positively I will add your acked-by. There are some nice synergies when I get all of the changes in one tree. If for some reason you want to carry this in your drm tree we can work something out. In this case I expect the change isn't big enough to worry about. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm: refactor out __alloc_contig_migrate_alloc
On Wed, 12 Sep 2012, Minchan Kim wrote: > __alloc_contig_migrate_alloc can be used by memory-hotplug so > refactor out(move + rename as a common name) it into > page_isolation.c. > > Cc: Kamezawa Hiroyuki > Cc: Yasuaki Ishimatsu > Cc: Michal Nazarewicz > Cc: Marek Szyprowski > Cc: Wen Congyang > Signed-off-by: Minchan Kim Acked-by: David Rientjes -- 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] drivers/net: Enable IOMMU pass through for be2net
This patch sets the coherent DMA mask to 64-bit after the be2net driver
has been acknowledged that the system is 64-bit DMA capable. The coherent
DMA mask is examined by the Intel IOMMU driver to determine whether to
allow pass through context mapping for all devices. With this patch, the
be2net driver combined with be2net compatible hardware provides
comparable performance to the case where vt-d is disabled. The main use
case for this change is to decrease the time necessary to copy virtual
machine memory during KVM live migration instantiations.
This patch was tested on a system that enables the IOMMU in non-coherent
mode. Two DMA remapper issues were encountered and both are in the Intel
IOMMU driver with the following patches submitted upstream but not yet
commited.
Patch 1 - DMAR:[fault reason 02] Present bit in context entry is clear
https://lkml.org/lkml/2012/6/15/20
Patch 2 - DMAR:[fault reason 02] Present bit in context entry is clear
https://lkml.org/lkml/2011/11/11/279
Signed-off-by: Craig Hada
---
drivers/net/ethernet/emulex/benet/be_main.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 78b8aa8..57bbea4 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3835,6 +3835,12 @@ static int __devinit be_probe(struct pci_dev *pdev,
status = dma_set_mask(>dev, DMA_BIT_MASK(64));
if (!status) {
+ status = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
+ if (status < 0) {
+ dev_err(>dev,
+ "dma_set_coherent_mask failed, aborting\n");
+ goto free_netdev;
+ }
netdev->features |= NETIF_F_HIGHDMA;
} else {
status = dma_set_mask(>dev, DMA_BIT_MASK(32));
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] drivers/net: Enable IOMMU pass through for be2net
This patch sets the coherent DMA mask to 64-bit after the be2net driver has been acknowledged that the system is 64-bit DMA capable. The coherent DMA mask is examined by the Intel IOMMU driver to determine whether to allow pass through context mapping for all devices. With this patch, the be2net driver combined with be2net compatible hardware provides comparable performance to the case where vt-d is disabled. The main use case for this change is to decrease the time necessary to copy virtual machine memory during KVM live migration instantiations. This patch was tested on a system that enables the IOMMU in non-coherent mode. Two DMA remapper issues were encountered and both are in the Intel IOMMU driver with the following patches submitted upstream but not yet commited. Patch 1 - DMAR:[fault reason 02] Present bit in context entry is clear https://lkml.org/lkml/2012/6/15/20 Patch 2 - DMAR:[fault reason 02] Present bit in context entry is clear https://lkml.org/lkml/2011/11/11/279 The performance of this patch was measured with netperf with vt-d enabled and disabled along with kernel boot parameters intel_iommu and iommu. Netperf was run 3 times and averaged for each configuration of vt-d and boot parameters. The command and parameters used in the netperf runs along with results are as follows: # netperf -c -p 12865 -H 10.10.0.2 -t TCP_STREAM -l 60 Recv SendSend Utilization Service Demand Socket Socket Message Elapsed Send Recv SendRecv Size SizeSize Time Throughput localremote local remote bytes bytes bytessecs.10^6bits/s % S % U us/KB us/KB vt-d enabled and intel-iommu=on 87380 16384 1638460.0 3634.29 16.76-1.002.267 -1.000 vt-d enabled 87380 16384 1638460.00 6779.01 6.77 -1.000.489 -1.000 vt-d disabled 87380 16384 1638460.00 6807.70 7.00 -1.000.505 -1.000 vt-d enabled and intel_iommu=on and iommu=pt 87380 16384 1638460.00 6849.93 7.19 -1.000.516 -1.000 Craig Hada (1): drivers/net: Enable IOMMU pass through for be2net drivers/net/ethernet/emulex/benet/be_main.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm: refactor out __alloc_contig_migrate_alloc
2012/09/12 10:43, Minchan Kim wrote:
> __alloc_contig_migrate_alloc can be used by memory-hotplug so
> refactor out(move + rename as a common name) it into
> page_isolation.c.
>
> Cc: Kamezawa Hiroyuki
> Cc: Yasuaki Ishimatsu
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> Cc: Michal Nazarewicz
> Cc: Marek Szyprowski
> Cc: Wen Congyang
> Signed-off-by: Minchan Kim
> ---
>
> This patch is intended for preparing next bug fix patch.
>
> include/linux/page-isolation.h |3 ++-
> mm/page_alloc.c| 14 +-
> mm/page_isolation.c| 11 +++
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> index 105077a..1c82261 100644
> --- a/include/linux/page-isolation.h
> +++ b/include/linux/page-isolation.h
> @@ -37,6 +37,7 @@ int test_pages_isolated(unsigned long start_pfn, unsigned
> long end_pfn);
>*/
> int set_migratetype_isolate(struct page *page);
> void unset_migratetype_isolate(struct page *page, unsigned migratetype);
> -
> +struct page *alloc_migrate_target(struct page *page, unsigned long private,
> + int **resultp);
>
> #endif
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a4ff74e..6716023 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5648,18 +5648,6 @@ static unsigned long pfn_max_align_up(unsigned long
> pfn)
> pageblock_nr_pages));
> }
>
> -static struct page *
> -__alloc_contig_migrate_alloc(struct page *page, unsigned long private,
> - int **resultp)
> -{
> - gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
> -
> - if (PageHighMem(page))
> - gfp_mask |= __GFP_HIGHMEM;
> -
> - return alloc_page(gfp_mask);
> -}
> -
> /* [start, end) must belong to a single zone. */
> static int __alloc_contig_migrate_range(unsigned long start, unsigned long
> end)
> {
> @@ -5700,7 +5688,7 @@ static int __alloc_contig_migrate_range(unsigned long
> start, unsigned long end)
> }
>
> ret = migrate_pages(,
> - __alloc_contig_migrate_alloc,
> + alloc_migrate_target,
> 0, false, MIGRATE_SYNC);
> }
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 247d1f1..6936545 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -233,3 +233,14 @@ int test_pages_isolated(unsigned long start_pfn,
> unsigned long end_pfn)
> spin_unlock_irqrestore(>lock, flags);
> return ret ? 0 : -EBUSY;
> }
> +
> +struct page *alloc_migrate_target(struct page *page, unsigned long private,
> + int **resultp)
> +{
> +gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
> +
> +if (PageHighMem(page))
> +gfp_mask |= __GFP_HIGHMEM;
> +
> +return alloc_page(gfp_mask);
> +}
>
--
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] memory-hotplug: don't replace lowmem pages with highmem
2012/09/12 10:43, Minchan Kim wrote:
> [1] reporeted that lowmem pages could be replaced by
> highmem pages during migration of CMA and fixed.
>
> Quote from [1]'s description
> "
> The filesystem layer expects pages in the block device's mapping to not
> be in highmem (the mapping's gfp mask is set in bdget()), but CMA can
> currently replace lowmem pages with highmem pages, leading to crashes in
> filesystem code such as the one below:
>
>Unable to handle kernel NULL pointer dereference at virtual address
> 0400
>pgd = c0c98000
>[0400] *pgd=00c91831, *pte=, *ppte=
>Internal error: Oops: 817 [#1] PREEMPT SMP ARM
>CPU: 0Not tainted (3.5.0-rc5+ #80)
>PC is at __memzero+0x24/0x80
>...
>Process fsstress (pid: 323, stack limit = 0xc0cbc2f0)
>Backtrace:
>[] (ext4_getblk+0x0/0x180) from []
> (ext4_bread+0x1c/0x98)
>[] (ext4_bread+0x0/0x98) from []
> (ext4_mkdir+0x160/0x3bc)
> r4:c15337f0
>[] (ext4_mkdir+0x0/0x3bc) from []
> (vfs_mkdir+0x8c/0x98)
>[] (vfs_mkdir+0x0/0x98) from []
> (sys_mkdirat+0x74/0xac)
> r6: r5:c152eb40 r4:01ff r3:c14b43f0
>[] (sys_mkdirat+0x0/0xac) from []
> (sys_mkdir+0x20/0x24)
> r6:beccdcf0 r5:00074000 r4:beccdbbc
>[] (sys_mkdir+0x0/0x24) from []
> (ret_fast_syscall+0x0/0x30)
> "
>
> Memory-hotplug has same problem with CMA so [1]'s fix could be applied
> with memory-hotplug, too.
>
> Fix it by reusing.
>
> [1] 6a6dccba2, mm: cma: don't replace lowmem pages with highmem
>
> Cc: Kamezawa Hiroyuki
> Cc: Yasuaki Ishimatsu
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> Cc: Michal Nazarewicz
> Cc: Marek Szyprowski
> Cc: Wen Congyang
> Signed-off-by: Minchan Kim
> ---
> mm/memory_hotplug.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 4491a6b..fb71e5c 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -752,13 +752,6 @@ static unsigned long scan_lru_pages(unsigned long start,
> unsigned long end)
> return 0;
> }
>
> -static struct page *
> -hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
> -{
> - /* This should be improved!! */
> - return alloc_page(GFP_HIGHUSER_MOVABLE);
> -}
> -
> #define NR_OFFLINE_AT_ONCE_PAGES(256)
> static int
> do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
> @@ -809,8 +802,12 @@ do_migrate_range(unsigned long start_pfn, unsigned long
> end_pfn)
> putback_lru_pages();
> goto out;
> }
> - /* this function returns # of failed pages */
> - ret = migrate_pages(, hotremove_migrate_alloc, 0,
> +
> + /*
> + * alloc_migrate_target should be improved!!
> + * migrate_pages returns # of failed pages.
> + */
> + ret = migrate_pages(, alloc_migrate_target, 0,
> true, MIGRATE_SYNC);
> if (ret)
> putback_lru_pages();
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Staging: comedi: fl512: Replace printk with dev_info et al
Replace printk(KERN_XXX with the appropiate dev_info, dev_warn, dev_dbg in
fl512.c
Signed-off-by: Bruce Humphrey Ventura
---
drivers/staging/comedi/drivers/fl512.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/fl512.c
b/drivers/staging/comedi/drivers/fl512.c
index d1da809..5a8e0ae 100644
--- a/drivers/staging/comedi/drivers/fl512.c
+++ b/drivers/staging/comedi/drivers/fl512.c
@@ -118,9 +118,9 @@ static int fl512_attach(struct comedi_device *dev, struct
comedi_devconfig *it)
struct comedi_subdevice *s;
iobase = it->options[0];
- printk(KERN_INFO "comedi:%d fl512: 0x%04lx", dev->minor, iobase);
+ dev_info(dev->class_dev, "%s: 0x%04lx\n", dev->board_name, iobase);
if (!request_region(iobase, FL512_SIZE, "fl512")) {
- printk(KERN_WARNING " I/O port conflict\n");
+ dev_warn(dev->class_dev, " I/O port conflict\n");
return -EIO;
}
dev->iobase = iobase;
@@ -129,7 +129,7 @@ static int fl512_attach(struct comedi_device *dev, struct
comedi_devconfig *it)
return -ENOMEM;
#if DEBUG
- printk(KERN_DEBUG "malloc ok\n");
+ dev_dbg(dev->class_dev, "malloc ok\n");
#endif
ret = comedi_alloc_subdevices(dev, 2);
@@ -153,7 +153,8 @@ static int fl512_attach(struct comedi_device *dev, struct
comedi_devconfig *it)
s->range_table = _fl512;
/* function to call when read AD */
s->insn_read = fl512_ai_insn;
- printk(KERN_INFO "comedi: fl512: subdevice 0 initialized\n");
+ dev_info(dev->class_dev, "%s: subdevice 0 initialized\n",
+ dev->board_name);
/* Analog output */
s = dev->subdevices + 1;
@@ -171,7 +172,8 @@ static int fl512_attach(struct comedi_device *dev, struct
comedi_devconfig *it)
s->insn_write = fl512_ao_insn;
/* function to call when reading DA */
s->insn_read = fl512_ao_insn_readback;
- printk(KERN_INFO "comedi: fl512: subdevice 1 initialized\n");
+ dev_info(dev->class_dev, "%s: subdevice 1 initialized\n",
+ dev->board_name);
return 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Staging: Comedi: dyna_pci10xx: Replace printk with dev_info
Replace printk(KERN_XXX with dev_info, dev_warn, dev_dbg as appropiate in
dyna_pci10xx
Signed-off-by: Bruce Humphrey Ventura
---
drivers/staging/comedi/drivers/dyna_pci10xx.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/dyna_pci10xx.c
b/drivers/staging/comedi/drivers/dyna_pci10xx.c
index 064be9a..bfa62d1 100644
--- a/drivers/staging/comedi/drivers/dyna_pci10xx.c
+++ b/drivers/staging/comedi/drivers/dyna_pci10xx.c
@@ -140,8 +140,7 @@ static int dyna_pci10xx_insn_read_ai(struct comedi_device
*dev,
goto conv_finish;
}
data[n] = 0;
- printk(KERN_DEBUG "comedi: dyna_pci10xx: "
- "timeout reading analog input\n");
+ dev_dbg(dev->class_dev, "timeout reading analog input\n");
continue;
conv_finish:
/* mask the first 4 bits - EOC bits */
@@ -262,8 +261,7 @@ static int dyna_pci10xx_attach(struct comedi_device *dev,
int ret;
if (alloc_private(dev, sizeof(struct dyna_pci10xx_private)) < 0) {
- printk(KERN_ERR "comedi: dyna_pci10xx: "
- "failed to allocate memory!\n");
+ dev_err(dev->class_dev, "failed to allocate memory!\n");
return -ENOMEM;
}
@@ -276,14 +274,14 @@ static int dyna_pci10xx_attach(struct comedi_device *dev,
dev->irq = 0;
if (comedi_pci_enable(pcidev, DRV_NAME)) {
- printk(KERN_ERR "comedi: dyna_pci10xx: "
- "failed to enable PCI device and request regions!");
+ dev_err(dev->class_dev,
+ "failed to enable PCI device and request regions!\n");
return -EIO;
}
mutex_init(>mutex);
- printk(KERN_INFO "comedi: dyna_pci10xx: device found!\n");
+ pr_info("comedi: dyna_pci10xx: device found!\n");
dev->iobase = pci_resource_start(pcidev, 2);
devpriv->BADR3 = pci_resource_start(pcidev, 3);
@@ -333,7 +331,7 @@ static int dyna_pci10xx_attach(struct comedi_device *dev,
s->state = 0;
s->insn_bits = dyna_pci10xx_do_insn_bits;
- printk(KERN_INFO "comedi: dyna_pci10xx: %s - device setup completed!\n",
+ dev_info(dev->class_dev, "%s - device setup completed!\n",
thisboard->name);
return 1;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] drivers/block/aoe/aoecmd.c: Remove useless kfree
There's a patch in the mm tree that already makes this change, thanks.
Sent from my iPhone
On Sep 12, 2012, at 5:08 AM, "Peter Senna Tschudin"
wrote:
> From: Peter Senna Tschudin
>
> Remove useless kfree() and clean up code related to the removal.
>
> The semantic patch that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @r exists@
> position p1,p2;
> expression x;
> @@
>
> if (x@p1 == NULL) { ... kfree@p2(x); ... return ...; }
>
> @unchanged exists@
> position r.p1,r.p2;
> expression e <= r.x,x,e1;
> iterator I;
> statement S;
> @@
>
> if (x@p1 == NULL) { ... when != I(x,...) S
>when != e = e1
>when != e += e1
>when != e -= e1
>when != ++e
>when != --e
>when != e++
>when != e--
>when !=
> kfree@p2(x); ... return ...; }
>
> @ok depends on unchanged exists@
> position any r.p1;
> position r.p2;
> expression x;
> @@
>
> ... when != true x@p1 == NULL
> kfree@p2(x);
>
> @depends on !ok && unchanged@
> position r.p2;
> expression x;
> @@
>
> *kfree@p2(x);
> //
>
> Signed-off-by: Peter Senna Tschudin
>
> ---
> drivers/block/aoe/aoecmd.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index 5461faa..cbb0521 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -1257,7 +1257,6 @@ addtgt(struct aoedev *d, char *addr, ulong nframes)
>}
>t = kcalloc(1, sizeof *t, GFP_ATOMIC);
>if (!t) {
> -kfree(t);
>printk(KERN_INFO "aoe: cannot allocate memory to add target\n");
>return NULL;
>}
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] HID: hid-sensor-hub: Fix sensor_hub_probe error handling
Fix below issues in sensor_hub_probe error handling: 1. In the case of goto err_close, hid_hw_stop(hdev) is called twice. Fix it. 2. If fails to allocate MFD device name, we also need to free all successfully allocated names in previous iterations. Signed-off-by: Axel Lin --- drivers/hid/hid-sensor-hub.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 50bc8c7..8bd7620 100644 --- a/drivers/hid/hid-sensor-hub.c +++ b/drivers/hid/hid-sensor-hub.c @@ -584,7 +584,7 @@ static int sensor_hub_probe(struct hid_device *hdev, hid_err(hdev, "Failed MFD device name\n"); ret = -ENOMEM; - goto err_free_cells; + goto err_free_names; } sd->hid_sensor_hub_client_devs[ sd->hid_sensor_client_cnt].name = name; @@ -608,10 +608,8 @@ static int sensor_hub_probe(struct hid_device *hdev, err_free_names: for (i = 0; i < sd->hid_sensor_client_cnt ; ++i) kfree(sd->hid_sensor_hub_client_devs[i].name); -err_free_cells: kfree(sd->hid_sensor_hub_client_devs); err_close: - hid_hw_stop(hdev); hid_hw_close(hdev); err_stop_hw: hid_hw_stop(hdev); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] HID: hid-sensor-hub: Clear HID_CLAIMED_INPUT bit earlier
Clear HID_CLAIMED_INPUT bit of hdev->claimed, this prevents calling
hidinput_disconnect() in hid_disconnect(), which is called by hid_hw_stop().
We need to clear HID_CLAIMED_INPUT bit earlier rather than in
sensor_hub_remove() because we also call hid_hw_stop() in sensor_hub_probe
error handling.
Also adds comments for why we set hdev->claimed = HID_CLAIMED_INPUT.
Signed-off-by: Axel Lin
---
Hi srinivas,
I don't have this hardware, I'd appreciate if you can test these patches.
Axel
drivers/hid/hid-sensor-hub.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 4ac759c..50bc8c7 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -539,8 +539,11 @@ static int sensor_hub_probe(struct hid_device *hdev,
}
INIT_LIST_HEAD(>inputs);
+ /* We don't use hidinput but hid_hw_start() fails if nothing is
+* claimed. So spoof claimed input. */
hdev->claimed = HID_CLAIMED_INPUT;
ret = hid_hw_start(hdev, 0);
+ hdev->claimed &= ~HID_CLAIMED_INPUT;
if (ret) {
hid_err(hdev, "hw start failed\n");
goto err_free;
@@ -627,7 +630,6 @@ static void sensor_hub_remove(struct hid_device *hdev)
int i;
hid_dbg(hdev, " hardware removed\n");
- hdev->claimed &= ~HID_CLAIMED_INPUT;
hid_hw_stop(hdev);
hid_hw_close(hdev);
spin_lock_irqsave(>lock, flags);
--
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: [REVIEW][PATCH 12/15] userns: Convert drm to use kuid and kgid and struct pid where appropriate
> Blink Blink this had not been converted to use struct pid ages ago?
>
> - On drm open capture the openers kuid and struct pid.
> - On drm close release the kuid and struct pid
> - When reporting the uid and pid convert the kuid and struct pid
> into values in the appropriate namespace.
>
Hi Eric,
I'm fine with this seems okay, do you want me to merge it via drm-next?
Dave.
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Acked-by: Serge Hallyn
> Signed-off-by: Eric W. Biederman
> ---
> drivers/gpu/drm/drm_fops.c |3 ++-
> drivers/gpu/drm/drm_info.c |5 +++--
> drivers/gpu/drm/drm_ioctl.c |4 ++--
> include/drm/drmP.h |4 ++--
> init/Kconfig|1 -
> 5 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 5062eec..433d2fa 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -251,7 +251,7 @@ static int drm_open_helper(struct inode *inode, struct
> file *filp,
> filp->private_data = priv;
> priv->filp = filp;
> priv->uid = current_euid();
> - priv->pid = task_pid_nr(current);
> + priv->pid = get_pid(task_pid(current));
> priv->minor = idr_find(_minors_idr, minor_id);
> priv->ioctl_count = 0;
> /* for compatibility root is always authenticated */
> @@ -524,6 +524,7 @@ int drm_release(struct inode *inode, struct file *filp)
> if (drm_core_check_feature(dev, DRIVER_PRIME))
> drm_prime_destroy_file_private(_priv->prime);
>
> + put_pid(file_priv->pid);
> kfree(file_priv);
>
> /*
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index 8928edb..eb0af39 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -191,8 +191,9 @@ int drm_clients_info(struct seq_file *m, void *data)
> seq_printf(m, "%c %3d %5d %5d %10u %10lu\n",
>priv->authenticated ? 'y' : 'n',
>priv->minor->index,
> - priv->pid,
> - priv->uid, priv->magic, priv->ioctl_count);
> + pid_vnr(priv->pid),
> + from_kuid_munged(seq_user_ns(m), priv->uid),
> + priv->magic, priv->ioctl_count);
> }
> mutex_unlock(>struct_mutex);
> return 0;
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 64a62c6..39a4383 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -215,8 +215,8 @@ int drm_getclient(struct drm_device *dev, void *data,
> list_for_each_entry(pt, >filelist, lhead) {
> if (i++ >= idx) {
> client->auth = pt->authenticated;
> - client->pid = pt->pid;
> - client->uid = pt->uid;
> + client->pid = pid_vnr(pt->pid);
> + client->uid = from_kuid_munged(current_user_ns(),
> pt->uid);
> client->magic = pt->magic;
> client->iocs = pt->ioctl_count;
> mutex_unlock(>struct_mutex);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index d6b67bb..9bc5c6a 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -426,8 +426,8 @@ struct drm_prime_file_private {
> /** File private data */
> struct drm_file {
> int authenticated;
> - pid_t pid;
> - uid_t uid;
> + struct pid *pid;
> + kuid_t uid;
> drm_magic_t magic;
> unsigned long ioctl_count;
> struct list_head lhead;
> diff --git a/init/Kconfig b/init/Kconfig
> index d849ba2..2a388e5 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -930,7 +930,6 @@ config UIDGID_CONVERTED
> depends on FS_POSIX_ACL = n
> depends on QUOTA = n
> depends on QUOTACTL = n
> - depends on DRM = n
>
> # Networking
> depends on NET_9P = n
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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/
AMD Bulldozer FX-8150 Powers off during kernel build
I have a huge heatsink and large CPU fan plus lots of cooling fans in the case and nothing gets hot. If I build e.g 3.6-rc5 with 8 or 6 cores, part way through it suddenly powers off. I have checked hwmon/k10temp.c to see if I could see where these values were defined. k10temp.h is 0 bytes. -rw-r--r-- 1 root root 0 Sep 9 01:59 /usr/src/linux-3.6.0-rc5/include/config/sensors/k10temp.h Currently I build with "make -j 1" and temperature and power values are around those below. # sensors k10temp-pci-00c3 Adapter: PCI adapter temp1:+60.4°C (high = +70.0°C) (crit = +90.0°C, hyst = +87.0°C) fam15h_power-pci-00c4 Adapter: PCI adapter power1: 127.49 W (crit = 124.77 W) # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 1 model name : AMD FX(tm)-8150 Eight-Core Processor stepping: 2 microcode : 0x6000626 cpu MHz : 3600.000 cache size : 2048 KB from .config:- # grep HWMON .config CONFIG_IXGBE_HWMON=y CONFIG_HWMON=y CONFIG_HWMON_VID=m # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL_HWMON=y # grep POWERSAVE .config # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set CONFIG_CPU_FREQ_GOV_POWERSAVE=m # CONFIG_PCIEASPM_POWERSAVE is not set CONFIG_DEVFREQ_GOV_POWERSAVE=y On another 6-core box I can build kernels with "make -j 6" without problems. # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 1 model name : AMD FX(tm)-6100 Six-Core Processor stepping: 2 microcode : 0x6000623 cpu MHz : 3300.000 cache size : 2048 KB With a kernel build going on six core box, temperature and power hover around the values below. sabre:~ # sensors k10temp-pci-00c3 Adapter: PCI adapter temp1:+50.2°C (high = +70.0°C) (crit = +90.0°C, hyst = +87.0°C) fam15h_power-pci-00c4 Adapter: PCI adapter power1: 94.40 W (crit = 95.01 W) 73 ... Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: [ 042/108] NFS: Alias the nfs module to nfs4
On Wed, 2012-09-12 at 21:08 -0400, Josh Boyer wrote: > On Wed, Sep 12, 2012 at 7:28 PM, Greg Kroah-Hartman > wrote: > > From: Greg KH > > > > 3.5-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream. > > > > This allows distros to remove the line from their modprobe > > configuration. > > > > Signed-off-by: Bryan Schumaker > > Signed-off-by: Trond Myklebust > > [bwh: Backported to 3.2: adjust context] > > Signed-off-by: Ben Hutchings > > Signed-off-by: Greg Kroah-Hartman > > Could someone elaborate why this is acceptable now, while it wasn't > during the timeframe I sent an identical patch months ago? > > http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/02064.html > > We had some trouble in Fedora 17 because of this and would up with > patches to nfs-utils because the modalias was NAKed. If we're bringing > it into stable (and upstream) at this point, it would be good to know > what changed so I can go and undo what we did because I was told no. > > Please don't get me wrong, I'm all for simplicity. I'm just perhaps > so simple that the brief changelog confuses me because it doesn't > actually describe why the original solution wasn't followed up on. Linux-3.6 converts NFSv2/v3/v4 into modules, and so modprobe.conf entries of the form alias nfs4 nfs will now fail to ensure that 'mount -t nfs4 ...' works. In order to facilitate the task for the distros when dealing with kernels >= 3.5.x, we've added the automatic module alias so that they can remove the hard-coded aliases in modprobe.conf while remaining backward-compatible. -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com
Re: [PATCH v2 1/3] tracing,x86: add a TSC trace_clock
This change will require an ack from one of the x86 maintainers.
For reference to this patch, please see this thread:
https://lkml.org/lkml/2012/9/11/572
On Wed, 2012-09-12 at 16:31 -0700, David Sharp wrote:
> In order to promote interoperability between userspace tracers and ftrace,
> add a trace_clock that reports raw TSC values which will then be recorded
> in the ring buffer. Userspace tracers that also record TSCs are then on
> exactly the same time base as the kernel and events can be unambiguously
> interlaced.
>
> Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
> timestamp values.
>
> v2:
> Move arch-specific bits out of generic code.
As Masami pointed out, please add a SOB to your patches.
Thanks,
-- Steve
>
> Google-Bug-Id: 6980623
> ---
> arch/x86/include/asm/trace_clock.h | 16
> arch/x86/kernel/Makefile |1 +
> arch/x86/kernel/trace_clock.c | 20
> include/asm-generic/trace_clock.h | 15 +++
> include/linux/trace_clock.h|2 ++
> kernel/trace/trace.c |1 +
> 6 files changed, 55 insertions(+), 0 deletions(-)
> create mode 100644 arch/x86/include/asm/trace_clock.h
> create mode 100644 arch/x86/kernel/trace_clock.c
> create mode 100644 include/asm-generic/trace_clock.h
>
> diff --git a/arch/x86/include/asm/trace_clock.h
> b/arch/x86/include/asm/trace_clock.h
> new file mode 100644
> index 000..0b1f391
> --- /dev/null
> +++ b/arch/x86/include/asm/trace_clock.h
> @@ -0,0 +1,16 @@
> +#ifndef _ASM_X86_TRACE_CLOCK_H
> +#define _ASM_X86_TRACE_CLOCK_H
> +
> +#include
> +#include
> +
> +#ifdef CONFIG_X86_TSC
> +
> +extern u64 notrace trace_clock_x86_tsc(void);
> +
> +# define ARCH_TRACE_CLOCKS \
> + { trace_clock_x86_tsc, "tsc" },
> +
> +#endif
> +
> +#endif /* _ASM_X86_TRACE_CLOCK_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 8215e56..0ee9344 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
> obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
> obj-$(CONFIG_FTRACE_SYSCALLS)+= ftrace.o
> +obj-$(CONFIG_X86_TSC)+= trace_clock.o
> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
> diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.c
> new file mode 100644
> index 000..b8959f8
> --- /dev/null
> +++ b/arch/x86/kernel/trace_clock.c
> @@ -0,0 +1,20 @@
> +/*
> + * X86 trace clocks
> + */
> +#include
> +#include
> +#include
> +
> +/*
> + * trace_clock_x86_tsc(): A clock that is just the cycle counter.
> + *
> + * Unlike the other clocks, this is not in nanoseconds.
> + */
> +u64 notrace trace_clock_x86_tsc(void)
> +{
> + u64 ret;
> + rdtsc_barrier();
> + rdtscll(ret);
> +
> + return ret;
> +}
> diff --git a/include/asm-generic/trace_clock.h
> b/include/asm-generic/trace_clock.h
> new file mode 100644
> index 000..648cdcd
> --- /dev/null
> +++ b/include/asm-generic/trace_clock.h
> @@ -0,0 +1,15 @@
> +/*
> + * Arch-specific trace clocks.
> + */
> +#ifndef _ASM_GENERIC_TRACE_CLOCK_H
> +#define _ASM_GENERIC_TRACE_CLOCK_H
> +
> +/*
> + * Additional trace clocks added to the trace_clocks
> + * array in kernel/trace/trace.c
> + */
> +#ifndef ARCH_TRACE_CLOCKS
> +# define ARCH_TRACE_CLOCKS
> +#endif
> +
> +#endif /* _ASM_GENERIC_TRACE_CLOCK_H */
> diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
> index 4eb4902..d563f37 100644
> --- a/include/linux/trace_clock.h
> +++ b/include/linux/trace_clock.h
> @@ -12,6 +12,8 @@
> #include
> #include
>
> +#include
> +
> extern u64 notrace trace_clock_local(void);
> extern u64 notrace trace_clock(void);
> extern u64 notrace trace_clock_global(void);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c38c81..92fb08e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -480,6 +480,7 @@ static struct {
> { trace_clock_local,"local" },
> { trace_clock_global, "global" },
> { trace_clock_counter, "counter" },
> + ARCH_TRACE_CLOCKS
> };
>
> int trace_clock_id;
--
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 v9 10/13] ARM: SoC: convert imx6q to SoC descriptor
On Wed, Sep 12, 2012 at 04:58:23PM +0200, Arnd Bergmann wrote:
> From: Marc Zyngier
>
> Convert the imx6q platform to use the SoC descriptor to provide
> its SMP and CPU hotplug operations.
>
> Cc: Shawn Guo
> Signed-off-by: Marc Zyngier
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-imx/hotplug.c | 16 +---
> arch/arm/mach-imx/mach-imx6q.c |1 +
> arch/arm/mach-imx/platsmp.c | 18 ++
> arch/arm/plat-mxc/include/mach/common.h |4
> 4 files changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hotplug.c b/arch/arm/mach-imx/hotplug.c
> index f8f7437..b07b778 100644
> --- a/arch/arm/mach-imx/hotplug.c
> +++ b/arch/arm/mach-imx/hotplug.c
> @@ -15,11 +15,6 @@
> #include
> #include
>
> -int platform_cpu_kill(unsigned int cpu)
> -{
> - return 1;
> -}
> -
> static inline void cpu_enter_lowpower(void)
> {
> unsigned int v;
> @@ -47,7 +42,7 @@ static inline void cpu_enter_lowpower(void)
> *
> * Called with IRQs disabled
> */
> -void platform_cpu_die(unsigned int cpu)
> +void imx_cpu_die(unsigned int cpu)
> {
> cpu_enter_lowpower();
> imx_enable_cpu(cpu, false);
> @@ -56,12 +51,3 @@ void platform_cpu_die(unsigned int cpu)
> while (1)
> ;
> }
> -
> -int platform_cpu_disable(unsigned int cpu)
> -{
> - /*
> - * we don't allow CPU 0 to be shutdown (it is still too special
> - * e.g. clock tick interrupts)
> - */
> - return cpu == 0 ? -EPERM : 0;
> -}
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 045b3f6..ef0b52f 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -226,6 +226,7 @@ static const char *imx6q_dt_compat[] __initdata = {
> };
>
> DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad (Device Tree)")
> + .smp= smp_ops(imx6q_soc_desc),
s/imx6q_soc_desc/imx_smp_ops
Otherwise,
Acked-by: Shawn Guo
Regards,
Shawn
> .map_io = imx6q_map_io,
> .init_irq = imx6q_init_irq,
> .handle_irq = imx6q_handle_irq,
> diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
> index ab98c6f..2ac43e1 100644
> --- a/arch/arm/mach-imx/platsmp.c
> +++ b/arch/arm/mach-imx/platsmp.c
> @@ -41,7 +41,7 @@ void __init imx_scu_map_io(void)
> scu_base = IMX_IO_ADDRESS(base);
> }
>
> -void __cpuinit platform_secondary_init(unsigned int cpu)
> +static void __cpuinit imx_secondary_init(unsigned int cpu)
> {
> /*
>* if any interrupts are already enabled for the primary
> @@ -51,7 +51,7 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
> gic_secondary_init(0);
> }
>
> -int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
> +static int __cpuinit imx_boot_secondary(unsigned int cpu, struct task_struct
> *idle)
> {
> imx_set_cpu_jump(cpu, v7_secondary_startup);
> imx_enable_cpu(cpu, true);
> @@ -62,7 +62,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
> task_struct *idle)
> * Initialise the CPU possible map early - this describes the CPUs
> * which may be present or become present in the system.
> */
> -void __init smp_init_cpus(void)
> +static void __init imx_smp_init_cpus(void)
> {
> int i, ncores;
>
> @@ -79,7 +79,17 @@ void imx_smp_prepare(void)
> scu_enable(scu_base);
> }
>
> -void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> +static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
> {
> imx_smp_prepare();
> }
> +
> +struct smp_operations imx_smp_ops __initdata = {
> + .smp_init_cpus = imx_smp_init_cpus,
> + .smp_prepare_cpus = imx_smp_prepare_cpus,
> + .smp_secondary_init = imx_secondary_init,
> + .smp_boot_secondary = imx_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_die= imx_cpu_die,
> +#endif
> +};
> diff --git a/arch/arm/plat-mxc/include/mach/common.h
> b/arch/arm/plat-mxc/include/mach/common.h
> index 7128e97..e8b5150 100644
> --- a/arch/arm/plat-mxc/include/mach/common.h
> +++ b/arch/arm/plat-mxc/include/mach/common.h
> @@ -145,6 +145,8 @@ extern void imx53_smd_common_init(void);
> extern int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
> extern void imx6q_clock_map_io(void);
>
> +extern void imx_cpu_die(unsigned int cpu);
> +
> #ifdef CONFIG_PM
> extern void imx6q_pm_init(void);
> extern void imx51_pm_init(void);
> @@ -161,4 +163,6 @@ extern int mx51_neon_fixup(void);
> static inline int mx51_neon_fixup(void) { return 0; }
> #endif
>
> +extern struct smp_operations imx_smp_ops;
> +
> #endif
> --
> 1.7.10
>
--
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 1/3] tracing,x86: add a TSC trace_clock
(2012/09/13 8:31), David Sharp wrote:
> In order to promote interoperability between userspace tracers and ftrace,
> add a trace_clock that reports raw TSC values which will then be recorded
> in the ring buffer. Userspace tracers that also record TSCs are then on
> exactly the same time base as the kernel and events can be unambiguously
> interlaced.
>
> Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
> timestamp values.
Yeah, this is what I need!
BTW, could you add your signed-off-by signature to your patches?
Thank you,
>
> v2:
> Move arch-specific bits out of generic code.
>
> Google-Bug-Id: 6980623
> ---
> arch/x86/include/asm/trace_clock.h | 16
> arch/x86/kernel/Makefile |1 +
> arch/x86/kernel/trace_clock.c | 20
> include/asm-generic/trace_clock.h | 15 +++
> include/linux/trace_clock.h|2 ++
> kernel/trace/trace.c |1 +
> 6 files changed, 55 insertions(+), 0 deletions(-)
> create mode 100644 arch/x86/include/asm/trace_clock.h
> create mode 100644 arch/x86/kernel/trace_clock.c
> create mode 100644 include/asm-generic/trace_clock.h
>
> diff --git a/arch/x86/include/asm/trace_clock.h
> b/arch/x86/include/asm/trace_clock.h
> new file mode 100644
> index 000..0b1f391
> --- /dev/null
> +++ b/arch/x86/include/asm/trace_clock.h
> @@ -0,0 +1,16 @@
> +#ifndef _ASM_X86_TRACE_CLOCK_H
> +#define _ASM_X86_TRACE_CLOCK_H
> +
> +#include
> +#include
> +
> +#ifdef CONFIG_X86_TSC
> +
> +extern u64 notrace trace_clock_x86_tsc(void);
> +
> +# define ARCH_TRACE_CLOCKS \
> + { trace_clock_x86_tsc, "tsc" },
> +
> +#endif
> +
> +#endif /* _ASM_X86_TRACE_CLOCK_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 8215e56..0ee9344 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
> obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
> obj-$(CONFIG_FTRACE_SYSCALLS)+= ftrace.o
> +obj-$(CONFIG_X86_TSC)+= trace_clock.o
> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
> diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.c
> new file mode 100644
> index 000..b8959f8
> --- /dev/null
> +++ b/arch/x86/kernel/trace_clock.c
> @@ -0,0 +1,20 @@
> +/*
> + * X86 trace clocks
> + */
> +#include
> +#include
> +#include
> +
> +/*
> + * trace_clock_x86_tsc(): A clock that is just the cycle counter.
> + *
> + * Unlike the other clocks, this is not in nanoseconds.
> + */
> +u64 notrace trace_clock_x86_tsc(void)
> +{
> + u64 ret;
> + rdtsc_barrier();
> + rdtscll(ret);
> +
> + return ret;
> +}
> diff --git a/include/asm-generic/trace_clock.h
> b/include/asm-generic/trace_clock.h
> new file mode 100644
> index 000..648cdcd
> --- /dev/null
> +++ b/include/asm-generic/trace_clock.h
> @@ -0,0 +1,15 @@
> +/*
> + * Arch-specific trace clocks.
> + */
> +#ifndef _ASM_GENERIC_TRACE_CLOCK_H
> +#define _ASM_GENERIC_TRACE_CLOCK_H
> +
> +/*
> + * Additional trace clocks added to the trace_clocks
> + * array in kernel/trace/trace.c
> + */
> +#ifndef ARCH_TRACE_CLOCKS
> +# define ARCH_TRACE_CLOCKS
> +#endif
> +
> +#endif /* _ASM_GENERIC_TRACE_CLOCK_H */
> diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
> index 4eb4902..d563f37 100644
> --- a/include/linux/trace_clock.h
> +++ b/include/linux/trace_clock.h
> @@ -12,6 +12,8 @@
> #include
> #include
>
> +#include
> +
> extern u64 notrace trace_clock_local(void);
> extern u64 notrace trace_clock(void);
> extern u64 notrace trace_clock_global(void);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c38c81..92fb08e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -480,6 +480,7 @@ static struct {
> { trace_clock_local,"local" },
> { trace_clock_global, "global" },
> { trace_clock_counter, "counter" },
> + ARCH_TRACE_CLOCKS
> };
>
> int trace_clock_id;
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Digital signature library bugfix
On Wed, Sep 12, 2012 at 6:22 PM, Kasatkin, Dmitry wrote: > > But I will re-send updated patch in a moment. Ok, I took that updated patch instead of the pull request, since I liked that much more, and hadn't actually pushed out the pull yet. 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]URL is unavailable
On 12/09/12 12:03 PM, Borislav Petkov wrote: > Dear KORG admins, what are the chances of userweb.kernel.org coming back > online? Hello: There is no ETA on that service being available. It may not ever come back, at least not in the way it was before. That being said, I'm perfectly willing to set up a few redirects in place if broken URLs are causing problems. I just cannot use any of the existing backups of userweb data, as it is under a strict "do not use, ever" quarantine. If someone can provide me with trusted backups of that data, I will provide hosting and redirects to unbreak the URLs. Best, -- Konstantin Ryabitsev Systems Administrator Linux Foundation, kernel.org Montréal, Québec signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] dev_ and dynamic_debug cleanups
On Thu, 2012-09-06 at 13:53 -0400, Jason Baron wrote: > On Thu, Sep 06, 2012 at 09:13:59AM -0700, Greg Kroah-Hartman wrote: > > Jason, any ACK on these, or any of the other random dynamic debug > > patches floating around? What am I supposed to be applying here? [] > I just posted some follow up comments to Joe, so let's see where that > discussion goes. Jason, I think you need to ack these original 5 patches. -- 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: rcu self-detected stall messages on OMAP3, 4 boards
On Wed, Sep 12, 2012 at 10:51:30PM +, Paul Walmsley wrote:
>
> Hi Paul
>
> Recently several of us have been seeing "INFO: rcu_sched self-detected
> stall on CPU { 0} (t=20611 jiffies)" stack tracebacks on various OMAP3
> and 4 board.
>
> I only noticed it during v3.6-rc3, but I suspect it's been happening
> for users at least since May:
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68942.html
>
>
> The only quasi-reproducible test case that I've found so far
> is to boot the board with serial console enabled to a login prompt, then
> wait for a few minutes, then send a keypress to the board via serial.
> The tracebacks I get look like this:
Interesting. I am assuming that the interrupt in the stack below came
from idle, if not, please let me know what.
Could you please reproduce with CONFIG_RCU_CPU_STALL_INFO=y? That would
give me a bit more information about why RCU thought that there was
a stall. (CCing Becky Bruce, who saw something similar recently.)
Subodh Nijsure (also CCed) reported something that might be similar on
ARM, and also reported that setting the following got rid of the stalls:
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
At which point he was happy, which was good, but which also left the
underlying problem unsolved. Do these affect your system? If so,
do they cause a different ARM idle loop to be executed?
Thanx, Paul
> [ 467.480712] INFO: rcu_sched self-detected stall on CPU { 0} (t=20611
> jiffies)
> [ 467.484741] [] (unwind_backtrace+0x0/0xf0) from []
> (rcu_check_callbacks+0x180/0x630)
> [ 467.489929] [] (rcu_check_callbacks+0x180/0x630) from
> [] (update_process_times+0x38/0x68)
> [ 467.495361] [] (update_process_times+0x38/0x68) from
> [] (tick_sched_timer+0x80/0xec)
> [ 467.500518] [] (tick_sched_timer+0x80/0xec) from []
> (__run_hrtimer+0x7c/0x1e0)
> [ 467.505401] [] (__run_hrtimer+0x7c/0x1e0) from []
> (hrtimer_interrupt+0x11c/0x2d0)
> [ 467.510437] [] (hrtimer_interrupt+0x11c/0x2d0) from []
> (twd_handler+0x30/0x44)
> [ 467.515350] [] (twd_handler+0x30/0x44) from []
> (handle_percpu_devid_irq+0x90/0x13c)
> [ 467.520477] [] (handle_percpu_devid_irq+0x90/0x13c) from
> [] (generic_handle_irq+0x30/0x48)
> [ 467.525939] [] (generic_handle_irq+0x30/0x48) from []
> (handle_IRQ+0x4c/0xac)
> [ 467.530731] [] (handle_IRQ+0x4c/0xac) from []
> (gic_handle_irq+0x28/0x5c)
> [ 467.535339] [] (gic_handle_irq+0x28/0x5c) from []
> (__irq_svc+0x44/0x5c)
> [ 467.539886] Exception stack(0xc0729f58 to 0xc0729fa0)
> [ 467.542663] 9f40:
> 00047f2a 0001
> [ 467.547119] 9f60: c074a940 c0728000 c07c4b08 c05045a0 c074be20
> 411fc092
> [ 467.551574] 9f80: c074c040 0001 c0729fa0 00047f2b c0014f50
> 2113
> [ 467.556030] [] (__irq_svc+0x44/0x5c) from []
> (default_idle+0x20/0x44)
> [ 467.560485] [] (default_idle+0x20/0x44) from []
> (cpu_idle+0x9c/0x114)
> [ 467.564971] [] (cpu_idle+0x9c/0x114) from []
> (start_kernel+0x2b4/0x304)
>
> Looks like this message was added as of commit
> a858af2875fb291d0f4b0a4419fefbf03c2379c0 ("rcu: Print scheduling-clock
> information on RCU CPU stall-warning messages").
>
> Do you have any suggestions for how we can determine what is causing
> this?
>
> Here's an example of a kernel config that we use:
>
> http://www.pwsan.com/omap/testlogs/am33xx_hwmod_clock_devel_3.7/20120912092510/build/omap2plus_defconfig/Kconfig
>
> A few observations that may or may not be relevant: we use NO_HZ, and
> we also have a clockevents timer that is relatively slow to program.
>
>
> regards,
>
> - Paul
>
--
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: [ 042/108] NFS: Alias the nfs module to nfs4
On Wed, Sep 12, 2012 at 7:28 PM, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.5-stable review patch. If anyone has any objections, please let me know. > > -- > > commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream. > > This allows distros to remove the line from their modprobe > configuration. > > Signed-off-by: Bryan Schumaker > Signed-off-by: Trond Myklebust > [bwh: Backported to 3.2: adjust context] > Signed-off-by: Ben Hutchings > Signed-off-by: Greg Kroah-Hartman Could someone elaborate why this is acceptable now, while it wasn't during the timeframe I sent an identical patch months ago? http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/02064.html We had some trouble in Fedora 17 because of this and would up with patches to nfs-utils because the modalias was NAKed. If we're bringing it into stable (and upstream) at this point, it would be good to know what changed so I can go and undo what we did because I was told no. Please don't get me wrong, I'm all for simplicity. I'm just perhaps so simple that the brief changelog confuses me because it doesn't actually describe why the original solution wasn't followed up on. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Add ratelimited printk for different alert levels
On Tue, Sep 11, 2012 at 08:22:39PM -0700, Joe Perches wrote:
> On Wed, 2012-09-12 at 03:43 +0530, raghu.prabh...@gmail.com wrote:
> > Ratelimited printk will be useful in printing xfs messages which are
> > otherwise
> > not required to be printed always due to their high rate (to prevent kernel
> > ring
> > buffer from overflowing), while at the same time required to be printed.
> []
> > diff --git a/fs/xfs/xfs_message.h b/fs/xfs/xfs_message.h
> []
> > @@ -30,6 +32,32 @@ void xfs_debug(const struct xfs_mount *mp, const char
> > *fmt, ...)
> > }
> > #endif
> >
> > +#define xfs_printk_ratelimited(xfs_printk, dev, fmt, ...) \
> > +do {
> > \
> > + static DEFINE_RATELIMIT_STATE(_rs, \
> > + DEFAULT_RATELIMIT_INTERVAL, \
> > + DEFAULT_RATELIMIT_BURST); \
> > + if (__ratelimit(&_rs)) \
> > + xfs_printk(dev, fmt, ##__VA_ARGS__);\
> > +} while (0)
>
> It might be better to use an xfs singleton RATELIMIT_STATE
>
> DEFINE_RATELIMIT_STATE(xfs_rs);
> ...
> #define xfs_printk_ratelimited(xfs_printk, dev, fmt, ...) \
> do { \
> if (__ratelimit(_rs)) \
> xfs_printk(dev, fmt, ##__VA_ARGS__);\
> } while (0)
Which would then result in ratelimiting dropping potentially
important, unique messages. I think it's much better to guarantee
ratelimited messages get emitted at least once, especially as there
is the potential for multiple filesystems to emit messages
simultaneously.
I think per-location rate limiting is fine for the current usage -
ratelimiting is not widespread so there isn't a massive increase in
size as a result of this. If we do start to use ratelimiting in lots
of places in XFS, then we might have to revisit this, but it's OK
for now.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 004/108] ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled
From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Will Deacon commit 3d9fb0038a9b02febb01efc79a4a5d97f1822a90 upstream. VFPv4 support depends on the VFPv3 context save/restore code, so only advertise support in the hwcaps if the kernel can actually handle it. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman --- arch/arm/vfp/vfpmodule.c |2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -719,8 +719,10 @@ static int __init vfp_init(void) if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100) elf_hwcap |= HWCAP_NEON; #endif +#ifdef CONFIG_VFPv3 if ((fmrx(MVFR1) & 0xf000) == 0x1000) elf_hwcap |= HWCAP_VFPv4; +#endif } } return 0; -- 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/
[ 017/108] MIPS: pci-ar724x: avoid data bus error due to a missing PCIe module
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Gabor Juhos
commit a1dca315ce3f78347bca8ce8befe3cc71ae63b7e upstream.
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.
Signed-off-by: Gabor Juhos
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
---
arch/mips/pci/pci-ar724x.c | 22 ++
1 file changed, 22 insertions(+)
--- a/arch/mips/pci/pci-ar724x.c
+++ b/arch/mips/pci/pci-ar724x.c
@@ -23,9 +23,12 @@
#define AR724X_PCI_MEM_BASE0x1000
#define AR724X_PCI_MEM_SIZE0x0800
+#define AR724X_PCI_REG_RESET 0x18
#define AR724X_PCI_REG_INT_STATUS 0x4c
#define AR724X_PCI_REG_INT_MASK0x50
+#define AR724X_PCI_RESET_LINK_UP BIT(0)
+
#define AR724X_PCI_INT_DEV0BIT(14)
#define AR724X_PCI_IRQ_COUNT 1
@@ -38,6 +41,15 @@ static void __iomem *ar724x_pci_ctrl_bas
static u32 ar724x_pci_bar0_value;
static bool ar724x_pci_bar0_is_cached;
+static bool ar724x_pci_link_up;
+
+static inline bool ar724x_pci_check_link(void)
+{
+ u32 reset;
+
+ reset = __raw_readl(ar724x_pci_ctrl_base + AR724X_PCI_REG_RESET);
+ return reset & AR724X_PCI_RESET_LINK_UP;
+}
static int ar724x_pci_read(struct pci_bus *bus, unsigned int devfn, int where,
int size, uint32_t *value)
@@ -46,6 +58,9 @@ static int ar724x_pci_read(struct pci_bu
void __iomem *base;
u32 data;
+ if (!ar724x_pci_link_up)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
if (devfn)
return PCIBIOS_DEVICE_NOT_FOUND;
@@ -96,6 +111,9 @@ static int ar724x_pci_write(struct pci_b
u32 data;
int s;
+ if (!ar724x_pci_link_up)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
if (devfn)
return PCIBIOS_DEVICE_NOT_FOUND;
@@ -280,6 +298,10 @@ int __init ar724x_pcibios_init(int irq)
if (ar724x_pci_ctrl_base == NULL)
goto err_unmap_devcfg;
+ ar724x_pci_link_up = ar724x_pci_check_link();
+ if (!ar724x_pci_link_up)
+ pr_warn("ar724x: PCIe link is down\n");
+
ar724x_pci_irq_init(irq);
register_pci_controller(_pci_controller);
--
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/
[ 015/108] ARM: imx: select CPU_FREQ_TABLE when needed
From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream. The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, so it needs to select that code to be built. This problem has apparently existed since the i.MX cpufreq code was first merged in v2.6.37. Building IMX without CPU_FREQ_TABLE results in: arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr' arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target' arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify' arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo' arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Cc: Yong Shen Signed-off-by: Greg Kroah-Hartman --- arch/arm/Kconfig |1 + 1 file changed, 1 insertion(+) --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2083,6 +2083,7 @@ source "drivers/cpufreq/Kconfig" config CPU_FREQ_IMX tristate "CPUfreq driver for i.MX CPUs" depends on ARCH_MXC && CPU_FREQ + select CPU_FREQ_TABLE help This enables the CPUfreq driver for i.MX CPUs. -- 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/
[ 019/108] ASoC: omap-mcbsp: Fix 6pin mux configuration
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Ujfalusi
commit d0db84e713eaaccea2a435e1625fb3150b335f4a upstream.
The check for the mux_signal callback was wrong which prevents us to
configure the 6pin port's FSR/CLKR signal mux.
Reported-by: CF Adad
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/omap/mcbsp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -745,7 +745,7 @@ int omap_mcbsp_6pin_src_mux(struct omap_
{
const char *signal, *src;
- if (mcbsp->pdata->mux_signal)
+ if (!mcbsp->pdata->mux_signal)
return -EINVAL;
switch (mux) {
--
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/
[ 006/108] ARM: 7488/1: mm: use 5 bits for swapfile type encoding
From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Will Deacon commit f5f2025ef3e2cdb593707cbf87378761f17befbe upstream. Page migration encodes the pfn in the offset field of a swp_entry_t. For LPAE, we support physical addresses of up to 36 bits (due to sparsemem limitations with the size of page flags), requiring 24 bits to represent a pfn. A further 3 bits are used to encode a swp_entry into a pte, leaving 5 bits for the type field. Furthermore, the core code defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not get used. This patch reduces the width of the type field to 5 bits, allowing us to create up to 31 swapfiles of 64GB each. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman --- arch/arm/include/asm/pgtable.h |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -253,13 +253,13 @@ static inline pte_t pte_modify(pte_t pte * * 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 * 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 - * <--- offset > <- type --> 0 0 0 + * <--- offset --> < type -> 0 0 0 * - * This gives us up to 63 swap files and 32GB per swap file. Note that + * This gives us up to 31 swap files and 64GB per swap file. Note that * the offset field is always non-zero. */ #define __SWP_TYPE_SHIFT 3 -#define __SWP_TYPE_BITS6 +#define __SWP_TYPE_BITS5 #define __SWP_TYPE_MASK((1 << __SWP_TYPE_BITS) - 1) #define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT) -- 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/
[ 008/108] ARM: OMAP2+: Fix dmtimer set source clock failure
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jon Hunter
commit 54f32a35f4d3a653a18a2c8c239f19ae060bd803 upstream.
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
The following error message would be seen ...
omap_dm_timer_set_source: failed to set timer_32k_ck as parent
The problem is that, by design, pm_runtime_put() simply decrements the usage
count and returns before the timer has actually been disabled. Therefore,
setting the parent clock failed because the timer was still active when the
trying to set the parent clock. Setting a parent clock will fail if the clock
you are setting the parent of has a non-zero usage count. To ensure that this
does not fail use pm_runtime_put_sync() when disabling the timer.
Note that this will not be seen on OMAP1 devices, because these devices do
not use the clock framework for dmtimers.
Signed-off-by: Jon Hunter
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -236,7 +236,7 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
- pm_runtime_put(>pdev->dev);
+ pm_runtime_put_sync(>pdev->dev);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
--
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/
[ 018/108] ASoC: wm9712: Fix microphone source selection
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Brown
commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream.
Currently the microphone input source is not selectable as while there is
a DAPM widget it's not connected to anything so it won't be properly
instantiated. Add something more correct for the input structure to get
things going, even though it's not hooked into the rest of the routing
map and so won't actually achieve anything except allowing the relevant
register bits to be written.
Reported-by: Christop Fritz
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/wm9712.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -272,7 +272,7 @@ SOC_DAPM_ENUM("Route", wm9712_enum[9]);
/* Mic select */
static const struct snd_kcontrol_new wm9712_mic_src_controls =
-SOC_DAPM_ENUM("Route", wm9712_enum[7]);
+SOC_DAPM_ENUM("Mic Source Select", wm9712_enum[7]);
/* diff select */
static const struct snd_kcontrol_new wm9712_diff_sel_controls =
@@ -291,7 +291,9 @@ SND_SOC_DAPM_MUX("Left Capture Select",
_capture_selectl_controls),
SND_SOC_DAPM_MUX("Right Capture Select", SND_SOC_NOPM, 0, 0,
_capture_selectr_controls),
-SND_SOC_DAPM_MUX("Mic Select Source", SND_SOC_NOPM, 0, 0,
+SND_SOC_DAPM_MUX("Left Mic Select Source", SND_SOC_NOPM, 0, 0,
+ _mic_src_controls),
+SND_SOC_DAPM_MUX("Right Mic Select Source", SND_SOC_NOPM, 0, 0,
_mic_src_controls),
SND_SOC_DAPM_MUX("Differential Source", SND_SOC_NOPM, 0, 0,
_diff_sel_controls),
@@ -319,6 +321,7 @@ SND_SOC_DAPM_PGA("Out 3 PGA", AC97_INT_P
SND_SOC_DAPM_PGA("Line PGA", AC97_INT_PAGING, 2, 1, NULL, 0),
SND_SOC_DAPM_PGA("Phone PGA", AC97_INT_PAGING, 1, 1, NULL, 0),
SND_SOC_DAPM_PGA("Mic PGA", AC97_INT_PAGING, 0, 1, NULL, 0),
+SND_SOC_DAPM_PGA("Differential Mic", SND_SOC_NOPM, 0, 0, NULL, 0),
SND_SOC_DAPM_MICBIAS("Mic Bias", AC97_INT_PAGING, 10, 1),
SND_SOC_DAPM_OUTPUT("MONOOUT"),
SND_SOC_DAPM_OUTPUT("HPOUTL"),
@@ -379,6 +382,18 @@ static const struct snd_soc_dapm_route w
{"Mic PGA", NULL, "MIC1"},
{"Mic PGA", NULL, "MIC2"},
+ /* microphones */
+ {"Differential Mic", NULL, "MIC1"},
+ {"Differential Mic", NULL, "MIC2"},
+ {"Left Mic Select Source", "Mic 1", "MIC1"},
+ {"Left Mic Select Source", "Mic 2", "MIC2"},
+ {"Left Mic Select Source", "Stereo", "MIC1"},
+ {"Left Mic Select Source", "Differential", "Differential Mic"},
+ {"Right Mic Select Source", "Mic 1", "MIC1"},
+ {"Right Mic Select Source", "Mic 2", "MIC2"},
+ {"Right Mic Select Source", "Stereo", "MIC2"},
+ {"Right Mic Select Source", "Differential", "Differential Mic"},
+
/* left capture selector */
{"Left Capture Select", "Mic", "MIC1"},
{"Left Capture Select", "Speaker Mixer", "Speaker Mixer"},
--
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/
[ 012/108] xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk
commit c96aae1f7f393387d160211f60398d58463a7e65 upstream.
When we are finished with return PFNs to the hypervisor, then
populate it back, and also mark the E820 MMIO and E820 gaps
as IDENTITY_FRAMEs, we then call P2M to set areas that can
be used for ballooning. We were off by one, and ended up
over-writting a P2M entry that most likely was an IDENTITY_FRAME.
For example:
1-1 mapping on 4->40200
1-1 mapping on bc558->bc5ac
1-1 mapping on bc5b4->bc8c5
1-1 mapping on bc8c6->bcb7c
1-1 mapping on bcd00->10
Released 614 pages of unused memory
Set 277889 page(s) to 1-1 mapping
Populating 40200-40466 pfn range: 614 pages added
=> here we set from 40466 up to bc559 P2M tree to be
INVALID_P2M_ENTRY. We should have done it up to bc558.
The end result is that if anybody is trying to construct
a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
Reported-by-and-Tested-by: Andre Przywara
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/setup.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -78,9 +78,16 @@ static void __init xen_add_extra_mem(u64
memblock_reserve(start, size);
xen_max_p2m_pfn = PFN_DOWN(start + size);
+ for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
+ unsigned long mfn = pfn_to_mfn(pfn);
+
+ if (WARN(mfn == pfn, "Trying to over-write 1-1 mapping (pfn:
%lx)\n", pfn))
+ continue;
+ WARN(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has
%lx mfn!\n",
+ pfn, mfn);
- for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++)
__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ }
}
static unsigned long __init xen_do_chunk(unsigned long start,
--
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/
[ 030/108] pnfs: defer release of pages in layoutget
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Idan Kedar
commit 8554116e17eef055d9dd58a94b3427cb2ad1c317 upstream.
we have encountered a bug whereby reading a lot of files (copying
fedora's /bin) from a pNFS mount and hitting Ctrl+C in the middle caused
a general protection fault in xdr_shrink_bufhead. this function is
called when decoding the response from LAYOUTGET. the decoding is done
by a worker thread, and the caller of LAYOUTGET waits for the worker
thread to complete.
hitting Ctrl+C caused the synchronous wait to end and the next thing the
caller does is to free the pages, so when the worker thread calls
xdr_shrink_bufhead, the pages are gone. therefore, the cleanup of these
pages has been moved to nfs4_layoutget_release.
Signed-off-by: Idan Kedar
Signed-off-by: Benny Halevy
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4proc.c | 57 +-
fs/nfs/pnfs.c | 39
fs/nfs/pnfs.h |2 -
3 files changed, 58 insertions(+), 40 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6164,11 +6164,58 @@ static void nfs4_layoutget_done(struct r
dprintk("<-- %s\n", __func__);
}
+static size_t max_response_pages(struct nfs_server *server)
+{
+ u32 max_resp_sz = server->nfs_client->cl_session->fc_attrs.max_resp_sz;
+ return nfs_page_array_len(0, max_resp_sz);
+}
+
+static void nfs4_free_pages(struct page **pages, size_t size)
+{
+ int i;
+
+ if (!pages)
+ return;
+
+ for (i = 0; i < size; i++) {
+ if (!pages[i])
+ break;
+ __free_page(pages[i]);
+ }
+ kfree(pages);
+}
+
+static struct page **nfs4_alloc_pages(size_t size, gfp_t gfp_flags)
+{
+ struct page **pages;
+ int i;
+
+ pages = kcalloc(size, sizeof(struct page *), gfp_flags);
+ if (!pages) {
+ dprintk("%s: can't alloc array of %zu pages\n", __func__, size);
+ return NULL;
+ }
+
+ for (i = 0; i < size; i++) {
+ pages[i] = alloc_page(gfp_flags);
+ if (!pages[i]) {
+ dprintk("%s: failed to allocate page\n", __func__);
+ nfs4_free_pages(pages, size);
+ return NULL;
+ }
+ }
+
+ return pages;
+}
+
static void nfs4_layoutget_release(void *calldata)
{
struct nfs4_layoutget *lgp = calldata;
+ struct nfs_server *server = NFS_SERVER(lgp->args.inode);
+ size_t max_pages = max_response_pages(server);
dprintk("--> %s\n", __func__);
+ nfs4_free_pages(lgp->args.layout.pages, max_pages);
put_nfs_open_context(lgp->args.ctx);
kfree(calldata);
dprintk("<-- %s\n", __func__);
@@ -6180,9 +6227,10 @@ static const struct rpc_call_ops nfs4_la
.rpc_release = nfs4_layoutget_release,
};
-int nfs4_proc_layoutget(struct nfs4_layoutget *lgp)
+int nfs4_proc_layoutget(struct nfs4_layoutget *lgp, gfp_t gfp_flags)
{
struct nfs_server *server = NFS_SERVER(lgp->args.inode);
+ size_t max_pages = max_response_pages(server);
struct rpc_task *task;
struct rpc_message msg = {
.rpc_proc = _procedures[NFSPROC4_CLNT_LAYOUTGET],
@@ -6200,6 +6248,13 @@ int nfs4_proc_layoutget(struct nfs4_layo
dprintk("--> %s\n", __func__);
+ lgp->args.layout.pages = nfs4_alloc_pages(max_pages, gfp_flags);
+ if (!lgp->args.layout.pages) {
+ nfs4_layoutget_release(lgp);
+ return -ENOMEM;
+ }
+ lgp->args.layout.pglen = max_pages * PAGE_SIZE;
+
lgp->res.layoutp = >args.layout;
lgp->res.seq_res.sr_slot = NULL;
nfs41_init_sequence(>args.seq_args, >res.seq_res, 0);
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -583,9 +583,6 @@ send_layoutget(struct pnfs_layout_hdr *l
struct nfs_server *server = NFS_SERVER(ino);
struct nfs4_layoutget *lgp;
struct pnfs_layout_segment *lseg = NULL;
- struct page **pages = NULL;
- int i;
- u32 max_resp_sz, max_pages;
dprintk("--> %s\n", __func__);
@@ -594,20 +591,6 @@ send_layoutget(struct pnfs_layout_hdr *l
if (lgp == NULL)
return NULL;
- /* allocate pages for xdr post processing */
- max_resp_sz = server->nfs_client->cl_session->fc_attrs.max_resp_sz;
- max_pages = nfs_page_array_len(0, max_resp_sz);
-
- pages = kcalloc(max_pages, sizeof(struct page *), gfp_flags);
- if (!pages)
- goto out_err_free;
-
- for (i = 0; i < max_pages; i++) {
- pages[i] = alloc_page(gfp_flags);
- if (!pages[i])
- goto out_err_free;
- }
-
lgp->args.minlength = PAGE_CACHE_SIZE;
if (lgp->args.minlength >
[ 031/108] nfs: tear down caches in nfs_init_writepagecache when allocation fails
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 3dd4765fce04c0b4af1e0bc4c0b10f906f95fabc upstream.
...and ensure that we tear down the nfs_commit_data cache too when
unloading the module.
Cc: Bryan Schumaker
Signed-off-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/write.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1806,19 +1806,19 @@ int __init nfs_init_writepagecache(void)
nfs_wdata_mempool = mempool_create_slab_pool(MIN_POOL_WRITE,
nfs_wdata_cachep);
if (nfs_wdata_mempool == NULL)
- return -ENOMEM;
+ goto out_destroy_write_cache;
nfs_cdata_cachep = kmem_cache_create("nfs_commit_data",
sizeof(struct nfs_commit_data),
0, SLAB_HWCACHE_ALIGN,
NULL);
if (nfs_cdata_cachep == NULL)
- return -ENOMEM;
+ goto out_destroy_write_mempool;
nfs_commit_mempool = mempool_create_slab_pool(MIN_POOL_COMMIT,
nfs_wdata_cachep);
if (nfs_commit_mempool == NULL)
- return -ENOMEM;
+ goto out_destroy_commit_cache;
/*
* NFS congestion size, scale with available memory.
@@ -1841,11 +1841,20 @@ int __init nfs_init_writepagecache(void)
nfs_congestion_kb = 256*1024;
return 0;
+
+out_destroy_commit_cache:
+ kmem_cache_destroy(nfs_cdata_cachep);
+out_destroy_write_mempool:
+ mempool_destroy(nfs_wdata_mempool);
+out_destroy_write_cache:
+ kmem_cache_destroy(nfs_wdata_cachep);
+ return -ENOMEM;
}
void nfs_destroy_writepagecache(void)
{
mempool_destroy(nfs_commit_mempool);
+ kmem_cache_destroy(nfs_cdata_cachep);
mempool_destroy(nfs_wdata_mempool);
kmem_cache_destroy(nfs_wdata_cachep);
}
--
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: bootmem: use phys_addr_t for physical addresses
Hi Tejun, On 9/12/2012 8:34 PM, Tejun Heo wrote: Hello, On Wed, Sep 12, 2012 at 08:08:30PM -0400, Cyril Chemparathy wrote: So, a function which takes phys_addr_t for goal and limit but returns void * doesn't make much sense unless the function creates directly addressable mapping somewhere. On the 32-bit PAE platform in question, physical memory is located outside the 4GB range. Therefore phys_to_virt takes a 64-bit physical address and returns a 32-bit kernel mapped lowmem pointer. Yes but phys_to_virt() can return the vaddr only if the physical address is already mapped in the kernel address space; otherwise, you need one of the kmap*() calls which may not be online early in the boot and consumes either the vmalloc area or fixmaps. bootmem interface can't handle unmapped memory. You probably missed the lowmem bit from my response? This system has all of its memory outside the 4GB physical address space. This includes lowmem, which is permanently mapped into the kernel virtual address space as usual. -- Thanks - Cyril -- 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/
[ 034/108] NFS: return -ENOKEY when the upcall fails to map the name
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Bryan Schumaker
commit 12dfd080556124088ed61a292184947711b46cbe upstream.
This allows the normal error-paths to handle the error, rather than
making a special call to complete_request_key() just for this instance.
Signed-off-by: Bryan Schumaker
Tested-by: William Dauchy
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/idmap.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -763,9 +763,8 @@ idmap_pipe_downcall(struct file *filp, c
}
if (!(im.im_status & IDMAP_STATUS_SUCCESS)) {
- ret = mlen;
- complete_request_key(cons, -ENOKEY);
- goto out_incomplete;
+ ret = -ENOKEY;
+ goto out;
}
namelen_in = strnlen(im.im_name, IDMAP_NAMESZ);
@@ -782,7 +781,6 @@ idmap_pipe_downcall(struct file *filp, c
out:
complete_request_key(cons, ret);
-out_incomplete:
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/
[ 021/108] vfs: canonicalize create mode in build_open_flags()
From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit e68726ff72cf7ba5e7d789857fcd9a75ca573f03 upstream. Userspace can pass weird create mode in open(2) that we canonicalize to "(mode & S_IALLUGO) | S_IFREG" in vfs_create(). The problem is that we use the uncanonicalized mode before calling vfs_create() with unforseen consequences. So do the canonicalization early in build_open_flags(). Signed-off-by: Miklos Szeredi Tested-by: Richard W.M. Jones Signed-off-by: Greg Kroah-Hartman --- fs/open.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/fs/open.c +++ b/fs/open.c @@ -930,9 +930,10 @@ static inline int build_open_flags(int f int lookup_flags = 0; int acc_mode; - if (!(flags & O_CREAT)) - mode = 0; - op->mode = mode; + if (flags & O_CREAT) + op->mode = (mode & S_IALLUGO) | S_IFREG; + else + op->mode = 0; /* Must never be set by userspace */ flags &= ~FMODE_NONOTIFY; -- 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/
[ 033/108] NFS: Clear key construction data if the idmap upcall fails
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Bryan Schumaker
commit c5066945b7ea346a11424dbeb7830b7d7d00c206 upstream.
idmap_pipe_downcall already clears this field if the upcall succeeds,
but if it fails (rpc.idmapd isn't running) the field will still be set
on the next call triggering a BUG_ON(). This patch tries to handle all
possible ways that the upcall could fail and clear the idmap key data
for each one.
Signed-off-by: Bryan Schumaker
Tested-by: William Dauchy
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/idmap.c | 56 ++--
1 file changed, 42 insertions(+), 14 deletions(-)
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -63,6 +63,12 @@ struct idmap {
struct mutexidmap_mutex;
};
+struct idmap_legacy_upcalldata {
+ struct rpc_pipe_msg pipe_msg;
+ struct idmap_msg idmap_msg;
+ struct idmap *idmap;
+};
+
/**
* nfs_fattr_init_names - initialise the nfs_fattr owner_name/group_name fields
* @fattr: fully initialised struct nfs_fattr
@@ -326,6 +332,7 @@ static ssize_t nfs_idmap_get_key(const c
ret = nfs_idmap_request_key(_type_id_resolver_legacy,
name, namelen, type, data,
data_size, idmap);
+ idmap->idmap_key_cons = NULL;
mutex_unlock(>idmap_mutex);
}
return ret;
@@ -383,11 +390,13 @@ static const match_table_t nfs_idmap_tok
static int nfs_idmap_legacy_upcall(struct key_construction *, const char *,
void *);
static ssize_t idmap_pipe_downcall(struct file *, const char __user *,
size_t);
+static void idmap_release_pipe(struct inode *);
static void idmap_pipe_destroy_msg(struct rpc_pipe_msg *);
static const struct rpc_pipe_ops idmap_upcall_ops = {
.upcall = rpc_pipe_generic_upcall,
.downcall = idmap_pipe_downcall,
+ .release_pipe = idmap_release_pipe,
.destroy_msg= idmap_pipe_destroy_msg,
};
@@ -619,7 +628,8 @@ void nfs_idmap_quit(void)
nfs_idmap_quit_keyring();
}
-static int nfs_idmap_prepare_message(char *desc, struct idmap_msg *im,
+static int nfs_idmap_prepare_message(char *desc, struct idmap *idmap,
+struct idmap_msg *im,
struct rpc_pipe_msg *msg)
{
substring_t substr;
@@ -662,6 +672,7 @@ static int nfs_idmap_legacy_upcall(struc
const char *op,
void *aux)
{
+ struct idmap_legacy_upcalldata *data;
struct rpc_pipe_msg *msg;
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
@@ -669,15 +680,15 @@ static int nfs_idmap_legacy_upcall(struc
int ret = -ENOMEM;
/* msg and im are freed in idmap_pipe_destroy_msg */
- msg = kmalloc(sizeof(*msg), GFP_KERNEL);
- if (!msg)
- goto out0;
-
- im = kmalloc(sizeof(*im), GFP_KERNEL);
- if (!im)
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
goto out1;
- ret = nfs_idmap_prepare_message(key->description, im, msg);
+ msg = >pipe_msg;
+ im = >idmap_msg;
+ data->idmap = idmap;
+
+ ret = nfs_idmap_prepare_message(key->description, idmap, im, msg);
if (ret < 0)
goto out2;
@@ -686,15 +697,15 @@ static int nfs_idmap_legacy_upcall(struc
ret = rpc_queue_upcall(idmap->idmap_pipe, msg);
if (ret < 0)
- goto out2;
+ goto out3;
return ret;
+out3:
+ idmap->idmap_key_cons = NULL;
out2:
- kfree(im);
+ kfree(data);
out1:
- kfree(msg);
-out0:
complete_request_key(cons, ret);
return ret;
}
@@ -778,9 +789,26 @@ out_incomplete:
static void
idmap_pipe_destroy_msg(struct rpc_pipe_msg *msg)
{
+ struct idmap_legacy_upcalldata *data = container_of(msg,
+ struct idmap_legacy_upcalldata,
+ pipe_msg);
+ struct idmap *idmap = data->idmap;
+ struct key_construction *cons;
+ if (msg->errno) {
+ cons = ACCESS_ONCE(idmap->idmap_key_cons);
+ idmap->idmap_key_cons = NULL;
+ complete_request_key(cons, msg->errno);
+ }
/* Free memory allocated in nfs_idmap_legacy_upcall() */
- kfree(msg->data);
- kfree(msg);
+ kfree(data);
+}
+
+static void
+idmap_release_pipe(struct inode *inode)
+{
+ struct rpc_inode *rpci = RPC_I(inode);
+ struct idmap *idmap = (struct idmap *)rpci->private;
+ idmap->idmap_key_cons = NULL;
}
int nfs_map_name_to_uid(const struct nfs_server *server, const char *name,
size_t namelen, __u32 *uid)
--
To unsubscribe from this
[ 013/108] ARM: imx6: spin the cpu until hardware takes it down
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Guo
commit c944b0b9354ea06ffb0c8a7178949f1185f9f499 upstream.
Though commit 602bf40 (ARM: imx6: exit coherency when shutting down
a cpu) improves the stability of imx6q cpu hotplug a lot, there are
still hangs seen with a more stressful hotplug testing.
It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
will be taken down by hardware immediately, and the code after that
will not get any chance to execute. However, this is not always the
case from the testing. The cpu could possibly be alive for a few
cycles before hardware actually takes it down. So rather than letting
cpu execute some code that could cause a hang in these cycles, let's
make the cpu spin there and wait for hardware to take it down.
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-imx/hotplug.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -42,22 +42,6 @@ static inline void cpu_enter_lowpower(vo
: "cc");
}
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mrcp15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
/*
* platform-specific code to shutdown a CPU
*
@@ -67,11 +51,10 @@ void platform_cpu_die(unsigned int cpu)
{
cpu_enter_lowpower();
imx_enable_cpu(cpu, false);
- cpu_do_idle();
- cpu_leave_lowpower();
- /* We should never return from idle */
- panic("cpu %d unexpectedly exit from shutdown\n", cpu);
+ /* spin here until hardware takes it down */
+ while (1)
+ ;
}
int platform_cpu_disable(unsigned int cpu)
--
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/
[ 014/108] ARM: imx: build pm-imx5 code only when PM is enabled
From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit a28eecef8ac2671dce7d892165bf374eeaa04e15 upstream. This moves the imx5 pm code out of the list of unconditionally compiled files for imx5, mirroring what we already do for imx6 and how it was done before the code was move from mach-mx5 to mach-imx in v3.3. Without this patch, building with CONFIG_PM disabled results in: arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init' arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init' arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Signed-off-by: Greg Kroah-Hartman --- arch/arm/mach-imx/Makefile |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -9,7 +9,8 @@ obj-$(CONFIG_SOC_IMX27) += clk-imx27.o m obj-$(CONFIG_SOC_IMX31) += mm-imx3.o cpu-imx31.o clk-imx31.o iomux-imx31.o ehci-imx31.o pm-imx3.o obj-$(CONFIG_SOC_IMX35) += mm-imx3.o cpu-imx35.o clk-imx35.o ehci-imx35.o pm-imx3.o -obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o pm-imx5.o cpu_op-mx51.o +imx5-pm-$(CONFIG_PM) += pm-imx5.o +obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(imx5-pm-y) cpu_op-mx51.o obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \ clk-pfd.o clk-busy.o -- 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/
[ 022/108] alpha: fix fpu.h usage in userspace
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Frysinger
commit 0be421862b857e61964435ffcaa7499cf77a5e5a upstream.
After commit ec2212088c42 ("Disintegrate asm/system.h for Alpha"), the
fpu.h header which we install for userland started depending on
special_insns.h which is not installed.
However, fpu.h only uses that for __KERNEL__ code, so protect the
inclusion the same way to avoid build breakage in glibc:
/usr/include/asm/fpu.h:4:31: fatal error: asm/special_insns.h: No such file
or directory
Reported-by: Matt Turner
Signed-off-by: Mike Frysinger
Signed-off-by: Michael Cree
Acked-by: Matt Turner
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/alpha/include/asm/fpu.h |2 ++
1 file changed, 2 insertions(+)
--- a/arch/alpha/include/asm/fpu.h
+++ b/arch/alpha/include/asm/fpu.h
@@ -1,7 +1,9 @@
#ifndef __ASM_ALPHA_FPU_H
#define __ASM_ALPHA_FPU_H
+#ifdef __KERNEL__
#include
+#endif
/*
* Alpha floating-point control register defines:
--
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/
[ 025/108] mm: hugetlbfs: correctly populate shared pmd
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Michal Hocko
commit eb48c071464757414538c68a6033c8f8c15196f8 upstream.
Each page mapped in a process's address space must be correctly
accounted for in _mapcount. Normally the rules for this are
straightforward but hugetlbfs page table sharing is different. The page
table pages at the PMD level are reference counted while the mapcount
remains the same.
If this accounting is wrong, it causes bugs like this one reported by
Larry Woodman:
kernel BUG at mm/filemap.c:135!
invalid opcode: [#1] SMP
CPU 22
Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr
acpi_pad acpi]
Pid: 18001, comm: mpitest Tainted: GW3.3.0+ #4 Dell Inc.
PowerEdge R620/07NDJ2
RIP: 0010:[] []
__delete_from_page_cache+0x15d/0x170
Process mpitest (pid: 18001, threadinfo 880428972000, task
880428b5cc20)
Call Trace:
delete_from_page_cache+0x40/0x80
truncate_hugepages+0x115/0x1f0
hugetlbfs_evict_inode+0x18/0x30
evict+0x9f/0x1b0
iput_final+0xe3/0x1e0
iput+0x3e/0x50
d_kill+0xf8/0x110
dput+0xe2/0x1b0
__fput+0x162/0x240
During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc()
shared page tables with the check dst_pte == src_pte. The logic is if
the PMD page is the same, they must be shared. This assumes that the
sharing is between the parent and child. However, if the sharing is
with a different process entirely then this check fails as in this
diagram:
parent
|
>pmd
src_pte--> data page
^
other->pmd|
^
child---|
dst_pte
For this situation to occur, it must be possible for Parent and Other to
have faulted and failed to share page tables with each other. This is
possible due to the following style of race.
PROC A PROC B
copy_hugetlb_page_range copy_hugetlb_page_range
src_pte == huge_pte_offset src_pte == huge_pte_offset
!src_pte so no sharing !src_pte so no sharing
(time passes)
hugetlb_fault hugetlb_fault
huge_pte_alloc huge_pte_alloc
huge_pmd_share huge_pmd_share
LOCK(i_mmap_mutex)
find nothing, no sharing
UNLOCK(i_mmap_mutex)
LOCK(i_mmap_mutex)
find nothing, no sharing
UNLOCK(i_mmap_mutex)
pmd_alloc pmd_alloc
LOCK(instantiation_mutex)
fault
UNLOCK(instantiation_mutex)
LOCK(instantiation_mutex)
fault
UNLOCK(instantiation_mutex)
These two processes are not poing to the same data page but are not
sharing page tables because the opportunity was missed. When either
process later forks, the src_pte == dst pte is potentially insufficient.
As the check falls through, the wrong PTE information is copied in
(harmless but wrong) and the mapcount is bumped for a page mapped by a
shared page table leading to the BUG_ON.
This patch addresses the issue by moving pmd_alloc into huge_pmd_share
which guarantees that the shared pud is populated in the same critical
section as pmd. This also means that huge_pte_offset test in
huge_pmd_share is serialized correctly now which in turn means that the
success of the sharing will be higher as the racing tasks see the pud
and pmd populated together.
Race identified and changelog written mostly by Mel Gorman.
{a...@linux-foundation.org: attempt to make the huge_pmd_share() comment
comprehensible, clean up coding style]
Reported-by: Larry Woodman
Tested-by: Larry Woodman
Reviewed-by: Mel Gorman
Signed-off-by: Michal Hocko
Reviewed-by: Rik van Riel
Cc: David Gibson
Cc: Ken Chen
Cc: Cong Wang
Cc: Hillf Danton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/hugetlbpage.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -56,9 +56,16 @@ static int vma_shareable(struct vm_area_
}
/*
- * search for a shareable pmd page for hugetlb.
+ * Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
+ * and returns the corresponding pte. While this is not necessary for the
+ * !shared pmd case because we can allocate the pmd later as well, it makes the
+ * code much cleaner. pmd allocation is essential for the
[ 026/108] ALSA: hda - dont create dysfunctional mixer controls for ca0132
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: David Henningsson
commit c41999a23929f30808bae6009d8065052d4d73fd upstream.
It's possible that these amps are settable somehow, e g through
secret codec verbs, but for now, don't create the controls (as
they won't be working anyway, and cause errors in amixer).
BugLink: https://bugs.launchpad.net/bugs/1038651
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_ca0132.c |8
1 file changed, 8 insertions(+)
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -275,6 +275,10 @@ static int _add_switch(struct hda_codec
int type = dir ? HDA_INPUT : HDA_OUTPUT;
struct snd_kcontrol_new knew =
HDA_CODEC_MUTE_MONO(namestr, nid, chan, 0, type);
+ if ((query_amp_caps(codec, nid, type) & AC_AMPCAP_MUTE) == 0) {
+ snd_printdd("Skipping '%s %s Switch' (no mute on node 0x%x)\n",
pfx, dirstr[dir], nid);
+ return 0;
+ }
sprintf(namestr, "%s %s Switch", pfx, dirstr[dir]);
return snd_hda_ctl_add(codec, nid, snd_ctl_new1(, codec));
}
@@ -286,6 +290,10 @@ static int _add_volume(struct hda_codec
int type = dir ? HDA_INPUT : HDA_OUTPUT;
struct snd_kcontrol_new knew =
HDA_CODEC_VOLUME_MONO(namestr, nid, chan, 0, type);
+ if ((query_amp_caps(codec, nid, type) & AC_AMPCAP_NUM_STEPS) == 0) {
+ snd_printdd("Skipping '%s %s Volume' (no amp on node 0x%x)\n",
pfx, dirstr[dir], nid);
+ return 0;
+ }
sprintf(namestr, "%s %s Volume", pfx, dirstr[dir]);
return snd_hda_ctl_add(codec, nid, snd_ctl_new1(, codec));
}
--
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/
mmotm 2012-09-12-17-36 uploaded
The mm-of-the-moment snapshot 2012-09-12-17-36 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at https://github.com/mstsxfx/memcg-devel.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.cmpxchg.org/linux-mmotm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.6-rc5: (patches marked "*" will be included in linux-next) origin.patch * memory-hotplug-reset-pgdat-kswapd-to-null-if-creating-kernel-thread-fails.patch * mm-ia64-fix-a-memory-block-size-bug.patch * maintainers-fix-txt-maintainer-list-and-source-repo-path.patch * nbd-clear-waiting_queue-on-shutdown.patch * slab-do-clearslabpfmemalloc-for-all-pages-of-slab.patch * slab-fix-starting-index-for-finding-another-object.patch * slub-consider-pfmemalloc_match-in-get_partial_node.patch * include-net-sockh-squelch-compiler-warning-in-sk_rmem_schedule.patch * pid-namespace-limit-value-of-ns_last_pid-to-0-max_pid.patch * compilerh-add-__visible.patch * idr-rename-max_level-to-max_idr_level.patch * idr-rename-max_level-to-max_idr_level-fix.patch * idr-rename-max_level-to-max_idr_level-fix-fix-2.patch linux-next.patch i-need-old-gcc.patch idr-rename-max_level-to-max_idr_level-fix-3.patch arch-alpha-kernel-systblss-remove-debug-check.patch * cris-fix-i-o-macros.patch * drivers-scsi-iprc-missing-unlock-before-a-return.patch * selinux-fix-sel_netnode_insert-suspicious-rcu-dereference.patch * vfs-d_obtain_alias-needs-to-use-as-default-name.patch * cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch * acpi_memhotplugc-fix-memory-leak-when-memory-device-is-unbound-from-the-module-acpi_memhotplug.patch * acpi_memhotplugc-free-memory-device-if-acpi_memory_enable_device-failed.patch * acpi_memhotplugc-remove-memory-info-from-list-before-freeing-it.patch * acpi_memhotplugc-dont-allow-to-eject-the-memory-device-if-it-is-being-used.patch * acpi_memhotplugc-bind-the-memory-device-when-the-driver-is-being-loaded.patch * acpi_memhotplugc-auto-bind-the-memory-device-which-is-hotplugged-before-the-driver-is-loaded.patch * arch-x86-platform-iris-irisc-register-a-platform-device-and-a-platform-driver.patch * x86-mm-initc-devmem_is_allowed-off-by-one.patch * x86-numa-dont-check-if-node-is-numa_no_node.patch * serial-imx-fix-imx-uart-macro-usage-to-reflect-correct.patch * audith-replace-defines-with-c-stubs.patch * mn10300-only-add-mmem-funcs-to-kbuild_cflags-if-gcc-supports-it.patch * dma-dmaengine-lower-the-priority-of-failed-to-get-dma-channel-message.patch * pcmcia-move-unbind-rebind-into-dev_pm_opscomplete.patch * drm-i915-optimize-div_round_closest-call.patch cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch * timeconstpl-remove-deprecated-defined-array.patch * time-dont-inline-export_symbol-functions.patch * checksyscalls-fix-here-document-handling.patch * kbuild-make-fix-if_changed-when-command-contains-backslashes.patch * h8300-select-generic-atomic64_t-support.patch *
[PATCH v2 0/3] TSC trace_clock
Updated to move arch-specific bits out of generic code. I did this by adding a new file in asm-generic because I couldn't think of a better place to put it, but I'm open to suggestions. David Sharp (3): tracing,x86: add a TSC trace_clock tracing: reset ring buffer when changing trace_clocks tracing: format non-nanosec times from tsc clock without a decimal point. arch/x86/include/asm/trace_clock.h | 16 +++ arch/x86/kernel/Makefile |1 + arch/x86/kernel/trace_clock.c | 20 + include/asm-generic/trace_clock.h | 15 +++ include/linux/ftrace_event.h |6 +++ include/linux/trace_clock.h|2 + kernel/trace/trace.c | 24 +- kernel/trace/trace.h |4 -- kernel/trace/trace_output.c| 82 +--- 9 files changed, 138 insertions(+), 32 deletions(-) create mode 100644 arch/x86/include/asm/trace_clock.h create mode 100644 arch/x86/kernel/trace_clock.c create mode 100644 include/asm-generic/trace_clock.h -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.
With the addition of the "tsc" clock, formatting timestamps to look like
fractional seconds is misleading. Mark clocks as either in nanoseconds or
not, and format non-nanosecond timestamps as decimal integers.
Tested:
$ cd /sys/kernel/debug/tracing/
$ cat trace_clock
[local] global tsc
$ echo sched_switch > set_event
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ cat trace
-0 [000] 6330.52: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964
next_prio=120
sleep-29964 [000] 6330.555628: sched_switch: prev_comm=bash
prev_pid=29964 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
$ echo 1 > options/latency-format
$ cat trace
-0 0 4104553247us+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964 next_prio=120
sleep-29964 0 4104553322us+: sched_switch: prev_comm=bash prev_pid=29964
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
$ echo tsc > trace_clock
$ cat trace
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ echo 0 > options/latency-format
$ cat trace
-0 [000] 16490053398357: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128
next_prio=120
sleep-31128 [000] 16490053588518: sched_switch: prev_comm=bash
prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
echo 1 > options/latency-format
$ cat trace
-0 0 91557653238+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128 next_prio=120
sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
v2:
Move arch-specific bits out of generic code.
Google-Bug-Id: 6980623
---
arch/x86/include/asm/trace_clock.h |2 +-
include/linux/ftrace_event.h |6 +++
kernel/trace/trace.c | 15 +-
kernel/trace/trace.h |4 --
kernel/trace/trace_output.c| 82 +---
5 files changed, 76 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/trace_clock.h
b/arch/x86/include/asm/trace_clock.h
index 0b1f391..4af2eb7 100644
--- a/arch/x86/include/asm/trace_clock.h
+++ b/arch/x86/include/asm/trace_clock.h
@@ -9,7 +9,7 @@
extern u64 notrace trace_clock_x86_tsc(void);
# define ARCH_TRACE_CLOCKS \
- { trace_clock_x86_tsc, "tsc" },
+ { trace_clock_x86_tsc, "tsc", .in_ns = 0 },
#endif
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 642928c..c760670 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -86,6 +86,12 @@ struct trace_iterator {
cpumask_var_t started;
};
+enum trace_iter_flags {
+ TRACE_FILE_LAT_FMT = 1,
+ TRACE_FILE_ANNOTATE = 2,
+ TRACE_FILE_TIME_IN_NS = 4,
+};
+
struct trace_event;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 4e26df3..3fe4c5b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -476,10 +476,11 @@ static const char *trace_options[] = {
static struct {
u64 (*func)(void);
const char *name;
+ int in_ns; /* is this clock in nanoseconds? */
} trace_clocks[] = {
- { trace_clock_local,"local" },
- { trace_clock_global, "global" },
- { trace_clock_counter, "counter" },
+ { trace_clock_local,"local",1 },
+ { trace_clock_global, "global", 1 },
+ { trace_clock_counter, "counter", 0 },
ARCH_TRACE_CLOCKS
};
@@ -2425,6 +2426,10 @@ __tracing_open(struct inode *inode, struct file *file)
if (ring_buffer_overruns(iter->tr->buffer))
iter->iter_flags |= TRACE_FILE_ANNOTATE;
+ /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+ if (trace_clocks[trace_clock_id].in_ns)
+ iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
/* stop the trace while dumping */
tracing_stop();
@@ -3324,6 +3329,10 @@ static int tracing_open_pipe(struct inode *inode, struct
file *filp)
if (trace_flags & TRACE_ITER_LATENCY_FMT)
iter->iter_flags |= TRACE_FILE_LAT_FMT;
+ /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+ if (trace_clocks[trace_clock_id].in_ns)
+ iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
iter->cpu_file = cpu_file;
iter->tr = _trace;
mutex_init(>mutex);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 55e1f7f..84fefed 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -409,10 +409,6 @@ void tracing_start_sched_switch_record(void);
int register_tracer(struct tracer *type);
[PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change
In order to promote interoperability between userspace tracers and ftrace,
add a trace_clock that reports raw TSC values which will then be recorded
in the ring buffer. Userspace tracers that also record TSCs are then on
exactly the same time base as the kernel and events can be unambiguously
interlaced.
Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
timestamp values.
Google-Bug-Id: 6980623
Signed-off-by: David Sharp
---
include/linux/trace_clock.h |3 +++
kernel/trace/trace.c|3 +++
kernel/trace/trace_clock.c | 16
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
index 4eb4902..b86c7363 100644
--- a/include/linux/trace_clock.h
+++ b/include/linux/trace_clock.h
@@ -16,5 +16,8 @@ extern u64 notrace trace_clock_local(void);
extern u64 notrace trace_clock(void);
extern u64 notrace trace_clock_global(void);
extern u64 notrace trace_clock_counter(void);
+#ifdef CONFIG_X86_TSC
+extern u64 notrace trace_clock_tsc(void);
+#endif
#endif /* _LINUX_TRACE_CLOCK_H */
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5c38c81..dc1f1fa 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -480,6 +480,9 @@ static struct {
{ trace_clock_local,"local" },
{ trace_clock_global, "global" },
{ trace_clock_counter, "counter" },
+#ifdef CONFIG_X86_TSC
+ { trace_clock_tsc, "tsc" },
+#endif
};
int trace_clock_id;
diff --git a/kernel/trace/trace_clock.c b/kernel/trace/trace_clock.c
index 3947835..1770737 100644
--- a/kernel/trace/trace_clock.c
+++ b/kernel/trace/trace_clock.c
@@ -125,3 +125,19 @@ u64 notrace trace_clock_counter(void)
{
return atomic64_add_return(1, _counter);
}
+
+#ifdef CONFIG_X86_TSC
+/*
+ * trace_clock_tsc(): A clock that is just the cycle counter.
+ *
+ * Unlike the other clocks, this is not in nanoseconds.
+ */
+u64 notrace trace_clock_tsc(void)
+{
+ u64 ret;
+ rdtsc_barrier();
+ rdtscll(ret);
+
+ return ret;
+}
+#endif
--
1.7.7.3
--
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/
