Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Tue, Jul 16, 2013 at 08:51:36PM -0400, Steven Rostedt wrote: > On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote: > > > Another thing might deviated from the main theme, but I'd like to raise it > > here because I would like to see what's the proper way for that. > > > > For instance, people A posted a patch set to the mailing list at first, > > people B think that there are some issues in A's implementation, and he > > happened to play around the same stuff recently, so he submitted another > > patch series. Finally, people B made it. > > (In that period, people A kept silent, maybe because he/she was unhappy) > > > > This is a actual occurrence I once observed from a subsystem list(my > > apologies, I just want to talk this case rather than against somebody), > > it seems people A is a new comer(because I can not searched any past > > commits of him/her from the git log), people B is definitely a senior guy. > > > > So that's my question, is that a proper collaboration form in kernel > > community? Does it better if people B could give some suggestions to > > help A to improve the code, especially if those help would help A stepping > > into the kernel development -- maybe it's depend largely on one's opinion. > > :( > > This is a completely different issue from the one in this thread, but it > is also a legitimate issue and honestly, a bigger one than perceived > insults. > > Is it proper collaboration? Absolutely not. Something that I try to be > sensitive to as it's something I can do as well. There's been things on > my todo list, where someone would send me patches that do it. I would be > thinking "darn it, I wanted to do it" and even worse, the patches that > were sent wouldn't be of the way I wanted them. But I've tried to be > good, and instead of just going about and implementing it myself, I > would try to help the person massage the patches into what I wanted. > That takes a lot of effort and discipline, and honestly, helping someone > else do the work you wanted is much harder than just doing it yourself. > > Sometimes the maintainer just takes the easier route, and does the work > themselves (because it's also more fun too). But that's really a slap in > the face of the person that submitted the work in the first place. If > anything hurts the community, it's this behavior. Not Linus giving > someone an ass wipe. I'm used to practice a workaround for this issue on another project. When a newcomer sends me wrong code trying to address a real issue, I first spend a little time helping him/her. If I see that the gap is too large for him/her to adapt his/her work without too much help from me, then I do the work myself, propose to him/her and once it's OK, and ask him/her to submit the work with his/her name. That way they quickly gain trust in themselves, more easily feel part of the community and get a clearer idea of what is needed. Generally patches quality significantly improves with this, in very short time, because they realize the gap is huge and that they won't get this chance often. My principle is to value the effort more than the result. If the first author spent one week digging into the code to identify an issue and came up with the wrong fix, and I can fix it in 5 minutes, he certainly deserves all the merits for the work, not me. I don't believe this is that much practiced on LKML. I know at least one developer who does this, but he's probably the exception. I more often see counter proposals just as if two authors were fighting to get their patch merged. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: splice vs execve lockdep trace.
On Tue, Jul 16, 2013 at 09:54:09PM -0700, Linus Torvalds wrote: > On Tue, Jul 16, 2013 at 9:06 PM, Dave Chinner wrote: > > > > Right, and that's one of the biggest problems page based IO has - we > > can't serialise it against other IO and other page cache > > manipulation functions like hole punching. What happens when a > > splice read or mmap page fault races with a hole punch? You get > > stale data being left in the page cache because we can't serialise > > the page read with the page cache invalidation and underlying extent > > removal. > > But Dave, that's *good*. > > You call it "stale data". > > I call it "the data was valid at some point". Yes, that's true. But When i say "stale data" I mean that the data being returned might not have originally belonged to the underlying file you are reading. > This is what "splice()" is fundamentally all about. > > Think of it this way: even if you are 100% serialized during the > "splice()" operation, what do you think happens afterwards? Same as for read(2) - I don't care. Indeed, the locking is not to protect what splice does "afterwards". It's for IO serialisation, not page cache serialisation. For example, splice read races with hole punch - after the page is invalidated, but before the blocks are punched out. So we get a new page, a mapping from the inode, get_blocks() returns valid disk mapping, we start an IO. it gets blocked in the elevator. Maybe it's been throttled because the process has used it's blkio quota. Whatever - the IO gets stuck on the dispatch queue. Meanwhile, the holepunch runs the transaction to free the disk blocks, and then something else reallocates those blocks - maybe even the filesystem for new metadata. That then gets dispatched to disk. We now have two IOs pending for the same disk blocks What that means is that what the splice read returns is undefined. It *might* be the original data that belonged to the file, in which case we are good to go, but if the write wins the IO race then the splice read could return someone else's data or even filesystem metadata - that's what "stale data" means. Any way you look at it, that's a bad thing > Seriously, think it through. I have ;) > That data is in a kernel buffer - the pipe. The fact that it was > serialized at the time of the original splice() doesn't make _one_ > whit of a difference, because after the splice is over, the data still > sits around in that pipe buffer, and you're no longer serializing it. > Somebody else truncating the file or punching a hole in the file DOES > NOT MATTER. It's too late. Yes, I agree that once we have a page with valid data in it, we don't need serialisation for splice. Again, I'll stress that he serialisation is not for splice page cache manipulations but for the IO that splice may issue to initialise the pages it them manipulates Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: udc: add gadget state kobject uevent
Hi Greg, On Tue, Jul 16, 2013 at 2:31 PM, Greg KH wrote: > On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: >> Hi Greg, >> >> The USB on our platform can change roles between HOST and GADGET, but >> it is not capable of OTG. > > That kind of sounds like the definition of OTG :) Yes. But it just initiates its role according to the ID pin status. > >> When the USB changes between roles the udev will run some scripts >> automatically according to the udev rules. > > What exactly does udev/userspace see when the roles change? > Take HOST -> GADGET for example, the driver removes the USB hcd first, ACTION=remove DEVPATH=/devices/axi.0/uus-iobg.13/b801.usbcontroller/ci_hdrc.0/usb1/1-0:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=1d6b/2/310 TYPE=9/0/1 INTERFACE=9/0/0 MODALIAS=usb:v1D6Bp0002d0310dc09dsc00dp01ic09isc00ip00in00 SEQNUM=1843 Then it initiates the GADGET role which will call usb_add_gadget_udc ACTION=add DEVPATH=/devices/axi.0/uus-iobg.13/b801.usbcontroller/ci_hdrc.0/udc/ci_hdrc.0 SUBSYSTEM=udc USB_UDC_NAME=ci13xxx_sirf SEQNUM=1845 At this time, the udev finds this matches the rule and it will install g_mass_storage.ko. But we are actually not connecting to a PC now, so we do not umount the back-end file storage on our device. Currently the udc framework introduces an API usb_gadget_set_state to report to user-space the USB device state. But it's not compatible with udev. It needs user-space utility polling the "status" file under /sys. And it cannot be called in interrupt context but drivers do the state change in interrupt service routine. What's more, I grep the USB driver and find few driver apply this API except the udc core. But it just initiated its state as "NOT ATTACHED" when registering a new udc. In my opinion, the USB device state change is a common operation and it should be implemented by driver framework. The best place to do this is when composite framework handling standard USB requests. But it's not implemented yet. So we are not informed the USB state until the role changes again. We do not know when to secure the back-end file between our device and the host PC. > And what can trigger the change in roles? The role changes according to the ID pin status. When we plug in a mini-A (ID pin connects to ground) it will cause a ID pin interrupt and we will change to HOST role. If the ID pin connects to nothing we will act as GADGET. In a sum, role change takes place when we plug in different USB connectors. > >> The default role is GADGET, and we bind the g_mass_storage to the USB >> GADGET role. >> >> We should secure the back end file storage between the device and the >> host PC connecting to our device. >> We need to know when the GADGET is really connect to a host PC, then >> we can umount the file on the device >> and export it to the g_mass_storage. > > I thought you already get an event for this, otherwise no one would be > able to properly deal with this. Yes. We install file storage module on this event but we do not get further notice as mentioned above. > >> The question is since we default GADGET, so the g_mass_storage.ko is >> installed early but connecting to a host PC >> is randomly, But the udev has no idea when a host PC connects our device. >> >> So we consider it's reasonable to let the udev know the GADGET device state. >> Is there any alternative to our question? > > I thought we already export events for gadget device states, have you > looked for them? I can't dig through the code at the moment, but this > seems like a pretty common issue... > > Felipe, any ideas? > > 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 RFC] allow some kernel filesystems to be mounted in a user namespace
"Serge E. Hallyn" writes: > I'm not "relying on LSM" to make these safe. I'm relying on the > uid mappings to make these safe. > > Nevertheless I at least have hope of working around the others (in a > distro-acceptable way), so if the others are too scary I'll pursue > the workaround for the others and see where I get. But I really feel > the securityfs one is the best solution. Personally I don't trust debugfs enough to compile it into my kernel. fuse simply isn't ready to be have fresh mounts usefully created inside a user namespace. Fundamentally with debugfs and securityfs you run into the issue we saw with sysfs and proc where at some level it is the system administrators perogative if those filesystems should be mounted. The rule with filesystems like that is mounting them needs to be no more dangerous than bind mounting them. At the point in the cycle you are talking about mounting them you presumably have already thrown away their original mounts making it impossible to tell if it would have been safe to mount them or not. Making your patch completely inappropriate. What you need to do is at container setup time to bind mount those filesystems if they are already mounted and you want them in the container. If you are just shuffling around something you can already see there are no security issues. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: pinmux: Don't free pins requested by other devices
From: Sonic Zhang in pinmux_disable_setting after current device fails to request the same pins. Signed-off-by: Sonic Zhang --- drivers/pinctrl/pinmux.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c index 88cc509..9ebcf3b 100644 --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -482,13 +482,14 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting) pins[i]); continue; } + /* And release the pins */ + if (desc->mux_usecount && + !strcmp(desc->mux_owner, setting->dev_name)) + pin_free(pctldev, pins[i], NULL); + desc->mux_setting = NULL; } - /* And release the pins */ - for (i = 0; i < num_pins; i++) - pin_free(pctldev, pins[i], NULL); - if (ops->disable) ops->disable(pctldev, setting->data.mux.func, setting->data.mux.group); } -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION 3.10.1] System does not wake up from suspend
On Wed, Jul 17, 2013 at 10:27:15AM +0530, Srivatsa S. Bhat wrote: > On 07/17/2013 08:27 AM, Sören Brinkmann wrote: > > On Mon, Jul 15, 2013 at 12:20:19PM +0530, Srivatsa S. Bhat wrote: > >> On 07/15/2013 10:24 AM, Willy Tarreau wrote: > >>> On Sun, Jul 14, 2013 at 09:36:25PM -0700, Sören Brinkmann wrote: > Hi Greg, > > since upgrading to 3.10.1 I find my system not waking up from suspend > from time to time. Unfortunately, I couldn't figure out how to reliably > reproduce the issue. Sometimes it works just fine. > > All I know so far: > On 3.10 I had my system completely freezing a few times. But that did > not seem to be related to suspend/resume. I never experienced the > behavior described below on 3.10. > > On 3.10.1 I hit this bug a few times, that my system did not wake up. > I.e. the screen stayed black and the power LED kept flashing. But > nothing brought the system back up and I had to longpress power to reset > the system. > I had none of the system freezes like the ones described above anymore. > >>> > >>> Fortunately, 3.10.1 is very small. The only patch it contains which is > >>> related to suspend is 18/19 (cpufreq ondemand governor). Maybe you're > >>> having a problem with cpufreq on this machine in fact. > >>> > >>> You may want to try to force it to performance mode or powersave mode > >>> and try for a while, it is possible that both 3.10 and 3.10.1 will work > >>> fine. > >>> > >> > >> Or, you could try applying the patch shown below on top of 3.10.1 and > >> see if it fixes the suspend/resume regression for you. > >> > >> https://lkml.org/lkml/2013/7/11/661 > >> > >> (Just apply patch 1, not the entire patchset). > > So, this didn't end well. With that patch applied I end up in a kernel > > panic on suspend, reproducible - well two out of two is a small test set, > > but anyway. Unfortunately too late to get any information about it > > and my logs don't show anything either. But it's seems worse than the > > rather occasional hangs on resume on the vanilla 3.10.1 kernel. > > > > Kernel panic? Weird.. I suspect something _else_ is wrong. I suggest trying > out the following: > > 1. My patches only touch cpufreq. So completely turn off cpufreq by setting >CONFIG_CPU_FREQ=n. Then try suspend/resume and see how it goes. If it >fails, that shows that something _else_ is wrong and you can try a git >bisect for that. I changed my config like shown below. That one has a two out of two success rate for suspend/resume so far. > >However, if suspend/resume succeeds with CONFIG_CPU_FREQ=n, then try out >step 2 below. > > 2. Apply patch 1 (not the entire patchset) >https://lkml.org/lkml/2013/7/11/661 That's the one I already have in my tree > >On top of that, apply this patch: >https://patchwork.kernel.org/patch/2827512/ This one does not apply. I'll see if I can make it apply. > > >And then try suspend/resume with cpufreq turned on CONFIG_CPU_FREQ=y >(and turning on other cpufreq Kconfig options which are of interest to > you). > > > That should help us narrow down whether the suspend/resume issue is really > related to cpufreq or not. Config diff: --- /boot/config-3.10.1-custom-1-g14bc9ec 2013-07-15 19:26:02.0 -0700 +++ /boot/config-3.10.1-no_cpufreq-1-g14bc9ec 2013-07-16 22:21:22.0 -0700 @@ -48,7 +48,7 @@ # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" -CONFIG_LOCALVERSION="-custom" +CONFIG_LOCALVERSION="-no_cpufreq" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y @@ -538,36 +538,7 @@ # # CPU Frequency scaling # -CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_TABLE=y -CONFIG_CPU_FREQ_GOV_COMMON=y -CONFIG_CPU_FREQ_STAT=y -CONFIG_CPU_FREQ_STAT_DETAILS=y -# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set -# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set -# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y -# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set -CONFIG_CPU_FREQ_GOV_PERFORMANCE=y -CONFIG_CPU_FREQ_GOV_POWERSAVE=y -CONFIG_CPU_FREQ_GOV_USERSPACE=y -CONFIG_CPU_FREQ_GOV_ONDEMAND=y -CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y - -# -# x86 CPU frequency scaling drivers -# -# CONFIG_X86_INTEL_PSTATE is not set -# CONFIG_X86_PCC_CPUFREQ is not set -CONFIG_X86_ACPI_CPUFREQ=y -# CONFIG_X86_POWERNOW_K8 is not set -CONFIG_X86_SPEEDSTEP_CENTRINO=y -# CONFIG_X86_P4_CLOCKMOD is not set - -# -# shared options -# -# CONFIG_X86_SPEEDSTEP_LIB is not set +# CONFIG_CPU_FREQ is not set CONFIG_CPU_IDLE=y # CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set CONFIG_CPU_IDLE_GOV_LADDER=y @@ -2911,7 +2882,6 @@ # CONFIG_THERMAL_GOV_FAIR_SHARE is not set CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_USER_SPACE=y -CONFIG_CPU_THERMAL=y # CONFIG_THERMAL_EMULATION is not set # CONFIG_INTEL_POWERCLAMP is not set CONFIG_WATCHDOG=y Sören pgpud_X2LEbn_.pgp
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, Jul 16, 2013 at 10:22:38PM -0700, Darren Hart wrote: > On Tue, 2013-07-16 at 21:48 -0700, Linus Torvalds wrote: > > > Guys, I love my job. The kernel developer community is great. But I > > suspect that some of you don't necessarily think about the other side. > > I had slashdot discussing my abusive relationship with my wife and > > kids thanks to Sarah's comments. Talk about having a thick skin - > > trust me when I tell you that I get as well as I give out. > > That's awful. People suck. I stopped reading slashdot years ago for the > quality of the content and commentary, apparently it has not improved. Slashdot, Hacker News, and Reddit are all cesspools. I would much rather discuss this topic on LKML or at KS than wade through that muck. Bah, let's settle this at KS, away from the court of public opinion. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/7] cpufreq: Add boost frequency support in core
On 16 July 2013 17:36, Lukasz Majewski wrote: > On Tue, 16 Jul 2013 15:11:54 +0530 Viresh Kumar viresh.ku...@linaro.org > wrote, >> On 4 July 2013 14:20, Lukasz Majewski wrote: >> > +void cpufreq_set_boost_enabled(int state) > [*] > >> >> Maybe cpufreq_block_boost? As suggested by Rafael. > > What do you mean by cpufreq_block_boost()? This name would reverse the > logic. > > Function [*] is used to change boost_enabled static flag (defined at > cpufreq.c file) state according to acpi-cpufreq.c boost support status. I misread it again :( So, what about adding another field in struct cpufreq_driver: boost_enabled? And get rid of the global boost_enabled we have used? Similar to how boost_supported is used, then we don't need this routine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/7] cpufreq:boost:Kconfig: Enable software managed BOOST support at Kconfig
On 16 July 2013 17:20, Lukasz Majewski wrote: > On Tue, 16 Jul 2013 15:28:40 +0530 Viresh Kumar viresh.ku...@linaro.org > wrote, >> On 4 July 2013 14:20, Lukasz Majewski wrote: >> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig >> >> > +config CPU_FREQ_BOOST_SW >> > + bool "CPU frequency overclocking (BOOST)" >> >> Name it "CPU Frequency Overclocking - Software" > > Thanks, I had a puzzle to came up with a good short name :-). > >> >> > + depends on ARM_EXYNOS_CPUFREQ && EXYNOS_THERMAL > [*] >> >> Remote Exynos from here. If you want to enable it for your platform by >> default, then select it from EXYNOS. I misread it a bit. I wanted to say make it dependent only on THERMAL and not on Exynos. > The purpose of the condition [*] here is to prevent from enabling > boost when thermal for Exynos is not supported. Why? Can't others use it? Its not exynos specific :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] hyperv: Fix the NETIF_F_SG flag setting in netvsc
SG mode is not currently supported by netvsc, so remove this flag for now. Otherwise, it will be unconditionally enabled by commit ec5f0615642 "Kill link between CSUM and SG features" Previously, the SG feature is disabled because CSUM is not set here. Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan --- drivers/net/hyperv/netvsc_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 4dccead..23a0fff 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -431,8 +431,8 @@ static int netvsc_probe(struct hv_device *dev, net->netdev_ops = _ops; /* TODO: Add GSO and Checksum offload */ - net->hw_features = NETIF_F_SG; - net->features = NETIF_F_SG | NETIF_F_HW_VLAN_CTAG_TX; + net->hw_features = 0; + net->features = NETIF_F_HW_VLAN_CTAG_TX; SET_ETHTOOL_OPS(net, _ops); SET_NETDEV_DEV(net, >device); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/19] 3.10.1-stable review
On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote: > I react very strongly when somebody argues against fixing regressions. > Let's just say that there's too many years of baggage that I carry > around on that issue.. > > So that is definitely one of the things that make me go ballistic. > Buggy code isn't actually one of them. Bugs happen. Even really stupid > bugs happen, and happen to good people. They had a bad day, or it was > just a brainfart. Not that I will be _polite_ about bad code, mind > you, and there might be some bad words in there, but it doesn't make > me blow up. > > Being cavalier about known regressions is definitely the primary > trigger. I suspect there are others, but I can't seem to recall any > other particular hot-button issues right now. Maybe Sarah can post a > few more pointers.. Hmm... The only thing I can think of off the top of my head is that you tend to hate it when someone puts the needs of their particular architecture or distro at a higher priority than the needs of the kernel community. If they start to push crap code late in the merge window to further their personal goals, you tend to blow up at them. See the 'deep throat' comment on the PE binary signing thread, for instance. The timing of when incidents happen also seems to effect whether you get triggered. I suspect most of the incidents of you "blowing up" at people happen during the merge window. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/7] Documentation:cpufreq:boost: Update BOOST documentation
On 16 July 2013 17:03, Lukasz Majewski wrote: > As fair as I've understood our previous discussion (at [*]) we have > agreed about this. We only export boost attribute when it is supported > by cpufreq_driver. Rafael was very clear about exporting boost > attribute: > > "Simple: Export it only when supported." > > [*]: Re: [PATCH v4 2/7] cpufreq: Add boost frequency support in core I don't want to search in the Archives but I am sure what we decided earlier. Rafael Said: "Simple: Export it only when supported." AND "Don't change behavior of acpi-cpufreq driver" If you see acpi-cpufreq driver carefully, it always creates "boost" sysfs entry. If its not supported then it creates a read only entry. So, please preserve that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 13/18] mm: numa: Scan pages with elevated page_mapcount
On 07/15/2013 11:20 PM, Mel Gorman wrote:
Currently automatic NUMA balancing is unable to distinguish between false
shared versus private pages except by ignoring pages with an elevated
What's the meaning of false shared?
page_mapcount entirely. This avoids shared pages bouncing between the
nodes whose task is using them but that is ignored quite a lot of data.
This patch kicks away the training wheels in preparation for adding support
for identifying shared/private pages is now in place. The ordering is so
that the impact of the shared/private detection can be easily measured. Note
that the patch does not migrate shared, file-backed within vmas marked
VM_EXEC as these are generally shared library pages. Migrating such pages
is not beneficial as there is an expectation they are read-shared between
caches and iTLB and iCache pressure is generally low.
Signed-off-by: Mel Gorman
---
include/linux/migrate.h | 7 ---
mm/memory.c | 7 ++-
mm/migrate.c| 17 ++---
mm/mprotect.c | 4 +---
4 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index a405d3dc..e7e26af 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -92,11 +92,12 @@ static inline int migrate_huge_page_move_mapping(struct
address_space *mapping,
#endif /* CONFIG_MIGRATION */
#ifdef CONFIG_NUMA_BALANCING
-extern int migrate_misplaced_page(struct page *page, int node);
-extern int migrate_misplaced_page(struct page *page, int node);
+extern int migrate_misplaced_page(struct page *page,
+ struct vm_area_struct *vma, int node);
extern bool migrate_ratelimited(int node);
#else
-static inline int migrate_misplaced_page(struct page *page, int node)
+static inline int migrate_misplaced_page(struct page *page,
+struct vm_area_struct *vma, int node)
{
return -EAGAIN; /* can't migrate now */
}
diff --git a/mm/memory.c b/mm/memory.c
index ab933be..62ae8a7 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3586,7 +3586,7 @@ int do_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
}
/* Migrate to the requested node */
- migrated = migrate_misplaced_page(page, target_nid);
+ migrated = migrate_misplaced_page(page, vma, target_nid);
if (migrated)
current_nid = target_nid;
@@ -3651,9 +3651,6 @@ static int do_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct *vma,
page = vm_normal_page(vma, addr, pteval);
if (unlikely(!page))
continue;
- /* only check non-shared pages */
- if (unlikely(page_mapcount(page) != 1))
- continue;
/*
* Note that the NUMA fault is later accounted to either
@@ -3671,7 +3668,7 @@ static int do_pmd_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
/* Migrate to the requested node */
pte_unmap_unlock(pte, ptl);
- migrated = migrate_misplaced_page(page, target_nid);
+ migrated = migrate_misplaced_page(page, vma, target_nid);
if (migrated)
curr_nid = target_nid;
task_numa_fault(last_nid, curr_nid, 1, migrated);
diff --git a/mm/migrate.c b/mm/migrate.c
index 3bbaf5d..23f8122 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1579,7 +1579,8 @@ int numamigrate_isolate_page(pg_data_t *pgdat, struct
page *page)
* node. Caller is expected to have an elevated reference count on
* the page that will be dropped by this function before returning.
*/
-int migrate_misplaced_page(struct page *page, int node)
+int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma,
+ int node)
{
pg_data_t *pgdat = NODE_DATA(node);
int isolated;
@@ -1587,10 +1588,11 @@ int migrate_misplaced_page(struct page *page, int node)
LIST_HEAD(migratepages);
/*
-* Don't migrate pages that are mapped in multiple processes.
-* TODO: Handle false sharing detection instead of this hammer
+* Don't migrate file pages that are mapped in multiple processes
+* with execute permissions as they are probably shared libraries.
*/
- if (page_mapcount(page) != 1)
+ if (page_mapcount(page) != 1 && page_is_file_cache(page) &&
+ (vma->vm_flags & VM_EXEC))
goto out;
/*
@@ -1641,13 +1643,6 @@ int migrate_misplaced_transhuge_page(struct mm_struct
*mm,
int page_lru = page_is_file_cache(page);
/*
-* Don't migrate pages that are mapped in multiple processes.
-* TODO: Handle false sharing detection instead of this hammer
-*/
- if (page_mapcount(page) != 1)
- goto out_dropref;
-
- /*
* Rate-limit the amount of data
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, 2013-07-16 at 21:48 -0700, Linus Torvalds wrote: > Guys, I love my job. The kernel developer community is great. But I > suspect that some of you don't necessarily think about the other side. > I had slashdot discussing my abusive relationship with my wife and > kids thanks to Sarah's comments. Talk about having a thick skin - > trust me when I tell you that I get as well as I give out. That's awful. People suck. I stopped reading slashdot years ago for the quality of the content and commentary, apparently it has not improved. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux 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: [RFC PATCH 05/10] alpha: Primitive support for CPU power down.
On Tue, Jul 16, 2013 at 10:34 AM, Richard Henderson wrote:
> Use WTINT to wait for the next interrupt. Squash the WTINT call
> if the PALcode doesn't support it (e.g. MILO). No attempt is yet
> made to skip clock ticks during normal scheduling in order to stay
> in power down mode longer.
The architecture reference manual says
> The counter, PCC, may increment at a lower rate or may stop entirely
> during wtint execution. This side effect is implementation dependent.
Is that anything to worry about?
>
> Signed-off-by: Richard Henderson
> ---
> arch/alpha/include/asm/pal.h | 1 +
> arch/alpha/include/uapi/asm/pal.h | 1 +
> arch/alpha/kernel/process.c | 15 +++
> arch/alpha/kernel/traps.c | 12
> 4 files changed, 29 insertions(+)
>
> diff --git a/arch/alpha/include/asm/pal.h b/arch/alpha/include/asm/pal.h
> index 6fcd2b5..e78ec9b 100644
> --- a/arch/alpha/include/asm/pal.h
> +++ b/arch/alpha/include/asm/pal.h
> @@ -89,6 +89,7 @@ __CALL_PAL_W1(wrmces, unsigned long);
> __CALL_PAL_RW2(wrperfmon, unsigned long, unsigned long, unsigned long);
> __CALL_PAL_W1(wrusp, unsigned long);
> __CALL_PAL_W1(wrvptptr, unsigned long);
> +__CALL_PAL_RW1(wtint, unsigned long, unsigned long);
>
> /*
> * TB routines..
> diff --git a/arch/alpha/include/uapi/asm/pal.h
> b/arch/alpha/include/uapi/asm/pal.h
> index 3c0ce08..dfc8140 100644
> --- a/arch/alpha/include/uapi/asm/pal.h
> +++ b/arch/alpha/include/uapi/asm/pal.h
> @@ -46,6 +46,7 @@
> #define PAL_rdusp 58
> #define PAL_whami 60
> #define PAL_retsys 61
> +#define PAL_wtint 62
> #define PAL_rti63
>
>
> diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
> index f2360a7..3130f13 100644
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -46,6 +46,21 @@
> void (*pm_power_off)(void) = machine_power_off;
> EXPORT_SYMBOL(pm_power_off);
>
> +/*
> + * Sleep the CPU.
> + * EV6, LCA45 and QEMU know how to power down, skipping N timer interrupts.
> + */
> +void arch_cpu_idle(void)
> +{
> + wtint(0);
> + local_irq_enable();
> +}
> +
> +void arch_cpu_idle_dead(void)
> +{
> + wtint(INT_MAX);
> +}
> +
> struct halt_info {
> int mode;
> char *restart_cmd;
> diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> index affccb9..991f6c3 100644
> --- a/arch/alpha/kernel/traps.c
> +++ b/arch/alpha/kernel/traps.c
> @@ -243,6 +243,18 @@ do_entIF(unsigned long type, struct pt_regs *regs)
>(const char *)(data[1] | (long)data[2] << 32),
>data[0]);
> }
> + if (type == 4) {
> + /* If CALL_PAL WTINT is not supported by the PALcode,
> + "emulate" it by overwriting the insn. */
The pseudo-code for WTINT contains an IF(implemented) check, where the
ELSE case just does v0 <- 0. So is overwriting with nop just an
optimization to avoid the (expensive) PAL call? If it is, could we
clarify the comment?
> + unsigned int *pinsn
> + = (unsigned int *) regs->pc - 1;
> + if (*pinsn == PAL_wtint) {
> + *pinsn = 0x47e01400; /* mov 0,$0 */
> + imb();
> + regs->r0 = 0;
> + return;
> + }
> + }
> die_if_kernel((type == 1 ? "Kernel Bug" : "Instruction
> fault"),
> regs, type, NULL);
> }
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator
On 07/12/2013 10:03 AM, Robin Holt wrote: We have been working on this since we returned from shutdown and have something to discuss now. We restricted ourselves to 2MiB initialization to keep the patch set a little smaller and more clear. First, I think I want to propose getting rid of the page flag. If I knew of a concrete way to determine that the page has not been initialized, this patch series would look different. If there is no definitive way to determine that the struct page has been initialized aside from checking the entire page struct is zero, then I think I would suggest we change the page flag to indicate the page has been initialized. The heart of the problem as I see it comes from expand(). We nearly always see a first reference to a struct page which is in the middle of the 2MiB region. Due to that access, the unlikely() check that was originally proposed really ends up referencing a different page entirely. We actually did not introduce an unlikely and refactor the patches to make that unlikely inside a static inline function. Also, given the strong warning at the head of expand(), we did not feel experienced enough to refactor it to make things always reference the 2MiB page first. With this patch, we did boot a 16TiB machine. Without the patches, the v3.10 kernel with the same configuration took 407 seconds for free_all_bootmem. With the patches and operating on 2MiB pages instead of 1GiB, it took 26 seconds so performance was improved. I have no feel for how the 1GiB chunk size will perform. How to test how much time spend on free_all_bootmem? I am on vacation for the next three days so I am sorry in advance for my infrequent or non-existant responses. Signed-off-by: Robin Holt Signed-off-by: Nate Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 2013-07-17 at 00:01 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 16, 2013 05:08:16 PM Matthew Garrett wrote:
> > On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote:
> > > Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we
> > > no longer see switch status of backlight.
> >
> > Yeah, I can duplicate that. Rafael, we have to call
> > acpi_video_init_brightness() even if we're not going to initialise the
> > backlight - Thinkpads seem to use this as the trigger for enabling ACPI
> > notifications rather than handling it in firmware. This seems to do the
> > job:
>
> Igor, does this additional patch from Matthew help?
Yes. With this patch I have backlight switch indicator on my ThinkPad X230.
>
> Rafael
>
>
Tested-by: Igor Gnatenko
> > diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> > index 01b1a25..71865f7 100644
> > --- a/drivers/acpi/video.c
> > +++ b/drivers/acpi/video.c
> > @@ -900,6 +900,9 @@ static void acpi_video_device_find_cap(struct
> > acpi_video_device *device)
> > device->cap._DDC = 1;
> > }
> >
> > + if (acpi_video_init_brightness(device))
> > + return;
> > +
> > if (acpi_video_verify_backlight_support()) {
> > struct backlight_properties props;
> > struct pci_dev *pdev;
> > @@ -909,9 +912,6 @@ static void acpi_video_device_find_cap(struct
> > acpi_video_device *device)
> > static int count = 0;
> > char *name;
> >
> > - result = acpi_video_init_brightness(device);
> > - if (result)
> > - return;
> > name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
> > if (!name)
> > return;
> >
> >
> > --
> > Matthew Garrett | mj...@srcf.ucam.org
> >
--
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.11.0-0.rc0.git7.1.fc20.x86_64
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: (lm90) split set temp as common codes
On Wed, Jul 17, 2013 at 06:26:20AM +0200, Thierry Reding wrote: > On Mon, Jul 15, 2013 at 09:24:15AM +0200, Jean Delvare wrote: > > On Mon, 15 Jul 2013 14:25:29 +0800, Wei Ni wrote: > > > On 07/12/2013 10:40 PM, Guenter Roeck wrote: > > > > On Fri, Jul 12, 2013 at 04:30:34PM +0200, Jean Delvare wrote: > > > >> If that means that for example the ACPI thermal zone is no longer > > > >> displayed by "sensors", then I strongly object - unless it is > > > >> explicitly registered as a separate hwmon device from now on, of > > > >> course. > > > > > > > > If I recall correctly that was the idea. Of course, in practice that > > > > will mean > > > > that devices will _not_ get exposed as hwmon devices, as implementers > > > > won't > > > > bother doing both. > > > > > > > >> My idea was to make the bridge optional - you decide when you register > > > >> a thermal device if it should be exposed as hwmon or not. > > > > > > > > Yes, that would be a much better solution. > > > > > > I think we can decide it in the DT, we can add a dt property in the lm90 > > > device node, such as: > > > sys-interface = SYS_HWMON; > > > or > > > sys-interface = SYS_THERMAL; > > > So we register it as the hwmon or thermal device > > > > This is an option, but please keep in mind that DT is not the only way > > to instantiate LM90-like devices, and we should not expose duplicate > > inputs by default. It is fine with me if the default is to create only a > > HWMON device (as the lm90 driver was doing so far), and only > > DT-instantiated devices have the choice. > > I don't think this information belongs in the device tree. Whether the > device is exposed as hwmon or thermal device (or both) is entirely a > software issue whereas DT is a means to describe the hardware. > Correct; this is exactly the type of information which does _not_ belong int devicetree. > It seems to me that the earlier proposal of communicating to the bridge > whether or not a device should be exposed as hwmon device is the right > thing to do here. > Agreed.. 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 RESEND 2/2] fs/aio: Add support to aio ring pages migration
Hi Ben,
On 07/16/2013 09:34 PM, Benjamin LaHaise wrote:
> On Tue, Jul 16, 2013 at 05:56:16PM +0800, Gu Zheng wrote:
>> As the aio job will pin the ring pages, that will lead to mem migrated
>> failed. In order to fix this problem we use an anon inode to manage the aio
>> ring
>> pages, and setup the migratepage callback in the anon inode's address
>> space, so
>> that when mem migrating the aio ring pages will be moved to other mem node
>> safely.
>
> There are a few minor issues that needed to be fixed -- see below. I've
> made these changes and added them to git://git.kvack.org/~bcrl/aio-next.git ,
> and will ask for that tree to be included in linux-next.
Thanks very much, and your review.
Stephen sent out a build failed msg when merger this patch into next-tree from
your aio_next.
This is because we use migrate_page_move_mapping() which is protected by
CONFIG_MIGRATION, I'll
fix this issue in the next version.
Best regards,
Gu
>
> mm folks: can someone familiar with page migration / hot plug memory please
> review the migration changes?
>
>>
>> Signed-off-by: Gu Zheng
>> Signed-off-by: Benjamin LaHaise
>
> Again, I had not provided my Signed-off-by on this patch previously, so
> don't add it for me.
Sorry again.:)
>
>> ---
>> fs/aio.c| 120
>> ++
>> include/linux/migrate.h |3 +
>> mm/migrate.c|2 +-
>> 3 files changed, 113 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 9b5ca11..d10f956 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -35,6 +35,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>>
>> #include
>> #include
>> @@ -110,6 +113,7 @@ struct kioctx {
>> } cacheline_aligned_in_smp;
>>
>> struct page *internal_pages[AIO_RING_PAGES];
>> +struct file *aio_ring_file;
>> };
>>
>> /*-- sysctl variables*/
>> @@ -138,15 +142,78 @@ __initcall(aio_setup);
>>
>> static void aio_free_ring(struct kioctx *ctx)
>> {
>> -long i;
>> +int i;
>> +struct file *aio_ring_file = ctx->aio_ring_file;
>>
>> -for (i = 0; i < ctx->nr_pages; i++)
>> +for (i = 0; i < ctx->nr_pages; i++) {
>> +pr_debug("pid(%d) [%d] page->count=%d\n", current->pid, i,
>> +page_count(ctx->ring_pages[i]));
>> put_page(ctx->ring_pages[i]);
>> +}
>>
>> if (ctx->ring_pages && ctx->ring_pages != ctx->internal_pages)
>> kfree(ctx->ring_pages);
>> +
>> +if (aio_ring_file) {
>> +truncate_setsize(aio_ring_file->f_inode, 0);
>> +pr_debug("pid(%d) i_nlink=%u d_count=%d d_unhashed=%d
>> i_count=%d\n",
>> +current->pid, aio_ring_file->f_inode->i_nlink,
>> +aio_ring_file->f_path.dentry->d_count,
>> +d_unhashed(aio_ring_file->f_path.dentry),
>> +atomic_read(_ring_file->f_inode->i_count));
>> +fput(aio_ring_file);
>> +ctx->aio_ring_file = NULL;
>> +}
>> +}
>> +
>> +static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> +vma->vm_ops = _file_vm_ops;
>> +return 0;
>> +}
>> +
>> +static const struct file_operations aio_ring_fops = {
>> +.mmap = aio_ring_mmap,
>> +};
>> +
>> +static int aio_set_page_dirty(struct page *page)
>> +{
>> +return 0;
>> }
>>
>> +static int aio_migratepage(struct address_space *mapping, struct page *new,
>> +struct page *old, enum migrate_mode mode)
>> +{
>> +struct kioctx *ctx = mapping->private_data;
>> +unsigned long flags;
>> +unsigned idx = old->index;
>> +int rc;
>> +
>> +/*Writeback must be complete*/
>
> Missing spaces before/after beginning and end of comment.
>
>> +BUG_ON(PageWriteback(old));
>> +put_page(old);
>> +
>> +rc = migrate_page_move_mapping(mapping, new, old, NULL, mode);
>> +if (rc != MIGRATEPAGE_SUCCESS) {
>> +get_page(old);
>> +return rc;
>> +}
>> +
>> +get_page(new);
>> +
>> +spin_lock_irqsave(>completion_lock, flags);
>> +migrate_page_copy(new, old);
>> +ctx->ring_pages[idx] = new;
>> +spin_unlock_irqrestore(>completion_lock, flags);
>> +
>> +return rc;
>> +}
>> +
>> +static const struct address_space_operations aio_ctx_aops = {
>> +.set_page_dirty = aio_set_page_dirty,
>> +.migratepage= aio_migratepage,
>> +};
>> +
>> static int aio_setup_ring(struct kioctx *ctx)
>> {
>> struct aio_ring *ring;
>> @@ -154,20 +221,45 @@ static int aio_setup_ring(struct kioctx *ctx)
>> struct mm_struct *mm = current->mm;
>> unsigned long size, populate;
>> int nr_pages;
>> +int i;
>> +struct file *file;
>>
>> /* Compensate for the ring buffer's head/tail overlap entry */
>> nr_events += 2; /* 1 is required, 2 for good luck */
>>
>> size =
Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos
On Fri, Jun 14, 2013 at 02:38:49PM +0200, Arnd Bergmann wrote: > On Friday 14 June 2013 12:53:11 Thierry Reding wrote: > > > > I think the biggest missing piece is pci_common_exit(), the counterpart > > of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked > > in detail at the other architectures, but I suspect there must be some > > code to call when a host bridge is removed. > > > > Looking at drivers/pci/remove.c, it seems like pci_remove_root_bus() > > might be what we're looking at. It isn't exported so it can't be used by > > modules, but that can be changed. Is that how a host bridge is typically > > removed from the system? > > It's fairly new to have host bridges in loadable modules, so I'm pretty > sure it's not supported by the core yet, but it also doesn't seem hard > to do. I think you are right with regard to pci_remove_root_bus, > and Bjorn might be able to provide more information. > > Ideally we should be able to load and unload the pci host driver > in a loop indefinitely without crashing or exposing any races > or leaks, but I would not bet on that working without bugs in the > core, since that goes beyond the normal pci (device) hotplug case. I've done some preliminary testing on Tegra using sysfs to unbind and rebind the device from and to the driver. Some code needs to be added for this to work, but it doesn't crash and PCI even continues to work after unbinding and rebinding (tested using gigabit ethernet). However I haven't looked for leaks yet, and I'm pretty sure some more code is required to undo some of what pci_common_init() does on ARM. Looking more closely, I think most (if not all) remaining leaks could be fixed by keeping the list of pci_sys_data structures around and cleaning them up properly. Given the experimental nature of this I don't want to make that part of the driver for 3.12 and I've opted to just disable any means of removing the driver for now. But I do want to get back to this after the driver has been merged. Thierry pgpNOQWrrxQJ3.pgp Description: PGP signature
Re: [PATCH 0/8] Cpufreq, cpu hotplug, suspend/resume related fixes
On 07/17/2013 03:02 AM, Rafael J. Wysocki wrote: > On Tuesday, July 16, 2013 05:15:14 PM Toralf Förster wrote: >> On 07/12/2013 12:23 AM, Srivatsa S. Bhat wrote: >>> On 07/12/2013 04:03 AM, Rafael J. Wysocki wrote: On Friday, July 12, 2013 03:45:17 AM Srivatsa S. Bhat wrote: > > Hi, Hi, > Commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) caused > some subtle regressions in the cpufreq subsystem during suspend/resume. > This patchset is aimed at rectifying those problems, by fixing the > regression > as well as achieving the original goal of that commit in a proper way. > > Patch 1 reverts the above commit, and is CC'ed to stable. > > Patches 2 - 5 reorganize the code and have no functional impact, and can > go > in as general cleanups as well. This reorganization builds a base that the > rest of the patches will make use of. > > Patch 6 and 7 add a mechanism to perform light-weight init/tear-down of > CPUs > in the cpufreq subsystem and finally patch 8 uses it to preserve sysfs > files > across suspend/resume. > > All the patches apply on current mainline. > > > Robert, Durgadoss, it would be great if you could try it out and see if > it works > well for your usecase. I tested it locally and cpufreq related files did > retain > their permissions across suspend/resume. Let me know if it works fine in > your > setup too. > > And I'd of course appreciate to hear from Dirk, Tianyu and Toralf to know > whether their systems work fine after: > a. applying only the first commit (this is what gets backported to stable) > b. applying all the commits > > (Note: I had to use Michael's fix[1] to avoid CPU hotplug deadlock while > testing this patchset. Though that patch also touches cpufreq subsystem, > it > doesn't affect this patchset in any way and there is absolutely no > dependency > between the two in terms of code. That fix just makes basic CPU hotplug > work > without locking up on current mainline). > > [1]. https://lkml.org/lkml/2013/7/10/611 > > > Thank you very much! Thanks Srivatsa! I'm going to take [1/8] for 3.11 and queue up the rest for 3.12 if people don't hate them. This way we'll have some more testing coverage before they reach the mainline hopefully. >> >> On 07/16/2013 01:25 AM, Rafael J. Wysocki wrote:> On Monday, July 15, 2013 >> 07:38:02 PM Toralf Förster wrote: >>> Sorry, I have no idea what 1#8 means. >> >> sry - here again with full quote of the email : >> >> I applied patch [1/8] on top of v3.11-rc1-8-g47188d3 passes two s2ram/wakeup >> cycles fine and crashed the system at the 3rd attempt / one times just at >> the 4th (blinking power led, no sysrq, ...). >> >> Applying patch 1-8 on top of that tree differs in that way that it >> crashes now the system even at the 1st attempt or at least at the 2nd >> >> My hardware is a ThinkPad T420 with latest BIOS and a 32 bit stable >> Gentoo Linux - FWIW .config attached. > > I think you'll need the fixes first, basically [1/8] from this series and > this: https://patchwork.kernel.org/patch/2827512/ . > > Please try to run with these two things applied only and see how that goes. > In addition to what Rafael suggested above, also try running your kernel with cpufreq completely turned off (CONFIG_CPU_FREQ=n). My patches touch only cpufreq, so this experiment will tell us if your suspend/resume issues are really related to cpufreq or not. If turning off cpufreq also breaks your suspend/resume, then a fresh git-bisect might be the only way to go. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-net: put virtio net header inline with data
From: "Michael S. Tsirkin" Date: Wed, 17 Jul 2013 08:00:32 +0300 > On Tue, Jul 16, 2013 at 12:33:26PM -0700, David Miller wrote: >> From: Rusty Russell >> Date: Mon, 15 Jul 2013 11:13:25 +0930 >> >> > From: Michael S. Tsirkin >> > >> > For small packets we can simplify xmit processing >> > by linearizing buffers with the header: >> > most packets seem to have enough head room >> > we can use for this purpose. >> > Since existing hypervisors require that header >> > is the first s/g element, we need a feature bit >> > for this. >> > >> > Signed-off-by: Michael S. Tsirkin >> > Signed-off-by: Rusty Russell >> >> I really think this has to wait until the next merge window, sorry. >> >> Please resubmit this when I open net-next back up, thanks. > > I assumed since -rc1 is out net-next is already open? -rc1 being released never makes net-next open. Instead, I explicitly open it up at some point in time after -rc1 when I feel that things have settled down enough. And when that happens, I announce so here. So you have to follow my announcements here on netdev to know when net-next is actually open. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
Hi, I have a missing urb completion problem on ARMv7 based platform. I thought the above problem was caused by coherent memory between the EHCI device and CPU so I tryied to allocates device type memory for EHCI via dma_declare_coherent_memory at machine initialization step so that EHCI always allocates from those device type memory. It seems to solve the issue because I didn't see any problem. But I am not sure it is acceptable solution. So I applied the patch https://lkml.org/lkml/2011/8/31/344. But it could not solve the problem so that I added another wmb() as my patch, and now my platform works fine. I am not sure what's the exact problem and what wmb I added could solve but I just think the problem is related to store buffer flush of hw_next. Anyway, important thing is that it fixed my problem so I expect you expert guys could find what I am missing and a right solution. IMHO, the patch might miss updating hw_next pointer. Am I correct? I understand the wmb() is just memory barrier, not write-buffer flush. But it is true that wmb() can flush write buffer in ARM. Anyhow I think that memory type, "normal memory, non-cacheable", may have a problem for some devices that needs device type memory. I cannot get conclusion from the discussion at https://lkml.org/lkml/2011/8/31/344. Which can I do for my platform, wmb() or dma_coherent_write_sync()? Signed-off-by: Gioh Kim --- drivers/usb/host/ehci-q.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index d34b399..779d9e8 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c @@ -501,6 +501,7 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh) last = list_entry (qtd->qtd_list.prev, struct ehci_qtd, qtd_list); last->hw_next = qtd->hw_next; + wmb(); } /* remove qtd; it's recycled after possible urb completion */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION 3.10.1] System does not wake up from suspend
On 07/17/2013 08:27 AM, Sören Brinkmann wrote: > On Mon, Jul 15, 2013 at 12:20:19PM +0530, Srivatsa S. Bhat wrote: >> On 07/15/2013 10:24 AM, Willy Tarreau wrote: >>> On Sun, Jul 14, 2013 at 09:36:25PM -0700, Sören Brinkmann wrote: Hi Greg, since upgrading to 3.10.1 I find my system not waking up from suspend from time to time. Unfortunately, I couldn't figure out how to reliably reproduce the issue. Sometimes it works just fine. All I know so far: On 3.10 I had my system completely freezing a few times. But that did not seem to be related to suspend/resume. I never experienced the behavior described below on 3.10. On 3.10.1 I hit this bug a few times, that my system did not wake up. I.e. the screen stayed black and the power LED kept flashing. But nothing brought the system back up and I had to longpress power to reset the system. I had none of the system freezes like the ones described above anymore. >>> >>> Fortunately, 3.10.1 is very small. The only patch it contains which is >>> related to suspend is 18/19 (cpufreq ondemand governor). Maybe you're >>> having a problem with cpufreq on this machine in fact. >>> >>> You may want to try to force it to performance mode or powersave mode >>> and try for a while, it is possible that both 3.10 and 3.10.1 will work >>> fine. >>> >> >> Or, you could try applying the patch shown below on top of 3.10.1 and >> see if it fixes the suspend/resume regression for you. >> >> https://lkml.org/lkml/2013/7/11/661 >> >> (Just apply patch 1, not the entire patchset). > So, this didn't end well. With that patch applied I end up in a kernel > panic on suspend, reproducible - well two out of two is a small test set, > but anyway. Unfortunately too late to get any information about it > and my logs don't show anything either. But it's seems worse than the > rather occasional hangs on resume on the vanilla 3.10.1 kernel. > Kernel panic? Weird.. I suspect something _else_ is wrong. I suggest trying out the following: 1. My patches only touch cpufreq. So completely turn off cpufreq by setting CONFIG_CPU_FREQ=n. Then try suspend/resume and see how it goes. If it fails, that shows that something _else_ is wrong and you can try a git bisect for that. However, if suspend/resume succeeds with CONFIG_CPU_FREQ=n, then try out step 2 below. 2. Apply patch 1 (not the entire patchset) https://lkml.org/lkml/2013/7/11/661 On top of that, apply this patch: https://patchwork.kernel.org/patch/2827512/ And then try suspend/resume with cpufreq turned on CONFIG_CPU_FREQ=y (and turning on other cpufreq Kconfig options which are of interest to you). That should help us narrow down whether the suspend/resume issue is really related to cpufreq or not. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-net: put virtio net header inline with data
On Tue, Jul 16, 2013 at 12:33:26PM -0700, David Miller wrote: > From: Rusty Russell > Date: Mon, 15 Jul 2013 11:13:25 +0930 > > > From: Michael S. Tsirkin > > > > For small packets we can simplify xmit processing > > by linearizing buffers with the header: > > most packets seem to have enough head room > > we can use for this purpose. > > Since existing hypervisors require that header > > is the first s/g element, we need a feature bit > > for this. > > > > Signed-off-by: Michael S. Tsirkin > > Signed-off-by: Rusty Russell > > I really think this has to wait until the next merge window, sorry. > > Please resubmit this when I open net-next back up, thanks. I assumed since -rc1 is out net-next is already open? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: tegra: Correct PCIe entry
On Tue, Jun 11, 2013 at 10:30:48AM +0300, Peter De Schrijver wrote: > On Mon, Jun 10, 2013 at 09:55:12PM +0200, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Wed, Jun 05, 2013 at 12:27:31AM +0530, Jay Agarwal wrote: > > [...] > > > @@ -29,7 +29,7 @@ > > > ranges = <0x8200 0 0x 0x 0 0x1000 /* > > > port 0 configuration space */ > > > 0x8200 0 0x1000 0x1000 0 0x1000 /* > > > port 1 configuration space */ > > > 0x8200 0 0x4000 0x4000 0 0x1000 /* > > > port 2 configuration space */ > > > - 0x8100 0 0 0x0200 0 0x0001 /* > > > downstream I/O */ > > > + 0x8100 0 0 0x0200 0 0x0010 /* > > > downstream I/O */ > > > 0x8200 0 0x2000 0x2000 0 0x1000 /* > > > non-prefetchable memory */ > > > 0xc200 0 0x3000 0x3000 0 0x1000>; /* > > > prefetchable memory */ > > > > That increases the I/O region size from 64 KiB to 1 MiB. Why is that > > necessary? I/O operations can only address 64 KiB, so I don't think > > adding more makes any sense. > > At least PCI allows 32bit I/O addresses. No idea if anyone uses them though. I just realized that we are constrained to 64 KiB by the implementation of pci_ioremap_io(), which assumes each mapping is 64 KiB. Not that it couldn't be changed, but unless there actually is a use-case where more than 64 KiB are required I don't think we should worry about it. Thierry pgpwCQfbFFONz.pgp Description: PGP signature
Re: splice vs execve lockdep trace.
On Tue, Jul 16, 2013 at 9:06 PM, Dave Chinner wrote: > > Right, and that's one of the biggest problems page based IO has - we > can't serialise it against other IO and other page cache > manipulation functions like hole punching. What happens when a > splice read or mmap page fault races with a hole punch? You get > stale data being left in the page cache because we can't serialise > the page read with the page cache invalidation and underlying extent > removal. But Dave, that's *good*. You call it "stale data". I call it "the data was valid at some point". This is what "splice()" is fundamentally all about. Think of it this way: even if you are 100% serialized during the "splice()" operation, what do you think happens afterwards? Seriously, think it through. That data is in a kernel buffer - the pipe. The fact that it was serialized at the time of the original splice() doesn't make _one_ whit of a difference, because after the splice is over, the data still sits around in that pipe buffer, and you're no longer serializing it. Somebody else truncating the file or punching a hole in the file DOES NOT MATTER. It's too late. In other words, trying to "protect" against that kind of race is stupid. You're missing the big picture because you're concentrating on the details. Look beyond what happens inside XFS, and think about the higher-level meaning of splice() itself. So the only guarantee splice *should* give is entirely per-page. If you think it gives any other serialization, you're fundamentally wrong, because it *cannot*. See? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: > > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: > > > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote: > > > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > > > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger > > > > >> wrote: > > > > >>> Drilling down the work items ahead of a real mainline push is high > > > > >>> on > > > > >>> priority list for discussion. > > > > >>> > > > > >>> The parties to be included in such a discussion are: > > > > >>> > > > > >>> - Jens Axboe (blk-mq author) > > > > >>> - James Bottomley (scsi maintainer) > > > > >>> - Christoph Hellwig (scsi) > > > > >>> - Martin Petersen (scsi) > > > > >>> - Tejun Heo (block + libata) > > > > >>> - Hannes Reinecke (scsi error recovery) > > > > >>> - Kent Overstreet (block, per-cpu ida) > > > > >>> - Stephen Cameron (scsi-over-pcie driver) > > > > >>> - Andrew Vasquez (qla2xxx LLD) > > > > >>> - James Smart (lpfc LLD) > > > > >> > > > > >> Isn't this something that should have been discussed at the storage > > > > >> mini-summit a few months ago? > > > > > > > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did > > > > > not > > > > > exist a few short months ago. ;) > > > > > > > > > >> It seems very specific to one subsystem to be a kernel summit topic, > > > > >> don't you think? > > > > > > > > > > It's no more subsystem specific than half of the other proposals so > > > > > far, > > > > > and given it's reach across multiple subsystems (block, scsi, target), > > > > > and the amount of off-list interest on the topic, I think it would > > > > > make > > > > > a good candidate for discussion. > > > > > > > > > And it'll open up new approaches which previously were dismissed, > > > > like re-implementing multipathing on top of scsi-mq, giving us the > > > > single scsi device like other UNIX systems. > > > > > > > > Also I do think there's quite some synergy to be had, as with blk-mq > > > > we could nail each queue to a processor, which would eliminate the > > > > need for locking. > > > > Which could be useful for other subsystems, too. > > > > > > Lets start with discussing this on the list, please, and then see where > > > we go from there ... > > > > > > > Yes, the discussion is beginning to make it's way to the list. I've > > mostly been waiting for blk-mq to get a wider review before taking the > > early scsi-mq prototype driver to a larger public audience. > > > > Primarily, I'm now reaching out to the people most effected by existing > > scsi_request_fn() based performance limitations. Most of them have > > abandoned existing scsi_request_fn() based logic in favor of raw block > > make_request() based drivers, and are now estimating the amount of > > effort to move to an scsi-mq based approach. > > > > Regardless, as the prototype progresses over the next months, having a > > face-to-face discussion with the key parties in the room would be very > > helpful given the large amount of effort involved to actually make this > > type of generational shift in SCSI actually happen. > > There's a certain amount of overlap with the aio/O_DIRECT work as well. > But if it's not a general session, could always be a BOF or something. > > I'll second the argument that most technical topics probably DO belong > in a topic related workshop. But that leaves us with basically only > process related topics at KS, I don't think it hurts to have a bit of > tech meat on the bone too. At least I personally miss that part of KS > from years gone by. Heh well, given that most of the block mq discussions at LSF have been you saying you really should get around to cleaning up and posting the code, you'll understand my wanting to see that happen first ... I suppose we could try to run a storage workshop within KS, but I think most of the mini summit slots have already gone. There's also plumbers if all slots are gone (I would say that, being biased and on the programme committee) Ric is running the storage and Filesystems MC http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159 James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, Jul 16, 2013 at 8:16 PM, Ben Hutchings wrote: > On Tue, 2013-07-16 at 20:02 -0700, Linus Torvalds wrote: >> >> Umm. Notice how the "Joseph" I replied to had deleted all the comments he >> wrote? > > Sorry, that completely escaped me. > >> That should tell you something. I smacked down a troll. >> >> If I was polite to you all those years ago, and I was polite but firm >> in the two first responses, please give me credit for when I smack >> somebody down. There may be a reason for it. The fact that the person >> deleted his messages (or github deleted them for him - I have no idea >> what their comment policy is) and you cannot see that context any more >> online should not make you think that I suddenly went crazy. > > Unfortunately, it seems I'm not the only one to be confused by this. Heh. I think this one is a pretty extreme example (because the context simply is no longer *there*), but the fact is, it's not uncommon. People think I get all the credit (and hey, I do), but here's a somewhat darker side to the story too. I get a lot of grief too, and usually from people who don't have the context. In the blog you posted, it was because the context simply wasn't there any more, but let's be honest: even when the context is there, how many people read it? It's a cesspool out there (*cough*slashdot*cough*). And hey, I think Sarah's outburst itself was due to a similar "I know Linus curses at people, and who cares about context, it's never acceptable". Because I guarantee that it was *not* because of the actual email she replied to, or anything I've written her. Feel free to go back and check. I'm really not complaining. It's part of my job, and I'm quite used to it. This is not new. Certain people and places love to hate on Linus, the egotistical ass. And hey, on the whole I can honestly say that I'm *way* ahead. They aren't exactly wrong - it's not like I have a weak ego. I get most annoyed when people say it's "new" and due to the success of Linux. Dammit, I had a strong ego when I started this whole thing, so don't try to chalk it all up to success. Guys, I love my job. The kernel developer community is great. But I suspect that some of you don't necessarily think about the other side. I had slashdot discussing my abusive relationship with my wife and kids thanks to Sarah's comments. Talk about having a thick skin - trust me when I tell you that I get as well as I give out. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci: Correct misplaced newlines
Thanks Joe, I'll apply this to my tree after the merge window closes.
Sarah Sharp
On Tue, Jul 16, 2013 at 07:25:59PM -0700, Joe Perches wrote:
> Logging messages end in newlines, not have
> them put in the middle of messages.
>
> Signed-off-by: Joe Perches
> ---
> drivers/usb/host/xhci.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 2c49f00..87b5e65 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -3075,8 +3075,8 @@ static u32 xhci_calculate_no_streams_bitmask(struct
> xhci_hcd *xhci,
> /* Are streams already being freed for the endpoint? */
> if (ep_state & EP_GETTING_NO_STREAMS) {
> xhci_warn(xhci, "WARN Can't disable streams for "
> - "endpoint 0x%x\n, "
> - "streams are being disabled already.",
> + "endpoint 0x%x, "
> + "streams are being disabled already\n",
> eps[i]->desc.bEndpointAddress);
> return 0;
> }
> @@ -3084,8 +3084,8 @@ static u32 xhci_calculate_no_streams_bitmask(struct
> xhci_hcd *xhci,
> if (!(ep_state & EP_HAS_STREAMS) &&
> !(ep_state & EP_GETTING_STREAMS)) {
> xhci_warn(xhci, "WARN Can't disable streams for "
> - "endpoint 0x%x\n, "
> - "streams are already disabled!",
> + "endpoint 0x%x, "
> + "streams are already disabled!\n",
> eps[i]->desc.bEndpointAddress);
> xhci_warn(xhci, "WARN xhci_free_streams() called "
> "with non-streams endpoint\n");
> @@ -4353,7 +4353,7 @@ static u16 xhci_get_timeout_no_hub_lpm(struct
> usb_device *udev,
> state_name, sel);
> else
> dev_dbg(>dev, "Device-initiated %s disabled "
> - "due to long PEL %llu\n ms",
> + "due to long PEL %llu ms\n",
> state_name, pel);
> return USB3_LPM_DISABLED;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Minor Alpha updates for 3.11
On Tue, Jul 16, 2013 at 10:04 AM, Richard Henderson wrote: > Here's a set of minor updates for arch/alpha that should not > be controversial. Patches 1-5 and 7 (with the typo fixed) are Reviewed-and-Tested-by: Matt Turner I don't know enough patch 6 to make any kind of meaningful review, so it's Acked-by: Matt Turner I've got five patches in a for-linus branch on kernel.org that I was planning to send a pull request for soon. Would you like me to add these to that branch? Thanks! 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: [RFC PATCH 1/1] Dual Squashfs: multicore implementation
On 16 July 2013 19:48, mani wrote:
>
> From 19c055d73cee8e65f8c24393450014b3560a8c6a Mon Sep 17 00:00:00 2001
> From: Manish Sharma
> Date: Mon, 1 Apr 2013 12:52:35 +0530
> Subject: [RFC PATCH 1/1] Dual Squashfs: multicore implementation
Mani,
Please don't send me the same patch twice in two days I received
the patch the first time. I do have a day job (and Squashfs isn't
it), and so you shouldn't expect a response in one day. The patch is
queued for review as time permits.
Cheers
Phillip
>
> The basic idea includes getting big requests by using readpages and
> then decompressing two blocks on each core.
> This implementation gives 50% improvement for the sequential file reads.
> 1.Split the two chunks based on the squashfs block size in readpages
> 2.Removed the locks of the decompressor(zlib/lzo) for percpu.
> 3.Increase the number of the data cache to per cpu.
> Points to consider:-
> 1. Need a lot of memory for the mutiple cache & multiple workspaces.
> 2. All the cpu will be too busy to process all the requests. cpu %usage
> increase.
> 3. Own queue method is implemented can be replaced with workqueues.
> 4. percpu data strucutures can be used.
>
> Signed-off-by: Manish Sharma
> ---
> fs/squashfs/Kconfig | 23 +++
> fs/squashfs/Makefile |1 +
> fs/squashfs/file.c | 250
> fs/squashfs/lzo_wrapper.c| 113 -
> fs/squashfs/squashfs_fs_sb.h |6 +-
> fs/squashfs/super.c | 59 ++-
> fs/squashfs/tegra_mp.c | 368
> ++
> fs/squashfs/tegra_mp.h | 58 +++
> fs/squashfs/zlib_wrapper.c | 160 +-
> 9 files changed, 1030 insertions(+), 8 deletions(-)
> create mode 100644 fs/squashfs/tegra_mp.c
> create mode 100644 fs/squashfs/tegra_mp.h
>
> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
> index c70111e..ffcf730 100644
> --- a/fs/squashfs/Kconfig
> +++ b/fs/squashfs/Kconfig
> @@ -121,3 +121,26 @@ config SQUASHFS_FRAGMENT_CACHE_SIZE
>
>Note there must be at least one cached fragment. Anything
>much more than three will probably not make much difference.
> +
> +config SQUASHFS_READPAGES_ENABLE
> +bool "Enable Readpages for Squashfs"
> +depends on SQUASHFS
> +default n
> +help
> + Saying Y here enables readpages functionality.
> + If unsure, say N.
> +
> +config SQUASHFS_MPCORE
> +bool "Include Multi Core support in SquashFS file systems"
> +depends on SQUASHFS && SQUASHFS_READPAGES_ENABLE
> +default n
> +select SQUASHFS_4K_DEVBLK_SIZE
> +select TEGRA_MPCORE
> +help
> + Saying Y here includes support for Multi Core in SquashFS file
> systems
> + Multi Core supports creates the different kernel threads to improve
> the
> + SquashFS boot time performance.
> + This implementation is independent of the TEGRA board anyway as of
> now.
> + If unsure, say N.
> +
> +
> diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
> index 110b047..0b99517 100644
> --- a/fs/squashfs/Makefile
> +++ b/fs/squashfs/Makefile
> @@ -9,3 +9,4 @@ squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
> squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
> squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
> squashfs-$(CONFIG_SQUASHFS_ZLIB) += zlib_wrapper.o
> +squashfs-$(CONFIG_SQUASHFS_MPCORE) += tegra_mp.o
> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c
> index 8ca62c2..c134e13 100644
> --- a/fs/squashfs/file.c
> +++ b/fs/squashfs/file.c
> @@ -38,6 +38,11 @@
> * Larger files use multiple slots, with 1.75 TiB files using all 8 slots.
> * The index cache is designed to be memory efficient, and by default uses
> * 16 KiB.
> + *
> + * manish...@samsung.com
> + * Added support for readpages for getting the bigger requests.
> + * Added Multithread support for the bigger chunks > squashfs block size
> + *
> */
>
> #include
> @@ -53,6 +58,22 @@
> #include "squashfs_fs_i.h"
> #include "squashfs.h"
>
> +#ifdef CONFIG_SQUASHFS_MPCORE
> +#include "tegra_mp.h"
> +
> +
> +extern struct squashfs_queue *to_reader_1;
> +#endif /* CONFIG_SQUASHFS_MPCORE*/
> +
> +
> +
> +#ifdef CONFIG_SQUASHFS_READPAGES_ENABLE
> +#define list_to_page(head) (list_entry((head)->prev, struct page, lru))
> +#define list_to_page_index(pos, head, index) \
> +for (pos = list_entry((head)->prev, struct page, lru);
> pos->index != index;\
> +pos = list_entry((pos)->prev, struct page, lru))
> +#endif
> +
> /*
> * Locate cache slot in range [offset, index] for specified inode. If
> * there's more than one return the slot closest to index.
> @@ -494,8 +515,237 @@ out:
>
> return 0;
> }
> +#ifdef CONFIG_SQUASHFS_READPAGES_ENABLE
> +
> +/*
> + * copy of squashfs_readpage function for
> + * supports
> + * readpages & Multicore implementation
> + */
> +int read_this_page(struct file *file, struct page *page)
> +{
> +struct inode *inode
Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Wed, Jul 17, 2013 at 04:53:58AM +0100, Ben Hutchings wrote: > On Tue, 2013-07-16 at 09:36 -0700, Greg KH wrote: > > On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote: > > > On Mon, 15 Jul 2013, Greg KH wrote: > > > > > > > > Anything that's being reviewed on the stable list is public. I know > > > > > this is an old argument, but if you point out a fix you *know* has a > > > > > security impact then you'll help general distribution maintainers and > > > > > users a lot more than you help the black-hats who are quite capable of > > > > > recognising such a fix (if they haven't already spotted and exploited > > > > > the bug). > > > > > > > > I'm sorry, but you know I will not do that, so asking about it isn't > > > > going to change this behavior. > > > > > > I just followed up in the other thread, where Ted was explaining why the > > > huge /dev/random rework was a -stable material. > > > > > > Why specifically would it be wrong to be open about this being security > > > related, and providing the necessary data (i.e. at least reference to > > > http://factorable.net/) publically? > > > > > > I fail to see what the point behind hiding this would be. > > > > I'm not "hiding" anything, all I'm doing is using the exact same > > changelog comments that are in Linus's tree, and nothing else. > > Right, and I wouldn't expect you to edit commit messages. But if a fix > was privately proposed to you for stable on the grounds that the bug is > found to be exploitable, maybe you could include that information in the > cover message for the review. Sorry, my position on that has not changed, I will not do that for the obvious reasons discussed many times in the past. 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: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
On Tue, Jul 16, 2013 at 11:02:22PM +0200, Oliver Schinagl wrote:
> On 07/16/13 08:41, Greg KH wrote:
> > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> >> With your latest patches for binary attributes and your blog post, I
> >> thought that you want to create your binary attributes before the probe
> >> function, to avoid the userspace race. To do that, we have two options,
> >> create them in init (ugly?) or fill the .group member if available so it
> >> gets automatically created from the register function.
> > Yes, the .group thing should be what is needed here.
> That's what I thought (and used).
> >
> >> Well in my case, I'm using the module_platform_driver() macro which
> >> expects the struct platform_driver. Platform_driver has a device_driver
> >> member .driver where the .groups is located. Great, using that works and
> >> we should have the sysfs entry race-free. However I don't know hot to
> >> exchange data between that and the rest of my driver.
> >>
> >> Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the
> >> .read function to obtain a platform_device where i could use
> >> platform_get_drvdata on. All was good, but that doesn't fly now and my
> >> knowledge is a bit short as to why.
> > I don't understand, why not use the platform device that was passed to
> > the binary attribute write function?
> Because the pointers don't match and I get a null pointer from
> platform_get_data
That's not good, that shouldn't happen.
> >> The second method is finding some other shared structure given that we
> >> get a platform_device in the probe function, yet I couldn't find
> >> anything and this platform_device isn't the same as the one from the .read.
> > It should be, why isn't it?
> I think that's a little above my grasp :p
> >
> >> Of course using a global var bypasses this issue, but I'm sure it won't
> >> pass review ;)
> > The platform device structure should have what you need, right?
> Should, but doesn't :(
> >
> >> So using these new patches for binary attributes, how can I pass data
> >> between my driver and the sysfs files using a platform_driver? Or are
> >> other 'hacks' needed and using the .groups attribute from
> >> platform_driver->device_driver->groups is really the wrong approach.
> >>
> >> I did ask around and still haven't figured it out so far, so I do
> >> apologize if you feel I'm wasting your precious time.
> > How is the platform device not the same thing that was passed to your
> > probe function?
> I don't know :( But i'll add the relevant sections with printk results
> below, which I should have done before, then again those printk's were
> not supposed to be in that e-mail to begin with ;)
>
> So if I'm not seeing something stupidly obvious, feel free to shout at me :)
Your code looks good, and correct, to me, I don't see anything obviously
wrong. What creates your platform device in the first place?
>
> static ssize_t sid_read(struct file *fd, struct kobject *kobj,
> struct bin_attribute *attr, char *buf,
> loff_t pos, size_t size)
> {
> struct platform_device *pdev;
> void __iomem *sid_reg_base;
> int i;
>
> pdev = to_platform_device(kobj_to_dev(kobj));
> sid_reg_base = (void __iomem *)platform_get_drvdata(pdev);
> printk("0x%p, 0x%p, 0x%p, 0x%p\n", kobj, kobj_to_dev(kobj), pdev,
> sid_reg_base);
>
> 0xef1e7c80, 0xef1e7c78, 0xef1e7c68, 0x (null)
>
> if (pos < 0 || pos >= SID_SIZE)
> return 0;
> if (size > SID_SIZE - pos)
> size = SID_SIZE - pos;
>
> for (i = 0; i < size; i++)
> buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);
>
> return i;
> }
>
>
> static struct bin_attribute sid_bin_attr = {
> .attr = { .name = "eeprom", .mode = S_IRUGO, },
> .size = SID_SIZE,
> .read = sid_read,
> };
>
> static struct bin_attribute *sunxi_sid_attrs[] = {
> _bin_attr,
> NULL,
> };
>
> static const struct attribute_group sunxi_sid_group = {
> .bin_attrs = sunxi_sid_attrs,
> };
If you create a "normal" attribute here as well, does that work
properly?
>
> static const struct attribute_group *sunxi_sid_groups[] = {
> _sid_group,
> NULL,
> };
>
> static int __init sunxi_sid_probe(struct platform_device *pdev)
> {
> struct resource *res;
> void __iomem *sid_reg_base;
> u8 entropy[SID_SIZE];
> unsigned int i;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> sid_reg_base = devm_ioremap_resource(>dev, res);
> if (IS_ERR(sid_reg_base))
> return PTR_ERR(sid_reg_base);
> platform_set_drvdata(pdev, sid_reg_base);
>
> for (i = 0; i < SID_SIZE; i++)
> entropy[i] = sunxi_sid_read_byte(sid_reg_base, i);
> add_device_randomness(entropy, SID_SIZE);
> dev_dbg(>dev, "%s loaded\n", DRV_NAME);
> printk("0x%p, 0x%p\n", pdev, sid_reg_base);
>
> 0xef02b000, 0xf1c23800
The memory locations are really
Re: [PATCH v3 1/4] hwmon: (lm90) split set temp as common codes
On Mon, Jul 15, 2013 at 09:24:15AM +0200, Jean Delvare wrote: > On Mon, 15 Jul 2013 14:25:29 +0800, Wei Ni wrote: > > On 07/12/2013 10:40 PM, Guenter Roeck wrote: > > > On Fri, Jul 12, 2013 at 04:30:34PM +0200, Jean Delvare wrote: > > >> If that means that for example the ACPI thermal zone is no longer > > >> displayed by "sensors", then I strongly object - unless it is > > >> explicitly registered as a separate hwmon device from now on, of course. > > > > > > If I recall correctly that was the idea. Of course, in practice that will > > > mean > > > that devices will _not_ get exposed as hwmon devices, as implementers > > > won't > > > bother doing both. > > > > > >> My idea was to make the bridge optional - you decide when you register > > >> a thermal device if it should be exposed as hwmon or not. > > > > > > Yes, that would be a much better solution. > > > > I think we can decide it in the DT, we can add a dt property in the lm90 > > device node, such as: > > sys-interface = SYS_HWMON; > > or > > sys-interface = SYS_THERMAL; > > So we register it as the hwmon or thermal device > > This is an option, but please keep in mind that DT is not the only way > to instantiate LM90-like devices, and we should not expose duplicate > inputs by default. It is fine with me if the default is to create only a > HWMON device (as the lm90 driver was doing so far), and only > DT-instantiated devices have the choice. I don't think this information belongs in the device tree. Whether the device is exposed as hwmon or thermal device (or both) is entirely a software issue whereas DT is a means to describe the hardware. It seems to me that the earlier proposal of communicating to the bridge whether or not a device should be exposed as hwmon device is the right thing to do here. Thierry pgpNqNTYs3DDW.pgp Description: PGP signature
Re: [GIT PULL] PHY Framework for 3.12 merge window
On Tue, Jul 16, 2013 at 06:08:26PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Here's the pull request for the PHY Framework which I've been working on for a > while. > > I've applied these patches on the current linux mainline HEAD (which has one > commit after 3.11-rc1 is tagged). > > Even before this framework is merged, quite a few people started using it. > I've > queued those patches along with the PHY framework as well. > > I'm also planning to maintain this framework henceforth and will be sending > pull requests for anything related to this framework or users of this > framework. > > Let me know if you want any changes on this pull request > > Thanks > Kishon > > The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf: > > Merge tag 'ext4_for_linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51 > -0700) > > are available in the git repository at: > > > git://gitorious.org/linuxphy/linuxphy.git tags/phy-for-v3.12 I'm sorry, but I can't pull from a non-kernel.org account. And, why is this a pull request at all? There aren't many patches in this series, I can take them just fine through email. I only do pull requests from a _very_ limited number of people whom I have been working with for a long time, everyone else I handle just fine with email. Also, why me for this? Should it go through my "char/misc" tree? Do you have sign-offs for the subsystems that you touch? Will you be moving more phy code from the different subsystems (like all the USB phy code), into here as well? Or is this just for new devices? 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] Squashfs: sanity check information from disk
On 15 July 2013 17:17, Dan Carpenter wrote:
> We read the size of the name from the disk, but a larger name than
> expected would cause memory corruption.
Thanks for the patch, it's queued for the next merge window. There's
one mistake with the patch, but I can fix it when it's applied, or you
can send a revised patch (see later).
>
> Signed-off-by: Dan Carpenter
> ---
> I don't know this code very well, but to me it looks like there is an
> off by one bug here as well.
No, the code is perfectly OK here, the confusion stems from what the
+1 is doing.
>
> We say:
>
> size = le32_to_cpu(index->size) + 1;
>
> The "+ 1" is presumably for the NUL terminator. Then we do:
index->size is one less than the size of the name, so to get the true
size of the name we must add one to it. If index->size is 7 it means
the size of the name stored on disk is 8 bytes.
This storing the size as one less came from the observation we never
have 0 length filenames, and so 0 would effectively never be used.
>
> index->name[size] = '\0';
>
> That means we are putting a NUL character one space beyond the end of
> the array. Presumably the first character of the next thing saved to
> the disk is usually zero so that's why we don't notice that we are
> reading a extra character when we read "size" number of bytes.
>
> diff --git a/fs/squashfs/namei.c b/fs/squashfs/namei.c
> index 7834a51..bc1334c 100644
> --- a/fs/squashfs/namei.c
> +++ b/fs/squashfs/namei.c
> @@ -79,7 +79,8 @@ static int get_dir_index_using_name(struct super_block *sb,
> int len)
> {
> struct squashfs_sb_info *msblk = sb->s_fs_info;
> - int i, size, length = 0, err;
> + int i, length = 0, err;
> + unsigned int size;
> struct squashfs_dir_index *index;
> char *str;
>
> @@ -103,6 +104,10 @@ static int get_dir_index_using_name(struct super_block
> *sb,
>
>
> size = le32_to_cpu(index->size) + 1;
> + if (size >= SQUASHFS_NAME_LEN + 1) {
This should be
if (size > SQUASHFS_NAME_LEN)
I can fix it, or you can send a revised patch.
Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 17
Hi all, Changes since 20130716: New tree: aio The sound-asoc tree still has its build failure so I used the version from next-20130715. The aio tree gained a build failure for which I reverted a commit. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 231 trees (counting Linus' and 33 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (16fc5bc smp: blackfin: fix check error, using atomic_ops to handle atomic_t type) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (ad81f05 Linux 3.11-rc1) Merging arm-current/fixes (cbbe6f8 ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs) Merging m68k-current/for-linus (ad81f05 Linux 3.11-rc1) Merging metag-fixes/fixes (d903bca metag: checksum.h: fix carry in csum_tcpudp_nofold) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging net/master (52fe29e be2net: Fix to avoid hardware workaround when not needed) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (d52392b ALSA: hda - Add new GPU codec ID to snd-hda) Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem) Merging wireless/master (53e5946 ath9k_htc: fix data race between request_firmware_nowait() callback and suspend()) Merging driver-core.current/driver-core-linus (aa01aa3 sysfs: use file mode defines from stat.h) Merging tty.current/tty-linus (ad81f05 Linux 3.11-rc1) Merging usb.current/usb-linus (e583d9d USB: global suspend and remote wakeup don't mix) Merging staging.current/staging-linus (ad81f05 Linux 3.11-rc1) Merging char-misc.current/char-misc-linus (ad81f05 Linux 3.11-rc1) Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus) Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all RAID10 reshapes to move no data.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of bound overwrite issue) Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetree/merge (706b78f dtc: ensure #line directives don't consume data from the next line) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (397eada gpio/omap: don't use linear domain mapping for OMAP1) Merging rr-fixes/fixes (6407d75 virtio_console: fix uapi header) Merging mfd-fixes/master (5649d8f mfd: ab85
Re: [PATCH V5 09/12] perf: make events stream always parsable
On Tue, Jul 16, 2013 at 5:09 PM, Peter Zijlstra wrote:
> On Tue, Jul 16, 2013 at 09:49:31AM +0300, Adrian Hunter wrote:
>
>> If you want the ID at the first position in the ID sample, it is do-able.
>> It means perf tools will have to be changed to calculate the variable start
>> position of the ID sample, and then parse the ID sample forwards from there.
>> Please advise.
>
This is complicated and leads me to believe that a better way of doing this
is to leverage some bits in the header. This is what my proposal was. I did
not yet have a chance to post it. But you can use a bit in the header
to indicate
the presence of the eventID. That way, you do not have to relate to the
event attr->sample_type to determine how to parse the meta-data records
such as MMAP. When the bit is present in the header, the eventID is
to be found at -8 bytes form the end of the record.
> Oh urgh I see.. how about I merge something like the below first?
>
> Re-reading your patch; you add something to struct sample_id; which means that
> events which 'forget' to set perf_event_attr::sample_id_all while setting
> PERF_SAMPLE_IDENTIFIER are 'funny'. Should we refuse them?
>
>
> ---
> Subject: perf: Update perf_event_type documentation
>
> Due to a discussion with Adrian I had a good look at the perf_event_type
> record
> layout and found the documentation to be somewhat unclear.
>
> Cc: Adrian Hunter
> Signed-off-by: Peter Zijlstra
> ---
> include/uapi/linux/perf_event.h | 21 +++--
> kernel/events/core.c| 31 ---
> 2 files changed, 35 insertions(+), 17 deletions(-)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 0b1df41..335016c 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -478,6 +478,16 @@ enum perf_event_type {
> * file will be supported by older perf tools, with these new optional
> * fields being ignored.
> *
> +* struct sample_id {
> +* { u32 pid, tid; } && PERF_SAMPLE_TID
> +* { u64 time; } && PERF_SAMPLE_TIME
> +* { u64 id; } && PERF_SAMPLE_ID
> +* { u64 stream_id;} && PERF_SAMPLE_STREAM_ID
> +* { u32 cpu, res; } && PERF_SAMPLE_CPU
> +* } && perf_event_attr::sample_id_all
> +*/
> +
> + /*
> * The MMAP events record the PROT_EXEC mappings so that we can
> * correlate userspace IPs to code. They have the following structure:
> *
> @@ -488,7 +498,8 @@ enum perf_event_type {
> * u64 addr;
> * u64 len;
> * u64 pgoff;
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_MMAP= 1,
> @@ -498,6 +509,7 @@ enum perf_event_type {
> * struct perf_event_headerheader;
> * u64 id;
> * u64 lost;
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_LOST= 2,
> @@ -508,6 +520,7 @@ enum perf_event_type {
> *
> * u32 pid, tid;
> * charcomm[];
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_COMM= 3,
> @@ -518,6 +531,7 @@ enum perf_event_type {
> * u32 pid, ppid;
> * u32 tid, ptid;
> * u64 time;
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_EXIT= 4,
> @@ -528,6 +542,7 @@ enum perf_event_type {
> * u64 time;
> * u64 id;
> * u64 stream_id;
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_THROTTLE= 5,
> @@ -539,6 +554,7 @@ enum perf_event_type {
> * u32 pid, ppid;
> * u32 tid, ptid;
> * u64 time;
> +* struct sample_idsample_id;
> * };
> */
> PERF_RECORD_FORK= 7,
> @@ -549,6 +565,7 @@ enum perf_event_type {
> * u32 pid, tid;
> *
> * struct read_format values;
> +* struct
Re: splice vs execve lockdep trace.
On Tue, Jul 16, 2013 at 02:02:12PM -0700, Linus Torvalds wrote: > On Tue, Jul 16, 2013 at 1:43 PM, Dave Chinner wrote: > > > > Yes - IO is serialised based on the ip->i_iolock, not i_mutex. We > > don't use i_mutex for many things IO related, and so internal > > locking is needed to serialise against stuff like truncate, hole > > punching, etc, that are run through non-vfs interfaces. > > Umm. But the page IO isn't serialized by i_mutext *either*. You don't > hold it across page faults. In fact you don't even take it at all > across page faults. Right, and that's one of the biggest problems page based IO has - we can't serialise it against other IO and other page cache manipulation functions like hole punching. What happens when a splice read or mmap page fault races with a hole punch? You get stale data being left in the page cache because we can't serialise the page read with the page cache invalidation and underlying extent removal. Indeed, why do you think we've been talking about VFS-level IO range locking for the past year or more, and had a discussion session at LSF/MM this year on it? i.e. this: http://lwn.net/Articles/548939/ So forget about this "we don't need no steenkin' IO serialisation" concept - it's fundamentally broken. FWIW, hole punching in XFS takes the i_iolock in exclusive mode, and hence serialises correctly against splice. IOWs, there is a whole class of splice read data corruption race conditions that XFS is not susceptible to but > *Every* other local filesystem uses generic_file_splice_read() with > just a single > > .splice_read = generic_file_splice_read, ... and so they all are broken in a nasty, subtle way Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] x86: introduce int3-based instruction patching
On 07/12/2013 12:57 AM, Borislav Petkov wrote: > > Right, above sequence would work on AMD. > Awesome. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Tue, 2013-07-16 at 09:36 -0700, Greg KH wrote: > On Tue, Jul 16, 2013 at 11:11:24AM +0200, Jiri Kosina wrote: > > On Mon, 15 Jul 2013, Greg KH wrote: > > > > > > Anything that's being reviewed on the stable list is public. I know > > > > this is an old argument, but if you point out a fix you *know* has a > > > > security impact then you'll help general distribution maintainers and > > > > users a lot more than you help the black-hats who are quite capable of > > > > recognising such a fix (if they haven't already spotted and exploited > > > > the bug). > > > > > > I'm sorry, but you know I will not do that, so asking about it isn't > > > going to change this behavior. > > > > I just followed up in the other thread, where Ted was explaining why the > > huge /dev/random rework was a -stable material. > > > > Why specifically would it be wrong to be open about this being security > > related, and providing the necessary data (i.e. at least reference to > > http://factorable.net/) publically? > > > > I fail to see what the point behind hiding this would be. > > I'm not "hiding" anything, all I'm doing is using the exact same > changelog comments that are in Linus's tree, and nothing else. Right, and I wouldn't expect you to edit commit messages. But if a fix was privately proposed to you for stable on the grounds that the bug is found to be exploitable, maybe you could include that information in the cover message for the review. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 1/4] ARM: dts: imx23-evk: enable USB PHY and controller
On Tue, Jul 16, 2013 at 09:56:12AM -0300, Otavio Salvador wrote: > The i.MX23EVK board provides a USB port so the USB PHY and controller > need to be enabled for it to be usable. > > Signed-off-by: Otavio Salvador There is a typo i.XM23 in commit log of patch #2 and #3. I fixed them up and applied all 3. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (aio tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
fs/aio.c: In function 'aio_migratepage':
fs/aio.c:196:2: error: implicit declaration of function
'migrate_page_move_mapping' [-Werror=implicit-function-declaration]
rc = migrate_page_move_mapping(mapping, new, old, NULL, mode);
^
Caused by commit 36bc08cc0170 ("fs/aio: Add support to aio ring pages
migration"). The declaration of migrate_page_move_mapping() in
linux/migrate.h is protected by CONFIG_MIGRATION - its use in fs/aio.c is
not. So the usage needs to be protected, or there needs to be a dummy
version in linux/migrate.h
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpgszKZhVQcr.pgp
Description: PGP signature
Re: [ 00/19] 3.10.1-stable review
On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote: > On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell wrote: > >> > >> "Mauro, SHUT THE FUCK UP!" > > > > This one crosses the line. There's no non-offensive way to tell a geek > > "you are wrong", but this isn't even trying. Bad Linus! > > You know what? Not my proudest moment. I was really upset. This goes a long way to resolving the stated issues in my opinion. Of the three issues raised, Linus has either adequately justified himself or conceded. This wasn't meant to be Linus on trial was it? :-) I'm sure we could dig up a thousand more references of "bad" behavior from others on LKML. Before we do let's first make sure the recipient is not being "resistant to education" (a phrase I've picked up from Thomas Gleixner and like very much) or has somehow provoked things. Ted Ts'o will recall fondly all the pigs in guinea *smirk*. I enjoy a good rant as much as anyone, but I recognize personal attacks can be very harmful to the individual and possibly (difficult to prove) the quality of the project. This is especially true when coming from someone that is held in very high regard, such as Linus and the other maintainers. I think the one tangible TODO that has come out of this is to DOCUMENT expectations. Paul Gortmaker has already submitted a netdev FAQ which I have reviewed and David Miller approved of. I have committed to review stable_kernel_rules. It appears there is also call to have Linus' expectations of the maintainers documented. This would also be good for everyone to read to better understand the responses they receive from maintainers and why things are the way they are. With that done, I think some tolerance in both directions would improve things here. And as a last resort, we speak up when someone is under attack. "Whoa Nelly, calm down, don't forget your meds. Seriously though, that (is not acceptable code|violates a core policy), see the following documentation." This adds some burden on the broader audience to point people at the docs, because even RTFM has to get annoying to repeat too often. And with that, I'll sign out of this thread unless anyone wants to discuss documentation - but those should probably happen on LKML (or maybe KS as some have suggested). -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux 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: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Tue, 16 Jul 2013, Lorenzo Pieralisi wrote: > Hello, > > version v5 of VExpress SPC driver, please read on the changelog for major > changes and explanations. > > The probing scheme is unchanged, since after trying the early platform > devices approach it appeared that the end result was no better than the > current one. The only clean solution relies either on changing how > secondaries are brought up in the kernel (later than now) or enable > early platform device registration through DT. Please check this > thread for the related discussion: > > https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html > > The interface was adapted to regmap and again reverted to old driver for > the following reasons: > > - Power down registers locking is hairy and requires arch spinlocks in > the MCPM back end to work properly, normal spinlocks cannot be used > - Regmap adds unnecessary code to manage SPC since it is just a bunch of > registers used to control power management flags, the overhead is just > not worth it (talking about power down registers, not the vexpress config > interface) > - The locking scheme behind regmap requires all registers in the map > to be protected with the same lock, which is not exactly what we want > here > - Given the reasons above, adding a regmap interface buys us nothing from > a driver readability and maintainability perspective (again just talking > about the power interface, a few registers) because for the SPC it would > simply not be used > > /drivers/mfd is probably not the right place for this code as it stands (but > probably will be when the entire driver, with DVFS and config interface, is > complete). > > Thank you for the review in advance, > Lorenzo I've integrated this patch in my MCPM backend for TC2 patch series. ACKs from concerned/interested people would be appreciated so I could send this for ARM-SOC inclusion right away. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, 2013-07-16 at 20:02 -0700, Linus Torvalds wrote: > On Tue, Jul 16, 2013 at 7:18 PM, Ben Hutchings wrote: > > > > In fact, even in the pull request that's referenced here, Linus, you > > were polite but firm in your first two responses. When you're perfectly > > capable of doing that, why spoil it by adding insults? > > Umm. Notice how the "Joseph" I replied to had deleted all the comments he > wrote? Sorry, that completely escaped me. > That should tell you something. I smacked down a troll. > > If I was polite to you all those years ago, and I was polite but firm > in the two first responses, please give me credit for when I smack > somebody down. There may be a reason for it. The fact that the person > deleted his messages (or github deleted them for him - I have no idea > what their comment policy is) and you cannot see that context any more > online should not make you think that I suddenly went crazy. Unfortunately, it seems I'm not the only one to be confused by this. > Btw, since I get the github messages in email too, I have a copy. > Joseph replied to those "polite but firm" messages where I explained > exactly *why* I don't want to bother with github pull requests with > this gem: > >"I did not realizes that Linus' shit does not stink. Thanks for > clearing that up..." > > Quite frankly, I think I was quite polite enough. Exactly *because* I > had been polite but firm before that injection. > > The fact is, I don't suffer fools nicely. I call it like I see it, and > I called him a moron for entering the discussion with a totally > content-free comment. > > Feel free to disagree. Maybe you see some value in the troll comment? Indeed not. > And I somehow suspect that your message that I replied to back in 1999 > was somehow more relevant? Yes? No? Yes. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] Bcache fixes for 3.11
On Tue, Jul 16 2013, Kent Overstreet wrote: > Hey Jens - I've been busy torture testing and chasing bugs, here's the > fruits of my labors. These are all fairly small fixes, some of them > quite important: > > The following changes since commit 8e51e414a3c6d92ef2cc41720c67342a8e2c0bf7: > > bcache: Use standard utility code (2013-07-01 14:43:53 -0700) > > are available in the git repository at: > > git://evilpiepirate.org/~kent/linux-bcache.git bcache-for-3.11 > > for you to fetch changes up to 79826c35eb99cd3c0873b8396f45fa26c87fb0b0: > > bcache: Allocation kthread fixes (2013-07-12 00:22:49 -0700) Thanks Kent, pulled in for 3.11. Due to my recent move, the 3.11 drivers pull is delayed a bit, will go out shortly. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arcmsr: Fix bug of updating ARECA Raid adapter firmware through ioctl(ARCHTTP) interface
From: chingching2...@areca.com.tw Fix bug of updating ARECA Raid adapter firmware through ioctl(ARCHTTP) interface Signed-off-by: chingching2...@areca.com.tw --- patch3 Description: Binary data
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, Jul 16, 2013 at 7:18 PM, Ben Hutchings wrote: > > In fact, even in the pull request that's referenced here, Linus, you > were polite but firm in your first two responses. When you're perfectly > capable of doing that, why spoil it by adding insults? Umm. Notice how the "Joseph" I replied to had deleted all the comments he wrote? That should tell you something. I smacked down a troll. If I was polite to you all those years ago, and I was polite but firm in the two first responses, please give me credit for when I smack somebody down. There may be a reason for it. The fact that the person deleted his messages (or github deleted them for him - I have no idea what their comment policy is) and you cannot see that context any more online should not make you think that I suddenly went crazy. Btw, since I get the github messages in email too, I have a copy. Joseph replied to those "polite but firm" messages where I explained exactly *why* I don't want to bother with github pull requests with this gem: "I did not realizes that Linus' shit does not stink. Thanks for clearing that up..." Quite frankly, I think I was quite polite enough. Exactly *because* I had been polite but firm before that injection. The fact is, I don't suffer fools nicely. I call it like I see it, and I called him a moron for entering the discussion with a totally content-free comment. Feel free to disagree. Maybe you see some value in the troll comment? And I somehow suspect that your message that I replied to back in 1999 was somehow more relevant? Yes? No? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arcmsr: Fix command throttling for ARC188x series adapters
From: chingching2...@areca.com.tw Fix command throttling for ARC188x series adapters. Signed-off-by: chingching2...@areca.com.tw --- patch2 Description: Binary data
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Tue, 2013-07-16 at 22:10 +0200, Willy Tarreau wrote: > On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote: > > On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote: > > > > > People mark stable patches that way already today with a: > > > Cc: stable # delay for 3.12-rc4 > > > or some such wording. I take those and don't apply them until the noted > > > release happens, so you can do this if needed. > > > > I guess the thing is, are stable patches prone to regressions. Do we > > just do that for patches that we think are too complex and may cause > > some harm. Of course, there's the question about having a clue about > > what patches might cause harm or not. > > We'd probably better switch the tag to be "# now" to imply that we don't > want to delay them, and that by default those merged prior to rc4 are all > postponed. I think this might work. I definitely agree that most fixes aren't worth the risk of allowing into a stable release that quickly, so it's the right default. > I suspect that the switching could be mostly automated this way, > avoiding to add burden to Greg : > > - if commit ID >= -rc4 > move to immediate queue, it's a "critical" fix as per Linus' rules > > - if Cc: stable line has "now" at the end, move to immediate queue as > the maintainer takes this reponsibility ; > > - otherwise move to the next .2 queue. I can't speak for Greg, but that seems reasonably easy to implement. (Which I would have to do, as I was unable to reuse Greg's scripts.) Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: [REGRESSION 3.10.1] System does not wake up from suspend
On Mon, Jul 15, 2013 at 12:20:19PM +0530, Srivatsa S. Bhat wrote: > On 07/15/2013 10:24 AM, Willy Tarreau wrote: > > On Sun, Jul 14, 2013 at 09:36:25PM -0700, Sören Brinkmann wrote: > >> Hi Greg, > >> > >> since upgrading to 3.10.1 I find my system not waking up from suspend > >> from time to time. Unfortunately, I couldn't figure out how to reliably > >> reproduce the issue. Sometimes it works just fine. > >> > >> All I know so far: > >> On 3.10 I had my system completely freezing a few times. But that did > >> not seem to be related to suspend/resume. I never experienced the > >> behavior described below on 3.10. > >> > >> On 3.10.1 I hit this bug a few times, that my system did not wake up. > >> I.e. the screen stayed black and the power LED kept flashing. But > >> nothing brought the system back up and I had to longpress power to reset > >> the system. > >> I had none of the system freezes like the ones described above anymore. > > > > Fortunately, 3.10.1 is very small. The only patch it contains which is > > related to suspend is 18/19 (cpufreq ondemand governor). Maybe you're > > having a problem with cpufreq on this machine in fact. > > > > You may want to try to force it to performance mode or powersave mode > > and try for a while, it is possible that both 3.10 and 3.10.1 will work > > fine. > > > > Or, you could try applying the patch shown below on top of 3.10.1 and > see if it fixes the suspend/resume regression for you. > > https://lkml.org/lkml/2013/7/11/661 > > (Just apply patch 1, not the entire patchset). So, this didn't end well. With that patch applied I end up in a kernel panic on suspend, reproducible - well two out of two is a small test set, but anyway. Unfortunately too late to get any information about it and my logs don't show anything either. But it's seems worse than the rather occasional hangs on resume on the vanilla 3.10.1 kernel. Sören pgpLj3AWphZsF.pgp Description: PGP signature
[PATCH 1/3] arcmsr: Modify maxium outstanding command
From: Ching Modify maximum outstanding command number, notify command complete with auto request sense, reassign ARC12x4 series to SATA type adapter Signed-off-by: chingching2...@areca.com.tw --- patch1 Description: Binary data
linked-list: Remove __list_for_each
__list_for_each used to be the non prefetch() aware list walking primitive. When we removed the prefetch macros from the list routines, it became redundant. Given it does exactly the same thing as list_for_each now, we might as well remove it and call list_for_each directly. All users of __list_for_each have been converted to list_for_each calls in the current merge window. Signed-off-by: Dave Jones diff --git a/include/linux/list.h b/include/linux/list.h index b83e565..f4d8a2f 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -381,17 +381,6 @@ static inline void list_splice_tail_init(struct list_head *list, for (pos = (head)->next; pos != (head); pos = pos->next) /** - * __list_for_each - iterate over a list - * @pos: the list_head to use as a loop cursor. - * @head: the head for your list. - * - * This variant doesn't differ from list_for_each() any more. - * We don't do prefetching in either case. - */ -#define __list_for_each(pos, head) \ - for (pos = (head)->next; pos != (head); pos = pos->next) - -/** * list_for_each_prev - iterate over a list backwards * @pos: the list_head to use as a loop cursor. * @head: the head for your list. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/4] tracing: fix open/delete fixes
(2013/07/17 3:56), Oleg Nesterov wrote: > Hello. > > Completely untested and _incomplete_. This ignores instance_delete() > and ftrace_event_format_fops, at least. > > But I am not going to even try to finish this series unless you tell > me that you agree with this approach. > > I have no idea what else could I miss. I probably understand no more > than 1% of this code, I won't be surprized if this can't work. > > To remind, we also need other changes we are discussing. At a glance, you're trying to change which operation will be failed. Currently, user can not remove an event while someone opens files which related to the event. And this approach changes that the someone can remove the event even if the files are opened (and read/write operation will be failed). Am I understand correctly? Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: udc: add gadget state kobject uevent
On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote: > On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: > > Hi Greg, > > > > The USB on our platform can change roles between HOST and GADGET, but > > it is not capable of OTG. > > That kind of sounds like the definition of OTG :) > > > When the USB changes between roles the udev will run some scripts > > automatically according to the udev rules. > > What exactly does udev/userspace see when the roles change? > > And what can trigger the change in roles? > > > The default role is GADGET, and we bind the g_mass_storage to the USB > > GADGET role. > > > > We should secure the back end file storage between the device and the > > host PC connecting to our device. > > We need to know when the GADGET is really connect to a host PC, then > > we can umount the file on the device > > and export it to the g_mass_storage. > > I thought you already get an event for this, otherwise no one would be > able to properly deal with this. > > > The question is since we default GADGET, so the g_mass_storage.ko is > > installed early but connecting to a host PC > > is randomly, But the udev has no idea when a host PC connects our device. > > > > So we consider it's reasonable to let the udev know the GADGET device state. > > Is there any alternative to our question? > > I thought we already export events for gadget device states, have you > looked for them? I can't dig through the code at the moment, but this > seems like a pretty common issue... > If I understand correctly, what Rong wants is udev can be notified the udc state changes, like connect/disconnect event. Currently, we only export it to /sys. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xhci: Correct misplaced newlines
Logging messages end in newlines, not have
them put in the middle of messages.
Signed-off-by: Joe Perches
---
drivers/usb/host/xhci.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2c49f00..87b5e65 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3075,8 +3075,8 @@ static u32 xhci_calculate_no_streams_bitmask(struct
xhci_hcd *xhci,
/* Are streams already being freed for the endpoint? */
if (ep_state & EP_GETTING_NO_STREAMS) {
xhci_warn(xhci, "WARN Can't disable streams for "
- "endpoint 0x%x\n, "
- "streams are being disabled already.",
+ "endpoint 0x%x, "
+ "streams are being disabled already\n",
eps[i]->desc.bEndpointAddress);
return 0;
}
@@ -3084,8 +3084,8 @@ static u32 xhci_calculate_no_streams_bitmask(struct
xhci_hcd *xhci,
if (!(ep_state & EP_HAS_STREAMS) &&
!(ep_state & EP_GETTING_STREAMS)) {
xhci_warn(xhci, "WARN Can't disable streams for "
- "endpoint 0x%x\n, "
- "streams are already disabled!",
+ "endpoint 0x%x, "
+ "streams are already disabled!\n",
eps[i]->desc.bEndpointAddress);
xhci_warn(xhci, "WARN xhci_free_streams() called "
"with non-streams endpoint\n");
@@ -4353,7 +4353,7 @@ static u16 xhci_get_timeout_no_hub_lpm(struct usb_device
*udev,
state_name, sel);
else
dev_dbg(>dev, "Device-initiated %s disabled "
- "due to long PEL %llu\n ms",
+ "due to long PEL %llu ms\n",
state_name, pel);
return USB3_LPM_DISABLED;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux Plumbers ACPI/PM, PCI Microconference
Linux Plumbers has approved an ACPI/PM, PCI microconference. The overview page is here: http://wiki.linuxplumbersconf.org/2013:pci_subsystem We would like to start receiving volunteers for presenting topics of interest. There is a lot of activity in these subsystems so please respond by submitting presentation or discussion proposals that you would be willing to cover for consideration. You should also feel free to submit ideas as proposals that others could cover. The instructions for submitting ideas should be at: http://www.linuxplumbersconf.org/2013/submitting-topic/ This is the "Plumbers" conference so topics concerning userspace interaction with the kernel and not just topics concerning pure kernel subsystem internals would be greatly welcomed. As a possible aid towards promoting topics for submissions we have listed a few candidates that seem to meet the criteria in the microconference proposals wiki located at http://wiki.linuxplumbersconf.org/2013:pci_subsystem Last year, we had a good discussion on general issues in PCI space - that also might be worth giving updates on. If you have topics that you would like to add, wait until the instructions get posted at the link above. If you are impatient, feel free to email me directly (but probably best to drop the broad mailing lists from the reply). Thanks! Len, Bjorn, Myron, Rafael Yinghai - An update on host bridge hot-add capabilities, what is in place and what still remains to be done, would seem like a good topic. Shuah - You brought up the idea about "Converting drivers from Legacy PM ops to dev_pm_ops"; would you like to present what you have done/encountered so far? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/18] sched: Add infrastructure for split shared/private accounting of NUMA hinting faults
On Mon, Jul 15, 2013 at 11:20 PM, Mel Gorman wrote:
> /*
> * Got a PROT_NONE fault for a page on @node.
> */
> -void task_numa_fault(int node, int pages, bool migrated)
> +void task_numa_fault(int last_nid, int node, int pages, bool migrated)
For what is the new parameter?
> {
> struct task_struct *p = current;
> + int priv;
>
> if (!sched_feat_numa(NUMA))
> return;
>
> + /* For now, do not attempt to detect private/shared accesses */
> + priv = 1;
> +
> /* Allocate buffer to track faults on a per-node basis */
> if (unlikely(!p->numa_faults)) {
> - int size = sizeof(*p->numa_faults) * nr_node_ids;
> + int size = sizeof(*p->numa_faults) * 2 * nr_node_ids;
>
> /* numa_faults and numa_faults_buffer share the allocation */
> p->numa_faults = kzalloc(size * 2, GFP_KERNEL);
> @@ -900,7 +915,7 @@ void task_numa_fault(int node, int pages, bool migrated)
> return;
>
> BUG_ON(p->numa_faults_buffer);
> - p->numa_faults_buffer = p->numa_faults + nr_node_ids;
> + p->numa_faults_buffer = p->numa_faults + (2 * nr_node_ids);
> }
>
> /*
> @@ -914,7 +929,7 @@ void task_numa_fault(int node, int pages, bool migrated)
> task_numa_placement(p);
>
> /* Record the fault, double the weight if pages were migrated */
> - p->numa_faults_buffer[node] += pages << migrated;
> + p->numa_faults_buffer[task_faults_idx(node, priv)] += pages <<
> migrated;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, 2013-07-16 at 19:50 -0400, Theodore Ts'o wrote: > On Tue, Jul 16, 2013 at 03:43:57PM -0700, Sarah Sharp wrote: [...] > > > Keep in mind that there are some cultures where even pointing out a > > > technical flaw in code might considered bringing deep shame on the > > > engineer and their company. So how sensitive people are to criticism > > > during an electronic exchange is always going to be highly culutrally > > > and personally variable. > > > > Yes, that's true. Some kernel developers are better at moderating their > > comments and tone towards individuals who are "sensitive". > > ... and actually, I think it's actually quite difficult to find cases > where Linus has used a very harsh tone towards someone who would be > "sensitive". [...] Someone wrote on debian-private a little while back that 'I will not work on anything Linus might be involved in', and in a later mail linked to this example of abuse: http://mark.dreamwidth.org/22320.html Honestly, if I had seen newbies being treated that way before I was involved, I may well have made the same resolution. As it happens, when I made a quite basic mistake in the format one of my first patches back in 1999, Linus was entirely polite in correcting me. In fact, even in the pull request that's referenced here, Linus, you were polite but firm in your first two responses. When you're perfectly capable of doing that, why spoil it by adding insults? Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH V2] tracing: Check f_dentry before accessing event_file/call in inode->i_private
(2013/07/16 3:16), Oleg Nesterov wrote: > On 07/09, Masami Hiramatsu wrote: >> >> To avoid this, when opening events/*/*/enable, we have to ensure >> the dentry of the file is not unlinked yet, under event_mutex >> is locked. > > Probably this can work, but I am starting to think that this ref > count becomes too complex Oleg, I agree that is a bit complex way to fix but it can fix. However, I think we should fix bugs first, because there are bugs. I don't like to leave a bug in the kernel as it is, while we re- start discussing new approach... > Could you please look at the draft patch I sent in another email? I'm happy to see the series, and I guess it will take a long discussion and review time again. So, I'd like to suggest you getting these fixes into ftrace as first-aid treatment, and discuss your new series. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] mtd: orion_nand: convert to use devm_* APIs
From: Wei Yongjun
Convert to use devm_* APIs to avoid resources leak on error handling case.
Signed-off-by: Wei Yongjun
---
drivers/mtd/nand/orion_nand.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 46f308d..ce711b4 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -85,25 +85,23 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
int ret = 0;
u32 val = 0;
- nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
+ nc = devm_kzalloc(>dev,
+ sizeof(struct nand_chip) + sizeof(struct mtd_info),
+ GFP_KERNEL);
if (!nc) {
printk(KERN_ERR "orion_nand: failed to allocate device
structure.\n");
- ret = -ENOMEM;
- goto no_res;
+ return -ENOMEM;
}
mtd = (struct mtd_info *)(nc + 1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto no_res;
- }
+ if (!res)
+ return -ENODEV;
- io_base = ioremap(res->start, resource_size(res));
+ io_base = devm_ioremap(>dev, res->start, resource_size(res));
if (!io_base) {
printk(KERN_ERR "orion_nand: ioremap failed\n");
- ret = -EIO;
- goto no_res;
+ return -EIO;
}
if (pdev->dev.of_node) {
@@ -111,8 +109,7 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
GFP_KERNEL);
if (!board) {
printk(KERN_ERR "orion_nand: failed to allocate board
structure.\n");
- ret = -ENOMEM;
- goto no_res;
+ return -ENOMEM;
}
if (!of_property_read_u32(pdev->dev.of_node, "cle", ))
board->cle = (u8)val;
@@ -186,10 +183,6 @@ no_dev:
clk_disable_unprepare(clk);
clk_put(clk);
}
- iounmap(io_base);
-no_res:
- kfree(nc);
-
return ret;
}
@@ -201,10 +194,6 @@ static int orion_nand_remove(struct platform_device *pdev)
nand_release(mtd);
- iounmap(nc->IO_ADDR_W);
-
- kfree(nc);
-
clk = clk_get(>dev, NULL);
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] mm, hugetlb: fix and clean-up node iteration code to alloc or free
On 2013/7/15 17:52, Joonsoo Kim wrote:
> Current node iteration code have a minor problem which do one more
> node rotation if we can't succeed to allocate. For example,
> if we start to allocate at node 0, we stop to iterate at node 0.
> Then we start to allocate at node 1 for next allocation.
>
> I introduce new macros "for_each_node_mask_to_[alloc|free]" and
> fix and clean-up node iteration code to alloc or free.
> This makes code more understandable.
>
> Signed-off-by: Joonsoo Kim
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 0067cf4..a838e6b 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -752,33 +752,6 @@ static int hstate_next_node_to_alloc(struct hstate *h,
> return nid;
> }
>
> -static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
> -{
> - struct page *page;
> - int start_nid;
> - int next_nid;
> - int ret = 0;
> -
> - start_nid = hstate_next_node_to_alloc(h, nodes_allowed);
> - next_nid = start_nid;
> -
> - do {
> - page = alloc_fresh_huge_page_node(h, next_nid);
> - if (page) {
> - ret = 1;
> - break;
> - }
> - next_nid = hstate_next_node_to_alloc(h, nodes_allowed);
> - } while (next_nid != start_nid);
> -
> - if (ret)
> - count_vm_event(HTLB_BUDDY_PGALLOC);
> - else
> - count_vm_event(HTLB_BUDDY_PGALLOC_FAIL);
> -
> - return ret;
> -}
> -
> /*
> * helper for free_pool_huge_page() - return the previously saved
> * node ["this node"] from which to free a huge page. Advance the
> @@ -797,6 +770,42 @@ static int hstate_next_node_to_free(struct hstate *h,
> nodemask_t *nodes_allowed)
> return nid;
> }
>
> +#define for_each_node_mask_to_alloc(hs, nr_nodes, node, mask)
> \
> + for (nr_nodes = nodes_weight(*mask),\
> + node = hstate_next_node_to_alloc(hs, mask); \
> + nr_nodes > 0 && \
> + ((node = hstate_next_node_to_alloc(hs, mask)) || 1);\
Hi Joonsoo,
For the first loop, node = hstate_next_node_to_alloc() will be executed two
times,
so will skip the first node in mask, right?
Thanks,
Jianguo Wu.
> + nr_nodes--)
> +
> +#define for_each_node_mask_to_free(hs, nr_nodes, node, mask) \
> + for (nr_nodes = nodes_weight(*mask),\
> + node = hstate_next_node_to_free(hs, mask); \
> + nr_nodes > 0 && \
> + ((node = hstate_next_node_to_free(hs, mask)) || 1); \
> + nr_nodes--)
> +
> +static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
> +{
> + struct page *page;
> + int nr_nodes, node;
> + int ret = 0;
> +
> + for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
> + page = alloc_fresh_huge_page_node(h, node);
> + if (page) {
> + ret = 1;
> + break;
> + }
> + }
> +
> + if (ret)
> + count_vm_event(HTLB_BUDDY_PGALLOC);
> + else
> + count_vm_event(HTLB_BUDDY_PGALLOC_FAIL);
> +
> + return ret;
> +}
> +
> /*
> * Free huge page from pool from next node to free.
> * Attempt to keep persistent huge pages more or less
> @@ -806,36 +815,31 @@ static int hstate_next_node_to_free(struct hstate *h,
> nodemask_t *nodes_allowed)
> static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
>bool acct_surplus)
> {
> - int start_nid;
> - int next_nid;
> + int nr_nodes, node;
> int ret = 0;
>
> - start_nid = hstate_next_node_to_free(h, nodes_allowed);
> - next_nid = start_nid;
> -
> - do {
> + for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) {
> /*
>* If we're returning unused surplus pages, only examine
>* nodes with surplus pages.
>*/
> - if ((!acct_surplus || h->surplus_huge_pages_node[next_nid]) &&
> - !list_empty(>hugepage_freelists[next_nid])) {
> + if ((!acct_surplus || h->surplus_huge_pages_node[node]) &&
> + !list_empty(>hugepage_freelists[node])) {
> struct page *page =
> - list_entry(h->hugepage_freelists[next_nid].next,
> + list_entry(h->hugepage_freelists[node].next,
> struct page, lru);
> list_del(>lru);
> h->free_huge_pages--;
> - h->free_huge_pages_node[next_nid]--;
> + h->free_huge_pages_node[node]--;
> if (acct_surplus) {
>
What endianness is word in i2c_smbus_data?
I'm rather confused here. In SMBUS, the "read word" operation returns two bytes. Just to be confusing, the SMBUS spec calls the first byte "Data Byte Low" and the second byte "Data Byte High". But they really are the first and second bytes -- Read Word will return whatever Read Byte would have as its first byte. Let's call these bytes B1 and B2 for first and second. The eeprom and at24 drivers expect data->word to be (B2 << 8) | B1. That is, data->word is the cpu representation of the value on the bus if that value is treated as little-endian. Is that indeed the correct interpretation? If so, should it be documented somewhere? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.11-rc1 PATCH 0/5] printk: Initial restructuring
On Tue, 2013-07-16 at 18:48 -0700, Linus Torvalds wrote: > On Mon, Jul 15, 2013 at 2:51 PM, Joe Perches wrote: > > > > If this is acceptable, I'll post 5 or so patches at a time > > after/if each block of patches is applied. > > I didn't see anything objectionable, but I'm assuming this comes in > through Andrew? I'd rather you take it directly now. > And hopefully gets comments from others too.. There were a few 9 months ago. Mostly it was a timing issue as to who takes it and when. printk still moves around quite a bit and Andrew suggested shortly after an -rc1 was likely the best timing. http://lkml.indiana.edu/hypermail/linux/kernel/1212.0/02931.html As far as I'm concerned, the biggest deal is starting this refactoring. It doesn't have to be an big blast like what was submitted last year, but it should be started sooner rather never. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/19] 3.10.1-stable review
On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote: > Emotions aren't bad. Quite the reverse. Spock and Dr. Sheldon Cooper strongly disagree. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 3.10: discard/trim support on md-raid1?
On Wed, 17 Jul 2013 00:44:15 +0400 CoolCold wrote: > Neil, I've tryed to look around commit logs but failed to find commit > where discard/trim were added. > I was looking via > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/md?id=9f2a940965286754f3a34d5737c3097c05db8725=grep=discard+support > , tryed just "discard" without support - found commits about dm, not > md, though. > > Can you shed some light here? Thanks in advance. > > (resent in plaintext mode, please reply to this one) Did you try: grep -i discard drivers/md/raid1.c ?? commit 2ff8cc2c6d4e323de71a42affeb3041fa17d5b10 Author: Shaohua Li Date: Thu Oct 11 13:28:54 2012 +1100 md: raid 1 supports TRIM is the commit that introduced discard support for md/raid1.c NeilBrown > > > On Tue, Jul 16, 2013 at 11:15 AM, NeilBrown wrote: > > On Sat, 13 Jul 2013 06:34:19 -0400 "Justin Piszcz" > > wrote: > > > >> Hello, > >> > >> Running 3.10 and I see the following for an md-raid1 of two SSDs: > >> > >> Checking /sys/block/md1/queue: > >> add_random: 0 > >> discard_granularity: 512 > >> discard_max_bytes: 2147450880 > >> discard_zeroes_data: 0 > >> hw_sector_size: 512 > >> iostats: 0 > >> logical_block_size: 512 > >> max_hw_sectors_kb: 32767 > >> max_integrity_segments: 0 > >> max_sectors_kb: 512 > >> max_segment_size: 65536 > >> max_segments: 168 > >> minimum_io_size: 512 > >> nomerges: 0 > >> nr_requests: 128 > >> optimal_io_size: 0 > >> physical_block_size: 512 > >> read_ahead_kb: 8192 > >> rotational: 1 > >> rq_affinity: 0 > >> scheduler: none > >> write_same_max_bytes: 0 > >> > >> What should be seen: > >> rotational: 0 > > > > What has "rotational" got to do with "supports discard"? > > There may be some correlation, but it isn't causal. > > > >> And possibly: > >> discard_zeroes_data: 1 > > > > This should be set as the 'or' of the same value from component devices. > > And > > does not enable or disable the use of discard. > > > > I don't think that "does this device support discard" appears in sysfs. > > > > I believe trim does work on md/raid1 if the underlying devices all support > > it. > > > > NeilBrown > > > > > > > >> > >> Can anyone confirm if there is a workaround to allow TRIM when using > >> md-raid1? > >> > >> Some related discussion here: > >> http://us.generation-nt.com/answer/md-rotational-attribute-help-206571222.ht > >> ml > >> http://www.progtown.com/topic343938-ssd-strange-itself-conducts.html > >> > >> > >> Justin. > >> > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > signature.asc Description: PGP signature
Re: [v3.11-rc1 PATCH 0/5] printk: Initial restructuring
On Mon, Jul 15, 2013 at 2:51 PM, Joe Perches wrote: > > If this is acceptable, I'll post 5 or so patches at a time > after/if each block of patches is applied. I didn't see anything objectionable, but I'm assuming this comes in through Andrew? And hopefully gets comments from others too.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/19] 3.10.1-stable review
On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell wrote: >> >> "Mauro, SHUT THE FUCK UP!" > > This one crosses the line. There's no non-offensive way to tell a geek > "you are wrong", but this isn't even trying. Bad Linus! You know what? Not my proudest moment. I was really upset. But that said, in my defense I actually think that one stands out. I have written a lot of public emails, and that one line is probably the single most over-the-line one. Or at least pretty close to the top. And it's not so much because of the swearing, but because of the "shut up" part. Or is that just me not reacting to swearwords again? Do I go overboard sometimes? Hell yes. But I get emotional about some of this, and I not only think that's ok, I actually think it's important. You mentioned the "lost the raw, red-hot anger of the original", and I do think emotion is important to convey. It's not just the message, it's also the fact that I'm really really pissed. Neil Brown here somewhere earlier said "So my personal perspective on what it means to be responsible is: Don't flame: include the facts, exclude the emotion." and I can't overstate how much I disagree. You do need the factual part too, but "exclude the emotion" is not good either. Emotions aren't bad. Quite the reverse. If we are expected to have a sense of personal trust between the people involved (and quite frankly, apart from just "technical excellence" I think personal trust is just about the top criterion for good maintainers), I definitely think that it's not about just about the facts. You need to hear the *person* too. And some people are calm and don't swear, and that's them. Others aren't. Yeah, yeah, I go overboard. Whatever. At least you guys know that when I get emotional, I'm not going to come asking for a shoulder to cry on. I think a little excessive swearing is less awkward for everybody in the end. Linus Side note: the whole "trust the person" doesn't mean you have to like that person. "Trust" is about having your expectations met, not necessarily about those expectations always being all that positive. . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, 16 Jul 2013 19:50:08 -0400 Theodore Ts'o wrote: > The other question where I think you and Linus differ is the belief > whether polite messages of the form, "it's really rude to break the > kernel ABI, I would rather prefer if you wouldn't do that" are as > effective at establishing community norms, compared with his style of > e-mail messagtes, and whether the priority in establishing community > norms around technical excellence compares with the priority around > community norms around "civility". Can I call "strawman" here? A maintainer has a significant power - to accept, reject, or revert. I fully expect them to use that power. Linus (or any other maintainer) doesn't need to say "I would rather prefer if you wouldn't do that". They say: This is wrong. I will not accept that patch. or This was wrong. I have reverted it. And when absolutely necessary: "After a long succession of uncorrected errors I regret to advise you that I can no longer consider any patches you send". Using emotive language is an attempt to control someone else by addressing them at an emotional level. That sort of control is not needed when the above power is available, and it is a sort of control which is out of context and can affect different people very very differently. Personally, I find that a blunt but civil acceptance or rejection of patches is quite sufficient to establish community norms of technical excellence. Beyond that there are plenty of examples of very helpful and constructive dialogue that improve patch quality even more. NeilBrown signature.asc Description: PGP signature
Re: [PATCH 08/18] sched: Reschedule task on preferred NUMA node once selected
On Mon, Jul 15, 2013 at 11:20 PM, Mel Gorman wrote:
> +static int
> +find_idlest_cpu_node(int this_cpu, int nid)
> +{
> + unsigned long load, min_load = ULONG_MAX;
> + int i, idlest_cpu = this_cpu;
> +
> + BUG_ON(cpu_to_node(this_cpu) == nid);
> +
> + rcu_read_lock();
> + for_each_cpu(i, cpumask_of_node(nid)) {
Check allowed CPUs first if task is given?
> + load = weighted_cpuload(i);
> +
> + if (load < min_load) {
> + min_load = load;
> + idlest_cpu = i;
> + }
> + }
> + rcu_read_unlock();
> +
> + return idlest_cpu;
> +}
> +
[...]
> + /*
> +* Record the preferred node as the node with the most faults,
> +* requeue the task to be running on the idlest CPU on the
> +* preferred node and reset the scanning rate to recheck
> +* the working set placement.
> +*/
> if (max_faults && max_nid != p->numa_preferred_nid) {
> + int preferred_cpu;
> +
> + /*
> +* If the task is not on the preferred node then find the most
> +* idle CPU to migrate to.
> +*/
> + preferred_cpu = task_cpu(p);
> + if (cpu_to_node(preferred_cpu) != max_nid) {
> + preferred_cpu = find_idlest_cpu_node(preferred_cpu,
> +max_nid);
> + }
> +
> + /* Update the preferred nid and migrate task if possible */
> p->numa_preferred_nid = max_nid;
> p->numa_migrate_seq = 0;
> + migrate_task_to(p, preferred_cpu);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/2] fs/anon_inode: Introduce a new lib function anon_inode_getfile_private()
Hi Ben, On 07/16/2013 09:16 PM, Benjamin LaHaise wrote: > On Tue, Jul 16, 2013 at 05:56:12PM +0800, Gu Zheng wrote: >> >> Introduce a new lib function anon_inode_getfile_private(), it creates a new >> file >> instance by hooking it up to an anonymous inode, and a dentry that describe >> the >> "class" of the file, similar to anon_inode_getfile(), but each file holds a >> single inode. Furthermore, anyone who wants to create a private anon file >> will >> benefit from this change. >> >> Signed-off-by: Gu Zheng >> Signed-off-by: Benjamin LaHaise > > Please don't add my Signed-off-by when I have never even seen or reviewed > a patch -- that is completely unacceptable. Sorry for my reckless action, I'll remember your reminder.:) > Second, I don't think this > patch is suitable for 3.11, as it has not seen much testing outside of one > test program I had written. It's a long standing bug, so it isn't urgent > to get the fix into the tree. That said, it did pass a few tests I ran > last night, so it is probably suitable for the -next tree. Thanks for your test.:) Regards, Gu > > As for patch 1, it looks okay to me, but will need Al Viro's signoff. > > -ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Tue, Jul 16, 2013 at 08:51:36PM -0400, Steven Rostedt wrote: > On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote: > > > Another thing might deviated from the main theme, but I'd like to raise it > > here because I would like to see what's the proper way for that. > > > > For instance, people A posted a patch set to the mailing list at first, > > people B think that there are some issues in A's implementation, and he > > happened to play around the same stuff recently, so he submitted another > > patch series. Finally, people B made it. > > (In that period, people A kept silent, maybe because he/she was unhappy) > > > > This is a actual occurrence I once observed from a subsystem list(my > > apologies, I just want to talk this case rather than against somebody), > > it seems people A is a new comer(because I can not searched any past > > commits of him/her from the git log), people B is definitely a senior guy. > > > > So that's my question, is that a proper collaboration form in kernel > > community? Does it better if people B could give some suggestions to > > help A to improve the code, especially if those help would help A stepping > > into the kernel development -- maybe it's depend largely on one's opinion. > > :( > > This is a completely different issue from the one in this thread, but it > is also a legitimate issue and honestly, a bigger one than perceived > insults. > > Is it proper collaboration? Absolutely not. Something that I try to be > sensitive to as it's something I can do as well. There's been things on > my todo list, where someone would send me patches that do it. I would be > thinking "darn it, I wanted to do it" and even worse, the patches that > were sent wouldn't be of the way I wanted them. But I've tried to be > good, and instead of just going about and implementing it myself, I > would try to help the person massage the patches into what I wanted. > That takes a lot of effort and discipline, and honestly, helping someone > else do the work you wanted is much harder than just doing it yourself. > > Sometimes the maintainer just takes the easier route, and does the work > themselves (because it's also more fun too). But that's really a slap in > the face of the person that submitted the work in the first place. If > anything hurts the community, it's this behavior. Not Linus giving > someone an ass wipe. /me hands Steve a box of wet-wipes. :) There's a lot of controversy over whether a senior developer re-implementing someone's patchset is bad behavior. I've seen it argued both ways. "If I don't write code, I will just become a patch-pushing, pencil-pushing maintainer." Or "I don't want to bother working with newbies, it's faster to just implement this myself." I really think it's up to the maintainer whether they want to mentor someone through a big submission, or do it themselves. I usually lean towards mentorship, but hey, not everyone has the time. One thing that might make it easier for the original submitter is making sure they get a Signed-off-by line in the patchset that the maintainer submits. At the very least, their line should be directly below the maintainer's. That way, they get credit for the idea, and possibly help improve their statistics in the Signed-off-by count for that kernel revision. I suspect people would object if I suggested the original submitter should be the first Signed-off-by line, but in some cases it may be appropriate. Sometimes I take someone's code, leave it mostly intact, and fix the bugs or add a feature that we really need before the code can land. In that case, it makes sense to give the original submitter credit before the maintainer. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On 07/16/2013 07:53 PM, Myklebust, Trond wrote: On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote: On 07/16/2013 07:12 PM, Sarah Sharp wrote: On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: Yes, that's true. Some kernel developers are better at moderating their comments and tone towards individuals who are "sensitive". Others simply don't give a shit. So we need to figure out how to meet somewhere in the middle, in order to establish a baseline of civility. I have to ask this because I'm thick, and don't really understand, but ... What problem exactly are we trying to solve here? Personal attacks are not cool Steve. Some people simply don't care if a verbal tirade is directed at them. Others do not want anyone to attack them personally, but they're fine with people attacking their code. Bystanders that don't understand the kernel community structure are discouraged from contributing because they don't want to be verbally abused, and they really don't want to see either personal attacks or intense belittling, demeaning comments about code. In order to make our community better, we need to figure out where the baseline of "good" behavior is. We need to define what behavior we want from both maintainers and patch submitters. E.g. "No regressions" and "don't break userspace" and "no personal attacks". That needs to be written down somewhere, and it isn't. If it's documented somewhere, point me to the file in Documentation. Hint: it's not there. That is the problem. Sarah Sharp The problem you are pointing out - and it is a problem - makes us less effective as a community. Not really. Most of the people who already work as part of this community are completely used to it. We've created the environment, and have no problems with it. You should never judge success by being popular with those people who are already contributing and put up with things. If you did that in business, you would never reach new customers. Where it could possibly be a problem is when it comes to recruiting _new_ members to our community. Particularly so given that some journalists take a special pleasure in reporting particularly juicy comments and antics. That would tend to scare off a lot of gun-shy newbies. That is my point - recruiting new members is made harder. As some one who manages *a lot* of upstream kernel developers, I will add that it is not just new comers that find this occasionally offensive and off putting. On the other hand, it might tend to bias our recruitment toward people of a more "special" disposition. Perhaps we finally need the services of a social scientist to help us find out... To be fair, we usually do very well at this, especially with new comers to our community. I think that most of the problems come up between people who know each other quite well and are friendly with each other in person. The problem is that when you use language that you would use with good friends over drinks to tell them they are being stupid and do that on a public list, you set a tone that reaches far beyond your intended target. All of those new comers also read this list and do not see it as funny or friendly. I really don't think that we have to be politically correct or overly kind to make things better. As a very low bar, we could start by trying to avoid using language that would get you fired when you send off an email to someone that you have power over (either manage directly or indirectly control their career). Ric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/jumplabel] x86: Make jump_label use int3-based patching
Commit-ID: 51b2c07b22261f19188d9a9071943d60a067481c
Gitweb: http://git.kernel.org/tip/51b2c07b22261f19188d9a9071943d60a067481c
Author: Jiri Kosina
AuthorDate: Fri, 12 Jul 2013 11:22:09 +0200
Committer: H. Peter Anvin
CommitDate: Tue, 16 Jul 2013 17:55:37 -0700
x86: Make jump_label use int3-based patching
Make jump labels use text_poke_bp() for text patching instead of
text_poke_smp(), avoiding the need for stop_machine().
Reviewed-by: Steven Rostedt
Reviewed-by: Masami Hiramatsu
Signed-off-by: Jiri Kosina
Link: http://lkml.kernel.org/r/alpine.lnx.2.00.1307121120250.29...@pobox.suse.cz
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/jump_label.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index 2889b3d..460f5d9 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -37,7 +37,19 @@ static void __jump_label_transform(struct jump_entry *entry,
} else
memcpy(, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
- (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE);
+ /*
+* Make text_poke_bp() a default fallback poker.
+*
+* At the time the change is being done, just ignore whether we
+* are doing nop -> jump or jump -> nop transition, and assume
+* always nop being the 'currently valid' instruction
+*
+*/
+ if (poker)
+ (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE);
+ else
+ text_poke_bp((void *)entry->code, , JUMP_LABEL_NOP_SIZE,
+(void *)entry->code + JUMP_LABEL_NOP_SIZE);
}
void arch_jump_label_transform(struct jump_entry *entry,
@@ -45,7 +57,7 @@ void arch_jump_label_transform(struct jump_entry *entry,
{
get_online_cpus();
mutex_lock(_mutex);
- __jump_label_transform(entry, type, text_poke_smp);
+ __jump_label_transform(entry, type, NULL);
mutex_unlock(_mutex);
put_online_cpus();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/jumplabel] x86: Introduce int3 (breakpoint) -based instruction patching
Commit-ID: fd4363fff3d96795d3feb1b3fb48ce590f186bdd
Gitweb: http://git.kernel.org/tip/fd4363fff3d96795d3feb1b3fb48ce590f186bdd
Author: Jiri Kosina
AuthorDate: Fri, 12 Jul 2013 11:21:48 +0200
Committer: H. Peter Anvin
CommitDate: Tue, 16 Jul 2013 17:55:29 -0700
x86: Introduce int3 (breakpoint)-based instruction patching
Introduce a method for run-time instruction patching on a live SMP kernel
based on int3 breakpoint, completely avoiding the need for stop_machine().
The way this is achieved:
- add a int3 trap to the address that will be patched
- sync cores
- update all but the first byte of the patched range
- sync cores
- replace the first byte (int3) by the first byte of
replacing opcode
- sync cores
According to
http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/01530.html
synchronization after replacing "all but first" instructions should not
be necessary (on Intel hardware), as the syncing after the subsequent
patching of the first byte provides enough safety.
But there's not only Intel HW out there, and we'd rather be on a safe
side.
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
"handler" (which would typically mean just skipping over the patched
region, acting as "nop" has been there, in case we are doing nop -> jump
and jump -> nop transitions).
Ftrace has been using this very technique since 08d636b ("ftrace/x86:
Have arch x86_64 use breakpoints instead of stop machine") for ages
already, and jump labels are another obvious potential user of this.
Based on activities of Masami Hiramatsu
a few years ago.
Reviewed-by: Steven Rostedt
Reviewed-by: Masami Hiramatsu
Signed-off-by: Jiri Kosina
Link: http://lkml.kernel.org/r/alpine.lnx.2.00.1307121102440.29...@pobox.suse.cz
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/alternative.h | 1 +
arch/x86/kernel/alternative.c | 106 +
kernel/kprobes.c | 2 +-
3 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/alternative.h
b/arch/x86/include/asm/alternative.h
index 58ed6d9..3abf8dd 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -233,6 +233,7 @@ struct text_poke_param {
};
extern void *text_poke(void *addr, const void *opcode, size_t len);
+extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void
*handler);
extern void *text_poke_smp(void *addr, const void *opcode, size_t len);
extern void text_poke_smp_batch(struct text_poke_param *params, int n);
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index c15cf9a..0ab4936 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -596,6 +597,111 @@ void *__kprobes text_poke(void *addr, const void *opcode,
size_t len)
return addr;
}
+static void do_sync_core(void *info)
+{
+ sync_core();
+}
+
+static bool bp_patching_in_progress;
+static void *bp_int3_handler, *bp_int3_addr;
+
+static int int3_notify(struct notifier_block *self, unsigned long val, void
*data)
+{
+ struct die_args *args = data;
+
+ /* bp_patching_in_progress */
+ smp_rmb();
+
+ if (likely(!bp_patching_in_progress))
+ return NOTIFY_DONE;
+
+ /* we are not interested in non-int3 faults and ring > 0 faults */
+ if (val != DIE_INT3 || !args->regs || user_mode_vm(args->regs)
+ || args->regs->ip != (unsigned long)bp_int3_addr)
+ return NOTIFY_DONE;
+
+ /* set up the specified breakpoint handler */
+ args->regs->ip = (unsigned long) bp_int3_handler;
+
+ return NOTIFY_STOP;
+}
+/**
+ * text_poke_bp() -- update instructions on live kernel on SMP
+ * @addr: address to patch
+ * @opcode:opcode of new instruction
+ * @len: length to copy
+ * @handler: address to jump to when the temporary breakpoint is hit
+ *
+ * Modify multi-byte instruction by using int3 breakpoint on SMP.
+ * In contrary to text_poke_smp(), we completely avoid stop_machine() here,
+ * and achieve the synchronization using int3 breakpoint.
+ *
+ * The way it is done:
+ * - add a int3 trap to the address that will be patched
+ * - sync cores
+ * - update all but the first byte of the patched range
+ * - sync cores
+ * - replace the first byte (int3) by the first byte of
+ * replacing opcode
+ * - sync cores
+ *
+ * Note: must be called under text_mutex.
+ */
+void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
+{
+ unsigned char int3 = 0xcc;
+
+ bp_int3_handler = handler;
+ bp_int3_addr = (u8 *)addr + sizeof(int3);
+ bp_patching_in_progress = true;
+ /*
+*
[tip:x86/asm] x86, bitops: Change bitops to be native operand size
Commit-ID: 9b710506a03b01a9fdd83962912bc9d8237b82e8
Gitweb: http://git.kernel.org/tip/9b710506a03b01a9fdd83962912bc9d8237b82e8
Author: H. Peter Anvin
AuthorDate: Tue, 16 Jul 2013 15:20:14 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Jul 2013 15:24:04 -0700
x86, bitops: Change bitops to be native operand size
Change the bitops operation to be naturally "long", i.e. 63 bits on
the 64-bit kernel. Additional bugs are likely to crop up in the
future.
We already have bugs which machines with > 16 TiB of memory in a
single node, as can happen if memory is interleaved. The x86 bitop
operations take a signed index, so using an unsigned type is not an
option.
Jim Kukunas measured the effect of this patch on kernel size: it adds
2779 bytes to the allyesconfig kernel. Some of that probably could be
elided by replacing the inline functions with macros which select the
32-bit type if the index is a 32-bit value, something like:
In that case we could also use "Jr" constraints for the 64-bit
version.
However, this would more than double the amount of code for a
relatively small gain.
Note that we can't use ilog2() for _BITOPS_LONG_SHIFT, as that causes
a recursive header inclusion problem.
The change to constant_test_bit() should both generate better code and
give correct result for negative bit indicies. As previously written
the compiler had to generate extra code to create the proper wrong
result for negative values.
Signed-off-by: H. Peter Anvin
Cc: Jim Kukunas
Link: http://lkml.kernel.org/n/tip-z61ofiwe90xeyb461o72h...@git.kernel.org
---
arch/x86/include/asm/bitops.h | 46 ++
arch/x86/include/asm/sync_bitops.h | 24 ++--
2 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 6dfd019..41639ce 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -15,6 +15,14 @@
#include
#include
+#if BITS_PER_LONG == 32
+# define _BITOPS_LONG_SHIFT 5
+#elif BITS_PER_LONG == 64
+# define _BITOPS_LONG_SHIFT 6
+#else
+# error "Unexpected BITS_PER_LONG"
+#endif
+
#define BIT_64(n) (U64_C(1) << (n))
/*
@@ -59,7 +67,7 @@
* restricted to acting on a single-word quantity.
*/
static __always_inline void
-set_bit(unsigned int nr, volatile unsigned long *addr)
+set_bit(long nr, volatile unsigned long *addr)
{
if (IS_IMMEDIATE(nr)) {
asm volatile(LOCK_PREFIX "orb %1,%0"
@@ -81,7 +89,7 @@ set_bit(unsigned int nr, volatile unsigned long *addr)
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static inline void __set_bit(int nr, volatile unsigned long *addr)
+static inline void __set_bit(long nr, volatile unsigned long *addr)
{
asm volatile("bts %1,%0" : ADDR : "Ir" (nr) : "memory");
}
@@ -97,7 +105,7 @@ static inline void __set_bit(int nr, volatile unsigned long
*addr)
* in order to ensure changes are visible on other processors.
*/
static __always_inline void
-clear_bit(int nr, volatile unsigned long *addr)
+clear_bit(long nr, volatile unsigned long *addr)
{
if (IS_IMMEDIATE(nr)) {
asm volatile(LOCK_PREFIX "andb %1,%0"
@@ -118,13 +126,13 @@ clear_bit(int nr, volatile unsigned long *addr)
* clear_bit() is atomic and implies release semantics before the memory
* operation. It can be used for an unlock.
*/
-static inline void clear_bit_unlock(unsigned nr, volatile unsigned long *addr)
+static inline void clear_bit_unlock(long nr, volatile unsigned long *addr)
{
barrier();
clear_bit(nr, addr);
}
-static inline void __clear_bit(int nr, volatile unsigned long *addr)
+static inline void __clear_bit(long nr, volatile unsigned long *addr)
{
asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
}
@@ -141,7 +149,7 @@ static inline void __clear_bit(int nr, volatile unsigned
long *addr)
* No memory barrier is required here, because x86 cannot reorder stores past
* older loads. Same principle as spin_unlock.
*/
-static inline void __clear_bit_unlock(unsigned nr, volatile unsigned long
*addr)
+static inline void __clear_bit_unlock(long nr, volatile unsigned long *addr)
{
barrier();
__clear_bit(nr, addr);
@@ -159,7 +167,7 @@ static inline void __clear_bit_unlock(unsigned nr, volatile
unsigned long *addr)
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static inline void __change_bit(int nr, volatile unsigned long *addr)
+static inline void __change_bit(long nr, volatile unsigned long *addr)
{
asm volatile("btc %1,%0" : ADDR : "Ir" (nr));
}
@@ -173,7 +181,7 @@ static inline void __change_bit(int nr, volatile unsigned
long *addr)
* Note that @nr may be almost arbitrarily large; this function is not
* restricted to acting on a single-word quantity.
[PATCH] time: silence warning in tick_nohz_init().
Fix those warning message when compile:
>kernel/time/tick-sched.c: In function ‘tick_nohz_init’:
>kernel/time/tick-sched.c:346:6: warning: unused variable ‘cpu’
>[-Wunused-variable]
Signed-off-by: Jianpeng Ma
---
kernel/time/tick-sched.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6960172..ca1d6e3 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -343,8 +343,6 @@ static int tick_nohz_init_all(void)
void __init tick_nohz_init(void)
{
- int cpu;
-
if (!have_nohz_full_mask) {
if (tick_nohz_init_all() < 0)
return;
--
1.8.3.rc1.44.gb387c77
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs
Lucas De Marchi writes:
> On Tue, Jul 16, 2013 at 5:28 AM, Philipp Hahn wrote:
>> Hello,
>>
>> Am Dienstag 16 Juli 2013, 08:43:36 schrieb Takashi Iwai:
>>> At Tue, 16 Jul 2013 15:11:51 +0930, Rusty Russell wrote:
>>> > Philipp Matthias Hahn writes:
>>> > > My x86_64 systems has some trouble loading some ALSA snd-* modules since
>>> > > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
>>> > > loading snd-intel-hda and snd-audio-usb by hand still works.
>>> >
>>> > Not a known problem to me, at least. Perhaps it's a dep loop somehow.
>>>
>>> I remember that someone reported it being Debian specific snd-seq-oss
>>> loading stuff.
>>
>> FYI: "oss-compat" is installed.
>>
>>> > > ...
>>> > > 1071 ?S 0:00 sh -c /sbin/modprobe --ignore-install snd &&
>>> > > { /sbin/modprobe --quiet snd
>>> > > 1080 ?D 0:00 \_ /sbin/modprobe --quiet snd-seq
>>> >
>>> > This was first, and it's waiting. Which means it must be doing
>>> > something weird, because snd_seq_oss is loading now:
>>> >
>>> > > snd_seq_oss 33717 1 - Loading 0xa041b000
>>> >
>>> > Perhaps in the tangle of modprobe install commands somewhere this gets
>>> > invoked?
>>>
>>> Likely, but I wonder what triggered a bug suddenly on 3.10.
>>> There is absolutely no change in sound/core/seq/*, and through a quick
>>> look, I couldn't find any suspicious change in kernel/module.c that
>>> may lead to this problem between 3.9 and 3.10.
>>>
>>> Philipp, can you get a sysrq-T trace while the stall?
>>
>> I've finally been able to reducte the number of processes to get a full
>> trace; see attached file.
>>
>> Please note that in this case the proprietary "nvidia" module was loaded,
>> since I currently onyl have remove access to the machine.
>> The original trace from yesterday happend without the nvidia module ever
>> being loaded.
>>
>> Am Dienstag 16 Juli 2013, 08:42:35 schrieb Lucas De Marchi:
>>> On Tue, Jul 16, 2013 at 2:41 AM, Rusty Russell
>>> wrote:
>>> First thing to check is the /etc/modprobe.d/*.conf file that contains
>>> these install commands. Did they change besides the kernel upgrade?
>>
>> Not that I know of: Booting 3.9.9 works fine, 3.10.x shows the problem.
>
> Then one possible explanation is that in 3.9.9 you don't have some of
> the modules causing this problem
>
>>
>> ...
>>> Philipp, which kernel are you upgrading from?
>> I just upgraded from 3.9.9 to 3.10.0; also tried 3.10.1 which did not
>> improve the situation.
>>
>>> I don't see anything to
>>> blame in the changes for the past releases. Any chance a bad entry in
>>> your .conf was added too? You may want to paste the output of modprobe
>>> -c, at least until "# End of configuration files. Dumping indexes
>>> now:"
>>
>> blacklist snd_pcsp
>> blacklist arkfb
>> blacklist aty128fb
>> blacklist atyfb
>> blacklist radeonfb
>> blacklist cirrusfb
>> blacklist cyber2000fb
>> blacklist gx1fb
>> blacklist gxfb
>> blacklist kyrofb
>> blacklist matroxfb_base
>> blacklist mb862xxfb
>> blacklist neofb
>> blacklist nvidiafb
>> blacklist pm2fb
>> blacklist pm3fb
>> blacklist s3fb
>> blacklist savagefb
>> blacklist sisfb
>> blacklist tdfxfb
>> blacklist tridentfb
>> blacklist viafb
>> blacklist vt8623fb
>> blacklist garmin_gps
>> blacklist nouveau
>> install binfmt_ /bin/true
>> install sound_slot_0 /sbin/modprobe snd-card-0
>> install sound_slot_1 /sbin/modprobe snd-card-1
>> install sound_slot_2 /sbin/modprobe snd-card-2
>> install sound_slot_3 /sbin/modprobe snd-card-3
>> install sound_slot_4 /sbin/modprobe snd-card-4
>> install sound_slot_5 /sbin/modprobe snd-card-5
>> install sound_slot_6 /sbin/modprobe snd-card-6
>> install sound_slot_7 /sbin/modprobe snd-card-7
>> install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet
>> snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }
>> install snd_rawmidi /sbin/modprobe --ignore-install snd-rawmidi && {
>> /sbin/modprobe --quiet snd-seq-midi ; : ; }
>> install snd_emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && {
>> /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
>> alias net_pf_16_proto_1 wire
>> alias net_pf_16_proto_3 ip_queue
>> alias net_pf_16_proto_8 scsi_transport_iscsi
>> alias net_pf_16_proto_9 audit
>> alias net_pf_16_proto_11 cn
>> alias net_pf_16_proto_13 ip6_queue
>> alias binfmt_204 binfmt_aout
>> alias binfmt_263 binfmt_aout
>> alias binfmt_264 binfmt_aout
>> alias binfmt_267 binfmt_aout
>> alias binfmt_387 binfmt_aout
>> alias block_major_3_* ide_generic
>> alias block_major_22_* ide_generic
>> alias block_major_33_* ide_generic
>> alias block_major_34_* ide_generic
>> alias block_major_37_* ide_tape
>> alias block_major_44_* ftl
>> alias block_major_46_* pcd
>> alias block_major_47_* pf
>> alias block_major_56_* ide_generic
>> alias block_major_57_* ide_generic
>> alias block_major_58_* lvm_mod
>> alias block_major_88_* ide_generic
>> alias block_major_89_* ide_generic
>> alias block_major_90_* ide_generic
>> alias block_major_91_*
Re: [ 00/19] 3.10.1-stable review
Sarah Sharp writes: > On Tue, Jul 16, 2013 at 02:22:14PM +0930, Rusty Russell wrote: > Linus is complaining about code here, and the effects of merging bad > code on his own tree. I personally have no qualms with this type of > harsh email, because it focuses on the code, not the person. > > I do, however, object when the verbal abuse shifts from being directed > at code to being directed at *people*. For example, Linus chose to > curse at Mauro [2] and Rafael [3], rather than their code: > > > "Mauro, SHUT THE FUCK UP!" This one crosses the line. There's no non-offensive way to tell a geek "you are wrong", but this isn't even trying. Bad Linus! > "How long have you been a maintainer? And you *still* haven't learnt the > first rule of kernel maintenance?" > > "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious > garbage and idiocy from a kernel maintainer again. Seriously." > > "The fact that you then try to make *excuses* for breaking user space, > and blaming some external program that *used* to work, is just > shameful. It's not how we work." > > "Fix your f*cking "compliance tool", because it is obviously broken. > And fix your approach to kernel programming." ... > ...and I'm surprised to > hear that kind of utter garbage from you in particular." Linus repeats 5 times: you can tell he's upset. > "Seriously. Why do I even have to mention this? Why do I have to > explain this to somebody pretty much *every* f*cking merge window?" This one is OK, actually. So, I tried to rewrite Linus' email. And it lost the raw, red-hot anger of the original. It no longer makes everyone listen. It tempts one to argue. It is not as effective :( But suggesting alternate expressions might be constructive. Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-net: put virtio net header inline with data
David Miller writes: > From: Rusty Russell > Date: Mon, 15 Jul 2013 11:13:25 +0930 > >> From: Michael S. Tsirkin >> >> For small packets we can simplify xmit processing >> by linearizing buffers with the header: >> most packets seem to have enough head room >> we can use for this purpose. >> Since existing hypervisors require that header >> is the first s/g element, we need a feature bit >> for this. >> >> Signed-off-by: Michael S. Tsirkin >> Signed-off-by: Rusty Russell > > I really think this has to wait until the next merge window, sorry. > > Please resubmit this when I open net-next back up, thanks. Oh, assumed it was already open.Will re-submit then. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ATTEND] How to act on LKML
On Tue, Jul 16, 2013 at 04:46:33PM -0700, Casey Schaufler wrote: > On 7/16/2013 3:39 PM, Sarah Sharp wrote: > > On Wed, Jul 17, 2013 at 12:18:21AM +0200, Willy Tarreau wrote: > >> On Tue, Jul 16, 2013 at 02:12:35PM -0700, Sarah Sharp wrote: > >>> I *hate* both direct personal insults and indirect personal insults. > >>> Neither should be acceptable in our community. > >>> > >>> As I stated in an email to Rusty, what I'm objecting to here is not > >>> kernel developers criticizing code. I'm objecting to personal attacks, > >>> and developers directing personal verbal abuse towards each other. This > >>> include all developers, not just Linus. > >> Well, there are people like me who don't mind getting personally > >> insulted but who are really pained when their work is criticized. > >> > >> You'd rather tell me I'm a fucking moron than all what I carefully > >> designed, wrote and tested is pure crap. Probably that part of the > >> reason is that I'm as I am and I'm not really responsible for this, > >> so I don't care. Call me ugly if you want, why should I bother ? But > >> if you tell me I did some crap, it's entirely my fault and that hurts > >> a lot more. > > I think we come from different perspectives here. I can change my code. > > Therefore, I don't mind my code being insulted. I cannot change myself. > > Sure you can, he began politely. > > It's a process called personal growth, and it happens to most > of us as we go through life. It is in reasonable to expect change > and to some degree manage the way in which one's self changes. It > is unreasonable and expect to manage changes in others, although we > do insist on trying. Personal change does happen, but at a much slower pace. And it takes both a will to change, and incentive in order for change to happen. If someone wants personal change in others or in the community, there needs to be both incentive to change, and a will to change in the community. I've provided examples and personal stories in an attempt to give incentive to change. I cannot force on anyone the will to change, nor would I want to. I cannot "manage" change in others. I can only politely point out that the current community behavior does hurt other people, and keep people from contributing. > Communities develop expectations of behavior based on many factors. > No community responds well to individuals who demand changes in the > norms of the community. This is especially true when the change is > a demand that some aspect of the community that is seen as unique > or empowering by the members of the community be suppressed. The majority in the community never reacts well to minority voices in the community asking for change. (Note, I'm talking a majority of numbers, not a racial or gender minority.) I'm not demanding change. I'm merely asking to discuss the possibly of change at KS. > Email communities are notorious for what would be considered > inexcusable behavior in most other kinds of community. I do not > know of any explanation, nor will I attempt to justify the claim. > I suspect that the relative anonymity has something to do with it, > as does the fact you can't actually raise your voice or glare. Or > smile smugly, for that matter. I do smile often in email. :) And be sad. :( And be apologetic. :-/ Smug. ^~^ Angry. >:[ Sarcastic. ;) Trolling/crazy. 8) D'oh. (>.<) Worried. (>_>); Disappointed. (-_-) Kitty! =^_^= Meow! Be creative. There are ways of expressing emotion without cussing. > The norms of the Linux kernel community have changed over time, > and will continue to do so. Communities, like the individuals that > make them up, change over time. Linus and Al Viro have changed over > the years. I have changed over the years. If you stick around, you > will too. If you don't you'll still change, but in different ways. I do believe I have changed over the six years I've been involved in the kernel. If anything, I've gotten better at being loud, speaking my mind, and figuring out what's bad code and how to politely tell people I don't take their code. I do think it is a mark of respect, both from the community, and from me, that people are actually listening and responding to me raising this issue. The discussion has been mainly civil, even if we disagree. Five, ten years ago, I probably would have gotten flamed out of the community entirely. So, in short, thank you for listening. We may disagree, but I appreciate being listened to. > The changes that the community makes may or may not suit you when > they happen. You can certainly work to influence the behavior of > the community. Demanding that the community change to suit your > desires doesn't work in your apartment building (dorm, homeowner's > association or county courthouse) either. That's basic social > behavior. Look to yourself for change before you look to change > others. It works better. As I mentioned, I have changed much over the past six years. I suspect this
Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
Oh, sorry for my original impolite reply (at least it is not quite gentle).
:-)
On 07/16/2013 08:22 AM, Chen Gang wrote:
> On 07/16/2013 12:20 AM, Steven Rostedt wrote:
>> On Mon, 2013-07-15 at 10:12 +0800, Chen Gang wrote:
>>
Hello Frederic and Ingo:
>> Are you trying to go around me? I wrote this code and I'm one of the
>> maintainers for it. Your issue is very minor, and can wait till other
>> things get done first.
>>
>> You said my previous patch fixed your problem, right? Then I'll add your
>> tested by and push it in due course.
>>
>> I'll also get around to adding __init's to other functions too. But it
>> is *very* low on the totem pole of importance.
>>
>
> I only provide my suggestions (or recommendations) which I think might
> be useful for us, and I don't care about whether you accept or not.
>
> If you want discuss, we can continue, if you won't (now, I guess so),
> you can just provide your choice is OK.
>
Could you provide your suggestions or completions for it ?
The trace_selftest_startup_* funcitons are mostly added by you without
'__init', do you have additional considerations about it (intend to have
no '__init') ?
If no reply, I recommend to keep no '__init': apply this patch or
regress part of the patch "f1ed7c7 ftrace: Do not run selftest if
command line parameter is set" (at least, it can avoid related warnings
and treat all *selftest* fair).
>> It's a compile time warning that's a false positive. Not a run time
>> crash or other issue of importance. It can wait, relax. Otherwise you
>> are starting to become annoying.
>
> At least this patch is not 'urgent' (not a run time crash, or other
> issue of 'urgent'), but every members have their own opinions to treat
> this issue whether 'important' or not ('important' != 'urgent').
>
> And every members' time resources are expensive (not only you, but also
> me, and other members).
>
> When I got none-reply, I don't know what happened (whether you agree, or
> not, what I said correct or incorrect ?), it is a polite to give a
> confirmation reply to tell whether you accept or not.
>
>
> 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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote: > Another thing might deviated from the main theme, but I'd like to raise it > here because I would like to see what's the proper way for that. > > For instance, people A posted a patch set to the mailing list at first, > people B think that there are some issues in A's implementation, and he > happened to play around the same stuff recently, so he submitted another > patch series. Finally, people B made it. > (In that period, people A kept silent, maybe because he/she was unhappy) > > This is a actual occurrence I once observed from a subsystem list(my > apologies, I just want to talk this case rather than against somebody), > it seems people A is a new comer(because I can not searched any past > commits of him/her from the git log), people B is definitely a senior guy. > > So that's my question, is that a proper collaboration form in kernel > community? Does it better if people B could give some suggestions to > help A to improve the code, especially if those help would help A stepping > into the kernel development -- maybe it's depend largely on one's opinion. :( This is a completely different issue from the one in this thread, but it is also a legitimate issue and honestly, a bigger one than perceived insults. Is it proper collaboration? Absolutely not. Something that I try to be sensitive to as it's something I can do as well. There's been things on my todo list, where someone would send me patches that do it. I would be thinking "darn it, I wanted to do it" and even worse, the patches that were sent wouldn't be of the way I wanted them. But I've tried to be good, and instead of just going about and implementing it myself, I would try to help the person massage the patches into what I wanted. That takes a lot of effort and discipline, and honestly, helping someone else do the work you wanted is much harder than just doing it yourself. Sometimes the maintainer just takes the easier route, and does the work themselves (because it's also more fun too). But that's really a slap in the face of the person that submitted the work in the first place. If anything hurts the community, it's this behavior. Not Linus giving someone an ass wipe. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 3.8.y.z extended stable ] Patch "memcg, kmem: fix reference count handling on the error path" has been added to staging queue
On Tue, 16 Jul 2013 16:40:09 -0700 Kamal Mostafa wrote: > On Tue, 2013-07-16 at 16:06 -0700, Andrew Morton wrote: > > On Tue, 16 Jul 2013 15:54:02 -0700 Kamal Mostafa > > wrote: > > > > > This is a note to let you know that I have just added a patch titled > > > > > > memcg, kmem: fix reference count handling on the error path > > > > > > to the linux-3.8.y-queue branch of the 3.8.y.z extended stable tree > > > which can be found at: > > > > hm, why. > > Because it said "Cc: [3.8]", making me think > the author specifically wanted it to be applied to 3.8-stable. Damn, so it did, sorry. Your version removed that line. I don't know why I did that - afaict problems can only occur when kmalloc(GFP_KERNEL) fails, and that's exceedingly unlikely. > > Now, I will freely admit that I may have made a mistake. But please be > > aware that you are taking a path which I have already considered and > > rejected. So a little extra care is warranted for akpm patches, please. > > I'll try to watch out for them. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pch_dma: fix error return code in pch_dma_probe()
From: Wei Yongjun
Fix to return -ENODEV when no proper base address found error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/dma/pch_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 237f1d5..956314d 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -860,6 +860,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
dev_err(>dev, "Cannot find proper base address\n");
+ err = -ENODEV;
goto err_disable_pdev;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/18] mm: numa: Account for THP numa hinting faults on the correct node
On Mon, Jul 15, 2013 at 11:20 PM, Mel Gorman wrote: > THP NUMA hinting fault on pages that are not migrated are being > accounted for incorrectly. Currently the fault will be counted as if the > task was running on a node local to the page which is not necessarily > true. > Can you please run test again without this correction and check the difference? > Signed-off-by: Mel Gorman > --- > mm/huge_memory.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index e2f7f5aa..e4a79fa 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1293,7 +1293,7 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct > vm_area_struct *vma, > struct page *page; > unsigned long haddr = addr & HPAGE_PMD_MASK; > int target_nid; > - int current_nid = -1; > + int src_nid = -1; > bool migrated; > > spin_lock(>page_table_lock); > @@ -1302,9 +1302,9 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct > vm_area_struct *vma, > > page = pmd_page(pmd); > get_page(page); > - current_nid = page_to_nid(page); > + src_nid = numa_node_id(); > count_vm_numa_event(NUMA_HINT_FAULTS); > - if (current_nid == numa_node_id()) > + if (src_nid == page_to_nid(page)) > count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL); > > target_nid = mpol_misplaced(page, vma, haddr); > @@ -1346,8 +1346,8 @@ clear_pmdnuma: > update_mmu_cache_pmd(vma, addr, pmdp); > out_unlock: > spin_unlock(>page_table_lock); > - if (current_nid != -1) > - task_numa_fault(current_nid, HPAGE_PMD_NR, false); > + if (src_nid != -1) > + task_numa_fault(src_nid, HPAGE_PMD_NR, false); > return 0; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On 07/17/2013 07:12 AM, Sarah Sharp wrote: > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: >> >>> Yes, that's true. Some kernel developers are better at moderating their >>> comments and tone towards individuals who are "sensitive". Others >>> simply don't give a shit. So we need to figure out how to meet >>> somewhere in the middle, in order to establish a baseline of civility. >> >> I have to ask this because I'm thick, and don't really understand, >> but ... >> >> What problem exactly are we trying to solve here? > > Personal attacks are not cool Steve. Some people simply don't care if a > verbal tirade is directed at them. Others do not want anyone to attack > them personally, but they're fine with people attacking their code. +1 I accept someone attaching my code, but it's better if he/she can point me out why the code is stupid. :) > > Bystanders that don't understand the kernel community structure are > discouraged from contributing because they don't want to be verbally > abused, and they really don't want to see either personal attacks or > intense belittling, demeaning comments about code. I feel the same way. > > In order to make our community better, we need to figure out where the > baseline of "good" behavior is. We need to define what behavior we want > from both maintainers and patch submitters. E.g. "No regressions" and > "don't break userspace" and "no personal attacks". That needs to be > written down somewhere, and it isn't. If it's documented somewhere, > point me to the file in Documentation. Hint: it's not there. Another thing might deviated from the main theme, but I'd like to raise it here because I would like to see what's the proper way for that. For instance, people A posted a patch set to the mailing list at first, people B think that there are some issues in A's implementation, and he happened to play around the same stuff recently, so he submitted another patch series. Finally, people B made it. (In that period, people A kept silent, maybe because he/she was unhappy) This is a actual occurrence I once observed from a subsystem list(my apologies, I just want to talk this case rather than against somebody), it seems people A is a new comer(because I can not searched any past commits of him/her from the git log), people B is definitely a senior guy. So that's my question, is that a proper collaboration form in kernel community? Does it better if people B could give some suggestions to help A to improve the code, especially if those help would help A stepping into the kernel development -- maybe it's depend largely on one's opinion. :( Thanks, -Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] "UEFI: Don't pass boot services regions to SetVirtualAddressMap()" breaks macbook efi boot
On 07/10/2013 04:39 AM, Fleming, Matt wrote: > On 10 July 2013 12:34, Maarten Lankhorst > wrote: >> Hey, >> >> It seems that in the merge window my macbook pro stopped working at some >> point. I looked for suspicious >> efi related commits, and found that reverting commit >> 1acba98f810a14b1255e34bc620594f83de37e36 worked, >> letting my macbook pro boot succesfully. > > Thanks for the report. I'm going to queue up a revert of this patch, > Dave Young also reported a problem on his thinkpad. > Can I grab this somewhere yet? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)
On Tue, Jul 16, 2013 at 7:32 PM, Andy Lutomirski wrote: > Fair enough. I leave it to the experts to comment on whether there > should be some explicit check of whether this is > EFI_BOOT_SERVICES_DATA. > I am reading the code again and something doesn't sound right. The original code calls efi_lookup_mapped_address. It doesn't find the image address there - which is strange given that on my system the address lies in mem type 4 as printed during boot. Hmm. But then phys_to_virt on the same address succeeds and we can read the image off of that. I might need to do some debugging of efi_lookup_mapped_address to see why it isn't finding it there. If it did find it there, none of the ioremap issues would arise. > FWIW, if my board does indeed have a DWORD-swapped address, it's in > plain old RAM (type=7). Yeah, for the status invalid case I think we would be better off just ignoring it. Too much heuristic trickery required and it might not be worth it after all that if the firmware didn't bother putting a proper image in there. Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: ppc64 module CRC relocation fix causes perf issues
On 07/16/2013 07:04:05 PM, Benjamin Herrenschmidt wrote: On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote: > On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote: > > On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote: > > > Module CRCs are implemented as absolute symbols that get resolved by > > > a linker script. We build an intermediate .o that contains an > > > unresolved symbol for each CRC. genksysms parses this .o, calculates > > > the CRCs and writes a linker script that "resolves" the symbols to > > > the calc > > > > Scott, can somebody from FSL test that on 32-bit and Ack it ? > > > > Thanks ! > > > > Cheers, > > Ben. > > It boots for me on e500mc and I can insert modules. But does perf work ? :-) What specifically should I do to test it? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: ppc64 module CRC relocation fix causes perf issues
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote: > On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote: > > On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote: > > > Module CRCs are implemented as absolute symbols that get resolved by > > > a linker script. We build an intermediate .o that contains an > > > unresolved symbol for each CRC. genksysms parses this .o, calculates > > > the CRCs and writes a linker script that "resolves" the symbols to > > > the calc > > > > Scott, can somebody from FSL test that on 32-bit and Ack it ? > > > > Thanks ! > > > > Cheers, > > Ben. > > It boots for me on e500mc and I can insert modules. But does perf work ? :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] Minor Alpha updates for 3.11
On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote: > On 07/16/2013 12:04:33 PM, Richard Henderson wrote: > >Here's a set of minor updates for arch/alpha that should not > >be controversial. > > I also note that I had to do this to get busybox to build against > uClibc: > -#define __NR_umount 22 > +#define __NR_umount2 22 > -#define __NR_oldumount 321 > +#define __NR_umount 321 I anticipate that this will likely break userspace. busybox should be fixed to test for __NR_oldumount and then call the correct functions, namely oldumount and umount if __NR_oldumount is defined and umount and umount2 if it is not defined. Cheers Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, 2013-07-16 at 19:50 -0400, Theodore Ts'o wrote: > Hopefully this helps to clarify the discussion. I'm trying rather > purposely not take one side or another, but instead trying to > articulate what I think I've been hearing people say (over, and over, > and over again, on this very long mail thread). I'll end the thread now... Dictating what you can or can not say is what the Nazis would do. There, now that Godwin's Rule has been satisfied, lets just continue this discussion at Kernel Summit. I doubt anything will change before then. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: make sure IDT is page aligned
On Tue, Jul 16, 2013 at 4:43 PM, H. Peter Anvin wrote: > On 07/16/2013 04:39 PM, Yinghai Lu wrote: >> >> ok. so the old code is just for optimization to keep it cacheline aligned? >> > > To the best of my knowledge. I guess I should look through the git log > to make sure it isn't some old erratum fix. > looks like before commit e57113bc1ff591005ec0b0fb4885d97c01de73d8 Author: Jan Beulich Date: Sat Mar 25 16:30:01 2006 +0100 [PATCH] x86_64: miscellaneous cleanup - adjust limits of GDT/IDT pseudo-descriptors (some were off by one) - move empty_zero_page into .bss.page_aligned - move cpu_gdt_table into .data.page_aligned - move idt_table into .bss - align inital_code and init_rsp - eliminate pointless (re-)declaration of idt_table in traps.c it is PAGE aligned as it is after gdt page, after the commit, it is cacheline aligned. @@ -378,9 +378,12 @@ gdt_end: /* zero the remaining page */ .fill PAGE_SIZE / 8 - GDT_ENTRIES,8,0 -ENTRY(idt_table) - .rept 256 - .quad 0 - .quad 0 - .endr + .section .bss, "aw", @nobits + .align L1_CACHE_BYTES +ENTRY(idt_table) + .skip 256 * 16 + .section .bss.page_aligned, "aw", @nobits + .align PAGE_SIZE +ENTRY(empty_zero_page) + .skip PAGE_SIZE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote: > On 07/16/2013 07:12 PM, Sarah Sharp wrote: > > On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: > >> On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: > >> > >>> Yes, that's true. Some kernel developers are better at moderating their > >>> comments and tone towards individuals who are "sensitive". Others > >>> simply don't give a shit. So we need to figure out how to meet > >>> somewhere in the middle, in order to establish a baseline of civility. > >> I have to ask this because I'm thick, and don't really understand, > >> but ... > >> > >> What problem exactly are we trying to solve here? > > Personal attacks are not cool Steve. Some people simply don't care if a > > verbal tirade is directed at them. Others do not want anyone to attack > > them personally, but they're fine with people attacking their code. > > > > Bystanders that don't understand the kernel community structure are > > discouraged from contributing because they don't want to be verbally > > abused, and they really don't want to see either personal attacks or > > intense belittling, demeaning comments about code. > > > > In order to make our community better, we need to figure out where the > > baseline of "good" behavior is. We need to define what behavior we want > > from both maintainers and patch submitters. E.g. "No regressions" and > > "don't break userspace" and "no personal attacks". That needs to be > > written down somewhere, and it isn't. If it's documented somewhere, > > point me to the file in Documentation. Hint: it's not there. > > > > That is the problem. > > > > Sarah Sharp > > The problem you are pointing out - and it is a problem - makes us less > effective > as a community. Not really. Most of the people who already work as part of this community are completely used to it. We've created the environment, and have no problems with it. Where it could possibly be a problem is when it comes to recruiting _new_ members to our community. Particularly so given that some journalists take a special pleasure in reporting particularly juicy comments and antics. That would tend to scare off a lot of gun-shy newbies. On the other hand, it might tend to bias our recruitment toward people of a more "special" disposition. Perhaps we finally need the services of a social scientist to help us find out... -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)
On Tue, Jul 16, 2013 at 03:43:57PM -0700, Sarah Sharp wrote: > I don't think we disagree on this, Ted. I've stated that I view > personal attacks and insults negatively, and I don't see an issue with > pointing out that code is bad. I think you're agreeing with me on this. Perhaps I misundrestood you, then; when you replied to Olivier's message, which used as his example "your code is crap", and "Let's leverage my fifth grade nephew's capabilities to assist you in fixing the code", it seemed to me that you called one a "personal attack", and the other an "indirect personal insults". If we're trying to say that "words matter", then it would be useful if we are careful in what we describe as "a personal atack", and what gets described as "abuse". For example, when you brought up the example of Linus yelling at Mauro, most of what I saw was Linus "yelling" (electronically) about his behaviour being unacceptable. I saw mostly, "your behaviour is idiotic", not "you are an idiot". Which perhaps is a finer gradation than the difference between "your code is crap" and "you are crap". Still, while I might call Linus's words to Mauro many things, "a personal attack" wouldn't have been one of those words. Emphatic? Yes. Yelling? Yes. Something I wouldn't do? Probably. But "A personal attack"? I'm not so sure. And then when you start reading comments from folks forua suc as G+ and Hacker News calling Linus "a dick" or "a douchebag", the irony is quite palpable > > Keep in mind that there are some cultures where even pointing out a > > technical flaw in code might considered bringing deep shame on the > > engineer and their company. So how sensitive people are to criticism > > during an electronic exchange is always going to be highly culutrally > > and personally variable. > > Yes, that's true. Some kernel developers are better at moderating their > comments and tone towards individuals who are "sensitive". ... and actually, I think it's actually quite difficult to find cases where Linus has used a very harsh tone towards someone who would be "sensitive". The argument which I've more commonly heard is one of "collatoral damage". That is, that people other than the transgressor of the bad behaviour see Linus's messages, and (a) don't realize that the vast majority of his e-mails are not that harsh, and (b) assume that Linus would use that language on them. And certainly that is a downside of sending messages of chastisement publically rather than privately. I doubt that neither Linus nor you would disagee that there is a downside tradeoff. On the other hand, if such messages are sent priviately, they are much less useful as far as establishing community norms around technical excellence, especially in regards to "no regressions" and "don't break userspace". I suspect that you and he come down on different sides of the question, "is it worth the tradeoff". The other question where I think you and Linus differ is the belief whether polite messages of the form, "it's really rude to break the kernel ABI, I would rather prefer if you wouldn't do that" are as effective at establishing community norms, compared with his style of e-mail messagtes, and whether the priority in establishing community norms around technical excellence compares with the priority around community norms around "civility". (And of course, what is considered "civil", and what is considered a "personal attack", and what isn't.) Hopefully this helps to clarify the discussion. I'm trying rather purposely not take one side or another, but instead trying to articulate what I think I've been hearing people say (over, and over, and over again, on this very long mail thread). Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] initmpfs v2: use tmpfs instead of ramfs for rootfs
Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=. Specify rootfstype=ramfs to get the old initramfs behavior. The previous initramfs code provided a fairly crappy root filesystem: didn't let you --bind mount directories out of it, reported zero size/usage so it didn't show up in "df" and couldn't run things like rpm that query available space before proceeding, would fill up all available memory and panic the system if you wrote too much to it... Using tmpfs instead provides a much better root filesystem. Changes from v1: use test_and_set_bit() for "once" logic. Changes from this morning's send: none, just hopefully not screwing up the message-id this time trying to make it a reply to another message via cut and paste... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] initmpfs v2: Move bdi setup from init_rootfs to init_ramfs
From: Rob Landley
Even though ramfs hasn't got a backing device, commit e0bf68ddec4f added one
anyway, and put the initialization in init_rootfs() since that's the first
user, leaving it out of init_ramfs() to avoid duplication.
But initmpfs uses init_tmpfs() instead, so move the init into the filesystem's
init function, add a "once" guard to prevent duplicate initialization, and
call the filesystem init from rootfs init.
This goes part of the way to allowing ramfs to be built as a module.
Signed-off-by: Rob Landley
---
fs/ramfs/inode.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
--- initold/fs/ramfs/inode.c2013-06-28 15:12:03.205879730 -0500
+++ initold2/fs/ramfs/inode.c 2013-06-28 15:12:12.425880115 -0500
@@ -275,21 +275,34 @@
static int __init init_ramfs_fs(void)
{
- return register_filesystem(_fs_type);
+ static unsigned long once;
+ int err;
+
+ if (test_and_set_bit(1, ))
+ return 0;
+
+ err = bdi_init(_backing_dev_info);
+ if (err)
+ return err;
+
+ err = register_filesystem(_fs_type);
+ if (err)
+ bdi_destroy(_backing_dev_info);
+
+ return err;
}
module_init(init_ramfs_fs)
int __init init_rootfs(void)
{
- int err;
+ int err = register_filesystem(_fs_type);
- err = bdi_init(_backing_dev_info);
if (err)
return err;
- err = register_filesystem(_fs_type);
+ err = init_ramfs_fs();
if (err)
- bdi_destroy(_backing_dev_info);
+ unregister_filesystem(_fs_type);
return err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
