[PATCH] net: brcm80211: Delete an unnecessary check before the function call "release_firmware"
From: Markus Elfring Date: Fri, 6 Nov 2015 08:48:23 +0100 The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c index 4248f3c..33afb9a 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c @@ -449,8 +449,7 @@ static void brcmf_fw_request_nvram_done(const struct firmware *fw, void *ctx) if (raw_nvram) bcm47xx_nvram_release_contents(data); - if (fw) - release_firmware(fw); + release_firmware(fw); if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) goto fail; -- 2.6.2 -- 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 4/7] PCI/ACPI: Add interface acpi_pci_root_create()
On 2015/11/6 2:19, Lorenzo Pieralisi wrote:
> On Thu, Nov 05, 2015 at 03:21:34PM +0100, Tomasz Nowicki wrote:
>> On 14.10.2015 08:29, Jiang Liu wrote:
>
> [...]
>
>>> +static void acpi_pci_root_validate_resources(struct device *dev,
>>> +struct list_head *resources,
>>> +unsigned long type)
>>> +{
>>> + LIST_HEAD(list);
>>> + struct resource *res1, *res2, *root = NULL;
>>> + struct resource_entry *tmp, *entry, *entry2;
>>> +
>>> + BUG_ON((type & (IORESOURCE_MEM | IORESOURCE_IO)) == 0);
>>> + root = (type & IORESOURCE_MEM) ? _resource : _resource;
>>> +
>>> + list_splice_init(resources, );
>>> + resource_list_for_each_entry_safe(entry, tmp, ) {
>>> + bool free = false;
>>> + resource_size_t end;
>>> +
>>> + res1 = entry->res;
>>> + if (!(res1->flags & type))
>>> + goto next;
>>> +
>>> + /* Exclude non-addressable range or non-addressable portion */
>>> + end = min(res1->end, root->end);
>>> + if (end <= res1->start) {
>>> + dev_info(dev, "host bridge window %pR (ignored, not CPU
>>> addressable)\n",
>>> +res1);
>>> + free = true;
>>> + goto next;
>>> + } else if (res1->end != end) {
>>> + dev_info(dev, "host bridge window %pR ([%#llx-%#llx]
>>> ignored, not CPU addressable)\n",
>>> +res1, (unsigned long long)end + 1,
>>> +(unsigned long long)res1->end);
>>> + res1->end = end;
>>> + }
>>> +
>>> + resource_list_for_each_entry(entry2, resources) {
>>> + res2 = entry2->res;
>>> + if (!(res2->flags & type))
>>> + continue;
>>> +
>>> + /*
>>> +* I don't like throwing away windows because then
>>> +* our resources no longer match the ACPI _CRS, but
>>> +* the kernel resource tree doesn't allow overlaps.
>>> +*/
>>> + if (resource_overlaps(res1, res2)) {
>>> + res2->start = min(res1->start, res2->start);
>>> + res2->end = max(res1->end, res2->end);
>>> + dev_info(dev, "host bridge window expanded to
>>> %pR; %pR ignored\n",
>>> +res2, res1);
>>> + free = true;
>>> + goto next;
>>> + }
>>> + }
>>> +
>>> +next:
>>> + resource_list_del(entry);
>>> + if (free)
>>> + resource_list_free_entry(entry);
>>> + else
>>> + resource_list_add_tail(entry, resources);
>>> + }
>>> +}
>>> +
>>> +int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
>>> +{
>>> + int ret;
>>> + struct list_head *list = >resources;
>>> + struct acpi_device *device = info->bridge;
>>> + struct resource_entry *entry, *tmp;
>>> + unsigned long flags;
>>> +
>>> + flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_MEM_8AND16BIT;
>>> + ret = acpi_dev_get_resources(device, list,
>>> +acpi_dev_filter_resource_type_cb,
>>> +(void *)flags);
>>> + if (ret < 0)
>>> + dev_warn(>dev,
>>> +"failed to parse _CRS method, error code %d\n", ret);
>>> + else if (ret == 0)
>>> + dev_dbg(>dev,
>>> + "no IO and memory resources present in _CRS\n");
>>> + else {
>>> + resource_list_for_each_entry_safe(entry, tmp, list) {
>>> + if (entry->res->flags & IORESOURCE_DISABLED)
>>> + resource_list_destroy_entry(entry);
>>> + else
>>> + entry->res->name = info->name;
>>> + }
>>> + acpi_pci_root_validate_resources(>dev, list,
>>> +IORESOURCE_MEM);
>>> + acpi_pci_root_validate_resources(>dev, list,
>>> +IORESOURCE_IO);
>>
>> It is not clear to me why we need these two calls above ^^^. We are
>> using pci_acpi_root_add_resources(info) later. Is it not enough?
>>
>> Also, I cannot use acpi_pci_probe_root_resources() in my ARM64 PCI
>> driver. It is because acpi_dev_get_resources is adding
>> translation_offset to IO ranges start address and then:
>> acpi_pci_root_validate_resources(>dev, list,
>> IORESOURCE_IO);
>> rejects that IO regions as it is out of my 0x0-SZ_16M window.
>>
>> Does acpi_pci_probe_root_resources meant to be x86 specific and I
>> should avoid using it?
>
> IIUC, you _have_ to have the proper translation_offset to map the bridge
> window into the IO address
Re: [PATCH 0/2] [media] c8sectpfe: Deletion of a few unnecessary checks
Hi Markus, On 11/05/2015 07:45 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Thu, 5 Nov 2015 19:39:32 +0100 Another update suggestion was taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete unnecessary checks before two function calls Combine three checks into a single if block drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) For the series: Acked-by: Maxime Coquelin Thanks! Maxime -- 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 4/7] PCI/ACPI: Add interface acpi_pci_root_create()
On 2015/11/5 22:21, Tomasz Nowicki wrote:
> On 14.10.2015 08:29, Jiang Liu wrote:
>> Introduce common interface acpi_pci_root_create() and related data
>> structures to create PCI root bus for ACPI PCI host bridges. It will
>> be used to kill duplicated arch specific code for IA64 and x86. It may
>> also help ARM64 in future.
>>
>> Reviewed-by: Lorenzo Pieralisi
>> Tested-by: Tony Luck
>> Signed-off-by: Jiang Liu
>> Signed-off-by: Liu Jiang
>> ---
>> drivers/acpi/pci_root.c | 204
>> ++
>> include/linux/pci-acpi.h | 24 ++
>> 2 files changed, 228 insertions(+)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index 393706a5261b..850d7bf0c873 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -652,6 +652,210 @@ static void acpi_pci_root_remove(struct
>> acpi_device *device)
>> kfree(root);
>> }
>>
>> +/*
>> + * Following code to support acpi_pci_root_create() is copied from
>> + * arch/x86/pci/acpi.c and modified so it could be reused by x86, IA64
>> + * and ARM64.
>> + */
>> +static void acpi_pci_root_validate_resources(struct device *dev,
>> + struct list_head *resources,
>> + unsigned long type)
>> +{
>> +LIST_HEAD(list);
>> +struct resource *res1, *res2, *root = NULL;
>> +struct resource_entry *tmp, *entry, *entry2;
>> +
>> +BUG_ON((type & (IORESOURCE_MEM | IORESOURCE_IO)) == 0);
>> +root = (type & IORESOURCE_MEM) ? _resource : _resource;
>> +
>> +list_splice_init(resources, );
>> +resource_list_for_each_entry_safe(entry, tmp, ) {
>> +bool free = false;
>> +resource_size_t end;
>> +
>> +res1 = entry->res;
>> +if (!(res1->flags & type))
>> +goto next;
>> +
>> +/* Exclude non-addressable range or non-addressable portion */
>> +end = min(res1->end, root->end);
>> +if (end <= res1->start) {
>> +dev_info(dev, "host bridge window %pR (ignored, not CPU
>> addressable)\n",
>> + res1);
>> +free = true;
>> +goto next;
>> +} else if (res1->end != end) {
>> +dev_info(dev, "host bridge window %pR ([%#llx-%#llx]
>> ignored, not CPU addressable)\n",
>> + res1, (unsigned long long)end + 1,
>> + (unsigned long long)res1->end);
>> +res1->end = end;
>> +}
>> +
>> +resource_list_for_each_entry(entry2, resources) {
>> +res2 = entry2->res;
>> +if (!(res2->flags & type))
>> +continue;
>> +
>> +/*
>> + * I don't like throwing away windows because then
>> + * our resources no longer match the ACPI _CRS, but
>> + * the kernel resource tree doesn't allow overlaps.
>> + */
>> +if (resource_overlaps(res1, res2)) {
>> +res2->start = min(res1->start, res2->start);
>> +res2->end = max(res1->end, res2->end);
>> +dev_info(dev, "host bridge window expanded to %pR;
>> %pR ignored\n",
>> + res2, res1);
>> +free = true;
>> +goto next;
>> +}
>> +}
>> +
>> +next:
>> +resource_list_del(entry);
>> +if (free)
>> +resource_list_free_entry(entry);
>> +else
>> +resource_list_add_tail(entry, resources);
>> +}
>> +}
>> +
>> +int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
>> +{
>> +int ret;
>> +struct list_head *list = >resources;
>> +struct acpi_device *device = info->bridge;
>> +struct resource_entry *entry, *tmp;
>> +unsigned long flags;
>> +
>> +flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_MEM_8AND16BIT;
>> +ret = acpi_dev_get_resources(device, list,
>> + acpi_dev_filter_resource_type_cb,
>> + (void *)flags);
>> +if (ret < 0)
>> +dev_warn(>dev,
>> + "failed to parse _CRS method, error code %d\n", ret);
>> +else if (ret == 0)
>> +dev_dbg(>dev,
>> +"no IO and memory resources present in _CRS\n");
>> +else {
>> +resource_list_for_each_entry_safe(entry, tmp, list) {
>> +if (entry->res->flags & IORESOURCE_DISABLED)
>> +resource_list_destroy_entry(entry);
>> +else
>> +entry->res->name = info->name;
>> +}
>> +acpi_pci_root_validate_resources(>dev, list,
>> + IORESOURCE_MEM);
>> +acpi_pci_root_validate_resources(>dev, list,
>> + IORESOURCE_IO);
>
> It is not clear to me why we need these two calls above ^^^. We are
> using pci_acpi_root_add_resources(info) later. Is it not enough?
Hi Tomasz,
acpi_pci_root_validate_resources() will try adjust (or fix)
conflicting resources among all resources of the PCI
Re: [PATCH v10 1/5] configfs: Allow dynamic group creation
Is this going into 4.4 through the iio tree? If not is there any chance to get it in through some other tree? While we're not past the merge window is trivial new functionality that doesn't change code, and I'd like to move existing configfs users over to it ASAP, so getting it into a baseline tree ASAP would be immensely helpful. Oh, and: Reviewed-by: Christoph Hellwig (I though we already had that, but oh well) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr
On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote: > Peter Zijlstra [pet...@infradead.org] wrote: > | On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote: > | > Second patch updates struct arch_misc_reg for arch/powerpc with pmu > registers > | > and adds offsetof macro for the same. It extends perf_reg_value() > | > to use reg idx to decide on struct to return value from. > | > | Why; what's in those regs? > > Those are PMU control registers/counters (in Patch 2) that are of > interest only in the context of a PMU interrupt and not relevant > to ptrace itself. Yes. Thats right. > Could we add those registers to 'struct pt_regs' anyway? I would prefer not to. Since as you mentioned, these are not relevant to ptrace. Currently patch 2, adds only few pmu registers, but would like to include more. > We do have 'struct perf_regs' but that seems to be arch nuetral. > If architectures could override that, maybe we could add these > new registers there without touching 'struct pt_regs'. Exactly, idea here is to capture more data using perf_sample_reg_intr without extending pt_regs structure. Maddy > Even so, lot of perf code depends on 'struct pt_regs'. > > Sukadev -- 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] I2C: designware: fix IO timeout issue for AMD controller
On Fri, Nov 06, 2015 at 04:34:19AM +, Yu, Xiangliang wrote:
> > -Original Message-
> > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > Sent: Thursday, November 05, 2015 9:52 PM
> > To: Yu, Xiangliang
> > Cc: andriy.shevche...@linux.intel.com; jarkko.nik...@linux.intel.com;
> > w...@the-dreams.de; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Xue, Ken; Wan, Vincent; Huang, Ray; Wang, Annie;
> > Li, Tony
> > Subject: Re: [PATCH 1/1] I2C: designware: fix IO timeout issue for AMD
> > controller
> >
> > On Thu, Nov 05, 2015 at 08:34:44PM +0800, Xiangliang Yu wrote:
> > > Because of some hardware limitation, AMD I2C controller can't trigger
> > > next interrupt if interrupt status has been changed after clearing
> > > interrupt status bits. Then, I2C will lost interrupt and IO timeout.
> > >
> > > According to hardware design, this patch implements a workaround to
> > > disable i2c controller interrupt after clearing interrupt bits when
> > > entering ISR and to enable i2c interrupt before exiting ISR.
> > >
> > > To reduce the performance impacts on other vendors, use unlikely
> > > function to check flag in ISR.
> > >
> > > Signed-off-by: Xiangliang Yu
> > > ---
> > > drivers/i2c/busses/i2c-designware-core.c| 6 ++
> > > drivers/i2c/busses/i2c-designware-core.h| 1 +
> > > drivers/i2c/busses/i2c-designware-platdrv.c | 4
> > > 3 files changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-designware-core.c
> > > b/drivers/i2c/busses/i2c-designware-core.c
> > > index 7441cdc..04e7b65 100644
> > > --- a/drivers/i2c/busses/i2c-designware-core.c
> > > +++ b/drivers/i2c/busses/i2c-designware-core.c
> > > @@ -783,6 +783,9 @@ irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
> > >
> > > stat = i2c_dw_read_clear_intrbits(dev);
> >
> > What if the status changes right here, before you go and mask the interrupt?
> Have no effect, because i2c controller can't trigger next interrupt.
>
> >
> > >
> > > + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> > > + i2c_dw_disable_int(dev);
> > > +
> > > if (stat & DW_IC_INTR_TX_ABRT) {
> > > dev->cmd_err |= DW_IC_ERR_TX_ABRT;
> > > dev->status = STATUS_IDLE;
> > > @@ -811,6 +814,9 @@ tx_aborted:
> > > if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) ||
> > dev->msg_err)
> > > complete(>cmd_complete);
> > >
> > > + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> > > + dw_writel(dev, DW_IC_INTR_DEFAULT_MASK,
> > DW_IC_INTR_MASK);
> >
> > The driver disables TX interrupt when it is not needed anymore or when TX
> > gets aborted but the above will re-enable all interrupts regardless.
> > Is that the intention?
> No, i2c controller can trigger next interrupt only after re-enable all
> interrupt.
If you get an error the function masks all interrupts and jumps to
tx_aborted label. With this patch you unmask all interrupts again before
exiting the function.
> >
> > > +
> > > return IRQ_HANDLED;
> > > }
> > > EXPORT_SYMBOL_GPL(i2c_dw_isr);
> > > diff --git a/drivers/i2c/busses/i2c-designware-core.h
> > > b/drivers/i2c/busses/i2c-designware-core.h
> > > index 9630222..808ef6a 100644
> > > --- a/drivers/i2c/busses/i2c-designware-core.h
> > > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > > @@ -111,6 +111,7 @@ struct dw_i2c_dev {
> > >
> > > #define ACCESS_SWAP 0x0001
> > > #define ACCESS_16BIT 0x0002
> > > +#define ACCESS_INTR_MASK 0x0004
> > >
> > > extern u32 dw_readl(struct dw_i2c_dev *dev, int offset); extern void
> > > dw_writel(struct dw_i2c_dev *dev, u32 b, int offset); diff --git
> > > a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > index 472b882..0c59357 100644
> > > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > @@ -251,6 +251,10 @@ static int dw_i2c_probe(struct platform_device
> > *pdev)
> > > dev->rx_fifo_depth = ((param1 >> 8) & 0xff) + 1;
> > > dev->adapter.nr = pdev->id;
> > > }
> > > +
> > > + if (!strncmp(pdev->name, "AMD0010", 7))
> > > + dev->accessor_flags |= ACCESS_INTR_MASK;
> > > +
> >
> > Can't you put this to ->driver_data? For example it could refer to a
> > configuration structure that then contains quirk flags.
> I think it will need to add a function to support it, but the function
> Is rarely used. It will easy to add if i2c driver has quirk mechanisms.
> Added code is very simple and have no influence on others.
What if the next AMD I2C controller needs another quirk, and then
another?
I would rather pass flags or similar (reference to config structure
including flags) with ->driver_data.
>
> >
> > > r = i2c_dw_init(dev);
> > > if (r)
> > > return r;
> > > --
> > > 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection
On Thu, Nov 05, 2015 at 03:36:25PM -0800, Jacob Pan wrote: > I did some testing with the code below, it shows random > [ 150.442597] NOHZ: local_softirq_pending 02 > [ 153.032673] NOHZ: local_softirq_pending 202 > [ 153.203785] NOHZ: local_softirq_pending 202 > [ 153.206486] NOHZ: local_softirq_pending 282 > I recalled that was why i checked for local_softirq_pending in the > initial patch, still trying to find out how we can avoid that. These > also causes non stop sched ticks in the inner idle loop. Check the softirq stuff before calling throttle ? -- 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 PULL] x86/mm changes for v4.4
(resent with Matt's email address fixed.) * Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones wrote: > > > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote: > > > > > > > > I don't have that later debug output at all. Presumably some config > > > difference. > > > > > > CONFIG_X86_PTDUMP_CORE iirc. > > > > No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead. > > > > Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should > > not default to 'y' unless it is made more useful if it actually > > triggers. Ingo? > > Yeah, agreed absolutely. > > So this is a bit sad because RWX pages are a real problem in practice, > especially > since the EFI addresses are well predictable, but generating a warning > without > being able to fix it quickly is counterproductive as well, as it only annoys > people and makes them turn off the option. (Which we could do as well to > begin > with, without the annoyance factor...) > > So the plan would be: > > 1) Make it default-n. > > 2) We should try to further improve the messages to make it easier to > determine > what's wrong. We _do_ try to output symbolic information in the warning, > to > make it easier to find buggy mappings, but these are not standard kernel > mappings. So I think we need an e820 mappings based semi-symbolic > printout of > bad addresses - maybe even correlate it with the MMIO resource tree. > > 3) We should fix the EFI permission problem without relying on the firmware: > it > appears we could just mark everything R-X optimistically, and if a write > fault > happens (it's pretty rare in fact, only triggers when we write to an EFI > variable and so), we can mark the faulting page RW- on the fly, because > it > appears that writable EFI sections, while not enumerated very well in > 'old' > firmware, are still supposed to be page granular. (Even 'new' firmware I > wouldn't automatically trust to get the enumeration right...) > > If that 'supposed to be' turns out to be 'not true' (not unheard of in > firmware land), then plan B would be to mark pages that generate write > faults > RWX as well, to not break functionality. (This 'mark it RWX' is not > something > that exploits would have easy access to, and we could also generate a > warning > [after the EFI call has finished] if it ever triggers.) > > Admittedly this approach might not be without its own complications, but > it > looks reasonably simple (I don't think we need per EFI call page tables, > etc.), and does not assume much about the firmware being able to > enumerate its > permissions properly. Were we to merge EFI support today I'd have > insisted on > trying such an approach from day 1 on. > > Thanks, > > Ingo -- 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 PULL] platform-drivers-x86 for 4.4-1
On Thu, Nov 5, 2015 at 10:56 PM, Darren Hart wrote: > > Please note the OLPC/MAINTAINERS changes described in the tag message. If > adding > this to my maintenance bin is innappropriate, please drop these two patches. Heh. The only thing inappropriate is your atrocious spelling of the word. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
On 11/6/15, Anju T wrote: > Hi Denis, > > On Wednesday 04 November 2015 02:26 PM, Denis Kirjanov wrote: >> On 11/3/15, Anju T wrote: >>> This short patch series adds the ability to sample the interrupted >>> machine state for each hardware sample. >>> >>> To test this patchset, >>> Eg: >>> >>> $perf record -I ls // record machine state at interrupt >>> $perf script -D //read the perf.data file >> Uncovered the following warning with the series applied. Looks like >> that it's not >> directly related to your patches but anyway... > > May I know the config you used while testing? > Did this warning appeared on boot time? Hi Anju, This happens when perf record is invoked. I think you have to enable DEBUG_LOCKDEP Thanks > > Thanks > > Anju > >> >> [ 507.655197] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) >> [ 507.655220] [ cut here ] >> [ 507.655226] WARNING: at kernel/locking/lockdep.c:3523 >> [ 507.655230] Modules linked in: ipv6 binfmt_misc ehea >> [ 507.655242] CPU: 12 PID: 3746 Comm: ls Tainted: G S >> 4.3.0-rc3-00103-g3b0e21e-dirty #11 >> [ 507.655249] task: c005b607b290 ti: c005b62e8000 task.ti: >> c005b62e8000 >> [ 507.655255] NIP: c010c944 LR: c010c940 CTR: >> c0659380 >> [ 507.655261] REGS: c005b62eb5c0 TRAP: 0700 Tainted: G S >> (4.3.0-rc3-00103-g3b0e21e-dirty) >> [ 507.655266] MSR: 80029032 CR: 22088422 >> XER: 000e >> [ 507.655284] CFAR: c08977c4 SOFTE: 0 >> GPR00: c010c940 c005b62eb840 c102e600 >> 002f >> GPR04: 0001 c01208d8 >> 0001 >> GPR08: c0eee600 c005b607b290 >> 3fef >> GPR12: 42088428 ce956600 001f >> 3fffd546c4b0 >> GPR16: 001f 0013 c0b198a8 >> >> GPR20: c005acbb2f80 c005b5c5dd00 3fffd546c500 >> 0001 >> GPR24: c024af54 0001 >> 0001 >> GPR28: c005acbb2ea0 >> c1e0cf78 >> [ 507.655376] NIP [c010c944] .check_flags.part.36+0xd4/0x240 >> [ 507.655382] LR [c010c940] .check_flags.part.36+0xd0/0x240 >> [ 507.655387] Call Trace: >> [ 507.655391] [c005b62eb840] [c010c940] >> .check_flags.part.36+0xd0/0x240 (unreliable) >> [ 507.655400] [c005b62eb8c0] [c01112b8] >> .lock_acquire+0x208/0x2a0 >> [ 507.655407] [c005b62eb990] [c024af80] >> .__might_fault+0xb0/0xf0 >> [ 507.655415] [c005b62eba10] [c04d5d38] >> .strnlen_user+0x1d8/0x200 >> [ 507.655422] [c005b62ebad0] [c032fa0c] >> .load_elf_binary+0x103c/0x1650 >> [ 507.655430] [c005b62ebc10] [c02bac54] >> .search_binary_handler+0xc4/0x260 >> [ 507.655437] [c005b62ebcb0] [c02bcd54] >> .do_execveat_common.isra.22+0x7d4/0xb40 >> [ 507.655444] [c005b62ebda0] [c02bd4a8] >> .SyS_execve+0x38/0x50 >> [ 507.655451] [c005b62ebe30] [c000916c] >> system_call+0x38/0xd0 >> [ 507.655456] Instruction dump: >> [ 507.655461] 419e0034 3d4200e5 392a3280 8129 2f89 40fe0020 >> 3c62ffad 3c82ffad >> [ 507.655475] 3863c038 38841f88 4878adfd 6000 <0fe0> 3c62ffad >> 38632010 4878ade9 >> [ 507.655490] ---[ end trace 47284e8c92efaa7e ]--- >> [ 507.655494] possible reason: unannotated irqs-on. >> [ 507.655498] irq event stamp: 2324 >> [ 507.655501] hardirqs last enabled at (2323): [] >> ._raw_spin_unlock_irqrestore+0x54/0xd0 >> [ 507.655510] hardirqs last disabled at (2324): [] >> restore_irq_off+0x24/0x28 >> [ 507.655518] softirqs last enabled at (2184): [] >> .__do_softirq+0x500/0x670 >> [ 507.655526] softirqs last disabled at (2169): [] >> .irq_exit+0xd8/0x120 >> >>> Sample output obtained for this patchset/ output looks like as follows: >>> >>> 331557004666 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4807/4807: >>> 0xc01ddf60 period: 1 addr: 0 >>> ... intr regs: mask 0x7ff ABI 64-bit >>> gpr0 0xc01e6a74 >>> gpr1 0xc000ff33b9a0 >>> gpr2 0xc1523000 >>> gpr3 0xc00ffa9deb60 >>> gpr4 0xc000ff971e00 >>> gpr5 0x4d32564532 >>> gpr6 0x1e00 >>> gpr7 0x0 >>> gpr8 0x0 >>> gpr9 0x0 >>> gpr10 0x1 >>> gpr11 0x0 >>> gpr12 0x24022822 >>> gpr13 0xcfeeaf80 >>> gpr14 0x0 >>> gpr15 0xc000fbc21000 >>> gpr16 0x0 >>> gpr17 0xc00ffa9c5000 >>> gpr18 0xc000ff33b8a0 >>> gpr19 0xc1523000 >>> gpr20 0xc00a097c >>> gpr21 0xc00fcac65600 >>> gpr22 0xc01e55a8 >>> gpr23 0xc1523000 >>> gpr24 0xc000ff33b850 >>> gpr25 0xc00fcac65600 >>> gpr26 0xc01e4b378210 >>> gpr27 0xfead >>> gpr28 0x1 >>> gpr29 0xc00fcac65600 >>>
Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr
On Thursday 05 November 2015 08:12 PM, Stephane Eranian wrote: > Hi, > > On Wed, Nov 4, 2015 at 9:46 PM, Madhavan Srinivasan > wrote: >> This patchset extend the perf sample regs infrastructure >> to include architecture specific regs. Current perf_sample_regs_intr >> exports only registers in the pt_regs to perf.data using >> PERF_SAMPLE_REGS_INTR sample type. But sometimes we end up looking >> for or prefer raw register values at the interrupt during debug. >> > I don't quite understand this explanation here. > What do you mean by raw register values? > The content of pt_regs is also raw register values at interrupt. Was out and did not have access to mail, so missed to respond in time. Yes. that is right. My bad. Did not effectively communicate what I intended. Intend here is to capture more data related to pmu context for the sample. And in case of arch/powerpc, only a subset of pmu regs are in the pt_regs structure. By adding these additional pmu registers (which are not part of pt_regs and i dont intend to overload pt_regs struct with these regs, since it is not relevant to ptrace), more interesting data about the PMU and its context is captured for the sample. > The API does not say that the content of perf_sample_regs_intr can ONLY > contain names of registers coming from pt_regs. The meaning of each bit > is arch specific and you are free to map to whatever is relevant for your > arch. > All the API says is that the values captured in the sampling buffer for these > registers are taken at PMU interrupt. Yes thats right. But what I propose here to include an arch specific struct in the perf_regs, so that more register values can be fetched as part of perf_sample_regs_intr without extending pt_regs. Maddy >> This patchset extends the perf_regs to include arch specific struct, >> and makes perf_sample_regs_intr in kernel/event/core.c as __weak__ >> function. This way, an arch specific implementation of >> perf_sample_regs_intr() can update the arch specific data to >> the perf_regs. >> >> First patch defines a new structure arch_misc_reg and updates the same >> in the struct perf_regs. Patch also modifies the perf_reg_value() >> and perf_output_sample_regs() to take perf_regs parameter instead of pt_regs. >> >> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers >> and adds offsetof macro for the same. It extends perf_reg_value() >> to use reg idx to decide on struct to return value from. >> >> Third patch adds arch specific perf_sample_regs_intr() in arch/powerpc >> to hook up the arch_misc_regs to perf_regs. >> >> This patchset depends on the recent posting by Anju T in >> linuxppc-...@lists.ozlabs.org to enable PERF_SAMPLE_REGS_INTR >> support in arch/powerpc. >> >> https://patchwork.ozlabs.org/patch/539242/ >> https://patchwork.ozlabs.org/patch/539243/ >> https://patchwork.ozlabs.org/patch/539244/ >> >> Would appreciate comments and feedback. >> >> Signed-off-by: Madhavan Srinivasan >> Cc: Thomas Gleixner >> Cc: Ingo Molnar >> Cc: Peter Zijlstra >> Cc: Jiri Olsa >> Cc: Arnaldo Carvalho de Melo >> Cc: Stephane Eranian >> Cc: Russell King >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Benjamin Herrenschmidt >> Cc: Michael Ellerman >> Cc: Sukadev Bhattiprolu >> >> Madhavan Srinivasan (3): >> perf/core: extend perf_regs to include arch specific regs >> perf/powerpc: update macros and add regs to arch_misc_reg struct >> perf/powerpc: Functions to update arch_misc_regs >> >> arch/arm/include/asm/ptrace.h | 2 ++ >> arch/arm/kernel/perf_regs.c | 4 +++- >> arch/arm64/include/asm/ptrace.h | 2 ++ >> arch/arm64/kernel/perf_regs.c | 4 +++- >> arch/powerpc/include/uapi/asm/perf_regs.h | 10 ++ >> arch/powerpc/include/uapi/asm/ptrace.h | 11 +++ >> arch/powerpc/perf/core-book3s.c | 29 >> + >> arch/powerpc/perf/perf_regs.c | 28 >> ++-- >> arch/x86/include/asm/ptrace.h | 2 ++ >> arch/x86/kernel/perf_regs.c | 4 +++- >> include/linux/perf_regs.h | 5 +++-- >> kernel/events/core.c| 8 >> tools/perf/arch/powerpc/include/perf_regs.h | 16 >> 13 files changed, 114 insertions(+), 11 deletions(-) >> >> -- >> 1.9.1 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr
On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote: > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote: >> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers >> and adds offsetof macro for the same. It extends perf_reg_value() >> to use reg idx to decide on struct to return value from. > Why; what's in those regs? Was out and did not have access to mail, so missed to respond in time. In current implementation of patch 2, have added few pmu control/status and counter registers, which give additional information about the PMU context for the sample. These pmu registers are not relevant for ptrace and did not want to overload pt_regs struct. Adding these arch specific regs in perf_regs will break the "arch neutral" part, and other arch can also use this new struct in perf_regs to add more data using perf_sample_regs_intr without extending the pt_regs. Maddy -- 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/
Urgent Business Proposal
Attached is the full details of the Business Proposal view it and get back to me immediately for more details. Project Investment Deal.pdf Description: Adobe PDF document
Re: [PATCH 01/23] usb: gadget: f_sourcesink: make ISO altset user-selectable
On 11/06/2015 04:05 AM, Peter Chen wrote:
> On Tue, Nov 03, 2015 at 01:53:40PM +0100, Robert Baldyga wrote:
>> So far it was decided during the bind process whether is iso altsetting
>> included to f_sourcesink function or not. This decision was based on
>> availability of isochronous endpoints.
>>
>> Since we can assemble gadget driver using composite framework and configfs
>> from many different functions, availability of given type of endpoint
>> can depend on selected components or even on their order in given
>> configuration.
>>
>> This can result with non-obvious behavior - even small, seemingly unrelated
>> change in gadget configuration can decide if we have second altsetting with
>> iso endpoints in given sourcesink function instance or not.
>>
>> Because of this it's way better to have additional parameter allowing user
>> to decide if he/she wants to have iso altsetting, and if iso altsetting is
>> included, and there are no iso endpoints available, function bind will fail
>> instead of silently allowing to have non-complete function bound.
>
> Hi Robert,
>
> Why another isoc_enabled parameter is needed instead of judging if it
> is supported through gadget framework? Any use cases can't be supported
> by current way?
>
It's because guessing during bind process leads to non-obvious behavior
- we can have iso altsetting included into function or not depending on
many seemingly unrelated factors.
Moreover SourceSink, which is in fact testing Function, is the only
Function which implements conditional altsetting enabling, and we
definitely don't want testing function to behave that much differently
from another USB Functions.
The third reason is that modifying descriptors set depending on
availability of given endpoint type during bind process complicates bind
process automatization, which I implement in this patch set. After all,
I don't know any real USB device doing such strange thing.
Thanks,
Robert
>>
>> Signed-off-by: Robert Baldyga
>> ---
>> drivers/usb/gadget/function/f_sourcesink.c | 99
>> --
>> drivers/usb/gadget/function/g_zero.h | 3 +
>> drivers/usb/gadget/legacy/zero.c | 6 ++
>> 3 files changed, 77 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_sourcesink.c
>> b/drivers/usb/gadget/function/f_sourcesink.c
>> index d7646d3..1d6ec88 100644
>> --- a/drivers/usb/gadget/function/f_sourcesink.c
>> +++ b/drivers/usb/gadget/function/f_sourcesink.c
>> @@ -56,6 +56,7 @@ struct f_sourcesink {
>> unsigned isoc_maxpacket;
>> unsigned isoc_mult;
>> unsigned isoc_maxburst;
>> +unsigned isoc_enabled;
>> unsigned buflen;
>> };
>>
>> @@ -347,17 +348,28 @@ sourcesink_bind(struct usb_configuration *c, struct
>> usb_function *f)
>>
>> /* allocate bulk endpoints */
>> ss->in_ep = usb_ep_autoconfig(cdev->gadget, _source_desc);
>> -if (!ss->in_ep) {
>> -autoconf_fail:
>> -ERROR(cdev, "%s: can't autoconfigure on %s\n",
>> -f->name, cdev->gadget->name);
>> -return -ENODEV;
>> -}
>> +if (!ss->in_ep)
>> +goto autoconf_fail;
>>
>> ss->out_ep = usb_ep_autoconfig(cdev->gadget, _sink_desc);
>> if (!ss->out_ep)
>> goto autoconf_fail;
>>
>> +/* support high speed hardware */
>> +hs_source_desc.bEndpointAddress = fs_source_desc.bEndpointAddress;
>> +hs_sink_desc.bEndpointAddress = fs_sink_desc.bEndpointAddress;
>> +
>> +/* support super speed hardware */
>> +ss_source_desc.bEndpointAddress = fs_source_desc.bEndpointAddress;
>> +ss_sink_desc.bEndpointAddress = fs_sink_desc.bEndpointAddress;
>> +
>> +if (!ss->isoc_enabled) {
>> +fs_source_sink_descs[FS_ALT_IFC_1_OFFSET] = NULL;
>> +hs_source_sink_descs[HS_ALT_IFC_1_OFFSET] = NULL;
>> +ss_source_sink_descs[SS_ALT_IFC_1_OFFSET] = NULL;
>> +goto no_iso;
>> +}
>> +
>> /* sanity check the isoc module parameters */
>> if (ss->isoc_interval < 1)
>> ss->isoc_interval = 1;
>> @@ -379,30 +391,14 @@ autoconf_fail:
>> /* allocate iso endpoints */
>> ss->iso_in_ep = usb_ep_autoconfig(cdev->gadget, _iso_source_desc);
>> if (!ss->iso_in_ep)
>> -goto no_iso;
>> +goto autoconf_fail;
>>
>> ss->iso_out_ep = usb_ep_autoconfig(cdev->gadget, _iso_sink_desc);
>> -if (!ss->iso_out_ep) {
>> -usb_ep_autoconfig_release(ss->iso_in_ep);
>> -ss->iso_in_ep = NULL;
>> -no_iso:
>> -/*
>> - * We still want to work even if the UDC doesn't have isoc
>> - * endpoints, so null out the alt interface that contains
>> - * them and continue.
>> - */
>> -fs_source_sink_descs[FS_ALT_IFC_1_OFFSET] = NULL;
>> -hs_source_sink_descs[HS_ALT_IFC_1_OFFSET] = NULL;
>> -ss_source_sink_descs[SS_ALT_IFC_1_OFFSET] = NULL;
>> -}
What's TRACE_IRQS_OFF_DEBUG for?
The comment says: /* * When dynamic function tracer is enabled it will add a breakpoint * to all locations that it is about to modify, sync CPUs, update * all the code, sync CPUs, then remove the breakpoints. In this time * if lockdep is enabled, it might jump back into the debug handler * outside the updating of the IST protection. (TRACE_IRQS_ON/OFF). * * We need to change the IDT table before calling TRACE_IRQS_ON/OFF to * make sure the stack pointer does not get reset back to the top * of the debug stack, and instead just reuses the current stack. */ #if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_TRACE_IRQFLAGS) .macro TRACE_IRQS_OFF_DEBUG ... Unless I'm missing something, TRACE_IRQS_OFF isn't a tracepoint at all, though -- it's a lockdep debugging thing. Is the worry that someone might stick a kprobe or similar in the trace_hardirqs_off code? If so, could we just disable that instead? I could easily be missing something here. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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: GSO with udp_tunnel_xmit_skb
On Thu, Nov 5, 2015 at 7:52 PM, Jason A. Donenfeld wrote: > Hi folks, > > When sending arbitrary SKBs with udp_tunnel_xmit_skb, the networking > stack does not appear to be utilizing UFO on the outgoing UDP packets, > which significantly caps the transmission speed. I see about 50% CPU > usage in this send path, triggered for every single outgoing packet. > Is there a particular skb option I need to set to enable this? I read > Tom's patch [1] from last year, but this seems to be about setting the > inner packet type. In my case, the inner type is opaque encrypted > data, so there's not a relevant setting. > Jason, Is this about UFO or GSO (in email subject)? UFO should operate independently encapsulation or inner packet setting. Tom > Thanks, > Jason > > [1] http://thread.gmane.org/gmane.linux.network/332194 > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/3] Documentation: Email client improvements
On Thu, Nov 05, 2015 at 11:20:39PM -0700, Eddie Kovsky wrote: > A recent mailing list discussion about developer tools extended over > to Google+. > > https://plus.google.com/+DarrenHart/posts/EbVFWJu3FK9 > > Several members of the kernel community felt that improving the email > client documentation would make it easier for new developers to get > started submitting patches. > > This series introduces three updates to help new contributors get > Mutt working as quickly as possible. > > * Clarify that Gmail is acceptable for sending patches, as long as it > is used without the web interface. > > * Add instructions for sending files directly from Mutt without use of a > specific editor. > > * Add a minimal Mutt configuration to use Gmail's IMAP servers to send > text email. > > I tested this configuration using a mockup local user and my own Gmail > account. > > Thanks > > Eddie Thank you Eddie! Each of these patches is an incremental improvement and adds useful information to the documentation. For the series: Reviewed-by: Darren Hart > > Eddie Kovsky (3): > Clarify use of Gmail for emailing patches > Add note on sending files directly with Mutt > Add minimal Mutt config for using Gmail > > Documentation/email-clients.txt | 39 ++- > 1 file changed, 38 insertions(+), 1 deletion(-) > > -- > 2.6.2 > > -- Darren Hart Intel Open Source Technology Center -- 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] DWC Ethernet QoS: Delete an unnecessary check before the function call "of_node_put"
From: Markus Elfring Date: Fri, 6 Nov 2015 08:00:22 +0100 The of_node_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ethernet/synopsys/dwc_eth_qos.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c b/drivers/net/ethernet/synopsys/dwc_eth_qos.c index 85b3326..9066d7a 100644 --- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c +++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c @@ -2970,8 +2970,7 @@ err_out_unregister_netdev: err_out_clk_dis_aper: clk_disable_unprepare(lp->apb_pclk); err_out_free_netdev: - if (lp->phy_node) - of_node_put(lp->phy_node); + of_node_put(lp->phy_node); free_netdev(ndev); platform_set_drvdata(pdev, NULL); return ret; -- 2.6.2 -- 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] goldfish: add goldfish match node for dt driver probe
qemu use device tree to bootup linux kernel,
we need add device node match table to plaftorm driver,
so that can probe the goldfish driver correctly.
test by this qemu:
git clone https://android.googlesource.com/platform/external/qemu
Signed-off-by: yalin wang
---
drivers/input/keyboard/goldfish_events.c | 9 +
drivers/platform/goldfish/goldfish_pipe.c | 11 ++-
drivers/power/goldfish_battery.c | 11 ++-
drivers/staging/goldfish/goldfish_audio.c | 11 ++-
drivers/staging/goldfish/goldfish_nand.c | 11 ++-
drivers/tty/goldfish.c| 11 ++-
drivers/video/fbdev/goldfishfb.c | 10 +-
7 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/goldfish_events.c
b/drivers/input/keyboard/goldfish_events.c
index 907e4e2..7b99ab8 100644
--- a/drivers/input/keyboard/goldfish_events.c
+++ b/drivers/input/keyboard/goldfish_events.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -178,10 +179,18 @@ static int events_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_events_match[] = {
+ { .compatible = "generic,goldfish-events-keypad" },
+ { },
+};
+#endif
+
static struct platform_driver events_driver = {
.probe = events_probe,
.driver = {
.name = "goldfish_events",
+ .of_match_table = of_match_ptr(goldfish_events_match),
},
};
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..55b6d7c 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -615,11 +616,19 @@ static int goldfish_pipe_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_pipe_match[] = {
+ { .compatible = "generic,android-pipe" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_pipe = {
.probe = goldfish_pipe_probe,
.remove = goldfish_pipe_remove,
.driver = {
- .name = "goldfish_pipe"
+ .name = "goldfish_pipe",
+ .of_match_table = of_match_ptr(goldfish_pipe_match),
}
};
diff --git a/drivers/power/goldfish_battery.c b/drivers/power/goldfish_battery.c
index a50bb98..48b057d 100644
--- a/drivers/power/goldfish_battery.c
+++ b/drivers/power/goldfish_battery.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -227,11 +228,19 @@ static int goldfish_battery_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_battery_match[] = {
+ { .compatible = "generic,goldfish-battery" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_battery_device = {
.probe = goldfish_battery_probe,
.remove = goldfish_battery_remove,
.driver = {
- .name = "goldfish-battery"
+ .name = "goldfish-battery",
+ .of_match_table = of_match_ptr(goldfish_battery_match),
}
};
module_platform_driver(goldfish_battery_device);
diff --git a/drivers/staging/goldfish/goldfish_audio.c
b/drivers/staging/goldfish/goldfish_audio.c
index b0927e4..f0c5118 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -344,11 +345,19 @@ static int goldfish_audio_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_audio_match[] = {
+ { .compatible = "generic,goldfish-audio" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_audio_driver = {
.probe = goldfish_audio_probe,
.remove = goldfish_audio_remove,
.driver = {
- .name = "goldfish_audio"
+ .name = "goldfish_audio",
+ .of_match_table = of_match_ptr(goldfish_audio_match),
}
};
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index 623353db5..d4c4285 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -430,11 +431,19 @@ static int goldfish_nand_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_nand_match[] = {
+ { .compatible = "generic,goldfish-nand" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_nand_driver = {
.probe =
RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
From: a...@kernel.org [mailto:a...@kernel.org] >> >>Em Thu, Nov 05, 2015 at 02:08:48PM +, 平松雅巳 / HIRAMATU，MASAMI escreveu: >>> From: Wang Nan [mailto:wangn...@huawei.com] >>> > >>> >It is possible that find_perf_probe_point_from_map() fails to find >>> >symbol but still returns 0 because of an small error when coding: >>> >find_perf_probe_point_from_map() set 'ret' to error code at first, >>> >but also use it to hold return value of >>> >kernel_get_symbol_address_by_name(). >>> >>> OK, I didn't expect that there is a symbol which can be found by >>> kernel_get_symbol_address_by_name() but not by __find_kernel_function()... >> >>> Would you have any example of the error? >>> >>> > >>> >This patch resets 'ret' to error even kernel_get_symbol_address_by_name() >>> >success, so if !sym, the whole function returns error correctly. >>> >>> Hmm, that sounds tricky. I'd rather like to add *psym to >>> kernel_get_symbol_address_by_name() >>> to save symbol and don't use __find_kernel_function() instead. >> >>Tricky? I don't think so, suboptimal? possibly, but it fixes an error, >>so should be processed quickly, right? I'm applying his patch and then >>whatever improvement can be done on top. > >OK, then I'll send an improvement patch. Ah, finally I got what happened. I guess the problem may happen when we put a probe on the kernel somewhere outside of any functions and run "perf probe -l". I think it should not be allowed to put the probe outside any symbol. The background is here, at first "perf-probe -a somewhere" defines a probe in the kernel but its address is relative from "_text". (thus, vfs_read becomes "_text+2348080" for example). Since it is not readable by human, perf probe -l tries to get an appropriate symbol from the "_text+OFFSET". For the purpose, the first kernel_get_symbol_address_by_name() is for translating _text to an address, and the second __find_kernel_function() is for finding a symbol from the address+OFFSET. Then, if the address+OFFSET is out of the symbol map, the second one can fail. This means the first symbol and the second symbol is not same. So, the direction of Wang solution is good :). Just a cleanup is required. Thank you! > >Thanks, > >> >>- Arnaldo
[PATCH 5/5] KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes
At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
placed right after the call to detect unrelated sptes which should not
be found in the reverse-mapping list.
Move this check in rmap_get_first/next() so that all call sites, not
just the users of the for_each_rmap_spte() macro, will be checked the
same way. In addition, change the BUG_ON to WARN_ON since killing the
whole host is the last thing that KVM should try.
One thing to keep in mind is that kvm_mmu_unlink_parents() also uses
rmap_get_first() to handle parent sptes. The change will not break it
because parent sptes are present, at least until drop_parent_pte()
actually unlinks them, and not mmio-sptes.
Signed-off-by: Takuya Yoshikawa
---
Documentation/virtual/kvm/mmu.txt | 4 ++--
arch/x86/kvm/mmu.c| 31 ++-
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/Documentation/virtual/kvm/mmu.txt
b/Documentation/virtual/kvm/mmu.txt
index 3a4d681..daf9c0f 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -203,10 +203,10 @@ Shadow pages contain the following information:
page cannot be destroyed. See role.invalid.
parent_ptes:
The reverse mapping for the pte/ptes pointing at this page's spt. If
-parent_ptes bit 0 is zero, only one spte points at this pages and
+parent_ptes bit 0 is zero, only one spte points at this page and
parent_ptes points at this single spte, otherwise, there exists multiple
sptes pointing at this page and (parent_ptes & ~0x1) points at a data
-structure with a list of parent_ptes.
+structure with a list of parent sptes.
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c5e2363..353d752 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1099,17 +1099,28 @@ struct rmap_iterator {
*/
static u64 *rmap_get_first(unsigned long rmap, struct rmap_iterator *iter)
{
+ u64 *sptep;
+
if (!rmap)
return NULL;
if (!(rmap & 1)) {
iter->desc = NULL;
- return (u64 *)rmap;
+ sptep = (u64 *)rmap;
+ goto out;
}
iter->desc = (struct pte_list_desc *)(rmap & ~1ul);
iter->pos = 0;
- return iter->desc->sptes[iter->pos];
+ sptep = iter->desc->sptes[iter->pos];
+out:
+ /*
+* Parent sptes found in sp->parent_ptes lists are also checked here
+* since kvm_mmu_unlink_parents() uses this function. If the condition
+* needs to be changed for them, make another wrapper function.
+*/
+ WARN_ON(!is_shadow_present_pte(*sptep));
+ return sptep;
}
/*
@@ -1119,14 +1130,14 @@ static u64 *rmap_get_first(unsigned long rmap, struct
rmap_iterator *iter)
*/
static u64 *rmap_get_next(struct rmap_iterator *iter)
{
+ u64 *sptep;
+
if (iter->desc) {
if (iter->pos < PTE_LIST_EXT - 1) {
- u64 *sptep;
-
++iter->pos;
sptep = iter->desc->sptes[iter->pos];
if (sptep)
- return sptep;
+ goto out;
}
iter->desc = iter->desc->more;
@@ -1134,17 +1145,20 @@ static u64 *rmap_get_next(struct rmap_iterator *iter)
if (iter->desc) {
iter->pos = 0;
/* desc->sptes[0] cannot be NULL */
- return iter->desc->sptes[iter->pos];
+ sptep = iter->desc->sptes[iter->pos];
+ goto out;
}
}
return NULL;
+out:
+ WARN_ON(!is_shadow_present_pte(*sptep));
+ return sptep;
}
#define for_each_rmap_spte(_rmap_, _iter_, _spte_) \
for (_spte_ = rmap_get_first(*_rmap_, _iter_); \
- _spte_ && ({BUG_ON(!is_shadow_present_pte(*_spte_)); 1;}); \
- _spte_ = rmap_get_next(_iter_))
+ _spte_; _spte_ = rmap_get_next(_iter_))
static void drop_spte(struct kvm *kvm, u64 *sptep)
{
@@ -1358,7 +1372,6 @@ static bool kvm_zap_rmapp(struct kvm *kvm, unsigned long
*rmapp)
bool flush = false;
while ((sptep = rmap_get_first(*rmapp, ))) {
- BUG_ON(!(*sptep & PT_PRESENT_MASK));
rmap_printk("%s: spte %p %llx.\n", __func__, sptep, *sptep);
drop_spte(kvm, sptep);
--
2.1.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/
[PATCH 4/5] KVM: x86: MMU: Remove is_rmap_spte() and use is_shadow_present_pte()
is_rmap_spte(), originally named is_rmap_pte(), was introduced when the
simple reverse mapping was implemented by commit cd4a4e5374110444
("[PATCH] KVM: MMU: Implement simple reverse mapping"). At that point,
its role was clear and only rmap_add() and rmap_remove() were using it
to select sptes that need to be reverse-mapped.
Independently of that, is_shadow_present_pte() was first introduced by
commit c7addb902054195b ("KVM: Allow not-present guest page faults to
bypass kvm") to do bypass_guest_pf optimization, which does not exist
any more.
These two seem to have changed their roles somewhat, and is_rmap_spte()
just calls is_shadow_present_pte() now.
Since using both of them without no clear distinction just makes the
code confusing, remove is_rmap_spte().
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 13 -
arch/x86/kvm/mmu_audit.c | 2 +-
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 69e7d20..c5e2363 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -311,11 +311,6 @@ static int is_large_pte(u64 pte)
return pte & PT_PAGE_SIZE_MASK;
}
-static int is_rmap_spte(u64 pte)
-{
- return is_shadow_present_pte(pte);
-}
-
static int is_last_spte(u64 pte, int level)
{
if (level == PT_PAGE_TABLE_LEVEL)
@@ -540,7 +535,7 @@ static bool mmu_spte_update(u64 *sptep, u64 new_spte)
u64 old_spte = *sptep;
bool ret = false;
- WARN_ON(!is_rmap_spte(new_spte));
+ WARN_ON(!is_shadow_present_pte(new_spte));
if (!is_shadow_present_pte(old_spte)) {
mmu_spte_set(sptep, new_spte);
@@ -595,7 +590,7 @@ static int mmu_spte_clear_track_bits(u64 *sptep)
else
old_spte = __update_clear_spte_slow(sptep, 0ull);
- if (!is_rmap_spte(old_spte))
+ if (!is_shadow_present_pte(old_spte))
return 0;
pfn = spte_to_pfn(old_spte);
@@ -2575,7 +2570,7 @@ static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep, unsigned pte_access,
pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
*sptep, write_fault, gfn);
- if (is_rmap_spte(*sptep)) {
+ if (is_shadow_present_pte(*sptep)) {
/*
* If we overwrite a PTE page pointer with a 2MB PMD, unlink
* the parent of the now unreachable PTE.
@@ -2919,7 +2914,7 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu, gva_t
gva, int level,
* If the mapping has been changed, let the vcpu fault on the
* same address again.
*/
- if (!is_rmap_spte(spte)) {
+ if (!is_shadow_present_pte(spte)) {
ret = true;
goto exit;
}
diff --git a/arch/x86/kvm/mmu_audit.c b/arch/x86/kvm/mmu_audit.c
index 03d518e..90ee420 100644
--- a/arch/x86/kvm/mmu_audit.c
+++ b/arch/x86/kvm/mmu_audit.c
@@ -183,7 +183,7 @@ static void check_mappings_rmap(struct kvm *kvm, struct
kvm_mmu_page *sp)
return;
for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
- if (!is_rmap_spte(sp->spt[i]))
+ if (!is_shadow_present_pte(sp->spt[i]))
continue;
inspect_spte_has_rmap(kvm, sp->spt + i);
--
2.1.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/
[PATCH 3/5] KVM: x86: MMU: Make mmu_set_spte() return emulate value
mmu_set_spte()'s code is based on the assumption that the emulate
parameter has a valid pointer value if set_spte() returns true and
write_fault is not zero. In other cases, emulate may be NULL, so a
NULL-check is needed.
Stop passing emulate pointer and make mmu_set_spte() return the emulate
value instead to clean up this complex interface. Prefetch functions
can just throw away the return value.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 27 ++-
arch/x86/kvm/paging_tmpl.h | 10 +-
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a9622a2..69e7d20 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2564,13 +2564,13 @@ done:
return ret;
}
-static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
-unsigned pte_access, int write_fault, int *emulate,
-int level, gfn_t gfn, pfn_t pfn, bool speculative,
-bool host_writable)
+static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned
pte_access,
+int write_fault, int level, gfn_t gfn, pfn_t pfn,
+bool speculative, bool host_writable)
{
int was_rmapped = 0;
int rmap_count;
+ bool emulate = false;
pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
*sptep, write_fault, gfn);
@@ -2600,12 +2600,12 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep,
if (set_spte(vcpu, sptep, pte_access, level, gfn, pfn, speculative,
true, host_writable)) {
if (write_fault)
- *emulate = 1;
+ emulate = true;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
- if (unlikely(is_mmio_spte(*sptep) && emulate))
- *emulate = 1;
+ if (unlikely(is_mmio_spte(*sptep)))
+ emulate = true;
pgprintk("%s: setting spte %llx\n", __func__, *sptep);
pgprintk("instantiating %s PTE (%s) at %llx (%llx) addr %p\n",
@@ -2624,6 +2624,8 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep,
}
kvm_release_pfn_clean(pfn);
+
+ return emulate;
}
static pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
@@ -2658,9 +2660,8 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
return -1;
for (i = 0; i < ret; i++, gfn++, start++)
- mmu_set_spte(vcpu, start, access, 0, NULL,
-sp->role.level, gfn, page_to_pfn(pages[i]),
-true, true);
+ mmu_set_spte(vcpu, start, access, 0, sp->role.level, gfn,
+page_to_pfn(pages[i]), true, true);
return 0;
}
@@ -2721,9 +2722,9 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
for_each_shadow_entry(vcpu, (u64)gfn << PAGE_SHIFT, iterator) {
if (iterator.level == level) {
- mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
-write, , level, gfn, pfn,
-prefault, map_writable);
+ emulate = mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
+ write, level, gfn, pfn, prefault,
+ map_writable);
direct_pte_prefetch(vcpu, iterator.sptep);
++vcpu->stat.pf_fixed;
break;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index b41faa9..de24499 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -475,8 +475,8 @@ FNAME(prefetch_gpte)(struct kvm_vcpu *vcpu, struct
kvm_mmu_page *sp,
* we call mmu_set_spte() with host_writable = true because
* pte_prefetch_gfn_to_pfn always gets a writable pfn.
*/
- mmu_set_spte(vcpu, spte, pte_access, 0, NULL, PT_PAGE_TABLE_LEVEL,
-gfn, pfn, true, true);
+ mmu_set_spte(vcpu, spte, pte_access, 0, PT_PAGE_TABLE_LEVEL, gfn, pfn,
+true, true);
return true;
}
@@ -556,7 +556,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
struct kvm_mmu_page *sp = NULL;
struct kvm_shadow_walk_iterator it;
unsigned direct_access, access = gw->pt_access;
- int top_level, emulate = 0;
+ int top_level, emulate;
direct_access = gw->pte_access;
@@ -622,8 +622,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
}
clear_sp_write_flooding_count(it.sptep);
- mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault, ,
-it.level, gw->gfn, pfn, prefault, map_writable);
+ emulate = mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault,
[PATCH 2/5] KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap
Both __mmu_unsync_walk() and mmu_pages_clear_parents() have three line
code which clears a bit in the unsync child bitmap; the former places it
inside a loop block and uses a few goto statements to jump to it.
A new helper function, clear_unsync_child_bit(), makes the code cleaner.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a76bc04..a9622a2 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1806,6 +1806,13 @@ static int mmu_pages_add(struct kvm_mmu_pages *pvec,
struct kvm_mmu_page *sp,
return (pvec->nr == KVM_PAGE_ARRAY_NR);
}
+static inline void clear_unsync_child_bit(struct kvm_mmu_page *sp, int idx)
+{
+ --sp->unsync_children;
+ WARN_ON((int)sp->unsync_children < 0);
+ __clear_bit(idx, sp->unsync_child_bitmap);
+}
+
static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
struct kvm_mmu_pages *pvec)
{
@@ -1815,8 +1822,10 @@ static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
struct kvm_mmu_page *child;
u64 ent = sp->spt[i];
- if (!is_shadow_present_pte(ent) || is_large_pte(ent))
- goto clear_child_bitmap;
+ if (!is_shadow_present_pte(ent) || is_large_pte(ent)) {
+ clear_unsync_child_bit(sp, i);
+ continue;
+ }
child = page_header(ent & PT64_BASE_ADDR_MASK);
@@ -1825,28 +1834,21 @@ static int __mmu_unsync_walk(struct kvm_mmu_page *sp,
return -ENOSPC;
ret = __mmu_unsync_walk(child, pvec);
- if (!ret)
- goto clear_child_bitmap;
- else if (ret > 0)
+ if (!ret) {
+ clear_unsync_child_bit(sp, i);
+ continue;
+ } else if (ret > 0) {
nr_unsync_leaf += ret;
- else
+ } else
return ret;
} else if (child->unsync) {
nr_unsync_leaf++;
if (mmu_pages_add(pvec, child, i))
return -ENOSPC;
} else
-goto clear_child_bitmap;
-
- continue;
-
-clear_child_bitmap:
- __clear_bit(i, sp->unsync_child_bitmap);
- sp->unsync_children--;
- WARN_ON((int)sp->unsync_children < 0);
+ clear_unsync_child_bit(sp, i);
}
-
return nr_unsync_leaf;
}
@@ -2009,9 +2011,7 @@ static void mmu_pages_clear_parents(struct mmu_page_path
*parents)
if (!sp)
return;
- --sp->unsync_children;
- WARN_ON((int)sp->unsync_children < 0);
- __clear_bit(idx, sp->unsync_child_bitmap);
+ clear_unsync_child_bit(sp, idx);
level++;
} while (level < PT64_ROOT_LEVEL-1 && !sp->unsync_children);
}
--
2.1.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/
[PATCH 1/5] KVM: x86: MMU: Remove unused parameter of __direct_map()
Signed-off-by: Takuya Yoshikawa
---
arch/x86/kvm/mmu.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7d85bca..a76bc04 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,9 +2708,8 @@ static void direct_pte_prefetch(struct kvm_vcpu *vcpu,
u64 *sptep)
__direct_pte_prefetch(vcpu, sp, sptep);
}
-static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, int write,
- int map_writable, int level, gfn_t gfn, pfn_t pfn,
- bool prefault)
+static int __direct_map(struct kvm_vcpu *vcpu, int write, int map_writable,
+ int level, gfn_t gfn, pfn_t pfn, bool prefault)
{
struct kvm_shadow_walk_iterator iterator;
struct kvm_mmu_page *sp;
@@ -3018,8 +3017,7 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t v,
u32 error_code,
make_mmu_pages_available(vcpu);
if (likely(!force_pt_level))
transparent_hugepage_adjust(vcpu, , , );
- r = __direct_map(vcpu, v, write, map_writable, level, gfn, pfn,
-prefault);
+ r = __direct_map(vcpu, write, map_writable, level, gfn, pfn, prefault);
spin_unlock(>kvm->mmu_lock);
@@ -3541,8 +3539,7 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
gpa, u32 error_code,
make_mmu_pages_available(vcpu);
if (likely(!force_pt_level))
transparent_hugepage_adjust(vcpu, , , );
- r = __direct_map(vcpu, gpa, write, map_writable,
-level, gfn, pfn, prefault);
+ r = __direct_map(vcpu, write, map_writable, level, gfn, pfn, prefault);
spin_unlock(>kvm->mmu_lock);
return r;
--
2.1.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/
Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()
On Thu, Nov 5, 2015 at 10:32 PM, Eric Biggers wrote: > Here's the revised patch: Thanks, applied. 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/
[PATCH 0/5] KVM: x86: MMU: Clean up x86's mmu code for future work
Patch 1/2/3 are easy ones. Following two, patch 4/5, may not be ideal solutions, but at least explain, or try to explain, the problems. Takuya Yoshikawa (5): KVM: x86: MMU: Remove unused parameter of __direct_map() KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap KVM: x86: MMU: Make mmu_set_spte() return emulate value KVM: x86: MMU: Remove is_rmap_spte() and use is_shadow_present_pte() KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes Documentation/virtual/kvm/mmu.txt | 4 +- arch/x86/kvm/mmu.c| 118 -- arch/x86/kvm/mmu_audit.c | 2 +- arch/x86/kvm/paging_tmpl.h| 10 ++-- 4 files changed, 70 insertions(+), 64 deletions(-) -- 2.1.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/
Re: [GIT PULL] x86/mm changes for v4.4
On Thu, Nov 5, 2015 at 10:55 PM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones wrote: >> > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote: >> > > >> > > I don't have that later debug output at all. Presumably some config >> > difference. >> > >> > CONFIG_X86_PTDUMP_CORE iirc. >> >> No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead. >> >> Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should >> not default to 'y' unless it is made more useful if it actually >> triggers. Ingo? > > Yeah, agreed absolutely. > > So this is a bit sad because RWX pages are a real problem in practice, > especially > since the EFI addresses are well predictable, but generating a warning without > being able to fix it quickly is counterproductive as well, as it only annoys > people and makes them turn off the option. (Which we could do as well to begin > with, without the annoyance factor...) > > So the plan would be: > > 1) Make it default-n. > > 2) We should try to further improve the messages to make it easier to > determine > what's wrong. We _do_ try to output symbolic information in the warning, > to > make it easier to find buggy mappings, but these are not standard kernel > mappings. So I think we need an e820 mappings based semi-symbolic > printout of > bad addresses - maybe even correlate it with the MMIO resource tree. > > 3) We should fix the EFI permission problem without relying on the firmware: > it > appears we could just mark everything R-X optimistically, and if a write > fault > happens (it's pretty rare in fact, only triggers when we write to an EFI > variable and so), we can mark the faulting page RW- on the fly, because it > appears that writable EFI sections, while not enumerated very well in > 'old' > firmware, are still supposed to be page granular. (Even 'new' firmware I > wouldn't automatically trust to get the enumeration right...) I think it was Borislav who pointed out that this idea, which might have been mine, is a bit silly. Why not just skip mapping the EFI stuff in the init_pgd entirely and only map it in the EFI pgd? We'll have RWX stuff in the EFI pgd, but so what? If we're exposing anything that runs with the EFI pgd loaded to untrusted input, I think we've already lost. Admittedly, we might need to use a certain amount of care to avoid interesting conflicts with the vmap mechanism. We might need to vmap all of the EFI stuff, and possibly even all the top-level entries that contain EFI stuff (i.e. exactly one of them unless EFI ends up *huge*) as a blank not-present region to avoid overlaps, but that's not a big deal. > > If that 'supposed to be' turns out to be 'not true' (not unheard of in > firmware land), then plan B would be to mark pages that generate write > faults > RWX as well, to not break functionality. (This 'mark it RWX' is not > something > that exploits would have easy access to, and we could also generate a > warning > [after the EFI call has finished] if it ever triggers.) > > Admittedly this approach might not be without its own complications, but > it > looks reasonably simple (I don't think we need per EFI call page tables, > etc.), and does not assume much about the firmware being able to > enumerate its > permissions properly. Were we to merge EFI support today I'd have > insisted on > trying such an approach from day 1 on. I think we have separate EFI page tables already for other reasons. I could be wrong -- I've never really understood the EFI mapping layout very well. --Andy -- 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] h8300: cleanup startup and remove module code.
h8300's clocksource driver update.
Changes for v1
- Drop non-initialize changes.
- Private data static allocation.
- Avoid magic number.
- Use request_irq.
Signed-off-by: Yoshinori Sato
---
drivers/clocksource/h8300_timer16.c | 142 +
drivers/clocksource/h8300_timer8.c | 151
drivers/clocksource/h8300_tpu.c | 118 ++--
3 files changed, 144 insertions(+), 267 deletions(-)
diff --git a/drivers/clocksource/h8300_timer16.c
b/drivers/clocksource/h8300_timer16.c
index 82941c1..cdf0d83 100644
--- a/drivers/clocksource/h8300_timer16.c
+++ b/drivers/clocksource/h8300_timer16.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -47,9 +49,7 @@
#define ABSOLUTE 1
struct timer16_priv {
- struct platform_device *pdev;
struct clocksource cs;
- struct irqaction irqaction;
unsigned long total_cycles;
unsigned long mapbase;
unsigned long mapcommon;
@@ -144,111 +144,77 @@ static void timer16_disable(struct clocksource *cs)
p->cs_enabled = false;
}
+static struct timer16_priv timer16_priv = {
+ .cs = {
+ .name = "h8300_16timer",
+ .rating = 200,
+ .read = timer16_clocksource_read,
+ .enable = timer16_enable,
+ .disable = timer16_disable,
+ .mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+ },
+};
+
#define REG_CH 0
#define REG_COMM 1
-static int timer16_setup(struct timer16_priv *p, struct platform_device *pdev)
+static void __init h8300_16timer_init(struct device_node *node)
{
- struct resource *res[2];
+ void __iomem *base[2];
int ret, irq;
unsigned int ch;
+ struct clk *clk;
- memset(p, 0, sizeof(*p));
- p->pdev = pdev;
-
- res[REG_CH] = platform_get_resource(p->pdev,
- IORESOURCE_MEM, REG_CH);
- res[REG_COMM] = platform_get_resource(p->pdev,
- IORESOURCE_MEM, REG_COMM);
- if (!res[REG_CH] || !res[REG_COMM]) {
- dev_err(>pdev->dev, "failed to get I/O memory\n");
- return -ENXIO;
- }
- irq = platform_get_irq(p->pdev, 0);
- if (irq < 0) {
- dev_err(>pdev->dev, "failed to get irq\n");
- return irq;
+ clk = of_clk_get(node, 0);
+ if (IS_ERR(clk)) {
+ pr_err("failed to get clock for clocksource\n");
+ return;
}
- p->clk = clk_get(>pdev->dev, "fck");
- if (IS_ERR(p->clk)) {
- dev_err(>pdev->dev, "can't get clk\n");
- return PTR_ERR(p->clk);
+ base[REG_CH] = of_iomap(node, 0);
+ if (!base[REG_CH]) {
+ pr_err("failed to map registers for clocksource\n");
+ goto free_clk;
}
- of_property_read_u32(p->pdev->dev.of_node, "renesas,channel", );
-
- p->pdev = pdev;
- p->mapbase = res[REG_CH]->start;
- p->mapcommon = res[REG_COMM]->start;
- p->enb = 1 << ch;
- p->imfa = 1 << ch;
- p->imiea = 1 << (4 + ch);
- p->cs.name = pdev->name;
- p->cs.rating = 200;
- p->cs.read = timer16_clocksource_read;
- p->cs.enable = timer16_enable;
- p->cs.disable = timer16_disable;
- p->cs.mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8);
- p->cs.flags = CLOCK_SOURCE_IS_CONTINUOUS;
- ret = request_irq(irq, timer16_interrupt,
- IRQF_TIMER, pdev->name, p);
- if (ret < 0) {
- dev_err(>pdev->dev, "failed to request irq %d\n", irq);
- return ret;
+ base[REG_COMM] = of_iomap(node, 1);
+ if (!base[REG_COMM]) {
+ pr_err("failed to map registers for clocksource\n");
+ goto unmap_ch;
}
- clocksource_register_hz(>cs, clk_get_rate(p->clk) / 8);
-
- return 0;
-}
-
-static int timer16_probe(struct platform_device *pdev)
-{
- struct timer16_priv *p = platform_get_drvdata(pdev);
-
- if (p) {
- dev_info(>dev, "kept as earlytimer\n");
- return 0;
+ irq = irq_of_parse_and_map(node, 0);
+ if (irq < 0) {
+ pr_err("failed to get irq for clockevent\n");
+ goto unmap_comm;
}
- p = devm_kzalloc(>dev, sizeof(*p), GFP_KERNEL);
- if (!p)
- return -ENOMEM;
+ of_property_read_u32(node, "renesas,channel", );
- return timer16_setup(p, pdev);
-}
+ timer16_priv.mapbase = (unsigned long)base[REG_CH];
+ timer16_priv.mapcommon = (unsigned long)base[REG_COMM];
+ timer16_priv.enb = 1 << ch;
+ timer16_priv.imfa = 1 << ch;
+ timer16_priv.imiea = 1 << (4 + ch);
-static int timer16_remove(struct platform_device
Re: [PATCH V3 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
Hi Denis, On Wednesday 04 November 2015 02:26 PM, Denis Kirjanov wrote: On 11/3/15, Anju T wrote: This short patch series adds the ability to sample the interrupted machine state for each hardware sample. To test this patchset, Eg: $perf record -I ls // record machine state at interrupt $perf script -D //read the perf.data file Uncovered the following warning with the series applied. Looks like that it's not directly related to your patches but anyway... May I know the config you used while testing? Did this warning appeared on boot time? Thanks Anju [ 507.655197] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) [ 507.655220] [ cut here ] [ 507.655226] WARNING: at kernel/locking/lockdep.c:3523 [ 507.655230] Modules linked in: ipv6 binfmt_misc ehea [ 507.655242] CPU: 12 PID: 3746 Comm: ls Tainted: G S 4.3.0-rc3-00103-g3b0e21e-dirty #11 [ 507.655249] task: c005b607b290 ti: c005b62e8000 task.ti: c005b62e8000 [ 507.655255] NIP: c010c944 LR: c010c940 CTR: c0659380 [ 507.655261] REGS: c005b62eb5c0 TRAP: 0700 Tainted: G S (4.3.0-rc3-00103-g3b0e21e-dirty) [ 507.655266] MSR: 80029032 CR: 22088422 XER: 000e [ 507.655284] CFAR: c08977c4 SOFTE: 0 GPR00: c010c940 c005b62eb840 c102e600 002f GPR04: 0001 c01208d8 0001 GPR08: c0eee600 c005b607b290 3fef GPR12: 42088428 ce956600 001f 3fffd546c4b0 GPR16: 001f 0013 c0b198a8 GPR20: c005acbb2f80 c005b5c5dd00 3fffd546c500 0001 GPR24: c024af54 0001 0001 GPR28: c005acbb2ea0 c1e0cf78 [ 507.655376] NIP [c010c944] .check_flags.part.36+0xd4/0x240 [ 507.655382] LR [c010c940] .check_flags.part.36+0xd0/0x240 [ 507.655387] Call Trace: [ 507.655391] [c005b62eb840] [c010c940] .check_flags.part.36+0xd0/0x240 (unreliable) [ 507.655400] [c005b62eb8c0] [c01112b8] .lock_acquire+0x208/0x2a0 [ 507.655407] [c005b62eb990] [c024af80] .__might_fault+0xb0/0xf0 [ 507.655415] [c005b62eba10] [c04d5d38] .strnlen_user+0x1d8/0x200 [ 507.655422] [c005b62ebad0] [c032fa0c] .load_elf_binary+0x103c/0x1650 [ 507.655430] [c005b62ebc10] [c02bac54] .search_binary_handler+0xc4/0x260 [ 507.655437] [c005b62ebcb0] [c02bcd54] .do_execveat_common.isra.22+0x7d4/0xb40 [ 507.655444] [c005b62ebda0] [c02bd4a8] .SyS_execve+0x38/0x50 [ 507.655451] [c005b62ebe30] [c000916c] system_call+0x38/0xd0 [ 507.655456] Instruction dump: [ 507.655461] 419e0034 3d4200e5 392a3280 8129 2f89 40fe0020 3c62ffad 3c82ffad [ 507.655475] 3863c038 38841f88 4878adfd 6000 <0fe0> 3c62ffad 38632010 4878ade9 [ 507.655490] ---[ end trace 47284e8c92efaa7e ]--- [ 507.655494] possible reason: unannotated irqs-on. [ 507.655498] irq event stamp: 2324 [ 507.655501] hardirqs last enabled at (2323): [] ._raw_spin_unlock_irqrestore+0x54/0xd0 [ 507.655510] hardirqs last disabled at (2324): [] restore_irq_off+0x24/0x28 [ 507.655518] softirqs last enabled at (2184): [] .__do_softirq+0x500/0x670 [ 507.655526] softirqs last disabled at (2169): [] .irq_exit+0xd8/0x120 Sample output obtained for this patchset/ output looks like as follows: 331557004666 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4807/4807: 0xc01ddf60 period: 1 addr: 0 ... intr regs: mask 0x7ff ABI 64-bit gpr0 0xc01e6a74 gpr1 0xc000ff33b9a0 gpr2 0xc1523000 gpr3 0xc00ffa9deb60 gpr4 0xc000ff971e00 gpr5 0x4d32564532 gpr6 0x1e00 gpr7 0x0 gpr8 0x0 gpr9 0x0 gpr10 0x1 gpr11 0x0 gpr12 0x24022822 gpr13 0xcfeeaf80 gpr14 0x0 gpr15 0xc000fbc21000 gpr16 0x0 gpr17 0xc00ffa9c5000 gpr18 0xc000ff33b8a0 gpr19 0xc1523000 gpr20 0xc00a097c gpr21 0xc00fcac65600 gpr22 0xc01e55a8 gpr23 0xc1523000 gpr24 0xc000ff33b850 gpr25 0xc00fcac65600 gpr26 0xc01e4b378210 gpr27 0xfead gpr28 0x1 gpr29 0xc00fcac65600 gpr30 0x1 gpr31 0x0 nip 0xc01ddf68 msr 0x90009032 orig_r3 0xc01e5fcc ctr 0xc009e1b0 link 0xc01e6a74 xer 0x0 ccr 0x84022882 softe 0x0 trap 0xf01 dar 0x0 dsisr 0xf0004006004 ... thread: :4807:4807 .. dso: /root/.debug/.build-id/1c/011201a1082e91b8449e6dd528f224d7a16535 :4807 4807 331.557004: 1 cycles: c01ddf60 .perf_ctx_unlock (/boot/vmlinux) 0x1b10 [0x188]: event: 9
[GIT PULL] platform-drivers-x86 for 4.4-1
Hi Linus, Please note the OLPC/MAINTAINERS changes described in the tag message. If adding this to my maintenance bin is innappropriate, please drop these two patches. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c: Linux 4.3-rc3 (2015-09-27 07:50:08 -0400) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.4-1 for you to fetch changes up to d2f20619942fe4618160a7fa3dbdcbac335cff59: toshiba_acpi: Initialize hotkey_event_type variable (2015-11-05 16:09:24 -0800) platform-drivers-x86 for 4.4-1 Various toshiba hotkey and keyboard related fixes and a new WMI driver. Several intel_scu_ipc cleanups and a locking fix. A spattering of small single fixes across various platforms. I was asked to pick up an OLPC cleanup as the driver appeared unmaintained and it seemed similar to what is maintained in platform/drivers/x86. I have included the patch and an update to the MAINTAINERS file. toshiba_acpi: - Initialize hotkey_event_type variable - Remove unneeded u32 variables from *setup_keyboard - Add 0x prefix to available_kbd_modes_show function - Change default Hotkey enabling value - Unify hotkey enabling functions toshiba-wmi: - Toshiba WMI Hotkey Driver intel_scu_ipc: - Protect dev member assignment on ->remove() - Switch to use module_pci_driver() macro - Convert to use struct device * - Propagate pointer to struct intel_scu_ipc_dev - Fix error path by turning to devm_* / pcim_* acer-wmi: - remove threeg and interface sysfs interfaces OLPC: - Use %*ph specifier instead of passing direct values MAINTAINERS: - Add drivers/platform/olpc to drivers/platform/x86 sony-laptop: - Fix handling sony_nc_hotkeys_decode result intel_mid_powerbtn: - Remove misuse of IRQF_NO_SUSPEND flag compal-laptop: - Add charge control limit asus-wmi: - restore kbd led level after resume Andrzej Hajda (1): sony-laptop: Fix handling sony_nc_hotkeys_decode result Andy Shevchenko (6): OLPC: Use %*ph specifier instead of passing direct values intel_scu_ipc: Fix error path by turning to devm_* / pcim_* intel_scu_ipc: Propagate pointer to struct intel_scu_ipc_dev intel_scu_ipc: Convert to use struct device * intel_scu_ipc: Switch to use module_pci_driver() macro intel_scu_ipc: Protect dev member assignment on ->remove() Azael Avalos (6): toshiba_acpi: Unify hotkey enabling functions toshiba_acpi: Change default Hotkey enabling value toshiba_acpi: Add 0x prefix to available_kbd_modes_show function toshiba_acpi: Remove unneeded u32 variables from *setup_keyboard platform/x86: Toshiba WMI Hotkey Driver toshiba_acpi: Initialize hotkey_event_type variable Darren Hart (1): MAINTAINERS: Add drivers/platform/olpc to drivers/platform/x86 Lee, Chun-Yi (1): acer-wmi: remove threeg and interface sysfs interfaces Oleksij Rempel (1): asus-wmi: restore kbd led level after resume Roald Frederickx (1): compal-laptop: Add charge control limit Sudeep Holla (1): intel_mid_powerbtn: Remove misuse of IRQF_NO_SUSPEND flag MAINTAINERS | 7 ++ drivers/platform/olpc/olpc-ec.c | 13 +- drivers/platform/x86/Kconfig | 22 +++- drivers/platform/x86/Makefile | 1 + drivers/platform/x86/acer-wmi.c | 92 --- drivers/platform/x86/asus-wmi.c | 19 ++- drivers/platform/x86/compal-laptop.c | 43 ++- drivers/platform/x86/intel_mid_powerbtn.c | 10 +- drivers/platform/x86/intel_scu_ipc.c | 189 ++ drivers/platform/x86/sony-laptop.c| 13 +- drivers/platform/x86/toshiba-wmi.c| 138 ++ drivers/platform/x86/toshiba_acpi.c | 63 -- 12 files changed, 358 insertions(+), 252 deletions(-) create mode 100644 drivers/platform/x86/toshiba-wmi.c -- Darren Hart Intel Open Source Technology Center -- 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 PULL] x86/mm changes for v4.4
* Linus Torvalds wrote: > On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones wrote: > > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote: > > > > > > I don't have that later debug output at all. Presumably some config > > difference. > > > > CONFIG_X86_PTDUMP_CORE iirc. > > No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead. > > Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should > not default to 'y' unless it is made more useful if it actually > triggers. Ingo? Yeah, agreed absolutely. So this is a bit sad because RWX pages are a real problem in practice, especially since the EFI addresses are well predictable, but generating a warning without being able to fix it quickly is counterproductive as well, as it only annoys people and makes them turn off the option. (Which we could do as well to begin with, without the annoyance factor...) So the plan would be: 1) Make it default-n. 2) We should try to further improve the messages to make it easier to determine what's wrong. We _do_ try to output symbolic information in the warning, to make it easier to find buggy mappings, but these are not standard kernel mappings. So I think we need an e820 mappings based semi-symbolic printout of bad addresses - maybe even correlate it with the MMIO resource tree. 3) We should fix the EFI permission problem without relying on the firmware: it appears we could just mark everything R-X optimistically, and if a write fault happens (it's pretty rare in fact, only triggers when we write to an EFI variable and so), we can mark the faulting page RW- on the fly, because it appears that writable EFI sections, while not enumerated very well in 'old' firmware, are still supposed to be page granular. (Even 'new' firmware I wouldn't automatically trust to get the enumeration right...) If that 'supposed to be' turns out to be 'not true' (not unheard of in firmware land), then plan B would be to mark pages that generate write faults RWX as well, to not break functionality. (This 'mark it RWX' is not something that exploits would have easy access to, and we could also generate a warning [after the EFI call has finished] if it ever triggers.) Admittedly this approach might not be without its own complications, but it looks reasonably simple (I don't think we need per EFI call page tables, etc.), and does not assume much about the firmware being able to enumerate its permissions properly. Were we to merge EFI support today I'd have insisted on trying such an approach from day 1 on. Thanks, Ingo -- 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/
[ANNOUNCE]: SCST 3.1 pre-release freeze
Hi All, I'm glad to announce SCST 3.1 pre-release code freeze in the SCST SVN branch 3.0.x. You can get it by command: $ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.1.x It is going to be released after few weeks of testing, if no significant issues found. Highlights for this release: - Cluster support for SCSI reservations. This feature is essential for initiator-side clustering approaches based on persistent reservations, e.g. the quorum disk implementation in Windows Clustering. - Full support for VAAI or vStorage API for Array Integration: Extended Copy command support has been added as well as performance of WRITE SAME and of Atomic Test & Set, also known as COMPARE AND WRITE, has been improved. - T10-PI support has been added. - ALUA support has been improved: explicit ALUA (SET TARGET PORT GROUPS command) has been added and DRBD compatibility has been improved. - SCST events user space infrastructure has been added, so now SCST can notify a user space agent about important internal and fabric events. - QLogic target driver has been significantly improved. SCST is alternative SCSI target stack for Linux. SCST allows creation of sophisticated storage devices, which can provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. More info about SCST and its modules you can find on: http://scst.sourceforge.net Thanks to all who made it happen, especially to SanDisk for the great support! All above highlights development was supported by SanDisk. Vlad -- 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 v1] mm: hwpoison: adjust for new thp refcounting
On Fri, Nov 06, 2015 at 01:31:49AM -0500, Sasha Levin wrote: > On 11/06/2015 01:11 AM, Naoya Horiguchi wrote: > > In the new refcounting, we no longer use tail->_mapcount to keep tail's > > refcount, and thereby we can simplify get_hwpoison_page() and remove > > put_hwpoison_page() (by replacing with put_page()). > > This is confusing for the reader (and some static analysis tools): this adds > put_page()s without corresponding get_page()s. > > Could we instead macro put_hwpoison_page() as put_page() for the sake of > readability? OK, I'll do this. Thanks, Naoya Horiguchi-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 5/5] ACPI / debugger: Add module support for ACPI debugger
This patch converts AML debugger into a loadable module.
Note that, it implements driver unloading at the level dependent on the
module reference count. Which means if ACPI debugger is being used by a
userspace program, "rmmod acpi_dbg" should result in failure.
Signed-off-by: Lv Zheng
---
drivers/acpi/Kconfig | 11 +++
drivers/acpi/Makefile|2 +-
drivers/acpi/acpi_dbg.c | 80 --
drivers/acpi/bus.c |3 +-
drivers/acpi/osl.c | 207 --
include/linux/acpi.h | 71
include/linux/acpi_dbg.h | 52
7 files changed, 338 insertions(+), 88 deletions(-)
delete mode 100644 include/linux/acpi_dbg.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 2b89fd7..c4d4a05 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -66,6 +66,17 @@ config ACPI_DEBUGGER
This is still under development, currently enabling this only
results in the compilation of the ACPICA debugger files.
+if ACPI_DEBUGGER
+
+config ACPI_DEBUGGER_USER
+ tristate "Userspace debugger accessiblity"
+ depends on DEBUG_FS
+ help
+ Export /sys/kernel/debug/acpi/acpidbg for userspace utilities
+ to access the debugger functionalities.
+
+endif
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 102b5e6..c6f236f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,7 +50,6 @@ acpi-y+= sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
-acpi-$(CONFIG_ACPI_DEBUGGER) += acpi_dbg.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
@@ -80,6 +79,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB)+= cppc_acpi.o
+obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
# processor has its own "processor." module_param namespace
processor-y:= processor_driver.o
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
index 853ea94..7ca3202 100644
--- a/drivers/acpi/acpi_dbg.c
+++ b/drivers/acpi/acpi_dbg.c
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include "internal.h"
#define ACPI_AML_BUF_ALIGN (sizeof (acpi_size))
@@ -307,7 +307,7 @@ static int acpi_aml_readb_kern(void)
* the debugger output and store the output into the debugger interface
* buffer. Return the size of stored logs or errno.
*/
-ssize_t acpi_aml_write_log(const char *msg)
+static ssize_t acpi_aml_write_log(const char *msg)
{
int ret = 0;
int count = 0, size = 0;
@@ -350,7 +350,6 @@ again:
}
return size > 0 ? size : ret;
}
-EXPORT_SYMBOL(acpi_aml_write_log);
/*
* acpi_aml_read_cmd() - Capture debugger input
@@ -361,7 +360,7 @@ EXPORT_SYMBOL(acpi_aml_write_log);
* the debugger input commands and store the input commands into the
* debugger interface buffer. Return the size of stored commands or errno.
*/
-ssize_t acpi_aml_read_cmd(char *msg, size_t count)
+static ssize_t acpi_aml_read_cmd(char *msg, size_t count)
{
int ret = 0;
int size = 0;
@@ -403,7 +402,6 @@ again:
}
return size > 0 ? size : ret;
}
-EXPORT_SYMBOL(acpi_aml_read_cmd);
static int acpi_aml_thread(void *unsed)
{
@@ -440,7 +438,7 @@ static int acpi_aml_thread(void *unsed)
* This function should be used to implement acpi_os_execute() which is
* used by the ACPICA debugger to create the debugger thread.
*/
-int acpi_aml_create_thread(acpi_osd_exec_callback function, void *context)
+static int acpi_aml_create_thread(acpi_osd_exec_callback function, void
*context)
{
struct task_struct *t;
@@ -462,30 +460,27 @@ int acpi_aml_create_thread(acpi_osd_exec_callback
function, void *context)
mutex_unlock(_aml_io.lock);
return 0;
}
-EXPORT_SYMBOL(acpi_aml_create_thread);
-int acpi_aml_wait_command_ready(void)
+static int acpi_aml_wait_command_ready(bool single_step,
+ char *buffer, size_t length)
{
acpi_status status;
- if (!acpi_gbl_method_executing)
- acpi_os_printf("%1c ", ACPI_DEBUGGER_COMMAND_PROMPT);
- else
+ if (single_step)
acpi_os_printf("%1c ", ACPI_DEBUGGER_EXECUTE_PROMPT);
+ else
+ acpi_os_printf("%1c ", ACPI_DEBUGGER_COMMAND_PROMPT);
- status = acpi_os_get_line(acpi_gbl_db_line_buf,
- ACPI_DB_LINE_BUFFER_SIZE, NULL);
+ status = acpi_os_get_line(buffer, length, NULL);
if (ACPI_FAILURE(status))
return -EINVAL;
[RFC PATCH v2 4/5] tools/power/acpi: Add userspace AML interface support
This patch adds a userspace tool to access Linux kernel AML debugger interface. Tow modes are supported by this tool: 1. Interactive: Users are able to launch a debugging shell to talk with in-kernel AML debugger. Note that it's user duty to ensure kernel runtime integrity by using this debugging tool: A. Some control methods evaluated by the users may result in kernel panics if those control methods shouldn't be evaluated by the OSPMs according to the current BIOS/OS configurations. B. Currently if a single stepping evaluation couldn't run to an end, then the synchronization primitives acquired by the evaluation may block normal OSPM control method evaluations. 2. Batch: Users are able to execute debugger commands in a script. Note that in addition to the above duties, it's user duty to ensure script runtime integrity by using this debugging tool in this mode: C. Currently only those commands that are not used for single stepping are suitable to be used in this mode. D. If the execution of the command may cause a failure that could result in an endless kernel execution, the execution of the script may also get blocked. To exit the utility, currently "exit/quit" commands are recommended, but ctrl-C" can also be used. Signed-off-by: Lv Zheng --- tools/power/acpi/Makefile| 16 +- tools/power/acpi/tools/acpidbg/Makefile | 27 ++ tools/power/acpi/tools/acpidbg/acpidbg.c | 438 ++ 3 files changed, 473 insertions(+), 8 deletions(-) create mode 100644 tools/power/acpi/tools/acpidbg/Makefile create mode 100644 tools/power/acpi/tools/acpidbg/acpidbg.c diff --git a/tools/power/acpi/Makefile b/tools/power/acpi/Makefile index e882c83..a8bf908 100644 --- a/tools/power/acpi/Makefile +++ b/tools/power/acpi/Makefile @@ -10,18 +10,18 @@ include ../../scripts/Makefile.include -all: acpidump ec -clean: acpidump_clean ec_clean -install: acpidump_install ec_install -uninstall: acpidump_uninstall ec_uninstall +all: acpidbg acpidump ec +clean: acpidbg_clean acpidump_clean ec_clean +install: acpidbg_install acpidump_install ec_install +uninstall: acpidbg_uninstall acpidump_uninstall ec_uninstall -acpidump ec: FORCE +acpidbg acpidump ec: FORCE $(call descend,tools/$@,all) -acpidump_clean ec_clean: +acpidbg_clean acpidump_clean ec_clean: $(call descend,tools/$(@:_clean=),clean) -acpidump_install ec_install: +acpidbg_install acpidump_install ec_install: $(call descend,tools/$(@:_install=),install) -acpidump_uninstall ec_uninstall: +acpidbg_uninstall acpidump_uninstall ec_uninstall: $(call descend,tools/$(@:_uninstall=),uninstall) .PHONY: FORCE diff --git a/tools/power/acpi/tools/acpidbg/Makefile b/tools/power/acpi/tools/acpidbg/Makefile new file mode 100644 index 000..352df4b --- /dev/null +++ b/tools/power/acpi/tools/acpidbg/Makefile @@ -0,0 +1,27 @@ +# tools/power/acpi/tools/acpidbg/Makefile - ACPI tool Makefile +# +# Copyright (c) 2015, Intel Corporation +# Author: Lv Zheng +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; version 2 +# of the License. + +include ../../Makefile.config + +TOOL = acpidbg +vpath %.c \ + ../../../../../drivers/acpi/acpica\ + ../../common\ + ../../os_specific/service_layers\ + . +CFLAGS += -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER\ + -I.\ + -I../../../../../drivers/acpi/acpica\ + -I../../../../../include +LDFLAGS += -lpthread +TOOL_OBJS = \ + acpidbg.o + +include ../../Makefile.rules diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c b/tools/power/acpi/tools/acpidbg/acpidbg.c new file mode 100644 index 000..e4e8316 --- /dev/null +++ b/tools/power/acpi/tools/acpidbg/acpidbg.c @@ -0,0 +1,438 @@ +/* + * ACPI AML interfacing userspace utility + * + * Copyright (C) 2015, Intel Corporation + * Authors: Lv Zheng + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include + +/* Headers not included by include/acpi/platform/aclinux.h */ +#include +#include +#include +#include + +#define ACPI_AML_FILE "/sys/kernel/debug/acpi/acpidbg" +#define ACPI_AML_SEC_TICK 1 +#define ACPI_AML_USEC_PEEK 200 +#define ACPI_AML_BUF_SIZE 4096 + +#define ACPI_AML_BATCH_WRITE_CMD 0x00 /* Write command to kernel */ +#define ACPI_AML_BATCH_READ_LOG0x01 /* Read log from kernel */ +#define ACPI_AML_BATCH_WRITE_LOG 0x02 /* Write log to console */ + +#define ACPI_AML_LOG_START 0x00 +#define ACPI_AML_PROMPT_START 0x01 +#define ACPI_AML_PROMPT_STOP 0x02 +#define ACPI_AML_LOG_STOP 0x03 +#define ACPI_AML_PROMPT_ROLL
[RFC PATCH v2 2/5] ACPICA: Debugger: Convert some mechanisms to OSPM specific
The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acdebug.h |2 +- drivers/acpi/acpica/acglobal.h|5 -- drivers/acpi/acpica/dbinput.c | 97 - drivers/acpi/acpica/dbxface.c | 63 +++- drivers/acpi/acpica/utmutex.c | 17 --- include/acpi/acpiosxf.h | 18 ++- include/acpi/acpixf.h | 11 + include/acpi/platform/aclinux.h |4 ++ include/acpi/platform/aclinuxex.h | 19 9 files changed, 89 insertions(+), 147 deletions(-) diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h index c928ba4..86474d8 100644 --- a/drivers/acpi/acpica/acdebug.h +++ b/drivers/acpi/acpica/acdebug.h @@ -257,7 +257,7 @@ acpi_db_command_dispatch(char *input_buffer, void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void *context); -acpi_status acpi_db_user_commands(char prompt, union acpi_parse_object *op); +acpi_status acpi_db_user_commands(void); char *acpi_db_get_next_token(char *string, char **next, acpi_object_type * return_type); diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index faa9760..3977134 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -326,7 +326,6 @@ ACPI_GLOBAL(struct acpi_external_file *, acpi_gbl_external_file_list); #ifdef ACPI_DEBUGGER ACPI_INIT_GLOBAL(u8, acpi_gbl_abort_method, FALSE); -ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE); ACPI_INIT_GLOBAL(acpi_thread_id, acpi_gbl_db_thread_id, ACPI_INVALID_THREAD_ID); ACPI_GLOBAL(u8, acpi_gbl_db_opt_no_ini_methods); @@ -345,7 +344,6 @@ ACPI_GLOBAL(acpi_object_type, acpi_gbl_db_arg_types[ACPI_DEBUGGER_MAX_ARGS]); /* These buffers should all be the same size */ -ACPI_GLOBAL(char, acpi_gbl_db_line_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_parsed_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_scope_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_debug_filename[ACPI_DB_LINE_BUFFER_SIZE]); @@ -360,9 +358,6 @@ ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc); ACPI_GLOBAL(u32, acpi_gbl_num_nodes); ACPI_GLOBAL(u32, acpi_gbl_num_objects); -ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_ready); -ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_complete); - #endif /* ACPI_DEBUGGER */
[RFC PATCH v2 3/5] ACPI / debugger: Add IO interface to access debugger functionalities
This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by
userspace programs to access ACPICA debugger functionalities.
Known issue:
1. IO flush support
acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can
be used by acpi_dbg module to implement .flush() filesystem operation.
While this patch doesn't go that far. It then becomes userspace tool's
duty now to flush old commands before executing new batch mode commands.
Signed-off-by: Lv Zheng
---
drivers/acpi/Kconfig |2 +-
drivers/acpi/Makefile |1 +
drivers/acpi/acpi_dbg.c | 792 +
drivers/acpi/bus.c|2 +
drivers/acpi/osl.c| 55 ++-
include/acpi/platform/aclinux.h |2 -
include/acpi/platform/aclinuxex.h | 10 -
include/linux/acpi_dbg.h | 52 +++
8 files changed, 899 insertions(+), 17 deletions(-)
create mode 100644 drivers/acpi/acpi_dbg.c
create mode 100644 include/linux/acpi_dbg.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 25dbb76..2b89fd7 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -58,7 +58,7 @@ config ACPI_CCA_REQUIRED
bool
config ACPI_DEBUGGER
- bool "In-kernel debugger (EXPERIMENTAL)"
+ bool "In-kernel debugger"
select ACPI_DEBUG
help
Enable in-kernel debugging facilities: statistics, internal
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..102b5e6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,6 +50,7 @@ acpi-y+= sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
+acpi-$(CONFIG_ACPI_DEBUGGER) += acpi_dbg.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
new file mode 100644
index 000..853ea94
--- /dev/null
+++ b/drivers/acpi/acpi_dbg.c
@@ -0,0 +1,792 @@
+/*
+ * ACPI AML interfacing support
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Authors: Lv Zheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* #define DEBUG */
+#define pr_fmt(fmt) "ACPI : AML: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "internal.h"
+
+#define ACPI_AML_BUF_ALIGN (sizeof (acpi_size))
+#define ACPI_AML_BUF_SIZE PAGE_SIZE
+
+#define circ_count(circ) \
+ (CIRC_CNT((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_count_to_end(circ) \
+ (CIRC_CNT_TO_END((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_space(circ) \
+ (CIRC_SPACE((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_space_to_end(circ) \
+ (CIRC_SPACE_TO_END((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+
+#define ACPI_AML_OPENED0x0001
+#define ACPI_AML_CLOSED0x0002
+#define ACPI_AML_IN_USER 0x0004 /* user space is writing cmd */
+#define ACPI_AML_IN_KERN 0x0008 /* kernel space is reading cmd */
+#define ACPI_AML_OUT_USER 0x0010 /* user space is reading log */
+#define ACPI_AML_OUT_KERN 0x0020 /* kernel space is writing log */
+#define ACPI_AML_USER (ACPI_AML_IN_USER | ACPI_AML_OUT_USER)
+#define ACPI_AML_KERN (ACPI_AML_IN_KERN | ACPI_AML_OUT_KERN)
+#define ACPI_AML_BUSY (ACPI_AML_USER | ACPI_AML_KERN)
+#define ACPI_AML_OPEN (ACPI_AML_OPENED | ACPI_AML_CLOSED)
+
+struct acpi_aml_io {
+ wait_queue_head_t wait;
+ unsigned long flags;
+ unsigned long users;
+ struct mutex lock;
+ struct task_struct *thread;
+ char out_buf[ACPI_AML_BUF_SIZE] __aligned(ACPI_AML_BUF_ALIGN);
+ struct circ_buf out_crc;
+ char in_buf[ACPI_AML_BUF_SIZE] __aligned(ACPI_AML_BUF_ALIGN);
+ struct circ_buf in_crc;
+ acpi_osd_exec_callback function;
+ void *context;
+ unsigned long usages;
+};
+
+static struct acpi_aml_io acpi_aml_io;
+static bool acpi_aml_initialized;
+static struct file *acpi_aml_active_reader;
+static struct dentry *acpi_aml_dentry;
+
+static inline bool __acpi_aml_running(void)
+{
+ return acpi_aml_io.thread ? true : false;
+}
+
+static inline bool __acpi_aml_access_ok(unsigned long flag)
+{
+ /*
+* The debugger interface is in opened state (OPENED && !CLOSED),
+* then it is allowed to access the debugger buffers from either
+* user space or the kernel space.
+* In addition, for the kernel space, only the debugger thread
+* (thread ID matched) is allowed to access.
+*/
+ if
[RFC PATCH v2 1/5] ACPICA: Debugger: Remove unnecessary status check
From: Colin Ian King
ACPICA commit f9d5c6c9a25e9f5ac05458bfcd8b381e21bb2ba5
ACPICA BZ 1205. Colin Ian King.
Link: https://bugs.acpica.org/show_bug.cgi?id=1205
Link: https://github.com/acpica/acpica/commit/f9d5c6c9
Signed-off-by: Colin Ian King
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dbinput.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index 0480254..fe93f67 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -1246,9 +1246,6 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
* and wait for the command to complete.
*/
acpi_os_release_mutex(acpi_gbl_db_command_ready);
- if (ACPI_FAILURE(status)) {
- return (status);
- }
status =
acpi_os_acquire_mutex(acpi_gbl_db_command_complete,
--
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/
[PATCH v5 6/6] arm64: ftrace: add a test of function prologue analyzer
The patch ("arm64: ftrace: add arch-specific stack tracer") introduced
a function prologue analyzer.
Given that there is no fixed template for a function prologue, at least
on gcc for aarch64, a function prologue analyzer may be rather heuristic.
So this patch adds a kernel command line option,
function_prologue_analyzer_test, in order to run a basic test at startup
by executing an analyzer against all the *traceable* functions.
For function_prologue_analyzer_test=2, the output looks like:
po spfpsymbol
== ======
0: 0 0x040 0x000 gic_handle_irq+0x20/0xa4
1: 0 0x040 0x000 gic_handle_irq+0x34/0x114
2: 0 0x030 0x000 run_init_process+0x14/0x48
3: 0 0x020 0x000 try_to_run_init_process+0x14/0x58
4: 0 0x080 0x000 do_one_initcall+0x1c/0x194
...
22959: 0 0x020 0x000 tty_lock_slave+0x14/0x3c
22960: 0 0x020 0x000 tty_unlock_slave+0x14/0x3c
function prologue analyzer test: 0 errors
"po" indicates a position of callsite of mcount(), and should be zero
if an analyzer has parsed a function prologue successfully and reached
a location where fp is properly updated.
"sp" is a final offset to a parent's fp at the exit of function prologue.
"fp" is also an ofset against sp at the exit of function prologue.
So normally,
= + <"sp">
= - <"fp">
And the last line shows the number of possible errors in the result.
For function_prologue_analyzer_test=1, only the last line will be shown.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/kernel/stacktrace.c | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 4ee052a..d1a9e5b 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -322,5 +323,56 @@ void save_stack_trace_sp(struct stack_trace *trace,
{
__save_stack_trace_tsk(current, trace, stack_dump_sp);
}
+
+static int start_analyzer_test __initdata;
+
+static int __init enable_analyzer_test(char *str)
+{
+ get_option(, _analyzer_test);
+ return 0;
+}
+early_param("function_prologue_analyzer_test", enable_analyzer_test);
+
+static void __init do_test_function_prologue_analyzer(void)
+{
+ extern unsigned long __start_mcount_loc[];
+ extern unsigned long __stop_mcount_loc[];
+ unsigned long count, i, errors;
+ int print_once;
+
+ count = __stop_mcount_loc - __start_mcount_loc;
+ errors = print_once = 0;
+ for (i = 0; i < count; i++) {
+ unsigned long addr, sp_off, fp_off;
+ int pos;
+ bool check;
+ char buf[60];
+
+ addr = __start_mcount_loc[i];
+ pos = analyze_function_prologue(addr, _off, _off);
+ check = ((pos != 0) || !sp_off || (sp_off <= fp_off));
+ if (check)
+ errors++;
+ if (check || (start_analyzer_test > 1)) {
+ if (!print_once) {
+ pr_debug(" po spfpsymbol\n");
+ pr_debug(" == ======\n");
+ print_once++;
+ }
+ sprint_symbol(buf, addr);
+ pr_debug("%5ld: %d 0x%03lx 0x%03lx %s\n",
+ i, pos, sp_off, fp_off, buf);
+ }
+ }
+ pr_debug("function prologue analyzer test: %ld errors\n", errors);
+}
+
+static int __init test_function_prologue_analyzer(void)
+{
+ if (start_analyzer_test)
+ do_test_function_prologue_analyzer();
+ return 0;
+}
+late_initcall(test_function_prologue_analyzer);
#endif /* CONFIG_STACK_TRACER */
#endif
--
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/
[RFC PATCH v2 0/5] ACPICA / debugger: Add in-kernel AML debugger support
This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it. A. Build the AML debugger In order to build the kernel support of AML debugger, the following kconfig items should be enabled: CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUGGER=y CONFIG_DEBUG_FS=y CONFIG_ACPI_DEBUGGER_USER=m The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type "make acpi". B. Load the AML debugger during runtime In order to use the in-kernel AML debugger, the following command should be executed using root user: # modprobe acpi_dbg # mount -t debugfs none /sys/kernel/debug # acpidbg C. Batch mode In order to support scripts, the userspace utility also supports single command batch mode: # acpidbg -b "help" # acpidbg -b "tables" # acpidbg -b "find _LID" # acpidbg -b "execute \_SB.LID0._LID" You can find the documentation about the ACPICA debugger commands in: https://acpica.org/sites/acpica/files/acpica-reference_17.pdf (The latest document can be found at https://acpica.org/documentation) And refer to the chapter - ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger. D. Unload the AML debugger during runtime After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel: # rmmod acpi_dbg The following tasks are not completed: 1. .flush() support in the kernel debugger IO driver. 2. multi-commands batch mode. 3. upstream the userspace acpidbg to the ACPICA upstream. Colin Ian King (1): ACPICA: Debugger: Remove unnecessary status check Lv Zheng (4): ACPICA: Debugger: Convert some mechanisms to OSPM specific ACPI / debugger: Add IO interface to access debugger functionalities tools/power/acpi: Add userspace AML interface support ACPI / debugger: Add module support for ACPI debugger drivers/acpi/Kconfig | 13 +- drivers/acpi/Makefile|1 + drivers/acpi/acpi_dbg.c | 818 ++ drivers/acpi/acpica/acdebug.h|2 +- drivers/acpi/acpica/acglobal.h |5 - drivers/acpi/acpica/dbinput.c| 100 +--- drivers/acpi/acpica/dbxface.c| 63 +-- drivers/acpi/acpica/utmutex.c| 17 - drivers/acpi/bus.c |1 + drivers/acpi/osl.c | 250 - include/acpi/acpiosxf.h | 18 +- include/acpi/acpixf.h| 11 + include/acpi/platform/aclinux.h |2 + include/acpi/platform/aclinuxex.h|9 + include/linux/acpi.h | 71 +++ tools/power/acpi/Makefile| 16 +- tools/power/acpi/tools/acpidbg/Makefile | 27 + tools/power/acpi/tools/acpidbg/acpidbg.c | 438 18 files changed, 1699 insertions(+), 163 deletions(-) create mode 100644 drivers/acpi/acpi_dbg.c create mode 100644 tools/power/acpi/tools/acpidbg/Makefile create mode 100644 tools/power/acpi/tools/acpidbg/acpidbg.c -- 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/
[PATCH v5 4/6] arm64: insn: add instruction decoders for ldp/stp and add/sub
A function prologue analyzer is a requisite for implementing stack tracer
and getting better views of stack usages on arm64.
To implement a function prologue analyzer, we have to be able to decode,
at least, stp, add, sub and mov instructions.
This patch adds decoders for those instructions, that are used solely
by stack tracer for now, but generic enough for other uses.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/insn.h | 18
arch/arm64/kernel/insn.c | 102 +
2 files changed, 120 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..8d5c538 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -165,6 +165,8 @@ enum aarch64_insn_ldst_type {
AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX,
AARCH64_INSN_LDST_LOAD_PAIR_POST_INDEX,
AARCH64_INSN_LDST_STORE_PAIR_POST_INDEX,
+ AARCH64_INSN_LDST_LOAD_PAIR,
+ AARCH64_INSN_LDST_STORE_PAIR,
};
enum aarch64_insn_adsb_type {
@@ -225,6 +227,8 @@ static __always_inline u32
aarch64_insn_get_##abbr##_value(void) \
__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800)
__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(stp, 0x7FC0, 0x2900)
+__AARCH64_INSN_FUNCS(ldp, 0x7FC0, 0x2940)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC0, 0x2980)
@@ -277,6 +281,7 @@ __AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
__AARCH64_INSN_FUNCS(br, 0xFC1F, 0xD61F)
__AARCH64_INSN_FUNCS(blr, 0xFC1F, 0xD63F)
__AARCH64_INSN_FUNCS(ret, 0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(eret, 0x, 0xD69F00E0)
#undef __AARCH64_INSN_FUNCS
@@ -370,6 +375,19 @@ bool aarch32_insn_is_wide(u32 insn);
u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
u32 aarch32_insn_mcr_extract_opc2(u32 insn);
u32 aarch32_insn_mcr_extract_crm(u32 insn);
+int aarch64_insn_decode_add_sub_imm(u32 insn,
+ enum aarch64_insn_register *dst,
+ enum aarch64_insn_register *src,
+ int *imm,
+ enum aarch64_insn_variant *variant,
+ enum aarch64_insn_adsb_type *type);
+int aarch64_insn_decode_load_store_pair(u32 insn,
+ enum aarch64_insn_register *reg1,
+ enum aarch64_insn_register *reg2,
+ enum aarch64_insn_register *base,
+ int *offset,
+ enum aarch64_insn_variant *variant,
+ enum aarch64_insn_ldst_type *type);
#endif /* __ASSEMBLY__ */
#endif /* __ASM_INSN_H */
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index c08b9ad..b56a66c 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -33,6 +33,7 @@
#include
#define AARCH64_INSN_SF_BITBIT(31)
+#define AARCH64_INSN_S_BIT BIT(29)
#define AARCH64_INSN_N_BIT BIT(22)
static int aarch64_insn_encoding_class[] = {
@@ -1141,3 +1142,104 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
{
return insn & CRM_MASK;
}
+
+enum aarch64_insn_register aarch64_insn_extract_reg_num(u32 insn,
+ enum aarch64_insn_register_type type)
+{
+ int shift;
+
+ switch (type) {
+ case AARCH64_INSN_REGTYPE_RT:
+ case AARCH64_INSN_REGTYPE_RD:
+ shift = 0;
+ break;
+ case AARCH64_INSN_REGTYPE_RN:
+ shift = 5;
+ break;
+ case AARCH64_INSN_REGTYPE_RT2:
+ case AARCH64_INSN_REGTYPE_RA:
+ shift = 10;
+ break;
+ case AARCH64_INSN_REGTYPE_RM:
+ shift = 16;
+ break;
+ default:
+ pr_err("%s: unknown register type decoding %d\n", __func__,
+ type);
+ return ~0L;
+ }
+
+ return (insn & (GENMASK(4, 0) << shift)) >> shift;
+}
+
+int aarch64_insn_decode_add_sub_imm(u32 insn,
+ enum aarch64_insn_register *dst,
+ enum aarch64_insn_register *src,
+ int *imm,
+ enum aarch64_insn_variant *variant,
+ enum aarch64_insn_adsb_type *type)
+{
+ if (aarch64_insn_is_add_imm(insn))
+ *type = ((insn) & AARCH64_INSN_S_BIT) ?
+ AARCH64_INSN_ADSB_ADD_SETFLAGS :
+ AARCH64_INSN_ADSB_ADD;
+ else if (aarch64_insn_is_sub_imm(insn))
+ *type = ((insn) & AARCH64_INSN_S_BIT) ?
+
[PATCH v5 5/6] arm64: ftrace: add arch-specific stack tracer
Stack tracer on arm64, check_stack(), is uniqeue in the following
points:
* analyze a function prologue of a traced function to estimate a more
accurate stack pointer value, replacing naive ' + 0x10.'
* use walk_stackframe(), instead of slurping stack contents as orignal
check_stack() does, to identify a stack frame and a stack index (height)
for every callsite.
Regarding a function prologue analyzer, there is no guarantee that we can
handle all the possible patterns of function prologue as gcc does not use
any fixed templates to generate them. 'Instruction scheduling' is another
issue here.
Nevertheless, the current version will surely cover almost all the cases
in the kernel image and give us useful information on stack pointers.
So this patch utilizes a function prologue only for stack tracer, and
does not affect the behaviors of existing stacktrace functions.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/stacktrace.h |4 +
arch/arm64/kernel/ftrace.c | 64
arch/arm64/kernel/stacktrace.c | 185 ++-
3 files changed, 250 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/stacktrace.h
b/arch/arm64/include/asm/stacktrace.h
index 7318f6d..47b4832 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -25,5 +25,9 @@ struct stackframe {
extern int unwind_frame(struct stackframe *frame);
extern void walk_stackframe(struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data);
+#ifdef CONFIG_STACK_TRACER
+struct stack_trace;
+extern void save_stack_trace_sp(struct stack_trace *trace, unsigned long *sp);
+#endif
#endif /* __ASM_STACKTRACE_H */
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 314f82d..46bfe37 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -9,6 +9,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -16,6 +17,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DYNAMIC_FTRACE
/*
@@ -173,3 +175,65 @@ int ftrace_disable_ftrace_graph_caller(void)
}
#endif /* CONFIG_DYNAMIC_FTRACE */
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#ifdef CONFIG_STACK_TRACER
+static unsigned long stack_trace_sp[STACK_TRACE_ENTRIES];
+static unsigned long raw_stack_trace_max_size;
+
+void check_stack(unsigned long ip, unsigned long *stack)
+{
+ unsigned long this_size, flags;
+ unsigned long top;
+ int i, j;
+
+ this_size = ((unsigned long)stack) & (THREAD_SIZE-1);
+ this_size = THREAD_SIZE - this_size;
+
+ if (this_size <= raw_stack_trace_max_size)
+ return;
+
+ /* we do not handle an interrupt stack yet */
+ if (!object_is_on_stack(stack))
+ return;
+
+ local_irq_save(flags);
+ arch_spin_lock(_stack_lock);
+
+ /* check again */
+ if (this_size <= raw_stack_trace_max_size)
+ goto out;
+
+ /* find out stack frames */
+ stack_trace_max.nr_entries = 0;
+ stack_trace_max.skip = 0;
+ save_stack_trace_sp(_trace_max, stack_trace_sp);
+ stack_trace_max.nr_entries--; /* for the last entry ('-1') */
+
+ /* calculate a stack index for each function */
+ top = ((unsigned long)stack & ~(THREAD_SIZE-1)) + THREAD_SIZE;
+ for (i = 0; i < stack_trace_max.nr_entries; i++)
+ stack_trace_index[i] = top - stack_trace_sp[i];
+ raw_stack_trace_max_size = this_size;
+
+ /* Skip over the overhead of the stack tracer itself */
+ for (i = 0; i < stack_trace_max.nr_entries; i++)
+ if (stack_trace_max.entries[i] == ip)
+ break;
+
+ stack_trace_max.nr_entries -= i;
+ for (j = 0; j < stack_trace_max.nr_entries; j++) {
+ stack_trace_index[j] = stack_trace_index[j + i];
+ stack_trace_max.entries[j] = stack_trace_max.entries[j + i];
+ }
+ stack_trace_max_size = stack_trace_index[0];
+
+ if (task_stack_end_corrupted(current)) {
+ WARN(1, "task stack is corrupted.\n");
+ stack_trace_print();
+ }
+
+ out:
+ arch_spin_unlock(_stack_lock);
+ local_irq_restore(flags);
+}
+#endif /* CONFIG_STACK_TRACER */
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 5fd3477..4ee052a 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -23,6 +23,144 @@
#include
+#ifdef CONFIG_STACK_TRACER
+/*
+ * This function parses a function prologue of a traced function and
+ * determines its stack size.
+ * A return value indicates a location of @pc in a function prologue.
+ * @return value:
+ *
+ * 1:
+ * sub sp, sp, #XXsub sp, sp, #XX
+ * 2:
+ * stp x29, x30, [sp, #YY]stp x29, x30, [sp, #--ZZ]!
+ * 3:
+ * add x29, sp, #YY
[PATCH v5 3/6] ftrace: allow arch-specific stack tracer
A stack frame may be used in a different way depending on cpu architecture.
Thus it is not always appropriate to slurp the stack contents, as current
check_stack() does, in order to calcurate a stack index (height) at a given
function call. At least not on arm64.
In addition, there is a possibility that we will mistakenly detect a stale
stack frame which has not been overwritten.
This patch makes check_stack() a weak function so as to later implement
arch-specific version.
Signed-off-by: AKASHI Takahiro
---
include/linux/ftrace.h | 10 ++
kernel/trace/trace_stack.c | 80
2 files changed, 53 insertions(+), 37 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 6cd8c0e..fdc2ca5 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -263,7 +263,17 @@ static inline void ftrace_kill(void) { }
#endif /* CONFIG_FUNCTION_TRACER */
#ifdef CONFIG_STACK_TRACER
+#define STACK_TRACE_ENTRIES 500
+
+struct stack_trace;
+
+extern unsigned stack_trace_index[];
+extern struct stack_trace stack_trace_max;
+extern unsigned long stack_trace_max_size;
+extern arch_spinlock_t max_stack_lock;
+
extern int stack_tracer_enabled;
+void stack_trace_print(void);
int
stack_trace_sysctl(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index 8abf1ba..e34392e 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -16,24 +16,22 @@
#include "trace.h"
-#define STACK_TRACE_ENTRIES 500
-
static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
{ [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-static unsigned stack_dump_index[STACK_TRACE_ENTRIES];
+unsigned stack_trace_index[STACK_TRACE_ENTRIES];
/*
* Reserve one entry for the passed in ip. This will allow
* us to remove most or all of the stack size overhead
* added by the stack tracer itself.
*/
-static struct stack_trace max_stack_trace = {
+struct stack_trace stack_trace_max = {
.max_entries= STACK_TRACE_ENTRIES - 1,
.entries= _dump_trace[0],
};
-static unsigned long max_stack_size;
-static arch_spinlock_t max_stack_lock =
+unsigned long stack_trace_max_size;
+arch_spinlock_t max_stack_lock =
(arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
static DEFINE_PER_CPU(int, trace_active);
@@ -42,30 +40,38 @@ static DEFINE_MUTEX(stack_sysctl_mutex);
int stack_tracer_enabled;
static int last_stack_tracer_enabled;
-static inline void print_max_stack(void)
+void stack_trace_print(void)
{
long i;
int size;
pr_emerg("DepthSize Location(%d entries)\n"
"- \n",
- max_stack_trace.nr_entries);
+ stack_trace_max.nr_entries);
- for (i = 0; i < max_stack_trace.nr_entries; i++) {
+ for (i = 0; i < stack_trace_max.nr_entries; i++) {
if (stack_dump_trace[i] == ULONG_MAX)
break;
- if (i+1 == max_stack_trace.nr_entries ||
+ if (i+1 == stack_trace_max.nr_entries ||
stack_dump_trace[i+1] == ULONG_MAX)
- size = stack_dump_index[i];
+ size = stack_trace_index[i];
else
- size = stack_dump_index[i] - stack_dump_index[i+1];
+ size = stack_trace_index[i] - stack_trace_index[i+1];
- pr_emerg("%3ld) %8d %5d %pS\n", i, stack_dump_index[i],
+ pr_emerg("%3ld) %8d %5d %pS\n", i, stack_trace_index[i],
size, (void *)stack_dump_trace[i]);
}
}
-static inline void
+/*
+ * When arch-specific code overides this function, the following
+ * data should be filled up, assuming max_stack_lock is held to
+ * prevent concurrent updates.
+ * stack_trace_index[]
+ * stack_trace_max
+ * stack_trace_max_size
+ */
+void __weak
check_stack(unsigned long ip, unsigned long *stack)
{
unsigned long this_size, flags; unsigned long *p, *top, *start;
@@ -78,7 +84,7 @@ check_stack(unsigned long ip, unsigned long *stack)
/* Remove the frame of the tracer */
this_size -= frame_size;
- if (this_size <= max_stack_size)
+ if (this_size <= stack_trace_max_size)
return;
/* we do not handle interrupt stacks yet */
@@ -103,18 +109,18 @@ check_stack(unsigned long ip, unsigned long *stack)
this_size -= tracer_frame;
/* a race could have already updated it */
- if (this_size <= max_stack_size)
+ if (this_size <= stack_trace_max_size)
goto out;
- max_stack_size = this_size;
+ stack_trace_max_size = this_size;
- max_stack_trace.nr_entries = 0;
-
[PATCH v5 2/6] arm64: ftrace: fix a stack tracer's output under function graph tracer
Function graph tracer modifies a return address (LR) in a stack frame
to hook a function return. This will result in many useless entries
(return_to_handler) showing up in a stack tracer's output.
This patch replaces such entries with originals values preserved in
current->ret_stack[].
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/ftrace.h |2 ++
arch/arm64/kernel/stacktrace.c | 21 +
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index c5534fa..3c60f37 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -28,6 +28,8 @@ struct dyn_arch_ftrace {
extern unsigned long ftrace_graph_call;
+extern void return_to_handler(void);
+
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
/*
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ccb6078..5fd3477 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -17,6 +17,7 @@
*/
#include
#include
+#include
#include
#include
@@ -73,6 +74,9 @@ struct stack_trace_data {
struct stack_trace *trace;
unsigned int no_sched_functions;
unsigned int skip;
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ unsigned int ret_stack_index;
+#endif
};
static int save_trace(struct stackframe *frame, void *d)
@@ -81,6 +85,20 @@ static int save_trace(struct stackframe *frame, void *d)
struct stack_trace *trace = data->trace;
unsigned long addr = frame->pc;
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ if (addr == (unsigned long)return_to_handler - AARCH64_INSN_SIZE) {
+ /*
+* This is a case where function graph tracer has
+* modified a return address (LR) in a stack frame
+* to hook a function return.
+* So replace it to an original value.
+*/
+ frame->pc = addr =
+ current->ret_stack[data->ret_stack_index--].ret
+ - AARCH64_INSN_SIZE;
+ }
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
if (data->no_sched_functions && in_sched_functions(addr))
return 0;
if (data->skip) {
@@ -100,6 +118,9 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
data.trace = trace;
data.skip = trace->skip;
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ data.ret_stack_index = current->curr_ret_stack;
+#endif
if (tsk != current) {
data.no_sched_functions = 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 v5 1/6] arm64: ftrace: modify a stack frame in a safe way
Function graph tracer modifies a return address (LR) in a stack frame by
calling ftrace_prepare_return() in a traced function's function prologue.
The current code does this modification before preserving an original
address at ftrace_push_return_trace() and there is always a small window
of inconsistency when an interrupt occurs.
This doesn't matter, as far as an interrupt stack is introduced, because
stack tracer won't be invoked in an interrupt context. But it would be
better to proactively minimize such a window by moving the LR modification
after ftrace_push_return_trace().
Signed-off-by: AKASHI Takahiro
---
arch/arm64/kernel/ftrace.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index c851be7..314f82d 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -125,23 +125,20 @@ void prepare_ftrace_return(unsigned long *parent,
unsigned long self_addr,
* on other archs. It's unlikely on AArch64.
*/
old = *parent;
- *parent = return_hooker;
trace.func = self_addr;
trace.depth = current->curr_ret_stack + 1;
/* Only trace if the calling function expects to */
- if (!ftrace_graph_entry()) {
- *parent = old;
+ if (!ftrace_graph_entry())
return;
- }
err = ftrace_push_return_trace(old, self_addr, ,
frame_pointer);
- if (err == -EBUSY) {
- *parent = old;
+ if (err == -EBUSY)
return;
- }
+ else
+ *parent = return_hooker;
}
#ifdef CONFIG_DYNAMIC_FTRACE
--
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 v5 0/6] arm64: ftrace: fix incorrect output from stack tracer
This is the fifth patch series for fixing stack tracer on arm64.
The original issue was reported by Jungseok[1], and then I found more
issues[2].
We don't have to care about the original issue because the root cause
(patch "ARM64: unwind: Fix PC calculation") has been reverted in v4.3.
I address here all the issues and implement fixes described in [2] except
for interrupt-triggered problems(II-3) and leaf function(II-5). Recent
discussions[3] about introducing a dedicated interrupt stack suggests that
we may avoid walking through from an interrupt stack to a process stack.
(So interrupt-stack patch is a prerequisite.)
Basically,
patch1 is a proactive improvement of function_graph tracer.
patch2 corresponds to II-4(functions under function_graph tracer).
patch3, 4 and 5 correspond to II-1(slurping stack) and II-2(differences
between x86 and arm64).
patch6 is a function prologue analyzer test. This won't attest
the correctness of the functionality, but it can suggest that all
the traced functions are treated properly by this function.
(Please note that patch3 has already been queued in Steven's for-next.)
I tested the code with v4.3 + Jungseok's patch v5[4].
Changes from v4:
- removed a patch("arm64: ftrace: adjust callsite addresses examined
by stack tracer")
- added a function prologue analyzer test(patch 6)
Changes from v3:
- fixed build errors/warnings reported by kbuild test robot
- addressed Steven's comments around check_stack()
- removed a patch ("arm64: ftrace: allow for tracing leaf functions")
I don't remember why I thought this was necessary, but anyhow "-pg" seems
to disable omit-leaf-stack-frame.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355920.html
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368003.html
[4]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/378699.html
AKASHI Takahiro (6):
arm64: ftrace: modify a stack frame in a safe way
arm64: ftrace: fix a stack tracer's output under function graph
tracer
ftrace: allow arch-specific stack tracer
arm64: insn: add instruction decoders for ldp/stp and add/sub
arm64: ftrace: add arch-specific stack tracer
arm64: ftrace: add a test of function prologue analyzer
arch/arm64/include/asm/ftrace.h |2 +
arch/arm64/include/asm/insn.h | 18 +++
arch/arm64/include/asm/stacktrace.h |4 +
arch/arm64/kernel/ftrace.c | 75 +-
arch/arm64/kernel/insn.c| 102 ++
arch/arm64/kernel/stacktrace.c | 258 ++-
include/linux/ftrace.h | 10 ++
kernel/trace/trace_stack.c | 80 ++-
8 files changed, 502 insertions(+), 47 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Sparc
On Fri, 6 Nov 2015, Julian Calaby wrote: > Hi Linus, > > On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds > wrote: > > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds > > wrote: > >> > >> Not that this *matters*, but it's a bit odd to have to cast constants > >> to perfectly regular C types. > > > > Looking around with "git grep", there's a few more of these. > > > > - btrfs seems to like "(unsigned long)-1" > > > >There's a few other users of that too, including more sparc uses. > > > > - scsi/qla seems to like "(unsigned long)" > > > > - fmdrv_common.h seems to like "((unsigned long)1< > > > along with a smattering of random noise all over of "(unsigned long) > > n" where 'n' is some integer. > > > > Apparently people aren't as aware of the normal "ul" postfix syntax as > > I would have expected. That said, it's a hundred-odd cases in all of > > the kernel, so it's still fairly rare. > > Maybe this is something the kernel-janitors team should look at? (CC'd) Do you have some concrete examples of the code that is undesirable? thanks, julia -- 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] clk: add CS2000 Fractional-N driver
Hi again
ping again ?
> [R] 森本 wrote:
> >
> > From: Kuninori Morimoto
> >
> > This patch adds CS2000 Fractional-N driver as clock provider.
> >
> > Signed-off-by: Kuninori Morimoto
> > ---
> > v4 -> v5
> >
> > - remove "clock-frequency"
> > - use dev on clk_register()
> > - remove CLK_IS_BASIC
> > - .enable -> .prepare since it is using I2C
> > . .disabe -> .unprepare since it is using I2C
> >
> > .../devicetree/bindings/clock/cs2000-cp.txt| 22 +
> > drivers/clk/Kconfig| 6 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/clk-cs2000-cp.c| 510
> > +
> > 4 files changed, 539 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > create mode 100644 drivers/clk/clk-cs2000-cp.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > new file mode 100644
> > index 000..54e6df0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > @@ -0,0 +1,22 @@
> > +CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
> > +
> > +Required properties:
> > +
> > +- compatible: "cirrus,cs2000-cp"
> > +- reg: The chip select number on the I2C bus
> > +- clocks: common clock binding for CLK_IN, XTI/REF_CLK
> > +- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk
> > +- #clock-cells:must be <0>
> > +
> > +Example:
> > +
> > + {
> > + ...
> > + cs2000: clk_multiplier@4f {
> > + #clock-cells = <0>;
> > + compatible = "cirrus,cs2000-cp";
> > + reg = <0x4f>;
> > + clocks = <_sound 0>, <_clk>;
> > + clock-names = "clk_in", "ref_clk";
> > + };
> > +};
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 42f7120..0e961b2 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -95,6 +95,12 @@ config COMMON_CLK_CDCE925
> > Given a target output frequency, the driver will set the PLL and
> > divider to best approximate the desired output.
> >
> > +config COMMON_CLK_CS2000_CP
> > + tristate "Clock driver for CS2000 Fractional-N Clock Synthesizer &
> > Clock Multiplier"
> > + depends on I2C
> > + help
> > + If you say yes here you get support for the CS2000 clock multiplier.
> > +
> > config COMMON_CLK_S2MPS11
> > tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> > depends on MFD_SEC_CORE
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index 9d31e2c..2fb77a8 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) +=
> > clk-axi-clkgen.o
> > obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
> > obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> > obj-$(CONFIG_COMMON_CLK_CDCE706) += clk-cdce706.o
> > +obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
> > obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
> > obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
> > obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
> > diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
> > new file mode 100644
> > index 000..71d9340
> > --- /dev/null
> > +++ b/drivers/clk/clk-cs2000-cp.c
> > @@ -0,0 +1,510 @@
> > +/*
> > + * CS2000 -- CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock
> > Multiplier
> > + *
> > + * Copyright (C) 2015 Renesas Electronics Corporation
> > + * Kuninori Morimoto
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define CH_MAX 4
> > +
> > +#define DEVICE_ID 0x1
> > +#define DEVICE_CTRL0x2
> > +#define DEVICE_CFG10x3
> > +#define DEVICE_CFG20x4
> > +#define GLOBAL_CFG 0x5
> > +#define Ratio_Add(x, nth) (6 + (x * 4) + (nth))
> > +#define Ratio_Val(x, nth) ((x >> (24 - (8 * nth))) & 0xFF)
> > +#define Val_Ratio(x, nth) ((x & 0xFF) << (24 - (8 * nth)))
> > +#define FUNC_CFG1 0x16
> > +#define FUNC_CFG2 0x17
> > +
> > +/* DEVICE_CTRL */
> > +#define PLL_UNLOCK (1 << 7)
> > +
> > +/* DEVICE_CFG1 */
> > +#define RSEL(x)(((x) & 0x3) << 3)
> > +#define RSEL_MASK RSEL(0x3)
> > +#define ENDEV1 (0x1)
> > +
> > +/* GLOBAL_CFG */
> > +#define ENDEV2 (0x1)
> > +
> > +#define CH_SIZE_ERR(ch)((ch < 0) || (ch >= CH_MAX))
> > +#define hw_to_priv(_hw)container_of(_hw, struct cs2000_priv,
> > hw)
> > +#define priv_to_client(priv) (priv->client)
> > +#define priv_to_dev(priv) (&(priv_to_client(priv)->dev))
> > +
> > +#define CLK_IN 0
> >
[GIT PULL] Please pull powerpc/linux.git powerpc-4.4-1 tag
Hi Linus, Please pull powerpc updates for 4.4: The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c: Linux 4.3-rc3 (2015-09-27 07:50:08 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.4-1 for you to fetch changes up to 8bdf2023e238ce2262d0cf1aca78785dc46e15db: Merge branch 'next' of git://git.denx.de/linux-denx-agust into next (2015-11-05 19:35:12 +1100) powerpc updates for 4.4 - Kconfig: remove BE-only platforms from LE kernel build from Boqun Feng - Refresh ps3_defconfig from Geoff Levand - Emit GNU & SysV hashes for the vdso from Michael Ellerman - Define an enum for the bolted SLB indexes from Anshuman Khandual - Use a local to avoid multiple calls to get_slb_shadow() from Michael Ellerman - Add gettimeofday() benchmark from Michael Neuling - Avoid link stack corruption in __get_datapage() from Michael Neuling - Add virt_to_pfn and use this instead of opencoding from Aneesh Kumar K.V - Add ppc64le_defconfig from Michael Ellerman - pseries: extract of_helpers module from Andy Shevchenko - Correct string length in pseries_of_derive_parent() from Nathan Fontenot - Free the MSI bitmap if it was slab allocated from Denis Kirjanov - Shorten irq_chip name for the SIU from Christophe Leroy - Wait 1s for secondaries to enter OPAL during kexec from Samuel Mendoza-Jonas - Fix _ALIGN_* errors due to type difference. from Aneesh Kumar K.V - powerpc/pseries/hvcserver: don't memset pi_buff if it is null from Colin Ian King - Disable hugepd for 64K page size. from Aneesh Kumar K.V - Differentiate between hugetlb and THP during page walk from Aneesh Kumar K.V - Make PCI non-optional for pseries from Michael Ellerman - Individual System V IPC system calls from Sam bobroff - Add selftest of unmuxed IPC calls from Michael Ellerman - discard .exit.data at runtime from Stephen Rothwell - Delete old orphaned PrPMC 280/2800 DTS and boot file. from Paul Gortmaker - Use of_get_next_parent to simplify code from Christophe Jaillet - Paginate some xmon output from Sam bobroff - Add some more elements to the xmon PACA dump from Michael Ellerman - Allow the tm-syscall selftest to build with old headers from Michael Ellerman - Run EBB selftests only on POWER8 from Denis Kirjanov - Drop CONFIG_TUNE_CELL in favour of CONFIG_CELL_CPU from Michael Ellerman - Avoid reference to potentially freed memory in prom.c from Christophe Jaillet - Quieten boot wrapper output with run_cmd from Geoff Levand - EEH fixes and cleanups from Gavin Shan - Fix recursive fenced PHB on Broadcom shiner adapter from Gavin Shan - Use of_get_next_parent() in of_get_ibm_chip_id() from Michael Ellerman - Fix section mismatch warning in msi_bitmap_alloc() from Denis Kirjanov - Fix ps3-lpm white space from Rudhresh Kumar J - Fix ps3-vuart null dereference from Colin King - nvram: Add missing kfree in error path from Christophe Jaillet - nvram: Fix function name in some errors messages. from Christophe Jaillet - drivers/macintosh: adb: fix misleading Kconfig help text from Aaro Koskinen - agp/uninorth: fix a memleak in create_gatt_table from Denis Kirjanov - cxl: Free virtual PHB when removing from Andrew Donnellan - scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target from Michael Ellerman - scripts/kconfig/Makefile: Fix KBUILD_DEFCONFIG check when building with O= from Michael Ellerman - Freescale updates from Scott: Highlights include 64-bit book3e kexec/kdump support, a rework of the qoriq clock driver, device tree changes including qoriq fman nodes, support for a new 85xx board, and some fixes. - MPC5xxx updates from Anatolij: Highlights include a driver for MPC512x LocalPlus Bus FIFO with its device tree binding documentation, mpc512x device tree updates and some minor fixes. Aaro Koskinen (1): drivers/macintosh: adb: fix misleading Kconfig help text Alexander Popov (2): powerpc/512x: add LocalPlus Bus FIFO device driver powerpc/512x: add a device tree binding for LocalPlus Bus FIFO Andrew Donnellan (2): powerpc/pci: export pcibios_free_controller() cxl: Free virtual PHB when removing Andy Fleming (1): powerpc/85xx: Add support for Varisys Cyrus board Andy Shevchenko (5): powerpc/pseries: extract of_helpers module powerpc/pseries: fix a potential memory leak powerpc/pseries: replace kmalloc + strlcpy powerpc/pseries: handle nodes without '/' powerpc/pseries: re-use code from of_helpers module Aneesh Kumar K.V (4): powerpc/mm: Add virt_to_pfn and use this instead of opencoding powerpc: Fix _ALIGN_* errors due to type difference. powerpc/mm: Disable hugepd for 64K page size. powerpc/mm: Differentiate between hugetlb and THP during page walk Anshuman
RE: [PATCH] arm: kernel: utilize hrtimer based broadcast
Hi, Could you help to review this patch? Thanks. Best Regards, Alison Wang > On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote: > > Hrtimer based broadcast is used on ARM platform. It can be registered > > as the tick broadcast device in the absence of a real external clock; > > device. > > > > Signed-off-by: Alison Wang > > This looks sensible to me. FWIW: > > Acked-by: Mark Rutland > > Thanks, > Mark. > > > --- > > arch/arm/kernel/time.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index > > a66e37e..a9bc73c 100644 > > --- a/arch/arm/kernel/time.c > > +++ b/arch/arm/kernel/time.c > > @@ -12,6 +12,7 @@ > > * reading the RTC at bootup, etc... > > */ > > #include > > +#include > > #include > > #include > > #include > > @@ -121,5 +122,7 @@ void __init time_init(void) > > of_clk_init(NULL); > > #endif > > clocksource_of_init(); > > + > > + tick_setup_hrtimer_broadcast(); > > } > > } > > -- > > 2.1.0.27.g96db324 > > -- 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 v1] mm: hwpoison: adjust for new thp refcounting
On 11/06/2015 01:11 AM, Naoya Horiguchi wrote: > In the new refcounting, we no longer use tail->_mapcount to keep tail's > refcount, and thereby we can simplify get_hwpoison_page() and remove > put_hwpoison_page() (by replacing with put_page()). This is confusing for the reader (and some static analysis tools): this adds put_page()s without corresponding get_page()s. Could we instead macro put_hwpoison_page() as put_page() for the sake of readability? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()
Here's the revised patch:
vfs: clear remainder of 'full_fds_bits' in dup_fd()
This fixes a bug from commit f3f86e33dc3d ("vfs: Fix pathological
performance case for __alloc_fd()").
v2: refactor to share fd bitmap copying code
Signed-off-by: Eric Biggers
---
fs/file.c | 64 +++
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 6f6eb2b..a6ff7c3 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -60,8 +60,31 @@ static void free_fdtable_rcu(struct rcu_head *rcu)
#define BITBIT_SIZE(nr)(BITBIT_NR(nr) * sizeof(long))
/*
- * Expand the fdset in the files_struct. Called with the files spinlock
- * held for write.
+ * Copy 'count' fd bits from the old table to the new table and clear the extra
+ * space if any. This does not copy the file pointers. Called with the files
+ * spinlock held for write.
+ */
+static void copy_fd_bitmaps(struct fdtable *nfdt, struct fdtable *ofdt,
+ unsigned int count)
+{
+ unsigned int cpy, set;
+
+ cpy = count / BITS_PER_BYTE;
+ set = (nfdt->max_fds - count) / BITS_PER_BYTE;
+ memcpy(nfdt->open_fds, ofdt->open_fds, cpy);
+ memset((char *)nfdt->open_fds + cpy, 0, set);
+ memcpy(nfdt->close_on_exec, ofdt->close_on_exec, cpy);
+ memset((char *)nfdt->close_on_exec + cpy, 0, set);
+
+ cpy = BITBIT_SIZE(count);
+ set = BITBIT_SIZE(nfdt->max_fds) - cpy;
+ memcpy(nfdt->full_fds_bits, ofdt->full_fds_bits, cpy);
+ memset((char *)nfdt->full_fds_bits + cpy, 0, set);
+}
+
+/*
+ * Copy all file descriptors from the old table to the new, expanded table and
+ * clear the extra space. Called with the files spinlock held for write.
*/
static void copy_fdtable(struct fdtable *nfdt, struct fdtable *ofdt)
{
@@ -72,19 +95,9 @@ static void copy_fdtable(struct fdtable *nfdt, struct
fdtable *ofdt)
cpy = ofdt->max_fds * sizeof(struct file *);
set = (nfdt->max_fds - ofdt->max_fds) * sizeof(struct file *);
memcpy(nfdt->fd, ofdt->fd, cpy);
- memset((char *)(nfdt->fd) + cpy, 0, set);
+ memset((char *)nfdt->fd + cpy, 0, set);
- cpy = ofdt->max_fds / BITS_PER_BYTE;
- set = (nfdt->max_fds - ofdt->max_fds) / BITS_PER_BYTE;
- memcpy(nfdt->open_fds, ofdt->open_fds, cpy);
- memset((char *)(nfdt->open_fds) + cpy, 0, set);
- memcpy(nfdt->close_on_exec, ofdt->close_on_exec, cpy);
- memset((char *)(nfdt->close_on_exec) + cpy, 0, set);
-
- cpy = BITBIT_SIZE(ofdt->max_fds);
- set = BITBIT_SIZE(nfdt->max_fds) - cpy;
- memcpy(nfdt->full_fds_bits, ofdt->full_fds_bits, cpy);
- memset(cpy+(char *)nfdt->full_fds_bits, 0, set);
+ copy_fd_bitmaps(nfdt, ofdt, ofdt->max_fds);
}
static struct fdtable * alloc_fdtable(unsigned int nr)
@@ -276,7 +289,7 @@ struct files_struct *dup_fd(struct files_struct *oldf, int
*errorp)
{
struct files_struct *newf;
struct file **old_fds, **new_fds;
- int open_files, size, i;
+ int open_files, i;
struct fdtable *old_fdt, *new_fdt;
*errorp = -ENOMEM;
@@ -333,13 +346,11 @@ struct files_struct *dup_fd(struct files_struct *oldf,
int *errorp)
open_files = count_open_files(old_fdt);
}
+ copy_fd_bitmaps(new_fdt, old_fdt, open_files);
+
old_fds = old_fdt->fd;
new_fds = new_fdt->fd;
- memcpy(new_fdt->open_fds, old_fdt->open_fds, open_files / 8);
- memcpy(new_fdt->close_on_exec, old_fdt->close_on_exec, open_files / 8);
- memcpy(new_fdt->full_fds_bits, old_fdt->full_fds_bits,
BITBIT_SIZE(open_files));
-
for (i = open_files; i != 0; i--) {
struct file *f = *old_fds++;
if (f) {
@@ -357,19 +368,8 @@ struct files_struct *dup_fd(struct files_struct *oldf, int
*errorp)
}
spin_unlock(>file_lock);
- /* compute the remainder to be cleared */
- size = (new_fdt->max_fds - open_files) * sizeof(struct file *);
-
- /* This is long word aligned thus could use a optimized version */
- memset(new_fds, 0, size);
-
- if (new_fdt->max_fds > open_files) {
- int left = (new_fdt->max_fds - open_files) / 8;
- int start = open_files / BITS_PER_LONG;
-
- memset(_fdt->open_fds[start], 0, left);
- memset(_fdt->close_on_exec[start], 0, left);
- }
+ /* clear the remainder */
+ memset(new_fds, 0, (new_fdt->max_fds - open_files) * sizeof(struct file
*));
rcu_assign_pointer(newf->fdt, new_fdt);
--
2.6.2
--
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/3] Documentation: Add minimal Mutt config for using Gmail
This patch provides a minimal configuration to set up Mutt for submitting plain text patches using Gmail. Signed-off-by: Eddie Kovsky --- Documentation/email-clients.txt | 32 1 file changed, 32 insertions(+) diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index d11c20b0e897..d2fb26a547f3 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -185,6 +185,38 @@ It should work with default settings. However, it's a good idea to set the "send_charset" to: set send_charset="us-ascii:utf-8" +Mutt is highly customizable. Here is a minimum configuration to start +using Mutt to send patches through Gmail: + +# .muttrc +# IMAP +set imap_user = 'yourusern...@gmail.com' +set imap_pass = 'yourpassword' +set spoolfile = imaps://imap.gmail.com/INBOX +set folder = imaps://imap.gmail.com/ +set record="imaps://imap.gmail.com/[Gmail]/Sent Mail" +set postponed="imaps://imap.gmail.com/[Gmail]/Drafts" +set mbox="imaps://imap.gmail.com/[Gmail]/All Mail" + +# SMTP +set smtp_url = "smtp://usern...@smtp.gmail.com:587/" +set smtp_pass = $imap_pass +set ssl_force_tls = yes # Require encrypted connection + +# Composition +set editor = `echo \$EDITOR` +set edit_headers = yes # See the headers when editing +set charset = UTF-8 # value of $LANG; also fallback for send_charset +# Sender, email address, and sign-off line must match +unset use_domain# because joe@localhost is just embarrassing +set realname = "YOUR NAME" +set from = "usern...@gmail.com" +set use_from = yes + +The Mutt docs have lots more information: +http://dev.mutt.org/trac/wiki/UseCases/Gmail +http://dev.mutt.org/doc/manual.html + ~~ Pine (TUI) -- 2.6.2 -- 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] livepatch: x86: bugfix about kASLR
When enable KASLR, livepatch will adjust old_addr of changed
function accordingly. So do the same thing for reloc.
[PATCH v1] https://lkml.org/lkml/2015/11/4/91
Reported-by: Cyril B.
Signed-off-by: Zhou Chengming
---
kernel/livepatch/core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 6e53441..db545cb 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -294,6 +294,12 @@ static int klp_write_object_relocations(struct module
*pmod,
for (reloc = obj->relocs; reloc->name; reloc++) {
if (!klp_is_module(obj)) {
+
+#if defined(CONFIG_RANDOMIZE_BASE)
+ /* If KASLR has been enabled, adjust old value
accordingly */
+ if (kaslr_enabled())
+ reloc->val += kaslr_offset();
+#endif
ret = klp_verify_vmlinux_symbol(reloc->name,
reloc->val);
if (ret)
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
From: a...@kernel.org [mailto:a...@kernel.org] > >Em Thu, Nov 05, 2015 at 02:08:48PM +, 平松雅巳 / HIRAMATU，MASAMI escreveu: >> From: Wang Nan [mailto:wangn...@huawei.com] >> > >> >It is possible that find_perf_probe_point_from_map() fails to find >> >symbol but still returns 0 because of an small error when coding: >> >find_perf_probe_point_from_map() set 'ret' to error code at first, >> >but also use it to hold return value of >> >kernel_get_symbol_address_by_name(). >> >> OK, I didn't expect that there is a symbol which can be found by >> kernel_get_symbol_address_by_name() but not by __find_kernel_function()... > >> Would you have any example of the error? >> >> > >> >This patch resets 'ret' to error even kernel_get_symbol_address_by_name() >> >success, so if !sym, the whole function returns error correctly. >> >> Hmm, that sounds tricky. I'd rather like to add *psym to >> kernel_get_symbol_address_by_name() >> to save symbol and don't use __find_kernel_function() instead. > >Tricky? I don't think so, suboptimal? possibly, but it fixes an error, >so should be processed quickly, right? I'm applying his patch and then >whatever improvement can be done on top. OK, then I'll send an improvement patch. Thanks, > >- Arnaldo
[PATCH 1/3] Documentation: Clarify use of Gmail for emailing patches
Clarify that Gmail can be used to send patches, provided you use Gmail as a server and avoid the Web UI. Signed-off-by: Eddie Kovsky --- Documentation/email-clients.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index aba85b39a400..ca38031c4762 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -250,7 +250,8 @@ Works. Use "Insert file..." or external editor. ~~ Gmail (Web GUI) -Does not work for sending patches. +Gmail works fine for sending patches provided you do NOT use the web interface +and just use Gmail as an IMAP server with a text based email client. Gmail web client converts tabs to spaces automatically. -- 2.6.2 -- 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/3] Documentation: Add note on sending files directly with Mutt
Like 'git send-email', Mutt can also be used to send patches generated with 'git format-patch'. This works regardless of the editor the contributor has set up to use with Mutt. Signed-off-by: Eddie Kovsky --- Documentation/email-clients.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index ca38031c4762..d11c20b0e897 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -176,6 +176,10 @@ To use 'vim' with mutt: if you want to include the patch inline. (a)ttach works fine without "set paste". +You can also generate patches with 'git format-patch' and then use Mutt +to send them: +$ mutt -H 0001-some-bug-fix.patch + Config options: It should work with default settings. However, it's a good idea to set the "send_charset" to: -- 2.6.2 -- 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 0/3] Documentation: Email client improvements
A recent mailing list discussion about developer tools extended over to Google+. https://plus.google.com/+DarrenHart/posts/EbVFWJu3FK9 Several members of the kernel community felt that improving the email client documentation would make it easier for new developers to get started submitting patches. This series introduces three updates to help new contributors get Mutt working as quickly as possible. * Clarify that Gmail is acceptable for sending patches, as long as it is used without the web interface. * Add instructions for sending files directly from Mutt without use of a specific editor. * Add a minimal Mutt configuration to use Gmail's IMAP servers to send text email. I tested this configuration using a mockup local user and my own Gmail account. Thanks Eddie Eddie Kovsky (3): Clarify use of Gmail for emailing patches Add note on sending files directly with Mutt Add minimal Mutt config for using Gmail Documentation/email-clients.txt | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) -- 2.6.2 -- 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: Question with maxcpus= parameter.
Thanks for your quick response, Raj. It's OL6 compatible with rhel6. zduan 在 2015/11/6 14:57, Raj, Ashok 写道: Hi Zduan do you know which distribution it is? This isn't a kernel bug. if you look at dmesg you should see how many CPUs were booted. But the sysfs files are created and the usermode script is bringing every cpu online. Tony mentioned this to me couple weeks ago when i was fixing another bug in maxcpus. I think you can safely remove the script and it should be fine. Cheers, Ashok On Fri, Nov 06, 2015 at 01:24:16PM +0800, Zhenzhong Duan wrote: Hi Maintainers, Recently we faced an cpu online issue with maxcpus= parameter. We want to have 4 cpus onlined at bootup, test 3.8.13-stable on an 72 cpus env with maxcpus=4, I found more cpus than 4 are onlined. It's the udev scripts make them onlined. But below script exist for a long time. ACTION=="add", KERNEL=="cpu[0-9]*", RUN+="/bin/bash -c 'echo 1 > /sys/devices/system/cpu/%k/online'" maxcpu= parameter didn't take effect, so is this a kernel bug? Or that script should be removed? Btw: 2.6.39 works fine, I checked udev log, seems CPU ADD event is only sent for 4cpus. Why the difference between 2.6.39 and 3.8.13? thanks zduan -- 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 v1] mm: hwpoison: adjust for new thp refcounting
Some mm-related BUG_ON()s could trigger from hwpoison code due to recent
changes in thp refcounting rule. This patch fixes them up.
In the new refcounting, we no longer use tail->_mapcount to keep tail's
refcount, and thereby we can simplify get_hwpoison_page() and remove
put_hwpoison_page() (by replacing with put_page()).
And another change is that tail's refcount is not transferred to the raw
page during thp split (more precisely, in new rule we don't take refcount
on tail page any more.) So when we need thp split, we have to transfer the
refcount properly to the 4kB soft-offlined page before migration.
thp split code goes into core code only when precheck (total_mapcount(head)
== page_count(head) - 1) passes to avoid useless split, where we assume that
one refcount is held by the caller of thp split and the others are taken
via mapping. To meet this assumption, this patch moves thp split part in
soft_offline_page() after get_any_page().
Signed-off-by: Naoya Horiguchi
---
- based on mmotm-2015-10-21-14-41 + Kirill's "[PATCH 0/4] Bugfixes for THP
refcounting" series.
---
include/linux/mm.h | 1 -
mm/hwpoison-inject.c | 2 +-
mm/memory-failure.c | 103 ++-
3 files changed, 37 insertions(+), 69 deletions(-)
diff --git mmotm-2015-10-21-14-41/include/linux/mm.h
mmotm-2015-10-21-14-41_patched/include/linux/mm.h
index a36f9fa4e4cd..ac3a9db4f3cf 100644
--- mmotm-2015-10-21-14-41/include/linux/mm.h
+++ mmotm-2015-10-21-14-41_patched/include/linux/mm.h
@@ -2173,7 +2173,6 @@ extern int memory_failure(unsigned long pfn, int trapno,
int flags);
extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
extern int unpoison_memory(unsigned long pfn);
extern int get_hwpoison_page(struct page *page);
-extern void put_hwpoison_page(struct page *page);
extern int sysctl_memory_failure_early_kill;
extern int sysctl_memory_failure_recovery;
extern void shake_page(struct page *p, int access);
diff --git mmotm-2015-10-21-14-41/mm/hwpoison-inject.c
mmotm-2015-10-21-14-41_patched/mm/hwpoison-inject.c
index 9d26fd9fefe4..5015679014c1 100644
--- mmotm-2015-10-21-14-41/mm/hwpoison-inject.c
+++ mmotm-2015-10-21-14-41_patched/mm/hwpoison-inject.c
@@ -55,7 +55,7 @@ static int hwpoison_inject(void *data, u64 val)
pr_info("Injecting memory failure at pfn %#lx\n", pfn);
return memory_failure(pfn, 18, MF_COUNT_INCREASED);
put_out:
- put_hwpoison_page(p);
+ put_page(p);
return 0;
}
diff --git mmotm-2015-10-21-14-41/mm/memory-failure.c
mmotm-2015-10-21-14-41_patched/mm/memory-failure.c
index a2c987df80eb..3be8884d032a 100644
--- mmotm-2015-10-21-14-41/mm/memory-failure.c
+++ mmotm-2015-10-21-14-41_patched/mm/memory-failure.c
@@ -882,15 +882,7 @@ int get_hwpoison_page(struct page *page)
{
struct page *head = compound_head(page);
- if (PageHuge(head))
- return get_page_unless_zero(head);
-
- /*
-* Thp tail page has special refcounting rule (refcount of tail pages
-* is stored in ->_mapcount,) so we can't call get_page_unless_zero()
-* directly for tail pages.
-*/
- if (PageTransHuge(head)) {
+ if (!PageHuge(head) && PageTransHuge(head)) {
/*
* Non anonymous thp exists only in allocation/free time. We
* can't handle such a case correctly, so let's give it up.
@@ -902,41 +894,12 @@ int get_hwpoison_page(struct page *page)
page_to_pfn(page));
return 0;
}
-
- if (get_page_unless_zero(head)) {
- if (PageTail(page))
- get_page(page);
- return 1;
- } else {
- return 0;
- }
}
- return get_page_unless_zero(page);
+ return get_page_unless_zero(head);
}
EXPORT_SYMBOL_GPL(get_hwpoison_page);
-/**
- * put_hwpoison_page() - Put refcount for memory error handling:
- * @page: raw error page (hit by memory error)
- */
-void put_hwpoison_page(struct page *page)
-{
- struct page *head = compound_head(page);
-
- if (PageHuge(head)) {
- put_page(head);
- return;
- }
-
- if (PageTransHuge(head))
- if (page != head)
- put_page(head);
-
- put_page(page);
-}
-EXPORT_SYMBOL_GPL(put_hwpoison_page);
-
/*
* Do all that is necessary to remove user space mappings. Unmap
* the pages and send SIGBUS to the processes if the data was dirty.
@@ -1158,10 +1121,12 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
pr_err("MCE: %#lx: thp split failed\n", pfn);
if (TestClearPageHWPoison(p))
num_poisoned_pages_sub(nr_pages);
- put_hwpoison_page(p);
+
[PATCH 2/2] usb: host: ehci-msm: Use posted data writes on AHB
This patch sets the AHBMODE to allow for posted data writes. This results in higher performance. Signed-off-by: Andy Gross --- drivers/usb/host/ehci-msm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c index c4f84c8..c23e285 100644 --- a/drivers/usb/host/ehci-msm.c +++ b/drivers/usb/host/ehci-msm.c @@ -57,8 +57,8 @@ static int ehci_msm_reset(struct usb_hcd *hcd) /* bursts of unspecified length. */ writel(0, USB_AHBBURST); - /* Use the AHB transactor */ - writel(0, USB_AHBMODE); + /* Use the AHB transactor, allow posted data writes */ + writel(0x8, USB_AHBMODE); /* Disable streaming mode and select host mode */ writel(0x13, USB_USBMODE); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Configure AHB to post data transfers
This patch configures the ChipIdea USB 2.0 controller found on Qualcomm platforms to post data transfers on the AHB bus. This yields approximately a 50% increase in performance. Andy Gross (2): usb: chipidea: msm: Use posted data writes on AHB usb: host: ehci-msm: Use posted data writes on AHB drivers/usb/chipidea/ci_hdrc_msm.c |3 ++- drivers/usb/host/ehci-msm.c|4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] usb: chipidea: msm: Use posted data writes on AHB
This patch sets the AHBMODE to allow for posted data writes. This results in higher performance. Signed-off-by: Andy Gross --- drivers/usb/chipidea/ci_hdrc_msm.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c index d79ecc0..3889809 100644 --- a/drivers/usb/chipidea/ci_hdrc_msm.c +++ b/drivers/usb/chipidea/ci_hdrc_msm.c @@ -25,7 +25,8 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event) case CI_HDRC_CONTROLLER_RESET_EVENT: dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n"); writel(0, USB_AHBBURST); - writel(0, USB_AHBMODE); + /* use AHB transactor, allow posted data writes */ + writel(0x8, USB_AHBMODE); usb_phy_init(ci->usb_phy); break; case CI_HDRC_CONTROLLER_STOPPED_EVENT: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ARM: add v7 LPAE multi-platform defconfig
> On Wednesday 04 November 2015 03:17:06 Huan Wang wrote: > > > On Tue, Oct 27, 2015 at 10:35:07PM +0800, Alison Wang wrote: > > > > v7 LPAE multi-platform defconfig is based on v7 multi-platform > > > > defconfig and adds LPAE support. > > > > > > > > This defconfig is verified on LS1021A which enables GIANFAR, I2C, > > > > WATCHDOG, AUDIO, EDMA and DSPI drivers, etc. > > > > > > > > Signed-off-by: Alison Wang > > > > > > I think this would be great if it also had: > > > > > > CONFIG_ARCH_VIRT=y > > > CONFIG_VIRTUALIZATION=y > > > CONFIG_KVM=y > > > > > > That would allow it to be used for KVM testing both as host and > guest. > > > > > > FWIW, I just tried booting this on my TC2, but I don't get any > > > output from there. Is it supposed to work on this platform? If not, > why not? > > > > > [Alison Wang] One question, does TC2 support LPAE? If so, we could try > > to find the reason and add it in this defconfig for armv7 LPAE support. > > Yes, I think we should enable all platforms that we enable in the normal > multi_v7_defconfig, if we decide to add a new one. Just remove the > platforms that are based on Cortex-A5/A8/A9, Scorpion or PJ4 rather than > A7/A12/A15/A17 or Krait. > [Alison Wang] Thanks for your advice. I will try to prepare a new one according to your advice. Best Regards, Alison Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/7] spi: tegra: remove redundant "depends on RESET_CONTROLLER"
2015-11-05 20:50 GMT+09:00 Mark Brown : > On Thu, Nov 05, 2015 at 08:15:24PM +0900, Masahiro Yamada wrote: >> ARCH_TEGRA selects RESET_CONTROLLER. >> The dependency "depends on RESET_CONTROLLER" is already met. > >> tristate "NVIDIA Tegra114 SPI Controller" >> depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST >> - depends on RESET_CONTROLLER && HAS_DMA >> + depends on HAS_DMA > > Again, this driver doesn't depend on ARCH_TEGRA. How come? Sorry, I have not been tracking this sub-system, so I do not get the "Again". The prompt says "NVIDIA Tegra114 SPI Controller". It sounds natural for me that this driver depends on ARCH_TEGRA. No? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/7] spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
2015-11-06 0:05 GMT+09:00 Mark Brown : > On Thu, Nov 05, 2015 at 09:32:15PM +0900, Masahiro Yamada wrote: > >> For compile test, right, "depends on RESET_CONTROLLER" is >> redundant in the first place. > >> For run-time on real SoCs,the driver failed at the following point >> without the reset-controller sub-system. > > Your changelog needs to say this clearly, right now what it's saying > clearly doesn't correspond to what the change does. OK. This series is RFC and my main focus in on the 1/7. I will wait for more comments against the first one. -- Best Regards Masahiro Yamada -- 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: Question with maxcpus= parameter.
Hi Zduan do you know which distribution it is? This isn't a kernel bug. if you look at dmesg you should see how many CPUs were booted. But the sysfs files are created and the usermode script is bringing every cpu online. Tony mentioned this to me couple weeks ago when i was fixing another bug in maxcpus. I think you can safely remove the script and it should be fine. Cheers, Ashok On Fri, Nov 06, 2015 at 01:24:16PM +0800, Zhenzhong Duan wrote: > Hi Maintainers, > > Recently we faced an cpu online issue with maxcpus= parameter. > > We want to have 4 cpus onlined at bootup, test 3.8.13-stable on an 72 cpus > env with maxcpus=4, I found more cpus than 4 are onlined. > It's the udev scripts make them onlined. But below script exist for a long > time. > ACTION=="add", KERNEL=="cpu[0-9]*", RUN+="/bin/bash -c 'echo 1 > > /sys/devices/system/cpu/%k/online'" > > maxcpu= parameter didn't take effect, so is this a kernel bug? Or that > script should be removed? > > Btw: 2.6.39 works fine, I checked udev log, seems CPU ADD event is only sent > for 4cpus. > Why the difference between 2.6.39 and 3.8.13? > > thanks > zduan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/7] reset: make RESET_CONTROLLER a select'ed option
Hi Arnd, 2015-11-05 23:49 GMT+09:00 Arnd Bergmann : > On Thursday 05 November 2015 20:15:21 Masahiro Yamada wrote: >> When I was implementing a new reset controller for my SoCs, >> I struggled to make my sub-menu shown under the reset >> controller menu. >> I noticed the Kconfig in reset sub-system are screwed up due to two >> config options (ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER). >> >> I think only the former should be select'ed by relevant SoCs, >> but in fact the latter is also select'ed here and there. >> Mixing "select" to a user-configurable option is a mess. >> >> Finally, I started to wonder whether it could be more simpler? >> >> The first patch drops ARCH_HAS_RESET_CONTROLLER. >> RESET_CONTROLLER should be directly selected by SoCs. >> >> The rest of this series are minor clean ups in other >> sub-systems. >> I can postpone them if changes over cross sub-systems >> are not preferred. > > Thanks a lot for picking up this topic! It has been annoying me > for a while and I have submitted an experimental patch some time > ago, but not finished it myself. > > For some reason, I only see a subset of your patches here (patch 1, 4 and 6), > so I don't know exactly what you did. All the patches CCed linux-kernel@vger.kernel.org, so you can dig into LKML log or the following patchwork https://patchwork.kernel.org/project/LKML/list/ > For reference, you can find > my original patch below. Please check if I did things that your > series doesn't do, and whether those are still needed. Thanks. Yours looks mostly nice, and this work is worth continuing. (I am pleased to review it when you submit the next version.) I have some comments. [1] Why is ARCH_HAS_RESET_CONTROLLER select'ed by ARCH_MULTIPLATFORM, but not by others? This seems weird. We do not have such options like ARCH_HAS_PINCTRL, ARCH_HAS_COMMON_CLK... [2] The difference is that yours is adding per-driver options such as RESET_SOCFPGA, RESET_BERLIN, etc. I think this is a good idea. But, I notice lowlevel drivers select RESET_CONTROLLER, for example, RESET_SOCFPGA select RESET_CONTROLLER. We generally do the opposite in other subsystems, I think. For example, the whole of clk menu is guarded by "depends on COMMON_CLK". menu "Common Clock Framework" depends on COMMON_CLK endmenu Likewise for pinctrl. -- Best Regards Masahiro Yamada -- 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] arm64: defconfig: Enable samsung MFD and related configs
2015-11-06 14:27 GMT+09:00 Alim Akhtar : > Exynos7 based espresso board uses S2MPS15, a multifunction device. > This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by > the same. > > Signed-off-by: Alim Akhtar > --- > Changes since v1: > * updated the comment message to describe which platfrom uses it. > * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block. > > arch/arm64/configs/defconfig |4 > 1 file changed, 4 insertions(+) Reviewed-by: Krzysztof Kozlowski Catalin, Are you usually taking such arm64 defconfig changes or should they go through arm-soc? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH] f2fs: refactor __find_rev_next_{zero}_bit
In bitmaps of f2fs, bytes are sorted in ascending order, but bits in a byte are
sorted
in descending order. It seems to be the reason why __reverse_ulong is needed.
May I ask why f2fs bitmap apply such order?
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, October 23, 2015 12:36 AM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: refactor __find_rev_next_{zero}_bit
>
> Hi Chao,
>
> On Thu, Oct 22, 2015 at 07:24:01PM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Thursday, October 22, 2015 6:30 AM
> > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Subject: Re: [f2fs-dev] [PATCH] f2fs: refactor
> > > __find_rev_next_{zero}_bit
> > >
> > > On Wed, Oct 21, 2015 at 02:16:43PM -0700, Jaegeuk Kim wrote:
> > > > This patch refactors __find_rev_next_{zero}_bit which was disabled
> > > > previously due to bugs.
> >
> > Actually I didn't know the history here, could you please explain
> > details about the bugs? then I can do the review.
>
> When I disabled the existing function by:
>
> commit e19ef527aa32f057710ec842fe656bffc263b0bb
> Author: Jaegeuk Kim
> Date: Mon May 18 11:45:15 2015 -0700
>
> f2fs: avoid buggy functions
>
> I found a mismatch of results between the existing __find_rev_next_bit and
> f2fs_test_bit work. I remember it happened on
> __find_rev_next_bit sometimes by xfstests which include trim_fs.
> (I didn't get an error from __find_rev_zero_bit though.)
>
> Since I have no time to investigate the bug in more detail at that time, I
> just disabled it. But, now I'm trying to refactor the
flow to fix
> this.
>
> Thanks,
>
> >
> > Thanks,
> >
> > > >
> > > > Signed-off-by: Jaegeuk Kim
> > > > ---
> > > > fs/f2fs/segment.c | 106
> > > > +-
> > > > 1 file changed, 49 insertions(+), 57 deletions(-)
> > > >
> > > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index
> > > > f37c212..50afc93 100644
> > > > --- a/fs/f2fs/segment.c
> > > > +++ b/fs/f2fs/segment.c
> > > > @@ -29,6 +29,21 @@ static struct kmem_cache *discard_entry_slab;
> > > > static struct kmem_cache *sit_entry_set_slab; static struct
> > > > kmem_cache *inmem_entry_slab;
> > > >
> > > > +static unsigned long __reverse_ulong(unsigned char *str) {
> > > > + unsigned long tmp = 0;
> > > > + int shift = 24, idx = 0;
> > > > +
> > > > +#if BITS_PER_LONG == 64
> > > > + shift = 56;
> > > > +#endif
> > > > + while (shift >= 0) {
> > > > + tmp |= (unsigned long)str[idx++] << shift;
> > > > + shift -= BITS_PER_BYTE;
> > > > + }
> > > > + return tmp;
> > > > +}
> > > > +
> > > > /*
> > > > * __reverse_ffs is copied from include/asm-generic/bitops/__ffs.h
> > > > since
> > > > * MSB and LSB are reversed in a byte by f2fs_set_bit.
> > > > @@ -38,27 +53,31 @@ static inline unsigned long __reverse_ffs(unsigned
> > > > long word)
> > > > int num = 0;
> > > >
> > > > #if BITS_PER_LONG == 64
> > > > - if ((word & 0x) == 0) {
> > > > + if ((word & 0x) == 0)
> > >
> > > I fixed the sparse warning by modifying:
> > > if ((word & 0xUL) == 0)
> > >
> > > Thanks,
> > >
> > > > num += 32;
> > > > + else
> > > > word >>= 32;
> > > > - }
> > > > #endif
> > > > - if ((word & 0x) == 0) {
> > > > + if ((word & 0x) == 0)
> > > > num += 16;
> > > > + else
> > > > word >>= 16;
> > > > - }
> > > > - if ((word & 0xff) == 0) {
> > > > +
> > > > + if ((word & 0xff00) == 0)
> > > > num += 8;
> > > > + else
> > > > word >>= 8;
> > > > - }
> > > > +
> > > > if ((word & 0xf0) == 0)
> > > > num += 4;
> > > > else
> > > > word >>= 4;
> > > > +
> > > > if ((word & 0xc) == 0)
> > > > num += 2;
> > > > else
> > > > word >>= 2;
> > > > +
> > > > if ((word & 0x2) == 0)
> > > > num += 1;
> > > > return num;
> > > > @@ -68,26 +87,16 @@ static inline unsigned long __reverse_ffs(unsigned
> > > > long word)
> > > > * __find_rev_next(_zero)_bit is copied from lib/find_next_bit.c
> > > > because
> > > > * f2fs_set_bit makes MSB and LSB reversed in a byte.
> > > > * Example:
> > > > - * LSB <--> MSB
> > > > - * f2fs_set_bit(0, bitmap) => 0001
> > > > - * f2fs_set_bit(7, bitmap) => 1000
> > > > + * MSB <--> LSB
> > > > + * f2fs_set_bit(0, bitmap) => 1000
> > > > + * f2fs_set_bit(7, bitmap)
Re: [PATCH] goldfish: add goldfish match node for dt driver probe
Hi yalin,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.3 next-20151105]
url:
https://github.com/0day-ci/linux/commits/yalin-wang/goldfish-add-goldfish-match-node-for-dt-driver-probe/20151106-132647
config: x86_64-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/staging/goldfish/goldfish_nand.c:446:3: error: request for member
>> 'of_match_table' in something not a structure or union
.of_match_table = of_match_ptr(goldfish_nand_match),
^
vim +/of_match_table +446 drivers/staging/goldfish/goldfish_nand.c
440
441 static struct platform_driver goldfish_nand_driver = {
442 .probe = goldfish_nand_probe,
443 .remove = goldfish_nand_remove,
444 .driver = {
445 .name = "goldfish_nand"
> 446 .of_match_table = of_match_ptr(goldfish_nand_match),
447 }
448 };
449
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH] Staging: gdm72xx: Fix sparse warning
Fix following sparse warnings by adding new structure for user-space
data (struct data_us) in wm_ioctl.h:
drivers/staging/gdm72xx/gdm_wimax.c:381:37: warning: incorrect type in
argument 1 (different address spaces)
drivers/staging/gdm72xx/gdm_wimax.c:381:37:expected void [noderef]
*to
drivers/staging/gdm72xx/gdm_wimax.c:381:37:got void *buf
drivers/staging/gdm72xx/gdm_wimax.c:404:41: warning: incorrect type in
argument 2 (different address spaces)
drivers/staging/gdm72xx/gdm_wimax.c:404:41:expected void const
[noderef] *from
drivers/staging/gdm72xx/gdm_wimax.c:404:41:got void *buf
Signed-off-by: Ksenija Stanojevic
---
drivers/staging/gdm72xx/gdm_wimax.c | 8
drivers/staging/gdm72xx/wm_ioctl.h | 6 ++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/gdm72xx/gdm_wimax.c
b/drivers/staging/gdm72xx/gdm_wimax.c
index b8eea21..362a980 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.c
+++ b/drivers/staging/gdm72xx/gdm_wimax.c
@@ -363,7 +363,7 @@ static void kdelete(void **buf)
}
}
-static int gdm_wimax_ioctl_get_data(struct data_s *dst, struct data_s *src)
+static int gdm_wimax_ioctl_get_data(struct data_us *dst, struct data_s *src)
{
int size;
@@ -379,7 +379,7 @@ static int gdm_wimax_ioctl_get_data(struct data_s *dst,
struct data_s *src)
return 0;
}
-static int gdm_wimax_ioctl_set_data(struct data_s *dst, struct data_s *src)
+static int gdm_wimax_ioctl_set_data(struct data_s *dst, struct data_us *src)
{
if (!src->size) {
dst->size = 0;
@@ -469,7 +469,7 @@ static int gdm_wimax_ioctl(struct net_device *dev, struct
ifreq *ifr, int cmd)
}
if (req->cmd == SIOCG_DATA) {
ret = gdm_wimax_ioctl_get_data(
- >data, >sdk_data[req->data_id]);
+ >udata, >sdk_data[req->data_id]);
if (ret < 0)
return ret;
} else if (req->cmd == SIOCS_DATA) {
@@ -481,7 +481,7 @@ static int gdm_wimax_ioctl(struct net_device *dev, struct
ifreq *ifr, int cmd)
req->data.buf);
}
ret = gdm_wimax_ioctl_set_data(
- >sdk_data[req->data_id], >data);
+ >sdk_data[req->data_id], >udata);
if (ret < 0)
return ret;
}
diff --git a/drivers/staging/gdm72xx/wm_ioctl.h
b/drivers/staging/gdm72xx/wm_ioctl.h
index ed8f649..066765d 100644
--- a/drivers/staging/gdm72xx/wm_ioctl.h
+++ b/drivers/staging/gdm72xx/wm_ioctl.h
@@ -78,6 +78,11 @@ struct data_s {
void*buf;
};
+struct data_us {
+ int size;
+ void __user *buf;
+};
+
struct wm_req_s {
union {
char ifrn_name[IFNAMSIZ];
@@ -85,6 +90,7 @@ struct wm_req_s {
unsigned short cmd;
unsigned short data_id;
struct data_s data;
+ struct data_us udata;
/* NOTE: sizeof(struct wm_req_s) must be less than sizeof(struct ifreq). */
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] arm64: defconfig: Enable samsung MFD and related configs
Exynos7 based espresso board uses S2MPS15, a multifunction device. This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by the same. Signed-off-by: Alim Akhtar --- Changes since v1: * updated the comment message to describe which platfrom uses it. * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block. arch/arm64/configs/defconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 9492fe7edbbc..2e1f815daa2b 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -131,9 +131,11 @@ CONFIG_GPIO_XGENE=y CONFIG_POWER_RESET_XGENE=y CONFIG_POWER_RESET_SYSCON=y # CONFIG_HWMON is not set +CONFIG_MFD_SEC_CORE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_QCOM_SMD_RPM=y +CONFIG_REGULATOR_S2MPS11=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y CONFIG_FRAMEBUFFER_CONSOLE=y @@ -162,6 +164,7 @@ CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_CPU=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_S5M=y CONFIG_RTC_DRV_EFI=y CONFIG_RTC_DRV_XGENE=y CONFIG_DMADEVICES=y @@ -169,6 +172,7 @@ CONFIG_QCOM_BAM_DMA=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_MMIO=y +CONFIG_COMMON_CLK_S2MPS11=y CONFIG_COMMON_CLK_QCOM=y CONFIG_MSM_GCC_8916=y CONFIG_HWSPINLOCK_QCOM=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: update DT binding doc locations
On Friday 06 November 2015 01:11 AM, Rob Herring wrote: > After the recent moving of DT binding documents, some maintainers entries > are stale. Update them to the new locations. > > In bindings/fb/, there were only 2 files and I'm assuming the FB > maintainers don't want to be copied on all of bindings/display/. So I've > dropped them. > > Reported-by: Thierry Reding > Cc: Thierry Reding > Cc: Jianwei Wang > Cc: Alison Wang > Cc: Philipp Zabel > Cc: Mark Yao > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Cc: James Hogan > Cc: Hans de Goede > Cc: Vineet Gupta For arc bits: Acked-by: Vineet Gupta > Signed-off-by: Rob Herring > --- > ... > > @@ -10072,6 +10072,7 @@ M:Vineet Gupta > S: Supported > F: arch/arc/ > F: Documentation/devicetree/bindings/arc/* > +F: Documentation/devicetree/bindings/interrupt-controller/snps,arc* > F: drivers/tty/serial/arc_uart.c > T: git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git > -- 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] goldfish: add goldfish match node for dt driver probe
Signed-off-by: yalin wang
---
drivers/input/keyboard/goldfish_events.c | 9 +
drivers/platform/goldfish/goldfish_pipe.c | 11 ++-
drivers/power/goldfish_battery.c | 11 ++-
drivers/staging/goldfish/goldfish_audio.c | 11 ++-
drivers/staging/goldfish/goldfish_nand.c | 9 +
drivers/tty/goldfish.c| 11 ++-
drivers/video/fbdev/goldfishfb.c | 10 +-
7 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/goldfish_events.c
b/drivers/input/keyboard/goldfish_events.c
index 907e4e2..7b99ab8 100644
--- a/drivers/input/keyboard/goldfish_events.c
+++ b/drivers/input/keyboard/goldfish_events.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -178,10 +179,18 @@ static int events_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_events_match[] = {
+ { .compatible = "generic,goldfish-events-keypad" },
+ { },
+};
+#endif
+
static struct platform_driver events_driver = {
.probe = events_probe,
.driver = {
.name = "goldfish_events",
+ .of_match_table = of_match_ptr(goldfish_events_match),
},
};
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..55b6d7c 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -615,11 +616,19 @@ static int goldfish_pipe_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_pipe_match[] = {
+ { .compatible = "generic,android-pipe" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_pipe = {
.probe = goldfish_pipe_probe,
.remove = goldfish_pipe_remove,
.driver = {
- .name = "goldfish_pipe"
+ .name = "goldfish_pipe",
+ .of_match_table = of_match_ptr(goldfish_pipe_match),
}
};
diff --git a/drivers/power/goldfish_battery.c b/drivers/power/goldfish_battery.c
index a50bb98..48b057d 100644
--- a/drivers/power/goldfish_battery.c
+++ b/drivers/power/goldfish_battery.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -227,11 +228,19 @@ static int goldfish_battery_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_battery_match[] = {
+ { .compatible = "generic,goldfish-battery" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_battery_device = {
.probe = goldfish_battery_probe,
.remove = goldfish_battery_remove,
.driver = {
- .name = "goldfish-battery"
+ .name = "goldfish-battery",
+ .of_match_table = of_match_ptr(goldfish_battery_match),
}
};
module_platform_driver(goldfish_battery_device);
diff --git a/drivers/staging/goldfish/goldfish_audio.c
b/drivers/staging/goldfish/goldfish_audio.c
index b0927e4..f0c5118 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -344,11 +345,19 @@ static int goldfish_audio_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_audio_match[] = {
+ { .compatible = "generic,goldfish-audio" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_audio_driver = {
.probe = goldfish_audio_probe,
.remove = goldfish_audio_remove,
.driver = {
- .name = "goldfish_audio"
+ .name = "goldfish_audio",
+ .of_match_table = of_match_ptr(goldfish_audio_match),
}
};
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index 623353db5..f26de0f 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -430,11 +431,19 @@ static int goldfish_nand_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_nand_match[] = {
+ { .compatible = "generic,goldfish-nand" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_nand_driver = {
.probe = goldfish_nand_probe,
.remove = goldfish_nand_remove,
.driver = {
.name = "goldfish_nand"
+ .of_match_table = of_match_ptr(goldfish_nand_match),
}
};
diff --git
Question with maxcpus= parameter.
Hi Maintainers, Recently we faced an cpu online issue with maxcpus= parameter. We want to have 4 cpus onlined at bootup, test 3.8.13-stable on an 72 cpus env with maxcpus=4, I found more cpus than 4 are onlined. It's the udev scripts make them onlined. But below script exist for a long time. ACTION=="add", KERNEL=="cpu[0-9]*", RUN+="/bin/bash -c 'echo 1 > /sys/devices/system/cpu/%k/online'" maxcpu= parameter didn't take effect, so is this a kernel bug? Or that script should be removed? Btw: 2.6.39 works fine, I checked udev log, seems CPU ADD event is only sent for 4cpus. Why the difference between 2.6.39 and 3.8.13? thanks zduan -- 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/
προσφορά δανείου
-- Καλημέρα «Το όνομά μου είναι Μαρία Λέων, μια ιδιωτική εταιρεία δανεισμού EASYLOANS ΟΙΚΟΝΟΜΙΚΕΣ LTD, που εδρεύει στην Αγγλία και την Ιταλία, Προσφέρουμε όλα τα είδη των δανείων προς ιδιώτες και επιχειρήσεις, να κάνει τον εαυτό σας οικονομικά σταθερά για την επίτευξη των δανείων ΟΙΚΟΝΟΜΙΚΕΣ LTD EASYLOANS στο 3% επιτόκιο τόσο σύντομο και μακροπρόθεσμα δάνεια, επιχειρηματικά δάνεια, δάνεια αυτοκινήτων, υποθήκες, επιχειρηματικά δάνεια, κλπ συμπληρώστε το έντυπο της αίτησης δανείου παρακάτω αν σας ενδιαφέρει σε ένα δάνειο, * Όνομα: * Είδος: Χώρα / διεύθυνση: * Ποσό που απαιτείται: * Διάρκεια της πίστωσης: * Δάνειο Σκοπός: * Τηλέφωνο: Παρακαλούμε επικοινωνήστε μαζί μας μέσω e-mail: easyloans...@outlook.com Σ 'ευχαριστώ και τις καλύτερες ευχές. MARIE LEO -- 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] Sparc
From: Linus Torvalds Date: Thu, 5 Nov 2015 16:43:52 -0800 > On Thu, Nov 5, 2015 at 1:39 PM, David Miller wrote: >> >> 5) Fix iommu-common code so it doesn't emit rediculous warnings >>on some architectures, particularly ARM. > > Heh. So looking at that patch, I can't but help to react that this: > > #define IOMMU_ERROR_CODE (~(unsigned long) 0) > > is still pretty ridiculous. Maybe just (-1ul), or for those people > who don't understand C unsigned long arithmetic and think that a > negative unsigned long looks odd, (~0ul)? Yeah I struggled with this, believe it or not. The expression causing the problem was (~(dma_addr_t) 0) (AKA DMA_ERROR_CODE) being used as the return value. So I just replicated that expression. A neuron did fire saying "hey pinhead, why not just use ~0UL" but I did not listen to the little voice in my head this time. -- 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 5/5] ARM: dts: AM4372: add entry for qspi mmap region
Hi,
Rob Herring writes:
> On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote:
>> Add qspi memory mapped region entries for AM43xx based SoCs. Also,
>> update the binding documents for the controller to document this change.
>>
>> Signed-off-by: Vignesh R
>
> Acked-by: Rob Herring
>
>> ---
>> Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
>> arch/arm/boot/dts/am4372.dtsi | 4 +++-
>> 2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> index f05dd631bef1..05488970060b 100644
>> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> @@ -17,9 +17,10 @@ Recommended properties:
>>
>> Example:
>>
>> +For am4372:
>> qspi: qspi@4b30 {
>> -compatible = "ti,dra7xxx-qspi";
>> -reg = <0x4790 0x100>, <0x3000 0x3ff>;
>> +compatible = "ti,am4372-qspi";
>> +reg = <0x4790 0x100>, <0x3000 0x400>;
>> reg-names = "qspi_base", "qspi_mmap";
>> #address-cells = <1>;
>> #size-cells = <0>;
and how does the user for this look like ? Don't you need to give this a
proper 'ranges' binding ?
--
balbi
signature.asc
Description: PGP signature
Re: NETIF_F_GSO_SOFTWARE vs NETIF_F_GSO
On Fri, Nov 06, 2015 at 02:31:59AM +0100, Jason A. Donenfeld wrote: > > So far implementing (3) is failing miserably. Is there anything wrong > with my general idea that might make this a priori impossible? For > example, will udp_tunnel_xmit_skb not accept super-packets? Or, am I > just not making use of whatever nice convenience functions are > available for constructing super-packets, and thus am doing something > wrong? I don't see anything fundamentally wrong with your idea. After all what you're describing is the basis of GSO, i.e., letting data stay in the form of super-packets for as long as we can. Of course there's going to be a lot of niggly bits that you'll have to sort out to get it to work. Good luck, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: sun4i-ss: add missing statesize
On Thu, Nov 05, 2015 at 08:07:19AM -0800, Maxime Ripard wrote: > > On Thu, Nov 05, 2015 at 08:48:57AM +0100, LABBE Corentin wrote: > > sun4i-ss implementaton of md5/sha1 is via ahash algorithms. > > A recent change make impossible to load them without giving statesize. > > Which one? We recently disabled ahash drivers that do not declare statesize because it can lead to a crash when the driver is used through algif. Not declaring statesize is a bug anyway but the fact that it is exported through algif makes it much worse. > > This patch specifiy statesize for sha1 and md5. > > > > Signed-off-by: LABBE Corentin > > Cc: sta...@vger.kernel.org > > Please also add a Fixes tag (and the stable version it applies to). I don't see the point for a fixes tag as it would simply refer to the original patch-set that added the driver. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] I2C: designware: fix IO timeout issue for AMD controller
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Thursday, November 05, 2015 9:52 PM
> To: Yu, Xiangliang
> Cc: andriy.shevche...@linux.intel.com; jarkko.nik...@linux.intel.com;
> w...@the-dreams.de; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Xue, Ken; Wan, Vincent; Huang, Ray; Wang, Annie;
> Li, Tony
> Subject: Re: [PATCH 1/1] I2C: designware: fix IO timeout issue for AMD
> controller
>
> On Thu, Nov 05, 2015 at 08:34:44PM +0800, Xiangliang Yu wrote:
> > Because of some hardware limitation, AMD I2C controller can't trigger
> > next interrupt if interrupt status has been changed after clearing
> > interrupt status bits. Then, I2C will lost interrupt and IO timeout.
> >
> > According to hardware design, this patch implements a workaround to
> > disable i2c controller interrupt after clearing interrupt bits when
> > entering ISR and to enable i2c interrupt before exiting ISR.
> >
> > To reduce the performance impacts on other vendors, use unlikely
> > function to check flag in ISR.
> >
> > Signed-off-by: Xiangliang Yu
> > ---
> > drivers/i2c/busses/i2c-designware-core.c| 6 ++
> > drivers/i2c/busses/i2c-designware-core.h| 1 +
> > drivers/i2c/busses/i2c-designware-platdrv.c | 4
> > 3 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-core.c
> > b/drivers/i2c/busses/i2c-designware-core.c
> > index 7441cdc..04e7b65 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.c
> > +++ b/drivers/i2c/busses/i2c-designware-core.c
> > @@ -783,6 +783,9 @@ irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
> >
> > stat = i2c_dw_read_clear_intrbits(dev);
>
> What if the status changes right here, before you go and mask the interrupt?
Have no effect, because i2c controller can't trigger next interrupt.
>
> >
> > + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> > + i2c_dw_disable_int(dev);
> > +
> > if (stat & DW_IC_INTR_TX_ABRT) {
> > dev->cmd_err |= DW_IC_ERR_TX_ABRT;
> > dev->status = STATUS_IDLE;
> > @@ -811,6 +814,9 @@ tx_aborted:
> > if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) ||
> dev->msg_err)
> > complete(>cmd_complete);
> >
> > + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> > + dw_writel(dev, DW_IC_INTR_DEFAULT_MASK,
> DW_IC_INTR_MASK);
>
> The driver disables TX interrupt when it is not needed anymore or when TX
> gets aborted but the above will re-enable all interrupts regardless.
> Is that the intention?
No, i2c controller can trigger next interrupt only after re-enable all
interrupt.
>
> > +
> > return IRQ_HANDLED;
> > }
> > EXPORT_SYMBOL_GPL(i2c_dw_isr);
> > diff --git a/drivers/i2c/busses/i2c-designware-core.h
> > b/drivers/i2c/busses/i2c-designware-core.h
> > index 9630222..808ef6a 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.h
> > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > @@ -111,6 +111,7 @@ struct dw_i2c_dev {
> >
> > #define ACCESS_SWAP0x0001
> > #define ACCESS_16BIT 0x0002
> > +#define ACCESS_INTR_MASK 0x0004
> >
> > extern u32 dw_readl(struct dw_i2c_dev *dev, int offset); extern void
> > dw_writel(struct dw_i2c_dev *dev, u32 b, int offset); diff --git
> > a/drivers/i2c/busses/i2c-designware-platdrv.c
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index 472b882..0c59357 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -251,6 +251,10 @@ static int dw_i2c_probe(struct platform_device
> *pdev)
> > dev->rx_fifo_depth = ((param1 >> 8) & 0xff) + 1;
> > dev->adapter.nr = pdev->id;
> > }
> > +
> > + if (!strncmp(pdev->name, "AMD0010", 7))
> > + dev->accessor_flags |= ACCESS_INTR_MASK;
> > +
>
> Can't you put this to ->driver_data? For example it could refer to a
> configuration structure that then contains quirk flags.
I think it will need to add a function to support it, but the function
Is rarely used. It will easy to add if i2c driver has quirk mechanisms.
Added code is very simple and have no influence on others.
>
> > r = i2c_dw_init(dev);
> > if (r)
> > return r;
> > --
> > 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "compatible" and "model" properties in .dts for ARC boards
+CC lkml,Arnd, Rob
On Friday 06 November 2015 12:20 AM, Alexey Brodkin wrote:
> Hi Vineet,
>
> During OpenWRT upsreaming process one interesting topic was raised.
> See in the middle of
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/036959.html
>
> In Device Tree descriptions for our boards we don't use "model" property
> even though it is a required one as specified by ePAPR, see
> http://free-electrons.com/~thomas/pub/Power_ePAPR_APPROVED_v1.0.pdf,
> page 39 "Table 3-1 Root node properties".
>
> Instead we put 2 items in "compatible" property.
>
> For example:
> --->8
> compatible = "snps,axs101", "snps,arc-sdp";
> --->8
>
> And from ePAPR standpoint it makes sense to split contents of that
> "compatible"
> property in 2:
> --->8
> compatible = "snps,arc-sdp";
> model = "snps,axs101";
> --->8
It seems model is just a descriptive label and we can surely add them to
existing DT.
compatible on the other hand is more fundamental used for exact comparisons etc
and follows the vendor,device convention.
It is pretty common for compatible to have multiple strings for exactly the same
reason as I have them here. Both axs101 and axs103 are based on sdp thus we want
the ability to have both pieces of information and use as needed.
While doing some other DT research recently, I found some of the best basic DT
documentation is a somewhat misnamed in-kernel document
Documentation/devicetree/booting-without-of.txt
> But I do see problems with implementation of that thing.
> Today we have a luxury of selection of AXS init functionality
> based on that compatible value and if "snps,axs101" goes in
> "model" then we'll need to add some more code in
> arch/arc/plat-axs10x/axs10x.c that reads "model" value with
> of_get_property() and then compare to "axs10{1|3}".
>
> Any thoughts?
>
> -Alexey
--
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] arm64: defconfig: Enable samsung MFD and related configs
2015-11-06 13:35 GMT+09:00 Alim Akhtar : > This patch enables below configs by default: > * CONFIG_MFD_SEC_CORE > * CONFIG_REGULATOR_S2MPS11 > * CONFIG_RTC_DRV_S5M Instead of duplicating in the description the contents of the patch, please describe why you want this and for which devices. Best regards, Krzysztof > > Signed-off-by: Alim Akhtar > --- > arch/arm64/configs/defconfig |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 9492fe7edbbc..78e89e690dc1 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -131,9 +131,11 @@ CONFIG_GPIO_XGENE=y > CONFIG_POWER_RESET_XGENE=y > CONFIG_POWER_RESET_SYSCON=y > # CONFIG_HWMON is not set > +CONFIG_MFD_SEC_CORE=y > CONFIG_REGULATOR=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_QCOM_SMD_RPM=y > +CONFIG_REGULATOR_S2MPS11=y > CONFIG_FB=y > CONFIG_FB_ARMCLCD=y > CONFIG_FRAMEBUFFER_CONSOLE=y > @@ -162,6 +164,7 @@ CONFIG_LEDS_TRIGGERS=y > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_LEDS_TRIGGER_CPU=y > CONFIG_RTC_CLASS=y > +CONFIG_RTC_DRV_S5M=y > CONFIG_RTC_DRV_EFI=y > CONFIG_RTC_DRV_XGENE=y > CONFIG_DMADEVICES=y > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro Signed-off-by: Sunny Kumar --- drivers/staging/rdma/hfi1/user_sdma.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/rdma/hfi1/user_sdma.c b/drivers/staging/rdma/hfi1/user_sdma.c index 36c838d..7998797 100644 --- a/drivers/staging/rdma/hfi1/user_sdma.c +++ b/drivers/staging/rdma/hfi1/user_sdma.c @@ -146,8 +146,8 @@ MODULE_PARM_DESC(sdma_comp_size, "Size of User SDMA completion ring. Default: 12 #define KDETH_OM_MAX_SIZE (1 << ((KDETH_OM_LARGE / KDETH_OM_SMALL) + 1)) /* Last packet in the request */ -#define TXREQ_FLAGS_REQ_LAST_PKT (1 << 0) -#define TXREQ_FLAGS_IOVEC_LAST_PKT (1 << 0) +#define TXREQ_FLAGS_REQ_LAST_PKT BIT(0) +#define TXREQ_FLAGS_IOVEC_LAST_PKT BIT(0) #define SDMA_REQ_IN_USE 0 #define SDMA_REQ_FOR_THREAD 1 @@ -156,9 +156,9 @@ MODULE_PARM_DESC(sdma_comp_size, "Size of User SDMA completion ring. Default: 12 #define SDMA_REQ_HAS_ERROR 4 #define SDMA_REQ_DONE_ERROR 5 -#define SDMA_PKT_Q_INACTIVE (1 << 0) -#define SDMA_PKT_Q_ACTIVE (1 << 1) -#define SDMA_PKT_Q_DEFERRED (1 << 2) +#define SDMA_PKT_Q_INACTIVE BIT(0) +#define SDMA_PKT_Q_ACTIVE BIT(1) +#define SDMA_PKT_Q_DEFERRED BIT(2) /* * Maximum retry attempts to submit a TX request -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: defconfig: Enable samsung MFD and related configs
This patch enables below configs by default: * CONFIG_MFD_SEC_CORE * CONFIG_REGULATOR_S2MPS11 * CONFIG_RTC_DRV_S5M Signed-off-by: Alim Akhtar --- arch/arm64/configs/defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 9492fe7edbbc..78e89e690dc1 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -131,9 +131,11 @@ CONFIG_GPIO_XGENE=y CONFIG_POWER_RESET_XGENE=y CONFIG_POWER_RESET_SYSCON=y # CONFIG_HWMON is not set +CONFIG_MFD_SEC_CORE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_QCOM_SMD_RPM=y +CONFIG_REGULATOR_S2MPS11=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y CONFIG_FRAMEBUFFER_CONSOLE=y @@ -162,6 +164,7 @@ CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_CPU=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_S5M=y CONFIG_RTC_DRV_EFI=y CONFIG_RTC_DRV_XGENE=y CONFIG_DMADEVICES=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()
On Thu, Nov 05, 2015 at 08:15:49PM -0800, Linus Torvalds wrote: > Would you mind doing that version of the patch instead? I can do it > too, but I'd rather give authorship to you, since you found the stupid > issue, which is actually the much bigger deal. Sure, I'll try it that way and see what it looks like. 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: Improve spinlock performance by moving work to one core
Longman Thanks for your suggestion. We will look for real scenario to test, and could you please introduce some benchmarks on spinlock ? Regards Ling > > Your new spinlock code completely change the API and the semantics of the > existing spinlock calls. That requires changes to thousands of places > throughout the whole kernel. It also increases the size of the spinlock from > 4 bytes to 32 bytes. It is basically a no-go. > > However, if you can improve the performance within the existing API and > locking semantics, it will be much more acceptable. > > Cheers, > Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfs: clear remainder of 'full_fds_bits' in dup_fd()
On Thu, Nov 5, 2015 at 7:42 PM, Eric Biggers wrote:
> This fixes a bug from commit f3f86e33dc3d ("vfs: Fix pathological
> performance case for __alloc_fd()").
Gaah. Good catch. The first version of that patch allocated the
full_fds_bits array separately and always cleared it (using kzalloc),
but then people hated on that.. So I did the "obvious" thing to just
allocate it as part of the same allocation as open_fds. And didn't
think about that thay does to the dup_fd() code.
That said, the more I look at your patch, the more I hate it. Not
because your patch is wrong, but because dup_fd() is such a nasty
horrid mess, and your patch looks bad just because that function is
bad.
Just look at what "copy_fdtable()" does: it's the exact same bitmap
copy, but it actually makes more sense there. Well, at least it's more
compact without the very odd "let's drop the spinlock in the middle
and clear the end later. That optimization just doesn't seem to be
worth it. Especially since we don't do it for the expend_fdtable()
case.
So what I would do is to just extract out the bitmap copying from
"copy_fdtable()" (call it "copy_fd_bitmaps()"?) and then use that for
both copy_fdtable() and for dup_fd(). And then I guess you could leave
the
memset(new_fds, 0, size);
outside the spinlock still, but at least have the bitmap copying in
one sane place rather than spread out oddly like that.
Would you mind doing that version of the patch instead? I can do it
too, but I'd rather give authorship to you, since you found the stupid
issue, which is actually the much bigger deal.
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] mm, oom: add comment for why oom_adj exists
>
> /proc/pid/oom_adj exists solely to avoid breaking existing userspace
> binaries that write to the tunable.
>
> Add a comment in the only possible location within the kernel tree to
> describe the situation and motivation for keeping it around.
>
> Signed-off-by: David Rientjes
> ---
Acked-by: Hillf Danton
> fs/proc/base.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1032,6 +1032,16 @@ static ssize_t oom_adj_read(struct file *file, char
> __user *buf, size_t count,
> return simple_read_from_buffer(buf, count, ppos, buffer, len);
> }
>
> +/*
> + * /proc/pid/oom_adj exists solely for backwards compatibility with previous
> + * kernels. The effective policy is defined by oom_score_adj, which has a
> + * different scale: oom_adj grew exponentially and oom_score_adj grows
> linearly.
> + * Values written to oom_adj are simply mapped linearly to oom_score_adj.
> + * Processes that become oom disabled via oom_adj will still be oom disabled
> + * with this implementation.
> + *
> + * oom_adj cannot be removed since existing userspace binaries use it.
> + */
> static ssize_t oom_adj_write(struct file *file, const char __user *buf,
>size_t count, loff_t *ppos)
> {
> --
--
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 RESEND 03/16] Documentation: dt-bindings: hwmon: add TI LMU HWMON binding information
On 11/6/2015 10:57 AM, Rob Herring wrote: On Mon, Nov 02, 2015 at 02:24:22PM +0900, Milo Kim wrote: Hardware fault monitoring driver is used in LM3633 and LM3697 device. Just 'compatible' property is required to describe the driver. Cc: devicet...@vger.kernel.org Cc: Guenter Roeck Cc: Jean Delvare Cc: Lee Jones Cc: lm-sens...@lm-sensors.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim Acked-by: Rob Herring Thanks for your review, Rob. HWMON maintainer, Guenter suggested moving LMU HWMON driver to MFD as the sysfs attributes because it has no sensor data like temperature or voltage. So I'll move this property to mfd/ti-lmu.txt in the next patch. Best regards, Milo -- 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] vfs: clear remainder of 'full_fds_bits' in dup_fd()
This fixes a bug from commit f3f86e33dc3d ("vfs: Fix pathological
performance case for __alloc_fd()").
Signed-off-by: Eric Biggers
---
fs/file.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 6f6eb2b..36e5103 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -276,7 +276,7 @@ struct files_struct *dup_fd(struct files_struct *oldf, int
*errorp)
{
struct files_struct *newf;
struct file **old_fds, **new_fds;
- int open_files, size, i;
+ int open_files, i;
struct fdtable *old_fdt, *new_fdt;
*errorp = -ENOMEM;
@@ -357,18 +357,16 @@ struct files_struct *dup_fd(struct files_struct *oldf,
int *errorp)
}
spin_unlock(>file_lock);
- /* compute the remainder to be cleared */
- size = (new_fdt->max_fds - open_files) * sizeof(struct file *);
-
- /* This is long word aligned thus could use a optimized version */
- memset(new_fds, 0, size);
-
+ /* clear the remainder if needed */
if (new_fdt->max_fds > open_files) {
- int left = (new_fdt->max_fds - open_files) / 8;
+ int left = new_fdt->max_fds - open_files;
int start = open_files / BITS_PER_LONG;
- memset(_fdt->open_fds[start], 0, left);
- memset(_fdt->close_on_exec[start], 0, left);
+ memset(new_fds, 0, left * sizeof(struct file *));
+ memset(_fdt->open_fds[start], 0, left / 8);
+ memset(_fdt->close_on_exec[start], 0, left / 8);
+ memset(_fdt->full_fds_bits[BITBIT_NR(open_files)], 0,
+ BITBIT_SIZE(new_fdt->max_fds) - BITBIT_SIZE(open_files));
}
rcu_assign_pointer(newf->fdt, new_fdt);
--
2.6.2
--
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] x86/mm: Skip the hypervisor range when walking PGD
On 11/05/2015 05:31 PM, H. Peter Anvin wrote:
On 11/05/15 10:56, Boris Ostrovsky wrote:
The range between 0x8000 and 0x87ff is reserved
for hypervisor and therefore we should not try to follow PGD's indexes
corresponding to those addresses.
While this has alsways been a problem, with commit e1a58320a38d ("x86/mm:
Warn on W^X mappings") ptdump_walk_pgd_level_core() can now be called
during boot, causing a PV Xen guest to crash.
Reported-by: Sander Eikelenboom
Signed-off-by: Boris Ostrovsky
---
arch/x86/mm/dump_pagetables.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 1bf417e..756c921 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -362,8 +362,13 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m,
pgd_t *pgd,
bool checkwx)
{
#ifdef CONFIG_X86_64
+/* 8000 - 87ff is reserved for hypervisor */
+#define is_hypervisor_range(idx) (paravirt_enabled() && \
+ (((idx) >= pgd_index(__PAGE_OFFSET) - 16) && \
+ ((idx) < pgd_index(__PAGE_OFFSET
pgd_t *start = (pgd_t *) _level4_pgt;
#else
+#define is_hypervisor_range(idx) 0
pgd_t *start = swapper_pg_dir;
#endif
pgprotval_t prot;
@@ -381,7 +386,7 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m,
pgd_t *pgd,
for (i = 0; i < PTRS_PER_PGD; i++) {
st.current_address = normalize_addr(i * PGD_LEVEL_MULT);
- if (!pgd_none(*start)) {
+ if (!pgd_none(*start) && !is_hypervisor_range(i)) {
if (pgd_large(*start) || !pgd_present(*start)) {
prot = pgd_flags(*start);
note_page(m, , __pgprot(prot), 1);
Maybe we could use the max_lines field in the address_markers[] array?
We really shouldn't be mapping anything in the hypervisor space even on
native.
You mean overload max_lines with a value indicating that the range needs
to be skipped?
That would require checking the range on each loop iteration since we
update st.marker *after* we've walked a particular index. (And I think
it would need to be done on each level to be generic).
I could just drop paravirt_enabled() in is_hypervisor_range() but you
are thinking about avoiding the macro altogether, right?
(I do need to add hypervisor range to address_markers[])
-boris
--
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: fs: out of bounds on stack in iov_iter_advance
On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote: > > How are we going to handle that one? I can put it into mainline pull > request via vfs.git, with Cc: stable, but if e.g. Jens prefers to take it > via the block tree, I'll be glad to leave it for him to deal with. Put it in the vfs tree (I'm hoping for a pull request soon..) I pulled the block trees from Jens yesterday, so there is presumably nothing pending there right now. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] thermal: mediatek: Add cpu power cooling model.
Cc'ing Javi (which you should have as he wrote the power-thing for cpu-cooling). On 05-11-15, 19:10, dawei chien wrote: > This is because our platform currently only support mt8173_cpufreq.c, so > that I only add static power model for our owner IC. Bindings are (normally) supposed to be general than a platform specific. > Please understanding that I wouldn't give a DT binding document since I > will remove static power table on next version, but I can try to explain > it. Then just don't add things in the first place. > As far as I know, static power is somewhat leakage of CPU clusters, so > that we hardly to find a formula, which can suitable all kinds of CPUs > since leakage is different. In ARM IPA framework, static power only need > to be defined by who register cpufreq_power_cooling_register. The > voltage/power table is just one way to present leakage power of CPUs. The bindings don't fix the values for static power, but just provides a field for platforms to use. Everyone can then send its own power figures. Why do you thing it can't be generalized? > Actually, static power is optional since dynamic power is much more than > static power. Maybe, we should still capture it. @Javi ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 6
Hi all,
Please do *not* add any material intended for v4.5 to your linux-next
included branches until after v4.4-rc1 has been released.
Changes since 20151105:
The thermal-soc tree still had its build failure for which I reverted
a commit.
The battery tree still had its build failure so I used the version from
next-20150925.
Non-merge commits (relative to Linus' tree): 4836
4749 files changed, 206535 insertions(+), 74370 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.
Below is a summary of the state of the merge.
I am currently merging 229 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (66339fdacb63 Merge tag 'please-pull-pstore' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (38850d786a79 ARM: 8449/1: fix bug in vdsomunge
swab32 macro)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (977bf062bba3 powerpc/dma: dma_set_coherent_mask()
should not be GPL only)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (52708d690b8b sparc64: Fix numa distance values)
Merging net/master (49a496c97d03 tcp: use correct req pointer in tcp_move_syn()
calls)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for
nf_dup_ipv{4,6})
Merging sound-current/for-linus (5cf92c8b3dc5 ALSA: hda - Add Intel Lewisburg
device IDs Audio)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag
'iwlwifi-for-kalle-2015-10-05' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval
before calling fb_set_par)
Merging usb.current/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-gadget-fixes/fixes (25cb62b76430 Linux 4.3-rc5)
Merging usb-serial-fixes/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (f256896afdb6 usb: chipidea: otg:
gadget module load and unload support)
Merging staging.current/staging-linus (32b88194f71d Linux 4.3-rc7)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (e60e063c14b1 HID: hid-gfrm: avoid warning for
input_configured API change)
Merging crypto-current/master (4afa5f961792 crypto: algif_hash - Only export
and import on sockets with data)
Merging ide/master (1b1050cdc5cd Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default
emit rule)
Merging backlight-fixes
Re: [PATCH 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
> On Nov 5, 2015, at 8:34 PM, Rob Herring wrote: > > On Thu, Nov 05, 2015 at 04:07:52PM -0600, Matthew McClintock wrote: >> From: Varadarajan Narayanan >> >> Add pinctrl driver support for IPQ4019 platform >> >> Signed-off-by: Sricharan R >> Signed-off-by: Mathieu Olivari >> Signed-off-by: Varadarajan Narayanan >> Signed-off-by: Matthew McClintock >> --- >> .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 116 ++ >> drivers/pinctrl/qcom/Kconfig |8 + >> drivers/pinctrl/qcom/Makefile |1 + >> drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 >> >> 4 files changed, 1405 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c >> >> diff --git >> a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> new file mode 100644 >> index 000..045c5aa >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> @@ -0,0 +1,116 @@ >> +Qualcomm Atheros IPQ4019 TLMM block >> + >> +Required properties: >> +- compatible: "qcom,ipq4019-pinctrl" > > Perhaps the name should have TLMM in it. Whatever that stands for. Sure, this was a holdover from Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt mostly. Will elaborate on v2 though. -M -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model
On 05-11-15, 19:09, dawei chien wrote: > Thank you for your kindly explaining, now I could understand what I > miss, I will send device tree binding on next version such like > following description. > > --- a/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > +++ b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > @@ -10,6 +10,17 @@ Required properties: > Please refer to > Documentation/devicetree/bindings/clk/clock-bindings.txt for > generic clock consumer properties. > - proc-supply: Regulator for Vproc of CPU cluster. > +- dynamic-power-coefficient: > + Usage: optional > + Value type: > + Definition: A u32 value that represents an indicative > + running time dynamic power coefficient in > + fundamental units of mW/MHz/uVolt^2. > + The dynamic energy consumption of the CPU > + is proportional to the square of the > + Voltage (V) and the clock frequency (f). > + Pdyn = dynamic-power-coefficient * V^2 * f > + where voltage is in uV, frequency is in MHz. Please check with Punit if he is planning to add the same.. > Thank you for your kindly explaining, Now I know I should develop and > test on mainline branch since this is where I try to add code. > > However, please understanding currently mt8173_cpufreq.c is not ready > for OPPV2 in mainline as far, that's the reason why currently I can't > reuse OPPV2 and extend for static power table. My propose is for adding > CPU cooling device for our own product. Firstly, we don't care. You are pushing something to mainline, you have to get it tested someway on mainline. Secondly, there are *almost* no changes required to the mtk cpufreq driver for OPPV2. Just update your DT in a similar way it is done for one of the exynos platforms and it should just work fine. -- viresh -- 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/
