Re: [PATCH 1/3] vxlan: silence one build warning
On Fri, Oct 25, 2013 at 11:41 PM, Stephen Hemminger
wrote:
> On Fri, 25 Oct 2013 15:49:18 +0800
> Zhi Yong Wu wrote:
>
>> From: Zhi Yong Wu
>>
>> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
>> drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
>> drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
>> LD drivers/net/built-in.o
>>
>> Signed-off-by: Zhi Yong Wu
>> ---
>> drivers/net/vxlan.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 2ef5b62..e15f1af 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -2272,7 +2272,7 @@ static struct vxlan_sock *vxlan_socket_create(struct
>> net *net, __be16 port,
>> {
>> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
>> struct vxlan_sock *vs;
>> - struct socket *sock;
>> + struct socket *sock = NULL;
>> struct sock *sk;
>> int rc = 0;
>> unsigned int h;
>
> This only happens with certain versions of Gcc which have buggy dependency
> analysis. It doesn't happen with Gcc 4.7, think it only shows up in 4.4.
> I would rather not fix the warning this way since it risks masking later bugs
> if this code ever changes.
Gcc version is 4.7.2 on my box, this warning took palce.
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
...
gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
--
Regards,
Zhi Yong Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default
On Fri, 2013-10-25 at 23:17 -0400, Dave Jones wrote: > On Fri, Oct 25, 2013 at 07:20:15PM -0700, Adam Williamson wrote: > > OK, so, findings: F16 and F17 live images reboot quickly. F18 is the > > first that reboots slowly. > > wait, stop. what does "reboots slowly" mean ? > In every one of the failure I've seen, without a quirk it means reboot > doesn't happen at all. If you read the original report - on Z1s, if you leave the system alone, it sits at the 'Restarting system.' message for about two minutes, then finally reboots. If you pass 'reboot=pci', reboot is as fast as you'd expect. https://bugzilla.kernel.org/show_bug.cgi?id=61721 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Xen-devel] [PATCH] xen/hvc-console: Make it work with HVM guests.
On Fri, 2013-10-25 at 15:38 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 24, 2013 at 05:43:54PM +0100, Ian Campbell wrote:
> > But stepping back how/why is this function called on x86 when not
> > running under Xen? Wouldn't the use have to be using console=hvc or
> > earlyprintk=xen or something -- which strikes me as user error... IOW
> > can we not just nuke the check
>
> It shouldn't - ever. On x86 it is called from the early PV bootup code.
>
> I occasionaly use it when developing/debugging and as such want it working
> in HVM even during early bootup.
Does earlyprintk=ttyS0,cough not Just Work for HVM guests? That would
avoid all of this stuff and assuming it works would be preferable IMHO.
Anyway, if not, then given that the xen_cpuid_base case is entirely x86
specific perhaps we can abstract this as something like:
if (xen_arch_raw_console(str))
return
dom0_write_console(...)
Then ARM:
#define xen_arch_raw_console 0
and x86
static inline int xen_arch_raw_console(str)
{
if (xen_domain())
return 0;
/* Do the outb thing */
return 1;
}
This would also avoid the need for #ifdef x86 in the main function which
Julien pointed out.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
my subject
Need a Loan, Loans from $5000 - $10,000,000 00. Get your no obligation FREE quote now! Repayments up to 54 Months. No Collateral, Money paid into your account within 24 hours after approval. For more Info contact us today guaranteeloancompa...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
my subject
Need a Loan, Loans from $5000 - $10,000,000 00. Get your no obligation FREE quote now! Repayments up to 54 Months. No Collateral, Money paid into your account within 24 hours after approval. For more Info contact us today guaranteeloancompa...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
db_data
what is the use of the variable dbs_data in cpufreq_ondemand.c file??? - Thank You Johns -- View this message in context: http://linux-kernel.2935.n7.nabble.com/db-data-tp743048.html Sent from the Linux Kernel mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree
* Will Deacon wrote: > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote: > > Today's linux-next merge of the tip tree got conflicts in > > > > tools/perf/config/Makefile > > tools/perf/config/feature-tests.mak > > > > caused by commits 405ffbd (perf tools: Check libunwind for availability of > > dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the > > libunwind logic in config/Makefile) as well as various follow-up patches. > > > > I fixed it up (see below). Please verify that the resolution looks good. > > Also note that this isn't really a trivial resolution of a conflict, but > > required modifying various other files. That causes rerere magic not to > > work and needs part of conflict to be resolved manually. Perhaps a good > > idea would be to rebase Jean's patch on top of the cleanups going on in > > the tip tree? Perhaps even carry the patch in the tip tree? > > These came via my tree (arm perf) after discussion here: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html > > Now that they've been pulled by rmk, we can't back them out with > ugly reverts, so I'm not sure what we can do to resolve in the ARM > tree; it looks like the perf Makefile has changed significantly in > -tip. I realize that it was acked by Arnaldo, but for workflow reasons I'd really prefer it if non-trivial perf tooling patches went to Arnaldo as a pull request so that he can resolve any such conflicts. perf is in constant development so it's less work for you that way. (Kernel side changes can go that route as well, as long as they are perf related.) 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/
od_cpu_dbs_info
Hi Iam new to this linux kernel coding and im trying to understand the ondemand cpu governor. And when i read the file i couldnt undertsnad what is od_cpu_dbs_info variable in cpufreq_ondemand.c. Can someone please explain what is its function.?? - Thank You Johns -- View this message in context: http://linux-kernel.2935.n7.nabble.com/od-cpu-dbs-info-tp743052.html Sent from the Linux Kernel mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf/ftrace lockup on 3.12-rc6 with trigger code
* Vince Weaver wrote: > I don't know if there are any better ways to try to debug things > than the printk route. Though that has its own problems as the > printk's themselves start showing up in the ftrace traces. One additional brute-force method is earlyprintk=...,keep and marking the (handful of) earlyprintk functions (and snprintf) notrace, plus turning off printk itself completely. That gives a completely instrumentation-free and locking-free console output function of last resort :-/ 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: ktap inclusion in drivers/staging/?
* Jovi Zhangwei wrote: > Thanks. An addition question I want to discuss in here is the ktap > code structure layout in first patch series, this don't need to > dig out any ktap design detail, so we can make agreement on this > point, and ease for me to prepare patch series. > > Do I need to prepare patchset target on staging tree or "real" > part of kernel? [...] I'd suggest adding it to the core, i.e. kernel/tracing/ and kernel/trace/trace_events_filter.c in particular which includes the current filter script interpreter. (Please also make sure that the Lua copyright notices get carried over properly.) > [...] If target on driver/staging/ktap, then kernel code and > userspace code still need to locate at same directory, that many > people may don't like it. > > Target on "real" part kernel? - include/trace/ktap (header file > common used by interpreter and userspace compiler) - > kernel/trace/ktap (interpreter code, ktapvm, pure kernel module) - > tools/perf/ktap?(userspace compiler code) > As I also agree integrating ktap and perf together, two > subsystem can share many codes, so it's better putting ktap > userspace into perf directory. Once there's a more split-out submission it will be easier to see what belongs where. I agree with Pekka that for the user the UI should be integrated and obvious. I'd also like there to be a natural 'extract the script' functionality from an installed tap script. This gives more flexibiliy and improves security as well: no hidden, binary-only crap, every script installed on a running system should be extractable in source form, should be reviewable and modifiable. 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: [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default
* Adam Williamson wrote: > On Fri, 2013-10-25 at 23:17 -0400, Dave Jones wrote: > > On Fri, Oct 25, 2013 at 07:20:15PM -0700, Adam Williamson wrote: > > > OK, so, findings: F16 and F17 live images reboot quickly. F18 is the > > > first that reboots slowly. > > > > wait, stop. what does "reboots slowly" mean ? > > In every one of the failure I've seen, without a quirk it means reboot > > doesn't happen at all. > > If you read the original report - on Z1s, if you leave the system alone, > it sits at the 'Restarting system.' message for about two minutes, then > finally reboots. If you pass 'reboot=pci', reboot is as fast as you'd > expect. > > https://bugzilla.kernel.org/show_bug.cgi?id=61721 So, the best range for the breakage we have is v3.3..v3.5. As a blind shot into the dark, that turns out to be a range when a number of irq-remapping, vt-d changes went upstream: comet:~/tip> gll v3.3..v3.6 arch/x86 | grep -i remap 399988eea194 irq_remap: Fix compiler warning with CONFIG_IRQ_REMAP=y 79fec2c557cf Merge tag 'intr-remapping-ops-for-ingo' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu into core/iommu 8a8f422d3b4f iommu: rename intr_remapping.[ch] to irq_remapping.[ch] 95a02e976c39 iommu: rename intr_remapping references to irq_remapping 263b5e8629c9 x86, iommu/vt-d: Clean up interfaces for interrupt remapping 5e2b930b0784 iommu/vt-d: Convert MSI remapping setup to remap_ops 9d619f657222 iommu/vt-d: Convert free_irte into a remap_ops callback 4c1bad6a0af1 iommu/vt-d: Convert IR set_affinity function to remap_ops 0c3f173a88c4 iommu/vt-d: Convert IR ioapic-setup to use remap_ops 4f3d8b67ad30 iommu/vt-d: Convert missing apic.c intr-remapping call to remap_ops 736baef4472d iommu/vt-d: Make intr-remapping initialization generic f7219a5300ba x86: Introduce CONFIG_X86_DMA_REMAP So if you are able to test current kernels, it might be an additional data point to see whether the reboot delay (which appears to be a reboot hang on other systems) is related to the following kernel option: CONFIG_IRQ_REMAP=y (CONFIG_X86_DMA_REMAP is off on Fedora.) IRQ_REMAP is somewhat of a dual personality feature, living half in arch/x86/, half in drivers/iommu/. It should normally matter for servers more than for laptops. Btw., regarding your encrypted partitions boot problem, do you have any non-encrypted filesystem? If yes then you could copy /[s]bin and /lib to it and boot via init=/bin/bash, you ought to get a minimal shell and be able to run /sbin/reboot. 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: [PATCH v3 2/2] hwrng: msm: Add PRNG support for MSM SoC's
On Fri, Oct 25, 2013 at 04:57:23PM +0300, Stanimir Varbanov wrote: > Hi Herbert, > > On 10/23/2013 12:45 PM, Herbert Xu wrote: > > On Wed, Oct 23, 2013 at 12:41:10PM +0300, Stanimir Varbanov wrote: > >> On 10/15/2013 05:11 PM, Stanimir Varbanov wrote: > >>> This adds a driver for hardware random number generator present > >>> on Qualcomm MSM SoC's. > >>> > >>> Signed-off-by: Stanimir Varbanov > >> > >> Hi Matt, Herbert, > >> > >> Sorry for the noise but this patch staying for a while in mailing list > >> and I'd like to get some attention to this driver. Do you think it needs > >> another re-spin or it has obvious issues / concerns? > >> > >> Thanks for your time. > > > > Well if the ARM folks are OK with it I'm happy to take them. > > Thanks! > > Can I add your Acked-by for the driver part patch 2/2? Sure. Acked-by: Herbert Xu -- 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 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Kamil,
On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski wrote:
> Change the phy provider used from the old usb phy specific to a new one
> using the generic phy framework.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> drivers/usb/host/ehci-s5p.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 7cc26e6..76606ff 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -45,7 +46,7 @@ static struct hc_driver __read_mostly s5p_ehci_hc_driver;
>
> struct s5p_ehci_hcd {
> struct clk *clk;
> - struct usb_phy *phy;
> + struct phy *phy;
> struct usb_otg *otg;
> struct s5p_ehci_platdata *pdata;
> };
> @@ -77,10 +78,11 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> {
> struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
> struct s5p_ehci_hcd *s5p_ehci;
> + struct phy *phy;
just a nit here:
Lets keep the pointer to 'phy' and 'phy_name' together ?
and move this above phy_name ?
> struct usb_hcd *hcd;
> struct ehci_hcd *ehci;
> struct resource *res;
> - struct usb_phy *phy;
> + const char *phy_name;
> int irq;
> int err;
>
> @@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> return -ENOMEM;
> }
> s5p_ehci = to_s5p_ehci(hcd);
> -
> + phy_name = of_get_property(pdev->dev.of_node, "phy-names", NULL);
> + phy = devm_phy_get(&pdev->dev, phy_name);
Below check for exynos5440 was supposed to skip any request phy.
So shouldn't we place above two assignments to the original place
where devm_usb_get_phy()
was called ?
May be i am not getting you intention of changing the place.
> if (of_device_is_compatible(pdev->dev.of_node,
> "samsung,exynos5440-ehci")) {
> s5p_ehci->pdata = &empty_platdata;
> goto skip_phy;
> }
>
> - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> if (IS_ERR(phy)) {
> /* Fallback to pdata */
> if (!pdata) {
> @@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> }
> } else {
> s5p_ehci->phy = phy;
> - s5p_ehci->otg = phy->otg;
> }
>
> skip_phy:
> @@ -166,7 +167,7 @@ skip_phy:
> s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
Lets remove this line and similar calls to 'set_host()' in the driver,
since we don't have
s5p_ehci->otg anymore after the same is removed above.
Anyways this was helping the old phy-samsung-usb2 driver, and not needed now.
>
> if (s5p_ehci->phy)
> - usb_phy_init(s5p_ehci->phy);
> + phy_power_on(s5p_ehci->phy);
> else if (s5p_ehci->pdata->phy_init)
> s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
> @@ -188,7 +189,7 @@ skip_phy:
>
> fail_add_hcd:
> if (s5p_ehci->phy)
> - usb_phy_shutdown(s5p_ehci->phy);
> + phy_power_off(s5p_ehci->phy);
> else if (s5p_ehci->pdata->phy_exit)
> s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> fail_io:
> @@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
> s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
ditto
>
> if (s5p_ehci->phy)
> - usb_phy_shutdown(s5p_ehci->phy);
> + phy_power_off(s5p_ehci->phy);
> else if (s5p_ehci->pdata->phy_exit)
> s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> @@ -244,7 +245,7 @@ static int s5p_ehci_suspend(struct device *dev)
> s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
ditto
>
> if (s5p_ehci->phy)
> - usb_phy_shutdown(s5p_ehci->phy);
> + phy_power_off(s5p_ehci->phy);
> else if (s5p_ehci->pdata->phy_exit)
> s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> @@ -265,7 +266,7 @@ static int s5p_ehci_resume(struct device *dev)
> s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
ditto
>
> if (s5p_ehci->phy)
> - usb_phy_init(s5p_ehci->phy);
> + phy_power_on(s5p_ehci->phy);
> else if (s5p_ehci->pdata->phy_init)
> s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
[..] Rest looks good. :-)
--
Best Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] mm/zswap: refoctor the get/put routines
On Fri, Oct 25, 2013 at 6:20 PM, Minchan Kim wrote: > On Thu, Oct 24, 2013 at 05:53:32PM +0800, Weijie Yang wrote: >> The refcount routine was not fit the kernel get/put semantic exactly, >> There were too many judgement statements on refcount and it could be minus. >> >> This patch does the following: >> >> - move refcount judgement to zswap_entry_put() to hide resource free >> function. >> >> - add a new function zswap_entry_find_get(), so that callers can use easily >> in the following pattern: >> >>zswap_entry_find_get >>.../* do something */ >>zswap_entry_put >> >> - to eliminate compile error, move some functions declaration >> >> This patch is based on Minchan Kim 's idea and >> suggestion. >> >> Signed-off-by: Weijie Yang >> Cc: Seth Jennings >> Cc: Minchan Kim >> Cc: Bob Liu > > > I remember Bob had a idea to remove a look up and I think it's doable. > Anyway, I don't mind you send it with fix or not. Thanks for review. Bob's idea is: "Then how about use if (!RB_EMPTY_NODE(&entry->rbnode)) to replace rbtree searching?" I'm afraid not. Because entry could be freed in previous zswap_entry_put, we cann't reference entry or we would touch a free-and-use issue. > Thanks for handling this, Weijie! > > Acked-by: Minchan Kim > > -- > Kind regards, > Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
* Srikar Dronamraju wrote: > Hi Pekka, > > > > > > > You can now use it in all perf tools, such as: > > > > > > perf record -e libc:my_event -aR sleep 1 > > > > Is there a technical reason why 'perf list' could not show all the > > available SDT markers on a system and that the 'market to event' > > mapping cannot happen automatically? > > > > Technically feasible. But then we would have to parse each of the > libraries and executables to list them. Right? I am not sure if > such a delay is acceptable. I'd say lets try Pekka's suggestion and make it more palatable if there's complaints about the delay. (SSD systems are becoming dominant and there the search should be reasonably fast.) We could also make 'perf list' more sophisticated, if invoked naively as 'perf list' then maybe it should first display the various event categories, with a (rough) count: $ perf list 34 hardware events # use 'perf list --hw'to list them 40 hw-cache events # use 'perf list --cache' to list them 20 software events # use 'perf list --sw'to list them 2 raw events# use 'perf list --raw' to list them 120 tracepoints # use 'perf list --tp'to list them >10 SDT tracepoints # use 'perf list --sdt' to list them # use 'perf list -a' to list all events # use 'perf list ./binary' to list events in a given binary I.e. bring a bit more structure into it. > Also if a binary exists in a path thats is not covered in the > default search, an user might believe that his binary may not have > markers. I know the above reason is more of a user folly than a > tooling issue. I think in 99% of the usecases people will either use pre-built markers that come with their distro, or will be intimately aware of the markers because they are in the very app they are developing. So I wouldn't worry about 'user has a weird binary' case too much. I agree with Pekka that making them easily discoverable and visible as a coherent whole is really important. 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: [PATCH 02/11] asmlinkage: Make __iowrite32_copy visible
* Andi Kleen wrote: > From: Andi Kleen > > This is a assembler function on x86, so it should be visible. > > Cc: x...@kernel.org > Signed-off-by: Andi Kleen > --- > include/linux/io.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) NAK for this and all the other patches, for two technical reasons: - Please squash most of these trivial patches into a single patch that also describes the context completely, at least the x86 and core kernel ones that I'd apply within a single maintenance domain. - Please use the customary changelog style we use in the kernel: " Current code does (A), this has a problem when (B). We can improve this doing (C), because (D)." Just saying 'because of LTO' is not enough, obviously. You need to talk about and explain things Andi. Being cryptic, mysterious and curt might work with some ladies, but it's outright harmful on lkml. 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 PULLv2] For x86/mce ... enhanced error logs
* Luck, Tony wrote:
> Replacement for yesterday's pull request - fixes a build bug when CONFIG_SMP=n
> found by Fengguang's zero-day auto-build robot army. If you pulled (and
> pushed)
> that one before finding this in your mailbox - then I can send the one-line
> patch to be applied on top of yesterday's version.
>
> -Tony
>
> The following changes since commit 31d141e3a666269a3b6fcccddb0351caf7454240:
>
> Linux 3.12-rc6 (2013-10-19 12:28:15 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
> tags/please-pull-eMCA-fix
>
> for you to fetch changes up to 0f6d98727f0eea8cdeea4a3eacff266cad7dc764:
>
> UEFI, CPER: Move cper.c to a more proper place (2013-10-23 10:11:08 -0700)
>
>
> There is a enhanced error logging mechanism for Xeon processors.
> Full description is here:
> http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html
> This patch series provides a module (and support code) to
> check for an extended error log and print extra details about
> the error on the console.
>
>
> Chen, Gong (10):
> ACPI, APEI, CPER: Fix status check during error printing
> ACPI, CPER: Update cper info
> bitops: Introduce a more generic BITMASK macro
> ACPI, x86: Extended error log driver for x86 platform
> DMI: Parse memory device (type 17) in SMBIOS
> ACPI, APEI, CPER: Add UEFI 2.4 support for memory error
> ACPI, APEI, CPER: Enhance memory reporting capability
> ACPI, APEI, CPER: Cleanup CPER memory error output format
> EDAC, GHES: Update ghes error record info
> UEFI, CPER: Move cper.c to a more proper place
>
> arch/ia64/kernel/setup.c | 1 +
> arch/x86/include/asm/mce.h| 1 +
> arch/x86/kernel/cpu/mcheck/mce-apei.c | 3 +-
> arch/x86/kernel/setup.c | 1 +
> drivers/acpi/Kconfig | 20 +++
> drivers/acpi/Makefile | 2 +
> drivers/acpi/acpi_extlog.c| 327
> ++
> drivers/acpi/apei/Kconfig | 1 +
> drivers/acpi/apei/Makefile| 2 +-
> drivers/acpi/apei/apei-internal.h | 12 +-
> drivers/acpi/apei/ghes.c | 58 +++---
> drivers/acpi/bus.c| 3 +-
> drivers/edac/amd64_edac.c | 46 ++---
> drivers/edac/amd64_edac.h | 8 -
> drivers/edac/ghes_edac.c | 16 +-
> drivers/edac/sb_edac.c| 2 +-
> drivers/firmware/dmi_scan.c | 60 +++
> drivers/video/sis/init.c | 5 +-
> include/acpi/actbl1.h | 14 +-
> include/acpi/ghes.h | 2 +-
> include/linux/acpi.h | 1 +
> include/linux/bitops.h| 8 +
> include/linux/cper.h | 13 +-
> include/linux/dmi.h | 5 +
> include/linux/edac.h | 2 +-
> lib/Kconfig | 4 +
> lib/Makefile | 1 +
> {drivers/acpi/apei => lib}/cper.c | 132 +++---
> 28 files changed, 600 insertions(+), 150 deletions(-)
> create mode 100644 drivers/acpi/acpi_extlog.c
> rename {drivers/acpi/apei => lib}/cper.c (76%)
Pulled, thanks Tony!
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 PULLv2] For x86/mce ... enhanced error logs
* Tony Luck wrote: > On Wed, Oct 23, 2013 at 10:42 AM, Luck, Tony wrote: > > Replacement for yesterday's pull request - fixes a build bug when > > CONFIG_SMP=n > > found by Fengguang's zero-day auto-build robot army. If you pulled (and > > pushed) > > that one before finding this in your mailbox - then I can send the one-line > > patch to be applied on top of yesterday's version. > > Well - I might as well put the brown paper bag over my head and go sit > in the corner :-( > > I accidentally applied an extra patch "UEFI, CPER: Move cper.c to a > more proper place" > that Chen Gong had sent to me internally but has only been mentioned > in concept on the mailing list. Hm, I'm not sure we should move something named after a hardware feature into lib/. It's not really generic C library functionality, is it? > So feel free to pop the 10th patch off and drop it. Yeah, I did that. 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: ddccontrol doesn't work on the new kernel
CCing intel-gfx as it is related to intel GPU driver and might get missed by intel developers on LKML. Looking at the linked pastebins ddcontrol seems to make use of the same i2c/DDC line but getting different results. Surprising info I see in dmesg, that does apply to both kernels, is that uvesafb attaches intel GPU *after* i915/KMS has done so. Both i915 and uvesafb seem to be modular. Bruno On Fri, 25 October 2013 dbz wrote: > Hi, guys and girls! > > I have a strange trouble with ddccontrol that I cannot identify and solve > for about a month, so I hope you'll be able to help me. > > So, I'm using LMDE system (http://linuxmint.com/start/debian/). Initially > the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips > 232E2SB. I was able to change monitor brightness through ddccontrol > commands and I was really happy :) > > Then I upgraded my system to Update Pack 7, and the new kernel became of > version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still > works on the old one (so this isn't software issue). > > I have checked kernel configs - for the old kernel and for the new one. > Both configs are identical at i2c sections. I've tried to use old (3.2.32's > one) config with the new kernel, but there was no success. > > To be absolutely sure that the problem isn't in the this specific kernel > version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and > tried to use old config on this new kernel, but the issue is still > reproducing... > > It would be great if you can give me right direction on this issue, 'cause > I don't know what to do now... I really need new kernel and ability to use > ddccontrol. > > P.S. Additional info: > > The output of 'i2cdetect -l' on the old kernel (3.2.32): > http://pastebin.com/SqDPcwS9 > The same on the new one (3.10.5): http://pastebin.com/YCTmX90m > > The output of 'ddccontrol -p' on the old kernel (3.2.32): > http://pastebin.com/QL0fAZVC > The same on the new one (3.10.5): http://pastebin.com/vZ4bALmt > > And dmesg outputs for both 3.2.32 and 3.10.5 kernels: > - 3.2.32: http://pastebin.com/7ijujvkA > - 3.10.5: http://pastebin.com/t1wdKrAd > > I really need someone's help with ddccontrol. It would be great if you or > someone else who do you know can help me :) > > Thank you in advance! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] UBIFS: fix error return code in ubifs_remount_rw() and ubifs_fill_super()
On Wed, 2013-10-02 at 12:59 -0700, Brian Norris wrote: > Bump, Artem? I'm cleaning out my old email, and this patch looks > obviously correct. Picked to linux-ubifs.git, thanks! -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: unify copy_from_user() size checking
* Jan Beulich wrote:
> Commits 4a3127693001c61a21d1ce680db6340623f52e93 ("x86: Turn the
> copy_from_user check into an (optional) compile time warning") and
> 63312b6a6faae3f2e5577f2b001e3b504f10a2aa ("x86: Add a Kconfig option to
> turn the copy_from_user warnings into errors") touched only the 32-bit
> variant of copy_from_user(), whereas the original commit
> 9f0cf4adb6aa0bfccf675c938124e68f7f06349d ("x86: Use
> __builtin_object_size() to validate the buffer size for
> copy_from_user()") also added the same code to the 64-bit one.
>
> Further the earlier conversion from an inline WARN() to the call to
> copy_from_user_overflow() went a little too far: When the number of
> bytes to be copied is not a constant (e.g. [looking at 3.11] in
> drivers/net/tun.c:__tun_chr_ioctl() or
> drivers/pci/pcie/aer/aer_inject.c:aer_inject_write()), the compiler
> will always have to keep the funtion call, and hence there will always
> be a warning. By using __builtin_constant_p() we can avoid this.
>
> And then this slightly extends the effect of
> CONFIG_DEBUG_STRICT_USER_COPY_CHECKS in that apart from converting
> warnings to errors in the constant size case, it retains the (possibly
> wrong) warnings in the non-constant size case, such that if someone is
> prepared to get a few false positives, (s)he'll be able to recover the
> current behavior (except that these diagnostics now will never be
> converted to errors).
>
> Since the 32-bit variant (intentionally) didn't call might_fault(), the
> unification results in this being called twice now. Adding a suitable
> #ifdef would be the alternative if that's a problem.
Addressing that sanely would be nice.
> I'd like to point out though that with __compiletime_object_size()
> being restricted to gcc before 4.6, the whole construct is going to
> become more and more pointless going forward. I would question
> however that commit 2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a2 ("gcc4:
> disable __compiletime_object_size for GCC 4.6+") was really necessary,
> and instead this should have been dealt with as is done here from the
> beginning.
Can we now revert 2fb0815c9ee6?
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: [PATCH] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
* Don Zickus wrote: > On Thu, Oct 24, 2013 at 12:52:06PM +0200, Peter Zijlstra wrote: > > On Wed, Oct 23, 2013 at 10:48:38PM +0200, Peter Zijlstra wrote: > > > I'll also make sure to test we actually hit the fault path > > > by concurrently running something like: > > > > > > while :; echo 1 > /proc/sys/vm/drop_caches ; done > > > > > > while doing perf top or so.. > > > > So the below appears to work; I've ran: > > > > while :; do echo 1 > /proc/sys/vm/drop_caches; sleep 1; done & > > while :; do make O=defconfig-build/ clean; perf record -a -g fp -e > > cycles:pp make O=defconfig-build/ -s -j64; done > > > > And verified that the if (in_nmi()) trace_printk() was visible in the > > trace output verifying we indeed took the fault from the NMI code. > > > > I've had this running for ~ 30 minutes or so and the machine is still > > healthy. > > > > Don, can you give this stuff a spin on your system? > > Hi Peter, > > I finally had a chance to run this on my machine. From my > testing, it looks good. Better performance numbers. I think my > longest latency went from 300K cycles down to 150K cycles and very > few of those (most are under 100K cycles). Btw., do we know where those ~100k-150k cycles are spent specifically? 100k cycles is still an awful lot of time to spend in NMI context ... 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: [PATCH 0/3] fs: use helper function path_foo() to simpily code
Any advice? ping... On 10/14 20:25, Kefeng Wang wrote: > Use helper function patch_equal() and path_put() to simpily code. > > Kefeng Wang (3): > fs: use path_equal() and path_put() to simplify code > fs: nfsd: use path_equal() to simply code > fs: notify: use path_equal() to simply code > > fs/namei.c | 20 ++-- > fs/nfsd/export.c | 3 +-- > fs/nfsd/nfs4xdr.c| 2 +- > fs/notify/fanotify/fanotify.c| 3 +-- > fs/notify/inotify/inotify_fsnotify.c | 3 +-- > 5 files changed, 10 insertions(+), 21 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
Pekka Enberg writes: > Is there a technical reason why 'perf list' could not show all the > available SDT markers on a system and that the 'mark to event' > mapping cannot happen automatically? [...] A quick experiment with: find `echo $PATH | tr : ' '` -type f -perm -555 | xargs readelf -n 2>/dev/null | grep STAP 2>/dev/null suggests reasonable performance for my F19 workstation (a second or two over ~6000 executables), once all the ELF content is in the block cache. According to a stap eventcount.stp run, that required about 5 syscall.read events. Note that a $PATH search excludes shared libraries, which can also carry markers. Adding /usr/lib* in more than doubles the work, then there's /usr/libexec etc. - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] charger-manager: Use IIO subsystem to read battery temperature instead of legacy method
On 10/22/2013 02:51 PM, Chanwoo Choi wrote:
> This patch support charger-manager use IIO(Industrial I/O) subsystem to read
> current battery temperature instead of legacy methor about callback function.
How does this look in hardware? Do you have a general purpose ADC connected
to a temperature sensor that has a temperature dependent voltage output? And
at some point during the board design you measure the raw value of the ADC
both for the lower and the upper threshold temperatures?
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Kyungmin Park
> Signed-off-by: Myungjoo Ham
> ---
> drivers/power/Kconfig | 1 +
> drivers/power/charger-manager.c | 88
> +--
> include/linux/power/charger-manager.h | 13 ++
> 3 files changed, 97 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index e6f92b4..6700191 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -309,6 +309,7 @@ config CHARGER_MANAGER
> bool "Battery charger manager for multiple chargers"
> depends on REGULATOR && RTC_CLASS
> select EXTCON
> + select IIO
Are you sure you want to force select the IIO framework? It looks like we do
not stub out iio_channel_get() and friends yet if CONFIG_IIO is not
selected. But I think that will the better solution here.
> help
>Say Y to enable charger-manager support, which allows multiple
>chargers attached to a battery and multiple batteries attached to a
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
> index cc720f9..02a395c 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> static const char * const default_event_names[] = {
> [CM_EVENT_UNKNOWN] = "Unknown",
> @@ -542,6 +543,50 @@ static int check_charging_duration(struct
> charger_manager *cm)
> }
>
> /**
> + * read_battery_temperature - Read current battery temperature
> + * @cm: the Charger Manager representing the battery.
> + * @last_temp_mC: store current battery temperature
> + *
> + * Returns current state of temperature by using IIO or legacy method
> + * - CM_TEMP_NORMAL
> + * - CM_TEMP_OVERHEAT
> + * - CM_TEMP_COLD
> + */
> +static int read_battery_temperature(struct charger_manager *cm,
> + int *last_temp_mC)
> +{
> + struct charger_desc *desc = cm->desc;
> + int temp;
> +
> + if (desc->channel) {
> + temp = iio_read_channel_raw(desc->channel, last_temp_mC);
> +
> + /*
> + * The charger-manager use IIO subsystem to read ADC raw data
> + * from IIO ADC device drvier. The each device driver has
> + * own non-standard ADC table. If user of charger-manager
> + * would like to get correct temperature value, have to convert
> + * 'last_temp_mC' variable according to proper calculation
> + * method and own ADC table.
> + */
> +
> + if (*last_temp_mC >= desc->iio_adc_overheat)
> + temp = CM_TEMP_NORMAL; /* Overheat */
temp = CM_TEMP_OVERHEAT ?
> + else if (*last_temp_mC <= desc->iio_adc_cold)
> + temp = CM_TEMP_COLD;/* Cold */
> + else
> + temp = CM_TEMP_NORMAL; /* Normal */
> +
> + } else if (desc->temperature_out_of_range) {
> + temp = desc->temperature_out_of_range(last_temp_mC);
> + } else {
> + temp = INT_MAX;
> + }
> +
> + return temp;
> +}
> +
> +/**
> * _cm_monitor - Monitor the temperature and return true for exceptions.
> * @cm: the Charger Manager representing the battery.
> *
> @@ -551,7 +596,7 @@ static int check_charging_duration(struct charger_manager
> *cm)
> static bool _cm_monitor(struct charger_manager *cm)
> {
> struct charger_desc *desc = cm->desc;
> - int temp = desc->temperature_out_of_range(&cm->last_temp_mC);
> + int temp = read_battery_temperature(cm, &cm->last_temp_mC);
>
> dev_dbg(cm->dev, "monitoring (%2.2d.%3.3dC)\n",
> cm->last_temp_mC / 1000, cm->last_temp_mC % 1000);
> @@ -805,7 +850,7 @@ static int charger_get_property(struct power_supply *psy,
> case POWER_SUPPLY_PROP_TEMP:
> /* in thenth of centigrade */
> if (cm->last_temp_mC == INT_MIN)
> - desc->temperature_out_of_range(&cm->last_temp_mC);
> + read_battery_temperature(cm, &cm->last_temp_mC);
So this will now return the raw ADC value to userspace on a property that is
supposed to indicate milli-degree Celsius. That doesn't seem to be right.
> val->intval = cm->last_temp_mC / 100;
> if (!desc->meaure_battery_temp)
> ret = -ENODEV;
> @@ -813,7 +858,7 @@ static int charger_
Re: [PATCHv6 1/3] Input: twl4030-pwrbutton - add device tree support
On Sat, Oct 26, 2013 at 01:37:57AM -0500, Kumar Gala wrote:
>
> On Oct 25, 2013, at 5:18 PM, Sebastian Reichel wrote:
>
> > On Fri, Oct 25, 2013 at 04:41:20PM -0500, Kumar Gala wrote:
> >> On Oct 24, 2013, at 9:48 AM, Sebastian Reichel wrote:
> >>> +- interrupt: should be one of the following
> >>> + - <8>: For controllers compatible with twl4030
> >>
> >> Just checking, but the interrupt is always 8 for this device?
> >
> > Yes. It's currently hardcoded in drivers/mfd/twl-core.c.
>
> The fact that is hard coded in the driver does not imply that it
> should be in the device tree binding. Is there an interrupt
> controller as part of the TWL4030?
Hardware looks like this:
&twl4030 {
compatible = "ti,twl4030";
interrupt-controller;
#interrupt-cells = <1>;
twl_pwrbutton: pwrbutton {
compatible = "ti,twl4030-pwrbutton";
interrupts = <8>; /* 8th interrupt from the twl4030 */
};
};
Simplified the initialization of twl4030 stuff works
like this for non DT boot:
twl4030_init(...) {
init_subdev(...);
init_subdev("twl4030-pwrbutton", ..., irq=8, ...);
init_subdev(...);
};
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH 14/34] sysfs, kernfs: prepare read path for kernfs
Hi!
> We're in the process of separating out core sysfs functionality into
> kernfs which will deal with sysfs_dirents directly. This patch
> rearranges read path so that the kernfs and sysfs parts are separate.
> +static int sysfs_kf_seq_show(struct seq_file *sf, void *v)
> {
> struct sysfs_open_file *of = sf->private;
> struct kobject *kobj = of->sd->s_parent->priv;
> - const struct sysfs_ops *ops;
> + const struct sysfs_ops *ops = sysfs_file_ops(of->sd);
> + ssize_t count = 0;
> char *buf;
> - ssize_t count;
>
> /* acquire buffer and ensure that it's >= PAGE_SIZE */
> count = seq_get_buf(sf, &buf);
Initing count to zero is superfluous here.
> + /* the same behavior as single_open() */
> + return NULL + !*ppos;
> +}
That's certainly interesting code.
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Disabling in-memory write cache for x86-64 in Linux II
On Fri 2013-10-25 10:32:16, Linus Torvalds wrote: > On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton > wrote: > > > > Apparently all this stuff isn't working as desired (and perhaps as designed) > > in this case. Will take a look after a return to normalcy ;) > > It definitely doesn't work. I can trivially reproduce problems by just > having a cheap (==slow) USB key with an ext3 filesystem, and going a > git clone to it. The end result is not pretty, and that's actually not > even a huge amount of data. Hmm, I'd expect the result to be "dead USB key". Putting ext3 on cheap flash device normally just kills the devic :-(. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
* Linus Torvalds wrote:
> On Fri, Oct 25, 2013 at 11:23 AM, Thomas Gleixner wrote:
> >
> > Enable DEBUG_OBJECTS, DEBUG_OBJECTS_FREE, DEBUG_OBJECTS_TIMERS
>
> Yes, but nobody has actually been able to trigger it with those.
> It's pretty rare, and the debug options are so expensive that they
> aren't reasonable to enable generally...
>
> So we need to try to figure out how to trigger it, or narrow
> things down some way..
If it's timing then maybe the 1 seconds delay isn't enough
(especially if it's boot related, where we have a couple of delays
already) - the patch below triples it.
(If the bug goes away due to some other side effect then this patch
won't make a difference to reproducability.)
Thanks,
Ingo
diff --git a/lib/kobject.c b/lib/kobject.c
index 084f7b1..124188f 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -595,7 +595,7 @@ static void kobject_release(struct kref *kref)
pr_info("kobject: '%s' (%p): %s, parent %p (delayed)\n",
kobject_name(kobj), kobj, __func__, kobj->parent);
INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
- schedule_delayed_work(&kobj->release, HZ);
+ schedule_delayed_work(&kobj->release, 3*HZ);
#else
kobject_cleanup(kobj);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
blk-mq flush fix
I've just ran into an issue where I ran out of blk-mq tags on my virtio setup on what appears a heavy fsync workload. When drilling it down it seemed to be a tag leak. This reminded me of a commit I had seen in the scsi-mq tree but never on any mailinglist (and neither in my Inbox despite the Cc tag) which turned out to be in Jens' blk-mq tree either. https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=scsi-mq&id=620fe5a562440a823e7a25ae99dc19a6fbd53949 >From a quick look over the patch I'm not entirely sure it's correct, but it's at least going in the right direction. The reason for the issue that Alexander and I saw is the following: The flush state machine takes in a struct request, which then is submitted multiple times to the underling driver. The old block code requeses the same request for each of those, so it does not have an issue with tapping into the request pool. The new one on the other hand allocates a new request for each of the actualy steps of the flush sequence. In theory this should make the patch from Alexander the right fix, except that we do have a corner case where we do not do the above steps: In case the state machine doesn't need to be run we issue the request directly. This either happens if the driver doesn't need any cache flushes, or we only requested force unit access and the driver supports that natively. It seems like we should set simply not require a tag at all for those sub requests and solve the issue that way. And Alexander and Nick: how did this patch end up in Nick's tree? I'm a bit curious at all as there's been no visibility at all, despite Cc tags to Jens and me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Run checksumming in parallel accross multiple alu's
* Doug Ledford wrote: > > What I was objecting to strongly here was to measure the _wrong_ > > thing, i.e. the cache-hot case. The cache-cold case should be > > measured in a low noise fashion, so that results are > > representative. It's closer to the real usecase than any other > > microbenchmark. That will give us a usable speedup figure and > > will tell us which technique helped how much and which parameter > > should be how large. > > Cold cache, yes. Low noise, yes. But you need DMA traffic at the > same time to be truly representative. Well, but in most usecases network DMA traffic is an order of magnitude smaller than system bus capacity. 100 gigabit network traffic is possible but not very common. So I'd say that _if_ prefetching helps in the typical case we should tune it for that - not for the bus-contended case... > >> [...] This distance should be far enough out that it can > >> withstand other memory pressure, yet not so far as to > >> constantly be prefetching, tossing the result out of cache due > >> to pressure, then fetching/stalling that same memory on load. > >> And it may not benchmark as well on a quiescent system running > >> only the micro-benchmark, but it should end up performing > >> better in actual real world usage. > > > > The 'fully adversarial' case where all resources are maximally > > competed for by all other cores is actually pretty rare in > > practice. I don't say it does not happen or that it does not > > matter, but I do say there are many other important usecases as > > well. > > > > More importantly, the 'maximally adversarial' case is very hard > > to generate, validate, and it's highly system dependent! > > This I agree with 100%, which is why I tend to think we should > scrap the static prefetch optimizations entirely and have a boot > up test that allows us to find our optimum prefetch distance for > our given hardware. Would be interesting to see. I'm a bit sceptical - I think 'looking 1-2 cachelines in advance' is something that might work reasonably well on a wide range of systems, while trying to find a bus capacity/latency dependent sweet spot would be difficult. We had pretty bad experience from boot-time measurements, and it's not for lack of trying: I implemented the raid algorithm benchmarking thing and also the scheduler's boot time cache-size probing, both were problematic and have hurt reproducability and debuggability. 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/
[PATCH] drivers: w1: make w1_slave::flags long to avoid casts
From: Michal Nazarewicz
Changing flags field of the w1_slave to unsigned long may on
some architectures increase the size of the structure, but
otherwise makes the code more kosher as casting is avoided
and *_bit family of calls do not attempt to operate on an
entity of bigger size than realy is available.
The current behaviour does not introduce any bugs (since any
bytes past flags field are preserved) but make the code
slightly more confusing then it needs to be.
Signed-off-by: Michal Nazarewicz
---
drivers/w1/w1.c | 10 +-
drivers/w1/w1.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index fa932c2..66efa96 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -709,7 +709,7 @@ static int w1_attach_slave_device(struct w1_master *dev,
struct w1_reg_num *rn)
sl->owner = THIS_MODULE;
sl->master = dev;
- set_bit(W1_SLAVE_ACTIVE, (long *)&sl->flags);
+ set_bit(W1_SLAVE_ACTIVE, &sl->flags);
memset(&msg, 0, sizeof(msg));
memcpy(&sl->reg_num, rn, sizeof(sl->reg_num));
@@ -866,7 +866,7 @@ void w1_slave_found(struct w1_master *dev, u64 rn)
sl = w1_slave_search_device(dev, tmp);
if (sl) {
- set_bit(W1_SLAVE_ACTIVE, (long *)&sl->flags);
+ set_bit(W1_SLAVE_ACTIVE, &sl->flags);
} else {
if (rn && tmp->crc == w1_calc_crc8((u8 *)&rn_le, 7))
w1_attach_slave_device(dev, tmp);
@@ -984,14 +984,14 @@ void w1_search_process_cb(struct w1_master *dev, u8
search_type,
struct w1_slave *sl, *sln;
list_for_each_entry(sl, &dev->slist, w1_slave_entry)
- clear_bit(W1_SLAVE_ACTIVE, (long *)&sl->flags);
+ clear_bit(W1_SLAVE_ACTIVE, &sl->flags);
w1_search_devices(dev, search_type, cb);
list_for_each_entry_safe(sl, sln, &dev->slist, w1_slave_entry) {
- if (!test_bit(W1_SLAVE_ACTIVE, (unsigned long *)&sl->flags) &&
!--sl->ttl)
+ if (!test_bit(W1_SLAVE_ACTIVE, &sl->flags) && !--sl->ttl)
w1_slave_detach(sl);
- else if (test_bit(W1_SLAVE_ACTIVE, (unsigned long *)&sl->flags))
+ else if (test_bit(W1_SLAVE_ACTIVE, &sl->flags))
sl->ttl = dev->slave_ttl;
}
diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
index 45908e5..ca8081a 100644
--- a/drivers/w1/w1.h
+++ b/drivers/w1/w1.h
@@ -67,8 +67,8 @@ struct w1_slave
struct w1_reg_num reg_num;
atomic_trefcnt;
u8 rom[9];
- u32 flags;
int ttl;
+ unsigned long flags;
struct w1_master*master;
struct w1_family*family;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
* Neil Horman wrote: > On Mon, Oct 21, 2013 at 12:44:05PM -0700, Eric Dumazet wrote: > > On Mon, 2013-10-21 at 15:21 -0400, Neil Horman wrote: > > > > > > > > Ok, so I ran the above code on a single cpu using taskset, and set irq > > > affinity > > > such that no interrupts (save for local ones), would occur on that cpu. > > > Note > > > that I had to convert csum_partial_opt to csum_partial, as the _opt > > > variant > > > doesn't exist in my tree, nor do I see it in any upstream tree or in the > > > history > > > anywhere. > > > > This csum_partial_opt() was a private implementation of csum_partial() > > so that I could load the module without rebooting the kernel ;) > > > > > > > > base results: > > > 53569916 > > > 43506025 > > > 43476542 > > > 44048436 > > > 45048042 > > > 48550429 > > > 53925556 > > > 53927374 > > > 53489708 > > > 53003915 > > > > > > AVG = 492 ns > > > > > > prefetching only: > > > 53279213 > > > 45518140 > > > 49585388 > > > 53176179 > > > 44071822 > > > 43588822 > > > 44086546 > > > 47507065 > > > 53646812 > > > 54469118 > > > > > > AVG = 488 ns > > > > > > > > > parallel alu's only: > > > 46226844 > > > 44458101 > > > 46803498 > > > 45060002 > > > 46187624 > > > 37542946 > > > 45632866 > > > 46275249 > > > 45031141 > > > 46281204 > > > > > > AVG = 449 ns > > > > > > > > > both optimizations: > > > 45708837 > > > 45631124 > > > 45697135 > > > 45647011 > > > 45036679 > > > 39418544 > > > 44481577 > > > 46820868 > > > 44496471 > > > 35523928 > > > > > > AVG = 438 ns > > > > > > > > > We continue to see a small savings in execution time with prefetching (4 > > > ns, or > > > about 0.8%), a better savings with parallel alu execution (43 ns, or > > > 8.7%), and > > > the best savings with both optimizations (54 ns, or 10.9%). > > > > > > These results, while they've changed as we've modified the test case > > > slightly > > > have remained consistent in their sppedup ordinality. Prefetching helps, > > > but > > > not as much as using multiple alu's, and neither is as good as doing both > > > together. > > > > > > Unless you see something else that I'm doing wrong here. It seems like a > > > win to > > > do both. > > > > > > > Well, I only said (or maybe I forgot), that on my machines, I got no > > improvements at all with the multiple alu or the prefetch. (I tried > > different strides) > > > > Only noises in the results. > > > I thought you previously said that running netperf gave you a stastically > significant performance boost when you added prefetching: > http://marc.info/?l=linux-kernel&m=138178914124863&w=2 > > But perhaps I missed a note somewhere. > > > It seems it depends on cpus and/or multiple factors. > > > > Last machine I used for the tests had : > > > > processor : 23 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 44 > > model name : Intel(R) Xeon(R) CPU X5660 @ 2.80GHz > > stepping: 2 > > microcode : 0x13 > > cpu MHz : 2800.256 > > cache size : 12288 KB > > physical id : 1 > > siblings: 12 > > core id : 10 > > cpu cores : 6 > > > > > > > > > > Thats about what I'm running with: > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 44 > model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz > stepping: 2 > microcode : 0x13 > cpu MHz : 1600.000 > cache size : 12288 KB > physical id : 0 > siblings: 8 > core id : 0 > cpu cores : 4 > > > I can't imagine what would cause the discrepancy in our results (a > 10% savings in execution time seems significant to me). My only > thought would be that possibly the alu's on your cpu are faster > than mine, and reduce the speedup obtained by preforming operation > in parallel, though I can't imagine thats the case with these > processors being so closely matched. You keep ignoring my request to calculate and account for noise of the measurement. For example you are talking about a 0.8% prefetch effect while the noise in the results is obviously much larger than that, with a min/max distance of around 5%: > > > 43476542 > > > 53927374 so the noise of 10 measurements would be around 5-10%. (back of the envelope calculation) So you might be right in the end, but the posted data does not support your claims, statistically. It's your responsibility to come up with convincing measurements and results, not of those who review your work. 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: RFP: Fixing "-ga -ag -g fp -g dwarf" was Re: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v5)
* Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 25, 2013 at 01:22:27PM -0600, David Ahern escreveu: > > On 10/25/13 1:09 PM, Arnaldo Carvalho de Melo wrote: > > >>>I think I did with the second follow up patch: -ga -ag -g fp -g > > >>>dwarf should all work properly with fp the default for -g. > > > >>Acked-by: Ingo Molnar > > > >Can I have this one submitted? > > > Upon further review, Jiri was correct: that patch handles some of > > the old cases fine, but did not handle others. ie., it just moved > > the bad syntax problem around. > > perhaps we can do, at least for now, with what Ingo suggested? > > Namely, having: > > --call-graph Require an argument, either "dwarf" or "fp" > -g Doesn't require anything, uses whatever is configured, >fp if no explicit config is done in places like >~/.perfconfig > > Fits with what most people do usually, no? Please do this! Usability sucks right now, going from '-g' to '-g ' was an incompatible change, a regression I argue, which should be fixed in an urgent branch ASAP. 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: Automatic NUMA balancing patches for tip-urgent/stable
* Mel Gorman wrote: > On Mon, Oct 07, 2013 at 11:28:38AM +0100, Mel Gorman wrote: > > This series has roughly the same goals as previous versions despite the > > size. It reduces overhead of automatic balancing through scan rate reduction > > and the avoidance of TLB flushes. It selects a preferred node and moves > > tasks > > towards their memory as well as moving memory toward their task. It handles > > shared pages and groups related tasks together. Some problems such as shared > > page interleaving and properly dealing with processes that are larger than > > a node are being deferred. This version should be ready for wider testing > > in -tip. > > > > Hi Ingo, > > Off-list we talked with Peter about the fact that automatic NUMA > balancing as merged in 3.10, 3.11 and 3.12 shortly may corrupt > userspace memory. There is one LKML report on this that I'm aware of -- > https://lkml.org/lkml/2013/7/31/647 which I prompt forgot to follow up > properly on . The user-visible effect is that pages get filled with zeros > with results such as null pointer exceptions in JVMs. It is fairly difficult > to trigger but it became much easier to trigger during the development of > the series "Basic scheduler support for automatic NUMA balancing" which > is how it was discovered and finally fixed. > > In that series I tagged patches 2-9 for -stable as these patches addressed > the problem for me. I did not call it out as clearly as I should have > and did not realise the cc: stable tags were stripped. Worse, as it was > close to the release and the bug is relatively old I was ok with waiting > until 3.12 came out and then treat it as a -stable backport. It has been > highlighted that this is the wrong attitude and we should consider merging > the fixes now and backporting to -stable sooner rather than later. > > The most important patches are > > mm: Wait for THP migrations to complete during NUMA hinting fault > mm: Prevent parallel splits during THP migration > mm: Close races between THP migration and PMD numa clearing > > but on their own they will cause conflicts with tricky fixups and -stable > would differ from mainline in annoying ways. Patches 2-9 have been heavily > tested in isolation so I'm reasonably confident they fix the problem and are > -stable material. While strictly speaking not all the patches are required > for the fix, the -stable kernels would then be directly comparable with > 3.13 when the full NUMA balancing series is applied. If I rework them at > this point then I'll also have to retest delaying things until next week. > > Please consider queueing patches 2-9 for 3.12 via -urgent if it is > not too late and preserve the cc: stable tags so Greg will pick > them up automatically. Would be nice if you gave me all the specific SHA1 tags of sched/core that are required for the fix. We can certainly use a range to make it all safer to apply. 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/
[GIT PULL] locking fix
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: b0267507dfd0187fb7840a0ec461a510a7f041c5 mutex: Avoid gcc version
dependent __builtin_constant_p() usage
This tree fixes a boot crash in CONFIG_DEBUG_MUTEXES=y kernels, on
kernels built with GCC 3.x. (There are still such distros.)
Thanks,
Ingo
-->
Tetsuo Handa (1):
mutex: Avoid gcc version dependent __builtin_constant_p() usage
kernel/mutex.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 6d647ae..d24105b 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -410,7 +410,7 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock,
static __always_inline int __sched
__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
struct lockdep_map *nest_lock, unsigned long ip,
- struct ww_acquire_ctx *ww_ctx)
+ struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
{
struct task_struct *task = current;
struct mutex_waiter waiter;
@@ -450,7 +450,7 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
struct task_struct *owner;
struct mspin_node node;
- if (!__builtin_constant_p(ww_ctx == NULL) && ww_ctx->acquired >
0) {
+ if (use_ww_ctx && ww_ctx->acquired > 0) {
struct ww_mutex *ww;
ww = container_of(lock, struct ww_mutex, base);
@@ -480,7 +480,7 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
if ((atomic_read(&lock->count) == 1) &&
(atomic_cmpxchg(&lock->count, 1, 0) == 1)) {
lock_acquired(&lock->dep_map, ip);
- if (!__builtin_constant_p(ww_ctx == NULL)) {
+ if (use_ww_ctx) {
struct ww_mutex *ww;
ww = container_of(lock, struct ww_mutex, base);
@@ -551,7 +551,7 @@ slowpath:
goto err;
}
- if (!__builtin_constant_p(ww_ctx == NULL) && ww_ctx->acquired >
0) {
+ if (use_ww_ctx && ww_ctx->acquired > 0) {
ret = __mutex_lock_check_stamp(lock, ww_ctx);
if (ret)
goto err;
@@ -575,7 +575,7 @@ skip_wait:
lock_acquired(&lock->dep_map, ip);
mutex_set_owner(lock);
- if (!__builtin_constant_p(ww_ctx == NULL)) {
+ if (use_ww_ctx) {
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
struct mutex_waiter *cur;
@@ -615,7 +615,7 @@ mutex_lock_nested(struct mutex *lock, unsigned int subclass)
{
might_sleep();
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
- subclass, NULL, _RET_IP_, NULL);
+ subclass, NULL, _RET_IP_, NULL, 0);
}
EXPORT_SYMBOL_GPL(mutex_lock_nested);
@@ -625,7 +625,7 @@ _mutex_lock_nest_lock(struct mutex *lock, struct
lockdep_map *nest)
{
might_sleep();
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
- 0, nest, _RET_IP_, NULL);
+ 0, nest, _RET_IP_, NULL, 0);
}
EXPORT_SYMBOL_GPL(_mutex_lock_nest_lock);
@@ -635,7 +635,7 @@ mutex_lock_killable_nested(struct mutex *lock, unsigned int
subclass)
{
might_sleep();
return __mutex_lock_common(lock, TASK_KILLABLE,
- subclass, NULL, _RET_IP_, NULL);
+ subclass, NULL, _RET_IP_, NULL, 0);
}
EXPORT_SYMBOL_GPL(mutex_lock_killable_nested);
@@ -644,7 +644,7 @@ mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass)
{
might_sleep();
return __mutex_lock_common(lock, TASK_INTERRUPTIBLE,
- subclass, NULL, _RET_IP_, NULL);
+ subclass, NULL, _RET_IP_, NULL, 0);
}
EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
@@ -682,7 +682,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
might_sleep();
ret = __mutex_lock_common(&lock->base, TASK_UNINTERRUPTIBLE,
- 0, &ctx->dep_map, _RET_IP_, ctx);
+ 0, &ctx->dep_map, _RET_IP_, ctx, 1);
if (!ret && ctx->acquired > 1)
return ww_mutex_deadlock_injection(lock, ctx);
@@ -697,7 +697,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
might_sleep();
ret = __mutex_lock_common(&lock->base, TASK_INTERRUPTIBLE,
- 0, &ctx->dep_map, _RET_IP_, ctx);
+
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: e4f8eaad70ea186b8da290c99239dce721a34f88 Merge tag
'perf-urgent-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
The tree contains three fixes:
- Two tooling fixes
- Reversal of the new 'MMAP2' extended mmap record ABI, introduced
in this merge window. (Patches were proposed to fix it but it was
all a bit late and we felt it's safer to just delay the ABI one
more kernel release and do it right.)
Thanks,
Ingo
-->
Arnaldo Carvalho de Melo (1):
perf scripting perl: Fix build error on Fedora 12
Masami Hiramatsu (1):
perf probe: Fix to initialize fname always before use it
Stephane Eranian (1):
perf: Disable PERF_RECORD_MMAP2 support
kernel/events/core.c | 4 +++
tools/perf/util/event.c| 30 ++
tools/perf/util/evsel.c| 1 -
tools/perf/util/probe-finder.c | 2 +-
.../perf/util/scripting-engines/trace-event-perl.c | 2 +-
5 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d49a9d2..953c143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6767,6 +6767,10 @@ static int perf_copy_attr(struct perf_event_attr __user
*uattr,
if (ret)
return -EFAULT;
+ /* disabled for now */
+ if (attr->mmap2)
+ return -EINVAL;
+
if (attr->__reserved_1)
return -EINVAL;
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 9b393e7..63df031 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -187,7 +187,7 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
return -1;
}
- event->header.type = PERF_RECORD_MMAP2;
+ event->header.type = PERF_RECORD_MMAP;
/*
* Just like the kernel, see __perf_event_mmap in kernel/perf_event.c
*/
@@ -198,7 +198,6 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
char prot[5];
char execname[PATH_MAX];
char anonstr[] = "//anon";
- unsigned int ino;
size_t size;
ssize_t n;
@@ -209,13 +208,10 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
strcpy(execname, "");
/* 0040-0040c000 r-xp fd:01 41038 /bin/cat */
- n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %x:%x %u %s\n",
- &event->mmap2.start, &event->mmap2.len, prot,
- &event->mmap2.pgoff, &event->mmap2.maj,
- &event->mmap2.min,
- &ino, execname);
-
- event->mmap2.ino = (u64)ino;
+ n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %*x:%*x %*u
%s\n",
+ &event->mmap.start, &event->mmap.len, prot,
+ &event->mmap.pgoff,
+ execname);
if (n != 8)
continue;
@@ -227,15 +223,15 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
strcpy(execname, anonstr);
size = strlen(execname) + 1;
- memcpy(event->mmap2.filename, execname, size);
+ memcpy(event->mmap.filename, execname, size);
size = PERF_ALIGN(size, sizeof(u64));
- event->mmap2.len -= event->mmap.start;
- event->mmap2.header.size = (sizeof(event->mmap2) -
- (sizeof(event->mmap2.filename) - size));
- memset(event->mmap2.filename + size, 0, machine->id_hdr_size);
- event->mmap2.header.size += machine->id_hdr_size;
- event->mmap2.pid = tgid;
- event->mmap2.tid = pid;
+ event->mmap.len -= event->mmap.start;
+ event->mmap.header.size = (sizeof(event->mmap) -
+ (sizeof(event->mmap.filename) - size));
+ memset(event->mmap.filename + size, 0, machine->id_hdr_size);
+ event->mmap.header.size += machine->id_hdr_size;
+ event->mmap.pid = tgid;
+ event->mmap.tid = pid;
if (process(tool, event, &synth_sample, machine) != 0) {
rc = -1;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0ce9feb..9f1ef9b 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -678,7 +678,6 @@ void perf_evsel__config(struct perf_evsel *evsel,
attr->sample_type |= PERF_SAMPLE_WEIGHT;
attr->mmap = track;
- attr->mma
[GIT PULL] timer fix
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 97b9410643475d6557d2517c2aff9fd2221141a9 clockevents: Sanitize ticks
to nsec conversion
This tree contains a clockevents regression fix for certain ARM
subarchitectures.
Thanks,
Ingo
-->
Thomas Gleixner (1):
clockevents: Sanitize ticks to nsec conversion
kernel/time/clockevents.c | 65 ---
1 file changed, 50 insertions(+), 15 deletions(-)
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 38959c8..662c579 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -33,29 +33,64 @@ struct ce_unbind {
int res;
};
-/**
- * clockevents_delta2ns - Convert a latch value (device ticks) to nanoseconds
- * @latch: value to convert
- * @evt: pointer to clock event device descriptor
- *
- * Math helper, returns latch value converted to nanoseconds (bound checked)
- */
-u64 clockevent_delta2ns(unsigned long latch, struct clock_event_device *evt)
+static u64 cev_delta2ns(unsigned long latch, struct clock_event_device *evt,
+ bool ismax)
{
u64 clc = (u64) latch << evt->shift;
+ u64 rnd;
if (unlikely(!evt->mult)) {
evt->mult = 1;
WARN_ON(1);
}
+ rnd = (u64) evt->mult - 1;
+
+ /*
+* Upper bound sanity check. If the backwards conversion is
+* not equal latch, we know that the above shift overflowed.
+*/
+ if ((clc >> evt->shift) != (u64)latch)
+ clc = ~0ULL;
+
+ /*
+* Scaled math oddities:
+*
+* For mult <= (1 << shift) we can safely add mult - 1 to
+* prevent integer rounding loss. So the backwards conversion
+* from nsec to device ticks will be correct.
+*
+* For mult > (1 << shift), i.e. device frequency is > 1GHz we
+* need to be careful. Adding mult - 1 will result in a value
+* which when converted back to device ticks can be larger
+* than latch by up to (mult - 1) >> shift. For the min_delta
+* calculation we still want to apply this in order to stay
+* above the minimum device ticks limit. For the upper limit
+* we would end up with a latch value larger than the upper
+* limit of the device, so we omit the add to stay below the
+* device upper boundary.
+*
+* Also omit the add if it would overflow the u64 boundary.
+*/
+ if ((~0ULL - clc > rnd) &&
+ (!ismax || evt->mult <= (1U << evt->shift)))
+ clc += rnd;
do_div(clc, evt->mult);
- if (clc < 1000)
- clc = 1000;
- if (clc > KTIME_MAX)
- clc = KTIME_MAX;
- return clc;
+ /* Deltas less than 1usec are pointless noise */
+ return clc > 1000 ? clc : 1000;
+}
+
+/**
+ * clockevents_delta2ns - Convert a latch value (device ticks) to nanoseconds
+ * @latch: value to convert
+ * @evt: pointer to clock event device descriptor
+ *
+ * Math helper, returns latch value converted to nanoseconds (bound checked)
+ */
+u64 clockevent_delta2ns(unsigned long latch, struct clock_event_device *evt)
+{
+ return cev_delta2ns(latch, evt, false);
}
EXPORT_SYMBOL_GPL(clockevent_delta2ns);
@@ -380,8 +415,8 @@ void clockevents_config(struct clock_event_device *dev, u32
freq)
sec = 600;
clockevents_calc_mult_shift(dev, freq, sec);
- dev->min_delta_ns = clockevent_delta2ns(dev->min_delta_ticks, dev);
- dev->max_delta_ns = clockevent_delta2ns(dev->max_delta_ticks, dev);
+ dev->min_delta_ns = cev_delta2ns(dev->min_delta_ticks, dev, false);
+ dev->max_delta_ns = cev_delta2ns(dev->max_delta_ticks, dev, true);
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol
On Fri, Oct 25, 2013 at 7:58 PM, Rusty Russell wrote: >> >> Basically these symbols are only used to generate code, and in >> kernel mode, CPU won't run into the corresponding addresses >> because the generate code is copied to other address during booting, >> so I understand they won't appear in backtraces. > > An oops occurs when something went *wrong*. We look up all kinds of > stuff. Are you so sure that *none* of the callers will ever see these > strange symbols and produce a confusing result? Suppose that might happen, kernel should be smart enough to know that the address is not inside kernel address space and won't produce confusing result, right? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: RFP: Fixing "-ga -ag -g fp -g dwarf" was Re: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v5)
On Sat, Oct 26, 2013 at 02:03:36PM +0200, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > > > Em Fri, Oct 25, 2013 at 01:22:27PM -0600, David Ahern escreveu: > > > On 10/25/13 1:09 PM, Arnaldo Carvalho de Melo wrote: > > > >>>I think I did with the second follow up patch: -ga -ag -g fp -g > > > >>>dwarf should all work properly with fp the default for -g. > > > > > >>Acked-by: Ingo Molnar > > > > > >Can I have this one submitted? > > > > > Upon further review, Jiri was correct: that patch handles some of > > > the old cases fine, but did not handle others. ie., it just moved > > > the bad syntax problem around. > > > > perhaps we can do, at least for now, with what Ingo suggested? > > > > Namely, having: > > > > --call-graph Require an argument, either "dwarf" or "fp" > > -g Doesn't require anything, uses whatever is configured, > >fp if no explicit config is done in places like > >~/.perfconfig > > > > Fits with what most people do usually, no? > > Please do this! Usability sucks right now, going from '-g' to > '-g ' was an incompatible change, a regression I argue, > which should be fixed in an urgent branch ASAP. about to finish patches with that, will send it soon jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] thermal: bcm281xx: Add Temperature Monitor driver
On Sat, Oct 26, 2013 at 01:47:40AM -0500, Kumar Gala wrote:
>
> On Oct 26, 2013, at 1:46 AM, Kumar Gala wrote:
>
> >
> > On Oct 25, 2013, at 7:00 PM, Wendy Ng wrote:
> >
> >> This adds the support for Temperature Monitor (TMON) driver for
> >> Broadcom bcm281xx SoCs. This driver plugs into the Thermal Framework.
> >>
> >> Note that this version of the TMON driver does support interrupt-driven
> >> mode -- only polling-mode of the thermal framework can be used.
> >>
> >> Signed-off-by: Wendy Ng
> >> Reviewed-by: Markus Mayer
> >> Reviewed-by: Christian Daudt
> >> Reviewed-by: Matt Porter
> >> Reviewed-by: Tim Kryger
> >> ---
> >> .../bindings/thermal/bcm-kona-thermal.txt | 24 +++
> >> drivers/thermal/Kconfig| 11 ++
> >> drivers/thermal/Makefile |1 +
> >> drivers/thermal/bcm_kona_tmon.c| 173
> >>
> >> 4 files changed, 209 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> >> create mode 100644 drivers/thermal/bcm_kona_tmon.c
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> >> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> >> new file mode 100644
> >> index 000..225b898
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> >> @@ -0,0 +1,24 @@
> >> +* Broadcom Kona TMON bindings
> >> +
> >> +This version is for the Kona family of SoCs. The TMON (Temperature
> >> Monitor)
> >> +block in a Kona SoC device is used to measure the chip temperature at
> >> constant
> >> +intervals.
> >> +The TMON block asserts an interrupt if temperature exceeds a user
> >> programmed
> >> +threshold value. The TMON block would reset the entire device once it
> >> +reaches a critical temperature which is also a programmable setting.
> >> +
> >> +Required properties:
> >> +- compatible : "brcm,bcm11351-tmon", "brcm,kona-tmon"
> >> +- reg : Address range of the thermal register
> >> +- clocks : the clock signal that drives the TMON block
> >> +- interrupts: the interrupt signal associated with the TMON block
> >> +
> >> +
> >> +Example:
> >> + tmon@34008000 {
> >> + compatible = "brcm,bcm11351-tmon", "brcm,kona-tmon";
> >> + reg = <0x34008000 0x0024>;
> >> + clocks = <&tmon_1m_clk>;
> >> + interrupts = ;
> >> + status = "disabled";
> >
> > I'd remove the 'status' line from an example.
> >
> >> + };
> >
> > Ack on the binding (beyond my minor nit pick on the status prop).
> >
> > Acked-by: Kumar Gala
> >
> > - k
>
>
> After looking at your .dts{i} I see you've got a #thermal-sensor-cells prop,
> where is that documented?
It's in Eduardo's "device thermal limits represented in device tree
nodes" series. Here's the direct link to the binding post/discussion
https://lkml.org/lkml/2013/9/26/772
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RIP: mem_cgroup_move_account+0xf4/0x290
On 10/26/2013 11:39 AM, Johannes Weiner wrote: On Fri, Oct 25, 2013 at 02:15:55PM -0200, Flavio Leitner wrote: While playing with guests and net-next kernel, I've triggered this with some frequency. Even Fedora 19 kernel reproduces. It it a known issue? Thanks, fbl [ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound [ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound [ 7535.654438] perf samples too long (2719 > 2500), lowering kernel.perf_event_max_sample_rate to 5 [ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 11.560 msecs [ 7691.048392] virbr0: port 1(vnet0) entered disabled state [ 7691.056281] device vnet0 left promiscuous mode [ 7691.061674] virbr0: port 1(vnet0) entered disabled state [ 7691.163363] BUG: unable to handle kernel paging request at 60fbc0002a20 [ 7691.171145] IP: [] mem_cgroup_move_account+0xf4/0x290 [ 7691.178574] PGD 0 [ 7691.181042] Oops: [#1] SMP [ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw coretemp kvm_intel snd_hda_codec_realtek snd_hda_intel nfsd snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc sunrpc snd_timer crc32c_intel i7core_edac bnx2 shpchp ptp snd iTCO_wdt joydev pps_core iTCO_vendor_support pcspkr soundcore microcode serio_raw lpc_ich edac_core mfd_core i2c_i801 acpi_cpufreq hid_logitech_dj nouveau ata_generic pata_acpi video i2c_algo_bit drm_kms_helper ttm drm mxm_wmi i2c_core pata_marvell wmi [last unloaded: openvswitch] [ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G I 3.12.0-rc6-01188-gb45bd46 #1 [ 7691.295779] Hardware name: /DX58SO, BIOS SOX5810J.86A.5599.2012.0529.2218 05/29/2012 [ 7691.306066] Workqueue: events css_killed_work_fn [ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: 88042957a000 [ 7691.319673] RIP: 0010:[] [] mem_cgroup_move_account+0xf4/0x290 [ 7691.329728] RSP: 0018:88042957bcc8 EFLAGS: 00010002 [ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: 0004 [ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: 880424cd622c [ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: 0001 [ 7691.359751] R10: 0001 R11: 0001 R12: ea00103ef0c0 [ 7691.367745] R13: 880424cd6000 R14: R15: 880424cd622c [ 7691.375738] FS: () GS:88043fc2() knlGS: [ 7691.384755] CS: 0010 DS: ES: CR0: 8005003b [ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: 27e0 [ 7691.399235] Stack: [ 7691.401672] 88042957bce8 88042957bce8 81312b6d 880424cd4000 [ 7691.409968] 88040001 880424cd6000 ea00103ef0c0 880424cd0430 [ 7691.418264] 88042b17bc30 ea00103ef0e0 880424cd6000 88042957bda8 [ 7691.426578] Call Trace: [ 7691.429513] [] ? list_del+0xd/0x30 [ 7691.435250] [] mem_cgroup_reparent_charges+0x247/0x460 [ 7691.442874] [] mem_cgroup_css_offline+0xaf/0x1b0 [ 7691.449942] [] offline_css+0x27/0x50 [ 7691.455874] [] css_killed_work_fn+0x2d/0xa0 [ 7691.462466] [] process_one_work+0x175/0x430 [ 7691.469041] [] worker_thread+0x11b/0x3a0 [ 7691.475345] [] ? rescuer_thread+0x340/0x340 [ 7691.481919] [] kthread+0xc0/0xd0 [ 7691.487478] [] ? insert_kthread_work+0x40/0x40 [ 7691.494352] [] ret_from_fork+0x7c/0xb0 [ 7691.500464] [] ? insert_kthread_work+0x40/0x40 [ 7691.507335] Code: 85 f6 48 8b 55 d0 44 8b 4d c8 4c 8b 45 c0 0f 85 b3 00 00 00 41 8b 4c 24 18 85 c9 0f 88 a6 00 00 00 48 8b b2 30 02 00 00 45 89 ca <4c> 39 56 18 0f 8c 36 01 00 00 44 89 c9 f7 d9 89 cf 65 48 01 7e This is All code 0: 85 f6 test %esi,%esi 2: 48 8b 55 d0 mov-0x30(%rbp),%rdx 6: 44 8b 4d c8 mov-0x38(%rbp),%r9d a: 4c 8b 45 c0 mov-0x40(%rbp),%r8 e: 0f 85 b3 00 00 00 jne0xc7 14: 41 8b 4c 24 18 mov0x18(%r12),%ecx 19: 85 c9 test %ecx,%ecx 1b: 0f 88 a6 00 00 00 js 0xc7 21: 48 8b b2 30 02 00 00mov0x230(%rdx),%rsi 28: 45 89 camov%r9d,%r10d 2b:* 4c 39 56 18 cmp%r10,0x18(%rsi) <-- trapping instruction 2f: 0f 8c 36 01 00 00 jl 0x16b 35: 44 89 c9mov%r9d,%ecx 38: f7 d9
Re: [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default
On 10/25/2013 06:53 PM, Ingo Molnar wrote:
* tianyu@intel.com wrote:
From: Lan Tianyu
Sony Vaio Z1 series require "reboot=pci" for reboot and power off.
This patch is to add them machines to quirk table and set pci reboot
default.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61721
Reported-and-tested-by: Adam Williamson
Signed-off-by: Lan Tianyu
---
arch/x86/kernel/reboot.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 7e920bf..083ade7 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -382,6 +382,14 @@ static struct dmi_system_id __initdata reboot_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
},
},
+ { /* Handle problems with rebooting on Sony Vaio Z1 series*/
+ .callback = set_pci_reboot,
+ .ident = "Sony Vaio Z1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VPCZ1"),
+ },
+ },
This is becoming somewhat endemic - do we know _why_ the ACPI reboot
method does not work?
We reworked the x86 reboot sequence 2.5 years agom, in:
commit 660e34cebf0a11d54f2d5dd8838607452355f321
Author: Matthew Garrett
Date: Mon Apr 4 13:55:05 2011 -0400
x86: Reorder reboot method preferences
We have a never ending stream of 'reboot quirks' for new boxes
that will not reboot properly under Linux (they will hang on
reboot).
The reason is widespread 'Windows compatible' assumption of modern
x86 hardware, which expects the following reboot sequence:
- hitting the ACPI reboot vector (if available)
- trying the keyboard controller
- hitting the ACPI reboot vector again
- then giving the keyboard controller one last go
This sequence expectation gets more and more embedded in modern
hardware, which often lacks a keyboard controller and may even
lock up if the legacy io ports are hit - and which hardware is
often not tested with Linux during development.
The end result is that reboot works under Windows-alike OSs but not
under Linux.
Rework our reboot process to meet this hardware externality a little
better and match this assumption of newer x86 hardware.
In addition to the ACPI,kbd,ACPI,kbd sequence we'll still fall
through to attempting a legacy triple fault if nothing else
works - and keep trying that and the kbd reset.
[...]
Do we know why reboot apparently works quickly enough on Windows on
this laptop, but not under Linux? Does Windows use the ACPI reboot
method? If yes, does it use a different pattern?
Is it all perhaps virtualization or IRQ routing related?
I.e. we really need a real analysis here, not just a quirk!
Sorry about this. Will do some analyses.
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: [PATCHv5 4/4] Documentation: Add device tree bindings for Freescale FTM PWM.
On Fri, Oct 25, 2013 at 09:12:11PM +0100, Grant Likely wrote:
> On Mon, 30 Sep 2013 14:13:31 +0800, Xiubo Li wrote:
> > This adds the Document for Freescale FTM PWM driver under
> > Documentation/devicetree/bindings/pwm/.
> >
> > Signed-off-by: Xiubo Li
> > ---
> > .../devicetree/bindings/pwm/pwm-fsl-ftm.txt| 33
> > ++
> > 1 file changed, 33 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> > new file mode 100644
> > index 000..2c6969a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> > @@ -0,0 +1,33 @@
> > +Freescale FTM PWM controller
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,vf610-ftm-pwm"
> > +- reg: Physical base address and length of the controller's registers
> > +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description
> > of
> > + the cells format.
> > +- clock-names : Includes the following module clock source entries:
> > +"ftm0" (system clock),
> > +"ftm0_fix_sel" (fixed frequency clock),
> > +"ftm0_ext_sel" (external clock)
> > +- clocks : Must contain a clock specifier for each entry in clock-names.
> > +- fsl,pwm-counter-clk: The FTM PWM counter clock source, should be one of
> > the
> > + entries in clock-names.
> > +- pinctrl-names: must contain a "default" entry.
> > +- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
> > + See ../pinctrl/pinctrl-bindings.txt for details of the property values.
>
> Looks okay to me.
For consistency, shouldn't it also have:
"See ../clock/clock-bindings.txt for details of the property values"
where appropriate like is done under the pwm/pinctrl uses?
IMHO, referencing parent bindings all of the time should be a documented
best practice / requirement.
-Matt
> > +
> > +
> > +Example:
> > +
> > +pwm0: pwm@40038000 {
> > + compatible = "fsl,vf610-ftm-pwm";
> > + reg = <0x40038000 0x1000>;
> > + #pwm-cells = <3>;
> > + clock-names = "ftm0", "ftm0_fix_sel", "ftm0_ext_sel";
> > + clocks = <&clks VF610_CLK_FTM0>,
> > + <&clks VF610_CLK_FTM0_FIX_SEL>,
> > + <&clks VF610_CLK_FTM0_EXT_SEL>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm0_1>;
> > + fsl,pwm-counter-clk = "ftm0_ext_sel";
> > +};
> > --
> > 1.8.0
> >
> >
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: N900 DT
On Saturday 26 October 2013 02:25:02 Sebastian Reichel wrote: > Hi Pali, > > On Fri, Oct 25, 2013 at 08:39:40PM +0200, Pali Rohár wrote: > > Now I found this patch and it looks like it will be in > > mainline kernel. And after that it could be simple to > > listen for needed events from isp driver in my bq driver > > (without touching isp). > > > > https://lkml.org/lkml/2013/7/25/204 > > > > Can you look at isp1704 driver for DT support? I think that > > only one gpio needs to be passed to driver from board data. > > I had a quick overview over Jenny's patchset [0] (the patch > you referenced is part of a bigger patchset). I don't think > the scenario found in the Nokia N900 is covered by it, but > probably now is the time to change it :) > > So for everybody new to this thread: > > Multiple chips are involved in the charging of the Nokia N900 > battery: > > bq27200: This chip is used for reading battery status. AFAIK >it's not directly involved in charging the battery. > bq24150a: This chip takes care of actually charging the > battery. It has no clue about USB related stuff. The maximum > current it draws can be configured, though. isp1704: USB > charger detector. This chip is used to detect how much > current may be used by the bq24150a chip. rx51-temp: Analog > temperature sensor for the battery, which is connected via an > analog-digital-converter. > > The question is how to connected these driver with each other > if device tree is used to boot the system. Any suggestions? > > [0] http://thread.gmane.org/gmane.linux.kernel/1377608 > > -- Sebastian What I need is receive property change event (from isp1704) in bq24150a. And with this patch https://lkml.org/lkml/2013/7/25/204 bq24150a driver can receive them and use only these which comes from driver specified in DT (on n900 from isp1704). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux-next: manual merge of the c6x tree
On Fri, Oct 25, 2013 at 03:03:39PM +0200, Thierry Reding wrote: > diff --cc arch/arm/Kconfig > index c06647d,7db8abe0..b6a708e > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@@ -5,7 -5,7 +5,8 @@@ config AR > select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST > select ARCH_HAVE_CUSTOM_GPIO_H > +select ARCH_USE_CMPXCHG_LOCKREF > + select ARCH_MIGHT_HAVE_PC_PARPORT > select ARCH_WANT_IPC_PARSE_VERSION Thanks. Generally we want these things to be arranged alphabetically to reduce the longer term chances of hitting merge conflicts, but in this case it wouldn't make any difference. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usbatm: printk_ratelimit() always called in the atm_rldbg()
Hi,
commit 2d6401cf4ca3861692a4779745e0049cac769d10
("USB: usbatm: move the atm_dbg() call to use dynamic debug")
changed the atm_rldbg() to:
#define atm_rldbg(instance, format, arg...) \
if (printk_ratelimit()) \
atm_dbg(instance , format , ## arg)
and now printk_ratelimit() is always called even when debugging is
disabled and a lot of "callbacks suppressed" messages are printed
by the printk_ratelimit():
[...]
usbatm_rx_process: 4977 callbacks suppressed
usbatm_extract_one_cell: 2920 callbacks suppressed
[...]
I'm not sure how to fix that, maybe we need dynamic_pr_debug_ratelimit()?
Krzysiek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Portable assmbler code - newline (was Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL())
On 10/25/2013 01:10 PM, Vineet Gupta wrote: > On 10/25/2013 01:11 AM, Geert Uytterhoeven wrote: >> On Thu, Oct 24, 2013 at 7:28 PM, Vineet Gupta wrote: +CC linux-arch On 10/24/2013 11:33 AM, Richard Weinberger wrote: >> On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang wrote: >> For some architectures, tool chain is not smart enough to recognize >> the >> macro with multiple lines (e.g. arc tool chain), and for common ".S" >> file, this kind of macro is also rarely used. >> Does not "not smart enough" mean than the said toolchain is broken/buggy >> or is the kernel using an unsupported notation? >> IMHO this is not broken - rather the code is not fully portable - given that gas ports of arches have differnet notions of what to treat as comment and what newline. Looking as binutils/gas/config, I can see that avr, cris,...are likely broken in the same way as ARC is. Historically ARC has had ';' as comment char, which Joern relatively recently augmented to have '#' as well. However there's legacy codebase which relies on ';' being a comment and we can't change that fact. So can we introduce an ARCH over-ridable newline annotation in linkage.h and other places after auditing. Since asm/linkage.h preempts linux/linkage.h by way of #include it shd be pretty strightforward. Something like below. I can send the formal patch if people think the approach is OK. >> By what are you gonna override __ARCH_NL on ARC? >> I'm afraid cpp will still turn it into a single line. >> > > Eh ! My untested patch was broken but not because of what you mentioned. > > For ARC, the ; negating the newline annotation. So the following works > (backquote > is new line for ARC) > > diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h > index 0283e9e44e0d..b3eea2999322 100644 > --- a/arch/arc/include/asm/linkage.h > +++ b/arch/arc/include/asm/linkage.h > @@ -9,6 +9,8 @@ > #ifndef __ASM_LINKAGE_H > #define __ASM_LINKAGE_H > > +#define __ARCH_NL ` > + > #ifdef __ASSEMBLY__ > > > diff --git a/include/linux/linkage.h b/include/linux/linkage.h > index d3e8ad23a8e0..969e70ad231a 100644 > --- a/include/linux/linkage.h > +++ b/include/linux/linkage.h > @@ -6,6 +6,10 @@ > #include > #include > > +#ifndef __ARCH_NL > +#define __ARCH_NL ; > +#endif > + > #ifdef __cplusplus > #define CPP_ASMLINKAGE extern "C" > #else > @@ -75,7 +79,7 @@ > > #ifndef ENTRY > #define ENTRY(name) \ > - .globl name; \ > + .globl name __ARCH_NL \ >ALIGN; \ Do we also need consider about "ALIGN;"? >name: > #endif > For next-20130927 tree, do we also need consider about WEAK, ENDPROC? I am not quite sure about it, but I will try. Now, I am just analyzing another issue -- maybe the last issue for allmodconfig under arc, which may be related with this patch, the errors are: 1 Building modules, stage 2. 2 MODPOST 2994 modules 3 ERROR: "__st_r13_to_r20" [sound/usb/snd-usbmidi-lib.ko] undefined! 4 ERROR: "__ld_r13_to_r15" [sound/usb/snd-usbmidi-lib.ko] undefined! 5 ERROR: "__st_r13_to_r18" [sound/usb/snd-usbmidi-lib.ko] undefined! 6 ERROR: "__ld_r13_to_r14_ret" [sound/usb/snd-usbmidi-lib.ko] undefined! 7 ERROR: "__ld_r13_to_r22" [sound/usb/snd-usbmidi-lib.ko] undefined! 8 ERROR: "__ld_r13_to_r15_ret" [sound/usb/snd-usbmidi-lib.ko] undefined! 9 ERROR: "__ld_r13_to_r16" [sound/usb/snd-usbmidi-lib.ko] undefined! 10 ERROR: "__ld_r13_to_r18_ret" [sound/usb/snd-usbmidi-lib.ko] undefined! 11 ERROR: "__ld_r13_to_r24_ret" [sound/usb/snd-usbmidi-lib.ko] undefined! ... ... 28095 ERROR: "__st_r13_to_r17" [arch/arc/oprofile/oprofile.ko] undefined! 28096 ERROR: "__st_r13_to_r22" [arch/arc/oprofile/oprofile.ko] undefined! 28097 ERROR: "__ld_r13_to_r19_ret" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined! 28098 ERROR: "__st_r13_to_r19" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined! 28099 ERROR: "__ld_r13_to_r14_ret" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined! 28100 ERROR: "__ld_r13_to_r19_ret" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined! 28101 ERROR: "__st_r13_to_r19" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined! 28102 ERROR: "__ld_r13_to_r14_ret" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined! 28103 ERROR: "__ld_r13_to_r14_ret" [Documentation/connector/cn_test.ko] undefined! 28104 make[1]: *** [__modpost] Error 1 28105 make: *** [modules] Error 2 Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.h
[tip:x86/asm] x86: Unify copy_to_user() and add size checking to it
Commit-ID: 7a3d9b0f3abbea957b829cdfff8169872c575642
Gitweb: http://git.kernel.org/tip/7a3d9b0f3abbea957b829cdfff8169872c575642
Author: Jan Beulich
AuthorDate: Mon, 21 Oct 2013 09:44:37 +0100
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 12:27:37 +0200
x86: Unify copy_to_user() and add size checking to it
Similarly to copy_from_user(), where the range check is to
protect against kernel memory corruption, copy_to_user() can
benefit from such checking too: Here it protects against kernel
information leaks.
Signed-off-by: Jan Beulich
Cc:
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/526505950278000fc...@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
Cc: Arjan van de Ven
---
arch/x86/include/asm/uaccess.h| 30 ++
arch/x86/include/asm/uaccess_32.h | 3 ---
arch/x86/include/asm/uaccess_64.h | 10 --
arch/x86/lib/usercopy_32.c| 5 ++---
4 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index c9799ed..8ec57c0 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -544,6 +544,8 @@ extern struct movsl_mask {
unsigned long __must_check _copy_from_user(void *to, const void __user *from,
unsigned n);
+unsigned long __must_check _copy_to_user(void __user *to, const void *from,
+unsigned n);
#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
# define copy_user_diag __compiletime_error
@@ -553,6 +555,8 @@ unsigned long __must_check _copy_from_user(void *to, const
void __user *from,
extern void copy_user_diag("copy_from_user() buffer size is too small")
copy_from_user_overflow(void);
+extern void copy_user_diag("copy_to_user() buffer size is too small")
+copy_to_user_overflow(void) __asm__("copy_from_user_overflow");
#undef copy_user_diag
@@ -563,6 +567,11 @@ __compiletime_warning("copy_from_user() buffer size is not
provably correct")
__copy_from_user_overflow(void) __asm__("copy_from_user_overflow");
#define __copy_from_user_overflow(size, count) __copy_from_user_overflow()
+extern void
+__compiletime_warning("copy_to_user() buffer size is not provably correct")
+__copy_to_user_overflow(void) __asm__("copy_from_user_overflow");
+#define __copy_to_user_overflow(size, count) __copy_to_user_overflow()
+
#else
static inline void
@@ -571,6 +580,8 @@ __copy_from_user_overflow(int size, unsigned long count)
WARN(1, "Buffer overflow detected (%d < %lu)!\n", size, count);
}
+#define __copy_to_user_overflow __copy_from_user_overflow
+
#endif
static inline unsigned long __must_check
@@ -608,7 +619,26 @@ copy_from_user(void *to, const void __user *from, unsigned
long n)
return n;
}
+static inline unsigned long __must_check
+copy_to_user(void __user *to, const void *from, unsigned long n)
+{
+ int sz = __compiletime_object_size(from);
+
+ might_fault();
+
+ /* See the comment in copy_from_user() above. */
+ if (likely(sz < 0 || sz >= n))
+ n = _copy_to_user(to, from, n);
+ else if(__builtin_constant_p(n))
+ copy_to_user_overflow();
+ else
+ __copy_to_user_overflow(sz, n);
+
+ return n;
+}
+
#undef __copy_from_user_overflow
+#undef __copy_to_user_overflow
#endif /* _ASM_X86_UACCESS_H */
diff --git a/arch/x86/include/asm/uaccess_32.h
b/arch/x86/include/asm/uaccess_32.h
index c348c87..3c03a5d 100644
--- a/arch/x86/include/asm/uaccess_32.h
+++ b/arch/x86/include/asm/uaccess_32.h
@@ -184,7 +184,4 @@ __copy_from_user_inatomic_nocache(void *to, const void
__user *from,
return __copy_from_user_ll_nocache_nozero(to, from, n);
}
-unsigned long __must_check copy_to_user(void __user *to,
- const void *from, unsigned long n);
-
#endif /* _ASM_X86_UACCESS_32_H */
diff --git a/arch/x86/include/asm/uaccess_64.h
b/arch/x86/include/asm/uaccess_64.h
index 4df93c4..0acae71 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -46,19 +46,9 @@ copy_user_generic(void *to, const void *from, unsigned len)
}
__must_check unsigned long
-_copy_to_user(void __user *to, const void *from, unsigned len);
-__must_check unsigned long
copy_in_user(void __user *to, const void __user *from, unsigned len);
static __always_inline __must_check
-int copy_to_user(void __user *dst, const void *src, unsigned size)
-{
- might_fault();
-
- return _copy_to_user(dst, src, size);
-}
-
-static __always_inline __must_check
int __copy_from_user(void *dst, const void __user *src, unsigned size)
{
int ret = 0;
diff --git a/arch/x86/lib/usercopy_32.c b/arch/x86/lib/usercopy_32.c
index c408d02..e2f5e21 100644
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -654,14 +654,13 @@ EXPORT_SYMBOL(__copy_from_user_ll_
[tip:x86/debug] x86/dumpstack: Fix printk_address for direct addresses
Commit-ID: 8d4c812a3e5fff476c8900bab19a6af489cbd4be
Gitweb: http://git.kernel.org/tip/8d4c812a3e5fff476c8900bab19a6af489cbd4be
Author: Jiri Slaby
AuthorDate: Fri, 25 Oct 2013 15:06:58 +0200
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 12:19:25 +0200
x86/dumpstack: Fix printk_address for direct addresses
Consider a kernel crash in a module, simulated the following way:
static int my_init(void)
{
char *map = (void *)0x5;
*map = 3;
return 0;
}
module_init(my_init);
When we turn off FRAME_POINTERs, the very first instruction in
that function causes a BUG. The problem is that we print IP in
the BUG report using %pB (from printk_address). And %pB
decrements the pointer by one to fix printing addresses of
functions with tail calls.
This was added in commit 71f9e59800e5ad4 ("x86, dumpstack: Use
%pB format specifier for stack trace") to fix the call stack
printouts.
So instead of correct output:
BUG: unable to handle kernel NULL pointer dereference at 0005
IP: [] my_init+0x0/0x10 [pb173]
We get:
BUG: unable to handle kernel NULL pointer dereference at 0005
IP: [] 0xa0151fff
To fix that, we use %pS only for stack addresses printouts (via
newly added printk_stack_address) and %pB for regs->ip (via
printk_address). I.e. we revert to the old behaviour for all
except call stacks. And since from all those reliable is 1, we
remove that parameter from printk_address.
Signed-off-by: Jiri Slaby
Cc: Namhyung Kim
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: j...@perches.com
Cc: jirisl...@gmail.com
Link: http://lkml.kernel.org/r/1382706418-8435-1-git-send-email-jsl...@suse.cz
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/kdebug.h | 2 +-
arch/x86/kernel/dumpstack.c | 11 ---
arch/x86/kernel/process_64.c | 2 +-
arch/x86/mm/fault.c | 2 +-
arch/x86/platform/uv/uv_nmi.c | 2 +-
5 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/kdebug.h b/arch/x86/include/asm/kdebug.h
index 2c37aad..32ce713 100644
--- a/arch/x86/include/asm/kdebug.h
+++ b/arch/x86/include/asm/kdebug.h
@@ -21,7 +21,7 @@ enum die_val {
DIE_NMIUNKNOWN,
};
-extern void printk_address(unsigned long address, int reliable);
+extern void printk_address(unsigned long address);
extern void die(const char *, struct pt_regs *,long);
extern int __must_check __die(const char *, struct pt_regs *, long);
extern void show_trace(struct task_struct *t, struct pt_regs *regs,
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index deb6421..d9c12d3 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -25,12 +25,17 @@ unsigned int code_bytes = 64;
int kstack_depth_to_print = 3 * STACKSLOTS_PER_LINE;
static int die_counter;
-void printk_address(unsigned long address, int reliable)
+static void printk_stack_address(unsigned long address, int reliable)
{
pr_cont(" [<%p>] %s%pB\n",
(void *)address, reliable ? "" : "? ", (void *)address);
}
+void printk_address(unsigned long address)
+{
+ pr_cont(" [<%p>] %pS\n", (void *)address, (void *)address);
+}
+
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
static void
print_ftrace_graph_addr(unsigned long addr, void *data,
@@ -151,7 +156,7 @@ static void print_trace_address(void *data, unsigned long
addr, int reliable)
{
touch_nmi_watchdog();
printk(data);
- printk_address(addr, reliable);
+ printk_stack_address(addr, reliable);
}
static const struct stacktrace_ops print_trace_ops = {
@@ -281,7 +286,7 @@ int __kprobes __die(const char *str, struct pt_regs *regs,
long err)
#else
/* Executive summary in case the oops scrolled away */
printk(KERN_ALERT "RIP ");
- printk_address(regs->ip, 1);
+ printk_address(regs->ip);
printk(" RSP <%016lx>\n", regs->sp);
#endif
return 0;
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index bb1dc51..8e9fe8d 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -63,7 +63,7 @@ void __show_regs(struct pt_regs *regs, int all)
unsigned int ds, cs, es;
printk(KERN_DEFAULT "RIP: %04lx:[<%016lx>] ", regs->cs & 0x,
regs->ip);
- printk_address(regs->ip, 1);
+ printk_address(regs->ip);
printk(KERN_DEFAULT "RSP: %04lx:%016lx EFLAGS: %08lx\n", regs->ss,
regs->sp, regs->flags);
printk(KERN_DEFAULT "RAX: %016lx RBX: %016lx RCX: %016lx\n",
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 3aaeffc..18feeb3 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -596,7 +596,7 @@ show_fault_oops(struct pt_regs *regs, unsigned long
error_code,
printk(KERN_CONT " at %p\n", (void *) address);
printk(KERN_ALERT "IP:");
- printk_address(regs->ip, 1);
+ printk_address(regs->ip);
dump_pagetable(address);
[tip:timers/core] x86/time: Honor ACPI FADT flag indicating absence of a CMOS RTC
Commit-ID: ee5872befc9324fa4c2583c24d7ee7120314a2b7
Gitweb: http://git.kernel.org/tip/ee5872befc9324fa4c2583c24d7ee7120314a2b7
Author: Jan Beulich
AuthorDate: Mon, 21 Oct 2013 09:31:57 +0100
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 13:36:00 +0200
x86/time: Honor ACPI FADT flag indicating absence of a CMOS RTC
Even though the omission was found only during code review
(originally in the Xen hypervisor, looking through ACPI v5 flags
and their meanings and uses), we shouldn't be creating a
corresponding platform device in that case.
Signed-off-by: Jan Beulich
Cc: John Stultz
Link: http://lkml.kernel.org/r/5265029d0278000fc...@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/rtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 0aa2939..5b9dd44 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -192,6 +192,14 @@ static __init int add_rtc_cmos(void)
if (mrst_identify_cpu())
return -ENODEV;
+#ifdef CONFIG_ACPI
+ if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ /* This warning can likely go away again in a year or two. */
+ pr_info("ACPI: not registering RTC platform device\n");
+ return -ENODEV;
+ }
+#endif
+
platform_device_register(&rtc_device);
dev_info(&rtc_device.dev,
"registered platform RTC device (no PNP device found)\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cpu] x86/cpu: Track legacy CPU model data only on 32-bit kernels
Commit-ID: 09dc68d958c67c76cf672ec78b7391af453010f8
Gitweb: http://git.kernel.org/tip/09dc68d958c67c76cf672ec78b7391af453010f8
Author: Jan Beulich
AuthorDate: Mon, 21 Oct 2013 09:35:20 +0100
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 13:34:39 +0200
x86/cpu: Track legacy CPU model data only on 32-bit kernels
struct cpu_dev's c_models is only ever set inside CONFIG_X86_32
conditionals (or code that's being built for 32-bit only), so
there's no use of reserving the (empty) space for the model
names in a 64-bit kernel.
Similarly, c_size_cache is only used in the #else of a
CONFIG_X86_64 conditional, so reserving space for (and in one
case even initializing) that field is pointless for 64-bit
kernels too.
While moving both fields to the end of the structure, I also
noticed that:
- the c_models array size was one too small, potentially causing
table_lookup_model() to return garbage on Intel CPUs (intel.c's
instance was lacking the sentinel with family being zero), so the
patch bumps that by one,
- c_models' vendor sub-field was unused (and anyway redundant
with the base structure's c_x86_vendor field), so the patch deletes it.
Also rename the legacy fields so that their legacy nature stands out
and comment their declarations.
Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/526503680278000fc...@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/amd.c | 6 +++---
arch/x86/kernel/cpu/centaur.c | 8 +---
arch/x86/kernel/cpu/common.c | 12 +++-
arch/x86/kernel/cpu/cpu.h | 20 +++-
arch/x86/kernel/cpu/intel.c | 12 ++--
arch/x86/kernel/cpu/umc.c | 4 ++--
6 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 903a264..3daece7 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -823,8 +823,8 @@ static const struct cpu_dev amd_cpu_dev = {
.c_vendor = "AMD",
.c_ident= { "AuthenticAMD" },
#ifdef CONFIG_X86_32
- .c_models = {
- { .vendor = X86_VENDOR_AMD, .family = 4, .model_names =
+ .legacy_models = {
+ { .family = 4, .model_names =
{
[3] = "486 DX/2",
[7] = "486 DX/2-WB",
@@ -835,7 +835,7 @@ static const struct cpu_dev amd_cpu_dev = {
}
},
},
- .c_size_cache = amd_size_cache,
+ .legacy_cache_size = amd_size_cache,
#endif
.c_early_init = early_init_amd,
.c_detect_tlb = cpu_detect_tlb_amd,
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index fbf6c3b..8d5652d 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -468,10 +468,10 @@ static void init_centaur(struct cpuinfo_x86 *c)
#endif
}
+#ifdef CONFIG_X86_32
static unsigned int
centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)
{
-#ifdef CONFIG_X86_32
/* VIA C3 CPUs (670-68F) need further shifting. */
if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
size >>= 8;
@@ -484,16 +484,18 @@ centaur_size_cache(struct cpuinfo_x86 *c, unsigned int
size)
if ((c->x86 == 6) && (c->x86_model == 9) &&
(c->x86_mask == 1) && (size == 65))
size -= 1;
-#endif
return size;
}
+#endif
static const struct cpu_dev centaur_cpu_dev = {
.c_vendor = "Centaur",
.c_ident= { "CentaurHauls" },
.c_early_init = early_init_centaur,
.c_init = init_centaur,
- .c_size_cache = centaur_size_cache,
+#ifdef CONFIG_X86_32
+ .legacy_cache_size = centaur_size_cache,
+#endif
.c_x86_vendor = X86_VENDOR_CENTAUR,
};
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2793d1f..9ada0b3 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -346,7 +346,8 @@ static void filter_cpuid_features(struct cpuinfo_x86 *c,
bool warn)
/* Look up CPU names by table lookup. */
static const char *table_lookup_model(struct cpuinfo_x86 *c)
{
- const struct cpu_model_info *info;
+#ifdef CONFIG_X86_32
+ const struct legacy_cpu_model_info *info;
if (c->x86_model >= 16)
return NULL;/* Range check */
@@ -354,13 +355,14 @@ static const char *table_lookup_model(struct cpuinfo_x86
*c)
if (!this_cpu)
return NULL;
- info = this_cpu->c_models;
+ info = this_cpu->legacy_models;
- while (info && info->family) {
+ while (info->family) {
if (info->family == c->x86)
return info->model_names[c->x86_model];
info++;
}
+#endif
return NULL;/* Not found */
}
@@ -450,8 +452,8 @@ void cpu_detect_cache_sizes(struct cpuinfo_x8
[tip:sched/core] sched/rt: Fix task_tick_rt() comment
Commit-ID: e9aa39bb7c4415ca26484239cc3a6686d549bf4f
Gitweb: http://git.kernel.org/tip/e9aa39bb7c4415ca26484239cc3a6686d549bf4f
Author: Li Bin
AuthorDate: Mon, 21 Oct 2013 20:15:43 +0800
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 12:25:21 +0200
sched/rt: Fix task_tick_rt() comment
This issue was introduced by 454c7f7e ("sched/rt: Fix SCHED_RR
across cgroups") that missed the word 'not'. Fix it.
Signed-off-by: Li Bin
Cc:
Cc:
Cc:
Link:
http://lkml.kernel.org/r/1382357743-54136-1-git-send-email-huawei.li...@huawei.com
Signed-off-by: Ingo Molnar
---
kernel/sched/rt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index a848f52..7d57275 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1935,8 +1935,8 @@ static void task_tick_rt(struct rq *rq, struct
task_struct *p, int queued)
p->rt.time_slice = sched_rr_timeslice;
/*
-* Requeue to the end of queue if we (and all of our ancestors) are the
-* only element on the queue
+* Requeue to the end of queue if we (and all of our ancestors) are not
+* the only element on the queue
*/
for_each_sched_rt_entity(rt_se) {
if (rt_se->run_list.prev != rt_se->run_list.next) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86: Unify copy_from_user() size checking
Commit-ID: 3df7b41aa5e7797f391d0a41f8b0dce1fe366a09
Gitweb: http://git.kernel.org/tip/3df7b41aa5e7797f391d0a41f8b0dce1fe366a09
Author: Jan Beulich
AuthorDate: Mon, 21 Oct 2013 09:43:57 +0100
Committer: Ingo Molnar
CommitDate: Sat, 26 Oct 2013 12:27:36 +0200
x86: Unify copy_from_user() size checking
Commits 4a3127693001c61a21d1ce680db6340623f52e93 ("x86: Turn the
copy_from_user check into an (optional) compile time warning")
and 63312b6a6faae3f2e5577f2b001e3b504f10a2aa ("x86: Add a
Kconfig option to turn the copy_from_user warnings into errors")
touched only the 32-bit variant of copy_from_user(), whereas the
original commit 9f0cf4adb6aa0bfccf675c938124e68f7f06349d ("x86:
Use __builtin_object_size() to validate the buffer size for
copy_from_user()") also added the same code to the 64-bit one.
Further the earlier conversion from an inline WARN() to the call
to copy_from_user_overflow() went a little too far: When the
number of bytes to be copied is not a constant (e.g. [looking at
3.11] in drivers/net/tun.c:__tun_chr_ioctl() or
drivers/pci/pcie/aer/aer_inject.c:aer_inject_write()), the
compiler will always have to keep the funtion call, and hence
there will always be a warning. By using __builtin_constant_p()
we can avoid this.
And then this slightly extends the effect of
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS in that apart from
converting warnings to errors in the constant size case, it
retains the (possibly wrong) warnings in the non-constant size
case, such that if someone is prepared to get a few false
positives, (s)he'll be able to recover the current behavior
(except that these diagnostics now will never be converted to
errors).
Since the 32-bit variant (intentionally) didn't call
might_fault(), the unification results in this being called
twice now. Adding a suitable #ifdef would be the alternative if
that's a problem.
I'd like to point out though that with
__compiletime_object_size() being restricted to gcc before 4.6,
the whole construct is going to become more and more pointless
going forward. I would question however that commit
2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a2 ("gcc4: disable
__compiletime_object_size for GCC 4.6+") was really necessary,
and instead this should have been dealt with as is done here
from the beginning.
Signed-off-by: Jan Beulich
Cc: Arjan van de Ven
Cc: Guenter Roeck
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/5265056d0278000fc...@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uaccess.h| 68 +++
arch/x86/include/asm/uaccess_32.h | 26 ---
arch/x86/include/asm/uaccess_64.h | 18 ---
arch/x86/lib/usercopy_32.c| 3 +-
4 files changed, 69 insertions(+), 46 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 5838fa9..c9799ed 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -542,5 +542,73 @@ extern struct movsl_mask {
# include
#endif
+unsigned long __must_check _copy_from_user(void *to, const void __user *from,
+ unsigned n);
+
+#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
+# define copy_user_diag __compiletime_error
+#else
+# define copy_user_diag __compiletime_warning
+#endif
+
+extern void copy_user_diag("copy_from_user() buffer size is too small")
+copy_from_user_overflow(void);
+
+#undef copy_user_diag
+
+#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
+
+extern void
+__compiletime_warning("copy_from_user() buffer size is not provably correct")
+__copy_from_user_overflow(void) __asm__("copy_from_user_overflow");
+#define __copy_from_user_overflow(size, count) __copy_from_user_overflow()
+
+#else
+
+static inline void
+__copy_from_user_overflow(int size, unsigned long count)
+{
+ WARN(1, "Buffer overflow detected (%d < %lu)!\n", size, count);
+}
+
+#endif
+
+static inline unsigned long __must_check
+copy_from_user(void *to, const void __user *from, unsigned long n)
+{
+ int sz = __compiletime_object_size(to);
+
+ might_fault();
+
+ /*
+* While we would like to have the compiler do the checking for us
+* even in the non-constant size case, any false positives there are
+* a problem (especially when DEBUG_STRICT_USER_COPY_CHECKS, but even
+* without - the [hopefully] dangerous looking nature of the warning
+* would make people go look at the respecitive call sites over and
+* over again just to find that there's no problem).
+*
+* And there are cases where it's just not realistic for the compiler
+* to prove the count to be in range. For example when multiple call
+* sites of a helper function - perhaps in different source files -
+* all doing proper range checking, yet the helper function not doing
+* so again.
+*
+* Therefore limit the com
Re: [PATCH] LSM: ModPin LSM for module loading restrictions
Tetsuo Handa wrote: > I would send another one which uses only security_file_alloc/free . I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and waiting for your response. How long are we expected to remain vulnerable due to lack of multiple concurrent LSM support? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:core/locking] x86/locking/kconfig: Update paravirt spinlock Kconfig description
Commit-ID: 4c4e4f61368164f326fe59e2156c70d7faa72c17 Gitweb: http://git.kernel.org/tip/4c4e4f61368164f326fe59e2156c70d7faa72c17 Author: Raghavendra K T AuthorDate: Mon, 21 Oct 2013 21:35:08 +0530 Committer: Ingo Molnar CommitDate: Sat, 26 Oct 2013 12:23:22 +0200 x86/locking/kconfig: Update paravirt spinlock Kconfig description Since the paravirt spinlock optimizations went into the v3.12 kernel we have a very good performance benefit for paravirtualized KVM / Xen kernels. Also we no longer suffer from 5% side effect on native kernel that is mentioned in the Kconfig entry. So update the Kconfig entry accordingly. pvspinlock benefit on KVM link: https://lkml.org/lkml/2013/8/6/178 Attilio's tests on native kernel impact: http://blog.xen.org/index.php/2012/05/11/benchmarking-the-new-pv-ticketlock-implementation/ Signed-off-by: Raghavendra K T Cc: Cc: Cc: Cc: Cc: Linus Torvalds Cc: Andrew Morton Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1382371508-3843-1-git-send-email-raghavendra...@linux.vnet.ibm.com [ Updated the changelog. ] Signed-off-by: Ingo Molnar --- arch/x86/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ee2fb9d..a92572d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -638,10 +638,10 @@ config PARAVIRT_SPINLOCKS spinlock implementation with something virtualization-friendly (for example, block the virtual CPU rather than spinning). - Unfortunately the downside is an up to 5% performance hit on - native kernels, with various workloads. + It has a minimal impact on native kernels and gives a nice performance + benefit on paravirtualized KVM / Xen kernels. - If you are unsure how to answer this question, answer N. + If you are unsure how to answer this question, answer Y. source "arch/x86/xen/Kconfig" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Run checksumming in parallel accross multiple alu's
On Sat, Oct 26, 2013 at 02:01:08PM +0200, Ingo Molnar wrote: > > * Neil Horman wrote: > > > On Mon, Oct 21, 2013 at 12:44:05PM -0700, Eric Dumazet wrote: > > > On Mon, 2013-10-21 at 15:21 -0400, Neil Horman wrote: > > > > > > > > > > > Ok, so I ran the above code on a single cpu using taskset, and set irq > > > > affinity > > > > such that no interrupts (save for local ones), would occur on that cpu. > > > > Note > > > > that I had to convert csum_partial_opt to csum_partial, as the _opt > > > > variant > > > > doesn't exist in my tree, nor do I see it in any upstream tree or in > > > > the history > > > > anywhere. > > > > > > This csum_partial_opt() was a private implementation of csum_partial() > > > so that I could load the module without rebooting the kernel ;) > > > > > > > > > > > base results: > > > > 53569916 > > > > 43506025 > > > > 43476542 > > > > 44048436 > > > > 45048042 > > > > 48550429 > > > > 53925556 > > > > 53927374 > > > > 53489708 > > > > 53003915 > > > > > > > > AVG = 492 ns > > > > > > > > prefetching only: > > > > 53279213 > > > > 45518140 > > > > 49585388 > > > > 53176179 > > > > 44071822 > > > > 43588822 > > > > 44086546 > > > > 47507065 > > > > 53646812 > > > > 54469118 > > > > > > > > AVG = 488 ns > > > > > > > > > > > > parallel alu's only: > > > > 46226844 > > > > 44458101 > > > > 46803498 > > > > 45060002 > > > > 46187624 > > > > 37542946 > > > > 45632866 > > > > 46275249 > > > > 45031141 > > > > 46281204 > > > > > > > > AVG = 449 ns > > > > > > > > > > > > both optimizations: > > > > 45708837 > > > > 45631124 > > > > 45697135 > > > > 45647011 > > > > 45036679 > > > > 39418544 > > > > 44481577 > > > > 46820868 > > > > 44496471 > > > > 35523928 > > > > > > > > AVG = 438 ns > > > > > > > > > > > > We continue to see a small savings in execution time with prefetching > > > > (4 ns, or > > > > about 0.8%), a better savings with parallel alu execution (43 ns, or > > > > 8.7%), and > > > > the best savings with both optimizations (54 ns, or 10.9%). > > > > > > > > These results, while they've changed as we've modified the test case > > > > slightly > > > > have remained consistent in their sppedup ordinality. Prefetching > > > > helps, but > > > > not as much as using multiple alu's, and neither is as good as doing > > > > both > > > > together. > > > > > > > > Unless you see something else that I'm doing wrong here. It seems like > > > > a win to > > > > do both. > > > > > > > > > > Well, I only said (or maybe I forgot), that on my machines, I got no > > > improvements at all with the multiple alu or the prefetch. (I tried > > > different strides) > > > > > > Only noises in the results. > > > > > I thought you previously said that running netperf gave you a stastically > > significant performance boost when you added prefetching: > > http://marc.info/?l=linux-kernel&m=138178914124863&w=2 > > > > But perhaps I missed a note somewhere. > > > > > It seems it depends on cpus and/or multiple factors. > > > > > > Last machine I used for the tests had : > > > > > > processor : 23 > > > vendor_id : GenuineIntel > > > cpu family: 6 > > > model : 44 > > > model name: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz > > > stepping : 2 > > > microcode : 0x13 > > > cpu MHz : 2800.256 > > > cache size: 12288 KB > > > physical id : 1 > > > siblings : 12 > > > core id : 10 > > > cpu cores : 6 > > > > > > > > > > > > > > > > Thats about what I'm running with: > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 44 > > model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz > > stepping: 2 > > microcode : 0x13 > > cpu MHz : 1600.000 > > cache size : 12288 KB > > physical id : 0 > > siblings: 8 > > core id : 0 > > cpu cores : 4 > > > > > > I can't imagine what would cause the discrepancy in our results (a > > 10% savings in execution time seems significant to me). My only > > thought would be that possibly the alu's on your cpu are faster > > than mine, and reduce the speedup obtained by preforming operation > > in parallel, though I can't imagine thats the case with these > > processors being so closely matched. > > You keep ignoring my request to calculate and account for noise of > the measurement. > Don't confuse "ignoring" with "haven't gotten there yet". Sometimes we all have to wait, Ingo. I'm working on it now, but I hit a snag on the machine I'm working with and am trying to figure it out now. > For example you are talking about a 0.8% prefetch effect while the > noise in the results is obviously much larger than that, with a > min/max distance of around 5%: > > > > > 43476542 > > > > 53927374 > > so the noise of 10 measurements would be around 5-10%. (back of the > envelope calculation) > > So you might be right in the end, but the posted data does
Re: linux-next: manual merge of the tip tree
Hi Ingo, [adding rmk] On Sat, Oct 26, 2013 at 09:40:33AM +0100, Ingo Molnar wrote: > * Will Deacon wrote: > > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote: > > > I fixed it up (see below). Please verify that the resolution looks good. > > > Also note that this isn't really a trivial resolution of a conflict, but > > > required modifying various other files. That causes rerere magic not to > > > work and needs part of conflict to be resolved manually. Perhaps a good > > > idea would be to rebase Jean's patch on top of the cleanups going on in > > > the tip tree? Perhaps even carry the patch in the tip tree? > > > > These came via my tree (arm perf) after discussion here: > > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html > > > > Now that they've been pulled by rmk, we can't back them out with > > ugly reverts, so I'm not sure what we can do to resolve in the ARM > > tree; it looks like the perf Makefile has changed significantly in > > -tip. > > I realize that it was acked by Arnaldo, but for workflow reasons I'd > really prefer it if non-trivial perf tooling patches went to Arnaldo > as a pull request so that he can resolve any such conflicts. perf is > in constant development so it's less work for you that way. Sure. I wasn't aware quite how much you guys had planned for the perf Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an indication that conflicts would be unlikely and/or trivial. In future, I'll push back on any perf changes outside of arch/ in my tree, but that doesn't help us get out of the current situation: the patches are currently sitting in rmk's tree for 3.13, so that won't meet with -tip (outside of next) until Linus pulls them both. What can we do about that? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] extcon: arizona: Fix reset of HPDET after race with removal
We need to make sure we reset back to our starting state, especially
making sure that we have disabled poll in the register cache.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 92eb486..3ce7b49 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -572,6 +572,14 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
goto out;
} else if (!ret) {
dev_dbg(arizona->dev, "Ignoring HPDET for removed cable\n");
+
+ /* Reset back to starting range */
+ regmap_update_bits(arizona->regmap,
+ ARIZONA_HEADPHONE_DETECT_1,
+ ARIZONA_HP_IMPEDANCE_RANGE_MASK |
+ ARIZONA_HP_POLL,
+ 0);
+
goto done;
}
@@ -607,9 +615,9 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
dev_err(arizona->dev, "Failed to report HP/line: %d\n",
ret);
+done:
arizona_extcon_do_magic(info, 0);
-done:
if (id_gpio)
gpio_set_value_cansleep(id_gpio, 0);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] extcon: arizona: Add defines for microphone detection levels
Improve readability by creating a define for each microphone detection
level.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c | 21 -
include/linux/mfd/arizona/registers.h |9 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index ec9a14e..92eb486 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -44,6 +44,17 @@
#define HPDET_DEBOUNCE 500
#define DEFAULT_MICD_TIMEOUT 2000
+enum {
+ MICD_LVL_1_TO_7 = ARIZONA_MICD_LVL_1 | ARIZONA_MICD_LVL_2 |
+ ARIZONA_MICD_LVL_3 | ARIZONA_MICD_LVL_4 |
+ ARIZONA_MICD_LVL_5 | ARIZONA_MICD_LVL_6 |
+ ARIZONA_MICD_LVL_7,
+
+ MICD_LVL_0_TO_7 = ARIZONA_MICD_LVL_0 | MICD_LVL_1_TO_7,
+
+ MICD_LVL_0_TO_8 = MICD_LVL_0_TO_7 | ARIZONA_MICD_LVL_8,
+};
+
struct arizona_extcon_info {
struct device *dev;
struct arizona *arizona;
@@ -767,7 +778,7 @@ static void arizona_micd_detect(struct work_struct *work)
mutex_lock(&info->lock);
- for (i = 0; i < 10 && !(val & 0x7fc); i++) {
+ for (i = 0; i < 10 && !(val & MICD_LVL_0_TO_8); i++) {
ret = regmap_read(arizona->regmap, ARIZONA_MIC_DETECT_3, &val);
if (ret != 0) {
dev_err(arizona->dev, "Failed to read MICDET: %d\n",
ret);
@@ -784,7 +795,7 @@ static void arizona_micd_detect(struct work_struct *work)
}
}
- if (i == 10 && !(val & 0x7fc)) {
+ if (i == 10 && !(val & MICD_LVL_0_TO_8)) {
dev_err(arizona->dev, "Failed to get valid MICDET value\n");
mutex_unlock(&info->lock);
return;
@@ -798,7 +809,7 @@ static void arizona_micd_detect(struct work_struct *work)
}
/* If we got a high impedence we should have a headset, report it. */
- if (info->detecting && (val & 0x400)) {
+ if (info->detecting && (val & ARIZONA_MICD_LVL_8)) {
arizona_identify_headphone(info);
ret = extcon_update_state(&info->edev,
@@ -827,7 +838,7 @@ static void arizona_micd_detect(struct work_struct *work)
* plain headphones. If both polarities report a low
* impedence then give up and report headphones.
*/
- if (info->detecting && (val & 0x3f8)) {
+ if (info->detecting && (val & MICD_LVL_1_TO_7)) {
if (info->jack_flips >= info->micd_num_modes * 10) {
dev_dbg(arizona->dev, "Detected HP/line\n");
arizona_identify_headphone(info);
@@ -851,7 +862,7 @@ static void arizona_micd_detect(struct work_struct *work)
* If we're still detecting and we detect a short then we've
* got a headphone. Otherwise it's a button press.
*/
- if (val & 0x3fc) {
+ if (val & MICD_LVL_0_TO_7) {
if (info->mic) {
dev_dbg(arizona->dev, "Mic button detected\n");
diff --git a/include/linux/mfd/arizona/registers.h
b/include/linux/mfd/arizona/registers.h
index 4706d3d..10d9e70 100644
--- a/include/linux/mfd/arizona/registers.h
+++ b/include/linux/mfd/arizona/registers.h
@@ -2196,6 +2196,15 @@
/*
* R677 (0x2A5) - Mic Detect 3
*/
+#define ARIZONA_MICD_LVL_0 0x0004 /* MICD_LVL - [2] */
+#define ARIZONA_MICD_LVL_1 0x0008 /* MICD_LVL - [3] */
+#define ARIZONA_MICD_LVL_2 0x0010 /* MICD_LVL - [4] */
+#define ARIZONA_MICD_LVL_3 0x0020 /* MICD_LVL - [5] */
+#define ARIZONA_MICD_LVL_4 0x0040 /* MICD_LVL - [6] */
+#define ARIZONA_MICD_LVL_5 0x0080 /* MICD_LVL - [7] */
+#define ARIZONA_MICD_LVL_6 0x0100 /* MICD_LVL - [8] */
+#define ARIZONA_MICD_LVL_7 0x0200 /* MICD_LVL - [9] */
+#define ARIZONA_MICD_LVL_8 0x0400 /* MICD_LVL - [10] */
#define ARIZONA_MICD_LVL_MASK0x07FC /* MICD_LVL - [10:2]
*/
#define ARIZONA_MICD_LVL_SHIFT2 /* MICD_LVL - [10:2]
*/
#define ARIZONA_MICD_LVL_WIDTH9 /* MICD_LVL - [10:2]
*/
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] perf tools: Split -g and --call-graph for record command
Splitting -g and --call-graph for record command, so we could
use '-g' with no option.
The '-g' option now takes NO argument and enables the configured
unwind method, which is currently the frame pointers method.
It will be possible to configure unwind method via config
file in upcoming patches.
All current '-g' arguments is overtaken by --call-graph option.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/Documentation/perf-record.txt | 6 ++-
tools/perf/builtin-record.c | 71 ++--
tools/perf/util/callchain.h | 3 ++
3 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index f10ab63..7be62770 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -92,8 +92,12 @@ OPTIONS
size is rounded up to have nearest pages power of two value.
-g::
+ Enables call-graph (stack chain/backtrace) recording.
+
--call-graph::
- Do call-graph (stack chain/backtrace) recording.
+ Setup and enable call-graph (stack chain/backtrace) recording,
+ implies -g.
+
-q::
--quiet::
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ab8d15e..27622bb 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -678,21 +678,12 @@ static int get_stack_size(char *str, unsigned long *_size)
}
#endif /* HAVE_LIBUNWIND_SUPPORT */
-int record_parse_callchain_opt(const struct option *opt,
- const char *arg, int unset)
+int record_parse_callchain(const char *arg, struct perf_record_opts *opts)
{
- struct perf_record_opts *opts = opt->value;
char *tok, *name, *saveptr = NULL;
char *buf;
int ret = -1;
- /* --no-call-graph */
- if (unset)
- return 0;
-
- /* We specified default option if none is provided. */
- BUG_ON(!arg);
-
/* We need buffer that we know we can write to. */
buf = malloc(strlen(arg) + 1);
if (!buf)
@@ -730,10 +721,6 @@ int record_parse_callchain_opt(const struct option *opt,
ret = get_stack_size(tok, &size);
opts->stack_dump_size = size;
}
-
- if (!ret)
- pr_debug("callchain: stack dump size %d\n",
-opts->stack_dump_size);
#endif /* HAVE_LIBUNWIND_SUPPORT */
} else {
pr_err("callchain: Unknown -g option "
@@ -744,13 +731,52 @@ int record_parse_callchain_opt(const struct option *opt,
} while (0);
free(buf);
+ return ret;
+}
+
+static void callchain_debug(struct perf_record_opts *opts)
+{
+ pr_debug("callchain: type %d\n", opts->call_graph);
+ if (opts->call_graph == CALLCHAIN_DWARF)
+ pr_debug("callchain: stack dump size %d\n",
+opts->stack_dump_size);
+}
+
+int record_parse_callchain_opt(const struct option *opt,
+ const char *arg,
+ int unset)
+{
+ struct perf_record_opts *opts = opt->value;
+ int ret;
+
+ /* --no-call-graph */
+ if (unset) {
+ opts->call_graph = CALLCHAIN_NONE;
+ pr_debug("callchain: disabled\n");
+ return 0;
+ }
+
+ ret = record_parse_callchain(arg, opts);
if (!ret)
- pr_debug("callchain: type %d\n", opts->call_graph);
+ callchain_debug(opts);
return ret;
}
+int record_callchain_opt(const struct option *opt,
+const char *arg __maybe_unused,
+int unset __maybe_unused)
+{
+ struct perf_record_opts *opts = opt->value;
+
+ if (opts->call_graph == CALLCHAIN_NONE)
+ opts->call_graph = CALLCHAIN_FP;
+
+ callchain_debug(opts);
+ return 0;
+}
+
static const char * const record_usage[] = {
"perf record [] []",
"perf record [] -- []",
@@ -779,12 +805,12 @@ static struct perf_record record = {
},
};
-#define CALLCHAIN_HELP "do call-graph (stack chain/backtrace) recording: "
+#define CALLCHAIN_HELP "setup and enables call-graph (stack chain/backtrace)
recording: "
#ifdef HAVE_LIBUNWIND_SUPPORT
-const char record_callchain_help[] = CALLCHAIN_HELP "[fp] dwarf";
+const char record_callchain_help[] = CALLCHAIN_HELP "fp dwarf";
#else
-const char record_callchain_help[] = CALLCHAIN_HELP "[fp]";
+const char record_callchain_help[] = CALLCHAIN_HELP "fp";
#endif
/*
@@ -825,9 +851,12 @@ const struct option record_options[] = {
perf_evlist__parse_
[PATCH 4/4] perf tools: Add readable output for callchain debug
Adding people readable output for callchain debug,
to get following '-v' output:
$ perf record -v -g ls
callchain: type DWARF
callchain: stack dump size 4096
...
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/builtin-record.c | 4 +++-
tools/perf/perf.h | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f597b9b..8bdd608 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -736,7 +736,9 @@ int record_parse_callchain(const char *arg, struct
perf_record_opts *opts)
static void callchain_debug(struct perf_record_opts *opts)
{
- pr_debug("callchain: type %d\n", opts->call_graph);
+ static const char *str[CALLCHAIN_MAX] = { "NONE", "FP", "DWARF" };
+
+ pr_debug("callchain: type %s\n", str[opts->call_graph]);
if (opts->call_graph == CALLCHAIN_DWARF)
pr_debug("callchain: stack dump size %d\n",
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index c4ed633..e84aeeb 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -209,7 +209,8 @@ void pthread__unblock_sigwinch(void);
enum perf_call_graph_mode {
CALLCHAIN_NONE,
CALLCHAIN_FP,
- CALLCHAIN_DWARF
+ CALLCHAIN_DWARF,
+ CALLCHAIN_MAX
};
struct perf_record_opts {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] perf tools: Fix -g option handling
hi, changing the '-g/-G' options for record/top commands to take NO argument and enable unwind method based on .perfconfig setup (using FP by default). The current -g option parsing moves into the '--call-graph' option. Examples: $ cat ~/.perfconfig: [top] call-graph = fp [record] call-graph = dwarf,8192 $ perf record -g ls - enables dwarf unwind with user stack size dump 8192 bytes $ perf top -G - enables frame pointer unwind $ perf record --call-graph=fp ls - enables frame pointer unwind $ perf top --call-graph=dwarf,4096 ls - enables dwarf unwind with user stack size dump 4096 bytes thanks, jirka Cc: Corey Ashford Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Andi Kleen Cc: Adrian Hunter --- Jiri Olsa (4): perf tools: Split -g and --call-graph for record command perf tools: Split -G and --call-graph for top command perf tools: Add call-graph option support into .perfconfig perf tools: Add readable output for callchain debug tools/perf/Documentation/perf-record.txt | 6 +- tools/perf/Documentation/perf-top.txt| 18 +- tools/perf/builtin-record.c | 89 - tools/perf/builtin-top.c | 35 +-- tools/perf/perf.h| 4 +++- tools/perf/util/callchain.h | 3 +++ tools/perf/util/evsel.c | 2 +- 7 files changed, 110 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] perf tools: Add call-graph option support into .perfconfig
Adding call-graph option support into .perfconfig file,
so it's now possible use call-graph option like:
[top]
call-graph = fp
[record]
call-graph = dwarf,8192
Above options ONLY setup the unwind method. To enable
perf record/top to actually use it the command line
option -g/-G must be specified.
The --call-graph option overloads .perfconfig setup.
Assuming above configuration:
$ perf record -g ls
- enables dwarf unwind with user stack size dump 8192 bytes
$ perf top -G
- enables frame pointer unwind
$ perf record --call-graph=fp ls
- enables frame pointer unwind
$ perf top --call-graph=dwarf,4096 ls
- enables dwarf unwind with user stack size dump 4096 bytes
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/builtin-record.c | 16
tools/perf/builtin-top.c| 12
tools/perf/perf.h | 1 +
tools/perf/util/evsel.c | 2 +-
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 27622bb..f597b9b 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -750,6 +750,8 @@ int record_parse_callchain_opt(const struct option *opt,
struct perf_record_opts *opts = opt->value;
int ret;
+ opts->call_graph_enabled = !unset;
+
/* --no-call-graph */
if (unset) {
opts->call_graph = CALLCHAIN_NONE;
@@ -770,6 +772,8 @@ int record_callchain_opt(const struct option *opt,
{
struct perf_record_opts *opts = opt->value;
+ opts->call_graph_enabled = !unset;
+
if (opts->call_graph == CALLCHAIN_NONE)
opts->call_graph = CALLCHAIN_FP;
@@ -777,6 +781,16 @@ int record_callchain_opt(const struct option *opt,
return 0;
}
+static int perf_record_config(const char *var, const char *value, void *cb)
+{
+ struct perf_record *rec = cb;
+
+ if (!strcmp(var, "record.call-graph"))
+ return record_parse_callchain(value, &rec->opts);
+
+ return perf_default_config(var, value, cb);
+}
+
static const char * const record_usage[] = {
"perf record [] []",
"perf record [] -- []",
@@ -905,6 +919,8 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
rec->evlist = evsel_list;
+ perf_config(perf_record_config, rec);
+
argc = parse_options(argc, argv, record_options, record_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
if (!argc && perf_target__none(&rec->opts.target))
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 488fec3..b326f61 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1028,6 +1028,16 @@ parse_callchain_opt(const struct option *opt, const char
*arg, int unset)
return record_parse_callchain_opt(opt, arg, unset);
}
+static int perf_top_config(const char *var, const char *value, void *cb)
+{
+ struct perf_top *top = cb;
+
+ if (!strcmp(var, "top.call-graph"))
+ return record_parse_callchain(value, &top->record_opts);
+
+ return perf_default_config(var, value, cb);
+}
+
static int
parse_percent_limit(const struct option *opt, const char *arg,
int unset __maybe_unused)
@@ -1152,6 +1162,8 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
if (top.evlist == NULL)
return -ENOMEM;
+ perf_config(perf_top_config, &top);
+
argc = parse_options(argc, argv, options, top_usage, 0);
if (argc)
usage_with_options(top_usage, options);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index f61c230..c4ed633 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -215,6 +215,7 @@ enum perf_call_graph_mode {
struct perf_record_opts {
struct perf_target target;
int call_graph;
+ bool call_graph_enabled;
bool group;
bool inherit_stat;
bool no_delay;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index ec0cc1e..f1ed2ad 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -633,7 +633,7 @@ void perf_evsel__config(struct perf_evsel *evsel,
attr->mmap_data = track;
}
- if (opts->call_graph) {
+ if (opts->call_graph_enabled) {
perf_evsel__set_sample_bit(evsel, CALLCHAIN);
if (opts->call_graph == CALLCHAIN_DWARF) {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] perf tools: Split -G and --call-graph for top command
Splitting -G and --call-graph for record command, so we could
use '-G' with no option.
The '-G' option now takes NO argument and enables the configured
unwind method, which is currently the frame pointers method.
It will be possible to configure unwind method via config
file in upcoming patches.
All current '-G' arguments is overtaken by --call-graph option.
NOTE The documentation for top --call-graph option
was wrongly copied from report command.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/Documentation/perf-top.txt | 18 +-
tools/perf/builtin-top.c | 23 +--
2 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index c16a09e..d311974 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -143,20 +143,12 @@ Default is to monitor all CPUS.
--asm-raw::
Show raw instruction encoding of assembly instructions.
--G [type,min,order]::
+-G::
+ Enables call-graph (stack chain/backtrace) recording.
+
--call-graph::
-Display call chains using type, min percent threshold and order.
- type can be either:
- - flat: single column, linear exposure of call chains.
- - graph: use a graph tree, displaying absolute overhead rates.
- - fractal: like graph, but displays relative rates. Each branch of
-the tree is considered as a new profiled object.
-
- order can be either:
- - callee: callee based call graph.
- - caller: inverted caller based call graph.
-
- Default: fractal,0.5,callee.
+ Setup and enable call-graph (stack chain/backtrace) recording,
+ implies -g.
--max-stack::
Set the stack depth limit when parsing the callchain, anything
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 04f5bf2..488fec3 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1015,16 +1015,16 @@ out_delete:
}
static int
-parse_callchain_opt(const struct option *opt, const char *arg, int unset)
+callchain_opt(const struct option *opt, const char *arg, int unset)
{
- /*
-* --no-call-graph
-*/
- if (unset)
- return 0;
-
symbol_conf.use_callchain = true;
+ return record_callchain_opt(opt, arg, unset);
+}
+static int
+parse_callchain_opt(const struct option *opt, const char *arg, int unset)
+{
+ symbol_conf.use_callchain = true;
return record_parse_callchain_opt(opt, arg, unset);
}
@@ -1110,9 +1110,12 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
" abort, in_tx, transaction"),
OPT_BOOLEAN('n', "show-nr-samples", &symbol_conf.show_nr_samples,
"Show a column with the number of samples"),
- OPT_CALLBACK_DEFAULT('G', "call-graph", &top.record_opts,
-"mode[,dump_size]", record_callchain_help,
-&parse_callchain_opt, "fp"),
+ OPT_CALLBACK(0, "call-graph", &top.record_opts,
+"mode[,dump_size]", record_callchain_help,
+&parse_callchain_opt),
+ OPT_CALLBACK_NOOPT('G', NULL, &top.record_opts,
+NULL, "enables call-graph recording",
+&callchain_opt),
OPT_INTEGER(0, "max-stack", &top.max_stack,
"Set the maximum stack depth when parsing the callchain. "
"Default: " __stringify(PERF_MAX_STACK_DEPTH)),
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] perf tools: Fix -g option handling
On Sat, Oct 26, 2013 at 04:25:32PM +0200, Jiri Olsa wrote: > hi, > changing the '-g/-G' options for record/top commands > to take NO argument and enable unwind method based > on .perfconfig setup (using FP by default). > > The current -g option parsing moves into the > '--call-graph' option. forgot to mention branch: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/cc jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ARM/kirkwood: v3.12-rc6: kernel BUG at mm/util.c:390!
On Thu, Oct 24, 2013 at 09:07:30PM +0100, Aaro Koskinen wrote: > Hi, Hello, [adding Catalin and Simon] > I was trying to debug kernel crashes on Marvell Kirkwood (openrd) > when upgrading from GCC 4.7.3 -> GCC 4.8.2. So I enabled most of the > kernel debug options. However, I noticed that already when compiled with > GCC 4.7.3 kernel crashes consistently at boot when DEBUG_VM is enabled > (without it there are no issues with 4.7.3). See below for the boot/crash > log & kernel config. Ok, but this doesn't seem to be related to GCC. [...] > [ 26.694345] ata2: link is slow to respond, please be patient (ready=0) > [ 31.194346] ata2: SRST failed (errno=-16) > [ 31.754426] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300) > [ 31.834619] ata2.00: ATA-6: eSATA-2 WD5000AAKX-00ERMA0, 15.01H15, max > UDMA/133 > [ 31.899627] ata2.00: 976773168 sectors, multi 0: LBA48 > [ 31.994458] ata2.00: configured for UDMA/133 > [ 32.075306] [ cut here ] > [ 32.136256] kernel BUG at mm/util.c:390! > [ 32.195446] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM > [ 32.255893] Modules linked in: > [ 32.313109] CPU: 0 PID: 12 Comm: kworker/u2:1 Not tainted > 3.12.0-rc6-openrd-los.git-1836ad9-dirty #3 > [ 32.435821] Workqueue: events_unbound async_run_entry_fn > [ 32.498701] task: df854700 ti: df8a8000 task.ti: df8a8000 > [ 32.561662] PC is at page_mapping+0x48/0x50 > [ 32.622764] LR is at flush_kernel_dcache_page+0x14/0x98 > [ 32.685421] pc : []lr : []psr: 2093 > [ 32.685421] sp : df8a99f8 ip : df8a9a08 fp : df8a9a04 > [ 32.812754] r10: 6093 r9 : df8a9c24 r8 : 0024 > [ 32.874269] r7 : r6 : c0a3cd0c r5 : 1000 r4 : c0e2732c > [ 32.936395] r3 : r2 : 0080 r1 : 0564 r0 : c0e2732c > [ 32.996978] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [ 33.059012] Control: 0005317f Table: 1a8dc000 DAC: 0017 > [ 33.119473] Process kworker/u2:1 (pid: 12, stack limit = 0xdf8a81c0) The BUG is because page_mapping is being given a slab page... > [ 36.477203] Backtrace: > [ 36.535603] [] (page_mapping+0x0/0x50) from [] > (flush_kernel_dcache_page+0x14/0x98) > [ 36.661070] [] (flush_kernel_dcache_page+0x0/0x98) from > [] (sg_miter_stop+0xc8/0x10c) > [ 36.792813] r4:df8a9a64 r3:0003 > [ 36.857524] [] (sg_miter_stop+0x0/0x10c) from [] > (sg_miter_next+0x14/0x13c) ... assumedly for scatter/gather DMA. How is your block driver allocating its buffers? If you're using the DMA API, I can't see how this would happen. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: wm5110: Enable micd clamp functionality
Add missing registers and interrupts required for the microphone
detection clamping.
Signed-off-by: Charles Keepax
---
drivers/mfd/wm5110-tables.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
index c5c116a..bf8b3b5 100644
--- a/drivers/mfd/wm5110-tables.c
+++ b/drivers/mfd/wm5110-tables.c
@@ -243,6 +243,12 @@ int wm5110_patch(struct arizona *arizona)
EXPORT_SYMBOL_GPL(wm5110_patch);
static const struct regmap_irq wm5110_aod_irqs[ARIZONA_NUM_IRQ] = {
+ [ARIZONA_IRQ_MICD_CLAMP_FALL] = {
+ .mask = ARIZONA_MICD_CLAMP_FALL_EINT1
+ },
+ [ARIZONA_IRQ_MICD_CLAMP_RISE] = {
+ .mask = ARIZONA_MICD_CLAMP_RISE_EINT1
+ },
[ARIZONA_IRQ_GP5_FALL] = { .mask = ARIZONA_GP5_FALL_EINT1 },
[ARIZONA_IRQ_GP5_RISE] = { .mask = ARIZONA_GP5_RISE_EINT1 },
[ARIZONA_IRQ_JD_FALL] = { .mask = ARIZONA_JD1_FALL_EINT1 },
@@ -505,6 +511,7 @@ static const struct reg_default wm5110_reg_default[] = {
{ 0x0293, 0x },/* R659 - Accessory Detect Mode 1 */
{ 0x029B, 0x0020 },/* R667 - Headphone Detect 1 */
{ 0x029C, 0x },/* R668 - Headphone Detect 2 */
+ { 0x02A2, 0x },/* R674 - Micd clamp control */
{ 0x02A3, 0x1102 },/* R675 - Mic Detect 1 */
{ 0x02A4, 0x009F },/* R676 - Mic Detect 2 */
{ 0x02A5, 0x },/* R677 - Mic Detect 3 */
@@ -1439,6 +1446,7 @@ static bool wm5110_readable_register(struct device *dev,
unsigned int reg)
case ARIZONA_ACCESSORY_DETECT_MODE_1:
case ARIZONA_HEADPHONE_DETECT_1:
case ARIZONA_HEADPHONE_DETECT_2:
+ case ARIZONA_MICD_CLAMP_CONTROL:
case ARIZONA_MIC_DETECT_1:
case ARIZONA_MIC_DETECT_2:
case ARIZONA_MIC_DETECT_3:
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
On 10/26/2013 10:42 AM, Chen Gang wrote: > On 10/24/2013 11:29 PM, Josh Boyer wrote: >> On Wed, Oct 23, 2013 at 10:31 PM, Chen Gang wrote: >>> For some architectures, tool chain is not smart enough to recognize the >>> macro with multiple lines (e.g. arc tool chain), and for common ".S" >>> file, this kind of macro is also rarely used. >>> >>> So expand the related contents of macro to let it pass compiling (can >>> use "arc-elf32-objdump -x" to know about it). >>> >>> The related error (allmodconfig for arc): >>> >>> LD init/built-in.o >>> kernel/built-in.o: In function `load_module_signing_keys': >>> kernel/modsign_pubkey.c:66: undefined reference to >>> `modsign_certificate_list' >>> kernel/modsign_pubkey.c:71: undefined reference to >>> `modsign_certificate_list_end' >>> kernel/modsign_pubkey.c:67: undefined reference to >>> `modsign_certificate_list_end' >>> >>> The related tool chain information: >>> >>> [root@gchenlinux linux-next]# arc-elf32-as -v >>> GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) >>> 2.23.2 >>> [root@gchenlinux linux-next]# arc-elf32-ld -v >>> GNU ld (GNU Binutils) 2.23.2 >>> [root@gchenlinux linux-next]# arc-elf32-gcc -v >>> Using built-in specs. >>> COLLECT_GCC=arc-elf32-gcc >>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper >>> Target: arc-elf32 >>> Configured with: ../gcc/configure --without-header --disable-nls >>> --enable-language=c --disable-threads --disable-shared --enable-werror=no >>> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >>> --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls >>> --enable-language=c --disable-threads --disable-shared --enable-werror=no >>> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >>> --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header >>> --disable-nls --enable-language=c --disable-threads --disable-shared >>> --enable-werror=no target_configargs=enable_vtable_verify=yes >>> --target=arc-elf32 --with-cpu=arc700 --disable-multilib >>> --with-headers=../newlib/newlib/libc/include >>> Thread model: single >>> gcc version 4.8.0 (GCC) >> >> Is this only an issue with using multi-line macro definitions in .S >> files? The practice of using multi-line macro definitions isn't rare. >> Look at e.g. include/linux/module.h, and a number of other header >> files. >> > > Yes, excluding "arch/*", for all ".S" files, except x86 driver and this > file, no others use multi-line macro definition, and "arch/arc" don't > use mulit-line macro definitions, either. > Oh, sorry, what my written is not quite precise, and my real meaning is: "no others *intend* to use multi-line macro definition in *.S". > The related search command is: > > "find | grep -i "\.S$" | grep -v "/arch/" | grep -v "Documentation" | > xargs grep define". > > Hmm... at least, in our case, we need not use the multi-line macro > definition, if expand it, the total lines will be shrunk, that will > be more clearer and simpler to source code readers and writers. > > >> This seems like a toolchain bug that should be fixable if it works for >> other architectures. >> > > Hmm... at least, we are sure the toolchain is not quite smart enough > (but we can not say it must be a bug). > > > So for me, I recommend to apply this patch (maybe the patch comment > need improvement). It is quite valuable to continue discussing about > it, but it is not related with whether applying this patch or not. > >> josh >> >> > > Thanks. > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] vxlan: silence one build warning
On Sat, 26 Oct 2013 15:06:04 +0800
Zhi Yong Wu wrote:
> On Fri, Oct 25, 2013 at 11:41 PM, Stephen Hemminger
> wrote:
> > On Fri, 25 Oct 2013 15:49:18 +0800
> > Zhi Yong Wu wrote:
> >
> >> From: Zhi Yong Wu
> >>
> >> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
> >> drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in
> >> this function [-Wmaybe-uninitialized]
> >> drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
> >> LD drivers/net/built-in.o
> >>
> >> Signed-off-by: Zhi Yong Wu
> >> ---
> >> drivers/net/vxlan.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> >> index 2ef5b62..e15f1af 100644
> >> --- a/drivers/net/vxlan.c
> >> +++ b/drivers/net/vxlan.c
> >> @@ -2272,7 +2272,7 @@ static struct vxlan_sock *vxlan_socket_create(struct
> >> net *net, __be16 port,
> >> {
> >> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
> >> struct vxlan_sock *vs;
> >> - struct socket *sock;
> >> + struct socket *sock = NULL;
> >> struct sock *sk;
> >> int rc = 0;
> >> unsigned int h;
> >
> > This only happens with certain versions of Gcc which have buggy dependency
> > analysis. It doesn't happen with Gcc 4.7, think it only shows up in 4.4.
> > I would rather not fix the warning this way since it risks masking later
> > bugs if this code ever changes.
> Gcc version is 4.7.2 on my box, this warning took palce.
> # gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> ...
> gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
>
>
I dont see it on Debian 7.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: video: metronomefb: avoid out-of-bounds array access
From: Michal Nazarewicz
load_waveform function checks whether padding bytes in stuff2a
and stuff2b are all zero, but does so by treating those arrays
as a single longer array. Since the structure is packed, and
the size sum matches, it all works, but creates some confusion
in the code.
This commit changes the stuff2a and stuff2b arrays into pad1 and
pad2 fields such that they cover the same bytes as the arrays
covered, and changes the check in the load_waveform function so
that the fields are read instead of iterating over an arary.
It also renames the other “stuff” fields to “ignore*” fields to
give them more semantic meaning.
Signed-off-by: Michal Nazarewicz
---
drivers/video/metronomefb.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/video/metronomefb.c b/drivers/video/metronomefb.c
index f30150d..44ef8b0 100644
--- a/drivers/video/metronomefb.c
+++ b/drivers/video/metronomefb.c
@@ -126,7 +126,7 @@ static struct fb_var_screeninfo metronomefb_var = {
/* the waveform structure that is coming from userspace firmware */
struct waveform_hdr {
- u8 stuff[32];
+ u8 ignore1[32];
u8 wmta[3];
u8 fvsn;
@@ -134,13 +134,14 @@ struct waveform_hdr {
u8 luts;
u8 mc;
u8 trc;
- u8 stuff3;
+ u8 ignore2;
u8 endb;
u8 swtb;
- u8 stuff2a[2];
+ u32 pad1; /* u16 halfof(pad1) */
- u8 stuff2b[3];
+ /* u16 halfof(pad1) */
+ u8 pad2;
u8 wfm_cs;
} __attribute__ ((packed));
@@ -210,11 +211,9 @@ static int load_waveform(u8 *mem, size_t size, int m, int
t,
}
wfm_hdr->mc += 1;
wfm_hdr->trc += 1;
- for (i = 0; i < 5; i++) {
- if (*(wfm_hdr->stuff2a + i) != 0) {
- dev_err(dev, "Error: unexpected value in padding\n");
- return -EINVAL;
- }
+ if (wfm_hdr->pad1 || wfm_hdr->pad2) {
+ dev_err(dev, "Error: unexpected value in padding\n");
+ return -EINVAL;
}
/* calculating trn. trn is something used to index into
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8] watchdog: Add MOXA ART watchdog driver
Hi Jonas, > This patch adds a watchdog driver for the main hardware watchdog timer > found on MOXA ART SoCs. > > The MOXA ART SoC provides one writable timer register, restarting > the hardware once it reaches zero. The register is auto decremented > every APB clock cycle. > > Signed-off-by: Jonas Jensen Added to linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: blk-mq flush fix
I think this variant of the patch from Alexander should fix the issue
in a minimally invasive way. Longer term I'd prefer to use q->flush_rq
like in the non-mq case by copying over the context and tag information.
diff --git a/block/blk-core.c b/block/blk-core.c
index 3bb9e9f..9677c65 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1102,7 +1102,7 @@ static struct request *blk_old_get_request(struct
request_queue *q, int rw,
struct request *blk_get_request(struct request_queue *q, int rw, gfp_t
gfp_mask)
{
if (q->mq_ops)
- return blk_mq_alloc_request(q, rw, gfp_mask);
+ return blk_mq_alloc_request(q, rw, gfp_mask, false);
else
return blk_old_get_request(q, rw, gfp_mask);
}
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 3e4cc9c..331e627 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -286,7 +286,7 @@ static void mq_flush_work(struct work_struct *work)
/* We don't need set REQ_FLUSH_SEQ, it's for consistency */
rq = blk_mq_alloc_request(q, WRITE_FLUSH|REQ_FLUSH_SEQ,
- __GFP_WAIT|GFP_ATOMIC);
+ __GFP_WAIT|GFP_ATOMIC, true);
rq->cmd_type = REQ_TYPE_FS;
rq->end_io = flush_end_io;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c88c0de..134100d1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -204,14 +204,15 @@ static struct request *blk_mq_alloc_request_pinned(struct
request_queue *q,
return rq;
}
-struct request *blk_mq_alloc_request(struct request_queue *q, int rw, gfp_t
gfp)
+struct request *blk_mq_alloc_request(struct request_queue *q, int rw,
+ gfp_t gfp, bool reserved)
{
struct request *rq;
if (blk_mq_queue_enter(q))
return NULL;
- rq = blk_mq_alloc_request_pinned(q, rw, gfp, false);
+ rq = blk_mq_alloc_request_pinned(q, rw, gfp, reserved);
blk_mq_put_ctx(rq->mq_ctx);
return rq;
}
@@ -1286,6 +1287,15 @@ struct request_queue *blk_mq_init_queue(struct
blk_mq_reg *reg,
reg->queue_depth = BLK_MQ_MAX_DEPTH;
}
+ /*
+* Set aside a tag for flush requests. It will only be used while
+* another flush request is in progress but outside the driver.
+*
+* TODO: only allocate if flushes are supported
+*/
+ reg->queue_depth++;
+ reg->reserved_tags++;
+
if (reg->queue_depth < (reg->reserved_tags + BLK_MQ_TAG_MIN))
return ERR_PTR(-EINVAL);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 158da52..3eb1beb 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -123,7 +123,7 @@ void blk_mq_flush_plug_list(struct blk_plug *plug, bool
from_schedule);
void blk_mq_run_queues(struct request_queue *q, bool async);
void blk_mq_free_request(struct request *rq);
bool blk_mq_can_queue(struct blk_mq_hw_ctx *);
-struct request *blk_mq_alloc_request(struct request_queue *q, int rw, gfp_t
gfp);
+struct request *blk_mq_alloc_request(struct request_queue *q, int rw, gfp_t
gfp, bool reserved);
struct request *blk_mq_alloc_reserved_request(struct request_queue *q, int rw,
gfp_t gfp);
struct request *blk_mq_rq_from_tag(struct request_queue *q, unsigned int tag);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RIP: mem_cgroup_move_account+0xf4/0x290
On Sat, Oct 26 2013, 含黛 wrote: > On 10/26/2013 11:39 AM, Johannes Weiner wrote: >> On Fri, Oct 25, 2013 at 02:15:55PM -0200, Flavio Leitner wrote: >>> While playing with guests and net-next kernel, I've triggered >>> this with some frequency. Even Fedora 19 kernel reproduces. >>> >>> It it a known issue? >>> >>> Thanks, >>> fbl >>> >>> [ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound >>> [ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound >>> [ 7535.654438] perf samples too long (2719 > 2500), lowering >>> kernel.perf_event_max_sample_rate to 5 >>> [ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long to >>> run: 11.560 msecs >>> [ 7691.048392] virbr0: port 1(vnet0) entered disabled state >>> [ 7691.056281] device vnet0 left promiscuous mode >>> [ 7691.061674] virbr0: port 1(vnet0) entered disabled state >>> [ 7691.163363] BUG: unable to handle kernel paging request at >>> 60fbc0002a20 >>> [ 7691.171145] IP: [] mem_cgroup_move_account+0xf4/0x290 >>> [ 7691.178574] PGD 0 >>> [ 7691.181042] Oops: [#1] SMP >>> [ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth >>> openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast >>> ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge >>> stp >>> llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 >>> nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle ip6table_security >>> ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 >>> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle >>> iptable_security iptable_raw coretemp kvm_intel snd_hda_codec_realtek >>> snd_hda_intel nfsd snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd >>> snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc sunrpc snd_timer >>> crc32c_intel i7core_edac bnx2 shpchp ptp snd iTCO_wdt joydev pps_core >>> iTCO_vendor_support pcspkr soundcore microcode serio_raw lpc_ich edac_core >>> mfd_core i2c_i801 acpi_cpufreq hid_logitech_dj nouveau ata_generic pata_acpi >>> video i2c_algo_bit drm_kms_helper ttm drm mxm_wmi i2c_core pata_marvell wmi >>> [last unloaded: openvswitch] >>> [ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G I >>> 3.12.0-rc6-01188-gb45bd46 #1 >>> [ 7691.295779] Hardware name: /DX58SO, BIOS >>> SOX5810J.86A.5599.2012.0529.2218 05/29/2012 >>> [ 7691.306066] Workqueue: events css_killed_work_fn >>> [ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: >>> 88042957a000 >>> [ 7691.319673] RIP: 0010:[] [] >>> mem_cgroup_move_account+0xf4/0x290 >>> [ 7691.329728] RSP: 0018:88042957bcc8 EFLAGS: 00010002 >>> [ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: >>> 0004 >>> [ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: >>> 880424cd622c >>> [ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: >>> 0001 >>> [ 7691.359751] R10: 0001 R11: 0001 R12: >>> ea00103ef0c0 >>> [ 7691.367745] R13: 880424cd6000 R14: R15: >>> 880424cd622c >>> [ 7691.375738] FS: () GS:88043fc2() >>> knlGS: >>> [ 7691.384755] CS: 0010 DS: ES: CR0: 8005003b >>> [ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: >>> 27e0 >>> [ 7691.399235] Stack: >>> [ 7691.401672] 88042957bce8 88042957bce8 81312b6d >>> 880424cd4000 >>> [ 7691.409968] 88040001 880424cd6000 ea00103ef0c0 >>> 880424cd0430 >>> [ 7691.418264] 88042b17bc30 ea00103ef0e0 880424cd6000 >>> 88042957bda8 >>> [ 7691.426578] Call Trace: >>> [ 7691.429513] [] ? list_del+0xd/0x30 >>> [ 7691.435250] [] mem_cgroup_reparent_charges+0x247/0x460 >>> [ 7691.442874] [] mem_cgroup_css_offline+0xaf/0x1b0 >>> [ 7691.449942] [] offline_css+0x27/0x50 >>> [ 7691.455874] [] css_killed_work_fn+0x2d/0xa0 >>> [ 7691.462466] [] process_one_work+0x175/0x430 >>> [ 7691.469041] [] worker_thread+0x11b/0x3a0 >>> [ 7691.475345] [] ? rescuer_thread+0x340/0x340 >>> [ 7691.481919] [] kthread+0xc0/0xd0 >>> [ 7691.487478] [] ? insert_kthread_work+0x40/0x40 >>> [ 7691.494352] [] ret_from_fork+0x7c/0xb0 >>> [ 7691.500464] [] ? insert_kthread_work+0x40/0x40 >>> [ 7691.507335] Code: 85 f6 48 8b 55 d0 44 8b 4d c8 4c 8b 45 c0 0f 85 b3 00 >>> 00 >>> 00 41 8b 4c 24 18 85 c9 0f 88 a6 00 00 00 48 8b b2 30 02 00 00 45 89 ca <4c> >>> 39 56 18 0f 8c 36 01 00 00 44 89 c9 f7 d9 89 cf 65 48 01 7e >> This is >> >> All code >> >> 0: 85 f6 test %esi,%esi >> 2: 48 8b 55 d0 mov-0x30(%rbp),%rdx >> 6: 44 8b 4d c8 mov-0x38(%rbp),%r9d >> a: 4c 8b 45 c0 mov-0x40(%rbp),%r8 >> e: 0f 85 b3 00 00 00 jne0xc7 >>14: 41 8b 4c 24 18 mov0x18(%r12),%ecx >>19:
RE: [PATCH] usb-storage: scsiglue: Changing the command result
Hi Alan,
Here is the new patch:
From: Vishal Annapurve
Date: Sat, 26 Oct 2013 21:10:11 +0530
Subject: [PATCH] usb: storage: Proper cmd result assignment
This change replaces DID_ABORT with DID_TIMEOUT as a command result
whenever US_FLIDX_TIMED_OUT bit is set.
This change is made to bring USB storage inline with a recent change:
commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8
[SCSI] Handle disk devices which can not process medium access commands
We have experienced several devices which fail in a fashion we do not
currently handle gracefully in SCSI. After a failure these devices will
respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.)
but any command accessing the storage medium will time out.
As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.
Change-Id: Ic58e2247fed11649f4dbea56382354ba2fe0be1b
---
drivers/staging/keucr/transport.c | 6 +++---
drivers/staging/keucr/usb.c | 5 +++--
drivers/usb/storage/cypress_atacb.c | 1 +
drivers/usb/storage/isd200.c| 2 +-
drivers/usb/storage/transport.c | 8
drivers/usb/storage/usb.c | 9 +
6 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/keucr/transport.c
b/drivers/staging/keucr/transport.c
index 1a8837d..ac0e3c2 100644
--- a/drivers/staging/keucr/transport.c
+++ b/drivers/staging/keucr/transport.c
@@ -312,7 +312,7 @@ void usb_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
we need to short-circuit all other processing */
if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
/* pr_info("-- command was aborted\n"); */
- srb->result = DID_ABORT << 16;
+ srb->result = DID_TIME_OUT << 16;
goto Handle_Errors;
}
@@ -371,7 +371,7 @@ void usb_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
/* pr_info("-- auto-sense aborted\n"); */
- srb->result = DID_ABORT << 16;
+ srb->result = DID_TIME_OUT << 16;
goto Handle_Errors;
}
if (temp_result != USB_STOR_TRANSPORT_GOOD) {
@@ -447,7 +447,7 @@ void ENE_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
we need to short-circuit all other processing */
if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
/* pr_info("-- command was aborted\n"); */
- srb->result = DID_ABORT << 16;
+ srb->result = DID_TIME_OUT << 16;
goto Handle_Errors;
}
diff --git a/drivers/staging/keucr/usb.c b/drivers/staging/keucr/usb.c
index 66aad3a..79405be 100644
--- a/drivers/staging/keucr/usb.c
+++ b/drivers/staging/keucr/usb.c
@@ -200,7 +200,7 @@ static int usb_stor_control_thread(void * __us)
/* has the command timed out *already* ? */
if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags))
{
- us->srb->result = DID_ABORT << 16;
+ us->srb->result = DID_TIME_OUT << 16;
goto SkipForAbort;
}
@@ -234,7 +234,8 @@ static int usb_stor_control_thread(void * __us)
scsi_lock(host);
/* indicate that the command is done */
- if (us->srb->result != DID_ABORT << 16)
+ if ((us->srb->result != DID_ABORT << 16) &&
+ (us->srb->result != DID_TIME_OUT << 16))
{
us->srb->scsi_done(us->srb);
}
diff --git a/drivers/usb/storage/cypress_atacb.c
b/drivers/usb/storage/cypress_atacb.c
index c844718..af24894 100644
--- a/drivers/usb/storage/cypress_atacb.c
+++ b/drivers/usb/storage/cypress_atacb.c
@@ -168,6 +168,7 @@ static void cypress_atacb_passthrough(struct scsi_cmnd
*srb, struct us_data *us)
*/
if ((srb->result != (DID_ERROR << 16) &&
srb->result != (DID_ABORT << 16)) &&
+ srb->result != (DID_TIME_OUT << 16) &&
save_cmnd[2] & 0x20) {
struct scsi_eh_save ses;
unsigned char regs[8];
diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index ffc4193..28b688b 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -705,7 +705,7 @@ static void isd200_invoke_transport( struct us_data *us,
/* abort processing: the bulk-only transport requires a reset
* following an abort */
Handle_Abort:
- srb->result = DID_ABORT << 16;
+ srb->result = DID_TIME_OUT << 16;
/* permit the reset transfer to take place */
clear_bit(US_FLIDX_ABORTING, &us->dflags);
diff --git a/drivers/usb/storage/
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On Mon, 21 Oct, at 03:37:41PM, Borislav Petkov wrote: > On Mon, Oct 21, 2013 at 08:47:39PM +0800, Dave Young wrote: > > What's the status of this series? > > They should appear at some point in Matt's efi-next branch, I think. > > > I need below patch for mapping to fixed virt addr passed > > from 1st kernel. > > You need this to map the runtime regions in the kexec kernel, right? > Please write that in the commit message. > > > Would you like to add it to your series or I send out it later? > > Yeah, just add it to your patchset. > > > BTW, what tree should my patches based on? Matt's next tree? > > Yeah, I think efi-next. Matt? Yes please. -- Matt Fleming, 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: EFI boot problem in 3.11
On Thu, 24 Oct, at 12:14:26PM, Jasper Bryant-Greene wrote: > I have a box here which is set up for EFI boot with no boot loader. > > The kernel is compiled with a built-in initrd and command line. > > In 3.10 this was all working well. However, after updating to 3.11.5 a > reboot leads to the EFI firmware boot screen appearing followed by the > middle section of it going black (just leaving two vertical stripes of > the EFI firmware boot screen on either side of the screen) and the > system locking up (numlock etc do not work). > > However, if I hit ‘delete’ quickly when powering on, and enter the > firmware setup screen, I can then ‘exit without saving’ and the system > will boot successfully — ‘save and exit’ does not work as that > performs a full reboot while ‘exit without saving’ seems to continue > the boot where it left off. > > Due to the aforementioned graphics corruption, I am wondering whether > it is somehow related to the frame buffer? As this is a production > system I unfortunately do not have flexibility to try a number of > kernel versions in-between to locate where the issue was introduced. Nothing springs to mind and nothing jumps out of the log in drivers/video or arch/x86/platform/efi. The best way to figure out what's causing this issue really is to bisect the kernel versions. What hardware are you running on? -- Matt Fleming, 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: [PATCH 1/2] x86: unify copy_from_user() size checking
On 10/26/2013 03:31 AM, Ingo Molnar wrote:
* Jan Beulich wrote:
Commits 4a3127693001c61a21d1ce680db6340623f52e93 ("x86: Turn the
copy_from_user check into an (optional) compile time warning") and
63312b6a6faae3f2e5577f2b001e3b504f10a2aa ("x86: Add a Kconfig option to
turn the copy_from_user warnings into errors") touched only the 32-bit
variant of copy_from_user(), whereas the original commit
9f0cf4adb6aa0bfccf675c938124e68f7f06349d ("x86: Use
__builtin_object_size() to validate the buffer size for
copy_from_user()") also added the same code to the 64-bit one.
Further the earlier conversion from an inline WARN() to the call to
copy_from_user_overflow() went a little too far: When the number of
bytes to be copied is not a constant (e.g. [looking at 3.11] in
drivers/net/tun.c:__tun_chr_ioctl() or
drivers/pci/pcie/aer/aer_inject.c:aer_inject_write()), the compiler
will always have to keep the funtion call, and hence there will always
be a warning. By using __builtin_constant_p() we can avoid this.
And then this slightly extends the effect of
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS in that apart from converting
warnings to errors in the constant size case, it retains the (possibly
wrong) warnings in the non-constant size case, such that if someone is
prepared to get a few false positives, (s)he'll be able to recover the
current behavior (except that these diagnostics now will never be
converted to errors).
Since the 32-bit variant (intentionally) didn't call might_fault(), the
unification results in this being called twice now. Adding a suitable
#ifdef would be the alternative if that's a problem.
Addressing that sanely would be nice.
I'd like to point out though that with __compiletime_object_size()
being restricted to gcc before 4.6, the whole construct is going to
become more and more pointless going forward. I would question
however that commit 2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a2 ("gcc4:
disable __compiletime_object_size for GCC 4.6+") was really necessary,
and instead this should have been dealt with as is done here from the
beginning.
Can we now revert 2fb0815c9ee6?
I sure don't mind if there is a different and better solution.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 REPOST] mfd: add support for ams AS3722 PMIC
Hi Grant, > > Acked-by: Stephen Warren > > Signed-off-by: Laxman Dewangan > > Signed-off-by: Florian Lobmaier > > Signed-off-by: Lee Jones > > +Optional properties: > > +--- > > + The input supply of regulators are the optional properties on the > > + regulator node. The input supply of these regulators are provided > > + through following properties: > > + vsup-sd2-supply: Input supply for SD2. > > + vsup-sd3-supply: Input supply for SD3. > > + vsup-sd4-supply: Input supply for SD4. > > + vsup-sd5-supply: Input supply for SD5. > > + vin-ldo0-supply: Input supply for LDO0. > > + vin-ldo1-6-supply: Input supply for LDO1 and LDO6. > > + vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7. > > + vin-ldo3-4-supply: Input supply for LDO3 and LDO4. > > + vin-ldo9-10-supply: Input supply for LDO9 and LDO10. > > + vin-ldo11-supply: Input supply for LDO11. > > What is the data in these properties? The documentation isn't clear. > > In principle, the binding looks okay to me. The properties to which you refer are standard regulator supply bindings specified here [1]. Specifically: "-supply: phandle to the parent supply/regulator node" The DT portion has already been Acked by Stephen and applied by me. [1] Documentation/devicetree/bindings/regulator/regulator.txt -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] extcon: arizona: Add defines for microphone detection levels
On Sat, 26 Oct 2013, Charles Keepax wrote: > Improve readability by creating a define for each microphone detection > level. > > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c | 21 - > include/linux/mfd/arizona/registers.h |9 + > 2 files changed, 25 insertions(+), 5 deletions(-) I haven't checked the actual 'values' of the new defines, but I assume you know what you're doing. I like the basic premise of the patch so I've applied it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: arizona: Fix reset of HPDET after race with removal
On Sat, 26 Oct 2013, Charles Keepax wrote:
> We need to make sure we reset back to our starting state, especially
> making sure that we have disabled poll in the register cache.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 92eb486..3ce7b49 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -572,6 +572,14 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
> goto out;
> } else if (!ret) {
> dev_dbg(arizona->dev, "Ignoring HPDET for removed cable\n");
> +
> + /* Reset back to starting range */
> + regmap_update_bits(arizona->regmap,
> +ARIZONA_HEADPHONE_DETECT_1,
> +ARIZONA_HP_IMPEDANCE_RANGE_MASK |
> +ARIZONA_HP_POLL,
> +0);
> +
> goto done;
> }
>
> @@ -607,9 +615,9 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
> dev_err(arizona->dev, "Failed to report HP/line: %d\n",
> ret);
>
> +done:
> arizona_extcon_do_magic(info, 0);
>
> -done:
> if (id_gpio)
> gpio_set_value_cansleep(id_gpio, 0);
>
What happens if we don't update the bits and we still do magic in the
new error path? Does that adversely affect any later 'goto done's?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: wm5110: Enable micd clamp functionality
On Sat, 26 Oct 2013, Charles Keepax wrote: > Add missing registers and interrupts required for the microphone > detection clamping. > > Signed-off-by: Charles Keepax > --- > drivers/mfd/wm5110-tables.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: kprobe: "BUG: unable to handle kernel paging request"
On Sat, Oct 26, 2013 at 1:01 AM, Azat Khuzhin wrote: > With some kernel's configuration there is such messages in dmesg in > different places while using kprobes. > > I investigated this and founded that it reproduced with > https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-deb > And not reproduced with > https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-worked-kprobe I reduced difference between this two configs, and the new one with not worked kprobe is here: https://gist.github.com/azat/7078890#file-config-3-12-0-rc5-dont-worked-kprobe The only thing I changed in "make menuconfig" is preemption model, from CONFIG_PREEMPT_VOLUNTARY(good) to CONFIG_PREEMPT(bad) U=https://gist.github.com/azat/7078890/raw/ diff -u0 <(curl -s $U/8268502680c9b1c5924ce6bf45dd08381bc9ddb3/config-3.12.0-rc5%2Bdont-worked-kprobe) <(curl -s $U/b7a9367506fa1c9598f5752c045cff582c3588ba/config-3.12.0-rc5%2Bworked-kprobe) --- /dev/fd/63 2013-10-26 20:35:00.679801733 +0400 +++ /dev/fd/62 2013-10-26 20:35:00.679801733 +0400 @@ -128,2 +128,2 @@ -CONFIG_TREE_PREEMPT_RCU=y -CONFIG_PREEMPT_RCU=y +CONFIG_TREE_RCU=y +# CONFIG_PREEMPT_RCU is not set @@ -137 +136,0 @@ -# CONFIG_RCU_BOOST is not set @@ -224,0 +224 @@ +CONFIG_OPTPROBES=y @@ -332 +332,5 @@ -CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y +CONFIG_INLINE_READ_UNLOCK=y +CONFIG_INLINE_READ_UNLOCK_IRQ=y +CONFIG_INLINE_WRITE_UNLOCK=y +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y @@ -378,2 +382,2 @@ -# CONFIG_PREEMPT_VOLUNTARY is not set -CONFIG_PREEMPT=y +CONFIG_PREEMPT_VOLUNTARY=y +# CONFIG_PREEMPT is not set @@ -3547,0 +3552 @@ +# CONFIG_DRM_I810 is not set @@ -5047 +5051,0 @@ -CONFIG_DEBUG_PREEMPT=y @@ -5075 +5078,0 @@ -# CONFIG_PROVE_RCU_DELAY is not set @@ -5079 +5081,0 @@ -CONFIG_RCU_CPU_STALL_VERBOSE=y @@ -5111 +5112,0 @@ -# CONFIG_PREEMPT_TRACER is not set > > I used the next script for testing > https://gist.github.com/azat/7078890#file-ktap-sh > > Here is the initial email log with Jovi (ktap author): > http://www.freelists.org/post/ktap/BUG-unable-to-handle-kernel-paging-request-after-ktap-script-to-trace-SyS-write > > If I can help, please let me know! > Thanks! > > -- > Respectfully > Azat Khuzhin -- Respectfully Azat Khuzhin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion
On 10/24/2013 06:39 AM, Bjorn Helgaas wrote: [+cc Greg] On Fri, Oct 18, 2013 at 08:44:12PM +0800, Lan Tianyu wrote: On 10/18/2013 04:33 AM, Bjorn Helgaas wrote: On Thu, Oct 17, 2013 at 12:09 AM, Lan Tianyu wrote: On 2013年10月17日 07:55, Bjorn Helgaas wrote: On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu@intel.com wrote: I wonder if it would make sense to make acpi_dev_resource_address_space() ignore addr.translation_offset for IO resources. Or maybe ignore it if the _TTP (type translation) bit is set? I wonder why current code doesn't check _TTP? The code in the add_io_space() seems to think _TTP is always set, right? I think it's an oversight, and you should fix it. I suggest that you ignore the _TRA value when _TTP is set. Obviously this only applies to I/O port resources, since _TTP is only defined in the I/O Resource Flag (Table 6-185 in ACPI 5.0 spec). _TTP is also defined in the Memory Resource flag, Please have a look at Table 6-184 in the ACPI 5.0 Spec. I am not sure how to deal with _TTP unsetting io resource? _TTP unsetting mean the resource is IO on the primary side and also IO on the secondary side. Mike, is there any chance you could collect an acpidump from an rx7620 or similar ia64 system? In particular, I want to see a multi-node system where we have several PCI domains, and whether it sets the _TTP bits. Greg collected an acpidump from an HP system that uses these I/O port ranges. Unfortunately the system wasn't running Linux, so it's an EFI dump, not the usual one we get from the "pmtools" package. But I think it has the information we want. It's huge, and I put some of the relevant parts of it here: https://bugzilla.kernel.org/show_bug.cgi?id=63581 Here's a sample that shows the _TTP bit is set for the I/O aperture: Device E000 (\_SB_.N000.E000) Name _SEG (\_SB_.N000.E000._SEG) 0x01 Name _CRS (\_SB_.N000.E001._CRS) Buffer 0x0092 ByteList <0x88 0x0d 0x00 0x02 0x0e 0x00 0x00 0x00 0x00 0x00 0xff 0x00 0x00 0x00 0x00 0x01 0x8a 0x2b 0x00 0x01 0x0c 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xd0 0x00 0x04 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 Byte 0: 0x8a (QWORD address space descriptor) Byte 3: Resource Type = 0x01 (I/O range) Byte 5: Type Specific Flags = 0x33 (_TRS, _TTP, _RNG = 3) QWORD Address Space Descriptor: Type: I/O Flags: Sparse, Translate, ISA I/O addresses, Non-ISA I/O addresses GRA: 0x MIN: 0x MAX: 0x TRA: 0x0400d000 LEN: 0x0001 MAX address fixed MIN address fixed Address positively decoded Device produces and consumes this resource Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] perf: add active_entry list head to struct perf_event
On Fri, Oct 25, 2013 at 4:56 PM, Jiri Olsa wrote:
>
> On Wed, Oct 23, 2013 at 02:58:02PM +0200, Stephane Eranian wrote:
> > This patch adds a new fields to the struct perf_event.
> > It is intended to be used to chain events which are
> > active (enabled). It helps in the hardware layer
> > for PMU which do not have actual counter restrictions, i.e.,
> > free running read-only counters. Active events are chained
> > as opposed to being tracked via the counter they use.
> >
> > Signed-off-by: Stephane Eranian
> > ---
> > include/linux/perf_event.h |1 +
> > kernel/events/core.c |1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 2e069d1..a376384 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -435,6 +435,7 @@ struct perf_event {
> > struct perf_cgroup *cgrp; /* cgroup event is attach to */
> > int cgrp_defer_enabled;
> > #endif
> > + struct list_headactive_entry;
>
> Could this be in union with 'hlist_entry' ? It looks
> as 'same purpose' and 'mutualy exclusive stuff.
>
You're saying that I could use the hlist_entry field because
it is currently only used by the sw events in the generic layer.
But it seems to be a complicated rcu list for the purpose here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 25
On Fri, Oct 25, 2013 at 03:31:44PM -0700, Randy Dunlap wrote: > That's unfortunate. The fixes should be part of the tree IMO. What Stephen does (which does seem like a good policy) is to keep the tree at the previous day's version instead of taking a new version if it introduces breakages on the architectures he tests. That seems to strike a good balance between keeping things working for users and providing pushback to get things fixed before they go to Linus. signature.asc Description: Digital signature
Account
Email Account Warning !!!
This mail is from Administrator; we wish to bring to your notice the Condition
of your email account.
We have just noticed that you have exceeded your email Database limit of 500 MB
quota and your email IP is causing conflict because it is been accessed in
different server location. You need to Upgrade and expand your email quota
limit before you can continue to use your email.Update your email quota limit
to 2.6 GB, fill up the detail to upgrade your account
{user-name:
{Password:
{Confirm Password:
Failure to do this will result to email deactivation within 24hours
Thank you for your understanding.
Copyright 2013 Help Desk
Email Upgrade
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] perf,x86: add Intel RAPL PMU support
On Fri, Oct 25, 2013 at 1:14 PM, Jiri Olsa wrote:
> On Wed, Oct 23, 2013 at 02:58:04PM +0200, Stephane Eranian wrote:
>
> SNIP
>
>> +
>> +static void rapl_init_cpu(int cpu)
>> +{
>> + int i, phys_id = topology_physical_package_id(cpu);
>> +
>> + spin_lock(&rapl_hotplug_lock);
>> +
>> + /* check if phys_is is already covered */
>> + for_each_cpu(i, &rapl_cpu_mask) {
>> + if (phys_id == topology_physical_package_id(i))
>> + return;
>
> missing 'spin_unlock(&rapl_hotplug_lock)' above
>
Good catch. I fixed that now.
>> + }
>> + /* was not found, so add it */
>> + cpumask_set_cpu(cpu, &rapl_cpu_mask);
>> +
>> + spin_unlock(&rapl_hotplug_lock);
>> +}
>> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] perf,x86: add RAPL hrtimer support
On Fri, Oct 25, 2013 at 7:44 PM, Jiri Olsa wrote:
> On Wed, Oct 23, 2013 at 02:58:05PM +0200, Stephane Eranian wrote:
>> The RAPL PMU counters do not interrupt on overflow.
>> Therefore, the kernel needs to poll the counters
>> to avoid missing an overflow. This patch adds
>> the hrtimer code to do this.
>>
>> The timer internval is calculated at boot time
>> based on the power unit used by the HW.
>>
>> Signed-off-by: Stephane Eranian
>> ---
>> arch/x86/kernel/cpu/perf_event_intel_rapl.c | 75
>> +--
>> 1 file changed, 70 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
>> b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
>> index 3d71d39..ed0566a 100644
>> --- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
>> +++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
>> @@ -92,11 +92,13 @@ static struct kobj_attribute format_attr_##_var =
>> \
>>
>> struct rapl_pmu {
>> spinlock_t lock;
>> - atomic_trefcnt;
>> int hw_unit; /* 1/2^hw_unit Joule */
>> - int phys_id;
>> - int n_active; /* number of active events */
>> + struct hrtimer hrtimer;
>> struct list_head active_list;
>> + ktime_t timer_interval; /* in ktime_t unit */
>> + int n_active; /* number of active events */
>> + int phys_id;
>> + atomic_trefcnt;
>> };
>>
>> static struct pmu rapl_pmu_class;
>> @@ -161,6 +163,47 @@ static u64 rapl_event_update(struct perf_event *event)
>> return new_raw_count;
>> }
>>
>> +static void rapl_start_hrtimer(struct rapl_pmu *pmu)
>> +{
>> + __hrtimer_start_range_ns(&pmu->hrtimer,
>> + pmu->timer_interval, 0,
>> + HRTIMER_MODE_REL_PINNED, 0);
>> +}
>> +
>> +static void rapl_stop_hrtimer(struct rapl_pmu *pmu)
>> +{
>> + hrtimer_cancel(&pmu->hrtimer);
>> +}
>> +
>> +static enum hrtimer_restart rapl_hrtimer_handle(struct hrtimer *hrtimer)
>> +{
>> + struct rapl_pmu *pmu = container_of(hrtimer, struct rapl_pmu, hrtimer);
>> + struct perf_event *event;
>> + unsigned long flags;
>> +
>> + if (!pmu->n_active)
>> + return HRTIMER_NORESTART;
>> +
>> + spin_lock_irqsave(&pmu->lock, flags);
>> +
>> + list_for_each_entry(event, &pmu->active_list, active_entry) {
>> + rapl_event_update(event);
>> + }
>
> hi,
> I dont fully understand the reason for the timer,
> I'm probably missing something..
>
The reason is rather simple and is similar to what happens with uncore.
The counter are narrow, 32-bit and there is no interrupt capability. We
need to poll the counters and accumulate in the sw counter to avoid missing
an overflow.
> - the timer calls rapl_event_update for all defined events
No, only for the defined RAPL events which is what we want.
> - but rapl_pmu_event_read calls rapl_event_update any time the
> event is read (sys_read)
>
Yes, but we want to prevent missing a counter overflow. It may happen
if the counter counts in a unit which increments fast.
> The rapl_event_update only read msr and updates
> event->count|hw,prev_count.
No, it does update the count:
local64_add(sdelta, &event->count);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default
On Sat, 2013-10-26 at 11:15 +0200, Ingo Molnar wrote: > So, the best range for the breakage we have is v3.3..v3.5. So far, yeah. I will try and narrow it down. > As a blind shot into the dark, that turns out to be a range when a > number of irq-remapping, vt-d changes went upstream: > > comet:~/tip> gll v3.3..v3.6 arch/x86 | grep -i remap > 399988eea194 irq_remap: Fix compiler warning with CONFIG_IRQ_REMAP=y > 79fec2c557cf Merge tag 'intr-remapping-ops-for-ingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu into core/iommu > 8a8f422d3b4f iommu: rename intr_remapping.[ch] to irq_remapping.[ch] > 95a02e976c39 iommu: rename intr_remapping references to irq_remapping > 263b5e8629c9 x86, iommu/vt-d: Clean up interfaces for interrupt remapping > 5e2b930b0784 iommu/vt-d: Convert MSI remapping setup to remap_ops > 9d619f657222 iommu/vt-d: Convert free_irte into a remap_ops callback > 4c1bad6a0af1 iommu/vt-d: Convert IR set_affinity function to remap_ops > 0c3f173a88c4 iommu/vt-d: Convert IR ioapic-setup to use remap_ops > 4f3d8b67ad30 iommu/vt-d: Convert missing apic.c intr-remapping call to > remap_ops > 736baef4472d iommu/vt-d: Make intr-remapping initialization generic > f7219a5300ba x86: Introduce CONFIG_X86_DMA_REMAP > > So if you are able to test current kernels, it might be an > additional data point to see whether the reboot delay (which appears > to be a reboot hang on other systems) is related to the following > kernel option: Thanks, I'll give it a shot. Note - I suspect some of the other cases may really be delays rather than hangs too. It's very easy to look at the screen sitting there doing absolutely nothing at all for 30-60 seconds, lose patience, conclude it's hung, and force a shutdown/reboot. Several of the earlier Z1 reporters on the vaio-z mailing list reported it as a 'hang', but after I pointed out that it wasn't, confirmed the same behaviour on their systems. This could possibly apply to others too. > CONFIG_IRQ_REMAP=y > > (CONFIG_X86_DMA_REMAP is off on Fedora.) > > IRQ_REMAP is somewhat of a dual personality feature, living half in > arch/x86/, half in drivers/iommu/. It should normally matter for > servers more than for laptops. > > Btw., regarding your encrypted partitions boot problem, do you have > any non-encrypted filesystem? If yes then you could copy /[s]bin and > /lib to it and boot via init=/bin/bash, you ought to get a minimal > shell and be able to run /sbin/reboot. > > Thanks, > > Ingo > -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ARM/kirkwood: v3.12-rc6: kernel BUG at mm/util.c:390!
Hi, On Sat, Oct 26, 2013 at 03:36:17PM +0100, Will Deacon wrote: > On Thu, Oct 24, 2013 at 09:07:30PM +0100, Aaro Koskinen wrote: > > [ 26.694345] ata2: link is slow to respond, please be patient (ready=0) > > [ 31.194346] ata2: SRST failed (errno=-16) > > [ 31.754426] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300) > > [ 31.834619] ata2.00: ATA-6: eSATA-2 WD5000AAKX-00ERMA0, 15.01H15, max > > UDMA/133 > > [ 31.899627] ata2.00: 976773168 sectors, multi 0: LBA48 > > [ 31.994458] ata2.00: configured for UDMA/133 > > [ 32.075306] [ cut here ] > > [ 32.136256] kernel BUG at mm/util.c:390! > > [ 32.195446] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM > > [ 32.255893] Modules linked in: > > [ 32.313109] CPU: 0 PID: 12 Comm: kworker/u2:1 Not tainted > > 3.12.0-rc6-openrd-los.git-1836ad9-dirty #3 > > [ 32.435821] Workqueue: events_unbound async_run_entry_fn > > [ 32.498701] task: df854700 ti: df8a8000 task.ti: df8a8000 > > [ 32.561662] PC is at page_mapping+0x48/0x50 > > [ 32.622764] LR is at flush_kernel_dcache_page+0x14/0x98 > > [ 32.685421] pc : []lr : []psr: 2093 > > [ 32.685421] sp : df8a99f8 ip : df8a9a08 fp : df8a9a04 > > [ 32.812754] r10: 6093 r9 : df8a9c24 r8 : 0024 > > [ 32.874269] r7 : r6 : c0a3cd0c r5 : 1000 r4 : c0e2732c > > [ 32.936395] r3 : r2 : 0080 r1 : 0564 r0 : c0e2732c > > [ 32.996978] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM > > Segment kernel > > [ 33.059012] Control: 0005317f Table: 1a8dc000 DAC: 0017 > > [ 33.119473] Process kworker/u2:1 (pid: 12, stack limit = 0xdf8a81c0) > > The BUG is because page_mapping is being given a slab page... > > > [ 36.477203] Backtrace: > > [ 36.535603] [] (page_mapping+0x0/0x50) from [] > > (flush_kernel_dcache_page+0x14/0x98) > > [ 36.661070] [] (flush_kernel_dcache_page+0x0/0x98) from > > [] (sg_miter_stop+0xc8/0x10c) > > [ 36.792813] r4:df8a9a64 r3:0003 > > [ 36.857524] [] (sg_miter_stop+0x0/0x10c) from [] > > (sg_miter_next+0x14/0x13c) > > ... assumedly for scatter/gather DMA. How is your block driver allocating > its buffers? If you're using the DMA API, I can't see how this would happen. This is sata_mv driver. As far as I understand, it's using DMA API (dma_pool_alloc() etc.). I noticed that for some reason CMA has gotten disabled on my .config. However, enabling both CMA and DMA_CMA will still trigger this BUG... A. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: arizona: Fix reset of HPDET after race with removal
On Sat, Oct 26, 2013 at 09:29:07AM -0700, Lee Jones wrote: > What happens if we don't update the bits and we still do magic in the > new error path? Does that adversely affect any later 'goto done's? I think best leave this patch for now I should probably rethink it slightly, as you say I am not sure all the paths through are correct there. I will post a new version shortly. Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: usbatm: printk_ratelimit() always called in the atm_rldbg()
On Sat, Oct 26, 2013 at 03:29:56PM +0200, Krzysztof Mazur wrote:
> Hi,
>
> commit 2d6401cf4ca3861692a4779745e0049cac769d10
> ("USB: usbatm: move the atm_dbg() call to use dynamic debug")
> changed the atm_rldbg() to:
>
> #define atm_rldbg(instance, format, arg...) \
> if (printk_ratelimit()) \
> atm_dbg(instance , format , ## arg)
>
> and now printk_ratelimit() is always called even when debugging is
> disabled and a lot of "callbacks suppressed" messages are printed
> by the printk_ratelimit():
>
> [...]
> usbatm_rx_process: 4977 callbacks suppressed
> usbatm_extract_one_cell: 2920 callbacks suppressed
> [...]
>
>
> I'm not sure how to fix that, maybe we need dynamic_pr_debug_ratelimit()?
How about just deleting the use of that macro entirely? Odds are it's
not really needed anymore, right?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] perf: add active_entry list head to struct perf_event
On Sat, Oct 26, 2013 at 06:57:37PM +0200, Stephane Eranian wrote:
> On Fri, Oct 25, 2013 at 4:56 PM, Jiri Olsa wrote:
> >
> > On Wed, Oct 23, 2013 at 02:58:02PM +0200, Stephane Eranian wrote:
> > > This patch adds a new fields to the struct perf_event.
> > > It is intended to be used to chain events which are
> > > active (enabled). It helps in the hardware layer
> > > for PMU which do not have actual counter restrictions, i.e.,
> > > free running read-only counters. Active events are chained
> > > as opposed to being tracked via the counter they use.
> > >
> > > Signed-off-by: Stephane Eranian
> > > ---
> > > include/linux/perf_event.h |1 +
> > > kernel/events/core.c |1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index 2e069d1..a376384 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -435,6 +435,7 @@ struct perf_event {
> > > struct perf_cgroup *cgrp; /* cgroup event is attach to
> > > */
> > > int cgrp_defer_enabled;
> > > #endif
> > > + struct list_headactive_entry;
> >
> > Could this be in union with 'hlist_entry' ? It looks
> > as 'same purpose' and 'mutualy exclusive stuff.
> >
> You're saying that I could use the hlist_entry field because
> it is currently only used by the sw events in the generic layer.
> But it seems to be a complicated rcu list for the purpose here.
nope, I just meant saving little space like:
union {
struct list_headactive_entry;
struct hlist_node hlist_entry;
}
just a nitpick
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] perf,x86: add RAPL hrtimer support
On Sat, Oct 26, 2013 at 07:07:06PM +0200, Stephane Eranian wrote:
> On Fri, Oct 25, 2013 at 7:44 PM, Jiri Olsa wrote:
> > On Wed, Oct 23, 2013 at 02:58:05PM +0200, Stephane Eranian wrote:
SNIP
> >> + list_for_each_entry(event, &pmu->active_list, active_entry) {
> >> + rapl_event_update(event);
> >> + }
> >
> > hi,
> > I dont fully understand the reason for the timer,
> > I'm probably missing something..
> >
> The reason is rather simple and is similar to what happens with uncore.
> The counter are narrow, 32-bit and there is no interrupt capability. We
> need to poll the counters and accumulate in the sw counter to avoid missing
> an overflow.
>
> > - the timer calls rapl_event_update for all defined events
>
> No, only for the defined RAPL events which is what we want.
ok, that's what I meant
>
> > - but rapl_pmu_event_read calls rapl_event_update any time the
> > event is read (sys_read)
> >
> Yes, but we want to prevent missing a counter overflow. It may happen
> if the counter counts in a unit which increments fast.
>
> > The rapl_event_update only read msr and updates
> > event->count|hw,prev_count.
> No, it does update the count:
> local64_add(sdelta, &event->count);
ah, there's the shift that takes care of the
overflowed msr value.. ok
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: fix host release issue after discard operation
Under function mmc_blk_issue_rq, after an MMC discard operation,
the MMC request data structure may be freed in memory. Later in
the same function, the check of req->cmd_flags & MMC_REQ_SPECIAL_MASK
is dangerous and invalid. It causes the MMC host not to be released
when it should
This patch fixes the issue by marking the special request down before
the discard/flush operation
Reported by: Harold (SoonYeal) Yang
Signed-off-by: Ray Jui
Reviewed-by: Seungwon Jeon
---
drivers/mmc/card/block.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1a3163f..4e8212c 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1959,6 +1959,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
struct mmc_card *card = md->queue.card;
struct mmc_host *host = card->host;
unsigned long flags;
+ unsigned int cmd_flags = req ? req->cmd_flags : 0;
if (req && !mq->mqrq_prev->req)
/* claim host only for the first request */
@@ -1974,7 +1975,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
}
mq->flags &= ~MMC_QUEUE_NEW_REQUEST;
- if (req && req->cmd_flags & REQ_DISCARD) {
+ if (cmd_flags & REQ_DISCARD) {
/* complete ongoing async transfer before issuing discard */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
@@ -1983,7 +1984,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
ret = mmc_blk_issue_secdiscard_rq(mq, req);
else
ret = mmc_blk_issue_discard_rq(mq, req);
- } else if (req && req->cmd_flags & REQ_FLUSH) {
+ } else if (cmd_flags & REQ_FLUSH) {
/* complete ongoing async transfer before issuing flush */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
@@ -1999,7 +2000,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
out:
if ((!req && !(mq->flags & MMC_QUEUE_NEW_REQUEST)) ||
-(req && (req->cmd_flags & MMC_REQ_SPECIAL_MASK)))
+(cmd_flags & MMC_REQ_SPECIAL_MASK))
/*
* Release host when there are no more requests
* and after special request(discard, flush) is done.
--
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/
[GIT PULL] target fixes for v3.12-rc7
Hello Linus! Here are the outstanding target pending fixes for v3.12-rc7. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master It includes a number of EXTENDED_COPY related fixes as a result of Thomas and Doug's continuing testing and feedback. Also included is an important vhost/scsi fix that addresses a long standing issue where the 'write' parameter for get_user_pages_fast() was incorrectly set for virtio-scsi WRITEs -> DMA_TO_DEVICE, and not for virtio-scsi READs -> DMA_FROM_DEVICE. This resulted in random userspace segfaults and other unpleasantness on KVM host, and unfortunately has been an issue since the initial merge of vhost/scsi in v3.6. This patch is CC'ed to stable, along with two other less critical items. Thank you, --nab Nicholas Bellinger (7): target: Make target_do_xcopy failures return INVALID_PARAMETER_LIST target: Allow non zero ListID in EXTENDED_COPY parameter list target: Reject EXTENDED_COPY when emulate_3pc is disabled target: Add missing XCOPY I/O operation sense_buffer target: Generate failure for XCOPY I/O with non-zero scsi_status target: Fail XCOPY for non matching source + destination block_size vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter Roland Dreier (2): target: Fix assignment of LUN in tracepoints target: Return an error for WRITE SAME with ANCHOR==1 Vu Pham (1): iser-target: check device before dereferencing its variable Wei Yongjun (1): target/pscsi: fix return value check drivers/infiniband/ulp/isert/ib_isert.c |2 +- drivers/target/target_core_pscsi.c |8 ++-- drivers/target/target_core_sbc.c|5 +++ drivers/target/target_core_xcopy.c | 53 +- drivers/vhost/scsi.c|2 +- include/trace/events/target.h |4 +- 6 files changed, 50 insertions(+), 24 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] fs: nfsd: remove calls to simple_strtoll
On Fri, Oct 25, 2013 at 07:33:12PM -0700, Daniel Walker wrote:
> Signed-off-by: Daniel Walker
> ---
> fs/nfsd/fault_inject.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/fault_inject.c b/fs/nfsd/fault_inject.c
> index d620e7f..41165f0 100644
> --- a/fs/nfsd/fault_inject.c
> +++ b/fs/nfsd/fault_inject.c
> @@ -125,20 +125,24 @@ static ssize_t fault_inject_write(struct file *file,
> const char __user *buf,
> size_t size = min(sizeof(write_buf) - 1, len);
> struct net *net = current->nsproxy->net_ns;
> struct sockaddr_storage sa;
> + int ret = -EFAULT;
> u64 val;
>
> if (copy_from_user(write_buf, buf, size))
> - return -EFAULT;
> + return ret;
> write_buf[size] = '\0';
>
> size = rpc_pton(net, write_buf, size, (struct sockaddr *)&sa,
> sizeof(sa));
> if (size > 0)
> nfsd_inject_set_client(file_inode(file)->i_private, &sa, size);
If we take this branch, don't we end up returning -EFAULT below?
--b.
> else {
> - val = simple_strtoll(write_buf, NULL, 0);
> - nfsd_inject_set(file_inode(file)->i_private, val);
> + ret = kstrtoll(write_buf, 0, &val);
> + if (ret == 0) {
> + nfsd_inject_set(file_inode(file)->i_private, val);
> + ret = len;
> + }
> }
> - return len; /* on success, claim we got the whole input */
> + return ret; /* on success, claim we got the whole input */
> }
>
> static const struct file_operations fops_nfsd = {
> --
> 1.8.3.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] printk: pr_debug_ratelimited: check state first to reduce "callbacks suppressed" messages
pr_debug_ratelimited should be coded similar to dev_dbg_ratelimited
to reduce the "callbacks suppressed" messages.
Signed-off-by: Joe Perches
---
On Sat, 2013-10-26 at 18:37 +0100, Greg Kroah-Hartman wrote:
> On Sat, Oct 26, 2013 at 03:29:56PM +0200, Krzysztof Mazur wrote:
> > Hi,
> >
> > commit 2d6401cf4ca3861692a4779745e0049cac769d10
> > ("USB: usbatm: move the atm_dbg() call to use dynamic debug")
> > changed the atm_rldbg() to:
> >
> > #define atm_rldbg(instance, format, arg...) \
> > if (printk_ratelimit()) \
> > atm_dbg(instance , format , ## arg)
> >
> > and now printk_ratelimit() is always called even when debugging is
> > disabled and a lot of "callbacks suppressed" messages are printed
> > by the printk_ratelimit():
> >
> > [...]
> > usbatm_rx_process: 4977 callbacks suppressed
> > usbatm_extract_one_cell: 2920 callbacks suppressed
> > [...]
> >
> >
> > I'm not sure how to fix that, maybe we need dynamic_pr_debug_ratelimit()?
>
> How about just deleting the use of that macro entirely? Odds are it's
> not really needed anymore, right?
include/linux/printk.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e6131a78..449d924 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -343,7 +343,19 @@ extern asmlinkage void dump_stack(void) __cold;
#endif
/* If you are writing a driver, please use dev_dbg instead */
-#if defined(DEBUG)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+/* descriptor check is first to prevent flooding with "callbacks suppressed" */
+#define pr_debug_ratelimited(dev, fmt, ...)\
+do { \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT) &&\
+ __ratelimit(&_rs)) \
+ __dynamic_pr_debug(fmt, ##__VA_ARGS__); \
+} while (0)
+#elif defined(DEBUG)
#define pr_debug_ratelimited(fmt, ...) \
printk_ratelimited(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Add missing data.h into LIB_H headers
On Wed, Oct 23, 2013 at 09:34:36AM +0300, Adrian Hunter wrote: > On 15/10/13 17:27, Jiri Olsa wrote: > > Adding perf_data_file__open interface to data object > > to open the perf.data file for both read and write. > > > > Signed-off-by: Jiri Olsa > > Cc: Corey Ashford > > Cc: Frederic Weisbecker > > Cc: Ingo Molnar > > Cc: Namhyung Kim > > Cc: Paul Mackerras > > Cc: Peter Zijlstra > > Cc: Arnaldo Carvalho de Melo > > Cc: David Ahern > > Cc: Adrian Hunter > > Cc: Andi Kleen > > --- > > tools/perf/Makefile.perf| 1 + > > tools/perf/builtin-record.c | 34 + > > tools/perf/builtin-top.c| 9 +--- > > tools/perf/util/data.c | 120 > > > > tools/perf/util/data.h | 4 ++ > > tools/perf/util/session.c | 95 +++ > > tools/perf/util/session.h | 2 +- > > 7 files changed, 158 insertions(+), 107 deletions(-) > > create mode 100644 tools/perf/util/data.c > > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf > > index c873e03..326a26e 100644 > > --- a/tools/perf/Makefile.perf > > +++ b/tools/perf/Makefile.perf > > @@ -365,6 +365,7 @@ LIB_OBJS += $(OUTPUT)util/vdso.o > > LIB_OBJS += $(OUTPUT)util/stat.o > > LIB_OBJS += $(OUTPUT)util/record.o > > LIB_OBJS += $(OUTPUT)util/srcline.o > > +LIB_OBJS += $(OUTPUT)util/data.o > > Also needs: > > LIB_H += util/data.h > oops, I knew I forgot something.. patch is attached thanks, jirka --- Adding missing data.h into LIB_H headers so the build could keep up with its changes. Reported-by: Adrian Hunter Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Andi Kleen Cc: Adrian Hunter --- tools/perf/Makefile.perf | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 8a9ca38..bc7cfa1 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -295,6 +295,7 @@ LIB_H += ui/helpline.h LIB_H += ui/progress.h LIB_H += ui/util.h LIB_H += ui/ui.h +LIB_H += util/data.h LIB_OBJS += $(OUTPUT)util/abspath.o LIB_OBJS += $(OUTPUT)util/alias.o -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
